[U-Boot] Support of device-tree for PowerPC platform: Query

[U-Boot] Support of device-tree for PowerPC platform: Query

[Prabhakar Kushwaha]

Hi All,

We are trying to add support of device-tree for PowerPC platforms. As per our analysis following 2 options can be used. 

a) CONFIG_OF_SEPARATE 
b) CONFIG_OF_EMBED

In PowerPC platforms, reset_vector is always expected at the **last** address of flash.  
U-boot binary has reset_vector at last followed by __bss sections(not present in binary) and must be programmed in such a way that reset_vecrot lie at **last** address of flash.  

Hence dtb cannot be appended at last of  u-boot binary.

So there looks to be following 2 possible solutions
a) Use CONFIG_OF_SEPARATE and append dtb at start of u-boot binary.  This require change in flash map because u-boot start address needs to shifted (due to reset_vector requirements).
     Exiting offset of env and fman ucode also needs shifting. This approach requires modification in almost all existing PowerPC platform to adhere to new **modified** flash map.

b) Use CONFIG_OF_EMBED and embed dtb inside u-boot. This way no change in exiting flash map. But its usage is being discouraged as per doc/README.fdt-control.

Please suggest way forward. 

Regards,
Prabhakar

[U-Boot] Support of device-tree for PowerPC platform: Query

[York Sun]

+Simon

On 06/27/2018 01:05 AM, Prabhakar Kushwaha wrote:
> Hi All,
> 
> We are trying to add support of device-tree for PowerPC platforms. As per our analysis following 2 options can be used. 
> 
> a) CONFIG_OF_SEPARATE 
> b) CONFIG_OF_EMBED
> 
> In PowerPC platforms, reset_vector is always expected at the **last** address of flash.  
> U-boot binary has reset_vector at last followed by __bss sections(not present in binary) and must be programmed in such a way that reset_vecrot lie at **last** address of flash.  
> 
> Hence dtb cannot be appended at last of  u-boot binary.
> 
> So there looks to be following 2 possible solutions
> a) Use CONFIG_OF_SEPARATE and append dtb at start of u-boot binary.  This require change in flash map because u-boot start address needs to shifted (due to reset_vector requirements).
>      Exiting offset of env and fman ucode also needs shifting. This approach requires modification in almost all existing PowerPC platform to adhere to new **modified** flash map.
> 
> b) Use CONFIG_OF_EMBED and embed dtb inside u-boot. This way no change in exiting flash map. But its usage is being discouraged as per doc/README.fdt-control.
> 

Clearly putting dtb at the very end doesn't work, neither last 4KB. I
think we either use CONFIG_OF_EMBED (many boards use this way), or try
"fdtcontroladdr".

York

[U-Boot] Support of device-tree for PowerPC platform: Query

[Simon Glass]

Hi,

On 27 June 2018 at 08:06, York Sun <york.sun@nxp.com> wrote:
>
> +Simon
>
> On 06/27/2018 01:05 AM, Prabhakar Kushwaha wrote:
> > Hi All,
> >
> > We are trying to add support of device-tree for PowerPC platforms. As per our analysis following 2 options can be used.
> >
> > a) CONFIG_OF_SEPARATE
> > b) CONFIG_OF_EMBED
> >
> > In PowerPC platforms, reset_vector is always expected at the **last** address of flash.
> > U-boot binary has reset_vector at last followed by __bss sections(not present in binary) and must be programmed in such a way that reset_vecrot lie at **last** address of flash.
> >
> > Hence dtb cannot be appended at last of  u-boot binary.
> >
> > So there looks to be following 2 possible solutions
> > a) Use CONFIG_OF_SEPARATE and append dtb at start of u-boot binary.  This require change in flash map because u-boot start address needs to shifted (due to reset_vector requirements).
> >      Exiting offset of env and fman ucode also needs shifting. This approach requires modification in almost all existing PowerPC platform to adhere to new **modified** flash map.
> >
> > b) Use CONFIG_OF_EMBED and embed dtb inside u-boot. This way no change in exiting flash map. But its usage is being discouraged as per doc/README.fdt-control.
> >
>
> Clearly putting dtb at the very end doesn't work, neither last 4KB. I
> think we either use CONFIG_OF_EMBED (many boards use this way), or try
> "fdtcontroladdr".


I discourage CONFIG_OF_EMBED - it is a debug feature. I'm not sure if
you have other options though.

Can the DT perhaps go before U-Boot in the flash? We would need a way
to find it though.

With binman it is possible to put the DT anyway and have a symbol
defined to its address. Would that help?

Regards,
Simon

[U-Boot] Support of device-tree for PowerPC platform: Query

[Prabhakar Kushwaha]

Hi Simon,


> -----Original Message-----
> From: sjg at google.com [mailto:sjg at google.com] On Behalf Of Simon Glass
> Sent: Thursday, June 28, 2018 3:36 AM
> To: York Sun <york.sun@nxp.com>
> Cc: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
> boot at lists.denx.de; Poonam Aggrwal <poonam.aggrwal@nxp.com>; Jagdish
> Gediya <jagdish.gediya@nxp.com>
> Subject: Re: Support of device-tree for PowerPC platform: Query
> 
> Hi,
> 
> On 27 June 2018 at 08:06, York Sun <york.sun@nxp.com> wrote:
> >
> > +Simon
> >
> > On 06/27/2018 01:05 AM, Prabhakar Kushwaha wrote:
> > > Hi All,
> > >
> > > We are trying to add support of device-tree for PowerPC platforms. As
> per our analysis following 2 options can be used.
> > >
> > > a) CONFIG_OF_SEPARATE
> > > b) CONFIG_OF_EMBED
> > >
> > > In PowerPC platforms, reset_vector is always expected at the **last**
> address of flash.
> > > U-boot binary has reset_vector at last followed by __bss sections(not
> present in binary) and must be programmed in such a way that reset_vecrot
> lie at **last** address of flash.
> > >
> > > Hence dtb cannot be appended at last of  u-boot binary.
> > >
> > > So there looks to be following 2 possible solutions
> > > a) Use CONFIG_OF_SEPARATE and append dtb at start of u-boot binary.
> This require change in flash map because u-boot start address needs to
> shifted (due to reset_vector requirements).
> > >      Exiting offset of env and fman ucode also needs shifting. This approach
> requires modification in almost all existing PowerPC platform to adhere to
> new **modified** flash map.
> > >
> > > b) Use CONFIG_OF_EMBED and embed dtb inside u-boot. This way no
> change in exiting flash map. But its usage is being discouraged as per
> doc/README.fdt-control.
> > >
> >
> > Clearly putting dtb at the very end doesn't work, neither last 4KB. I
> > think we either use CONFIG_OF_EMBED (many boards use this way), or try
> > "fdtcontroladdr".
> 
> 
> I discourage CONFIG_OF_EMBED - it is a debug feature. I'm not sure if you
> have other options though.
> 
> Can the DT perhaps go before U-Boot in the flash? We would need a way to
> find it though.
> 

Thanks for the direction.

We will be following approach "a" with updated flash map.
We will allocate 1MB for uboot in flash. Out which 64K for DTB and 960KB for u-boot for future increase.

We will also update location of env and fman ucode for NXP platforms. 

--pk


--pk

[U-Boot] Support of device-tree for PowerPC platform: Query

[Bin Meng]

Hi  Prabhakar,

On Thu, Jun 28, 2018 at 6:05 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi,
>
> On 27 June 2018 at 08:06, York Sun <york.sun@nxp.com> wrote:
>>
>> +Simon
>>
>> On 06/27/2018 01:05 AM, Prabhakar Kushwaha wrote:
>> > Hi All,
>> >
>> > We are trying to add support of device-tree for PowerPC platforms. As per our analysis following 2 options can be used.
>> >
>> > a) CONFIG_OF_SEPARATE
>> > b) CONFIG_OF_EMBED
>> >
>> > In PowerPC platforms, reset_vector is always expected at the **last** address of flash.
>> > U-boot binary has reset_vector at last followed by __bss sections(not present in binary) and must be programmed in such a way that reset_vecrot lie at **last** address of flash.
>> >
>> > Hence dtb cannot be appended at last of  u-boot binary.
>> >
>> > So there looks to be following 2 possible solutions
>> > a) Use CONFIG_OF_SEPARATE and append dtb at start of u-boot binary.  This require change in flash map because u-boot start address needs to shifted (due to reset_vector requirements).
>> >      Exiting offset of env and fman ucode also needs shifting. This approach requires modification in almost all existing PowerPC platform to adhere to new **modified** flash map.
>> >
>> > b) Use CONFIG_OF_EMBED and embed dtb inside u-boot. This way no change in exiting flash map. But its usage is being discouraged as per doc/README.fdt-control.
>> >
>>
>> Clearly putting dtb at the very end doesn't work, neither last 4KB. I
>> think we either use CONFIG_OF_EMBED (many boards use this way), or try
>> "fdtcontroladdr".
>
>
> I discourage CONFIG_OF_EMBED - it is a debug feature. I'm not sure if
> you have other options though.
>

Agree.

> Can the DT perhaps go before U-Boot in the flash? We would need a way
> to find it though.
>

I don't see any issue that DT go after U-Boot in the flash. x86 does
this way, and its reset vector is also the last address of flash.

> With binman it is possible to put the DT anyway and have a symbol
> defined to its address. Would that help?

Regards,
Bin

[U-Boot] Support of device-tree for PowerPC platform: Query

[Prabhakar Kushwaha]

Hi Simon,

> -----Original Message-----
> From: Prabhakar Kushwaha
> Sent: Thursday, June 28, 2018 11:17 AM
> To: Simon Glass <sjg@chromium.org>; York Sun <york.sun@nxp.com>
> Cc: u-boot at lists.denx.de; Poonam Aggrwal <poonam.aggrwal@nxp.com>;
> Jagdish Gediya <jagdish.gediya@nxp.com>
> Subject: RE: Support of device-tree for PowerPC platform: Query
> 
> Hi Simon,
> 
> 
> > -----Original Message-----
> > From: sjg at google.com [mailto:sjg at google.com] On Behalf Of Simon Glass
> > Sent: Thursday, June 28, 2018 3:36 AM
> > To: York Sun <york.sun@nxp.com>
> > Cc: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
> > boot at lists.denx.de; Poonam Aggrwal <poonam.aggrwal@nxp.com>;
> Jagdish
> > Gediya <jagdish.gediya@nxp.com>
> > Subject: Re: Support of device-tree for PowerPC platform: Query
> >
> > Hi,
> >
> > On 27 June 2018 at 08:06, York Sun <york.sun@nxp.com> wrote:
> > >
> > > +Simon
> > >
> > > On 06/27/2018 01:05 AM, Prabhakar Kushwaha wrote:
> > > > Hi All,
> > > >
> > > > We are trying to add support of device-tree for PowerPC platforms.
> > > > As
> > per our analysis following 2 options can be used.
> > > >
> > > > a) CONFIG_OF_SEPARATE
> > > > b) CONFIG_OF_EMBED
> > > >
> > > > In PowerPC platforms, reset_vector is always expected at the
> > > > **last**
> > address of flash.
> > > > U-boot binary has reset_vector at last followed by __bss
> > > > sections(not
> > present in binary) and must be programmed in such a way that
> > reset_vecrot lie at **last** address of flash.
> > > >
> > > > Hence dtb cannot be appended at last of  u-boot binary.
> > > >
> > > > So there looks to be following 2 possible solutions
> > > > a) Use CONFIG_OF_SEPARATE and append dtb at start of u-boot
> binary.
> > This require change in flash map because u-boot start address needs to
> > shifted (due to reset_vector requirements).
> > > >      Exiting offset of env and fman ucode also needs shifting.
> > > > This approach
> > requires modification in almost all existing PowerPC platform to
> > adhere to new **modified** flash map.
> > > >
> > > > b) Use CONFIG_OF_EMBED and embed dtb inside u-boot. This way no
> > change in exiting flash map. But its usage is being discouraged as per
> > doc/README.fdt-control.
> > > >
> > >
> > > Clearly putting dtb at the very end doesn't work, neither last 4KB.
> > > I think we either use CONFIG_OF_EMBED (many boards use this way), or
> > > try "fdtcontroladdr".
> >
> >
> > I discourage CONFIG_OF_EMBED - it is a debug feature. I'm not sure if
> > you have other options though.
> >
> > Can the DT perhaps go before U-Boot in the flash? We would need a way
> > to find it though.
> >
> 
> Thanks for the direction.
> 
> We will be following approach "a" with updated flash map.
> We will allocate 1MB for uboot in flash. Out which 64K for DTB and 960KB for
> u-boot for future increase.
> 
> We will also update location of env and fman ucode for NXP platforms.
> 


Other thought,
 use CONFIG_OF_SEPARATE but **don’t** concatenate dtb with u-boot. In this case user has to program u-boot and dtb separately at different location. It will also have minimal impact on PowerPC platforms 

Just wondering if this approach has any disadvantages in longer run.  
What if user forget to program dtb and restart system??

--pk

[U-Boot] Support of device-tree for PowerPC platform: Query

[York Sun]

On 06/27/2018 10:53 PM, Bin Meng wrote:
<snip>
> 
>> Can the DT perhaps go before U-Boot in the flash? We would need a way
>> to find it though.
>>
> 
> I don't see any issue that DT go after U-Boot in the flash. x86 does
> this way, and its reset vector is also the last address of flash.
> 

Big issue. e500 runs from the last address of the flash. We cannot put
DT after U-Boot.

York

[U-Boot] Support of device-tree for PowerPC platform: Query

[York Sun]

On 06/27/2018 11:30 PM, Prabhakar Kushwaha wrote:

<snip>

>> Thanks for the direction.
>>
>> We will be following approach "a" with updated flash map.
>> We will allocate 1MB for uboot in flash. Out which 64K for DTB and 960KB for
>> u-boot for future increase.
>>
>> We will also update location of env and fman ucode for NXP platforms.
>>
> 
> 
> Other thought,
>  use CONFIG_OF_SEPARATE but **don’t** concatenate dtb with u-boot. In this case user has to program u-boot and dtb separately at different location. It will also have minimal impact on PowerPC platforms 
> 
> Just wondering if this approach has any disadvantages in longer run.  
> What if user forget to program dtb and restart system??
> 

If we cannot combine DT with U-Boot image, we may have to live with two
separated images. We may have to shift the ENV sectors to make DT right
above U-Boot for convenience. If U-Boot can boot up and show a message
of missing DT, it is acceptable to me.

York

[U-Boot] Support of device-tree for PowerPC platform: Query

[Bin Meng]

Hi York,

On Thu, Jun 28, 2018 at 11:32 PM, York Sun <york.sun@nxp.com> wrote:
> On 06/27/2018 10:53 PM, Bin Meng wrote:
> <snip>
>>
>>> Can the DT perhaps go before U-Boot in the flash? We would need a way
>>> to find it though.
>>>
>>
>> I don't see any issue that DT go after U-Boot in the flash. x86 does
>> this way, and its reset vector is also the last address of flash.
>>
>
> Big issue. e500 runs from the last address of the flash. We cannot put
> DT after U-Boot.

Looks you did not get it. I know e500 reset vector is the last 4 bytes
below 4G. This is similar to x86. DTB can be put after the u-boot
image without reset vector. You may check how x86 does this.

Regards,
Bin

[U-Boot] Support of device-tree for PowerPC platform: Query

[Prabhakar Kushwaha]

> -----Original Message-----
> From: York Sun
> Sent: Thursday, June 28, 2018 9:07 PM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Simon Glass
> <sjg@chromium.org>
> Cc: u-boot at lists.denx.de; Poonam Aggrwal <poonam.aggrwal@nxp.com>;
> Jagdish Gediya <jagdish.gediya@nxp.com>
> Subject: Re: Support of device-tree for PowerPC platform: Query
> 
> On 06/27/2018 11:30 PM, Prabhakar Kushwaha wrote:
> 
> <snip>
> 
> >> Thanks for the direction.
> >>
> >> We will be following approach "a" with updated flash map.
> >> We will allocate 1MB for uboot in flash. Out which 64K for DTB and
> >> 960KB for u-boot for future increase.
> >>
> >> We will also update location of env and fman ucode for NXP platforms.
> >>
> >
> >
> > Other thought,
> >  use CONFIG_OF_SEPARATE but **don't** concatenate dtb with u-boot.
> In
> > this case user has to program u-boot and dtb separately at different
> > location. It will also have minimal impact on PowerPC platforms
> >
> > Just wondering if this approach has any disadvantages in longer run.
> > What if user forget to program dtb and restart system??
> >
> 
> If we cannot combine DT with U-Boot image, we may have to live with two
> separated images. We may have to shift the ENV sectors to make DT right
> above U-Boot for convenience. If U-Boot can boot up and show a message of
> missing DT, it is acceptable to me.
> 

Putting DT in place of Env require lots of modification. 
I want to use existing QorIQ platform's memory map. 

Here 1 MB flash memory is reserved for Linux DTB.  Just wanted to split into 2 parts (Linux, uboot) with both size 512KB. 
This 1 MB location is far from u-boot, env, fman ucode. 

--pk

[U-Boot] Support of device-tree for PowerPC platform: Query

[Bin Meng]

Hi Prabhakar,

