Hi Kever,
On Thu, 4 Apr 2019 at 07:11, Kever Yang kever.yang@rock-chips.com wrote:
Hi Simon,
On 04/04/2019 03:57 AM, Simon Glass wrote:
Hi Kever,
On Sat, 30 Mar 2019 at 15:18, Simon Glass sjg@chromium.org 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?
OK I figured it out from the context.
Do you have interest in supporting multiple SoCs with a single build?
Is there other vendor support multiple SoCs? For Rockchip platform, I don't think it's easy to do it now, the different for different SoCs now:
- SoC init, eg. debug uart init, sgrf setting and other one time init
setting;
- clock driver;
- pinctrl driver, David still working on it, but the target is for
minimum size for each SoC, but not enable common code in pinctrl-core as much as possible, so this is the opposite way with support multiple SoCs support.
I would like to use common board/spl/tpl files first, and then step to step to see what we need to do.
OK. We can today support multiple clock and pinctrl drivers. Minimising code size is a separate issue to actually making it work.
For SoC init we can use compatible strings to select the init - as you say, moving to common SPL/TPL is a useful step, but in fact this is not necessary for use to use a common U-Boot proper. I believe the main requirement is to create a new config with additional drivers, then make SPL select the correct DT.
But my concern is that your series to move things to #include asm/arch precludes supporting more than one SoC. So if we want this, we should leave things as they are.
If you like I could create a proof of concept for this for two chosen SoCs?
Regards, Simon