Re: CONFIG_GENERIC_PPC32

Re: CONFIG_GENERIC_PPC32

[Michael Sokolov]

benh@kernel.crashing.org wrote:

> No, let's fix the brain-damaged serial driver ;)

You mean to support PCMCIA modems in the compiled-in configuration? (It *has*
to be compiled in to support the serial console.) That would be good. Do you
volunteer to fix it in 2.4? 2.5-only is useless.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Michael Sokolov]

Mark A. Greer <mgreer@mvista.com> wrote:

> When you say push "it" are you referring to all of your changes or just the
> CONFIG_GENERIC_PPC32 stuff?

I was referring to CONFIG_GENERIC_PPC32. My GT-64260 and EV-64260A work would
be nice too though. :)

> From what I can tell, it
> looks like you moved much of the init functionality that was in gt64260_common and
> put it into ev64260_pci.c, et. al., and got rid of the "library" routines in
> gt64260_common.

I have replaced gt64260_common.c with gt64260_data.c and gt64260_utils.c so
that one can choose to use the utility functions for non-OF non-StarMON boards
or not use them for good OF/StarMON, but still always have the crucial global
variables.

> IMO, this is a large step backwards.

I disagree.

> The purpose of all the arch/ppc/*_common
> files is to provide a "library" for each bridge.  They aren't perfect and one of
> my TODO item over the next few months is to improve all of them but they provide
> common code that initializes and supports that particular bridge.  Having these
> files have played a large part in making ports to systems with MPC106/107/824x
> chips, for example, much simpler and much faster.  That is the purpose of
> gt64260_common.c but you just deleted it and put that code in a non-reusable,
> board-specific file.

Then fine, keep that library and use it for your ports to your heart's delight.
Just please let HEC ports not use it.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Mark A. Greer]

Michael Sokolov wrote:

> I have replaced gt64260_common.c with gt64260_data.c and gt64260_utils.c so
> that one can choose to use the utility functions for non-OF non-StarMON boards
> or not use them for good OF/StarMON, but still always have the crucial global
> variables.
>
> <snip>
>
> Then fine, keep that library and use it for your ports to your heart's delight.
> Just please let HEC ports not use it.

You never _had_ to use the gt64260_common code if you didn't want to.  Its just a
library of stuff there to be used (but I would expect most if not all boards with a
gt64260 to use many of the functions in it).  If you don't want to, that's fine.

My issue is that your gt64260_utils.c doesn't have a lot of functionality that
_common.c does.

I guess I still don't know what you want.  Do you want your _data.c and _utils.c pushed
too or instead of _common.c?  Either way, why not use the functions that are already in
_common.c instead?  If that functionality isn't there, add it.  If its the size of
gt64260_common.c, then it can be broken up.  I would already like to move the
find_bridges, bridge_init, and check_errata routines into their own file.  Doesn't
reduce the size that much but it splits it up a little so you can not link the .o file
with find_bridges, etc code if you don't want it, for example.

Mark


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Michael Sokolov]

benh@kernel.crashing.org wrote:

> Don't get to conclusions so fast. We have already a whole bunch of new
> machines support pending in _devel that has to be merged, and that will
> happen after 2.4.19. Things aren't fast on a stable kernel, but that's
> the way it should be.

Then why won't you accept my PPCStar port into 2_4_devel?

> Not having it as a module may prevent pcmcia modems from working.

OK, now I see the fundamental conflict of interest. Your machines and mine
can't coexist in the same kernel I guess then because mine can't work with the
serial driver as a module (because it's the system console) and yours can't
work with it compiled in because of PCMCIA. Let's have separate
CONFIG_CHRP_PMAC_PREP and CONFIG_HEC_PPCSTAR then.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[benh]

>> Don't get to conclusions so fast. We have already a whole bunch of new
>> machines support pending in _devel that has to be merged, and that will
>> happen after 2.4.19. Things aren't fast on a stable kernel, but that's
>> the way it should be.
>
>Then why won't you accept my PPCStar port into 2_4_devel?

I didn't say I didn't accept it. Paulus is the one to ultimately decide
about that though, but I understand if he wants to put a hold on new
boards until at least _devel gets merged into 2.4

>> Not having it as a module may prevent pcmcia modems from working.
>
>OK, now I see the fundamental conflict of interest. Your machines and mine
>can't coexist in the same kernel I guess then because mine can't work
with the
>serial driver as a module (because it's the system console) and yours can't
>work with it compiled in because of PCMCIA. Let's have separate
>CONFIG_CHRP_PMAC_PREP and CONFIG_HEC_PPCSTAR then.

No, let's fix the brain-damaged serial driver ;)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Michael Sokolov]

Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> Let's do it first in 2.5, we can backport it once we are satisfied

Bleah. 2.5 == never to me. It doesn't help me with my goal of getting support
for my boards in 2.4. I work on stable kernels and not development ones because
I'm not a Linux developer, I'm just a HW engineer trying to make Linux
(existing stable one) support my boards at least as well as it does those from
my competitors (IBM, Sun, etc).

I guess I'll just have to convince Debian to make a package from
linuxppc_2_4_alt to support HEC PPCStar machines and show all these exchanges
as evidence that the PPC MAINTAINERS are not intent on allowing new machine
support into 2.4 any time soon.

> Well.. you forget pmac here ;)
>
> The problem is that pmac has it's own serial HW with a different driver,
> but still may need serial.o for PCI serial cards or pcmcia modems.

But then a PMac doesn't need anything in rs_table!

If in addition to PMacs a CONFIG_GENERIC_PPC32 kernel supports other machines
with serial consoles, the serial driver must be compiled in. If no machines
other than PMac are selected, you can compile without the serial driver in
there as the PMac port won't care about rs_table and won't call
early_serial_setup. Then if you load it as a module, you'll have no fixed ports
will get all PCI, PCMCIA, etc. ones, which is exactly what you need here.

So I don't see a problem.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Geert Uytterhoeven]

On Thu, 11 Apr 2002, Michael Sokolov wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > Let's do it first in 2.5, we can backport it once we are satisfied
>
> Bleah. 2.5 == never to me. It doesn't help me with my goal of getting support
> for my boards in 2.4. I work on stable kernels and not development ones because
> I'm not a Linux developer, I'm just a HW engineer trying to make Linux
> (existing stable one) support my boards at least as well as it does those from
> my competitors (IBM, Sun, etc).
>
> I guess I'll just have to convince Debian to make a package from
> linuxppc_2_4_alt to support HEC PPCStar machines and show all these exchanges
> as evidence that the PPC MAINTAINERS are not intent on allowing new machine
> support into 2.4 any time soon.

Please note that most probably Marcelo won't accept new machine support into
2.4.x neither, unless it's a backport of 2.5.x and it has proven to be stable.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[benh]

>
>I guess I'll just have to convince Debian to make a package from
>linuxppc_2_4_alt to support HEC PPCStar machines and show all these exchanges
>as evidence that the PPC MAINTAINERS are not intent on allowing new machine
>support into 2.4 any time soon.

Don't get to conclusions so fast. We have already a whole bunch of new
machines support pending in _devel that has to be merged, and that will
happen after 2.4.19. Things aren't fast on a stable kernel, but that's
the way it should be.

>> Well.. you forget pmac here ;)
>>
>> The problem is that pmac has it's own serial HW with a different driver,
>> but still may need serial.o for PCI serial cards or pcmcia modems.
>
>But then a PMac doesn't need anything in rs_table!

But a pmac/prep/chrp kernel may.

>If in addition to PMacs a CONFIG_GENERIC_PPC32 kernel supports other machines
>with serial consoles, the serial driver must be compiled in. If no machines
>other than PMac are selected, you can compile without the serial driver in
>there as the PMac port won't care about rs_table and won't call
>early_serial_setup. Then if you load it as a module, you'll have no fixed
>ports
>will get all PCI, PCMCIA, etc. ones, which is exactly what you need here.
>
>So I don't see a problem.

Not having it as a module may prevent pcmcia modems from working.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Michael Sokolov]

Paul Mackerras <paulus@samba.org> wrote:

> A laudable goal.  I like the idea of having each platform selected
> with a bool rather than just having a single choice of platform.

So how about pushing it into 2_4_devel?

> I also agree about the CONFIG_ALL_PPC name but no-one has ever been
> able to come up with a better name for the PReP/PMac/CHRP combination.

Rather than rename it, eliminate it altogether and replace it with my solution!

> However, there are some aspects of the way you have done your
> CONFIG_GENERIC_PPC32 that I don't like.

So can you promise that if I change those to the way you said you'll accept my
patch into 2_4_devel? Without that there is no incentive for me to do any more
work.

> In particular I don't like
> the list of ifdefs in setup.c.  Whenever that sort of thing appears it
> is a sign that we need to rethink how we do things.  The old
> drivers/net/Space.c was a classic example, and it was a mistake and it
> basically became unmaintainable.  Fortunately we have better ways to
> handle that sort of thing these days.  In particular we can use ELF
> sections in creative ways to make lists of things without having to
> have strings of ifdefs.

I guess I could try to do that with ELF sections, but see above about
incentive.

> The other thing I don't like is the bi_rec changes.  While I like the
> idea of passing in device information in bi_recs, I really don't like
> the use of binary tags for the various specific pieces of information
> that we want to specify for the different devices.  This is ultimately
> once again a maintainability concern.  Using an enumeration like that
> basically forces us into having a central repository for assigning the
> numbers and that is going to get us into problems down the track.
>
> Instead I think that both the names of the pieces of information, and
> the values of things like the device type, should be represented as
> strings.  Using strings just gives us orders of magnitude more
> flexibility and extensibility, and is much more suitable for the sort
> of decentralized and distributed development that we do.

But this is not how bi_recs work. Do you want to break compatibility with the
existing bi_recs, to add a whole new boot info mechanism independent of
bi_recs, or what? And if I am to implement it, I need to be given some kind of
spec as to what to implement.

> About the early_serial_init changes - using early_serial_init is nice
> when the serial driver is built in, but the problem is that when the
> serial driver is a module, we don't get given the opportunity to do
> the early_serial_init calls between when the module is loaded and when
> it runs rs_init.  Otherwise I would have decreed the use of
> early_serial_init some time ago. :)

On all machines I've supported so far one of the system serial ports that are
supported in this manner is the system console and the serial driver therefore
has to be compiled in anyway. I don't see a problem with making a requirement
that the serial driver be compiled in for CONFIG_GENERIC_PPC32. After all, we
are not dealing with a PeeCee where the serial ports are an auxiliary feature,
we are dealing with real computers where the system serial ports are central
system resources like on a VAX.

For other hardware with similar problems but where it's unreasonable to require
compiling the driver in there are other solutions. Look for example what I did
for GT-64260 Ethernet in 2_4_alt. It's much like serial in that there is a
generic driver, the device is fairly peripheral and should be supported as a
module (even though it currently isn't, but never mind), but the driver needs
certain info that has to be provided by the board ports. There I have a table
like rs_table called gt64260_eth_config which itself lives not in the
gt64260_eth driver, but in arch/ppc/kernel/gt64260_data.c. This table is
therefore always present whether the gt64260_eth driver is present or not, and
it is always filled in by <board>_setup_arch. Then when/if the gt64260_eth
driver initializes, whether compiled-in or as a module, it uses the info in
that table that must be in the kernel.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Benjamin Herrenschmidt]

>
>Paul Mackerras <paulus@samba.org> wrote:
>
>> A laudable goal.  I like the idea of having each platform selected
>> with a bool rather than just having a single choice of platform.
>
>So how about pushing it into 2_4_devel?

Let's do it first in 2.5, we can backport it once we are satisfied

>> I also agree about the CONFIG_ALL_PPC name but no-one has ever been
>> able to come up with a better name for the PReP/PMac/CHRP combination.
>
>Rather than rename it, eliminate it altogether and replace it with my
>solution!

Wich is +/- what I'm doing in 2.5 though with some tweaks.

>> However, there are some aspects of the way you have done your
>> CONFIG_GENERIC_PPC32 that I don't like.
>
>So can you promise that if I change those to the way you said you'll
accept my
>patch into 2_4_devel? Without that there is no incentive for me to do
any more
>work.

Don't be in so much hurry ;) And things can be discussed, even with paulus
who is far from beeing a dictator :)

Leave me some time, I hope next week-end, I'll have everything done in
bk 2.5 for pmac/chrp/prep. Then we can see what to do, keep, change,
merge, whatever.

>> In particular I don't like
>> the list of ifdefs in setup.c.  Whenever that sort of thing appears it
>> is a sign that we need to rethink how we do things.  The old
>> drivers/net/Space.c was a classic example, and it was a mistake and it
>> basically became unmaintainable.  Fortunately we have better ways to
>> handle that sort of thing these days.  In particular we can use ELF
>> sections in creative ways to make lists of things without having to
>> have strings of ifdefs.
>
>I guess I could try to do that with ELF sections, but see above about
>incentive.

I'll do ELF sections in 2.5

>> The other thing I don't like is the bi_rec changes.  While I like the
>> idea of passing in device information in bi_recs, I really don't like
>> the use of binary tags for the various specific pieces of information
>> that we want to specify for the different devices.  This is ultimately
>> once again a maintainability concern.  Using an enumeration like that
>> basically forces us into having a central repository for assigning the
>> numbers and that is going to get us into problems down the track.
>>
>> Instead I think that both the names of the pieces of information, and
>> the values of things like the device type, should be represented as
>> strings.  Using strings just gives us orders of magnitude more
>> flexibility and extensibility, and is much more suitable for the sort
>> of decentralized and distributed development that we do.
>
>But this is not how bi_recs work. Do you want to break compatibility with the
>existing bi_recs, to add a whole new boot info mechanism independent of
>bi_recs, or what? And if I am to implement it, I need to be given some
kind of
>spec as to what to implement.

I'll keep bi_rec tags as longs, but I'll add "new" more friendly definitions
using 4 byte ASCII, keeping backward compatibility with older ones is easy.
We can still change that if we really want.

>> About the early_serial_init changes - using early_serial_init is nice
>> when the serial driver is built in, but the problem is that when the
>> serial driver is a module, we don't get given the opportunity to do
>> the early_serial_init calls between when the module is loaded and when
>> it runs rs_init.  Otherwise I would have decreed the use of
>> early_serial_init some time ago. :)
>
>On all machines I've supported so far one of the system serial ports that are
>supported in this manner is the system console and the serial driver
therefore
>has to be compiled in anyway. I don't see a problem with making a requirement
>that the serial driver be compiled in for CONFIG_GENERIC_PPC32. After all, we
>are not dealing with a PeeCee where the serial ports are an auxiliary
feature,
>we are dealing with real computers where the system serial ports are central
>system resources like on a VAX.

Well.. you forget pmac here ;)

The problem is that pmac has it's own serial HW with a different driver,
but still may need serial.o for PCI serial cards or pcmcia modems.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Mark A. Greer]

Michael Sokolov wrote:

> Paul Mackerras <paulus@samba.org> wrote:
>
> > A laudable goal.  I like the idea of having each platform selected
> > with a bool rather than just having a single choice of platform.
>
> So how about pushing it into 2_4_devel?

When you say push "it" are you referring to all of your changes or just the
CONFIG_GENERIC_PPC32 stuff?

If you are including the changes you made to arch/ppc/kernel/gt64269* and
arch/ppc/platforms/ev64260*, then I have some issues.  From what I can tell, it
looks like you moved much of the init functionality that was in gt64260_common and
put it into ev64260_pci.c, et. al., and got rid of the "library" routines in
gt64260_common.

IMO, this is a large step backwards.  The purpose of all the arch/ppc/*_common
files is to provide a "library" for each bridge.  They aren't perfect and one of
my TODO item over the next few months is to improve all of them but they provide
common code that initializes and supports that particular bridge.  Having these
files have played a large part in making ports to systems with MPC106/107/824x
chips, for example, much simpler and much faster.  That is the purpose of
gt64260_common.c but you just deleted it and put that code in a non-reusable,
board-specific file.

Again, this is a separate issue from the common kernel issue and bi_recs.

As far as bi_rec's are concerned, I'm waiting to see what benh produces and then
apply it to the gt/ev code (assuming Ben's patch is accepted).

Mark


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Paul Mackerras]

Michael Sokolov writes:

> > A laudable goal.  I like the idea of having each platform selected
> > with a bool rather than just having a single choice of platform.
>
> So how about pushing it into 2_4_devel?

When I'm happy with the implementation, sure.

> > However, there are some aspects of the way you have done your
> > CONFIG_GENERIC_PPC32 that I don't like.
>
> So can you promise that if I change those to the way you said you'll accept my
> patch into 2_4_devel? Without that there is no incentive for me to do any more
> work.

How can I promise to accept code that I haven't yet seen?  I can (and
do) promise to take a good look at it and seriously consider it,
though.

> > Instead I think that both the names of the pieces of information, and
> > the values of things like the device type, should be represented as
> > strings.  Using strings just gives us orders of magnitude more
> > flexibility and extensibility, and is much more suitable for the sort
> > of decentralized and distributed development that we do.
>
> But this is not how bi_recs work. Do you want to break compatibility with the
> existing bi_recs, to add a whole new boot info mechanism independent of
> bi_recs, or what? And if I am to implement it, I need to be given some kind of
> spec as to what to implement.

I think there are two tenable positions: the first is to have very
simple bi_recs, i.e. basically what we have at the moment, that convey
a small number of global pieces of information about the system.  If
we really need to convey information about individual devices then I
think we want something approaching the OF device tree, which is a
flexible and extensible structure that conveys arbitrary information
about the devices and their relationships very well.  So the second
position is to encode information about devices as a set of
properties, each of which has a string name and a value which is an
array of bytes.  In this case we would probably have one bi_rec per
device.  Ideally we would also have parent/child/sibling pointers for
each device as well.

> On all machines I've supported so far one of the system serial ports that are
> supported in this manner is the system console and the serial driver therefore
> has to be compiled in anyway. I don't see a problem with making a requirement
> that the serial driver be compiled in for CONFIG_GENERIC_PPC32. After all, we
> are not dealing with a PeeCee where the serial ports are an auxiliary feature,
> we are dealing with real computers where the system serial ports are central
> system resources like on a VAX.

Except on a powermac, as Ben has pointed out in another message.

One solution to the problem of the serial driver as a module is to
have the serial.o module have an empty rs_table (so it assumes no
ports when it loads), and then have a ppc_serial module which does
whatever magic is needed to find out about the serial ports on the
system and calls register_serial for each one.

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[benh]

>I think there are two tenable positions: the first is to have very
>simple bi_recs, i.e. basically what we have at the moment, that convey
>a small number of global pieces of information about the system.  If
>we really need to convey information about individual devices then I
>think we want something approaching the OF device tree, which is a
>flexible and extensible structure that conveys arbitrary information
>about the devices and their relationships very well.  So the second
>position is to encode information about devices as a set of
>properties, each of which has a string name and a value which is an
>array of bytes.  In this case we would probably have one bi_rec per
>device.  Ideally we would also have parent/child/sibling pointers for
>each device as well.

I started with something like that, then went back to something a lot
more simple in my experiments here. The fact is that, at least on embedded,
most devices are already self-describing. In a lot of cases, you don't need
any additional informations about a device but what the PCI bus probe already
provides.

Which is why I did my "BI_DEVICE" thing the other way around: Keep the flat
bi_recs, add an arbitrary number of "BI_DEVICE" records, that contain a set
of optional informations for a given device along with whatever is needed
to actually locate this device. The location part has to be more or less
normalized though, at least for known bus types like PCI. This is the role
of the BI_DEV_TYPE and BI_DEV_ID sub-records.

Now, either using names or 4-char-codes for identifying those sub-records
is mostly a matter of taste. I tend to like 4-char-codes as they are more
efficient to process, more compact, more easy to store in flattened out
structures without dealing with pointers, while still very readable, but if
you want to go the string way, then let's do this.

The only case I see for which an actual tree of devices makes sense is the
interrupt routing (and here again, not in all cases, a hell lot of board
can very well cope with a flat interrupt number stored either as a bi_rec
for non-PCI devices or in the PCI interrult line register).

In this case, I beleive nothing prevent us to still use bi_recs. Just define
the proper BI_DEVICE record for a bridge containing the interrupt map.
If the bus type is proprietary enough to make difficult the link betweeen
a device and it's parent bridge, then those devices will need a record with
a tag (a BI_DEV_PARENT_TYPE/DEV_PARENT_ID for example) indicating where the
parent is.

What I find interesting with that bi_rec scheme is that most of it is optional
and any info that is not needed can just be ommited. For example, the generic
PCI code can well read interrupts from PCI_INTERRUPT_LINE and only override it
with bi_rec provided infos if those exist.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Michael Sokolov]

Paul Mackerras <paulus@samba.org> wrote:

> > So how about pushing it into 2_4_devel?
>
> When I'm happy with the implementation, sure.

OK, so let's review that's left to be done in order to get there: eliminate the
per-machine lines from setup.c and replace them with ELF section magic, settle
the bi_recs issue, and serial stuff. Did I miss anything else?

Now the extra bi_recs I've added in 2_4_alt are currently only used by my
GT-64260 stuff, which I see will take its own mortal battle, and just the
CONFIG_GENERIC_PPC32 framework without the GT-64260 stuff can do without them.
So perhaps we could get CONFIG_GENERIC_PPC32 into 2_4_devel just like this,
I'll do the ELF section magic and address the serial concerns below, but
without touching bi_recs at all for now?

> I think there are two tenable positions: the first is to have very
> simple bi_recs, i.e. basically what we have at the moment, that convey
> a small number of global pieces of information about the system.

This is what I prefer.

> If
> we really need to convey information about individual devices then I
> think we want something approaching the OF device tree, which is a
> flexible and extensible structure that conveys arbitrary information
> about the devices and their relationships very well.

Well, since you like OF and you are the Linux/PPC dictator, I think the path of
least resistance to getting HEC machines supported by Linux/PPC would be for me
to construct a real OF device tree and pass it to Linux. Now it would be a lot
easier for me to just pass you a static tree rather than pass you a "PROM"
pointer in R5 for you to call to construct it. Would you accept a patch that
allows the entire OF device tree to be passed to the kernel in a single bi_rec?
I'm not going to rip out the prom_init code, I'll just make it skip over that
if the device tree has been passed in a bi_rec, effectively giving the user two
ways to get the OF device tree. Would that be acceptable for 2_4_devel?

And where can I find a spec for the OF device tree and a few examples?

> One solution to the problem of the serial driver as a module is to
> have the serial.o module have an empty rs_table (so it assumes no
> ports when it loads),

This is exactly what will happen in 2_4_alt if you build the serial driver as a
module for CONFIG_GENERIC_PPC32.

> and then have a ppc_serial module which does
> whatever magic is needed to find out about the serial ports on the
> system and calls register_serial for each one.

How about making it prepchrp_serial instead? I would say that only a few
systems would want that and it shouldn't be imposed on the rest of the PPC
world. PMacs wouldn't need anything in rs_table at all, as they have no
built-in NS16550 serial ports, the ISA serial port definitions currently given
by <asm/serial.h> for CONFIG_ALL_PPC are for PReP and CHRP. And for all the
systems I'm working with the point is moot as the serial driver must be
compiled in for the console. So I think having the serial driver as a module
and having it access hard-wired serial ports would be a very rare need, perhaps
only for PRePs and CHRPs with video consoles. Therefore I would suggest having
such a special module only for those rare cases where it's needed, and letting
the rest not worry about supporting it.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Tom Rini]

On Fri, Apr 12, 2002 at 12:02:19PM -0700, Michael Sokolov wrote:

> So perhaps we could get CONFIG_GENERIC_PPC32 into 2_4_devel just like this,
> I'll do the ELF section magic and address the serial concerns below, but
> without touching bi_recs at all for now?

Since pmac/chrp/prep haven't been ported over to CONFIG_GENERIC_PPC32
what are you planning on moving exactly?   You said the GT-64260 work
would be its own 'moral battle' and you don't 'own' K2 and Adirondack
anymore either remember...

> > One solution to the problem of the serial driver as a module is to
> > have the serial.o module have an empty rs_table (so it assumes no
> > ports when it loads),
>
> This is exactly what will happen in 2_4_alt if you build the serial driver as a
> module for CONFIG_GENERIC_PPC32.
>
> > and then have a ppc_serial module which does
> > whatever magic is needed to find out about the serial ports on the
> > system and calls register_serial for each one.
>
> How about making it prepchrp_serial instead?

If I'm reading this thread right, we would always need to do this since
we would always give the serial driver an empty table (and have a very
terse <asm/serial.h>.

> I would say that only a few
> systems would want that and it shouldn't be imposed on the rest of the PPC
> world. PMacs wouldn't need anything in rs_table at all, as they have no
> built-in NS16550 serial ports, the ISA serial port definitions currently given
> by <asm/serial.h> for CONFIG_ALL_PPC are for PReP and CHRP.

Again, if I'm following Paul correctly, <asm/serial.h> will just setup
the space for things and not have any definitions at all for the ports.

> And for all the
> systems I'm working with the point is moot as the serial driver must be
> compiled in for the console. So I think having the serial driver as a module
> and having it access hard-wired serial ports would be a very rare need, perhaps
> only for PRePs and CHRPs with video consoles. Therefore I would suggest having
> such a special module only for those rare cases where it's needed, and letting
> the rest not worry about supporting it.

I think what we can do is have the code which sets up the serial driver
work both when it's in a module and when it's compiled in.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Michael Sokolov]

Tom Rini <trini@kernel.crashing.org> wrote:

> Since pmac/chrp/prep haven't been ported over to CONFIG_GENERIC_PPC32
> what are you planning on moving exactly?

I was planning to convert CHRP, PMac, and PReP to CONFIG_GENERIC_PPC32 in
2_4_alt (blindly as I have no hardware to test on, just make it compile), then
find some volunteers with the hardware to test the new 2_4_alt, and if it works
make a patch for Paulus.

> You said the GT-64260 work
> would be its own 'moral battle'

Mortal, not moral.

> and you don't 'own' K2 and Adirondack
> anymore either remember...

I'm not going to touch K2 outside of 2_4_alt. I would say Adirondack can be
moved to CONFIG_GENERIC_PPC32 as owned or not, the port currently in 2_4_devel
does not support any ROM other than StarMON anyway. But I really don't care,
I've got it in 2_4_alt to prove my generic config framework, and I couldn't
care less what happens to the SBS ports in the public tree as I have no loyalty
to them any more.

> If I'm reading this thread right, we would always need to do this since
> we would always give the serial driver an empty table (and have a very
> terse <asm/serial.h>.

We would only need a special ppc_serial module when the serial driver is a
module and the machine has hard-wired serial ports. This would be a rare case,
on most machines with hard-wired serial ports one of them is the console and
the serial driver must be compiled in. Those board ports will simply call
early_serial_setup() from <board>_arch_setup as I currently do in 2_4_alt.

> Again, if I'm following Paul correctly, <asm/serial.h> will just setup
> the space for things and not have any definitions at all for the ports.

Which is exactly what I have in 2_4_alt right now.

> I think what we can do is have the code which sets up the serial driver
> work both when it's in a module and when it's compiled in.

Yes, sort of. When you see the implementation you'll see what I mean.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Tom Rini]

On Mon, Apr 15, 2002 at 11:08:31AM -0700, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > Since pmac/chrp/prep haven't been ported over to CONFIG_GENERIC_PPC32
> > what are you planning on moving exactly?
>
> I was planning to convert CHRP, PMac, and PReP to CONFIG_GENERIC_PPC32 in
> 2_4_alt (blindly as I have no hardware to test on, just make it compile), then
> find some volunteers with the hardware to test the new 2_4_alt, and if it works
> make a patch for Paulus.

Why not let Ben do it in 2.5 like he said?

> > You said the GT-64260 work
> > would be its own 'moral battle'
>
> Mortal, not moral.

Sorry, not yet awake enough I guess.

Yes, and serial as a module doesn't quite work on GENERIC32 either. :)

> > I think what we can do is have the code which sets up the serial driver
> > work both when it's in a module and when it's compiled in.
>
> Yes, sort of. When you see the implementation you'll see what I mean.

No 'sort-of' about it.  x_init() calls x_serial_init and sets
ppc_md.serial_fixups to x_serial_init.  x_serial_init takes care of
early_serial_setup() and early_init or so calls ppc_md.serial_fixups (if
existant).  'ppc_serial' (built if SERIAL=m) just calls
ppc_md.serial_fixups (or setup, or whatever).

Or we do it even more generic than that so that we can add in a hook for
all ports to use for using serial as a module & early_serial_setup.
(arch_serial_init or somrething?)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Michael Sokolov]

Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

>  - bi_recs are found in r4 when r3 contains "birc" (please, Michael, adapt
>    to this so we stay consistent which what BootX does). Older way of finding
>    them & cmdline & initrd still used when r3 doesn't contain that magic
>    value. r5 still contains the OF PROM pointer, at least until we have
>    the OF interface in a wrapper.

Let's have Paul rule on what the register interface should be. I'll go with
whatever interface is finalized. I've given up on having an external bootloader
boot vmlinux, as although I think ideally that's the RTTD and there are no
technical obstacles, you guys just can't agree on the vmlinux boot ABI and that
makes the point moot. I now have an arch/ppc/boot/ppcstar wrapper in each tree
that I work in which conforms to whatever vmlinux boot ABI that tree uses.

(This doesn't mean that having such wrapper is the RTTD or that the vmlinux
boot ABI inherently has to change all the time. It is perfectly possible
technically to fix the vmlinux boot ABI, keep it stable, and eliminate all
those wrappers. But that would require a revolution to oust the current tyrants
with a strangehold on write access to the mainline tree and let people with
more progressive minds in.)

> I don't plan to include Michael boards in it, I want to rework
> our ground to match what Michael does and then let him drop in his new
> boards.

I don't have my own boards yet. In my tree I used the Adirondack, EV-64260A,
and K2 ports to prove the CONFIG_GENERIC_PPC32 implementation. EV-64260A is
Galileo's reference board for the GT-64260A system controller, and Adirondack
and K2 are SBS boards already supported in 2_4_devel. I'm not at SBS any more
and don't have their hardware, but those boards are still fresh in my head and
I needed a few ports to prove my generic PPC32 implementation.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Benjamin Herrenschmidt]

>(This doesn't mean that having such wrapper is the RTTD or that the vmlinux
>boot ABI inherently has to change all the time. It is perfectly possible
>technically to fix the vmlinux boot ABI, keep it stable, and eliminate all
>those wrappers. But that would require a revolution to oust the current
>tyrants
>with a strangehold on write access to the mainline tree and let people with
>more progressive minds in.)

heh, well, I for one thinks the PPC tree hasn't a strong enough tyrant ;)

>> I don't plan to include Michael boards in it, I want to rework
>> our ground to match what Michael does and then let him drop in his new
>> boards.
>
>I don't have my own boards yet. In my tree I used the Adirondack, EV-64260A,
>and K2 ports to prove the CONFIG_GENERIC_PPC32 implementation. EV-64260A is
>Galileo's reference board for the GT-64260A system controller, and Adirondack
>and K2 are SBS boards already supported in 2_4_devel. I'm not at SBS any more
>and don't have their hardware, but those boards are still fresh in my
head and
>I needed a few ports to prove my generic PPC32 implementation.

Ok.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Michael Sokolov]

Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> I haven't look at the patch yet, but is my understanding correct that
> you have individual config options enabling the various board support
> and that you allow more than one to be selected at one time ?

Yes.

> If that is the case, then that's great. It's also what the arm ach does
> and I like it.

Good.

> Great ! Looks like you have more time than I do to spend on this.

It's just that I have a much greater need for it than you do. You guys using
PMacs can live with what you've got now, but I'm trying to make my own PPC
boards and I have to make mainline Linux support them in order to sell them,
so...

> I'll
> look at your patch and eventually get it merged asap.

Thanks!

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Benjamin Herrenschmidt]

>> I haven't look at the patch yet, but is my understanding correct that
>> you have individual config options enabling the various board support
>> and that you allow more than one to be selected at one time ?
>
>Yes.
>
>> If that is the case, then that's great. It's also what the arm ach does
>> and I like it.

Hi Paul !

I've looked at the patch in the meantime and it makes much sense. I want
to do something around those lines:

 - Completely rip off CONFIG_ALL_PPC in favor of CONFIG_GENERIC_PPC32
 - Each board model has it's own CONFIG_xxx entry (like Michael patch),
   which means adding "back" CONFIG_PMAC, CONFIG_CHRP, CONFIG_PREP, but
   those will only control which set of .c file will get in the makefile
   and the toplevel switch/case on platform_init. That is you will be able
   to select an arbitrary set of boards.
 - bi_recs are found in r4 when r3 contains "birc" (please, Michael, adapt
   to this so we stay consistent which what BootX does). Older way of finding
   them & cmdline & initrd still used when r3 doesn't contain that magic
   value. r5 still contains the OF PROM pointer, at least until we have
   the OF interface in a wrapper.

I think this patch will not be that invasive, and it will be fully backward
compatible, so I do intend to push it to _2_4_devel though I want your
ack first. I don't plan to include Michael boards in it, I want to rework
our ground to match what Michael does and then let him drop in his new
boards.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Geert Uytterhoeven]

On Sat, 6 Apr 2002, Benjamin Herrenschmidt wrote:
> I've looked at the patch in the meantime and it makes much sense. I want
> to do something around those lines:
>
>  - Completely rip off CONFIG_ALL_PPC in favor of CONFIG_GENERIC_PPC32
>  - Each board model has it's own CONFIG_xxx entry (like Michael patch),
>    which means adding "back" CONFIG_PMAC, CONFIG_CHRP, CONFIG_PREP, but
>    those will only control which set of .c file will get in the makefile
>    and the toplevel switch/case on platform_init. That is you will be able
>    to select an arbitrary set of boards.

Good, starts to look like m68k again, where you always were able to compile a
generic kernel (except for Sun-3 (not 3x) due to the different MMU)!
Now start moving platform specific files to arch/ppc/$platform/ again. Dan is
right, we're running in circles :-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Benjamin Herrenschmidt]

>On Sat, 6 Apr 2002, Benjamin Herrenschmidt wrote:
>> I've looked at the patch in the meantime and it makes much sense. I want
>> to do something around those lines:
>>
>>  - Completely rip off CONFIG_ALL_PPC in favor of CONFIG_GENERIC_PPC32
>>  - Each board model has it's own CONFIG_xxx entry (like Michael patch),
>>    which means adding "back" CONFIG_PMAC, CONFIG_CHRP, CONFIG_PREP, but
>>    those will only control which set of .c file will get in the makefile
>>    and the toplevel switch/case on platform_init. That is you will be able
>>    to select an arbitrary set of boards.
>
>Good, starts to look like m68k again, where you always were able to compile a
>generic kernel (except for Sun-3 (not 3x) due to the different MMU)!
>Now start moving platform specific files to arch/ppc/$platform/ again. Dan is
>right, we're running in circles :-)

No, we aren't ;)

In some way, all those new board brought us back to the pre-CONFIG_ALL_PPC
days since they all have their own config option and can't live in a
generic kernel. Mostly for no reason except maybe detecting the board
at boot time (which can be done in the wrapper now if there is no other
way).

The other way, iirc, making the generic (CONFIG_ALL_PPC) kernel from
split pmac/chrp/prep was necessary to get the non-platform specific code
really non-platform specific (at that time, we had the "common" irq, pci
etc... code diff'ing between platforms or #ifdef'ed in places).

So we aren't circling here. We are slowly moving toward an arch where the
common code is really common and no crippled with platform ifdefs, and
a platform is just a set of functions behind ppc_md along with appropriate
drivers beeing in the Makefile. It's a logical step to do the (few) Makefile
and Config.in work to make those individual platforms be selectable
in arbitrary sets.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Michael Schmitz]

On Sun, 7 Apr 2002, Geert Uytterhoeven wrote:
> >  - Completely rip off CONFIG_ALL_PPC in favor of CONFIG_GENERIC_PPC32
> >  - Each board model has it's own CONFIG_xxx entry (like Michael patch),
> >    which means adding "back" CONFIG_PMAC, CONFIG_CHRP, CONFIG_PREP, but
> >    those will only control which set of .c file will get in the makefile
> >    and the toplevel switch/case on platform_init. That is you will be able
> >    to select an arbitrary set of boards.
>
> Good, starts to look like m68k again, where you always were able to compile a
> generic kernel (except for Sun-3 (not 3x) due to the different MMU)!
> Now start moving platform specific files to arch/ppc/$platform/ again. Dan is
> right, we're running in circles :-)

Good spotting, Waldorf! :-)

ROTFL,

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

CONFIG_GENERIC_PPC32

[Michael Sokolov]

: ChangeSet
:   1.925 02/04/05 23:09:25 msokolov@helium.harhan.org +60 -0
:   Add generic PPC32 config, implemented for Adirondack, EV-64260A, and K2
:   New GT-64260 support implementation under CONFIG_GENERIC_PPC32
:   bi_recs enhancements (persistent, nested, searchable, GT-64260 support)
:   PPCStar zImage support under CONFIG_GENERIC_PPC32
:   Many small enhancements along the way

Some commentary is in order on this cset. I strongly recommend that Paulus,
people interested in bi_recs enhancements, and people interested in GT-64260
support check it out and give it a good look.

For Paulus: Remember the discussions a while ago about CONFIG_ALL_PPC not
really being all PPC and the need to either change it or remove it or somehow
get it straight? Well, this cset does it. I've created CONFIG_GENERIC_PPC32 as
an alternative to the current very misnamed CONFIG_ALL_PPC. Unlike the latter,
it actually can support all standard non-embedded PPC ports in the current
tree. It is a single configuration vmlinux that relies on a list of bi_recs to
be passed to it to tell it what it's running on: the _machine value passed via
BI_MACHTYPE and other info if necessary. The minimal platform_init parses the
bi_recs (pointed to by R3) and dispatches to the init routine for the platform
selected by BI_MACHTYPE. Any number of platforms can be included in the
configuration. Each is selected with a bool in config.in so the user can
include only the platform(s) that s/he needs, while distribution makers can
ship one kernel for the world.

The platforms I've initially included in this new model are Adirondack,
EV-64260A, and K2. Other non-CONFIG_ALL_PPC 6xx/7xx/74xx boards in the current
2_4_devel can be easily added given someone knowledgeable about that board.
(Some may require an #ifdef-ectomy.) And finally, the CHRP, PMac, and PReP
ports can also be converted to CONFIG_GENERIC_PPC32 by someone who knows more
about them than I do and has hardware to test on. (And perhaps the PReP port
could then be just like, say, the K2 port and the CHRP and PMac ones combined
into a single OF port as I've heard suggestions.) That would allow the current
CONFIG_ALL_PPC morass to be laid to rest and replaced with a true all PPC
configuration.

There is no extra overhead in the kernel for CONFIG_GENERIC_PPC32. A
CONFIG_GENERIC_PPC32 configuration with only one port selected is no different
from any of current castle-walled board ports in 2_4_devel. The only price to
pay for CONFIG_GENERIC_PPC32 is in the boot mechanism. One has to either boot
vmlinux directly with a bootloader that can generate all the needed bi_recs
including BI_MACHTYPE, have a zImage wrapper that can sense the machine type,
or have make zImage create a bunch of zImages for different ports and/or
bootloaders as done currently for CONFIG_ALL_PPC where make zImage gives you 3
zImages for chrp, pmac, and prep. However, the arch/ppc/boot/simple way of
doing things that the MVistities seem to love so much is fundamentally
incompatible with this.

In what I have right now make zImage for CONFIG_GENERIC_PPC32 makes a ppcstar
zImage wrapper for PPCStar systems, which can identify which PPCStar system
it's running on (per the PPCStar spec) and select the right port in vmlinux
with BI_MACHTYPE. (Adirondack, EV-64260A, and K2 are PPCStar systems when
fitted with StarMON ROMs that are available for them.) If the CHRP, PMac, and
PReP are integrated into CONFIG_GENERIC_PPC32 the chrp, pmac, and prep
subdirectories of arch/ppc/boot can be easily added to the CONFIG_GENERIC_PPC32
line in arch/ppc/boot, giving you 4 zImages made on one make zImage: chrp,
pmac, ppstar, and prep.

The problem is what to do about all the other board ports I envision people
adding, each having its own unique boot mechanism requiring its own zImage. In
that case I don't see much choice other than extending the chrp/pmac/prep 3
zImages model to N zImages for all those platform-unique booters. This will be
an encouragement to board makers to use standardized firmware like OF, StarMON,
or PPCBoot rather than roll a board-unique one: use something standard and you
can use one of existing zImages, or roll your own and be prepared to convince
people to accept adding yet another zImage. OTOH, it seems like a lot of boards
ship without any usable firmware at all and anyone wanting to run Linux has to
reach for the PROM burner anyway. For those we can simply tell people to use
StarMON or PPCBoot to run the new generic PPC Linux.

On to bi_recs. I have implemented the persistent, nested, and searchable
bi_recs which were the consensus of a recent hot discussion on this list
coached by Mark Greer. It works and is fully backward-compatible with the
bi_recs in the current 2_4_devel, check it out. While I was at it, I converted
the handling of BI_MEMSIZE to the new way. Right now in 2_4_devel it is
detected in the initial parsing and the value is saved in a global var that the
generic kernel code doesn't use. Instead, the latter calls
ppc_md.find_end_of_memory() to get the memory size, and ports wishing to use
BI_MEMSIZE provide a boilerplate routine consisting of return(boot_mem_size).
With the new persistent and searchable bi_recs the better way is obvious:
remove the boot_mem_size global var, have a routine that searches the
BI_MEMSIZE, and returns it. Ports wishing to use BI_MEMSIZE simply point
ppc_md.find_end_of_memory at this routine instead of each including the same
old boilerplate. It's implemented in my patch. I've also added all the bi_recs
in Mark's patch plus BI_CPU_BUS_SPEED and BI_CPU_CORE_SPEED.

On to GT-64260. I've rewritten the GT-64260 support code from scratch only
selectively taking bits from the old one, as opposed to taking the old one and
selectively modifying it. The old gt64260_common.c etc. files are bk rm'ed in
my tree. My new implementation is fully integrated into CONFIG_GENERIC_PPC32. A
single configuration can support a single GT-based port, multiple different
ones, or a mixture of GT-based and other ports. IOW, it's done right. The GT-
specific bi_recs are exactly as hashed out by Mark, just implemented right. The
only port is my tree for GT-64260 right now is my reference EV-64260A port.
Again it's written from scratch selectively taking a few old bits. It's not the
same as my old EV-64260-SBS and EV-64260-MS ports which were intended for my
own use only, this one is for public consumption. I only have a zImage wrapper
for PPCStar, but the actual port in vmlinux is designed to work with any sane
boot ROM, although I have nothing to test it on except StarMON. I encourage
PPCBoot folks to try it, since you say you boot vmlinux directly, it should
work for you, just give it the bi_recs it needs.

Have fun!

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Benjamin Herrenschmidt]

>
>: ChangeSet
>:   1.925 02/04/05 23:09:25 msokolov@helium.harhan.org +60 -0
>:   Add generic PPC32 config, implemented for Adirondack, EV-64260A, and K2
>:   New GT-64260 support implementation under CONFIG_GENERIC_PPC32
>:   bi_recs enhancements (persistent, nested, searchable, GT-64260 support)
>:   PPCStar zImage support under CONFIG_GENERIC_PPC32
>:   Many small enhancements along the way
>
>Some commentary is in order on this cset. I strongly recommend that Paulus,
>people interested in bi_recs enhancements, and people interested in GT-64260
>support check it out and give it a good look.
>
> .../...

I haven't look at the patch yet, but is my understanding correct that
you have individual config options enabling the various board support
and that you allow more than one to be selected at one time ?

If that is the case, then that's great. It's also what the arm ach does
and I like it.

>On to bi_recs. I have implemented the persistent, nested, and searchable
>bi_recs which were the consensus of a recent hot discussion on this list
>coached by Mark Greer. It works and is fully backward-compatible with the
>bi_recs in the current 2_4_devel, check it out. While I was at it, I
converted
>the handling of BI_MEMSIZE to the new way. Right now in 2_4_devel it is
>detected in the initial parsing and the value is saved in a global var
>that the

Great ! Looks like you have more time than I do to spend on this. I'll
look at your patch and eventually get it merged asap.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Tom Rini]

On Sat, Apr 06, 2002 at 12:23:17PM -0800, Michael Sokolov wrote:

> The platforms I've initially included in this new model are Adirondack,
> EV-64260A, and K2.

Just checking, but right now these are only supported with StarMON and
not necessarily their shipping ROMs, right? :)

> Other non-CONFIG_ALL_PPC 6xx/7xx/74xx boards in the current
> 2_4_devel can be easily added given someone knowledgeable about that board.
> (Some may require an #ifdef-ectomy.)

I'm sure it's unintentional, but it looks more like it'd be changing
platform_init to x_init, and serial fixes rather than changing #ifdefs.

>(And perhaps the PReP port
> could then be just like, say, the K2 port and the CHRP and PMac ones combined
> into a single OF port as I've heard suggestions.)

... And then the pplus stuff ripped out of the 'PReP' support and
CONFIG_PPLUS converted too.  Before we get too far along, I should say I
actually do like this idea.

> There is no extra overhead in the kernel for CONFIG_GENERIC_PPC32. A
> CONFIG_GENERIC_PPC32 configuration with only one port selected is no different
> from any of current castle-walled board ports in 2_4_devel.

Aside from some ugliness added back to the code (see my other email).

One other problem is that in case anyone forgot, back when we used to
always define a new _MACH type, we had actually ran out (or got w/in 3
or so) so we might want to think of changing the values in 2.5 to
something that can scale better, if we're going to do this.

> ... have a zImage wrapper that can sense the machine type,
> or have make zImage create a bunch of zImages for different ports

Well, in the case of most firmwares, this is what would be done.

> and/or
> bootloaders as done currently for CONFIG_ALL_PPC where make zImage gives you 3
> zImages for chrp, pmac, and prep.

It's worth noting why these are done as they are, since I'm not sure you
quite see why.  pmac and chrp fall into the same category as ppcstar,
which is 'We know the firmware, it can be useful, and we will use it'.
prep is more along the lines of 'Nothing useful here, but we've been
loaded, go go go!'.  The 'simple' stuff is 95% prep, but with the legacy
prep workarounds removed.  Also, pmac at least spits out 3 or 4 images
as it is.

> However, the arch/ppc/boot/simple way of
> doing things that the MVistities seem to love so much is fundamentally
> incompatible with this.

I'm sure there was no slight intended there, but the reason we 'love it
so' is that it just works.  If you've got a firmware which can load an
ELF image, that just works, barring HW/Firmware deficiencies/issues [1].
If you didn't have the option of replacing a firmware, I'd bet you'd end
up using it too :)

But anyhow, it's actually not incompatible with this.  I've gone and
looked at this abit, and it'd be a matter of re-writing the Makefile a
bit (obj-$(...) and XXX_OBJS -> platform.o, rm -f'ed after each zImage,
and then a -DMACH_TYPE=_MACH_xxx for one of the files..).

> The problem is what to do about all the other board ports I envision people
> adding, each having its own unique boot mechanism requiring its own zImage. In
> that case I don't see much choice other than extending the chrp/pmac/prep 3
> zImages model to N zImages for all those platform-unique booters.

Well, since 'simple' will still work, this is a non-issue once again.

> This will be
> an encouragement to board makers to use standardized firmware like OF,
> StarMON, or PPCBoot rather than roll a board-unique one: use something
> standard and you can use one of existing zImages, or roll your own and
> be prepared to convince people to accept adding yet another zImage.

Or use a firmware which can load an ELF image (pmon, yes?) or fake it
(IIRC, the embeddedplantet 8xx firmware doesn't quite do ELF, but it
does seem to recognize the header and skip it, if you don't strip it
off).

> OTOH, it seems like a lot of boards
> ship without any usable firmware at all and anyone wanting to run Linux has to
> reach for the PROM burner anyway. For those we can simply tell people to use
> StarMON or PPCBoot to run the new generic PPC Linux.

<joke>
Personally, I think some people spend too much time in the firmware and
not enough time actually in linux.
</joke>

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

[1]:  Take a look at what Matt did for 440 work.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Gabriel Paubert]

On Mon, 8 Apr 2002, Tom Rini wrote:

> ... And then the pplus stuff ripped out of the 'PReP' support and
> CONFIG_PPLUS converted too.  Before we get too far along, I should say I
> actually do like this idea.

Actually, why does CONFIG_PPLUS even exist? They are basically PreP with
an OpenPIC and slightly different (in some cases) MMIO and I/O mapping,

(Side note: on my MVME2xxx boards which are set in PreP mode by the
firmware, I reinitialize the bridge to be CHRP like, just because I need
larger MMIO area for VME but 1Gb of I/O space is overkill).

> It's worth noting why these are done as they are, since I'm not sure you
> quite see why.  pmac and chrp fall into the same category as ppcstar,
> which is 'We know the firmware, it can be useful, and we will use it'.
> prep is more along the lines of 'Nothing useful here, but we've been
> loaded, go go go!'.  The 'simple' stuff is 95% prep, but with the legacy
> prep workarounds removed.  Also, pmac at least spits out 3 or 4 images
> as it is.

Actually, PreP residual data can be useful, if you kow how to interpret it
to find interrupt routing for example.

	Gabriel.
	(Who should have properly submitted his PrePboot code 3 years ago)


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Tom Rini]

On Mon, Apr 08, 2002 at 06:03:28PM +0200, Gabriel Paubert wrote:
>
>
> On Mon, 8 Apr 2002, Tom Rini wrote:
>
> > ... And then the pplus stuff ripped out of the 'PReP' support and
> > CONFIG_PPLUS converted too.  Before we get too far along, I should say I
> > actually do like this idea.
>
> Actually, why does CONFIG_PPLUS even exist?

It's my understanding that since they're PReP + bits, it's cleaner to
support them seperatly than in the big prep mess.  It's also easier to
get all of the HW bits working.  But maybe Matt Porter will speak up. :)

> > It's worth noting why these are done as they are, since I'm not sure you
> > quite see why.  pmac and chrp fall into the same category as ppcstar,
> > which is 'We know the firmware, it can be useful, and we will use it'.
> > prep is more along the lines of 'Nothing useful here, but we've been
> > loaded, go go go!'.  The 'simple' stuff is 95% prep, but with the legacy
> > prep workarounds removed.  Also, pmac at least spits out 3 or 4 images
> > as it is.
>
> Actually, PreP residual data can be useful, if you kow how to interpret it
> to find interrupt routing for example.

Well, after talking with Hollis, IBM Residual data _has to be_ good,
since AIX or so relies on it.  But from talking to Cort a few times, he
never could trust it on either IBM or Motorola boxes.

> (Who should have properly submitted his PrePboot code 3 years ago)

Yes.  Willing to dig it up again and try and get it going for 2.5? :)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Gabriel Paubert]

On Mon, 8 Apr 2002, Tom Rini wrote:

> It's my understanding that since they're PReP + bits, it's cleaner to
> support them seperatly than in the big prep mess.  It's also easier to
> get all of the HW bits working.  But maybe Matt Porter will speak up. :)

Well, when the bits outside of initdata/initcode can be reduced to only
a different iobase, it seems overkill. And even the other bits can be
extremely tiny and mostly pushed to the bootloader. Maybe I've forgotten
something, since I've got machines running in production for about 3 years
and hardly touched anything since then.

> > Actually, PreP residual data can be useful, if you kow how to interpret it
> > to find interrupt routing for example.
>
> Well, after talking with Hollis, IBM Residual data _has to be_ good,
> since AIX or so relies on it.  But from talking to Cort a few times, he
> never could trust it on either IBM or Motorola boxes.

Well, his code to find interrupt routing was obvisouly buggy to start
with: interrupt routing is a bridge property in residual data, not a
device property (and it is the right thing to do when you think about hot
plugging).

Some minor items are wrong in MVME2xxx residual data, but the interrupt
routing for the second Ethernet or SCSI (can't remember which right now)
on MVME3600, which are not in the kernel tables, were correctly found by
my code (from the reports I got since I don't have the hardware).

>
> > (Who should have properly submitted his PrePboot code 3 years ago)
>
> Yes.  Willing to dig it up again and try and get it going for 2.5? :)

Hmm, it booted at least until 2.4.0 (early 2001), but I am very busy on
other things right now (some software, but mostly microwave, analog
electronics up to 18 GHz is so fun!) and I was waiting for at least the
new kbuild to appear in the official trees: if it holds up to its
promises, it will make life much simpler.

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Matt Porter]

On Mon, Apr 08, 2002 at 06:48:04PM +0200, Gabriel Paubert wrote:
>
> On Mon, 8 Apr 2002, Tom Rini wrote:
>
> > It's my understanding that since they're PReP + bits, it's cleaner to
> > support them seperatly than in the big prep mess.  It's also easier to
> > get all of the HW bits working.  But maybe Matt Porter will speak up. :)

Ok, Ok.

> Well, when the bits outside of initdata/initcode can be reduced to only
> a different iobase, it seems overkill. And even the other bits can be
> extremely tiny and mostly pushed to the bootloader. Maybe I've forgotten
> something, since I've got machines running in production for about 3 years
> and hardly touched anything since then.
>
> > > Actually, PreP residual data can be useful, if you kow how to interpret it
> > > to find interrupt routing for example.

Most of the MCG's residual data are so incorrect that you spend more time
fixing stuff up than using this "wonderful" source of board info. I had
an opportunity to examine all of them in detail at my previous employer
to realize that it's mostly useless to use it.

Couple that with the constant breakage of a numer of the boards by all
the tweaks to real legacy PReP workstations.

The CONFIG_PPLUS port made the code clean, neat, and maintainable.

Because the CONFIG_PPLUS port doesn't rely on residual data, the
ability to create a "ROMboot" image is simplified to the point that
it is generated in the kernel instead of an 18 step process involving
dumping a copy of residual data that was only being used to get
the memory size.  Retrieving memory size from the memory controller
configuration already had been done for other MCG boards with
inaccurate residual data info.

The firmware group at MCG will _never_ fix the residual data since
their AIX doesn't use it.  Even when they had some decent staff
on hand they weren't willing to fix anything related to residual
data.  Now, they've laid off just about everybody so it's guaranteed
to never happen.

CONFIG_PPLUS also made it easy to add pci_auto support since putting
it in PReP would have been a complete mess...

> > > (Who should have properly submitted his PrePboot code 3 years ago)

Yeah, you even had a sorting autoconfiguration algorithm in prepboot,
IIRC.

> > Yes.  Willing to dig it up again and try and get it going for 2.5? :)
>
> Hmm, it booted at least until 2.4.0 (early 2001), but I am very busy on
> other things right now (some software, but mostly microwave, analog
> electronics up to 18 GHz is so fun!) and I was waiting for at least the
> new kbuild to appear in the official trees: if it holds up to its
> promises, it will make life much simpler.

This makes me miss application work. :-/

--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Gabriel Paubert]

On Mon, 8 Apr 2002, Matt Porter wrote:

> Most of the MCG's residual data are so incorrect that you spend more time
> fixing stuff up than using this "wonderful" source of board info. I had
> an opportunity to examine all of them in detail at my previous employer
> to realize that it's mostly useless to use it.

I did not find so many bugs myself on MVME2400 and 2600. Actually I found
them mostly correct in my case...

>
> Couple that with the constant breakage of a numer of the boards by all
> the tweaks to real legacy PReP workstations.
>
> The CONFIG_PPLUS port made the code clean, neat, and maintainable.

Never enabled it for my boards until now, but I'm not interested at all in
having a ROMBoot image either. Almost all my boards used dhcp/bootp, the
other ones have a disk...

> Because the CONFIG_PPLUS port doesn't rely on residual data, the
> ability to create a "ROMboot" image is simplified to the point that
> it is generated in the kernel instead of an 18 step process involving
> dumping a copy of residual data that was only being used to get
> the memory size.  Retrieving memory size from the memory controller
> configuration already had been done for other MCG boards with
> inaccurate residual data info.

Do the kernel tables have the right interrupt routing for MVME3600 with
secondary Ethernet/SCSI for example ?

>
> The firmware group at MCG will _never_ fix the residual data since
> their AIX doesn't use it.  Even when they had some decent staff
> on hand they weren't willing to fix anything related to residual
> data.  Now, they've laid off just about everybody so it's guaranteed
> to never happen.
>
> CONFIG_PPLUS also made it easy to add pci_auto support since putting
> it in PReP would have been a complete mess...
>
> > > > (Who should have properly submitted his PrePboot code 3 years ago)
>
> Yeah, you even had a sorting autoconfiguration algorithm in prepboot,
> IIRC.

Indeed, can you think of any other solution when you reprogram the whole
PCI<->PPCbus maps of the chipset ?

The only problem is that it probably does not work with PCI<->PCI bridges
since I never had the hardware to test (I believe I even never implemented
that part, or scrapped after a brief attempt).

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Matt Porter]

On Mon, Apr 08, 2002 at 07:37:13PM +0200, Gabriel Paubert wrote:
>
>
> On Mon, 8 Apr 2002, Matt Porter wrote:
>
> > Most of the MCG's residual data are so incorrect that you spend more time
> > fixing stuff up than using this "wonderful" source of board info. I had
> > an opportunity to examine all of them in detail at my previous employer
> > to realize that it's mostly useless to use it.
>
> I did not find so many bugs myself on MVME2400 and 2600. Actually I found
> them mostly correct in my case...

The cPCI boards are especially bad as well as the 2300sc.

> > Couple that with the constant breakage of a numer of the boards by all
> > the tweaks to real legacy PReP workstations.
> >
> > The CONFIG_PPLUS port made the code clean, neat, and maintainable.
>
> Never enabled it for my boards until now, but I'm not interested at all in
> having a ROMBoot image either. Almost all my boards used dhcp/bootp, the
> other ones have a disk...

Yeah, I figured that's not what everybody wants but it is a popular
deployment option given the feedback I got on my original kludge
that was the standalone "bugboot" package.

> > Because the CONFIG_PPLUS port doesn't rely on residual data, the
> > ability to create a "ROMboot" image is simplified to the point that
> > it is generated in the kernel instead of an 18 step process involving
> > dumping a copy of residual data that was only being used to get
> > the memory size.  Retrieving memory size from the memory controller
> > configuration already had been done for other MCG boards with
> > inaccurate residual data info.
>
> Do the kernel tables have the right interrupt routing for MVME3600 with
> secondary Ethernet/SCSI for example ?

Unfortunately, the PReP port only ever supported the old INTA
routing tables so anything with slots was screwy.  There was
some route non-0 code but it was mostly a kludge.  A couple years
ago (when I had access to a MVME3600), it had the correct bus 0
routing tables in the PReP port.

The CONFIG_PPLUS port may or may not have the correct routings
for a MVME3600.  Randy, who did the work tried to get the
correct tables from the engineering docs but due to lack of
hardware it hasn't been tested.  Since the PPLUS port uses
the map_irq and swizzle kernel support it has proper A-D routing
tables that will work for add-in bridged I/O.

> > The firmware group at MCG will _never_ fix the residual data since
> > their AIX doesn't use it.  Even when they had some decent staff
> > on hand they weren't willing to fix anything related to residual
> > data.  Now, they've laid off just about everybody so it's guaranteed
> > to never happen.
> >
> > CONFIG_PPLUS also made it easy to add pci_auto support since putting
> > it in PReP would have been a complete mess...
> >
> > > > > (Who should have properly submitted his PrePboot code 3 years ago)
> >
> > Yeah, you even had a sorting autoconfiguration algorithm in prepboot,
> > IIRC.
>
> Indeed, can you think of any other solution when you reprogram the whole
> PCI<->PPCbus maps of the chipset ?

Most firmwares use a lossy allocator since the recursive implementation
is _very_ simple/compact code.  pci_auto.c is such an implementation.
Obviously, the disadvantage is that a large 1GB BAR discovered after a
4KB BAR will result in 2GB of PCI mem space being consumed.  To date,
that hasn't been too much of a problem...but will become one with the
"crazy" shared PCI memory systems being designed. :)

> The only problem is that it probably does not work with PCI<->PCI bridges
> since I never had the hardware to test (I believe I even never implemented
> that part, or scrapped after a brief attempt).

That was a focus of the pci_auto.c code since so many embedded boards
have rotten firmware.  We've haven't turned up any new bugs in many
months of throwing lots of complex cPCI/P2P configurations at it
which are generally the worst case situations.

I'd really like to extend it to a two pass sorting algorithm (a good
project for somebody with some extra time!).  Someday...

Regards,
--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Gabriel Paubert]

On Mon, 8 Apr 2002, Matt Porter wrote:

> The cPCI boards are especially bad as well as the 2300sc.

Ah, ok. Never had the (dis)pleasure to work with them...

> > > Because the CONFIG_PPLUS port doesn't rely on residual data, the
> > > ability to create a "ROMboot" image is simplified to the point that
> > > it is generated in the kernel instead of an 18 step process involving
> > > dumping a copy of residual data that was only being used to get
> > > the memory size.  Retrieving memory size from the memory controller
> > > configuration already had been done for other MCG boards with
> > > inaccurate residual data info.
> >
> > Do the kernel tables have the right interrupt routing for MVME3600 with
> > secondary Ethernet/SCSI for example ?
>
> Unfortunately, the PReP port only ever supported the old INTA
> routing tables so anything with slots was screwy.  There was
> some route non-0 code but it was mostly a kludge.  A couple years
> ago (when I had access to a MVME3600), it had the correct bus 0
> routing tables in the PReP port.

I suspect that INTA means 8259 crap, which I only use for serial
ports. All the other interrupts use the OpenPIC.

> > Indeed, can you think of any other solution when you reprogram the whole
> > PCI<->PPCbus maps of the chipset ?
>
> Most firmwares use a lossy allocator since the recursive implementation
> is _very_ simple/compact code.  pci_auto.c is such an implementation.
> Obviously, the disadvantage is that a large 1GB BAR discovered after a
> 4KB BAR will result in 2GB of PCI mem space being consumed.  To date,
> that hasn't been too much of a problem...but will become one with the
> "crazy" shared PCI memory systems being designed. :)

I know about typical lossy allocators: they hurt my aesthetic feelings ;-)
Especially since I wanted to compact everything to get the largest
posssible area for Universe VME mappings (and preferably through the BAT
mapped area). The algorithm is not complex, actually it was rather easy
once I had written all the memory management code for the x86 ROM BIOS
emulator: I just copied some linux kernel PCI code, added a trivial sort
routine on the resource trees (I/O, MMIO and I believe that I separated
prefetchable MMIO although it is only really needed for P2P bridges) and a
last pass to perform the actual BAR allocations.

The one shortcut I took is that I assumed that all bridges/devices would
allow 32 bit I/O space addresses, so I started at 0x10000 for I/O Space
allocation which guarantees no interference with ISA whatsoever. I know
that there are devices which only have 16 bit I/O space addresses but
they are a mess to handle properly when you have ISA devices lurking
around at random addresses.

> > The only problem is that it probably does not work with PCI<->PCI bridges
> > since I never had the hardware to test (I believe I even never implemented
> > that part, or scrapped after a brief attempt).
>
> That was a focus of the pci_auto.c code since so many embedded boards
> have rotten firmware.  We've haven't turned up any new bugs in many
> months of throwing lots of complex cPCI/P2P configurations at it
> which are generally the worst case situations.
>
> I'd really like to extend it to a two pass sorting algorithm (a good
> project for somebody with some extra time!).  Someday...

Me too, actually I believe P2P bridge support would be rather easy to add
to my code.

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Michael Sokolov]

Tom Rini <trini@kernel.crashing.org> wrote:

> > The platforms I've initially included in this new model are Adirondack,
> > EV-64260A, and K2.
>
> Just checking, but right now these are only supported with StarMON and
> not necessarily their shipping ROMs, right? :)

The Adirondack port currently in 2_4_devel has always been StarMON-only. For
this one board StarMON was the only existing firmware period for a few months,
and IMAO on this board it's essential, Adirondack can't be made to work right
with anything other than StarMON. I think they are still using StarMON to
production-test Adirondacks and program their serial EEPROMs with Ethernet
addresses, etc.

Of course that fucker, then software eng. manager, now director of engineering
Art Webb, wanted PeeMON on it no matter how stupid. I obstructed them as much
as I could by not making a zImage for the Adirondack and telling them that it
couldn't be done and that one had to boot vmlinux directly on Adirondack. But
the fuckers did manage to put their PeeMON on Adirondack, of course stealing
all the very complex board init code from StarMON. They actually made it load
the vmlinux ELF image and pass it a bi_recs list. But the only info they put in
there was the memory size. No way to set the command line, select the root
device, or boot with an initrd. So it's basically unusable. But the fuckers
didn't care if they make a usable system or not, all they cared was that it
says "PMON" on it, whether it works or not. No wonder they've recently had two
big customer projects canceled from what I've heard, with that attitude.

And I'm not even mentioning that the Adirondack has a hardware quirk it seems
that means that it *requires* something like OF or StarMON to work correctly.
It seems like that wonderful VT82C686B south bridge has a feature that if it's
enumerated more than once (like first by the firmware and then by Linux) IDE
won't work. In any case what I found when trying to get IDE to work was that it
stopped working after Linux did its pci_auto_bus_scan thing, but would work
fine if I changed the Linux port not to use pci_auto.c and instead keep the PCI
enumeration from StarMON (and of course IDE works in StarMON). If I made that
change, perfectly legitimate as it's necessary to make IDE work, it would bind
Adirondack Linux even more tightly to StarMON, stopping SBS fuckers' PeeMON
efforts once and for all. But the fucker fired me before I could do that. :-(

As for the K2, I just did it from memory to validate my CONFIG_GENERIC_PPC32
framework. I don't have a K2 or any other SBS hardware personally, so I'm not
defending that one.

Now I made the EV-64260A port very carefully to make it work with absolutely
any boot ROM. That's the vmlinux port, assuming it's booted with the right
bi_recs. I have a boot wrapper for StarMON, but not for anything else as I
don't have anything else. The PPCBoot people claim to boot vmlinux directly,
and I say they should be able to do it with my EV-64260A port, just pass it the
right bi_recs.

The issue of "shipping ROMs" for the EV-64260A is moot I think. There are as
many different ROMs for this eval board as there are actual boards. The one I
had at SBS came up right in VxWorks on power-up, no "shipping ROM" to boot
Linux with. The one I have now came with a PPCBoot ROM that spitted garbage out
the serial port and was unusable until I got the PROM burner working and made
it a StarMON ROM. (And that PPCBoot ROM was put in there by the guy I got the
board from, not by Galileo.)

> I'm sure it's unintentional, but it looks more like it'd be changing
> platform_init to x_init,

I'm not sure what you mean by unintentional, it's necessary to change
platform_init to <board>_init in order to have more than one board supported in
one kernel, which is necessary in order for my boards to compete fairly with
PMacs, PRePs, and CHRPs that are all supported in one kernel.

> and serial fixes rather than changing #ifdefs.

I think the way I've handled serial in CONFIG_GENERIC_PPC32 is neat and the
RTTD.

Adding other 2_4_devel boards to CONFIG_GENERIC_PPC32 will sometimes require an
#ifdef-ectomy. Look at Sandpoint for example. Choosing X2 or X3 at compile time
defeats the purpose of having one kernel support everything and decide at run
time. Same thing with Spruce having a compile option for 30 MHz or 33 MHz
serial port baud base.

> Aside from some ugliness added back to the code (see my other email).

I don't see it as ugly, I think it's quite beautiful.

> One other problem is that in case anyone forgot, back when we used to
> always define a new _MACH type, we had actually ran out (or got w/in 3
> or so) so we might want to think of changing the values in 2.5 to
> something that can scale better, if we're going to do this.

Perhaps you've missed my comment in processor.h:

/*
 * New CONFIG_GENERIC_PPC32 machine codes. There is absolutely no need for a
 * machine code to be a walking 1, so when defining a new code add 1 to the
 * last one, don't shift left one bit like before, or incur the wrath of the
 * person trying to support the 33rd machine. These machine codes are passed to
 * us by external bootloaders, so we are under a social contract not to ever
 * change them.
 */
