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

[Drew Fustini <drew@beagleboard.org>]

[resending from an address that is subscribed to the buidroot list]

On Mon, Dec 30, 2024 at 11:53:43PM +0100, Kilian Zinnecker via buildroot wrote:
> Hello all,
> 
> please feel free to give feedback once more if you like, but please don't 
> apply this series of the patches yet, since there are still some open issues:
> 
> 1) Still there is no LICENSE file in the xuantie-bins repository - hopefully I 
> can get someone to add the proper license eventually.
> 
> 2) The uboot is still the custom one. In the past I was not able to get the 
> official uboot running, which features the Lichee Pi 4A - another board with the 
> same SoC. I don't know, whether I can get it running though. So far I was not 
> successfull.
> 
> 3) Currently it seems that only one of the SoC's 4 cores gets activated. I see 
> the following in my bootlog:
> 
> [    0.111209] smp: Bringing up secondary CPUs ...
> [    1.132870] CPU1: failed to come online
> [    2.161923] CPU2: failed to come online
> [    3.190788] CPU3: failed to come online
> [    3.194847] smp: Brought up 1 node, 1 CPU
> 
> I didn't look into it yet. If anyone has a suggestion, what could be going 
> wrong, please tell me.

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:

https://openbeagle.org/beaglev-ahead/beaglev-ahead-linux/-/blob/beaglev-v5.10.113-1.1.2/arch/riscv/boot/dts/thead/light.dtsi#L380

                reset: reset-sample {
                        compatible = "thead,reset-sample";
                        plic-delegate = <0xff 0xd81ffffc>;
                        entry-reg = <0xff 0xff019050>;
                        entry-cnt = <4>;
                        control-reg = <0xff 0xff015004>;
                        control-val = <0x1c>;
                        csr-copy = <0x7f3 0x7c0 0x7c1 0x7c2 0x7c3 0x7c5 0x7cc>;
                };

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:

https://github.com/riscv-software-src/opensbi/commit/d1e0f7f25b2f1527425942dfc327f1d4a61bbff4

> In the past, we used fdt_reset_thead to help customers with prototype
> verification. However, with the emergence of the Big-little SoC system,
> it can no longer meet the demand. Therefore, we use zero_stage_boot
> instead of fdt_reset_thead. It cleans up the opensbi code and ends the
> disputation of reset_sample's dts.

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.

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