[PATCH 1/2] spl: Introduce architecture specific init function
Lukas Funke
lukas.funke-oss at weidmueller.com
Thu Mar 21 08:54:54 CET 2024
On 20.03.2024 16:49, Andre Przywara wrote:
> On Wed, 20 Mar 2024 11:33:16 -0400
> Tom Rini <trini at konsulko.com> wrote:
>
> Hi,
>
>> On Wed, Mar 20, 2024 at 08:52:30PM +0530, Devarsh Thakkar wrote:
>>> Hi Tom, Lukas,
>>>
>>> Thanks for the patch Lukas.
>>>
>>> On 20/03/24 20:00, Tom Rini wrote:
>>>> On Wed, Mar 20, 2024 at 02:19:26PM +0100, lukas.funke-oss at weidmueller.com wrote:
>>>>
>>>>> From: Lukas Funke <lukas.funke at weidmueller.com>
>>>>>
>>>>> Some architectures use spl_board_init() in their architecture specific
>>>>> implementation. Board developers should be able to add board specific
>>>>> implementation via spl_board_init(). Hence, introduce a spl_arch_init()
>>>>> method which is called right before spl_board_init() for architecture
>>>>> specific implementation.
>>>>>
>>>>> Signed-off-by: Lukas Funke <lukas.funke at weidmueller.com>
>>>>
>>>> I think this could allow for other SoCs to clean up their existing
>>>
>>> Does it make more sense to make this SoC specific then instead of arch
>>> specific to allow broader range of code?
>>
>> "soc" and "arch" are somewhat interchangeable at times, so I think we
>
> Isn't "arch" ambiguous anyway? I connect that with CPU architecture, as in
> x86, ARM, RISC-V. And we have that in the top level directories: arch/arm,
> etc.
> But here it's one level below, isn't it? Where "platform" (or "plat")
> would be a more suiting term to describe a SoC family, like xilinx or
> sunxi?
> So the hierarchy would be really: arch -> plat -> soc -> board?
>
> Or am I confused here?
No. But in some cases the 'platform' level is missing: for xilinx it's
"arch->arm->mach-zynq-><impl>", for rockchip it's
"arch->arm->plat->soc", i.e. "arch->arm->mach-rockchip->rk3399-><impl>".
If we follow your proposed rule it should be:
arch->arm->mach-xilinx->zynq-><impl>. Maybe this is an idea for the next
cleanup round?
Regarding the patch:
I'd agree that the init code is not (cpu)architecture dependent. Some
vendors init the console, some init the ddr, some init the leds and so
on. Thus, we should go one level upwards and change it to
"spl_soc_init()" if everyone is okay with it?
Best regards,
Lukas
>
> Cheers,
> Andre
>
>
>> can go one step at a time here and bring in this abstraction and see
>> where everyone else is able to clean their code up to.
>>
>
More information about the U-Boot
mailing list