Hi Jagdish, On Thu, Jul 5, 2018 at 1:31 PM, Jagdish Gediya <jagdish.ged...@nxp.com> wrote: > Hi Bin, > >> -----Original Message----- >> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Bin Meng >> Sent: Tuesday, July 3, 2018 8:11 PM >> To: Prabhakar Kushwaha <prabhakar.kushw...@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.kushw...@nxp.com> wrote: >> > Dear Bin, >> > >> > Coming back to x86 example. >> > >> >> -----Original Message----- >> >> From: Bin Meng [mailto:bmeng...@gmail.com] >> >> Sent: Friday, June 29, 2018 7:03 AM >> >> To: York Sun <york....@nxp.com> >> >> Cc: Simon Glass <s...@chromium.org>; Prabhakar Kushwaha >> >> <prabhakar.kushw...@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....@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
