From: Michael Sokolov <hidden> Date: 2002-03-21 02:13:19
Dan Malek [off-list ref] wrote:
The only reason _any_ Ethernet
information had been passed between the bootloader and the kernel
was for the processors with internal peripherals and a variety of
methods that were used for retrieving the MAC address.
Yes, and this is how it should be.
Now not just for Ethernet, but for any peripherals built into the CPU, the
system controller, or the board custom logic we need bi_recs to tell the kernel
how it's wired. Like if some random peripheral chip (not PCI or somesuch, but
"system" type that we have to have hard knowledge of) has a pin that can be
tied high or low that affects its operation and the Linux driver needs to know
how it's tied, we need to have the board firmware pass this magic info via
bi_recs (now it's done either with a board #ifdef maze or .config options). I
don't think there should be .config options for things that are fixed hard in
PCB traces or in silicon, and board #ifdefs are ugly. bi_recs are the answer.
That's why I included is_rmii and phy_addr in BI_GT64260_ETH_CFG.
There are
already Linux methods for configuring network interfaces, we don't
need to add another one.
Exactly. Things like 10 vs. 100 Mbps shouldn't be in bi_recs because they are
up to the user to decide and Linux already provides standard mechanisms for
them. bi_recs should be used only for stuff that's completely involuntary,
i.e., to describe how the board is wired. This way they can be completely
hidden from the user who can't override a PCB trace in software anyway.
MS
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2002-03-21 06:39:22
Michael Sokolov wrote:
......pass this magic info via
bi_recs (now it's done either with a board #ifdef maze or .config options). I
don't think there should be .config options for things that are fixed hard in
PCB traces or in silicon, and board #ifdefs are ugly. bi_recs are the answer.
I don't agree. I believe if you can't configure the software in the usual
way with configuration options, you can't do it cleanly with bi_recs, either.
There are pin multiplex configurations on 8xx that you just can't (or shouldn't
due to lots of complexity) define in a dynamic manner. The purpose of the
current Linux configuration is to create a binary that fits a particular board
and architecture. Not so long ago, we had great discussions over creating kernels
with lots of dynamic configuration that would boot on multiple boards and how
this wasn't suitable for embedded processors due to limited resources. We
painstakingly made changes to #defines and rewrote software so the compiler
would apply optimizations to create binaries as small as possible. I guess no
one remembers that anymore :-). The config options are exactly for things that
are fixed by board and processor design. The bi_recs are for only those things
that aren't fixed by board or processor design, like memory size, cpu speed,
MAC address. I almost have to give into Wolfgang's request for flash details,
but I would still rather have mtd configurations for that :-).
Just take a look at and understand how some of this software has evolved, and
the 8xx is a great example. Lots of boards use the same processor (and built in
peripherals) and are wired slightly different, but there is still a separate
configuration for all of them and it would be overly complex to not do this.
Yes, you _could_, but I don't see any value in doing so other than proving you
can do it. It creates code that just consumes more resources. Once you have
a configuration for the board, the variations are the things I keep mentioning..
...memory size, cpu speed, MAC address, console port baud rate. It's been working
nicely for years, and it is conceptually consistent with other types of Linux
configuration on other platforms.
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Paul Mackerras <hidden> Date: 2002-03-31 08:32:37
Dan Malek writes:
I don't agree. I believe if you can't configure the software in the usual
way with configuration options, you can't do it cleanly with bi_recs, either.
There are pin multiplex configurations on 8xx that you just can't (or shouldn't
due to lots of complexity) define in a dynamic manner. The purpose of the
current Linux configuration is to create a binary that fits a particular board
and architecture.
I don't particularly like the way we define what is on a given
embedded board with what boils down to a shell script. It seems ugly
and clumsy to me, as does the pile of #defines and #ifdefs that we end
up with as the way for drivers to know where their devices are.
What I would like to see is a readable, compact, clear description of
the hardware (for a given embedded board) in one place, i.e. one file.
Probably not in C code, rather some sort of syntax that can be parsed
with lex/yacc and describe a tree as the main structure but with other
cross-connections as well.
What do we do with such a machine description? I see three things we
could use it for:
1. Derive a set of config option values (or recommendations for those
values, at least) for including the necessary kernel drivers to
support the devices on the board.
2. Make a list of devices and the information that their drivers will
need about them, such as register base addresses, interrupt
assignments, etc., for inclusion in the kernel.
3. Make such a list for inclusion in a bootloader so that it can
supply it to the kernel, for people who aren't so worried about the
size of their kernels and who want to be able to use the same
kernel binary on several different boards.
The idea of 2 (and 3) is to make it easy for drivers to find out how
many instances of their device exist, and for each instance, the
critical information that the driver needs about it. This could be
implemented in various ways. The simplest would be to have a list in
one place with query functions defined which the drivers would use.
That would be relatively easy to implement but would maybe take up
more bytes than absolutely necessary.
For the situations where every byte is precious, we could get a little
cleverer and have preprocessing code which would scan the driver code
and convert the query function calls into references to an initialized
array, or even into just a constant if there is only one instance of
the device.
This would be needed primarily for on-chip or on-board peripherals
that are not self-describing, i.e. not for PCI devices. We already
have enumeration and query functions for PCI devices.
Paul.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2002-04-01 18:39:41
Paul Mackerras wrote:
I don't particularly like the way we define what is on a given
embedded board with what boils down to a shell script.
Why single out embedded boards?
What I would like to see is a readable, compact, clear description of
the hardware (for a given embedded board) in one place,
One of my peeves is all I have ever done with Linux is embedded boards,
for many years, no one seemed to care what I thought would make it
easier, and recently people that have little experience with them
now seem to want to solve all of the problems in one weekend :-).
I'm all for making it better, but I have yet to see anything that
really does. Everyone has an opinion, few people will ever agree
on the single solution, and all we seem to be doing is swapping
one equally successful (or poor) solution for another. It's different,
but not better.
1. Derive a set of config option values (or recommendations for those
values, at least) for including the necessary kernel drivers to
support the devices on the board.
The interdependencies among the resources on an intergrated processor
often require cooperation among drivers. Oh you could probably remove
a few #ifdefs and replace it with addtional overhead of some generic
function calls. Now, you have moved a few ifdefs into a "common" place,
but along with that you also moved the mental context of the code.
Rather than describing and implementing in the place where I can
understand it (the driver itself), I have to look someplace else and
remember why I am looking there.
2. Make a list of devices and the information that their drivers will
need about them, such as register base addresses, interrupt
assignments, etc., for inclusion in the kernel.
For PowerPC (well, 8xx anyway, I don't know what 4xx looks like these days)
all of this stuff is already defined in a board description configuration
file or in the generic processor files. IMHO, it isn't going to get
any better than this (and it seems sufficient for other processors).
3. Make such a list for inclusion in a bootloader so that it can
supply it to the kernel, for people who aren't so worried about the
size of their kernels and who want to be able to use the same
kernel binary on several different boards.
Bleh.....You have to compile the kernel anyway, why bother complicating
everything by passing information through the bootloader? We have gone
around and around with this "common binary" before. How come once we
decide to go one direction (no common binaries), we now have to expend
energy going the other direction again? Not long ago even you argued
for separate binaries, what happened? (change of business pressure? :-)
The idea of 2 (and 3) is to make it easy for drivers to find out how
many instances of their device exist,
For embedded boards you know this at compile/config time, especially
in a production environment. It only takes a few seconds to rebuild a
kernel these days, so just do it. Lots of this flexibility was nicer
a half dozen years ago when it took an hour to build a kernel.
For the situations where every byte is precious,....
Surprisingly, there are still many systems that care about this, and
I'm still trying to understand how a dynamic and complex boot/driver
interface is going to be better than something well defined at compile
time with a trivial boot interface.
For the situations where every byte is precious, we could get a little
cleverer and have preprocessing code....
Why have all of this complexity? For people that understand these
processors and are actively using them, a few #ifdefs and configuration
scripts work just fine. If you don't understand how the peripherals
interact, share processor resources, and the driver implementations operate,
I don't believe you can guide any configuration tool to the proper
results.
Rather rewrite drivers for the sake of removing some #ifdefs, let's write
a smart configuration tool that understands how to select the proper #ifdefs
and build the kernel. I thought we were headed this way with CML-2?
I would like to make it better, but making sweeping statements about
a "hardware description" that is going to make my life better doesn't cut it.
The devil is in the details, and unless you live those everyday to see
how people are developing software for real products I don't understand
how you can appreciate these suggestions.
I work on lots of processor and projects other than PowerPC, so I get
to see alternatives to what is done here. It's interesting how some of
those better ideas are met with such resistance here, in particular if
I have to modify something related to a workstation platform :-). IMHO,
there are many more important technical challenges to solve than worrying
about replacing some #ifdefs with a complex configuration process.
Thanks.
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Paul Mackerras <hidden> Date: 2002-04-02 05:32:55
Dan Malek writes:
Paul Mackerras wrote:
quoted
I don't particularly like the way we define what is on a given
embedded board with what boils down to a shell script.
Why single out embedded boards?
Two reasons: (a) it seems to be that (for example) most of the if
statements in arch/ppc/config.in are concerned with embedded boards,
and (b) embedded boards seem to have high proportion of devices that
aren't self-describing (by self-describing I mean devices such as PCI
devices where there is a straightforward way of enumerating the
devices and finding out what each device is).
quoted
What I would like to see is a readable, compact, clear description of
the hardware (for a given embedded board) in one place,
One of my peeves is all I have ever done with Linux is embedded boards,
for many years, no one seemed to care what I thought would make it
easier, and recently people that have little experience with them
now seem to want to solve all of the problems in one weekend :-).
So it's no use anyone discussing how to solve the problems?
quoted
1. Derive a set of config option values (or recommendations for those
values, at least) for including the necessary kernel drivers to
support the devices on the board.
The interdependencies among the resources on an intergrated processor
often require cooperation among drivers. Oh you could probably remove
a few #ifdefs and replace it with addtional overhead of some generic
function calls. Now, you have moved a few ifdefs into a "common" place,
No, I don't want to move ifdefs around, I want to get rid of them
altogether. :)
but along with that you also moved the mental context of the code.
Rather than describing and implementing in the place where I can
understand it (the driver itself), I have to look someplace else and
remember why I am looking there.
The information about the register addresses and interrupt assignments
isn't (or shouldn't need to be) part of the mental context of driver
code. Nor should the number of instances of the device.
quoted
2. Make a list of devices and the information that their drivers will
need about them, such as register base addresses, interrupt
assignments, etc., for inclusion in the kernel.
For PowerPC (well, 8xx anyway, I don't know what 4xx looks like these days)
all of this stuff is already defined in a board description configuration
file or in the generic processor files. IMHO, it isn't going to get
any better than this (and it seems sufficient for other processors).
My concern is that the current way of doing things is going to become
increasingly unmanageable as we get more and more chips with different
combinations and permutations of on-board peripherals.
I have this dream that one day we will get to the point where adding
support for a new board only involves adding files to the kernel
tree, with no changes to existing files needed.
quoted
3. Make such a list for inclusion in a bootloader so that it can
supply it to the kernel, for people who aren't so worried about the
size of their kernels and who want to be able to use the same
kernel binary on several different boards.
Bleh.....You have to compile the kernel anyway, why bother complicating
everything by passing information through the bootloader? We have gone
around and around with this "common binary" before. How come once we
decide to go one direction (no common binaries), we now have to expend
energy going the other direction again? Not long ago even you argued
for separate binaries, what happened? (change of business pressure? :-)
I'll assume that was purely a joke.
quoted
For the situations where every byte is precious,....
Surprisingly, there are still many systems that care about this, and
Well one would then wonder why they are using PowerPC, not known for
its code density...
(Just kidding :-)
Paul.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
If you are using the 4xx stuff as an example, I don't really like the
way that is being done, but I'm severely outnumbered in that battle so
I had to retreat and work somewhere else (like MIPS :-). I still
prefer to wait and see how unmanagable it gets before we start reworking
everything. Again, I don't see how using a bootloader to provide
information and adding more software complexity to drivers solves this
problem. If you can't make it work with #define constants and #ifdef
code sections, how will changing a #define with a variable name and
an #ifdef with an if () {} make it eaiser?
What battle would that be?? you're copied on all my changes to 4xx and
if you have a problem with it , you should say so:)
quoted
I have this dream that one day we will get to the point where adding
support for a new board only involves adding files to the kernel
tree, with no changes to existing files needed.
4xx you need 1 config , board.c, board.h and add board.h to ibm4xx.h at
a minimum. The 4xx drivers when conversion to ocp is completed will
make it possible:) Think of ocp as a static or manual pci driver
On Tue, Apr 02, 2002 at 03:32:55PM +1000, Paul Mackerras wrote:
Dan Malek writes:
quoted
Paul Mackerras wrote:
quoted
I don't particularly like the way we define what is on a given
embedded board with what boils down to a shell script.
Why single out embedded boards?
Two reasons: (a) it seems to be that (for example) most of the if
statements in arch/ppc/config.in are concerned with embedded boards,
That's just because pmac hw is so boring and limited. That and pmacs
are designed around an OS which depends on the hardware to describe
itself. That's the main reason it's so easy to do lots of things at
runtime on chrp/pmac, OF even describes the non self-describing devices
for you usually.
quoted
quoted
1. Derive a set of config option values (or recommendations for those
values, at least) for including the necessary kernel drivers to
support the devices on the board.
The interdependencies among the resources on an intergrated processor
often require cooperation among drivers. Oh you could probably remove
a few #ifdefs and replace it with addtional overhead of some generic
function calls. Now, you have moved a few ifdefs into a "common" place,
No, I don't want to move ifdefs around, I want to get rid of them
altogether. :)
Which is either generated code at runtime (which we're doing a bit of
when possible) or runtime, which isn't as desired.
Unless we get the proper symlink magic to do
#include <asm/platform.h>
which will get the right platform from CONFIG_foo. Which would get a
lot more of your 'just adding files' idea.
Nor should the number of instances of the device.
That's a different problem, mainly drivers which weren't initially
designed around multiple instances.
quoted
quoted
2. Make a list of devices and the information that their drivers will
need about them, such as register base addresses, interrupt
assignments, etc., for inclusion in the kernel.
For PowerPC (well, 8xx anyway, I don't know what 4xx looks like these days)
all of this stuff is already defined in a board description configuration
file or in the generic processor files. IMHO, it isn't going to get
any better than this (and it seems sufficient for other processors).
My concern is that the current way of doing things is going to become
increasingly unmanageable as we get more and more chips with different
combinations and permutations of on-board peripherals.
There's some cleanup which needs to be done (asm/commproc.h needs some
cleanups, which Wolfgang did at one point and I will push to 2.5 soon).
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2002-04-02 17:29:55
I'm glad you found _some_ of the humor in it :-)
Paul Mackerras wrote:
Two reasons: (a) it seems to be that (for example) most of the if
statements in arch/ppc/config.in are concerned with embedded boards,
Well, yes, and at one point I tried to create config.in files that were
unique to the boards/peripherals that were just callouts from config.in.
That didn't last long because all of these were incorporated (not by me :-)
into config.in and other places. I thought having these board specific
configuration files was kind of nice, kept arch/ppc/config.in cleaner,
kept the interdependencies localized to a sensible place, but I guess
someone thought different when it got merged from the development tree.
We are always discussing this separation of information and software
among the different platforms. I truly want it separate....everything.
The drivers, the configuration files, anything unique to a board that
isn't "common" across a wide range of platforms and architectures.
So it's no use anyone discussing how to solve the problems?
I guess the "problem" is in the eye of the beholder :-). I don't
see lots of defconfig files or some complexity to config.in, or
a few #ifdefs as a "problem" :-). These discussions become a
problem for me because I spend all of my time discussing why something
is the way it is, and why that isn't necessarily bad, considering
all of the details involved in development of the software. Then,
after I lose the battle, a bunch of code is changed, someone discovers
we don't have anything better than we started, and the "geeze I never
thought of that detail" discussions start so we can crawl out of a
hole. We then start all over again making changes that in the
end just traded one "problem" for another, making little progress
on the quality or features of the software.......In a year or so
I'll bring up this bi_recs discussion again as an example :-)
No, I don't want to move ifdefs around, I want to get rid of them
altogether. :)
I don't understand why that in itself has to be a goal. As we
have more experience with platforms and the use of the software,
these will be change and perhaps go away. I don't know how you
just declare this goal without having a better idea of how the
software can be placed into reusable modules.
The information about the register addresses and interrupt assignments
isn't (or shouldn't need to be) part of the mental context of driver
code. Nor should the number of instances of the device.
As far as I know, the interrupts and registers are fixed at compile
time. The more challenging resources are I/O pin multiplexing and
bus control. Again, taking the 8xx and 8260 as an example (of a well
thought out integrated processor design :-) you have flexibility that
can be wired at compile time, making the drivers much more simplified
(removing #ifdefs). In some cases, there is no way for a bootloader
to know this information (unless it's compiled in there, so why bother)
and there are performance trade offs you can make with these configuration
options (so you are building a kernel anyway).
My concern is that the current way of doing things is going to become
increasingly unmanageable as we get more and more chips with different
combinations and permutations of on-board peripherals.
If you are using the 4xx stuff as an example, I don't really like the
way that is being done, but I'm severely outnumbered in that battle so
I had to retreat and work somewhere else (like MIPS :-). I still
prefer to wait and see how unmanagable it gets before we start reworking
everything. Again, I don't see how using a bootloader to provide
information and adding more software complexity to drivers solves this
problem. If you can't make it work with #define constants and #ifdef
code sections, how will changing a #define with a variable name and
an #ifdef with an if () {} make it eaiser?
I have this dream that one day we will get to the point where adding
support for a new board only involves adding files to the kernel
tree, with no changes to existing files needed.
I pretty much live that dream every day with the 8xx stuff. Give me
a working piece of hardware and with a few file changes I can have
it booting in no time :-)
I'll assume that was purely a joke.
Not all of it :-) I thought we blew off trying to do common binaries
long ago. We try to do common source code as much as possible,
but we had the common binary discussion long ago. I guess I should
read some of the old archives to remember correctly.
Well one would then wonder why they are using PowerPC, not known for
its code density...
(Just kidding :-)
The code density is similar to any other risc processor, and it has
some pretty nice instructions. Quite honestly, Motorola knows how
to get embedded processors done right :-)
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Tue, Apr 02, 2002 at 12:29:55PM -0500, Dan Malek wrote:
I'm glad you found _some_ of the humor in it :-)
Paul Mackerras wrote:
quoted
Two reasons: (a) it seems to be that (for example) most of the if
statements in arch/ppc/config.in are concerned with embedded boards,
Well, yes, and at one point I tried to create config.in files that were
unique to the boards/peripherals that were just callouts from config.in.
That didn't last long because all of these were incorporated (not by me :-)
into config.in and other places. I thought having these board specific
configuration files was kind of nice, kept arch/ppc/config.in cleaner,
kept the interdependencies localized to a sensible place, but I guess
someone thought different when it got merged from the development tree.
It was probably me. One thing I want to do in the 2.5 tree is make
arch/ppc/platforms/{8xx,4xx}.in and source those from
arch/ppc/config.in, as well as move network things to network Config
files, and so on.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2002-04-02 21:02:56
Tom Rini wrote:
It was probably me.
Heh.....I'm just having some fun :-). I also know the reason
you probably changed it was to either make munuconfig or
something work, or had plans for CML-2. I think some of the
confusing stuff we have for configuration is due to the tools
themselves, and that sometimes is reflected in the way the
code (#define and #ifdef) is written.
... One thing I want to do in the 2.5 tree is make
arch/ppc/platforms/{8xx,4xx}.in and source those from
arch/ppc/config.in,
I know that would help. What happened to CML-2?
Thanks.
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Tue, Apr 02, 2002 at 04:02:56PM -0500, Dan Malek wrote:
Tom Rini wrote:
quoted
It was probably me.
Heh.....I'm just having some fun :-).
Ya, I figured :)
I also know the reason
you probably changed it was to either make munuconfig or
something work, or had plans for CML-2. I think some of the
confusing stuff we have for configuration is due to the tools
themselves, and that sometimes is reflected in the way the
code (#define and #ifdef) is written.
Yes, there are some neat things which might be less feasible, or at
least less of a good idea due to the current tools.
quoted
... One thing I want to do in the 2.5 tree is make
arch/ppc/platforms/{8xx,4xx}.in and source those from
arch/ppc/config.in,
I know that would help. What happened to CML-2?
I have a feeling that ESR stopped announcing releases of it on l-k since
it wasn't adopted yet, and Linus has decided to fix more important
things than the config system (and ESR refuses to try and transition
from CML1 to CML2 in a manner that can be easily verified to be correct
or stop trying to tackle the Aunt Tillie problem at the same time).
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/