Re: [Buildroot] [PATCH v5 0/2] Add board support for the BeagleV-Ahead

[Drew Fustini <drew@beagleboard.org>]

On Wed, Jan 01, 2025 at 06:13:21PM +0100, Kilian Zinnecker via buildroot wrote:
> Hello Drew,
> 
> [--SNIP--]
>  
> > When the TH1520-based Ahead and LPi4a boards launched, there was a
> > device tree node that was parsed by OpenSBI to start up the other harts:
> > 
> [--SNIP--]
> > 
> > The node was handled by OpenSBI in lib/utils/reset/fdt_reset_thead.c.
> > The problem was that the design of this device tree node had flaws from
> > the viewpoint of the device tree maintainers. Therefore, the upstream
> > th1520.dtsi doesn't have the reset-sample node. One would need to keep a
> > downstream version of th1520.dtsi that adds that reset-sample node.
> > 
> > However, this functionality was removed last year from OpenSBI, I think
> > the change made it in the OpensBI v1.4 release:
> [--SNIP--]
> > 
> > Thus for OpenSBI v1.4+, one must have an updated U-Boot SPL build that
> > performs this reset functionality that OpenSBI used to. SPL is the early
> > portion of U-Boot that does early setup like DDR training. There is a
> > build of U-Boot SPL for the LPi4a from RevyOS that does this. However,
> > I'm not sure about the status for the Ahead so I'll have to followup on
> > that.
> 
> thanks a lot for your insights! I tried two things, but unfortunately so far I 
> wasn't successful with either:
> 
> First, I made a patch which reverts the removal of fdt_reset_thead from 
> OpenSBI and try to use that patch to bring back that functionality to OpenSBI 
> 1.6. However, turn out that down the road multiple further changes were made, 
> which would have to be reverted. E.g., some structs and possible also code 
> handling them, does not exist anymore in OpenSBI 1.6. So I think trying to 
> bring back the functionality to v1.6 is probably the last resort if nothing 
> else works. I also in general don't like this approach, because it likely will 
> break if OpenSBI is eventually updated.
> 
> Hence, my second approach was to try to use OpenSBI 1.3.1 instead: I created a 
> custom device tree containing the reset-sample not you pointed out. I then had 
> to tackle a current issue revolving using a custom device tree and Linux 
> 6.12.x in buildroot (see [1]). However, there exists a working hotfix for that 
> issue ([2]), so that is no problem at the moment. But unfortunately the 
> OpenSBI 1.3.1 seems to be a problem. Uppon booting I get the error message:
> 
> init_coldboot: timer init failed (error -3)
> 
> Seems to be an error message thrown in sbi_init.c:
> 
> https://github.com/riscv-software-src/opensbi/blob/release-1.3.x/lib/sbi/
> sbi_init.c#L342
> 
> Looking a bit deeper, it seems to come from a function 
> "sbi_platform_timer_init":
> 
> https://github.com/riscv-software-src/opensbi/blob/
> bd613dd92113f683052acfb23d9dc8ba60029e0a/include/sbi/sbi_platform.h#L581
> 
> I can't track further, as I don't know which "const struct sbi_platform *plat" 
> is used here. However, seems like others had this issue in the past as well:
> 
> https://github.com/sipeed/LicheePi4A/issues/29
> 
> Their solution seem to be to switch to OpenSBI 1.4. However, I guess, then we 
> will have the problem that the core 1-3 are not activate again? If we can't fix 
> any of those two ways, then there might be still the revyos u-boot, you 
> mentioned. Is it this one?
> 
> https://github.com/revyos/thead-u-boot
> 
> It does contain a commit indicating that it might also feature the BeagleV-
> Ahead ([3]) and also has dts files for the board. What do you think, about 
> these options? Do you know anything which could help patching OpenSBI 1.6, 
> getting OpenSBI 1.3.1 running or using the revyos u-boot?
> 
> Thanks and best regards,
> Kilian
> 
> 
> [1] https://lists.buildroot.org/pipermail/buildroot/2024-October/765463.html
> [2] https://lore.kernel.org/buildroot/
> 035d6d78-0a31-4083-8fa1-65f5be5f74b5@grenoble.cnrs.fr/
> [3] https://github.com/revyos/thead-u-boot/commit/79454e91


I think that u-boot is the ideal solution since that is the direction
that T-Head decided to go. I asked Revy on Telegram [1] and they showed
me where in thead-u-boot [2] that reset_sample() is called.

Revy pointed me to a build of u-boot-with-spl-beagle.bin [3] that I've
just flashed to my Ahead [4]. Unfortunately, there is an issue that
results in the board not booting [5]. Revy is going to look into the
issue and get back to me.

Thanks,
Drew

[1] https://t.me/linux4rv
[2] https://github.com/revyos/thead-u-boot/blob/fc9575fa63442ae87ced0b147ca1a14e30fd3d3d/arch/riscv/lib/bootm.c#L166-L173
[3] https://github.com/revyos/thead-u-boot/releases/download/20241223/u-boot-with-spl-beagle.bin
[4] https://gist.github.com/pdp7/c3b1e5aec026e92940e27169172036e1
[5] https://gist.github.com/pdp7/a76e975304e26593eb19375ce3a1e40e

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot