Latest Bookworm Image for the Neo 2 Black seems to be broken #7367
Milestone
Comments
|
Many thanks for your report. Hmm, the images are identical despite the bootloader. Do you have a USB-UART adapter to check serial console output? I also just see it seems to support a serial console via USB, but it would need to be enabled. Can you access the ext4 partition from another system, in case? |
|
Yes, I'm able to access the rootfs partition using a card adapter for my laptop. With the black edition image the firstboot is alwasy stopping on the same place. Sometimes it's waiting for emmc for infinity. Here the header of the working neo2 image: Take a look at the ethernet device, too! |
|
Okay, while the bootloader does not detect the Ethernet, it detects the eMMC directly and loads kernel etc successfully. So you say at the end of the output, it does not do anything anymore? This is from the filesystem expansion script, which did expand partition successfully at this point. The next commands are What caught my eyes is that the bootloader is actually not for the NEO2 Black, but the NEO Core2. This is intentional, but not sure whether correct. At least it is two dedicated SBCs:
Mainline U-Boot does not support any of those two, but they are patched inside by the Armbian build system:
While FriendlyELEC's U-Boot fork does not provide a dedicated defconf for that board, the board detection code seems to indicate the the NEO2 Black is closer to the NEO2, than the NEO Core2: https://github.com/friendlyarm/u-boot/blob/sunxi-v2017.x/common/board_r.c#L842-L871 But it is probably a particular one particular hardware feature which lead to taking the Core2 config and device tree. Does the NEO2 image probably limit available RAM to 512 MiB on the 1 GiB RAM variant of the NEO2 Black? The U-Boot output however shows 1 GiB in both cases. |
|
The image of the Neo2 takes only a few minutes when resizing the partitions with resize2fs. |
|
Ah right, the eMMC which the NEO Core2 has as well will e the reason why its bootloader is used. And since there is no other/dedicated one for the NEO2 Black in mainline U-Boot or compatible vendor branch, that one was seen and likely just worked well enough. So the problem is not in the bootloader, but actually in the kernel/device tree. Let me check how it looks like:
Difference in the SD card node: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=aee2eca Also, regarding Ethernet and U-Boot we can try to fix it, taking recent updates from mainline U-Boot: https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/sun50i-h5-nanopi-neo2.dts |
Merged
Merged
MichaIng
added a commit
to MichaIng/build
that referenced
this issue
Jan 27, 2025
MichaIng/DietPi#7367 Signed-off-by: MichaIng <[email protected]>
|
U-Boot is ready for testing: MichaIng/build@03b248f cd /tmp
wget https://dietpi.com/downloads/binaries/testing/linux-u-boot-nanopineo2black-current.deb
dpkg -i linux-u-boot-nanopineo2black-current.deb
/boot/dietpi/func/dietpi-set_hardware flash-uboot-mmcThen check whether it detects the Ethernet device now. As far as I can see, the kernel drive is enabled with the existing patch already. |
|
Can you test the image from here? It shops with the patched kernel and bootloader: https://dietpi.com/downloads/images/testing/ |
|
Ok, I'll do it. But for now I have an hardware issue. I'll be back, soon. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Writing on different SD-Cards doesn't matter.
I tried the "normal" neo2 image, too.
This one is working like a charm.
Therefore it seems that the neo2 black image has an issue.
The text was updated successfully, but these errors were encountered: