DietPi
DietPi copied to clipboard
MichaIng
NanoPi 2 Fire not bootable since DietPi v8.4
Hi,
Since v8.4 my old NanoPi 2 Fire is no longer bootable, the board is probably an older revision since the kernel 4.4 official firmware is not working too, due to the incorrect dtb file used.
I compiled the dts from friendlyarm/linux#4, and my board boots successfully with all functions working properly.
Maybe DietPi can include the dtb for older revision boards?
Ah nice, many thanks for compiling it. So the bootloader picked it automatically, right?
Ah nice, many thanks for compiling it. So the bootloader picked it automatically, right?
Nope, the bootloader won't pick it up automatically (for NanoPi 2 Fire anyway, don't have M2), but user can probably interrupt the boot process and enter the following commands to change it (or simply replace the rev04 dtb file on PC).
setenv dtb_file s5p4418-nanopi2-rev05.dtb
saveenv
Ah okay. I'll have a look, probably it works when changing the U-Boot environment.
The dtb is selected based on board revision here: https://github.com/friendlyarm/u-boot/blob/nanopi2-v2016.01/board/s5p4418/nanopi2/board.c#L347-L354
Revisions are obtained here: https://github.com/friendlyarm/u-boot/blob/nanopi2-v2016.01/board/s5p4418/nanopi2/hwrev.c#L64-L131
Actually, as far as I understand code, it is derived in a generic way, and if it is returning 05 on NanoPi 2 Fire, the s5p4418-nanopi2-rev05.dtb device tree should be picked automatically. The board name will be shown as "s5p4418-X", but who cares 🙂.
The PR you compiled with states it is NanoPi M2, and indeed according to the sources, only NanoPi M2A device tree is present. However, usually one device tree can be used on another board, as long as no critical hardware elements differ.
Have you tried renaming it to s5p4418-nanopi2-rev06.dtb, whether this works without explicitly defining dtb_file in U-Boot env?
In U-Boot, you should be moreover able to print the revision via echo ${board_rev}, or the dtb which is tried to be used via echo ${dtb_name}.
@NewbieOrange
When you find time, have you tried renaming s5p4418-nanopi2-rev05.dtb to s5p4418-nanopi2-rev06.dtb or s5p4418-nanopi2-rev08.dtb, whether this works without explicitly defining dtb_file in U-Boot env?
Unfortunately, ${board_rev} is 04 too... It seems friendlyarm have released two hardware revisions of the "same board", both recognizing themselves as rev04. Maybe we can have a "legacy M2/T2/Fire 2A" version of DietPi? differentiating from the current (newer) hardware rev.
Nope, with the ancient kernel there are only other issues programmed, and the effort to implement and maintain a second build is too high, given the low amount of users and that we cannot support the board at all with Debian Bookworm next summer.
Hmm, probably the 05 dtb works with both 04 revisions. I'll compare those. Adding the 05 dtb at least is simple and makes sense.
Does it work if you rename s5p4418-nanopi2-rev05.dtb to s5p4418-nanopi2-rev04.dtb and skip defining it in boot env? The differences in the two dtb sources are minimal, so I can nearly not imagine how one can work and the other not.
Does it work if you rename s5p4418-nanopi2-rev05.dtb to s5p4418-nanopi2-rev04.dtb and skip defining it in boot env?
Yes. Maybe we can just add the 05 dtb, and user can simply switch to it if the 04 is not bootable.
With 04 dtb, kernel immediately crashed: https://pastebin.com/8pqfPzRP
Okay, based on U-Boot output indeed the 04 dtb is selected automatically. Difference is small, but obviously sufficient to break boot on NanoPi 2 Fire:
- https://github.com/friendlyarm/linux/blob/66b79c8/arch/arm/boot/dts/s5p4418-nanopi2-rev05.dts
- https://github.com/friendlyarm/linux/blob/66b79c8/arch/arm/boot/dts/s5p4418-nanopi2-rev04.dts
and user can simply switch
I guess most users wouldn't know how, also e.g. how to apply the change persistently. However, now that we know that the DTB is selected automatically, adding the 05 one at least adds support for another model (quite strange that the most popular M2(?) isn't supported by official FriendlyELEC images) and at least adds the option to manually fix it on NanoPi 2 Fire.
If we find a Fire 2A user/owner, we could further verify whether it works the other way round without downsides, e.g. not sure what this dummy sound driver and dummy DVFS are used for. Our of interest, could you paste the output of:
dmesg | grep -iE 'dvfs|asv'
root@DietPi:~# dmesg | grep -iE 'dvfs|asv'
[ 1.455000] DVFS: ASV[0] IDS(10mA, 8) Ro(110,105)
[ 1.455000] ASV 0 = 1400000khz, 1260000 uV
[ 1.455000] ASV 1 = 1300000khz, 1180000 uV
[ 1.455000] ASV 2 = 1200000khz, 1140000 uV
[ 1.455000] ASV 3 = 1100000khz, 1100000 uV
[ 1.455000] ASV 4 = 1000000khz, 1100000 uV
[ 1.455000] ASV 5 = 900000khz, 1060000 uV
[ 1.455000] ASV 6 = 800000khz, 1060000 uV
[ 1.455000] ASV 7 = 700000khz, 1020000 uV
[ 1.455000] ASV 8 = 600000khz, 1020000 uV
[ 1.455000] ASV 9 = 500000khz, 980000 uV
[ 1.455000] ASV 10 = 400000khz, 980000 uV
[ 1.462000] DVFS: regulator vdd_arm_axp
[ 1.462000] DVFS: cpu DVFS with PLL.1 [tables=11]
Okay see here: https://stackoverflow.com/questions/53790232/goodix-driver-not-loaded-from-arm-device
Actually exactly your model, but the vdd_arm_dummy regulator used, which is added by the 04 dtb:
[ 3.146000] DVFS: ASV[0] IDS(10mA, 7) Ro(110, 82)
[ 3.151000] ASV 0 = 1400000khz, 1200000 uV
[ 3.155000] ASV 1 = 1300000khz, 1160000 uV
[ 3.159000] ASV 2 = 1200000khz, 1120000 uV
[ 3.164000] ASV 3 = 1100000khz, 1080000 uV
[ 3.168000] ASV 4 = 1000000khz, 1080000 uV
[ 3.172000] ASV 5 = 900000khz, 1040000 uV
[ 3.177000] ASV 6 = 800000khz, 1040000 uV
[ 3.181000] ASV 7 = 700000khz, 1000000 uV
[ 3.186000] ASV 8 = 600000khz, 1000000 uV
[ 3.190000] ASV 9 = 500000khz, 960000 uV
[ 3.194000] ASV 10 = 400000khz, 960000 uV
[ 3.199000] c00bb000.dynamic-freq supply vdd_arm_dummy not found, using dummy regulator
[ 3.207000] DVFS: regulator vdd_arm_dummy
[ 3.211000] DVFS: cpu DVFS with PLL.1 [tables=11]
So generally that part should work. But the voltage per clock rate is lower compared to yours. The error message indicates differently, but in theory the lower voltage could lead to instabilities.
The other difference is this dummy sound driver and on 05 dtb instead the disabled dp_drm_lvds. Both Fire variants have no 3.5mm jack, so it seems right to disable the real sound driver, but probably it is somehow done improperly. E.g. not sure whether it is common or context here that ALSA devices are listed right belong the kernel Oops in your boot error log. Is there actually a 3.5mm ALSA device shown now, or related error in kernel log?
dmesg -l 0,1,2,3
apt install alsa-utils
aplay -l
The dp_drm_lvds seems to be an LCD panel: https://github.com/rushup/Kitra530-kernel/blob/master/Documentation/devicetree/bindings/drm/nexell/lvds_panel.txt
I cannot image that this makes a difference. So overall, I'm actually certain that the M2 dtb works on Fire 2A as well.
No error message about ALSA, dmesg just says no soundcards found.
[ 1.540000] ALSA device list:
[ 1.540000] No soundcards found.
This board (and M2) does have an LCD interface, without it disabled probably won't hurt anything.
compared to the crash log
[ 1.519000] ALSA device list:
[ 1.519000] #0: nanopi2-audio
It does look like the dummy audio interface is somehow causing problems for the old board.
Seems so. Leaving the LCD interface enabled is even better as long as there is no device tree overlay do enable it again.
So I think I'll take the risk to use the 05 dtb for 04 boards in general. If it really fails to boot on Fire 2A we can revert easily.
Image updated with the new DTB in place for M2, 2 Fire and Fire 2A. I also gave the scripts included with the firmware package some minor coding update (best practice bash coding) and added Provides+Conflicts for the libubootenv-tool package, which provides conflicting versions of fw_printenv/fw_setenv commands.