#define	_MACH_adir	0x00000001
#define	_MACH_ev64260a	0x00000002
#define	_MACH_k2	0x00000003

> It's worth noting why these are done as they are, since I'm not sure you
> quite see why.  pmac and chrp fall into the same category as ppcstar,
> which is 'We know the firmware, it can be useful, and we will use it'.

I know this.

> If you didn't have the option of replacing a firmware, I'd bet you'd end
> up using it too :)

Ahmm, when you are making a new board there is no firmware to replace, you have
to write it!

> But anyhow, it's actually not incompatible with this.  I've gone and
> looked at this abit, and it'd be a matter of re-writing the Makefile a
> bit (obj-$(...) and XXX_OBJS -> platform.o, rm -f'ed after each zImage,
> and then a -DMACH_TYPE=_MACH_xxx for one of the files..).

Are you saying you are going to make some kind of loop in
arch/ppc/boot/simple/Makefile that would spit out 20 zImages on one make zImage
for CONFIG_GENERIC_PPC32? Fine with me if you want to do that.

> Well, since 'simple' will still work, this is a non-issue once again.

Even better then.

> > This will be
> > an encouragement to board makers to use standardized firmware like OF,
> > StarMON, or PPCBoot rather than roll a board-unique one: use something
> > standard and you can use one of existing zImages, or roll your own and
> > be prepared to convince people to accept adding yet another zImage.
>
> Or use a firmware which can load an ELF image (pmon, yes?) or fake it

But this way you still have to add a new zImage for each new board, even if
only to carry the knowledge of which board it is. With standardized firmware
like OF and StarMON it's unnecessary, there is one firmware standard that can
be implemented on an infinite number of boards, one common interface so one
zImage can work on all, and a machine ID that it can sense to select the right
port in vmlinux.

> Personally, I think some people spend too much time in the firmware and
> not enough time actually in linux.

That's probably because some of us are more hardware than software engineers.
When you are trying to get SDRAM to work and it's tough going because you've
got a new unfamiliar system controller chip, you aren't sure of the right
timing parameters, and the board is the very first prototype with some HW
design errors still not caught and fixed, StarMON is a much better debug tool
than Linux.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Matt Porter]

On Mon, Apr 08, 2002 at 11:18:43AM -0700, Michael Sokolov wrote:
> Of course that fucker, then software eng. manager, now director of engineering
> Art Webb, wanted PeeMON on it no matter how stupid. I obstructed them as much
> as I could by not making a zImage for the Adirondack and telling them that it
> couldn't be done and that one had to boot vmlinux directly on Adirondack. But
> the fuckers did manage to put their PeeMON on Adirondack, of course stealing
> all the very complex board init code from StarMON. They actually made it load
> the vmlinux ELF image and pass it a bi_recs list. But the only info they put in
> there was the memory size. No way to set the command line, select the root
> device, or boot with an initrd. So it's basically unusable. But the fuckers
> didn't care if they make a usable system or not, all they cared was that it
> says "PMON" on it, whether it works or not. No wonder they've recently had two
> big customer projects canceled from what I've heard, with that attitude.

