Hi Kever, On Sun, 31 Mar 2019 at 20:46, Kever Yang <kever.y...@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.y...@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.y...@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.
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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
