CONFIG_GENERIC_PPC32

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

[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

[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

[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/

Bootloader (Re: CONFIG_GENERIC_PPC32)

[benh]

Just for your information, I noticed the OpenBIOS folks are
working on an Open Firmware implementation. They already have
the tokenizer, detokenizer & interpreter and started implementing
the OF standard words.

It would be interesting to have all those new boards use an OF
based firmware ;)

Ben.


** 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: Bootloader (Re: CONFIG_GENERIC_PPC32)

[Dan Malek]

benh@kernel.crashing.org wrote:

> Just for your information, I noticed the OpenBIOS folks ....

A few embedded boards have done this in the past, in particular
all of the Cogent Computer boards.

The only advantage was for the few (one :-) PCI I/O boards that
may have OF initialization roms.  In all other cases I found
it a PITA, because no one cares to write any documentation
about how it runs on their boards.  The response was "It's
standard OF".....yeah, right.

IMHO, if we would just standardize on ASCII bi_recs we would
actually make some progress :-).  If you want an OS in a boot
rom, just flash Linux and get it over with.


	-- Dan


** 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

[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

[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/

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

[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

[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: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

[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

[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

[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

[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/

The very common kernel, again... (Was: Re: CONFIG_GENERIC_PPC32)

[Tom Rini]

On Thu, Apr 11, 2002 at 09:16:08AM -0700, Michael Sokolov wrote:

> 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.

Why?  Why is it a good thing to put this into 'CONFIG_ALL_PPC' ?  You
still end up with 3 images (PReP, vmlinux for pmac/chrp, PPCStar) which
I wouldn't think is any worse from N (either the FW lets you load an
abitrary kernel off of the CD/HD/whatever, or you have to put on the
!vmlinux (in CONFIG_ALL_PPC's case, yaboot) booting kernel else-where.

This pops up now and again, and I still don't quite see why.  What I can
see as a good idea is something like CONFIG_HEC (in your case) which
since the FW is known and it is possible to figure out the model you're
on, have one kernel that runs on the whole product line.  This, iirc, is
what the current gemini bits do (Val, if you do happen to be reading
this, would CONFIG_SYNERGY make more sense than CONFIG_GEMINI at this
point?  Just curious...) and what the pmac (and to an extent chrp and
prep as well) do.

--
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: The very common kernel, again...

[Michael Sokolov]

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

> Why?  Why is it a good thing to put this into 'CONFIG_ALL_PPC' ?  You
> still end up with 3 images (PReP, vmlinux for pmac/chrp, PPCStar) which
> I wouldn't think is any worse from N (either the FW lets you load an
> abitrary kernel off of the CD/HD/whatever, or you have to put on the
> !vmlinux (in CONFIG_ALL_PPC's case, yaboot) booting kernel else-where.

But we wouldn't have this mess if you guys would just let us have one
CONFIG_GENERIC_PPC32 vmlinux with a standardized and stable boot ABI. Then we,
the people with incentive to sell boards, would do what we need to do with our
firmware or booters or whatever to boot that standard vmlinux and make it as
easy as possible for people like Debian to support us in the standard dist.

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: The very common kernel, again...

[Tom Rini]

On Thu, Apr 11, 2002 at 10:31:13AM -0700, Michael Sokolov wrote:
>
> Tom Rini <trini@kernel.crashing.org> wrote:
>
> > Why?  Why is it a good thing to put this into 'CONFIG_ALL_PPC' ?  You
> > still end up with 3 images (PReP, vmlinux for pmac/chrp, PPCStar) which
> > I wouldn't think is any worse from N (either the FW lets you load an
> > abitrary kernel off of the CD/HD/whatever, or you have to put on the
> > !vmlinux (in CONFIG_ALL_PPC's case, yaboot) booting kernel else-where.
>
> But we wouldn't have this mess if you guys would just let us have one
> CONFIG_GENERIC_PPC32 vmlinux with a standardized and stable boot ABI. Then we,
> the people with incentive to sell boards, would do what we need to do with our
> firmware or booters or whatever to boot that standard vmlinux and make it as
> easy as possible for people like Debian to support us in the standard dist.

This has _nothing_ to do with the boot ABI.  The boot ABI for 2.4 hasn't
changed, as far as I can remember anyhow.  The plan for 2.5 is to come
up with and agree upon once and for all (and it seems that it's been
mostly done too).  The question I asked is why do you want to make a
vmlinux that runs on large groups of totally unrelated, save for a CPU
family, mostly, group of computers.

If someone really wanted, they could put 8xx and 4xx into this mess too,
with some complex asm, and have 1 kernel that boots on 4xx/6xx/7xx/74xx/8xx.
I doubt it'd be useful, but it could be done.

>
> MS
>

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

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