Fwd: Re: DTS for PowerPC 440 based board

[Grant Likely]

On Mon, Nov 23, 2009 at 12:29 AM,  <vinayak.kale at gmail.com> wrote:
> Hi,
>
> David, Grant thank you for providing the info.
> From your reply and the other sources what I gather is as below. Please
> confirm whether I am on the right track.
>
> 1) Bootloader passing BDInfo:
> Here, I have to create a .dts file inside /arch/powerpc/boot/dts directory.
> dtc compiles the .dts file and creates a dtb. The kernel, dtb and
> boot-wrapper are then embedded in a cuImage.* file after make. We need to
> write the platform-specific fix-ups in the cuboot-*.c file. The bootloader
> will pass BDInfo struct to kernel.

The bootloader will pass bdinfo to the bootwrapper (the cuImage)

> The kernel will also receive the dtb.

The bootwrapper will pass the dtb to the kernel proper.  bootloader
knows nothing about the dtb, and the kernel knows nothing about
bdinfo.

> The only kernel changes we need to do here are fixups in cuboot-*.c and
> creation of .dts file.

Correct.  But if you're doing a new board and have control over your
bootloader, then don't choose this option.  bdinfo structures

> 2) Bootloader passing DT:
> Here, the booloader will directly pass the DT instead of BDInfo. The
> platform-specific code in simpleboot.c will get excuted. We don't have to do
> any fixups inside kernel here.

simpleboot.c doesn't get run at all.  In fact, the bootwrapper doesn't
get used at all in this case.  The uImage is just the raw compressed
kernel image (vmlinux) with a uImage header on it.

> I have queries with this approach -
> a) In this case, who creates DT? Do we need to use any tools to create a DT?

The .dts file still lives in the kernel tree, and the kernel build
process still compiles it into a .dtb

> or it can be created the same way by compiling the .dts file using dtc?

yes

> b) From previous implementaions of other boards, I didn't see any platform
> specific fix-ups inside kernel being done? Why is so that in case of BDInfo
> we need fix-ups and here we don't?

because bdinfo is a horribly method of passing data to the kernel.  So
the bdinfo data needs to be translated into a form the kernel can use
(the device tree).  Fixups aren't needed with this approach because
the device tree passed by the bootloader already has all the correct
data in it.  U-Boot has the ability to modify the .dtb blob at boot
time to update things like the kernel parameters line and the memory
size if it needs to.

> Please confirm my understanding of above to approaches. Also please suggest
> which way is better.

Pass the device tree from the bootloader.  the bootwrapper method is
only to support firmware that cannot pass a device tree image, and
passing bdinfo is non-portable and can cause problems.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.