[U-Boot] [PATCH 11/13] arm: zynq: dts: Add U-Boot device tree additions

[Michal Simek]

On 09/04/2015 02:22 AM, Simon Glass wrote:
> Hi Michal,
> 
> On 3 September 2015 at 05:35, Michal Simek <monstr at monstr.eu> 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
>>> <yamada.masahiro at socionext.com> wrote:
>>>> Hi.
>>>>
>>>>
>>>> 2015-09-02 0:41 GMT+09:00 Michal Simek <monstr at monstr.eu>:
>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> 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 at XXX {
    };
    uart1: uart at 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150904/29548541/attachment.sig>