Jump to content

awef

Members
  • Posts

    43
  • Joined

  • Last visited

Everything posted by awef

  1. 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!
  2. 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)
  3. https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/00-20-add-i2s-DT-pins.patch
  4. 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)
  5. https://forum.armbian.com/topic/5643-h3-i2s0-dt-overlay/
  6. 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?)
  7. 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)
  8. Probably the case. The expansion connector 95% just converts pins into pretty shaped connectors that you're familiar with.
  9. mostly everything on the expansion board is "brainless", so if it doesn't work, it's probably your main board
  10. 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
  11. And clearing out that solder bridge... what a pain! Don't do that!
  12. 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 !!
  13. 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.
  14. 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?
  15. 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.7z U-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.
  16. a little easier: https://jsfiddle.net/tuav7f6q/2/
  17. 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.
  18. 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
  19. 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?
  20. 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
  21. @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.conf From 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
  22. 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.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines