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?
- '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.
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.
Thanks, - Kever
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