Trying to get samuels linux fork working on a D1 based board

[Hannes Winkler]

Hey all,

first of all I really appreciate all the work this community is doing to get allwinner hardware working with linux.

My hardware is a ClockworkPi Devterm R01: https://www.clockworkpi.com/product-page/devterm-kit-r01. The "official" linux is a 5.4 linux distro which is a slightly modified version of the official allwinner linux sources for that device: https://github.com/ardera/clockworkpi-r01-linux (linking my repo since it has the git history restored)

I'd like to boot Samuel Hollands linux fork on it, since the hardware seems to be very close to the Nezha board. So I just built his fork (`riscv/d1-wip` branch, with `nezha_defconfig`) and replaced the kernel on the official image with my custom-built kernel.

However, when booting, i get kernel panic pretty early on in the boot (see attachment).

I'm not that experienced with hw bringup so I'm a bit lost here. Is that just the kernel equivalent of a segfault? Could that mean something with the device tree is wrong? Could it be caused by an incompatible u-boot?

[Samuel Holland]

Hi Hannes,

Yes, "Unable to handle kernel paging request" is effectively a kernel segfault.

Your first guess is most likely correct, that there is an issue with the
devicetree. I see from your log that you are loading "board.dtb", which I assume
came from the Allwinner BSP kernel build[1].

If my assumption is correct, that file is useless for booting mainline Linux.
Allwinner does not attempt to be compatible with the upstream devicetree
bindings/schema, or even with earlier versions of their own BSP. As a result,
"board.dtb" will only ever work with that one specific kernel.

What you need is a devicetree that follows the official/upstream schema. Then it
would be understood by both U-Boot and mainline Linux.

In fact, your U-Boot build already contains one of those, for the Nezha board.
If you remove the fdtfile line from your extlinux.conf file, that built-in
devicetree will get passed to Linux, and the system will probably boot. However,
I do *not* recommend this, because the R01 board has many differences from the
Nezha board, and using a devicetree for the wrong board could damage your hardware.

So someone will need to go through the schematic diagrams and write a devicetree
for the R01 core board and mainboard, using the upstream schema. Now that the
R01 core board schematic has been released, I plan to do this in the next few days.

Then you would build this new devicetree into U-Boot, and it would automatically
get provided to Linux.

Regards,
Samuel

[1]:
https://github.com/ardera/clockworkpi-r01-linux/blob/master/arch/riscv/boot/dts/sunxi/board.dts

[Hannes Winkler]

Hey Samuel,

thanks for the quick reply.

Actually, I did replace the board.dtb with the `sun20i-d1-nezha.dtb` generated by your kernel build, so that should be fine, but yeah if the nezha dtb won't work on R01 anyway then that's probably why it didn't work

Though I just found some the nezha board dts somewhere: https://github.com/YuzukiHD/Buildroot-YuzukiSBC/blob/master/buildroot/board/awol/nezha-d1s/dts/linux/sun20i-d1s-nezha-linux.dts

So I could just diff it to the board.dts of the allwinner r01 linux and roughly see what I need to change in your mainline forks' device tree right?

> Now that the
R01 core board schematic has been released, I plan to do this in the next few days.

Thanks, appreciate your work!

Best regards,
Hannes

[Samuel Holland]

Hi Hannes,

On 7/9/22 2:45 PM, Hannes Winkler wrote:
> Actually, I did replace the board.dtb with the `sun20i-d1-nezha.dtb` generated
> by your kernel build, so that should be fine, but yeah if the nezha dtb won't
> work on R01 anyway then that's probably why it didn't work

Ah, if you use a DTB from the kernel build, there is a different reason why it
would not work. Some information in the devicetree, such as the RAM size, is
automatically detected at runtime. That information is patched into the
devicetree by the firmware (SPL, OpenSBI, U-Boot) to tell Linux about it.

But that patching only happens to the devicetree that is built in to the
firmware package. If you load a DTB from extlinux.conf, it will not be patched,
and Linux will think the board has zero RAM. That causes the crash.

> Though I just found some the nezha board dts
> somewhere: https://github.com/YuzukiHD/Buildroot-YuzukiSBC/blob/master/buildroot/board/awol/nezha-d1s/dts/linux/sun20i-d1s-nezha-linux.dts
>
> So I could just diff it to the board.dts of the allwinner r01 linux and roughly
> see what I need to change in your mainline forks' device tree right?

You could, assuming both downstream devicetrees were complete and accurate to
start with. It would still be more work than using the schematic.

>> Now that the R01 core board schematic has been released, I plan to do this in the next few days.
>
> Thanks, appreciate your work!

Thank you!

Regards,
Samuel