In message [off-list ref] you wrote:
OK, lets look at the very simple problem of having two
ethernet interfaces. From where do I get the ethernet
mac addresses? Modifying bd_t with defines is gross.
This is hardware dependend. For example, on some boards the MAC
addresses are simply sequential - so you just add one :-)
Putting everything on the kernel command line results in
an unreadable command line.
Agreed. The command line is another bad solution to pass such
information.
Yeah, having the bi_recs interface actually working
would be ideal, but at the present time nothing is
working and as AFAIK no-one is working on it.
Mark A. Greer made a nice proposal more than 2 years ago. See
discussion that started as "EV-64260-BP & GT64260 bi_recs" around
March 19, 2002.
I'd be happy to see this accepted.
I have to have something working now and IMO just reading
the u-boot environment is the fastest solution.
OK - accepted. But it's a quick and dirty hack, and not something
that should go into a public tree.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
Microsoft Multitasking:
several applications can crash at the same time.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Wolfgang Denk wrote:
In message [off-list ref] you wrote:
quoted
OK, lets look at the very simple problem of having two
ethernet interfaces. From where do I get the ethernet
mac addresses? Modifying bd_t with defines is gross.
This is hardware dependend. For example, on some boards the MAC
addresses are simply sequential - so you just add one :-)
quoted
Putting everything on the kernel command line results in
an unreadable command line.
Agreed. The command line is another bad solution to pass such
information.
quoted
Yeah, having the bi_recs interface actually working
would be ideal, but at the present time nothing is
working and as AFAIK no-one is working on it.
Mark A. Greer made a nice proposal more than 2 years ago. See
discussion that started as "EV-64260-BP & GT64260 bi_recs" around
March 19, 2002.
I'd be happy to see this accepted.
Hey, thanks for the plug Wolfgang! :)
Here are some thoughts that don't directly address the bi_rec (or
whatever) issue but they are related...
Some things have changed since that thread. In particular, the "On Chip
Peripheral" or OCP support has been added to the kernel. Matt Porter
has spent a lot of time working on the OCP and has it looking/working
well. If you're not familiar with it, its worth a look.
We can use the OCP to pass information from the platform-specific kernel
code to drivers. We still have the issue of getting info into the
kernel in the first place so we still need to resolve that issue.
However, I would rather have drivers look in the OCP for info instead of
directly at bi_recs (or whatever we chose).
So for example, a network driver does not have to worry about where to
get a MAC address, it just looks in the OCP. The board-specific code
can deal with getting the MAC addr from a bi_rec, the cmd line, an I2C
SROM somewhere, conjuring one up using incrementing MAC addrs, or
whatever. After all, where to get the MAC addr really is platform (&
firmware) specific. The OCP provides a single, clean interface to pass
info into drivers.
I think its something worth considering.
Mark
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
I have seen many references to OCP. How does one find out what it is?
Mark Chambers
----- Original Message -----
From: "Mark A. Greer" <redacted>
Here are some thoughts that don't directly address the bi_rec (or
whatever) issue but they are related...
Some things have changed since that thread. In particular, the "On Chip
Peripheral" or OCP support has been added to the kernel.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Mark Chambers wrote:
I have seen many references to OCP. How does one find out what it is?
AFAIK, the best way is to just look at the code: arch/ppc/syslib/ocp.c.
Its pretty straightforward. Its used extensively by the 4xx code:
arch/ppc/platforms/4xx/*.
Mark
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Some things have changed since that thread. In particular, the "On
Chip
Peripheral" or OCP support has been added to the kernel. Matt Porter
has spent a lot of time working on the OCP and has it looking/working
well. If you're not familiar with it, its worth a look.
We can use the OCP to pass information from the platform-specific
kernel
code to drivers. We still have the issue of getting info into the
kernel in the first place so we still need to resolve that issue.
However, I would rather have drivers look in the OCP for info instead
of
directly at bi_recs (or whatever we chose).
So for example, a network driver does not have to worry about where to
get a MAC address, it just looks in the OCP. The board-specific code
can deal with getting the MAC addr from a bi_rec, the cmd line, an I2C
SROM somewhere, conjuring one up using incrementing MAC addrs, or
whatever. After all, where to get the MAC addr really is platform (&
firmware) specific. The OCP provides a single, clean interface to pass
info into drivers.
I think its something worth considering.
I agree with Mark. We are already doing this for 85xx in 2.4 and 2.6.
The board code handles populating mac addr's in OCP info.
Our intention is that drivers that support Freescale parts should use
OCP. One of the reasons for this is because of all the various
processors that will exist from Freescale were the driver should be
reusable.
- kumar
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/