Jump to content

Details with OPIZ2+ H5


malvcr

Recommended Posts

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

 

updates2.png.4519a93ca91195244a74c089fddc5f29.png

 

And Wifi is working

The I unlocked the Kernel and did an upgrade, but didn't unlock linux-firmware & armbian-firmware

 

updates3.png.7b4971e56e35808d67e4f989a678c6c9.png

 

And Wifi is working

 

Then apt-mark unhold armbian-firmware
apt-get update && apt-get upgrade

 

And WIFI is gone

Link to comment
Share on other sites

3 hours ago, Igor said:

Suspicions are confirmed ... now what would be the best fix? :huh:

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 ...

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines