linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Grant Likely" <grant.likely@secretlab.ca>
To: "David H. Lynch Jr." <dhlii@dlasys.net>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Ethernet driver for Linux kernel 2.6 running on ML403
Date: Tue, 19 Sep 2006 15:27:01 -0600	[thread overview]
Message-ID: <528646bc0609191427o11146c54q650738bcb10f8d98@mail.gmail.com> (raw)
In-Reply-To: <451055D2.5080308@dlasys.net>

On 9/19/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>
>  Grant Likely wrote:
>
>  Avast! After getting quizzed on IRC about this off-the-cuff comment,
> I should probably clarify. Since the Xilinx IP could be wired up to a
> ublaze core or an off-chip processor, the drivers still need to use a
> platform bus attachment to keep it all cross platform.
>
> So, replace above comment with the following:
>
> Populating the platform device with static code during initialization
> is sooo last year.
>
> Time to hack device trees to populate it instead.
>
>      So I got another X V4 board. I hacked in the Platform device stuff from
> you ml403 code with changes needed for my hardware.
>      and my brain is slowly begining to actually grasp  what is going on - I
> am begining to grasp the platform devices big picture (over a mountain
> through a spyglass in the fog)
>
>      Where do I begin with Device Trees ?

Step 1: run away
Step 2: don't look back.

Just kidding.  Unless you want to help move Virtex support from
arch/ppc to arch/powerpc, you don't really need to worry about device
trees for a while.

If you are interested, look at
Documentation/powerpc/booting-without-of.txt.  Then start poking Matt
Porter about when he's going to get 4xx ported to arch/powerpc.

I've been half heartedly looking at what needs to be done to generate
a device tree based on either system.mhs or xparameters.h.  I'm
probably going to write a tiny C program that is compiled against
xparameters.h and spits out a valid dts file.  The dts file can then
be run through the device tree compiler to produce the flattened
device tree structure.

>
>      The vague Picture I have is the have something to do with some
> datastructure that Mac's typically create at or prior to boot. And that for
> embedded systems we are building them
>      externally compiling them and then attaching the compiled device tree
> to our project.

That right.  You don't compile device base addresses, irqs, etc into
the kernel.  You pass them in at boot time with a data structure.

>
>      I got a Xilinv V4 device currently with a Pic, UartLite, TEMAC, Flash
> and Keyhole (pseuodo serial host interface). Of those it is only certain
> that the flash will always be there.
>      We have bit images with Keyhole only, Uartlite only TEMAC only,
> Sometimes we have a Pic sometimes not. I was trying to get to the point were
> I could dynamically add what was there
>      to Platform devices during initialization.
>
>      If Device trees are static, then do they even apply to what I have to
> deal with ?

Device trees don't have to be static.  They can be generated/modified
on the fly if the bootloader supports it.  Or you can pass a different
tree depending on what IP you have on the board.

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

  reply	other threads:[~2006-09-19 21:27 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.241.1158193867.2423.linuxppc-embedded@ozlabs.org>
2006-09-14  1:40 ` Ethernet driver for Linux kernel 2.6 running on ML403 Aleck Lin
2006-09-14  1:48   ` Eugene Surovegin
2006-09-14  1:52   ` Grant Likely
2006-09-14 11:18     ` David H. Lynch Jr.
2006-09-14 13:53       ` Michael Galassi
2006-09-14 14:34         ` Grant Likely
2006-09-14 15:47           ` Keith J Outwater
2006-09-14 22:57             ` Grant Likely
2006-09-19  7:48           ` Peter Korsgaard
2006-09-19 14:17             ` Grant Likely
2006-09-19 20:10               ` Grant Likely
2006-09-19 20:40                 ` David H. Lynch Jr.
2006-09-19 21:27                   ` Grant Likely [this message]
2006-09-24  5:42                     ` David H. Lynch Jr.
2006-09-24 14:35                       ` Grant Likely
2006-09-14 23:02         ` David H. Lynch Jr.
2006-09-14 16:40 John Bonesio
2006-09-14 17:36 ` Keith J Outwater
2006-09-14 22:02   ` T Ziomek
2006-09-14 23:16   ` David H. Lynch Jr.
2006-09-14 22:49 ` Grant Likely
2006-09-15 16:11   ` T Ziomek
2006-09-19 10:13 ` Peter Korsgaard
2006-09-19 18:06 ` Andrew
  -- strict thread matches above, loose matches on Subject: below --
2006-09-14 17:52 John Bonesio
2006-09-14 23:08 ` Keith J Outwater
2006-09-15  0:08 ` David H. Lynch Jr.
2006-09-15  1:14 ` David H. Lynch Jr.
2006-09-15 19:13 John Bonesio
2006-09-19 14:16 ` 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=528646bc0609191427o11146c54q650738bcb10f8d98@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=dhlii@dlasys.net \
    --cc=linuxppc-embedded@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).