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

[Simon Glass]

Hi Michal,

On 18 September 2015 at 19:07, Michal Simek  wrote:
> Hi Simon,
>
> first of all sorry for late reply. I am traveling and I have pretty busy
> time now.

That's OK, I don't think there is any particular hurry.

>
> 2015-09-09 20:07 GMT+02:00 Simon Glass :
>>
>> Hi Michal,
>>
>> On Friday, 4 September 2015, Michal Simek  wrote:
>> >
>> > Hi Simon,
>> >
>> > 
>> >
>> > 
>> >  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 =   
>> > >> }
>> > >>
>> > >> And in DTS if you have only one uart DTS will overwrite it.
>> > >> chosen {
>> > >> u-boot,dm-pre-reloc =  
>> > >> }
>> > >>
>> > >> 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.
>> > >
>> > > Yes I see - you just overwrite the property in the main file. If it
>> > > includes pinctrl nodes, gpio nodes, etc. then you would have to add
>> > > those also.
>> >
>> > Right - DTSI is most like a pattern to follow and DTS is doing that
>> > platform specific stuff. It means in DTSI you can have guidance what to
>> > use.
>>
>>
>> Do you mean we should add a comment to the .dtsi to tell you want you
>> need in your .dts? Is this improving anything?
>
>
> what I think it will be the best to add that line to DTSI with all IPs which
> should be pre relocated.
> Then algorithm should be like this
>
> for_each_IP_in_property {
> if (status=ok)
>   relocate
> else
> ignore it
> }
>
> If you have others nodes in DTS then you have to rewrite it.

Normally the .dts file will specify the UART which means that it will
often need rewriting with this scheme.

The potential for stuff-ups and confusion is there. With the current
scheme at least marking can be kept as a property of the device (where
arguably it belongs) rather than having to be recreated for each
board.

Perhaps we could allow multiple properties in /chosen and scan them
all (u-boot,dm-pre-reloc-soc, u-boot,dm-pre-reloc-pinctrl, etc.)?

>
>
>>
>>
>> >
>> > Also in algorithm can be checking if that IP has status okay or disabled
>> > and do relocation or not.
>>
>>
>> Can you please 

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

[Tom Rini]

On Sat, Sep 19, 2015 at 03:07:54AM +0200, Michal Simek wrote:
> Hi Simon,
> 
> first of all sorry for late reply. I am traveling and I have pretty busy
> time now.
> 
> 2015-09-09 20:07 GMT+02:00 Simon Glass :
[snip]
> > There are Linux-specific properties, so I really don't see the
> > difference. Don't forget that we are using device tree to control our
> > boot loader, so it would be unusual to not see at least some
> > U-Boot-specific properties.
> >
> > My understanding of /chosen is that it is for the OS. But in any case
> > it would still be a binding change, wouldn't it? What makes you think
> > that this scheme would be more acceptable as a binding change?
> >
> 
> I think we should move this discussion to device-tree mailing list.
> I simple just don't think that OS/bootloader property in the device node is
> a good idea.
> Maybe there is better solution but i think adding OS/Bootloader to chosen
> is just better option
> then added this to every node.
> Not sure if sequence matter or not but via one property you can also
> control it.

I think that with ELC-E coming up and that once again there will be a DT
BoF, we (the U-Boot community) need to show up there and in turn see
how many folks we can also get to show up in our mini-summit.  I've
already bugged Pantelis about this a few times.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Michal Simek]

Hi Simon,

first of all sorry for late reply. I am traveling and I have pretty busy
time now.

2015-09-09 20:07 GMT+02:00 Simon Glass :

> Hi Michal,
>
> On Friday, 4 September 2015, Michal Simek  wrote:
> >
> > Hi Simon,
> >
> > 
> >
> > 
> >  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 =   
> > >> }
> > >>
> > >> And in DTS if you have only one uart DTS will overwrite it.
> > >> chosen {
> > >> u-boot,dm-pre-reloc =  
> > >> }
> > >>
> > >> 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.
> > >
> > > Yes I see - you just overwrite the property in the main file. If it
> > > includes pinctrl nodes, gpio nodes, etc. then you would have to add
> > > those also.
> >
> > Right - DTSI is most like a pattern to follow and DTS is doing that
> > platform specific stuff. It means in DTSI you can have guidance what to
> > use.
>
>
> Do you mean we should add a comment to the .dtsi to tell you want you
> need in your .dts? Is this improving anything?
>

what I think it will be the best to add that line to DTSI with all IPs
which should be pre relocated.
Then algorithm should be like this

for_each_IP_in_property {
if (status=ok)
  relocate
else
ignore it
}

If you have others nodes in DTS then you have to rewrite it.



>
> >
> > Also in algorithm can be checking if that IP has status okay or disabled
> > and do relocation or not.
>
>
> Can you please rephrase that? I don't understand.
> >
> >
> > > For mainline Rockchip this means that each board would
> > > have to have something like:
> > >
> > >  chosen {
> > >  u-boot,dm-pre-reloc = , , , , 
> > >  _work _power;
> > >  }
> > >
> > > That seems a bit unwieldy to me. What do you think?
> >
> > (note: without commas)
> > I think that this solution is compatible with the binding and it is
> > better than adding bootloader specific property to nodes which I have
> > never seen before. Chosen node was used for that maybe even from
> beginning.
>
>
> There are Linux-specific properties, so I really don't see the
> difference. Don't forget that we are using device tree to control our
> boot loader, so it would be unusual to not see at least some
> U-Boot-specific properties.
>
> My understanding of /chosen is that it is for the OS. But in any case
> it 

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

[Simon Glass]

Hi Michal,

On Friday, 4 September 2015, Michal Simek  wrote:
>
> Hi Simon,
>
> 
>
> 
>  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 =   
> >> }
> >>
> >> And in DTS if you have only one uart DTS will overwrite it.
> >> chosen {
> >> u-boot,dm-pre-reloc =  
> >> }
> >>
> >> 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.
> >
> > Yes I see - you just overwrite the property in the main file. If it
> > includes pinctrl nodes, gpio nodes, etc. then you would have to add
> > those also.
>
> Right - DTSI is most like a pattern to follow and DTS is doing that
> platform specific stuff. It means in DTSI you can have guidance what to
> use.


Do you mean we should add a comment to the .dtsi to tell you want you
need in your .dts? Is this improving anything?

>
> Also in algorithm can be checking if that IP has status okay or disabled
> and do relocation or not.


Can you please rephrase that? I don't understand.
>
>
> > For mainline Rockchip this means that each board would
> > have to have something like:
> >
> >  chosen {
> >  u-boot,dm-pre-reloc = , , , , 
> >  _work _power;
> >  }
> >
> > That seems a bit unwieldy to me. What do you think?
>
> (note: without commas)
> I think that this solution is compatible with the binding and it is
> better than adding bootloader specific property to nodes which I have
> never seen before. Chosen node was used for that maybe even from beginning.


There are Linux-specific properties, so I really don't see the
difference. Don't forget that we are using device tree to control our
boot loader, so it would be unusual to not see at least some
U-Boot-specific properties.

My understanding of /chosen is that it is for the OS. But in any case
it would still be a binding change, wouldn't it? What makes you think
that this scheme would be more acceptable as a binding change?
>
>
> Regarding technical aspects - I have never checked if there is any line
> length limitation on parameter side which can be problematic. On the
> other hand if yes phandles should be used.


No there is not limit I know of. It should be fine.
>
>
> Regarding compactness of this solution. From one line you can see what
> will be pre relocated which looks pretty compact to me and you can easy
> check if something is missing.


Yes it is nice to have this in once place. But it's not really in one
place as you need to reference nodes from elsewhere, 

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

[Simon Glass]

Hi Michal,

On 4 September 2015 at 00:04, Michal Simek  wrote:
> On 09/04/2015 02:22 AM, Simon Glass wrote:
>> Hi Michal,
>>
>> On 3 September 2015 at 05:35, Michal Simek  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
  wrote:
> Hi.
>
>
> 2015-09-02 0:41 GMT+09:00 Michal Simek :
>

>
>> 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 = < ...>;
 }

 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 = < >;
>
> I think this should be
>
> u-boot,dm-pre-reloc = , 
>
>
> <> is used for phandle, while  is replaced with a string
> standing for the full path for the node.
>
>
> For example, stdout-path takes that:
>
>
> stdout-path = 
>
>
>
>
>
>>
>>>
>>> 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 =   
> }
>
> And in DTS if you have only one uart DTS will overwrite it.
> chosen {
> u-boot,dm-pre-reloc =  
> }
>
> 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.

Yes I see - you just overwrite the property in the main file. If it
includes pinctrl nodes, gpio nodes, etc. then you would have to add
those also. For mainline Rockchip this means that each board would
have to have something like:

 chosen {
 u-boot,dm-pre-reloc = , , , , 
 _work _power;
 }

