awef
-
Posts
43 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by awef
-
-
Thanks! Will give it a shot!
-
I think one thing I missed earlier is that it might be easier to use docker to compile a new kernel first (off board) since that's how armbian is "originally built" so to speak?
For chip, I'm using a PCM5102 but the interface is "just i2s" with of course it's chip specific settings (wherever those are put in)
-
-
not yet clear on how to use all the above info yet, but I'm looking into it (in case the wizards here have more urgent matters to reply to)
-
-
I just noticed there isn't a i2s/i2s0 overlay for the mainline kernel series:
Linux orangepipcplus 4.14.78-sunxi #412 SMP Fri Oct 26 11:37:04 CEST 2018 armv7l GNU/Linux
https://github.com/armbian/sunxi-DT-overlays/tree/master/sun8i-h3
Is it a simple matter of just adding some text files for DT? Or was i2s intentionally left out because or some conflict for example?
(I had good luck with legacy on Banana Pi Pro a long time ago with fex, so I'm guessing it's a unintended omission?)
-
You probably have a board with a defective SD Card Detect Pin is my guess.
I think the orange pi company doesn't check the card detect pin in their distros, so if you want your board to work, use the default distros rather than armbian for this board.
Otherwise get the board fixed (realistically probably not worth the price of shipping back and forth)
-
Probably the case. The expansion connector 95% just converts pins into pretty shaped connectors that you're familiar with.
-
Thanks for the tip!
-
mostly everything on the expansion board is "brainless", so if it doesn't work, it's probably your main board
-
try playing some audio?
-
Just a FYI
Previously using nmtui-connect and adding a Wifi Config would survive across reboots.
With nightly: Armbian_5.26.170226_Orangepipcplus_Ubuntu_xenial_dev_4.10.0
I find that I must repeatedly use nmtui-connect and even then it creates additional NM connection profiles
# nmcli c
NAME UUID TYPE DEVICE
MyWifi 60caede4-0d67-4e72-9696-6e9f76f9ec0a 802-11-wireless --
MyWifi 1 a4f778ff-e8b9-431c-ad70-98d3e32252bc 802-11-wireless --
No other OS mods (such as /etc/network/interfaces) were made
After nand-sata-install only nmtui-connect was utilized
-
And clearing out that solder bridge... what a pain!
Don't do that!
-
Interestingly enough, hard wiring SD CD to ground and having no SD card will generate constant errors. Right now, it's a bad idea
You will get constant errors
orangepipcplus login: [ 21.186031] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 8, RTO !!
[ 21.199645] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !!
[ 21.209426] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !!
[ 21.219214] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !!
[ 21.228940] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !!
[ 21.238730] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 1, RTO !!
[ 22.385924] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 8, RTO !!
[ 22.396793] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !!
[ 22.404493] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !!
[ 22.412190] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !!
[ 22.419900] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !! -
If Lubuntu and Raspbian use legacy u-boot then most probably it ignores card detect switch (i.e. legacy u-boot on Pine64 still boots fine)
In u-boot and SPL for sunxi devices - no, in kernel - maybe, but card presence can still be detected by polling. But this is a question of describing hardware configuration regardless of its usefullness, so if there is a CD switch of "correct" polarity, it is assumed to work.
Thanks for the info. I temporarily grounded out pin 9 of the SD card slot (pin nearest edge of card slot) and uboot was able to complete.
However, since it was hand-held, the kernel later hung at:
...
Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done.
...
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Check root= (did the system wait for the right device?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! UUID=928bf014-2cec-480f-98f2-ae0af0e9a28b does not exist. Dropping to a shell!
Rebooting automatically due to panic= boot argument
[ 67.957787] reboot: Restarting system
So holding CD down a bit longer it later hangs at:
...
Starting Update UTMP about System Runlevel Changes...
[ OK ] Started Update UTMP about System Runlevel Changes.
So I said okay what the heck, let's at least get nand copy going before letting go of CD. So I held CD low until the % progress bar started going and things seem to be progressing along.
Thanks all for the clues. Perhaps in later uboots we can choose to ignore CD... but I think that's a decision best left to the people more closely involved as this is clearly a hardware problem (which happens often enough for OPiPC+ aparrently). Huh... perhaps a more forgiving uboot just for OPiPC+? Bad idea? dunno.
-
This may happen if microSD slot card detection switch is broken (I have the same issue on my Pine64 - I can make it boot by pushing the card to the side when powering on, but I'll probably disable card detect switch or replace the microSD socket in the future). This can be worked around by recompiling the u-boot and changing kernel configuration (fex or DT).
Aha. So in short, the Lubuntu/Rasbian distro uboots don't reference the SD card detect h.switch. But Armbian does (which sounds like a technically good thing to do)
I'm curious, is there a benefit to checking the switch?
Or is it better to perhaps do what they do which is I'm guessing... read and check for success/fail?
-
No luck:
Armbian_5.26.170226_Orangepipcplus_Ubuntu_xenial_dev_4.10.0.img / Armbian_5.26.170226_Orangepipcplus_Ubuntu_xenial_dev_4.10.0.7zU-Boot SPL 2017.01-armbian (Feb 25 2017 - 04:11:39)
DRAM: 1024 MiB
Trying to boot from MMC1MMC: no card present
spl: mmc init failed with error: -123
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###FYI these same SD cards boot fine on other OPiPC+ boards. -
a little easier:
-
Some boards have troubles with early uboot init but this I can only guess since for that I would need to see u-boot console log. There are two things what you can do from here: attach a serial console and see what's going on - where it stops and second: try image from "Night release", which has many imprevements -> https://www.armbian.com/orange-pi-pc-plus
How do I generate this uboot log -> "since for that I would need to see u-boot console log."
I'm grabbing nightly now, so maybe it's auto-enabled.
-
Just a note. I have the same problem with just one of my boards. Here are some logs. I'm downloading nightly now.
https://www.evernote.com/l/AE_Sl4jw96dHSbCCd1bbb-Mml4-CukvFU2Y
-
FYI Replicated this on both the OPi Zero 256 and 512mb version, so it's not a board/model specific issue. Perhaps a SW config issue?
-
Orange Pi Zero - SPI1 - SPI_MOSI - Seems "weak"
SPI_SCLK is Peak-to-Peak 3.3v (no problem)
SPI_MOSI is Peak-to-Peak 165mv (whoa strange! hooked up to the o-scope)
I suspect that MOSI is "dead" in my config since the waveform matches SPI_SCLK almost exactly, so perhaps it's crosstalk or something of that sort.
I think my FEX is good. Anybody else with experience?
Does anyone else experience this problem?
root@orangepizero:/dev# ls -al spi*
crw------- 1 root root 153, 0 Jan 28 12:17 spidev0.0
crw------- 1 root root 153, 1 Jan 28 12:17 spidev1.0
[spi0]
spi_used = 1
spi_cs_bitmap = 1
spi_mosi = port:PC00<3><default><default><default>
spi_miso = port:PC01<3><default><default><default>
spi_sclk = port:PC02<3><default><default><default>
spi_cs0 = port:PC03<3><1><default><default>
[spi1]
spi_used = 1
spi_cs_bitmap = 1
spi_cs0 = port:PA13<2><default><default><default>
spi_sclk = port:PA14<2><default><default><default>
spi_mosi = port:PA15<2><default><default><default>
spi_miso = port:PA16<2><default><default><default>
[spi_devices]
spi_dev_num = 2
[spi_board0]
modalias = "spidev"
max_speed_hz = 33000000
bus_num = 0
chip_select = 0
mode = 0
full_duplex = 1
manual_cs = 0
[spi_board1]
modalias = "spidev"
max_speed_hz = 33000000
bus_num = 1
chip_select = 0
mode = 0
full_duplex = 1
manual_cs = 0
-
@tkaiser - Thanks a lot for your help. Despite hijackers, I think things work as designed.
@chrisd - Thanks for that interesting source level routing link. Coincidentally, I did spend a lot of time in Solaris, so I suppose I simply took some things for granted
As for the rest of you playing with 2 NICs in 1 subnet, the short answer is - Pick 1, Stop switching, wait a few minutes (really... wait!) , it will probably work.
Long story, the default config can easily make it look like both IPs for eth0 and wlan0 are on eth0. Thus when you finally disconnect eth0, all your wlan0 packets are sent to eth0 and fail (due to ARP responses for wlan0's IP pointing to eth0's MAC)
The fix: Update config to stop sending ARP responses for wlan0's IP with eth0's MAC. Just because it's the same "board" doesn't mean it should ARP reply that way - How?... perhaps it's something like what @chrisd wrote.
(I'll be damned.... damn near at the top of @chrisd's link)
Step 1: Enable ARP filtering on all interfaces:
# sysctl -w net.ipv4.conf.all.arp_filter=1
# echo "net.ipv4.conf.all.arp_filter = 1" >> /etc/sysctl.confFrom the file networking/ip-sysctl.txt in the Linux kernel docs:
arp_filter - BOOLEAN
1 - Allows you to have multiple network interfaces on the same
subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from
the ARP'd IP out that interface (therefore you must use source
based routing for this to work). In other words it allows control
of which cards (usually 1) will respond to an arp request.
0 - (default) The kernel can respond to arp requests with addresses
from other interfaces. This may seem wrong but it usually makes
sense, because it increases the chance of successful communication.
IP addresses are owned by the complete host on Linux, not by
particular interfaces. Only for more complex setups like load-
balancing, does this behaviour cause problems.
arp_filter for the interface will be enabled if at least one of
conf/{all,interface}/arp_filter is set to TRUE,
it will be disabled otherwise -
Anyways, my guess is that "you're right" that removing /etc/network/interfaces vastly improves reliability, even if I do have confusing issues.
I'm guessing that because ARP to wlan0-IP responds with 2 MACs (eth0 MAC, wlan0 MAC), now the macbook thinks that wlan0-IP is on the eth0-MAC.
Now this could be a "invalid case" because both eth0 and wlan0 are on the same subnet.
Anyways, back to the story. Now we disconnect eth0, and try again to connect to wlan0-IP. However wlan0-IP is associated with eth0-MAC, which of course is no longer available.
We now have to wait for wlan0-IP ARP cache to expire on the macbook before wlan0-IP will be associated at the next OPiZero ARP response with wlan0-MAC
One simple solution to all this is to say that ARP reply for wlan0-IP should be only wlan0-MAC (and not eth0-MAC), but... I can't remember off the top of my head right now whether that's correct either.
i2s Overlay for H3
in Allwinner sunxi
Posted
Well for the moment, I went the legacy/fex route and it works fine. I'll have to circle back to this mainline dto thing a bit later. Thanks!