On Fri, Jun 29, 2018 at 10:55 AM, Prabhakar Kushwaha
<prabhakar.kushwaha@nxp.com> wrote:
>
>> -----Original Message-----
>> From: York Sun
>> Sent: Thursday, June 28, 2018 9:07 PM
>> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Simon Glass
>> <sjg@chromium.org>
>> Cc: u-boot at lists.denx.de; Poonam Aggrwal <poonam.aggrwal@nxp.com>;
>> Jagdish Gediya <jagdish.gediya@nxp.com>
>> Subject: Re: Support of device-tree for PowerPC platform: Query
>>
>> On 06/27/2018 11:30 PM, Prabhakar Kushwaha wrote:
>>
>> <snip>
>>
>> >> Thanks for the direction.
>> >>
>> >> We will be following approach "a" with updated flash map.
>> >> We will allocate 1MB for uboot in flash. Out which 64K for DTB and
>> >> 960KB for u-boot for future increase.
>> >>
>> >> We will also update location of env and fman ucode for NXP platforms.
>> >>
>> >
>> >
>> > Other thought,
>> >  use CONFIG_OF_SEPARATE but **don't** concatenate dtb with u-boot.
>> In
>> > this case user has to program u-boot and dtb separately at different
>> > location. It will also have minimal impact on PowerPC platforms
>> >
>> > Just wondering if this approach has any disadvantages in longer run.
>> > What if user forget to program dtb and restart system??
>> >
>>
>> If we cannot combine DT with U-Boot image, we may have to live with two
>> separated images. We may have to shift the ENV sectors to make DT right
>> above U-Boot for convenience. If U-Boot can boot up and show a message of
>> missing DT, it is acceptable to me.
>>
>
> Putting DT in place of Env require lots of modification.
> I want to use existing QorIQ platform's memory map.
>
> Here 1 MB flash memory is reserved for Linux DTB.  Just wanted to split into 2 parts (Linux, uboot) with both size 512KB.
> This 1 MB location is far from u-boot, env, fman ucode.
>

Since the QorIQ parts have lots of firmware that need to be put in
flash, binman is the best choice here and can handle dtb as well.

Regards,
Bin

[U-Boot] Support of device-tree for PowerPC platform: Query

[Prabhakar Kushwaha]

Dear Bin,

> -----Original Message-----
> From: Bin Meng [mailto:bmeng.cn at gmail.com]
> Sent: Friday, June 29, 2018 9:09 AM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
> Cc: York Sun <york.sun@nxp.com>; Simon Glass <sjg@chromium.org>; u-
> boot at lists.denx.de
> Subject: Re: [U-Boot] Support of device-tree for PowerPC platform: Query
> 
> Hi Prabhakar,
> 
> On Fri, Jun 29, 2018 at 10:55 AM, Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com> wrote:
> >
> >> -----Original Message-----
> >> From: York Sun
> >> Sent: Thursday, June 28, 2018 9:07 PM
> >> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Simon Glass
> >> <sjg@chromium.org>
> >> Cc: u-boot at lists.denx.de; Poonam Aggrwal
> <poonam.aggrwal@nxp.com>;
> >> Jagdish Gediya <jagdish.gediya@nxp.com>
> >> Subject: Re: Support of device-tree for PowerPC platform: Query
> >>
> >> On 06/27/2018 11:30 PM, Prabhakar Kushwaha wrote:
> >>
> >> <snip>
> >>
> >> >> Thanks for the direction.
> >> >>
> >> >> We will be following approach "a" with updated flash map.
> >> >> We will allocate 1MB for uboot in flash. Out which 64K for DTB and
> >> >> 960KB for u-boot for future increase.
> >> >>
> >> >> We will also update location of env and fman ucode for NXP platforms.
> >> >>
> >> >
> >> >
> >> > Other thought,
> >> >  use CONFIG_OF_SEPARATE but **don't** concatenate dtb with u-
> boot.
> >> In
> >> > this case user has to program u-boot and dtb separately at
> >> > different location. It will also have minimal impact on PowerPC
> >> > platforms
> >> >
> >> > Just wondering if this approach has any disadvantages in longer run.
> >> > What if user forget to program dtb and restart system??
> >> >
> >>
> >> If we cannot combine DT with U-Boot image, we may have to live with
> >> two separated images. We may have to shift the ENV sectors to make DT
> >> right above U-Boot for convenience. If U-Boot can boot up and show a
> >> message of missing DT, it is acceptable to me.
> >>
> >
> > Putting DT in place of Env require lots of modification.
> > I want to use existing QorIQ platform's memory map.
> >
> > Here 1 MB flash memory is reserved for Linux DTB.  Just wanted to split into
> 2 parts (Linux, uboot) with both size 512KB.
> > This 1 MB location is far from u-boot, env, fman ucode.
> >
> 
> Since the QorIQ parts have lots of firmware that need to be put in flash,
> binman is the best choice here and can handle dtb as well.
> 