That seems a bit unwieldy to me. What do you think?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Michal Simek]

Hi Simon,




 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 =   
>> }
>>
>> And in DTS if you have only one uart DTS will overwrite it.
>> chosen {
>> u-boot,dm-pre-reloc =  
>> }
>>
>> 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.
> 
> Yes I see - you just overwrite the property in the main file. If it
> includes pinctrl nodes, gpio nodes, etc. then you would have to add
> those also. 

Right - DTSI is most like a pattern to follow and DTS is doing that
platform specific stuff. It means in DTSI you can have guidance what to
use.
Also in algorithm can be checking if that IP has status okay or disabled
and do relocation or not.

> For mainline Rockchip this means that each board would
> have to have something like:
> 
>  chosen {
>  u-boot,dm-pre-reloc = , , , , 
>  _work _power;
>  }
> 
> That seems a bit unwieldy to me. What do you think?

(note: without commas)
I think that this solution is compatible with the binding and it is
better than adding bootloader specific property to nodes which I have
never seen before. Chosen node was used for that maybe even from beginning.

Regarding technical aspects - I have never checked if there is any line
length limitation on parameter side which can be problematic. On the
other hand if yes phandles should be used.

Regarding compactness of this solution. From one line you can see what
will be pre relocated which looks pretty compact to me and you can easy
check if something is missing.

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
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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  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
>>>  wrote:
 Hi.


 2015-09-02 0:41 GMT+09:00 Michal Simek :

>>>

> 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 = < ...>;
>>> }
>>>
>>> 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 = < >;

 I think this should be

 u-boot,dm-pre-reloc = , 


 <> is used for phandle, while  is replaced with a string
 standing for the full path for the node.


 For example, stdout-path takes that:


 stdout-path = 





>
>>
>> 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 =   
}

And in DTS if you have only one uart DTS will overwrite it.
chosen {
u-boot,dm-pre-reloc =  
}

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
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [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
>  wrote:
>> Hi.
>>
>>
>> 2015-09-02 0:41 GMT+09:00 Michal Simek :
>>
>
>>
>>> 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 = < ...>;
> }
>
> 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 = < >;
>>
>> I think this should be
>>
>> u-boot,dm-pre-reloc = , 
>>
>>
>> <> is used for phandle, while  is replaced with a string
>> standing for the full path for the node.
>>
>>
>> For example, stdout-path takes that:
>>
>>
>> stdout-path = 
>>
>>
>>
>>
>>
>>>

 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




signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Simon Glass]

Hi Michal,

On 3 September 2015 at 05:35, Michal Simek  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
>>  wrote:
>>> Hi.
>>>
>>>
>>> 2015-09-02 0:41 GMT+09:00 Michal Simek :
>>>
>>
>>>
 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 = < ...>;
>> }
>>
>> 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 = < >;
>>>
>>> I think this should be
>>>
>>> u-boot,dm-pre-reloc = , 
>>>
>>>
>>> <> is used for phandle, while  is replaced with a string
>>> standing for the full path for the node.
>>>
>>>
>>> For example, stdout-path takes that:
>>>
>>>
>>> stdout-path = 
>>>
>>>
>>>
>>>
>>>

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

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

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Simon Glass]

+Tom and a few others who may have an opinion.

Hi,

On 1 September 2015 at 10:19, Masahiro Yamada
 wrote:
> Hi.
>
>
> 2015-09-02 0:41 GMT+09:00 Michal Simek :
>

>
>> 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 = < ...>;
 }

 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 = < >;
>
> I think this should be
>
> u-boot,dm-pre-reloc = , 
>
>
> <> is used for phandle, while  is replaced with a string
> standing for the full path for the node.
>
>
> For example, stdout-path takes that:
>
>
> stdout-path = 
>
>
>
>
>
>>
>>>
>>> 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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Masahiro Yamada]

Hi.


2015-09-02 0:41 GMT+09:00 Michal Simek :

>>>

> 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 = < ...>;
>>> }
>>>
>>> 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 = < >;

I think this should be

u-boot,dm-pre-reloc = , 


<> is used for phandle, while  is replaced with a string
standing for the full path for the node.


For example, stdout-path takes that:


stdout-path = 





>
>>
>> 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.




-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Michal Simek]

On 08/29/2015 05:10 PM, Simon Glass wrote:
> We need to mark some device tree nodes so that they are available before
> relocation. This enables driver model to find these automatically. In the
> case of SPL it ensures that these nodes will be retained in SPL.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  arch/arm/dts/zynq-7000.dtsi   | 1 +
>  arch/arm/dts/zynq-microzed.dts| 5 +
>  arch/arm/dts/zynq-picozed.dts | 5 +
>  arch/arm/dts/zynq-zc702.dts   | 1 +
>  arch/arm/dts/zynq-zc706.dts   | 1 +
>  arch/arm/dts/zynq-zc770-xm010.dts | 1 +
>  arch/arm/dts/zynq-zc770-xm011.dts | 1 +
>  arch/arm/dts/zynq-zc770-xm012.dts | 1 +
>  arch/arm/dts/zynq-zc770-xm013.dts | 1 +
>  arch/arm/dts/zynq-zed.dts | 1 +
>  arch/arm/dts/zynq-zybo.dts| 1 +
>  11 files changed, 19 insertions(+)
> 
> diff --git a/arch/arm/dts/zynq-7000.dtsi b/arch/arm/dts/zynq-7000.dtsi
> index 0b62cb0..12614f2 100644
> --- a/arch/arm/dts/zynq-7000.dtsi
> +++ b/arch/arm/dts/zynq-7000.dtsi
> @@ -54,6 +54,7 @@
>   };
>  
>   amba: amba {
> + u-boot,dm-pre-reloc;

One more point here IRC the first line in every node should be
compatible string not any property that's why this should be move below.

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
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Michal Simek]

On 09/01/2015 01:13 AM, Simon Glass wrote:
> Hi Michal,
> 
> On 31 August 2015 at 08:16, Michal Simek  wrote:
>> On 08/31/2015 03:54 PM, Simon Glass wrote:
>>> Hi Michal,
>>>
>>> On 31 August 2015 at 05:30, Michal Simek  wrote:
 On 08/29/2015 05:10 PM, Simon Glass wrote:
> We need to mark some device tree nodes so that they are available before
> relocation. This enables driver model to find these automatically. In the
> case of SPL it ensures that these nodes will be retained in SPL.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/arm/dts/zynq-7000.dtsi   | 1 +
>  arch/arm/dts/zynq-microzed.dts| 5 +
>  arch/arm/dts/zynq-picozed.dts | 5 +
>  arch/arm/dts/zynq-zc702.dts   | 1 +
>  arch/arm/dts/zynq-zc706.dts   | 1 +
>  arch/arm/dts/zynq-zc770-xm010.dts | 1 +
>  arch/arm/dts/zynq-zc770-xm011.dts | 1 +
>  arch/arm/dts/zynq-zc770-xm012.dts | 1 +
>  arch/arm/dts/zynq-zc770-xm013.dts | 1 +
>  arch/arm/dts/zynq-zed.dts | 1 +
>  arch/arm/dts/zynq-zybo.dts| 1 +
>  11 files changed, 19 insertions(+)
>
> diff --git a/arch/arm/dts/zynq-7000.dtsi b/arch/arm/dts/zynq-7000.dtsi
> index 0b62cb0..12614f2 100644
> --- a/arch/arm/dts/zynq-7000.dtsi
> +++ b/arch/arm/dts/zynq-7000.dtsi
> @@ -54,6 +54,7 @@
>   };
>
>   amba: amba {
> + u-boot,dm-pre-reloc;
>   compatible = "simple-bus";
>   #address-cells = <1>;
>   #size-cells = <1>;
> diff --git a/arch/arm/dts/zynq-microzed.dts 
> b/arch/arm/dts/zynq-microzed.dts
> index c373a2c..5dff18e6 100644
> --- a/arch/arm/dts/zynq-microzed.dts
> +++ b/arch/arm/dts/zynq-microzed.dts
> @@ -21,3 +21,8 @@
>   reg = <0 0x4000>;
>   };
>  };
> +
> + {
> + u-boot,dm-pre-reloc;

 Was this reviewed on DT mailing list?
>>>
>>> There is a thread going at present for Raspberry Pi but it had not
>>> yielded much light last time I looked.
>>>

 TBH adding this to every node seems to me a lot of work.
>>>
>>> This i how it works at present. Typically we only have a UART and that
>>> is not necessary since U-Boot can force-bind this. But when the UART
>>> is not in the root node we have to add something.
>>
>> It is partially problem with DT mess that we have platforms with and
>> without bus. :-)
>>
>>>
 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 = < ...>;
>> }
>>
>> 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 = < >;


