Details with OPIZ2+ H5

zador.blood.stained · October 10, 2017

6 minutes ago, martinayotte said:

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 ?

Yes, but why do we have to copy/overwrite files in the first place? Ideally we have to either distinguish between different chip revisions or find a single set of firmware that works for all hardware. In reality we may just select the one that breaks in fewer scenarios or for less popular boards.

martinayotte · October 10, 2017

Right ! Most of the boards are using A1 version, but some older board are using A0.

I would rather having to manually patch the crappy A0 !

But, unfortunately, I'm not fluent with how "armbian-firmware" package is built in the build process.

zador.blood.stained · October 10, 2017

9 minutes ago, martinayotte said:

But, unfortunately, I'm not fluent with how "armbian-firmware" package is built in the build process.

https://github.com/armbian/build/blob/master/packages/extras/firmware.sh

malvcr · October 10, 2017

I made some tests several months ago with two Zero machines, one powered from the other (that even worked as an usb0 network device) and a hard disk from one of them and it worked "well" ... but you are right, I don't know in the long term if this method for powering the computers could produce some damage. Maybe with a low consumption disk (or without it), would be better.

The next test was different. The Zero2+H5 was connected in a NAS expansion (from the internal 13 connector) and receiving the power from the barrel connector there. The hard disk was in the NAS expansion, and a Zero was connected on the Zero2+H5 GPIO pins. So, no micro USB was powering either machine.

In general, if it is necessary to power some machine through the USB port, then it is better this to be the last one in the chain, and not to ask that machine to consume a lot of power by reducing the quantity of connected devices there.

Now I am making a different arrange, but with a BPI-R2 machine; this receives 12V and was built for more demanding work than the OPi Zero ... then I can connect a Zero from the BPI-R2 USB port or from the BPI-R2 GPIO with less worries (in fact, I will replace the Zero with a BPI-M2+ when it arrives).

martinayotte · October 10, 2017

23 minutes ago, zador.blood.stained said:

https://github.com/armbian/build/blob/master/packages/extras/firmware.sh

Do you mean that simply adding the piece of code around line 28 of firmware.sh would do the job ?

If Yes, I will try, but with some exhaustive testing ...

zador.blood.stained · October 10, 2017

50 minutes ago, martinayotte said:

Do you mean that simply adding the piece of code around line 28 of firmware.sh would do the job ?

No, this is executed on the build host. In theory you could add a postinstall script to copy/overwrite the files, but IMO it is still an ugly and unreliable hack.

martinayotte · October 10, 2017

Yes, but if on build host we copied the good firmware from $SRC/cache/sources/$plugin_dir/lib/firmware/ap6212/fw_bcm43438a1_apsta.bin into $SRC/cache/sources/$plugin_dir/lib/firmware/brcm/brcmfmac43430-sdio.bin before doing the packaging, it should work too ...

zador.blood.stained · October 10, 2017

The hack in firstrun replaces one brcmfmac43430-sdio.bin with another depending on dmesg error message presence. If fw_bcm43438a1.bin can be used as brcmfmac43430-sdio.bin on all devices then we could just replace it in the repository, but this needs to be tested first.

zador.blood.stained · October 10, 2017

Also the mainline driver code has this:

BRCMF_FW_NVRAM_DEF(43430A0, "brcmfmac43430a0-sdio.bin", "brcmfmac43430a0-sdio.txt");
/* Note the names are not postfixed with a1 for backward compatibility */
BRCMF_FW_NVRAM_DEF(43430A1, "brcmfmac43430-sdio.bin", "brcmfmac43430-sdio.txt");

so we may just have to rename and copy some files

martinayotte · October 10, 2017

14 minutes ago, zador.blood.stained said:

but this needs to be tested first.

Of course !

When I get a chance ...

(Since I personally never do upgrades, always install from scratch, I've never faced the issue people reported.)

tkaiser · October 10, 2017

2 hours ago, zador.blood.stained said:

Ideally we have to either distinguish between different chip revisions

Can we read out the 'chip id' (according to this here 0x00000001 for 43430A0 and 0xFFFFFFFE for 43430A1)? There's a lot of work going on around 43430A1 used on RPi 3 (eg. preparing further firmware changes or recently the BroadPwn fix all 'our' AP6212 devices still wait for).

Wrt 'all devices'... we support certain boards that exchanged the A0 AP6212 with A1 in between (eg. Banana Pi M2+ or NanoPi Air).