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

Kever Yang kever.yang at rock-chips.com
Mon Apr 1 02:46:24 UTC 2019


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.

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.

Thinks,
- Kever
> although in practice we don't use that ability.
> So I don't think it is a big problem to drop it.
>
> Regards,
> Simon
>





More information about the U-Boot mailing list