> 
> 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.

>>
>>
>>> If you like you could look at working up a patch for this. I'm
>>> certainly interested in other ideas. It does need to be efficient.
>>
>> I will test this series and will look at it in more details soon.
> 
> Thanks.
> 
> BTW are there zynqmp dev boards available at reasonable cost? I did
> this Zynq series because I discovered some old patches that were not
> applied and decided to update then. It's a really interesting platform
> - FPGA, etc.

Not now. But you can use qemu platform. I will look at it to see what
there is. But I have confirmation that you should be able to run u-boot
there.

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
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Masahiro Yamada]

Simon,


2015-08-31 22:54 GMT+09:00 Simon Glass :
>>
>>
>> Any idea to propagate 'pre_reloc_only' downwards?
>
> Checking the GD_FLG_RELOC is the only thing I can think of. We don't
> want to add parameter to the bind() method I think.

Sounds good to me.
Are you willing to do this?



For now, I am planing to increase CONFIG_SYS_MALLOC_F_LEN
to work around the "All or Nothing" logic of the simple-bus binding.

http://patchwork.ozlabs.org/patch/512847/




-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Simon Glass]

Hi Michal,

On 31 August 2015 at 08:16, Michal Simek  wrote:
> On 08/31/2015 03:54 PM, Simon Glass wrote:
>> Hi Michal,
>>
>> On 31 August 2015 at 05:30, Michal Simek  wrote:
>>> On 08/29/2015 05:10 PM, Simon Glass wrote:
 We need to mark some device tree nodes so that they are available before
 relocation. This enables driver model to find these automatically. In the
 case of SPL it ensures that these nodes will be retained in SPL.

 Signed-off-by: Simon Glass 
 ---

  arch/arm/dts/zynq-7000.dtsi   | 1 +
  arch/arm/dts/zynq-microzed.dts| 5 +
  arch/arm/dts/zynq-picozed.dts | 5 +
  arch/arm/dts/zynq-zc702.dts   | 1 +
  arch/arm/dts/zynq-zc706.dts   | 1 +
  arch/arm/dts/zynq-zc770-xm010.dts | 1 +
  arch/arm/dts/zynq-zc770-xm011.dts | 1 +
  arch/arm/dts/zynq-zc770-xm012.dts | 1 +
  arch/arm/dts/zynq-zc770-xm013.dts | 1 +
  arch/arm/dts/zynq-zed.dts | 1 +
  arch/arm/dts/zynq-zybo.dts| 1 +
  11 files changed, 19 insertions(+)

 diff --git a/arch/arm/dts/zynq-7000.dtsi b/arch/arm/dts/zynq-7000.dtsi
 index 0b62cb0..12614f2 100644
 --- a/arch/arm/dts/zynq-7000.dtsi
 +++ b/arch/arm/dts/zynq-7000.dtsi
 @@ -54,6 +54,7 @@
   };

   amba: amba {
 + u-boot,dm-pre-reloc;
   compatible = "simple-bus";
   #address-cells = <1>;
   #size-cells = <1>;
 diff --git a/arch/arm/dts/zynq-microzed.dts 
 b/arch/arm/dts/zynq-microzed.dts
 index c373a2c..5dff18e6 100644
 --- a/arch/arm/dts/zynq-microzed.dts
 +++ b/arch/arm/dts/zynq-microzed.dts
 @@ -21,3 +21,8 @@
   reg = <0 0x4000>;
   };
  };
 +
 + {
 + u-boot,dm-pre-reloc;
>>>
>>> Was this reviewed on DT mailing list?
>>
>> There is a thread going at present for Raspberry Pi but it had not
>> yielded much light last time I looked.
>>
>>>
>>> TBH adding this to every node seems to me a lot of work.
>>
>> This i how it works at present. Typically we only have a UART and that
>> is not necessary since U-Boot can force-bind this. But when the UART
>> is not in the root node we have to add something.
>
> It is partially problem with DT mess that we have platforms with and
> without bus. :-)
>
>>
>>> 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 = < ...>;
> }
>
> 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?

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?

>
>
>> If you like you could look at working up a patch for this. I'm
>> certainly interested in other ideas. It does need to be efficient.
>
> I will test this series and will look at it in more details soon.

Thanks.

BTW are there zynqmp dev boards available at reasonable cost? I did
this Zynq series because I discovered some old patches that were not
applied and decided to update then. It's a really interesting platform
- FPGA, etc.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Masahiro Yamada]