Michael, don't hold back.  Tell us how you really feel.

--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Tom Rini]

On Mon, Apr 08, 2002 at 11:18:43AM -0700, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > > The platforms I've initially included in this new model are Adirondack,
> > > EV-64260A, and K2.
> >
> > Just checking, but right now these are only supported with StarMON and
> > not necessarily their shipping ROMs, right? :)
[snip]
> The issue of "shipping ROMs" for the EV-64260A is moot I think.

Yeah.

> > I'm sure it's unintentional, but it looks more like it'd be changing
> > platform_init to x_init,
>
> I'm not sure what you mean by unintentional, it's necessary to change

I ment the '#ifdef-ectomy' comment.  Most of the code is actually rather
clean.  The Sandpoint is actally a good candidate for some sort of run-time
checks since it's a development board and the X2/X3 (and X3b) do differ in
some ways.  I actually think the Spruce thing is a red-herring, but maybe the
Spurce Paul/David Gibson have is different than the one mporter has access to.


> > and serial fixes rather than changing #ifdefs.
>
> I think the way I've handled serial in CONFIG_GENERIC_PPC32 is neat and the
> RTTD.

This works great if you let the firmware deal with the serial port.  I
need to play abit more with it I suspect, but using early_serial_setup()
becomes less than ideal, w/o some trickery anyhow, ifyou have to use
arch/ppc/boot/common/ns16550.c

