On 09/04/2015 02:22 AM, Simon Glass wrote: > Hi Michal, > > On 3 September 2015 at 05:35, Michal Simek <[email protected]> wrote: >> On 09/02/2015 04:49 AM, Simon Glass wrote: >>> +Tom and a few others who may have an opinion. >>> >>> Hi, >>> >>> On 1 September 2015 at 10:19, Masahiro Yamada >>> <[email protected]> wrote: >>>> Hi. >>>> >>>> >>>> 2015-09-02 0:41 GMT+09:00 Michal Simek <[email protected]>: >>>> >>>>>>> >>>>>>>> >>>>>>>>> Why not just add one more uboot property to chosen with list of IPs >>>>>>>>> which needs to be relocated? >>>>>>>> >>>>>>>> You mean a list of devices needed before relocation? >>>>>>> >>>>>>> I mean something like this: >>>>>>> >>>>>>> chosen { >>>>>>> u-boot,dm-pre-reloc = <&uart1 ...>; >>>>>>> } >>>>>>> >>>>>>> And then just go through this list. I expect that you are looking for >>>>>>> that property anyway. >>>>>> >>>>>> In this case wouldn't it need to list the simple-bus also? >>>>> >>>>> yes for zc702 case >>>>> >>>>> u-boot,dm-pre-reloc = <&amba &uart1>; >>>> >>>> I think this should be >>>> >>>> u-boot,dm-pre-reloc = &amba, &uart1; >>>> >>>> >>>> <&label> is used for phandle, while &label is replaced with a string >>>> standing for the full path for the node. >>>> >>>> >>>> For example, stdout-path takes that: >>>> >>>> >>>> stdout-path = &serial0; >>>> >>>> >>>> >>>> >>>> >>>>> >>>>>> >>>>>> We also use this with fdtgrep to remove nodes not needed for SPL. So >>>>>> we would have to come up with a tool to make that work. At present >>>>>> 'fdtgrep -p u-boot,dm-pre-reloc' picks out all the nodes we want (it >>>>>> finds nodes with that property). >>>>>> >>>>>> I'm actually not sure that this approach is any easier/better. What >>>>>> are the advantages? >>>>> >>>>> The question is if current solution which you are using is fully >>>>> compatible with binding. Adding bootloader property to the HW node >>>>> doesn't look like a best solution. >>>>> On the other hand chosen node is the location where OS specific >>>>> properties are coming that's why I have suggested to use it. >>>> >>>> >>>> I like Michal's idea. >>>> We need some work for fdtgrep, but I believe it is worthwhile. >>>> >>>> From Michal's recent patches (http://patchwork.ozlabs.org/patch/498609/), >>>> I guess he is tackling on syncing device trees between Linux and U-boot, >>>> and this is right thing to do. >>>> >>>> Inserting the U-boot specific property here and there >>>> makes it difficult. >>> >>> Yes it is attractive. >>> >>> With this scheme we cannot put the properties into .dtsi (i.e. make >>> them common for the soc). Is there a way around that or would we just >>> have to live with it? >> >> Why not? You can add chosen node to dtsi without any problem which >> should be shared for all boards. The only one question remains which is >> what exactly you need to add to dtsi. >> One example is Zynq. We have 2 serial PS IPs. Which one you want to add? >> Both? > > If you have something like this: > > soc { > uart0 { > }; > uart1 { > }; > } > > in the common .dtsi then you can currently put the marker in the soc > node. I'm not sure how you do that with your scheme. If we put it in > the .dtsi then the .dts will override it. > > Does this matter?
As far as I understand DTSI is shared across all boards.
And DTS can overwrite DTSI at any time.
Let me extend this to make it more clear
soc: soc {
uart0: uart@XXX {
};
uart1: uart@XXX {
};
}
In DTSI I would put probably this to show everybody what needs to be there.
chosen {
u-boot,dm-pre-reloc = &soc &uart0 &uart1;
}
And in DTS if you have only one uart DTS will overwrite it.
chosen {
u-boot,dm-pre-reloc = &soc &uart0;
}
Or the next option is to make code smarter and detect that uart1 is
disabled that's why it is not used and only chosen from DTSI should be
enough.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
