5kft

Just fixed this in master; they rolled this patch into upstream with -rc6. Thanks for noting this!

Exactly - this is because these additional Wi-Fi drivers are conditionally added outside of each local target patchset. If the drivers aren't included (e.g., via "EXTRAWIFI=no", then the patches will fail because there are no files to patch. As @Werner notes, this is really just a cosmetic issue.

I'm not sure if this will help at all, but figured I'd mention it just in case: These traps look somewhat similar to some that I fixed for the RTL8812AU driver (see https://github.com/aircrack-ng/rtl8812au/pull/704). I don't have an RTL8188EU, but the changes are simple enough to try if you have some spare time - see https://github.com/aircrack-ng/rtl8812au/pull/704/commits/94340760e7d6144a2099eccbebb21dc53fe9fdeb. Obviously you'll have to find the related lines in the 8188 sources to make the changes, but this should be pretty easy to try.

@guidol - no, while this may seem weird it's perfectly normal - this is a "bind mount", and this is how bind mounts appear in "mount". You can create one of these yourself, for example: root@nanopi:~# mkdir foo bar root@nanopi:~# mount --bind foo bar root@nanopi:~# mount | grep bar /dev/mmcblk1p2 on /root/bar type f2fs (rw,relatime,lazytime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,fsync_mode=posix,compress_algorithm=lz4,compress_log_size=2) root@nanopi:~# (The "log.hdd" bind mount is created via "/usr/lib/armbian/armbian-ramlog".) Hope this helps!

It'd be worthwhile to search the forums regarding this subject, e.g., https://forum.armbian.com/topic/6398-orange-pi-zero-cpu-and-load-issues-with-538/?do=findComment&comment=58057. If you want to change this in the system, you'll have to update the appropriate DT and add the desired clock entries.

Which patching logs? Are you seeing errors w/-dev? AFAICT I resolved everything that needed resolution in v5.9. Again, are you seeing issues with something?

This fixes operation for these overlays under v5.9 so that they work correctly (just like under v5.8)

@guidol - thank you, the logs you provided were exactly what I needed! I have fixed the issue with the overclock overlays for -dev, and have push the changes to master (https://github.com/armbian/build/commit/9a096fc557367668e01736400d2c5cb4c8c28a75). Please give these changes a try and let me know how it goes!

DT additions checked in to sunxi-current and sunxi-dev (see https://github.com/armbian/build/commit/61e4b39303a2a07a828a2014af393064ba63f843). The board LEDs were also missing, so I added those too. Note that I don't actually have a NEO H3 to test with, but given that these parts of the board are identical to the NEO2 the changes should work

Actually from the schematic (http://wiki.friendlyarm.com/wiki/images/f/fd/Schematic_NanoPi-NEO-V1.4-1801-20180320.pdf), the NEO H3 has an MP2143DJ GPIO regulator, which supports switching betwen 1.1v/1.3v - the board DT is just missing the regulator entry. This is why the default maximum CPU clock is too high; adding this regulator will correctly address this problem by default and will also allow the board to be overclocked (potentially to 1.3GHz) using the overclocking overlays. I'll look at adding support for this in the DT.

Yes! I am glad to hear this

I think that would definitely be worth a try.

Part of this difference could be that in the newer kernel more audio modules built in. What I'm seeing is that when I try analog audio it works fine - e.g., I don't see the "no soundcards" error, and I can play audio, etc. (e.g., I tested on a NEO Core2 but don't get any audio errors on any of the other boards either). So it seems that there is something different for the A64, and I agree with you it's likely the DT configuration.

OK, so you don't have a problem with the v1.1, but you do have a problem with the v1.0. Doing a quick look at the bootloader logs, here is what I see so far: U-Boot 2019.04-armbian (Nov 18 2019 - 21:52:14 +0100) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO 2 DRAM: 512 MiB MMC: mmc@1c0f000: 0 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** In: serial Out: serial Err: serial NanoPi NEO2 v1.0 detected #### this is your v1.0 board Net: phy interface7 eth0: ethernet@1c30000 ** Reading file would overwrite reserved memory ** There is no valid bmp file at the given address #### this is strange - it can't find the LCD bitmap (??) starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning bus 3 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3042 bytes read in 1 ms (2.9 MiB/s) ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 143 bytes read in 0 ms 30956 bytes read in 7 ms (4.2 MiB/s) #### this is sun50i-h5-nanopi-neo2.dtb, which is correct 478 bytes read in 3 ms (155.3 KiB/s) #### this is sun50i-h5-cpu-clock-1.0GHz-1.1v.dtbo, which is correct Applying kernel provided DT overlay sun50i-h5-cpu-clock-1.0GHz-1.1v.dtbo failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND #### this is strange 504 bytes read in 6 ms (82 KiB/s) #### this is sun50i-h5-usbhost1.dtbo Applying kernel provided DT overlay sun50i-h5-usbhost1.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC #### strange base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 504 bytes read in 5 ms (97.7 KiB/s) #### sun50i-h5-usbhost2.dtbo Applying kernel provided DT overlay sun50i-h5-usbhost2.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ Error applying DT overlays, restoring original DT 30956 bytes read in 7 ms (4.2 MiB/s) 10302643 bytes read in 506 ms (19.4 MiB/s) 21235720 bytes read in 1038 ms (19.5 MiB/s) Could you post both the v5.8.3 dtb .deb and the v5.9-rc2 dtb .deb that you are using? It be helpful to take a look and see what the differences are.

OK, it's very likely a v1.1. If you "ls /sys/class/leds/" do you see "green" and "red" LED entries or "red" and "blue" LED entries?

OK, interesting - to confirm, this this second NEO2 a v1.1?

Yes, but he's running a version from last year. But, I don't think that's the problem because his old u-boot is booting 5.8 okay. It's more like his DT installation is broken or something. This is what is confusing because this is literally the same for 5.9. That's why I'd like to try a consistent baseline to debug (e.g., try the build I posted above).

Understood - just have no idea why it didn't install correctly.

@guidol - thanks! U-boot won't install if you try installing -dev over -current (for example) - this is what I wanted to see. I just did a full build of v5.9-rc2 from master and verified that it works fine on my NEO2 - do you want to give it a try? https://drive.google.com/file/d/1UBJY_PT66cA_MLRYxsgHsvX-Qex01ZMr/ (just "sudo dpkg -i *.deb" the files in this tarfile) This could hopefully help narrow down if it is a build problem or something else.

@guidol thanks for the detail! Ah, I'm too used to running different filesystems for "/", so I always have different partitions What it looks like is that the u-boot dpkg install failed for 5.9. When you used "dpkg -i" to install your 5.9 .debs, did you get any messages from dpkg regarding a package conflict for u-boot? Could you post the output of "dpkg --list | grep boot" for your 5.8 install? Correct - you want to use "Install/Update Bootloader on SD/eMMC". Also, as a test, I just reinstalled 5.9 on one of my NEO2s, and it works great, so it should work for you. This is why I suspect an installation issue with the bootloader .deb.

Did this work for you in 5.7.x. or 5.4.x? Perhaps there are some kernel configs missing, and/or some DT changes didn't make it over okay. Knowing what version it last worked on could provide a helpful starting point.

It's hard to say what happened without seeing the boot process on console, and the contents of /boot. I've gotten in the habit of uninstalling the current kernel + dtbs before installing the new one in some instances (such as going from -current -> -dev or 5.8 -> 5.9), as by default if you just install the new one the old one won't get uninstalled, and the boot partition can run out of space. (I ran into this a lot as I was doing the work on v5.9...perhaps I should bump the /boot partition size up a bit more again...) One relatively straightforward way to recover from this situation is to use another card and install a fresh/bootable Armbian image onto it (/boot, /, etc.) Then simply copy over the rootfs contents from the old card over to the new card (/ partition), taking care to set the new rootfs UUIDs in /boot/armbianEnv.txt and /etc/fstab. You can use "--exclude" with tar to skip copying the contents of /dev/, /proc/, etc. I created a full backup process for my boards using this process. I could try to write up some instructions on how to do this if it would be helpful.

Yes, one part of this patch is included in the v5.9 mainline upstream, so that particular part is rejected as it is already present. This patch is a general patch for all builds (it is present in patch/misc), so it's a little more work to address - e.g., it's a matter of splitting the patch and doing a kernel version check during the build. I simply haven't gotten around to addressing this yet in the build process (there's no impact because of this).

Agreed - I did this locally as well and it worked fine.