[U-Boot] [PATCH 2/3] rockchip: use 'arch-rockchip' as header file path【请注意，邮件由sjg at google.com代发】
kever.yang at rock-chips.com
Tue Apr 2 01:11:31 UTC 2019
On 04/02/2019 03:00 AM, Simon Glass wrote:
> 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
>> 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
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
some of then merged in next merge window.
I know there may be change request needed, so I really want to get
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
>> 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
>> 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.
More information about the U-Boot