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

[Drew Fustini <drew@beagleboard.org>]

On Wed, Jan 01, 2025 at 11:46:28AM -0800, Drew Fustini wrote:
> 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

Revy just replied that I should be trying mainline OpenSBI. I have to go
offline for awhile but I will try that later today.

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