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

From: Simon Glass <sjg@chromium.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/3] rockchip: use 'arch-rockchip' as header file path【请注意，邮件由sjg@google.com代发】
Date: Thu, 4 Apr 2019 20:33:46 -0600	[thread overview]
Message-ID: <CAPnjgZ3rAx=xuhyKb-c18KTK5ceg_KBJVnbKTyGx3trhO1U3Yw@mail.gmail.com> (raw)
In-Reply-To: <90b37950-31d5-c7c5-d4c4-ac4b79f0a6e2@rock-chips.com>

Hi Kever,

On Mon, 1 Apr 2019 at 19:11, Kever Yang <kever.yang@rock-chips.com> wrote:
>
>
>
> On 04/02/2019 03:00 AM, Simon Glass wrote:
> > Hi Kever,
> >
> > On Sun, 31 Mar 2019 at 20:46, Kever Yang <kever.yang@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@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@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.
>
> multiple SoCs + multiple boards, I know it sounds very good and we may able
> to implement it, but it would be a long time. Kernel already do this,
> but we have
> to know that it leaves all the one time program init job to U-Boot like
> loader and
> load/fix a correct dtb for it.
>
> Can we have more common codes first, my patches for common 'board/spl/tpl'
> has pending for more than one year, and I split it into pieces and hope
> to get
> some of then merged in next merge window.
>
> I know there may be change request needed, so I really want to get
> patches review
> and response a little faster so that I can update a new version.
>
> Well, this patch get reviewed pretty fast, but others seems no one sees
> them.

OK hopefully these can all be applied soon, perhaps in a -next branch.

Regards,
Simon