Re: Fwd: Re: DTS for PowerPC 440 based board

Re: Fwd: Re: DTS for PowerPC 440 based board

[vinayak.kale]

[-- Attachment #1: Type: text/plain, Size: 3191 bytes --]

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 kernel will also receive the dtb.
The only kernel changes we need to do here are fixups in cuboot-*.c and  
creation of .dts file.

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.
I have queries with this approach -
a) In this case, who creates DT? Do we need to use any tools to create a  
DT? or it can be created the same way by compiling the .dts file using dtc?
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?


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

Regards,
Vinayak

----------------------------------------------------------------------------------------------------
From: David Gibson <david@gibson.dropbear.id.au>
Date: Sun, Nov 22, 2009 at 2:50 AM
Subject: Re: DTS for PowerPC 440 based board
To: Vinayak Kale <vinayak.kale@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org



On Sun, Nov 22, 2009 at 12:16:59AM +0530, Vinayak Kale wrote:
> Hi,
> I am porting 2.6.31 for a PowerPC 440 core based board. I have couple of
> queries. I would really appreciate if someone could answer since i  
> couldn't
> find info from other places.

> 1) Is it mandatory to create a DTS file?


Roughly speaking, yes. You have to supply a device tree to the
kernel somehow, so if the firmware doesn't supply one itself, you will
need to create a DTS.


> 2) If uboot passes BDInfo struct to kernel instead of DT blob, then in  
> this
> case does kernel creates FDT at run time?


Not exactly. In this case the bootwrapper will be built with an FDT
(compiled from a dts) built in. It will however tweak the FDT with
information from the BDInfo before booting the kernel proper.


> 3) I believe in case of DTS, the kernel picks up the h/w info from DTS  
> blob
> so we need not hardcode any register addresses etc inside kernel other  
> than
> in dts file. What happens in case of uboot passing just BDInfo struct. How
> do we specify the register addresses etc?


There's always a device tree which specifies register addresses. If
the firmware only supplies a BDInfo, then the kernel wrapper must have
a device tree built in. In practice that will always be built from a
dts, though it doesn't have to be in theory.

--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: text/html, Size: 3769 bytes --]

Re: Fwd: Re: DTS for PowerPC 440 based board

[Grant Likely]

On Mon, Nov 23, 2009 at 12:29 AM,  <vinayak.kale@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.