Simon,


2015-08-30 0:10 GMT+09:00 Simon Glass :
> We need to mark some device tree nodes so that they are available before
> relocation. This enables driver model to find these automatically. In the
> case of SPL it ensures that these nodes will be retained in SPL.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/arm/dts/zynq-7000.dtsi   | 1 +
>  arch/arm/dts/zynq-microzed.dts| 5 +
>  arch/arm/dts/zynq-picozed.dts | 5 +
>  arch/arm/dts/zynq-zc702.dts   | 1 +
>  arch/arm/dts/zynq-zc706.dts   | 1 +
>  arch/arm/dts/zynq-zc770-xm010.dts | 1 +
>  arch/arm/dts/zynq-zc770-xm011.dts | 1 +
>  arch/arm/dts/zynq-zc770-xm012.dts | 1 +
>  arch/arm/dts/zynq-zc770-xm013.dts | 1 +
>  arch/arm/dts/zynq-zed.dts | 1 +
>  arch/arm/dts/zynq-zybo.dts| 1 +
>  11 files changed, 19 insertions(+)
>
> diff --git a/arch/arm/dts/zynq-7000.dtsi b/arch/arm/dts/zynq-7000.dtsi
> index 0b62cb0..12614f2 100644
> --- a/arch/arm/dts/zynq-7000.dtsi
> +++ b/arch/arm/dts/zynq-7000.dtsi
> @@ -54,6 +54,7 @@
> };
>
> amba: amba {
> +   u-boot,dm-pre-reloc;
> compatible = "simple-bus";
> #address-cells = <1>;
> #size-cells = <1>;


You are adding "u-boot,dm-pre-reloc" to a simple-bus node.

With this commit, all the children are bound before relocation.

simple_bus_post_bind() calls dm_scan_fdt_node() with false for 'pre_reloc_only'.
I guess, this implementation is a problem.


Currently, 'pre_reloc_only' can be specified for the first-level nodes.

For example, assume node structure like this:

amba  {
   uart0 {

 };

 pinctrl {

 };

   usb {

 };

 eth {

 };
   };



Please tell me:
how to bind  "uart0" and "pinctrl", but not "usb", "eth"
before relocation.


Any idea to propagate 'pre_reloc_only' downwards?




-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Michal Simek]

On 08/29/2015 05:10 PM, Simon Glass wrote:
> We need to mark some device tree nodes so that they are available before
> relocation. This enables driver model to find these automatically. In the
> case of SPL it ensures that these nodes will be retained in SPL.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  arch/arm/dts/zynq-7000.dtsi   | 1 +
>  arch/arm/dts/zynq-microzed.dts| 5 +
>  arch/arm/dts/zynq-picozed.dts | 5 +
>  arch/arm/dts/zynq-zc702.dts   | 1 +
>  arch/arm/dts/zynq-zc706.dts   | 1 +
>  arch/arm/dts/zynq-zc770-xm010.dts | 1 +
>  arch/arm/dts/zynq-zc770-xm011.dts | 1 +
>  arch/arm/dts/zynq-zc770-xm012.dts | 1 +
>  arch/arm/dts/zynq-zc770-xm013.dts | 1 +
>  arch/arm/dts/zynq-zed.dts | 1 +
>  arch/arm/dts/zynq-zybo.dts| 1 +
>  11 files changed, 19 insertions(+)
> 
> diff --git a/arch/arm/dts/zynq-7000.dtsi b/arch/arm/dts/zynq-7000.dtsi
> index 0b62cb0..12614f2 100644
> --- a/arch/arm/dts/zynq-7000.dtsi
> +++ b/arch/arm/dts/zynq-7000.dtsi
> @@ -54,6 +54,7 @@
>   };
>  
>   amba: amba {
> + u-boot,dm-pre-reloc;
>   compatible = "simple-bus";
>   #address-cells = <1>;
>   #size-cells = <1>;
> diff --git a/arch/arm/dts/zynq-microzed.dts b/arch/arm/dts/zynq-microzed.dts
> index c373a2c..5dff18e6 100644
> --- a/arch/arm/dts/zynq-microzed.dts
> +++ b/arch/arm/dts/zynq-microzed.dts
> @@ -21,3 +21,8 @@
>   reg = <0 0x4000>;
>   };
>  };
> +
> + {
> + u-boot,dm-pre-reloc;

Was this reviewed on DT mailing list?

TBH adding this to every node seems to me a lot of work.
Why not just add one more uboot property to chosen with list of IPs
which needs to be relocated?

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
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Michal Simek]

