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 --]
next parent 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).