> > Aside from some ugliness added back to the code (see my other email).
>
> I don't see it as ugly, I think it's quite beautiful.

Adding an #ifdef per board?

> > One other problem is that in case anyone forgot, back when we used to
> > always define a new _MACH type, we had actually ran out (or got w/in 3
> > or so) so we might want to think of changing the values in 2.5 to
> > something that can scale better, if we're going to do this.
>
> Perhaps you've missed my comment in processor.h:

Yeap.

> > If you didn't have the option of replacing a firmware, I'd bet you'd end
> > up using it too :)
>
> Ahmm, when you are making a new board there is no firmware to replace,
> you have to write it!

If you don't have the option to replace an existing firmware...  but
anyways.

> > But anyhow, it's actually not incompatible with this.  I've gone and
> > looked at this abit, and it'd be a matter of re-writing the Makefile a
> > bit (obj-$(...) and XXX_OBJS -> platform.o, rm -f'ed after each zImage,
> > and then a -DMACH_TYPE=_MACH_xxx for one of the files..).
>
> Are you saying you are going to make some kind of loop in
> arch/ppc/boot/simple/Makefile that would spit out 20 zImages on one
> make zImage for CONFIG_GENERIC_PPC32? Fine with me if you want to do that.

Well it'd be no worse than the loop we have right now to spit out
zImages.