Sure binman can help in creating/combining firmware for flash.

But we still require flash map change to accommodate dtb.  This is the reason I want to use reserved area which is very far from u-boot, env etc. 
I was thinking about any possible issue if u-boot and dtb are not together. 

--pk


 

[U-Boot] Support of device-tree for PowerPC platform: Query

[Prabhakar Kushwaha]

Dear Bin,

Coming back to x86 example. 

> -----Original Message-----
> From: Bin Meng [mailto:bmeng.cn at gmail.com]
> Sent: Friday, June 29, 2018 7:03 AM
> To: York Sun <york.sun@nxp.com>
> Cc: Simon Glass <sjg@chromium.org>; Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com>; u-boot at lists.denx.de
> Subject: Re: [U-Boot] Support of device-tree for PowerPC platform: Query
> 
> Hi York,
> 
> On Thu, Jun 28, 2018 at 11:32 PM, York Sun <york.sun@nxp.com> wrote:
> > On 06/27/2018 10:53 PM, Bin Meng wrote:
> > <snip>
> >>
> >>> Can the DT perhaps go before U-Boot in the flash? We would need a
> >>> way to find it though.
> >>>
> >>
> >> I don't see any issue that DT go after U-Boot in the flash. x86 does
> >> this way, and its reset vector is also the last address of flash.
> >>
> >
> > Big issue. e500 runs from the last address of the flash. We cannot put
> > DT after U-Boot.
> 
> Looks you did not get it. I know e500 reset vector is the last 4 bytes below 4G.
> This is similar to x86. DTB can be put after the u-boot image without reset
> vector. You may check how x86 does this.
> 

I tried to search thing for x86 but did not succeed ☹  

I request you to help me with sample code and boot flow.  
I will try to understand and see how it can help PowerPC. 

--pk

[U-Boot] Support of device-tree for PowerPC platform: Query

[Bin Meng]

Hi Prabhakar,

On Mon, Jul 2, 2018 at 11:27 PM, Prabhakar Kushwaha
<prabhakar.kushwaha@nxp.com> wrote:
> Dear Bin,
>
> Coming back to x86 example.
>
>> -----Original Message-----
>> From: Bin Meng [mailto:bmeng.cn at gmail.com]
>> Sent: Friday, June 29, 2018 7:03 AM
>> To: York Sun <york.sun@nxp.com>
>> Cc: Simon Glass <sjg@chromium.org>; Prabhakar Kushwaha
>> <prabhakar.kushwaha@nxp.com>; u-boot at lists.denx.de
>> Subject: Re: [U-Boot] Support of device-tree for PowerPC platform: Query
>>
>> Hi York,
>>
>> On Thu, Jun 28, 2018 at 11:32 PM, York Sun <york.sun@nxp.com> wrote:
>> > On 06/27/2018 10:53 PM, Bin Meng wrote:
>> > <snip>
>> >>
>> >>> Can the DT perhaps go before U-Boot in the flash? We would need a
>> >>> way to find it though.
>> >>>
>> >>
>> >> I don't see any issue that DT go after U-Boot in the flash. x86 does
>> >> this way, and its reset vector is also the last address of flash.
>> >>
>> >
>> > Big issue. e500 runs from the last address of the flash. We cannot put
>> > DT after U-Boot.
>>
>> Looks you did not get it. I know e500 reset vector is the last 4 bytes below 4G.
>> This is similar to x86. DTB can be put after the u-boot image without reset
>> vector. You may check how x86 does this.
>>
>
> I tried to search thing for x86 but did not succeed ☹
>

You can test x86 build easily with QEMU.

$ make qemu-x86_defconfig
$ make V=1

This way you can see how u-boot.rom image is built.

> I request you to help me with sample code and boot flow.
> I will try to understand and see how it can help PowerPC.
>

Please see the sample build flow below:

1.  objcopy --gap-fill=0xff  -O binary -R .start16 -R .resetvec u-boot
u-boot-nodtb.bin

