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

Grant Likely wrote:
>
> Step 1: run away
> Step 2: don't look back.
    There are days.

>
> 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.
    That depends. I am a consultant. My works is primarily paid for by
my clients, clients.
    I tinker when I am not otherwise busy. But I am very busy, despite
being short on work !?

   
>
> 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.
    That sounds somewhat interesting.

    But as was somewhat raised elsewhere - what about partial
reprogramming the FPGA on the fly ?
   
    One of the fundimental issues I am facing, is that I have to deal
with a system where nothing is certain except that there is a
    ppc405 present. There will always be more than that - but there is
not another component that MUST be present.
    As things go forward, more optional components get added.
    Pico is not yet doing partial FPGA reprogramming on the fly - but I
am certain it is coming. It fits perfectly with the goals and objectives
    of the company and its clients.

    For the moment the problem is fairly small. But it is only going to
get worse with time. The decisions I make now, will either make my life
pleasant or horrible later.
    Better to work towards where we are going now.

    I guess I need to digest
Documentation/powerpc/booting-without-of.txt. now. At the moment things
are  busy
>
>>
>>      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.
    Can you populate the tree dynamically inside the Linux setup code ?

>
> Cheers,
> g.
>


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

  reply	other threads:[~2006-09-24  5:48 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
2006-09-24  5:42                     ` David H. Lynch Jr. [this message]
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=45161ADB.4020106@dlasys.net \
    --to=dhlii@dlasys.net \
    --cc=grant.likely@secretlab.ca \
    --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).