[U-Boot] [PATCH 2/3] rockchip: use 'arch-rockchip' as header file path【请注意，邮件由sjg at google.com代发】

[Simon Glass]

Hi Kever,

On Sun, 31 Mar 2019 at 20:46, Kever Yang <kever.yang at rock-chips.com> wrote:
>
> Hi Simon,
>
>
> On 04/01/2019 10:00 AM, Simon Glass wrote:
> > Hi Kever,
> >
> > On Sun, 31 Mar 2019 at 19:03, Kever Yang <kever.yang at rock-chips.com> wrote:
> >> Hi Simon,
> >>
> >>
> >> On 03/31/2019 05:18 AM, Simon Glass wrote:
> >>> Hi Kever,
> >>>
> >>> On Wed, 27 Mar 2019 at 21:01, Kever Yang <kever.yang at rock-chips.com> wrote:
> >>>> Rockchip use 'arch-rockchip' instead of arch-$(SOC) as common
> >>>> header file path, so that we can get the correct path directly.
> >>> Can you give a few more details on the reason for this change? I
> >>> cannot see the benefit?
> >> 1. 'rockchip' is not SOC name but vendor name, we'd better use correct name;
> >> 2. the build system will include $(SOC)-u-boot.dtsi automatically
> >> without modify
> >>     $(SOC).dtsi or $(board).dtsi, if the $(SOC) default to 'rockchip',
> >> we can't use
> >>     this feature.
> > OK I see.
> >
> > So far Rockchip has been designed so that a single U-Boot (proper) can
> > support multiple SoCs,
>
> I don't understand, how can a single U-Boot(proper) support multiple
> Rockchip SoCs,
> it sounds awesome which is kernel like. But I thought we need different
> build
> with different source for different SoCs now.

It should be possible simply by enabling multiple SoCs, so long as you
don't try to use both 32/64-bit ones.

I suspect some extra work is needed, but probably not much.

>
> For $(SOC)-u-boot.dtsi, another way is using $(BOARD)-u-boot.dtsi, but I
> think in
> most case, we can have one $(SOC)-u-boot.dtsi instead of many
> $(BOARD)-u-boot.dtsi
> for one SoC, so we need this feature.

Well we can add multiple device-tree files. Each board has its own.
Then at runtime (in SPL) we select the correct one.

Regards,
Simon