.start16 and .resetvec is the x86 boot vector. This is similar to PPC
BookE's reset vector. These two sections are removed to generate a new
u-boot-nodtb binary.

2. cat arch/x86/dts/qemu-x86_i440fx.dtb > dts/dt.dtb
    cat u-boot-nodtb.bin dts/dt.dtb > u-boot-dtb.bin

Append dtb to the end of the u-boot-nodtb binary and get a new
u-boot-dtb binary.

3. cp dts/dt.dtb u-boot.dtb
    objcopy --gap-fill=0xff  -O binary -j .start16 -j .resetvec u-boot
u-boot-x86-16bit.bin

Create a binary which contains the reset vector.

4. ./tools/binman/binman -d u-boot.dtb -O . -I . -I
./board/emulation/qemu-x86 u-boot-x86-16bit.bin

Use binman to assemble the final u-boot.rom image.

Regards,
Bin

[U-Boot] Support of device-tree for PowerPC platform: Query

[Jagdish Gediya]

Hi Bin,

> -----Original Message-----
> From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Bin Meng
> Sent: Tuesday, July 3, 2018 8:11 PM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
> Cc: u-boot at lists.denx.de
> Subject: Re: [U-Boot] Support of device-tree for PowerPC platform: Query
> 
> Hi Prabhakar,
> 
> On Mon, Jul 2, 2018 at 11:27 PM, Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com> wrote:
> > Dear Bin,
> >
> > Coming back to x86 example.
> >
> >> -----Original Message-----
> >> From: Bin Meng [mailto:bmeng.cn at gmail.com]
> >> Sent: Friday, June 29, 2018 7:03 AM
> >> To: York Sun <york.sun@nxp.com>
> >> Cc: Simon Glass <sjg@chromium.org>; Prabhakar Kushwaha
> >> <prabhakar.kushwaha@nxp.com>; u-boot at lists.denx.de
> >> Subject: Re: [U-Boot] Support of device-tree for PowerPC platform:
> >> Query
> >>
> >> Hi York,
> >>
> >> On Thu, Jun 28, 2018 at 11:32 PM, York Sun <york.sun@nxp.com> wrote:
> >> > On 06/27/2018 10:53 PM, Bin Meng wrote:
> >> > <snip>
> >> >>
> >> >>> Can the DT perhaps go before U-Boot in the flash? We would need a
> >> >>> way to find it though.
> >> >>>
> >> >>
> >> >> I don't see any issue that DT go after U-Boot in the flash. x86
> >> >> does this way, and its reset vector is also the last address of flash.
> >> >>
> >> >
> >> > Big issue. e500 runs from the last address of the flash. We cannot
> >> > put DT after U-Boot.
> >>
> >> Looks you did not get it. I know e500 reset vector is the last 4 bytes below
> 4G.
> >> This is similar to x86. DTB can be put after the u-boot image without
> >> reset vector. You may check how x86 does this.
> >>
> >
> > I tried to search thing for x86 but did not succeed ☹
> >
> 
> You can test x86 build easily with QEMU.
> 
> $ make qemu-x86_defconfig
> $ make V=1
> 
> This way you can see how u-boot.rom image is built.
> 
> > I request you to help me with sample code and boot flow.
> > I will try to understand and see how it can help PowerPC.
> >
> 
> Please see the sample build flow below:
> 
> 1.  objcopy --gap-fill=0xff  -O binary -R .start16 -R .resetvec u-boot u-boot-
> nodtb.bin
> 
> .start16 and .resetvec is the x86 boot vector. This is similar to PPC BookE's reset
> vector. These two sections are removed to generate a new u-boot-nodtb
> binary.
> 
> 2. cat arch/x86/dts/qemu-x86_i440fx.dtb > dts/dt.dtb
>     cat u-boot-nodtb.bin dts/dt.dtb > u-boot-dtb.bin
> 
> Append dtb to the end of the u-boot-nodtb binary and get a new u-boot-dtb
> binary.
> 
> 3. cp dts/dt.dtb u-boot.dtb
>     objcopy --gap-fill=0xff  -O binary -j .start16 -j .resetvec u-boot u-boot-x86-
> 16bit.bin
> 
> Create a binary which contains the reset vector.
> 
> 4. ./tools/binman/binman -d u-boot.dtb -O . -I . -I
> ./board/emulation/qemu-x86 u-boot-x86-16bit.bin
> 
> Use binman to assemble the final u-boot.rom image.