> > > This will be
> > > an encouragement to board makers to use standardized firmware like OF,
> > > StarMON, or PPCBoot rather than roll a board-unique one: use something
> > > standard and you can use one of existing zImages, or roll your own and
> > > be prepared to convince people to accept adding yet another zImage.
> >
> > Or use a firmware which can load an ELF image (pmon, yes?) or fake it
>
> But this way you still have to add a new zImage for each new board, even if
> only to carry the knowledge of which board it is. With standardized firmware
> like OF and StarMON it's unnecessary, there is one firmware standard that can
> be implemented on an infinite number of boards, one common interface so one
> zImage can work on all, and a machine ID that it can sense to select the right
> port in vmlinux.

I'll probably soon give up on trying to convince you that this won't
happen and the closest that's ever likely to be seen as a 'standard
firmware' is the ability to deal with a static ELF program.  It'd be
_nice_ if everyone use PPCBoot or StarMON or something (remember, not
all OF is created equal, and Apple doesn't have much/any incentive to be
compatible w/ the rest of the OF world).

> > Personally, I think some people spend too much time in the firmware and
> > not enough time actually in linux.
>
> That's probably because some of us are more hardware than software engineers.

<Another Joke>
So you're more one of those hardware people inflicting really wierd
designs on us software people, aren't you? :)
</Another Joke>

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Michael Sokolov]

Tom Rini <trini@kernel.crashing.org> wrote:

> Most of the code is actually rather
> clean.  The Sandpoint is actally a good candidate for some sort of run-time
> checks since it's a development board and the X2/X3 (and X3b) do differ in
> some ways.  I actually think the Spruce thing is a red-herring, but maybe the
> Spurce Paul/David Gibson have is different than the one mporter has access to.

But the point is that these two ports as they are right now aren't suitable for
CONFIG_GENERIC_PPC32 because of #ifdefs in them. An #ifdef-ectomy would mean
splitting the Sandpoint port into two ports, X2 and X3 with different _machine
codes, selected at run time. I don't know what to do for the Spruce. Does that
board have a spec saying what the baud clock is supposed to be? If there is,
assume the value from the spec and fix the boards that don't meet the spec. If
there is no right value and both values are equally legit, that's a screwed-up
board that standard OSes like Debian Linux/PPC don't need to support, so don't
bother putting it in the generic kernel.

> > I think the way I've handled serial in CONFIG_GENERIC_PPC32 is neat and the
> > RTTD.
>
> This works great if you let the firmware deal with the serial port.  I
> need to play abit more with it I suspect, but using early_serial_setup()
> becomes less than ideal, w/o some trickery anyhow, ifyou have to use
> arch/ppc/boot/common/ns16550.c

Ahh, the arch/ppc/boot morass is a fly in the ointment again... Well, you know
my solution: remove the fly. When you have just vmlinux, early_serial_setup()
is the ideal solution as that's precisely what it's designed for. It's doing
things the right way, the way they were meant to be done.

You were just talking about making make zImage spit out a pile of zImages for
different boards by compiling the wrapper many times in different
configurations. Just instantiate the wrapper's ns16550 driver per board.

> > I don't see it as ugly, I think it's quite beautiful.
>
> Adding an #ifdef per board?

Yes. It's a lot more beautiful than getting link errors about platform_init
multiply defined or <x>_init undefined.

> So you're more one of those hardware people inflicting really wierd
> designs on us software people, aren't you? :)

Actually I've been very outspoken about strictly following standards and not
making frivolous designs some others are fond of. Also since I intend to run
standard OSes on any hardware I design and I'm the one writing that OS support,
I plan for that in advance in the hardware design stage.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Geert Uytterhoeven]

On Tue, 9 Apr 2002, Michael Sokolov wrote:
> Tom Rini <trini@kernel.crashing.org> wrote:
> > Most of the code is actually rather
> > clean.  The Sandpoint is actally a good candidate for some sort of run-time
> > checks since it's a development board and the X2/X3 (and X3b) do differ in
> > some ways.  I actually think the Spruce thing is a red-herring, but maybe the
> > Spurce Paul/David Gibson have is different than the one mporter has access to.
>
> But the point is that these two ports as they are right now aren't suitable for
> CONFIG_GENERIC_PPC32 because of #ifdefs in them. An #ifdef-ectomy would mean
> splitting the Sandpoint port into two ports, X2 and X3 with different _machine
> codes, selected at run time. I don't know what to do for the Spruce. Does that
> board have a spec saying what the baud clock is supposed to be? If there is,
> assume the value from the spec and fix the boards that don't meet the spec. If
> there is no right value and both values are equally legit, that's a screwed-up
> board that standard OSes like Debian Linux/PPC don't need to support, so don't
> bother putting it in the generic kernel.

Can't you pass the X parameter and the baud clock to the kernel, either using
the kernel command line or a bi_rec? On Amiga we pass things like VBLANK,
E-clock, and power supply frequencies as well (using bi_recs).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Tom Rini]

On Wed, Apr 10, 2002 at 10:27:05AM +0200, Geert Uytterhoeven wrote:
>
> On Tue, 9 Apr 2002, Michael Sokolov wrote:
> > Tom Rini <trini@kernel.crashing.org> wrote:
> > > Most of the code is actually rather
> > > clean.  The Sandpoint is actally a good candidate for some sort of run-time
> > > checks since it's a development board and the X2/X3 (and X3b) do differ in
> > > some ways.  I actually think the Spruce thing is a red-herring, but maybe the
> > > Spurce Paul/David Gibson have is different than the one mporter has access to.
> >
> > But the point is that these two ports as they are right now aren't suitable for
> > CONFIG_GENERIC_PPC32 because of #ifdefs in them. An #ifdef-ectomy would mean
> > splitting the Sandpoint port into two ports, X2 and X3 with different _machine
> > codes, selected at run time. I don't know what to do for the Spruce. Does that
> > board have a spec saying what the baud clock is supposed to be? If there is,
> > assume the value from the spec and fix the boards that don't meet the spec. If
> > there is no right value and both values are equally legit, that's a screwed-up
> > board that standard OSes like Debian Linux/PPC don't need to support, so don't
> > bother putting it in the generic kernel.
>
> Can't you pass the X parameter and the baud clock to the kernel, either using
> the kernel command line or a bi_rec? On Amiga we pass things like VBLANK,
> E-clock, and power supply frequencies as well (using bi_recs).

>From PPCBoot/StarMON/other linux knowing firmware, yes.  From
arch/ppc/boot we'd still have to compile it in and then pass it.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Michael Sokolov]

Tom Rini <trini@kernel.crashing.org> wrote:

> From PPCBoot/StarMON/other linux knowing firmware, yes.

Please don't call StarMON "linux knowing firmware", it isn't. It knows 0 about
Linux. For firmware to know about any one OS is a discrimination against users
wanting to run some other OS or write their own, and is unacceptable to me. I
still believe that every single person buying a computer should write his own
operating system.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Tom Rini]

On Wed, Apr 10, 2002 at 08:50:09PM -0700, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > From PPCBoot/StarMON/other linux knowing firmware, yes.
>
> Please don't call StarMON "linux knowing firmware", it isn't. It knows 0 about
> Linux. For firmware to know about any one OS is a discrimination against users
> wanting to run some other OS or write their own, and is unacceptable to me. I
> still believe that every single person buying a computer should write his own
> operating system.

Okay:
>From PPCBoot[1]/other linux knowing firmware, and StarMON + ppc-boot-linux.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

[1]: I suspect PPCBoot as well can handle other OS's, but I don't know
for certain...

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Tom Rini]

On Tue, Apr 09, 2002 at 12:52:40PM -0700, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > Most of the code is actually rather
> > clean.  The Sandpoint is actally a good candidate for some sort of run-time
> > checks since it's a development board and the X2/X3 (and X3b) do differ in
> > some ways.  I actually think the Spruce thing is a red-herring, but maybe the
> > Spurce Paul/David Gibson have is different than the one mporter has access to.
>
> But the point is that these two ports as they are right now aren't suitable for
> CONFIG_GENERIC_PPC32 because of #ifdefs in them. An #ifdef-ectomy would mean
> splitting the Sandpoint port into two ports, X2 and X3 with different _machine
> codes, selected at run time.



> I don't know what to do for the Spruce. Does that
> board have a spec saying what the baud clock is supposed to be? If there is,
> assume the value from the spec and fix the boards that don't meet the spec. If
> there is no right value and both values are equally legit, that's a screwed-up
> board that standard OSes like Debian Linux/PPC don't need to support, so don't
> bother putting it in the generic kernel.

Again, I think the Spruce thing is a red herring since I think it's only
the Spruce that David Gibson has which needs or needed a different
speed.  I suspect I'll end up looking in the archives and settling this
once and for all before Spruce moves up to linuxppc_2_4.

> > > I think the way I've handled serial in CONFIG_GENERIC_PPC32 is neat and the
> > > RTTD.
> >
> > This works great if you let the firmware deal with the serial port.  I
> > need to play abit more with it I suspect, but using early_serial_setup()
> > becomes less than ideal, w/o some trickery anyhow, ifyou have to use
> > arch/ppc/boot/common/ns16550.c
>
> Ahh, the arch/ppc/boot morass is a fly in the ointment again...

Not quite.  DINK32/PPCBug/PMON/Force firmware (pcore?)/other commerical
firmwares which know 0 about Linux and won't ever quite probably is the
'fly in the ointment'.

> Well, you know
> my solution: remove the fly. When you have just vmlinux, early_serial_setup()
> is the ideal solution as that's precisely what it's designed for. It's doing
> things the right way, the way they were meant to be done.

Except when you compile serial as a module like Paul pointed out.  Maybe
this will be better in 2.5 tho w/ the new serial driver Russel King has
(http://www.arm.linux.org.uk/cvs/).

> You were just talking about making make zImage spit out a pile of zImages for
> different boards by compiling the wrapper many times in different
> configurations. Just instantiate the wrapper's ns16550 driver per board.

That's what we do now, and would do, with the 'current' <asm/serial.h>
which gets the right file for the right board, in a 1-board config.  It
also 'just works' when the ports are at the legacy location, from what I
recall.  (or legacy + 0x00800000 or something).

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Michael Sokolov]

Tom Rini <trini@kernel.crashing.org> wrote:

> Not quite.  DINK32/PPCBug/PMON/Force firmware (pcore?)/other commerical
> firmwares which know 0 about Linux and won't ever quite probably is the
> 'fly in the ointment'.

I disagree. StarMON also knows 0 about Linux, which is how it should be as it's
none of the firmware's business to care what OS the user wants to run, and yet
I've got Linux to work with it very beautifully as you can see. Same with OF on
PMacs and CHRPs.

I think you have some confusion here. It seems to me like you think that
StarMON is something like PPCBoot. No, it's nowhere near that. It's a lot
closer to DINK or PPCBug. Actually what it's most like is a mechanical boot
console with blinking lights and toggle-switches. Wanna boot something? Toggle
in your boot code in binary into memory from switches. Or load it from a
punched paper tape. NO FRILLS. And forget about ELF, it has never heard of such
a thing. Every byte from the punched tape is loaded into memory at linearly
incrementing addresses, no header parsing of any kind, just straight binary.

If I've been able to make Linux/PPC boot so nicely and have one generic
configuration with my very very no-frills firmware, I claim you've gotta be
able to do that with other people's modern full-of-frills firmware.

OK, I added a few frills to StarMON later on, like those sc calls you see me
using in my new arch/ppc/boot/ppcstar. But those weren't in the original
design, they were an afterthought added not so much to help Linux but for my
internal use (in add-on modules for StarMON that add extra functionality where
I wanted to use the same binary for all boards without changes for different
serial ports etc), and Linux could do just fine without them as my original
design did. I also have a board ID as an ASCIZ string at FFF00010. But again
that isn't strictly necessary, my original plan was to tell users to put an OS-
defined machine type code in one of the registers manually before booting the
kernel.

Or you could make the zImage wrapper grep the ROM region for various strings to
identify what board/firmware it's running on. Right now you could take your
"simple" wrappers for different boards and merge them into one that will first
select the board and then proceed as it does now. The only problem would be
with board identification. Now my idea of having a board ID somewhere in the
ROM is nothing earth-shattering, DEC has done 16 years before me, and I think
just about company does that.

Now the problem with the PowerPC architecture (which doesn't exist in VAX and I
think Alpha and SPARC too) is that there is no central authority over it and no
universal standard for all board manufacurers, so while one company may have
some convention across its boards, there nothing across *all* boards. That's
where the grep idea comes in. I can bet that a board made by Mumbletech model
ABC will have strings "Mumbletech" and "ABC" somewhere in the ROM. Just look
for those magic strings and you'll know what you are running on. Past this step
for everything else there already is a solution.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Tom Rini]

On Wed, Apr 10, 2002 at 08:46:33PM -0700, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > Not quite.  DINK32/PPCBug/PMON/Force firmware (pcore?)/other commerical
> > firmwares which know 0 about Linux and won't ever quite probably is the
> > 'fly in the ointment'.
>
> I disagree. StarMON also knows 0 about Linux, which is how it should be as

Fine, StarMON + ppc-boot-linux.  But this really is splitting hairs.
The problem is firmware (or firmware writers) who know about Linux and
want to boot linux from their firmware (in your case, you wrote another
program, ppc-boot-linux, to know about the linux bits) and those who
don't.

> If I've been able to make Linux/PPC boot so nicely and have one generic
> configuration with my very very no-frills firmware, I claim you've gotta be
> able to do that with other people's modern full-of-frills firmware.

What's the incentive to do something like that when it all just works
tho?

> Or you could make the zImage wrapper grep the ROM region for various strings to
> identify what board/firmware it's running on. Right now you could take your
> "simple" wrappers for different boards and merge them into one that will first
> select the board and then proceed as it does now. The only problem would be
> with board identification. Now my idea of having a board ID somewhere in the
> ROM is nothing earth-shattering, DEC has done 16 years before me, and I think
> just about company does that.

One of the real beautiful parts of the 'simple' wrapper (I wish someone
else would have came up w/ another name for it when I asked, anyhow...)
is that it doesn't care about firmware what so ever.

Hell, it could probably run on StarMON (I suspect it'd just need to have
the ELF header stripped off and loaded into a 'good' location). :)

> some convention across its boards, there nothing across *all* boards. That's
> where the grep idea comes in. I can bet that a board made by Mumbletech model
> ABC will have strings "Mumbletech" and "ABC" somewhere in the ROM. Just look
> for those magic strings and you'll know what you are running on. Past this step
> for everything else there already is a solution.

Which means for N boards (or N board mfrs) you have to add in another
bit to a file, or come up w/ some nice magic to compile all
xxx_detect.c files or something like that.

'simple' doesn't want to know about the firmware, 'simple' wants to get
Linux up and running. :)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Michael Sokolov]

Tom Rini <trini@kernel.crashing.org> wrote:

> Fine, StarMON + ppc-boot-linux.  But this really is splitting hairs.
> The problem is firmware (or firmware writers) who know about Linux and
> want to boot linux from their firmware (in your case, you wrote another
> program, ppc-boot-linux, to know about the linux bits) and those who
> don't.

First it's ppc-linux-boot, not ppc-boot-linux. Second as you can see from it's
code it is not specific to StarMON except on boards where there is no other
firmware. So your whole argument of StarMON + ppc-linux-boot as somehow special
is misbased. You could have PPCBug + ppc-linux-boot or DINK + ppc-linux-boot
just as well.

Also I'm not even using ppc-linux-boot any more, in 2_4_alt I've made a
zImage.ppcstar that runs directly from the (completely Linux-unaware) StarMON
console. As you can see it isn't that hard. (And as I already wrote I made that
wrapper instead of ppc-linux-boot not because I like this, but because you guys
just can't agree on the vmlinux entry point ABI precluding external booters.)

> What's the incentive to do something like that when it all just works
> tho?

The incentive, for me at least, is to sell boards and to have standard Linux
and BSD distributions shipping with them to make them sell better. I don't
think any company would be particularly happy about cutting, testing,
archiving, distributing, etc. 20 different CD variants for each release of an
OS because you have to have a different one for each slightly different CPU
board model, even if the difference is one byte.

I don't think we'll ever come to an agreement because we have different goals.
You are taking directions from people like Art Webb, and I'm trying to deliver
a better product to the market that all those Art Webbs. I want my boards
supported in the CONFIG_ALL_PPC kernel or its successor and I'm prepared to do
whatever boot mechanism changes it takes to do that. If you don't have that
goal and your goal is instead to keep things "simple", fine, no one can tell
you what to do with your boards. Let's just accept that my board ports will
always be very different from yours.

> Hell, it could probably run on StarMON (I suspect it'd just need to have
> the ELF header stripped off and loaded into a 'good' location). :)

Yes, it would run, except on boards where somewhere along the way you make an
assumption about some hardware (like the interrupt controller or IDE) being in
a certain state on entry, which is the state established by some other firmware
but not StarMON. I remember problems of that sort on K2. Also in your current
EV-64260 port the wrapper assumes that the GT registers are at 0x14000000,
while StarMON puts them at the much more reasonable 0xF1000000. But I did
indeed boot your EV-64260 zImage from StarMON, I just wrote a tiny program that
remaps the GT registers back to 0x14000000 and jumps to 0x800000 where zImage
lives. (I also had to comment out a few things in the Linux code proper in your
wonderful EV-64260 port that prevented it from running on my board, but that's
beside the point here.)

It'll also run inefficiently on most boards as far as caches go. StarMON stores
its state variables and in some implementations its code in locked caches. When
you get a full OS up and running you want to flush all that out to use all
caches normally as caches in their full capacity.

> 'simple' doesn't want to know about the firmware, 'simple' wants to get
> Linux up and running. :)

Let's just accept that I'll do my board ports differently because I have a
different view and a different goal.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Mark A. Greer]

Michael Sokolov wrote:

> but not StarMON. I remember problems of that sort on K2. Also in your current
> EV-64260 port the wrapper assumes that the GT registers are at 0x14000000,
> while StarMON puts them at the much more reasonable 0xF1000000. But I did
> indeed boot your EV-64260 zImage from StarMON, I just wrote a tiny program that
> remaps the GT registers back to 0x14000000 and jumps to 0x800000 where zImage
> lives. (I also had to comment out a few things in the Linux code proper in your
> wonderful EV-64260 port that prevented it from running on my board, but that's
> beside the point here.)

Yes, it assumes the registers are at 0x14000000 because that's where DINK leaves
them.  It was made clear from the start that the arch/ppc/boot code for the
ev64260 was built for boards running DINK.

When we see what Benh has for bi_recs, we can start making this more general.

Mark


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Tom Rini]

On Thu, Apr 11, 2002 at 09:16:08AM -0700, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> Also I'm not even using ppc-linux-boot any more, in 2_4_alt I've made a
> zImage.ppcstar that runs directly from the (completely Linux-unaware) StarMON
> console. As you can see it isn't that hard.

Of course it's not hard.  That's what the 'simple' stuff does. :)  Runs
directly from the (completely Linux-unaware) DINK/PMON/What-have-you.

> The incentive, for me at least, is to sell boards and to have standard Linux
> and BSD distributions shipping with them to make them sell better.

Then get an OF license (I hear OpenBIOS is adding OF stuffs) and yaboot
will Just Work and booting from CD will probably just work too.
Otherwise StarMON is no more standard than the rest of the bunch.

> I don't
> think any company would be particularly happy about cutting, testing,
> archiving, distributing, etc. 20 different CD variants for each release of an
> OS because you have to have a different one for each slightly different CPU
> board model, even if the difference is one byte.

That's a rather large exageration.  If a vendor doesn't test their
distribution on a model but is going to claim it works, it's going to
upset someone when they find out it doesn't.


> > Hell, it could probably run on StarMON (I suspect it'd just need to have
> > the ELF header stripped off and loaded into a 'good' location). :)
>
> Yes, it would run, except on boards where somewhere along the way you make an
> assumption about some hardware (like the interrupt controller or IDE) being in
> a certain state on entry, which is the state established by some other
> firmware but not StarMON.

It's a good thing it doesn't rely on the firmware having done anything
for us.  Linux may or may not, but the bootwrapper certainly doesn't[1],
except:

> I remember problems of that sort on K2.

So do I, and things (except for Spruce) have been cleaned up to not do
any of that in the firmware and to do it in the kernel (which was a
known ugliness at the time it was done and which is why it was cleaned
up).

> Also in your current
> EV-64260 port the wrapper assumes that the GT registers are at 0x14000000,
> while StarMON puts them at the much more reasonable 0xF1000000.

>From what I recall on this, someone from the BSD camp popped up and said
they wanted to relocate things and that's why it has to be delt with
(and I _think_ the _galileo tree does handle it, but I don't know).  But
anyhow, that's a galileo issue..

> But I did
> indeed boot your EV-64260 zImage from StarMON, I just wrote a tiny program
> that remaps the GT registers back to 0x14000000 and jumps to 0x800000
> where zImage lives.

Did you have to strip the ELF header off or no?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Michael Sokolov]

Tom Rini <trini@kernel.crashing.org> wrote:

> Then get an OF license

I'm sure most customers would appreciate a lower price for boards without OF
license costs. I also claim that StarMON is better than OF.

> yaboot
> will Just Work and booting from CD will probably just work too.

I plan to write ybboot that will do for PPCStar what yaboot does for OF. Then
I'll just need to convince Debian to include ybboot in addition to yaboot,
which I hope won't be too hard as it's a really tiny and non-invasive bit.

> That's a rather large exageration.  If a vendor doesn't test their
> distribution on a model but is going to claim it works, it's going to
> upset someone when they find out it doesn't.

Of course it must be tested. But it should be one distribution, not 20 slightly
different, identical-except-for-one-byte-machine-code ones. Testing will be a
lot easier this way too.

> Did you have to strip the ELF header off or no?

I just loaded the zImage file as it was generated at 0x7F0000 so that the
actual code ended up at 0x800000, and started it at 0x800000.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Tom Rini]

On Thu, Apr 11, 2002 at 10:25:42AM -0700, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > Then get an OF license
>
> I'm sure most customers would appreciate a lower price for boards without OF
> license costs. I also claim that StarMON is better than OF.

I'm not going to attempt to argue either of those points, but I will
argue that if you want things to just work, OF is the least common
denominator :)

> > yaboot
> > will Just Work and booting from CD will probably just work too.
>
> I plan to write ybboot that will do for PPCStar what yaboot does for OF. Then
> I'll just need to convince Debian to include ybboot in addition to yaboot,
> which I hope won't be too hard as it's a really tiny and non-invasive bit.

Have fun, and good luck.

> > That's a rather large exageration.  If a vendor doesn't test their
> > distribution on a model but is going to claim it works, it's going to
> > upset someone when they find out it doesn't.
>
> Of course it must be tested. But it should be one distribution, not
> 20 slightly different, identical-except-for-one-byte-machine-code ones.
> Testing will be a lot easier this way too.

That's a good case to try and argue, but it's not the current case
either.  We don't have 20 slightly different,
identical-except-for-one-byte-machine-code ones, we have 20 different
machines, most of which have roughly the same code for the wrapper
(serial differences).  And the actual kernels are very different.  And
why on earth would you have 20 different distributions.  You'd have 20
different kernel images, but that's because you have 2 different boards.

> > Did you have to strip the ELF header off or no?
>
> I just loaded the zImage file as it was generated at 0x7F0000 so that the
> actual code ended up at 0x800000, and started it at 0x800000.

Oh, so you just skipped over it anyhow.  Most of the boards just dd it
off and load right at 0x800000.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Tom Rini]

On Tue, Apr 09, 2002 at 12:52:40PM -0700, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > > I don't see it as ugly, I think it's quite beautiful.
> >
> > Adding an #ifdef per board?
>
> Yes. It's a lot more beautiful than getting link errors about platform_init
> multiply defined or <x>_init undefined.

And neither are as nice as doing some ELF tricks like what Paul
mentioned.  If you do something ala __init which marks a function as
going into .text.platform.init or so, change <x>_init to have a check to
make sure it's on the right board and then have early_init call a
function that goes and runs all of the functions marked as
.text.platform.init, a 1-board kernel is almost no different, and adding
new boards to GENERIC_PPC32 means touching one less file.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[Paul Mackerras]

Michael Sokolov writes:

> Some commentary is in order on this cset. I strongly recommend that Paulus,
> people interested in bi_recs enhancements, and people interested in GT-64260
> support check it out and give it a good look.

I have had a quick look...

>  Any number of platforms can be included in the
> configuration. Each is selected with a bool in config.in so the user can
> include only the platform(s) that s/he needs, while distribution makers can
> ship one kernel for the world.

A laudable goal.  I like the idea of having each platform selected
with a bool rather than just having a single choice of platform.
I also agree about the CONFIG_ALL_PPC name but no-one has ever been
able to come up with a better name for the PReP/PMac/CHRP combination.

However, there are some aspects of the way you have done your
CONFIG_GENERIC_PPC32 that I don't like.  In particular I don't like
the list of ifdefs in setup.c.  Whenever that sort of thing appears it
is a sign that we need to rethink how we do things.  The old
drivers/net/Space.c was a classic example, and it was a mistake and it
basically became unmaintainable.  Fortunately we have better ways to
handle that sort of thing these days.  In particular we can use ELF
sections in creative ways to make lists of things without having to
have strings of ifdefs.

In fact, any place where we have lists of things, one per platform or
one per config option, is a place where we are going to potentially
get maintainability problems as the number of platforms we support
grows.  At the moment we can't really avoid that completely in the
Makefiles and config.in files.  We can avoid it in C source and we can
mostly avoid it in header files (but not completely at this stage).
As a guideline, ultimately I want it to be the case that you can add
support for a new board without changing *any* existing source files
in the kernel tree, i.e. just by adding files.  (That means that
anything that lists platforms or config options will need to be
autogenerated.)

The other thing I don't like is the bi_rec changes.  While I like the
idea of passing in device information in bi_recs, I really don't like
the use of binary tags for the various specific pieces of information
that we want to specify for the different devices.  This is ultimately
once again a maintainability concern.  Using an enumeration like that
basically forces us into having a central repository for assigning the
numbers and that is going to get us into problems down the track.

Instead I think that both the names of the pieces of information, and
the values of things like the device type, should be represented as
strings.  Using strings just gives us orders of magnitude more
flexibility and extensibility, and is much more suitable for the sort
of decentralized and distributed development that we do.

Now if we are worried about space then we can get creative about how
the strings are stored in the bi_recs, for instance we could store
each unique string exactly once in a string table and then just use a
16-bit index in each place where we want to refer to a string.  We
could put the string table in a bi_rec of its own, and even gzip it if
necessary.

About the early_serial_init changes - using early_serial_init is nice
when the serial driver is built in, but the problem is that when the
serial driver is a module, we don't get given the opportunity to do
the early_serial_init calls between when the module is loaded and when
it runs rs_init.  Otherwise I would have decreed the use of
early_serial_init some time ago. :)

Regards,
Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: CONFIG_GENERIC_PPC32

[benh]

>The other thing I don't like is the bi_rec changes.  While I like the
>idea of passing in device information in bi_recs, I really don't like
>the use of binary tags for the various specific pieces of information
>that we want to specify for the different devices.  This is ultimately
>once again a maintainability concern.  Using an enumeration like that
>basically forces us into having a central repository for assigning the
>numbers and that is going to get us into problems down the track.
>
>Instead I think that both the names of the pieces of information, and
>the values of things like the device type, should be represented as
>strings.  Using strings just gives us orders of magnitude more
>flexibility and extensibility, and is much more suitable for the sort
>of decentralized and distributed development that we do.

Well, I don't think we really need strings. If we go tha way, we'll
soon end-up re-inventing a bastardized OF device-tree and we could
rather use a real one there ;)

What I would have liked would have to use the tag 32 bits as a 4
character constant (common practice in macos). The problem is that
it requires re-defining existing bi_rec's but that isn't really
compilicated to support them for compatibility.

That way, we have something that is more readable than an enum, less
likely to collide. Then, we define that the kernel will only define,
for example, all lowercase constants. That mean that you are free to
add your custom tags making sure you won't collide with whatever a
new kernel version can recognize (and that include drivers bundled
with the kernel).

Now, we can even define some more precise scheme for using those 4
characters, like though I really don't think it's that much needed.
We will never define bazillions of tags. Maybe a few dozen for what
is currently in bd_t, and a dozen or so more for drivers that can
get configuration infos, and that's all.

>Now if we are worried about space then we can get creative about how
>the strings are stored in the bi_recs, for instance we could store
>each unique string exactly once in a string table and then just use a
>16-bit index in each place where we want to refer to a string.  We
>could put the string table in a bi_rec of its own, and even gzip it if
>necessary.
>
>About the early_serial_init changes - using early_serial_init is nice
>when the serial driver is built in, but the problem is that when the
>serial driver is a module, we don't get given the opportunity to do
>the early_serial_init calls between when the module is loaded and when
>it runs rs_init.  Otherwise I would have decreed the use of
>early_serial_init some time ago. :)

Does Ted has an idea ? I've also been told Russel King was rewriting the
serial driver for 2.5...

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/