malvcr Posted October 2, 2017 Posted October 2, 2017 1) The included Android image gives a lot of CPU failures when checking with the TTL cable. 2) When adding an Gigabit Ethernet dongle (in this case a Plugable one ~ ASIX Electronics Corp. AX88179 Gigabit Ethernet), the interface name will something similar to enx+Mac address. To replace this a file as the following one must be created: /etc/udev/rules.d/70-persistent-net.rules Containing (remember to replace THE_REAL_MAC_ADDRESS for the displayed enx+Mac interface address: SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="THE_REAL_MAC_ADDRESS", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" 3) When making an apt-get update ; apt-get upgrade, some errors can be displayed ... but it works in general. Unpacking linux-headers-dev-sun50iw2 (5.31) over (5.27) ... dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.11.0-sun50iw2/scripts/mod': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.11.0-sun50iw2/scripts/kconfig': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.11.0-sun50iw2/scripts/basic': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.11.0-sun50iw2/scripts/dtc': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.11.0-sun50iw2/scripts': Directory not empty Before update: Linux orangepizeroplus2 4.11.0-sun50iw2 #3 SMP Sun May 14 17:34:53 CEST 2017 aarch64 aarch64 aarch64 GNU/Linux After update: Linux orangepizeroplus2 4.11.1-sun50iw2 #17 SMP Thu Jun 15 03:10:38 CEST 2017 aarch64 aarch64 aarch64 GNU/Linux 4) Before or after the upgrade, the micro usb port DOES NOT WORK even in host mode. 5) After working for a while, the temperature it is normal. (39 in the H5 machine, with a NAS extension and an USB SSD attached there). 6) armbianmonitor really doesn't work (all, but the temperature, it is zero, and CPU frequenncy is ---). 7) The nand-sata-install works well. No SD is needed after that. I will check the micro-usb to see what happens. In the while I will ask for some H3 models of this card. 1
malvcr Posted October 2, 2017 Author Posted October 2, 2017 I have been trying with the dtb files to change from OTG (micro USB port) to HOST the usb0 interface when attached to a NAS extension (the machine it is powered from the extension through the 13 pinouts). After checking with several devices, nothing happened. Then I connected a USB tester in the USB line and it doesn't work ... even can't turn the LCD tester screen ... it seems that the port it is disconnected when receiving electricity from the NAS card. I will continue checking what could be the reason for that, or if this is an "expected" behavior.
martinayotte Posted October 2, 2017 Posted October 2, 2017 This is because of Q10 MOSFET, it isolate the DCIN pin from header from the one of MicroUSB. To workaround that, you will need to short the DRAIN and SOURCE of this Q10 or to wire DCIN with VBUS.
malvcr Posted October 2, 2017 Author Posted October 2, 2017 Hi Martin ... mmm, I am not confident enough to change the electronics in so small devices. What about to modify a data USB cable and to acquire the electricity from the DCIN ... or even the GPIO, letting the other wires as they are connected in the micro-USB port? At the end, my intention is to connect a Zero or even a R1 machine using the OTG to the Zero+2 with g_ether (to create some sort of physical firewall) ... just that I was short of USB ports and I didn't like to share other ports bandwidth or electricity capacities.
martinayotte Posted October 2, 2017 Posted October 2, 2017 Yes, you can hack the cable itself ... But, wait a minutes : do you wish OTG or HOST mode, because for OTG, no need to hack the wire, the MicroUSB in "input" when OTG g_ether ! ( I though you wish to connect an USB drive into the HOST mode ...) Then, this mean maybe you forgot something in DT or their is a missing setup with the driver.
malvcr Posted October 2, 2017 Author Posted October 2, 2017 Well ... I am 50%. Following the idea, and taking into consideration what several hats do, I was able to power the OPIZ from the OPIZ+2H5 wiring the GPIO between both directly (5v to 5v and Ground to Ground). So I don't need to hack USB cables to power the computer, just to create the right cable for GPIO ports. However I can't make the OPIZ+2 to keep the microUSB active. Reading everywhere, I found that changing the dr_mode to "host" in the dtb file (that it is not named zeroplus2 but just zeroplus) could do that, but no matter what I do, the same message is present: usb0-vbus: disabling
martinayotte Posted October 3, 2017 Posted October 3, 2017 13 hours ago, malvcr said: I found that changing the dr_mode to "host" in the dtb file That is why I've asked you : do you want it to be OTG with g_ether or HOST ? HOST mode is to attached an external HDD, so in this case you will need the cable hack and use this kind of adaptor : http://www.ebay.ca/itm/USB-Host-OTG-Adaptor-Adapter-Cable-Cord-For-Acer-Iconia-Tab-A1-810-B1-A71-B1-710-/251802722532
malvcr Posted October 3, 2017 Author Posted October 3, 2017 When using the g_ether, one side must be HOST and the other SLAVE (OTG mode). I can choose whatever side as OTG, even the H5 machine. However, I read someplace (could be wrong) that the OTG in the current Armbian implementation for the OPIZ+2 H5 it is not complete. This is why I was trying to configure it as HOST, letting the OTG in the OPIZ side. But if Armbian can work in OTG mode for the OPIZ+2 H5 then I don't need to do that. I just need to resolve the "disabling" issue. -- I also will try something different. Instead of connecting the Zero with the microUSB cable, I will connect a USB disk there with a hacked cable. But I am not sure if this works when having the disabling usb0 still present. Maybe the first thing I need to do is to avoid that "disabling" operation some way, and then I will have all these options at my hand. With no port enabled, no option available.
martinayotte Posted October 3, 2017 Posted October 3, 2017 13 minutes ago, malvcr said: I just need to resolve the "disabling" issue. This is probably due to your cable hack ... In HOST mode, The USB-IDDET pin level determine if it is really in HOST mode (when pin grounded) or OTG (when pin floating). See this post : So, if you purchase the adaptor I've provided link above, this USB-IDDET pin is already properly wired for HOST mode.
malvcr Posted October 3, 2017 Author Posted October 3, 2017 I will wait for a little ... it is exhausting to test these things :-). In fact, I have three different OTG cables as the one you reference (from ASUS, from Canakit and from Pimoroni) ... no one of them do a difference. I made my own mixed cable, read about the IDDET signal and built according with that ... no difference. Then, I downloaded the nightly-build from the download page (who knows, maybe works) ... no way. In fact, that version has some strange things. In some moment asked me for an alwinner directory bellow dtb/allwinner, and for a dtb ending on "plus2" while there is no dtb file with that name there. In this moment what I know is that if I use the NAS extension, I only will have one extra USB and the microUSB will be disabled.
Harry Posted October 5, 2017 Posted October 5, 2017 Hello. Sorry if I'm posting to the wrong topic. I have Orange Pi Zero Plus 2 H5. Installed Armbian, all worked well but after apt-get upgrade wifi stopped to work. I tried twice to write image to SD card, move to eMMC, but after apt-get upgrade wlan0 disappeared. Any suggestions? sorry for my english
malvcr Posted October 5, 2017 Author Posted October 5, 2017 There is something really strange ... to have a double check, I replaced the NAS extension with direct cables to the USB port pinouts. Then, I found that my problem is consistent (it is not related with the NAS extension). Doing this, I found that the H5 machine really has been working well as the HOST side of the Ethernet over USB connection; for doing that, I connected a Raspberry Pi Zero and immediately acquired the address and performed a full perfect connection. But my Orange Pi Zero (with Legacy kernel) doesn't like to work well. Then, reading the usb0 link on the OPIZ+2 with tcpdump, I found that both machines are communicating but that my ping packages are shifted 4 bytes. This is the reason they don't like to agree with the communication. No one package arrive complete and they are broken at 28 bytes. Checking around, it seems there was a bug in some kernel driver on the Gadget ethernet implementation for kernel 4.0 series . But as it works well when connecting with the Raspberry Pi Zero, tomorrow I will check with a mainline kernel on the Orange Pi Zero to verify if the problem is with the kernel versions.
Igor Posted October 5, 2017 Posted October 5, 2017 23 minutes ago, Harry said: but after apt-get upgrade wlan0 disappeared. Images are experimental and not ready for end users, upgrading is not tested and might break. Go to armbian-config (download if not present) and hold/freeze kernel upgrades. This might help and you could be able to upgrade other packages safely. It's a temporary solution.
Michael Dehn Klit Posted October 5, 2017 Posted October 5, 2017 Quote Go to armbian-config (download if not present) and hold/freeze kernel upgrades. I tried this, and it doesn't work WiFi breaks the moment you upgrade.
Igor Posted October 5, 2017 Posted October 5, 2017 9 minutes ago, Michael Dehn Klit said: I tried this, and it doesn't work WiFi breaks the moment you upgrade. Then it could be firmware related ... will check this later on. Which packages are getting update?
Michael Dehn Klit Posted October 5, 2017 Posted October 5, 2017 Locked the Kernel in Armbian-Config and did the upgrade. And the result is no wifi
Michael Dehn Klit Posted October 5, 2017 Posted October 5, 2017 Did another test with the 5.32.170706 nightly Ubuntu 16.04.2 LTS 4.11.8-sun50iw2 and wifi is working on this version. Did a package lock and updated Armbian and it looked like this. Reboot and WIFI is gone.
Igor Posted October 6, 2017 Posted October 6, 2017 Try to also apt-hold linux-firmware and armbian-firmware prior to the upgrade. I highly suspect they overwrites correct firmware.
Michael Dehn Klit Posted October 6, 2017 Posted October 6, 2017 So I used the 5.32.170706 nightly Ubuntu 16.04.2 LTS 4.11.8-sun50iw2 Locked Kernel in Armbian-Config and did a apt-mark hold linux-firmware apt-mark hold armbian-firmware apt-get update && apt-get upgrade And Wifi is working The I unlocked the Kernel and did an upgrade, but didn't unlock linux-firmware & armbian-firmware And Wifi is working Then apt-mark unhold armbian-firmware apt-get update && apt-get upgrade And WIFI is gone 1
Igor Posted October 6, 2017 Posted October 6, 2017 Suspicions are confirmed ... now what would be the best fix? Thanks for your time.
zador.blood.stained Posted October 6, 2017 Posted October 6, 2017 3 hours ago, Igor said: Suspicions are confirmed ... now what would be the best fix? Check/bisect our firmware changes? https://github.com/armbian/build/commits/62884059870855f7f4603df45d8a30cb77992ff0/bin/firmware-overlay This would be the first suspicious commit to check and possibly restore old firmware files: https://github.com/armbian/build/commit/042c25aaef2ae81b9117201aae0aa0da6c214354#diff-7b6ff26268d948c881ef30427eecc5f9 looks like a legacy kernel related change We may need to compare /lib/firmware contents before and after the upgrade to find what files were changed
martinayotte Posted October 6, 2017 Posted October 6, 2017 1 hour ago, zador.blood.stained said: We may need to compare /lib/firmware contents before and after the upgrade to find what files were changed Right ! ... and since fresh image instead of upgrade is working properly, it is probably that upgrade doesn't overwrite something.
zador.blood.stained Posted October 6, 2017 Posted October 6, 2017 I wouldn't call a 3 months old nightly "fresh image", last time I tested OPiZ+2 wireless didn't work with the latest firmware from armbian/build
martinayotte Posted October 6, 2017 Posted October 6, 2017 I means that I've my OPiZeroPlus2-H5 actually running 4.13.2 built on Sept 14th, and wlan0 is working fine, but I'm seeing that I've overwritten the /lib/firmware/brcm/brcmfmac43430-sdio.bin. I don't recall why I've done this overwrite or if it is part of an automated first_run script, since it produced /lib/firmware/brcm/brcmfmac43430-sdio.bin.bak (usally, when I do manual backup, I do it more visible with *-BAK or *-ORIG) The new one has filesize 374608 bytes, while the one inside the image is still 336323 bytes.
martinayotte Posted October 6, 2017 Posted October 6, 2017 Got it : https://github.com/armbian/build/blob/master/packages/bsp/common/etc/init.d/firstrun#L174-L179 But this code isn't ran during a simple upgrade ... 1
xalu Posted October 10, 2017 Posted October 10, 2017 On 10/2/2017 at 7:51 PM, malvcr said: Following the idea, and taking into consideration what several hats do, I was able to power the OPIZ from the OPIZ+2H5 wiring the GPIO between both directly (5v to 5v and Ground to Ground). Sparked my curiosity here. So you are powering the orangepi zero plus2 into gipo (pins 1 and 2?) directly from an orange pi zero's gipo? I didn't think they could take that much current without burning up. Would be good to know. I can try a different approach to what I was planning. Thanks
martinayotte Posted October 10, 2017 Posted October 10, 2017 Depending of manufacturer of the female headers, such pins could support around 3.0A, far more than the MicroUSB ...
willmore Posted October 10, 2017 Posted October 10, 2017 4 minutes ago, martinayotte said: Depending of manufacturer of the female headers, such pins could support around 3.0A, far more than the MicroUSB ... I think the question becomes "where does the OpiZ get power? If it's over the micro-USB, then it's looking dangerous.
zador.blood.stained Posted October 10, 2017 Posted October 10, 2017 On 06.10.2017 at 9:40 PM, martinayotte said: Got it : https://github.com/armbian/build/blob/master/packages/bsp/common/etc/init.d/firstrun#L174-L179 But this code isn't ran during a simple upgrade ... I wonder what devices actually work without this hack: https://github.com/armbian/build/commit/71c466cba7f3a1fb3221f154c8e86ff781a4a565#diff-7563a343fbfc02b76915df346c297ba1 i.e. what will break if we just copy/overwrite the firmware files in the armbian-firmware package
martinayotte Posted October 10, 2017 Posted October 10, 2017 What I means is that if OP was doing an upgrade, not a fresh install, this copy of firmware was already executed during his first installation. But if a new firmware package is installed afterword, and since this piece of code is not part as "post install script", the copy will be reverted to the wrong firmware. Right ? Of course, the OP can do this manual copy, it will fix the issue ...
Recommended Posts