linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: vinayak.kale@gmail.com
To: david@gibson.dropbear.id.au, grant.likely@secretlab.ca,
	Vinayak Kale <vinayak.kale@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: Fwd: Re: DTS for PowerPC 440 based board
Date: Mon, 23 Nov 2009 07:29:35 +0000	[thread overview]
Message-ID: <0016e646923c937a80047904c936@google.com> (raw)
In-Reply-To: <001636832accdcc8a40479024c96@google.com>

[-- 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 --]

       reply	other threads:[~2009-11-23  7:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <001636832accdcc8a40479024c96@google.com>
2009-11-23  7:29 ` vinayak.kale [this message]
2009-11-23 18:11   ` Fwd: Re: DTS for PowerPC 440 based board Grant Likely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0016e646923c937a80047904c936@google.com \
    --to=vinayak.kale@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=grant.likely@secretlab.ca \
    --cc=linuxppc-dev@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).