On 08/31/2015 03:54 PM, Simon Glass wrote:
> Hi Michal,
> 
> On 31 August 2015 at 05:30, Michal Simek  wrote:
>> On 08/29/2015 05:10 PM, Simon Glass wrote:
>>> We need to mark some device tree nodes so that they are available before
>>> relocation. This enables driver model to find these automatically. In the
>>> case of SPL it ensures that these nodes will be retained in SPL.
>>>
>>> Signed-off-by: Simon Glass 
>>> ---
>>>
>>>  arch/arm/dts/zynq-7000.dtsi   | 1 +
>>>  arch/arm/dts/zynq-microzed.dts| 5 +
>>>  arch/arm/dts/zynq-picozed.dts | 5 +
>>>  arch/arm/dts/zynq-zc702.dts   | 1 +
>>>  arch/arm/dts/zynq-zc706.dts   | 1 +
>>>  arch/arm/dts/zynq-zc770-xm010.dts | 1 +
>>>  arch/arm/dts/zynq-zc770-xm011.dts | 1 +
>>>  arch/arm/dts/zynq-zc770-xm012.dts | 1 +
>>>  arch/arm/dts/zynq-zc770-xm013.dts | 1 +
>>>  arch/arm/dts/zynq-zed.dts | 1 +
>>>  arch/arm/dts/zynq-zybo.dts| 1 +
>>>  11 files changed, 19 insertions(+)
>>>
>>> diff --git a/arch/arm/dts/zynq-7000.dtsi b/arch/arm/dts/zynq-7000.dtsi
>>> index 0b62cb0..12614f2 100644
>>> --- a/arch/arm/dts/zynq-7000.dtsi
>>> +++ b/arch/arm/dts/zynq-7000.dtsi
>>> @@ -54,6 +54,7 @@
>>>   };
>>>
>>>   amba: amba {
>>> + u-boot,dm-pre-reloc;
>>>   compatible = "simple-bus";
>>>   #address-cells = <1>;
>>>   #size-cells = <1>;
>>> diff --git a/arch/arm/dts/zynq-microzed.dts b/arch/arm/dts/zynq-microzed.dts
>>> index c373a2c..5dff18e6 100644
>>> --- a/arch/arm/dts/zynq-microzed.dts
>>> +++ b/arch/arm/dts/zynq-microzed.dts
>>> @@ -21,3 +21,8 @@
>>>   reg = <0 0x4000>;
>>>   };
>>>  };
>>> +
>>> + {
>>> + u-boot,dm-pre-reloc;
>>
>> Was this reviewed on DT mailing list?
> 
> There is a thread going at present for Raspberry Pi but it had not
> yielded much light last time I looked.
> 
>>
>> TBH adding this to every node seems to me a lot of work.
> 
> This i how it works at present. Typically we only have a UART and that
> is not necessary since U-Boot can force-bind this. But when the UART
> is not in the root node we have to add something.

It is partially problem with DT mess that we have platforms with and
without bus. :-)

> 
>> 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 = < ...>;
}

And then just go through this list. I expect that you are looking for
that property anyway.


> If you like you could look at working up a patch for this. I'm
> certainly interested in other ideas. It does need to be efficient.

I will test this series and will look at it in more details soon.

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
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Simon Glass]

Hi Michal,