Wouldn't it be similar to CONFIG_OF_EMBED as dtb is embedded in final binary(before start and resetvec sections)?

Thanks,
Jagdish

[U-Boot] Support of device-tree for PowerPC platform: Query

[Bin Meng]

Hi Jagdish,

On Thu, Jul 5, 2018 at 1:31 PM, Jagdish Gediya <jagdish.gediya@nxp.com> wrote:
> Hi Bin,
>
>> -----Original Message-----
>> From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Bin Meng
>> Sent: Tuesday, July 3, 2018 8:11 PM
>> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
>> Cc: u-boot at lists.denx.de
>> Subject: Re: [U-Boot] Support of device-tree for PowerPC platform: Query
>>
>> Hi Prabhakar,
>>
>> On Mon, Jul 2, 2018 at 11:27 PM, Prabhakar Kushwaha
>> <prabhakar.kushwaha@nxp.com> wrote:
>> > Dear Bin,
>> >
>> > Coming back to x86 example.
>> >
>> >> -----Original Message-----
>> >> From: Bin Meng [mailto:bmeng.cn at gmail.com]
>> >> Sent: Friday, June 29, 2018 7:03 AM
>> >> To: York Sun <york.sun@nxp.com>
>> >> Cc: Simon Glass <sjg@chromium.org>; Prabhakar Kushwaha
>> >> <prabhakar.kushwaha@nxp.com>; u-boot at lists.denx.de
>> >> Subject: Re: [U-Boot] Support of device-tree for PowerPC platform:
>> >> Query
>> >>
>> >> Hi York,
>> >>
>> >> On Thu, Jun 28, 2018 at 11:32 PM, York Sun <york.sun@nxp.com> wrote:
>> >> > On 06/27/2018 10:53 PM, Bin Meng wrote:
>> >> > <snip>
>> >> >>
>> >> >>> Can the DT perhaps go before U-Boot in the flash? We would need a
>> >> >>> way to find it though.
>> >> >>>
>> >> >>
>> >> >> I don't see any issue that DT go after U-Boot in the flash. x86
>> >> >> does this way, and its reset vector is also the last address of flash.
>> >> >>
>> >> >
>> >> > Big issue. e500 runs from the last address of the flash. We cannot
>> >> > put DT after U-Boot.
>> >>
>> >> Looks you did not get it. I know e500 reset vector is the last 4 bytes below
>> 4G.
>> >> This is similar to x86. DTB can be put after the u-boot image without
>> >> reset vector. You may check how x86 does this.
>> >>
>> >
>> > I tried to search thing for x86 but did not succeed ☹
>> >
>>
>> You can test x86 build easily with QEMU.
>>
>> $ make qemu-x86_defconfig
>> $ make V=1
>>
>> This way you can see how u-boot.rom image is built.
>>
>> > I request you to help me with sample code and boot flow.
>> > I will try to understand and see how it can help PowerPC.
>> >
>>
>> Please see the sample build flow below:
>>
>> 1.  objcopy --gap-fill=0xff  -O binary -R .start16 -R .resetvec u-boot u-boot-
>> nodtb.bin
>>
>> .start16 and .resetvec is the x86 boot vector. This is similar to PPC BookE's reset
>> vector. These two sections are removed to generate a new u-boot-nodtb
>> binary.
>>
>> 2. cat arch/x86/dts/qemu-x86_i440fx.dtb > dts/dt.dtb
>>     cat u-boot-nodtb.bin dts/dt.dtb > u-boot-dtb.bin
>>
>> Append dtb to the end of the u-boot-nodtb binary and get a new u-boot-dtb
>> binary.
>>
>> 3. cp dts/dt.dtb u-boot.dtb
>>     objcopy --gap-fill=0xff  -O binary -j .start16 -j .resetvec u-boot u-boot-x86-
>> 16bit.bin
>>
>> Create a binary which contains the reset vector.
>>
>> 4. ./tools/binman/binman -d u-boot.dtb -O . -I . -I
>> ./board/emulation/qemu-x86 u-boot-x86-16bit.bin
>>
>> Use binman to assemble the final u-boot.rom image.
>
> Wouldn't it be similar to CONFIG_OF_EMBED as dtb is embedded in final binary(before start and resetvec sections)?

It's similar, but they are different things. CONFIG_OF_EMBED builds
dts into the data section of U-Boot image while CONFIG_OF_SEPARATE
does not. Both should be supported in PowerPC IMO.

Regards,
Bin