martinayotte

So, in this case, why you need u-boot to control them if you are using python in userspace ?

Which LEDs are you talking about ?

Right ! If I remember correctly ... In such case, tweezers or jumper is the way to go !

If you wish to get rid of Android and having Armbian installed on eMMC, yes, "nand-sata-install" is the tool for that ...

Are the old module and the new RTL8723BS are pin compatible ?

With billions of 192.168.x.x around the world, they will get troubles to find you ...

Funny to have local IPs hiddened ...

What kind of error you're facing ?

There is a RTL8723BS on OrangePiPrime (and in Pinebook too if I recall correctly), and it is working fine with both NEXT or DEV images.

I've ran your cpuload.py script on mine without any issue, although top didn't reveal much stress ! My current kernel is 4.20.0 ...

00 is for the T4, 01 is for the M4 and 04 for the NEO4 ... With "default" Legacy build, the SPIDEV is builtin the kernel while in NEXT or DEV Mainline it is built as module.

Right !

Yes ! This will help to figured out the issue ...

Probably a corrupted filesystem ... Doing "ls -l /lib/aarch64-linux-gnu/libsystemd.so.0*" should reveal 2 files, one is symbolic link to the other. If files are there, maybe they are corrupted ...

So, I must be masochist since ALL by boards using old fashion /etc/network/interfaces ...

@rmoriz are you willing to do another build ? it seems that there are few commit in u-boot mainline since v2018.11 ... In your Armbian build scripts, edit this line https://github.com/armbian/build/blob/master/config/sources/sunxi64_common.inc#L7 and change u-boot tag to v2019.01, it is almost hot from the oven ... Hoping this will fix the issue, but no warranty ...

Right ! The eMMC is the one on the bottom side ... Yours is KLM8G1GETF, mine is KLM8G1WEPD . Can any other OPiZeroPlus2-H5 can tell what are their eMMC chip number ? I've also a OPiZeroPlus2-H3, and it has also WEPD version ... That must be the culprit ... EDIT : @Igor , if you get in touch with Steven from Xunlong in a near future, can you confirm with him about chip change ? Still, I don't know what need to be tweak in u-boot ... I will try to compare between u-boot and kernel drivers ... EDIT2 : @Igor , can you ask Steven to send me new OPiZeroPlus2-H5 so I can debug this issue ?

Euuh ??? So, something has been corrupted somehow ... Maybe you are better to prepare new image from scratch ...

How long it take to fill the free space ? Maybe trying to kill processes one by one to discover the guilty one ...

Thanks for the effort ! Sorry if I've been rude earlier ... Strange issue ... Could you provide picture of the eMMC ? If it differ from the one on all forum members's boards, like mine, it is maybe a new eMMC chip not supported yet by U-Boot, but still strange since it is working on a already booted kernel. I will search in U-Boot forums, mailing list, and IIRC to see if a U-Boot dev already have a fix, but I doubt since Armbian is already using v2018.11, which is quite recent ...

So, sadly, we have no clues here ... Maybe there is no other solution to do that workaround, except if you found the process that send those hexadecimal to the journal deamon ... systemctl stop systemd-journald.service systemctl disable systemd-journald.service

How your /etc/systemd/journald.conf looks like ? Mine, on all my boards, everything is commented, so disabled ... Even for myself, some RTFM is always good, we always have something to learn... Here are some reading : "man journald.conf" . Yes, it is matter : simply to know what is logged in this files to figure out who is using it, maybe a specific appllication. I can't verify on my side, since none are created ...

Thanks ! Merged : https://github.com/armbian/build/commit/5dda4b35fbd58bf485c61e8a99441ada3b94d4f1

Welcome ! Seems to be Ok ! But perhaps you should do the same in config/kernel/linux-sunxi64-dev.config too ... (no need to re-do PR, simply a additional commit)