[U-Boot] Support of device-tree for PowerPC platform: Query
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
+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
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
Hi Simon,
-----Original Message----- From: sjg@google.com [mailto:sjg@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@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 approachrequires 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
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@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@google.com [mailto:sjg@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@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
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
-----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@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
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@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
Dear Bin,
-----Original Message----- From: Bin Meng [mailto:bmeng.cn@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@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@lists.denx.de; Poonam Aggrwal
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
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
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
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
Dear Bin,
Coming back to x86 example.
-----Original Message----- From: Bin Meng [mailto:bmeng.cn@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@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
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@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@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
Hi Bin,
-----Original Message----- From: U-Boot [mailto:u-boot-bounces@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@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@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@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:
- 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.
- 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.
- 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.
- ./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
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@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@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@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@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:
- 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.
- 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.
- 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.
- ./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
participants (5)
-
Bin Meng -
Jagdish Gediya -
Prabhakar Kushwaha -
Simon Glass -
York Sun