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?
- 'rockchip' is not SOC name but vendor name, we'd better use correct name;
- 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