[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 at 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 at 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 at 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 at nxp.com>
>> >> Cc: Simon Glass <sjg at chromium.org>; Prabhakar Kushwaha
>> >> <prabhakar.kushwaha at 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 at 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