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

[Michal Simek]

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?

System can have 0, 1 or 2 uarts or uart on any other IP in PL.

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/20150903/f390e91e/attachment.sig>