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

Simon Glass sjg at chromium.org
Wed Sep 2 04:49:02 CEST 2015


+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?

If we go this way, who is going to write the patch??

Regards,
Simon


More information about the U-Boot mailing list