On 31 August 2015 at 05:30, Michal Simek  wrote:
> On 08/29/2015 05:10 PM, Simon Glass wrote:
>> We need to mark some device tree nodes so that they are available before
>> relocation. This enables driver model to find these automatically. In the
>> case of SPL it ensures that these nodes will be retained in SPL.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>>  arch/arm/dts/zynq-7000.dtsi   | 1 +
>>  arch/arm/dts/zynq-microzed.dts| 5 +
>>  arch/arm/dts/zynq-picozed.dts | 5 +
>>  arch/arm/dts/zynq-zc702.dts   | 1 +
>>  arch/arm/dts/zynq-zc706.dts   | 1 +
>>  arch/arm/dts/zynq-zc770-xm010.dts | 1 +
>>  arch/arm/dts/zynq-zc770-xm011.dts | 1 +
>>  arch/arm/dts/zynq-zc770-xm012.dts | 1 +
>>  arch/arm/dts/zynq-zc770-xm013.dts | 1 +
>>  arch/arm/dts/zynq-zed.dts | 1 +
>>  arch/arm/dts/zynq-zybo.dts| 1 +
>>  11 files changed, 19 insertions(+)
>>
>> diff --git a/arch/arm/dts/zynq-7000.dtsi b/arch/arm/dts/zynq-7000.dtsi
>> index 0b62cb0..12614f2 100644
>> --- a/arch/arm/dts/zynq-7000.dtsi
>> +++ b/arch/arm/dts/zynq-7000.dtsi
>> @@ -54,6 +54,7 @@
>>   };
>>
>>   amba: amba {
>> + u-boot,dm-pre-reloc;
>>   compatible = "simple-bus";
>>   #address-cells = <1>;
>>   #size-cells = <1>;
>> diff --git a/arch/arm/dts/zynq-microzed.dts b/arch/arm/dts/zynq-microzed.dts
>> index c373a2c..5dff18e6 100644
>> --- a/arch/arm/dts/zynq-microzed.dts
>> +++ b/arch/arm/dts/zynq-microzed.dts
>> @@ -21,3 +21,8 @@
>>   reg = <0 0x4000>;
>>   };
>>  };
>> +
>> + {
>> + u-boot,dm-pre-reloc;
>
> Was this reviewed on DT mailing list?

There is a thread going at present for Raspberry Pi but it had not
yielded much light last time I looked.

>
> TBH adding this to every node seems to me a lot of work.

This i how it works at present. Typically we only have a UART and that
is not necessary since U-Boot can force-bind this. But when the UART
is not in the root node we have to add something.

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

If you like you could look at working up a patch for this. I'm
certainly interested in other ideas. It does need to be efficient.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Simon Glass]

Hi Masahiro,

On 31 August 2015 at 04:01, Masahiro Yamada
 wrote:
> Simon,
>
>
> 2015-08-30 0:10 GMT+09:00 Simon Glass :
>> We need to mark some device tree nodes so that they are available before
>> relocation. This enables driver model to find these automatically. In the
>> case of SPL it ensures that these nodes will be retained in SPL.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>>  arch/arm/dts/zynq-7000.dtsi   | 1 +
>>  arch/arm/dts/zynq-microzed.dts| 5 +
>>  arch/arm/dts/zynq-picozed.dts | 5 +
>>  arch/arm/dts/zynq-zc702.dts   | 1 +
>>  arch/arm/dts/zynq-zc706.dts   | 1 +
>>  arch/arm/dts/zynq-zc770-xm010.dts | 1 +
>>  arch/arm/dts/zynq-zc770-xm011.dts | 1 +
>>  arch/arm/dts/zynq-zc770-xm012.dts | 1 +
>>  arch/arm/dts/zynq-zc770-xm013.dts | 1 +
>>  arch/arm/dts/zynq-zed.dts | 1 +
>>  arch/arm/dts/zynq-zybo.dts| 1 +
>>  11 files changed, 19 insertions(+)
>>
>> diff --git a/arch/arm/dts/zynq-7000.dtsi b/arch/arm/dts/zynq-7000.dtsi
>> index 0b62cb0..12614f2 100644
>> --- a/arch/arm/dts/zynq-7000.dtsi
>> +++ b/arch/arm/dts/zynq-7000.dtsi
>> @@ -54,6 +54,7 @@
>> };
>>
>> amba: amba {
>> +   u-boot,dm-pre-reloc;
>> compatible = "simple-bus";
>> #address-cells = <1>;
>> #size-cells = <1>;
>
>
> You are adding "u-boot,dm-pre-reloc" to a simple-bus node.
>
> With this commit, all the children are bound before relocation.

That should not happen unless you put the property in each child.

>
> simple_bus_post_bind() calls dm_scan_fdt_node() with false for 
> 'pre_reloc_only'.
> I guess, this implementation is a problem.

Yes, that is wrong. I remember noticing this at the time but not
having it as a parameter so I wasn't sure how to best regenerate it.

>
>
> Currently, 'pre_reloc_only' can be specified for the first-level nodes.
>
> For example, assume node structure like this:
>
> amba  {
>uart0 {
>
>  };
>
>  pinctrl {
>
>  };
>
>usb {
>
>  };
>
>  eth {
>
>  };
>};
>
>
>
> Please tell me:
> how to bind  "uart0" and "pinctrl", but not "usb", "eth"
> before relocation.
>
>
> Any idea to propagate 'pre_reloc_only' downwards?

Checking the GD_FLG_RELOC is the only thing I can think of. We don't
want to add parameter to the bind() method I think.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot