Re: QUERY: Embedded PowerPC Linux?

Re: QUERY: Embedded PowerPC Linux?

[Matt Porter]

[This message has also been posted.]
On Thu, 18 May 2000 13:57:16 -0500, Tom Roberts <tjroberts@lucent.com> wrote:
>	Our LSPS-1 board has 3 PPC604 100MHz CPUs with 16 MBytes of
>	SDRAM each, an ISA interface to the host, and a SCSA-bus
>	telephony interface. Our LSPS-2 board has 3 PPC750 200
>	MHz CPUs with 64 MBytes of SDRAM each, a PCI interface to
>	the host, and an H.110 telephony interface. These boards have
>	no conventional computer peripherals, and can only communicate
>	with the host via memory. We have sample versions of this
>	latter board with PPC755 CPUs and PPC7400 CPUs, and 128 MBytes
>	SDRAM per CPU -- these are our real interest for Linux. it
>	is likely that in the future we will add Ethernet interfaces
>	to our boards.
>
>I downloaded the Yellowdog PPC linux source, and am attempting to
>configure it to boot on our PowerPC board (single CPU, 48 MB SDRAM).
>This board has no I/O whatsoever (except an H.110 telephony interface
>for which I'll have to write a driver). I already have written a driver
>which communicates via memory buffers to/from the host, and have tested
>it using stub code based upon our proprietary on-board OS.
>
>
>The problem is: this Linux distribution thinks that anything which is
>not a PPC8xx is a Macintosh of some sort or another. So I have been
>searching out CONFIG_PMAC (and others) and adding in my own CONFIG_LSPS
>as appropriate. This means removing large numbers of drivers and
>initialization files, and is not very pretty. The hard part is those
>confounded "#ifndef CONFIG_8xx" some of which I need to keep and
>some of which I must replace....
>
>Is there a better distribution to start from than Yellowdog for such
>bare-bones hardware? So far all of the "embedded PowerPC" links I
>have found share the assumption that "embedded" means a PPC8xx;
>my embedded processors are MPC604, MPC750, MPC755, and MPC7400; and
>they are embedded so deeply that they have no conventional I/O at all.

You are talking about a different distribution to start from but that is
really just a collection of apps and tools centered around the Linux
kernel itself.  If I understand correctly, you are concerned about the
fact that the kernel itself doesn't seem very aware of embedded 6xx/7xx/7xxx
systems.  Well, that's true.  The assumption is that 6xx/7xx/7xxx are only
chrp/pmac/prep desktop systems and 8xx/82xx are embedded systems but that
is changing quickly.

I've worked on several embedded 750 ports recently in which I've implemented
some preliminary concepts that should make things _much_ easier when porting
embedded 6xx/7xx systems that don't conform to chrp/pmac/prep specs.

You basically follow MACH_prep and/or MACH_gemini since they are much
simpler than pmac.  Provide kernel/head.S, mm/init.c, and kernel/setup.c
changes where necessary for your MACH type.  I generally prefer setting
up a PReP style memmap unless I'm on a CPCI board and need all that extra
PCI mem space (to map other boards RAM into).

Board specific support should go into kernel/<board>_setup.c, <board>_pci.c,
<board>_pic.c, <board>_time.c, <board>_stubs.c.  <board>_stubs.c is where
I stub out all the chrp/pmac/prep garbage like "prom_init()" to make the
linker happy and have a reasonablly slim kernel for 29F040 boot flashes.
..._pic.c and ..._time.c are new since <board>_setup.c is getting to be
too lengthy for my tastes.  <board>pci.c has something new in that
I'm adding a (rather simplistic) PCI autoconfig routine to the pci_init()
call since a firmware/monitor is not always available or desired.

Everything to this point is non-intrusive into the current arch/ppc
build process which is good.  The only intrusive thing I add is is a
CONFIG_EMBEDDED which arch/ppc/kernel/Makefile keys off of to not link
in all the extra chrp/pmac/prep stuff as well as not linking in the
drivers/macintosh/ library archive.  An embedded port simply sets up
config.in to define CONFIG_EMBEDDED when their board is selected from
the machine type selection.

One sore point is that MACH_<board> is defined as a single bit flag so we
will run out of those with the many MACH types that want to be in the
kernel in the near future.  That should probably get fixed up to something
with more longevity.

The other thing that needs to happen is that the directory structure
will need a reorg to avoid clutter since each port that is merged into
the kernel will add 2-6 files to arch/ppc/kernel/.  I would really
like to see a structure more like arch/ppc/kernel/<system1>,<system2>,etc.
Perhaps the system dependent files belong in arch/ppc/system/<system1>,etc..
Cort has been receptive to something like this in the past, I just like
some input before "showing the code". :)

I've Cc'ed linuxppc-embedded to move the discussion there where it
really belongs.

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

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

Re: QUERY: Embedded PowerPC Linux?

[Matt Porter]

[This message has also been posted.]
On Sun, 21 May 2000 20:46:47 -0500, Tom Roberts <TomRoberts@chicago.avenew.com>
 wrote:
>Matt Porter wrote:
>> I've worked on several embedded 750 ports recently in which I've implemented
>> some preliminary concepts that should make things _much_ easier when porting
>> embedded 6xx/7xx systems that don't conform to chrp/pmac/prep specs.
>>
>> You basically follow MACH_prep and/or MACH_gemini since they are much
>> simpler than pmac.  Provide kernel/head.S, mm/init.c, and kernel/setup.c
>> changes where necessary for your MACH type.  I generally prefer setting
>> up a PReP style memmap unless I'm on a CPCI board and need all that extra
>> PCI mem space (to map other boards RAM into).
>
>Good advice, and that's what I was doing. However -- head.S is
>incredibly convuoluted and complicated -- it's like someone insisted on
>shaving nanoseconds and bytes everywhere possible, which is silly given
>the rest of Linux....

head.S is the start of everything.  Look at romInit.s in VxWorks or the
equivalent in another RTOS.  Jumping through the early hoops to setup
memory management and the like is usually ugly.  This isn't to say that
head.S isn't ugly, it is.  Obviously the tons of #ifdefs do not make
the code very readable but it is a design decision that ensures that
memory management (and other core changes) don't have to be spread
throughout many files for every board that shares the same processor.
I know firsthand that adding a generic change that affects VxWorks BSPs
is a nightmare simply because each BSP is a completely independent set
of files.

>My other problem is that I do not have any sort of boot ROM, and
>head.S does not fully initialize the CPU. I am running on an MPC604,
>and I cannot get it to execute past the point where the icache is
>enabled (enabling the dcache is OK). I can boot another OS on the
>board (which it just so happens I wrote), and I put the complete CPU
>initialization of that OS in before jumping to address 0 -- no go.

Again, we are talking about kernel/head.S, right?  Well, no.  Linux
isn't going to be what you want it to be into you add to it.  The
kernel/head.S entry point assumes that it came from a firmware spawned
bootloader that set up these things.

This particular problem sounds rather odd, if possible it would help if
you could post your early init code (that you merged from your own
OS) and the modified head.S somewhere and give a pointer to it.

I have several ports in which I simply set the MSR to a known value,
disable/invalidate icache/dcache/L2cache, clear the BATs, configure
the memory controller/PCI bridge, and then set R4-7 to know values from
a JTAG emulator script.  I can simply load/boot vmlinux at this point with
no problems.

>> One sore point is that MACH_<board> is defined as a single bit flag so we
>> will run out of those with the many MACH types that want to be in the
>> kernel in the near future.  That should probably get fixed up to something
>> with more longevity.
>
>It is not clear to me that a single build will support multiple
>boards/machines.

Look for CONFIG_PPC_ALL and read the Makefiles to see the instances of
all the chrp*.o, pmac*.o, and prep*.o objects being linked together.
System type is determined at runtime.

>I think we need to separate the CPU from the machine....

It's being worked on as far as making a framework for non-chrp/pmac/prep
6xx/7xx/74xx ports.  There just hasn't been a real pressing need until
lately.

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

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

Re: QUERY: Embedded PowerPC Linux?

[Dan Malek]

Matt Porter wrote:


> .....  The assumption is that 6xx/7xx/7xxx are only
> chrp/pmac/prep desktop systems and 8xx/82xx are embedded systems but that
> is changing quickly.

Some further information.  The 8240 it really a 603/PCI configuration.
I followed Cort's Gemini port for most of this.  The 8260 is a 603 along
the path of the 8xx/CPM configuration.

> I stub out all the chrp/pmac/prep garbage like "prom_init()" to make the
> linker happy and have a reasonablly slim kernel for 29F040 boot flashes.

We should try to find some common compressed boot image as well, or
better define why they are different.  I started the 'mbxboot' long
ago with the 8xx processors, and it has proved useful for the 8260
as well.  It seems to be the place where all of the highly integrated
processors boot because of their unique I/O devices.  The 'coffboot'
directory is where all of the standard I/O (like PCI with 165xx serial
ports) boards exist.


> I'm adding a (rather simplistic) PCI autoconfig routine to the pci_init()
> call since a firmware/monitor is not always available or desired.

Is this the right place for it, or should it be done prior to calling
the Linux kernel?  I don't really know.  I have done this in both
places, each has advantages and disadvantages.  For further discussion
I am even considering a "PCI emulation" set of functions.  There are
more and more boards with PCI type I/O devices, but attached to the
processor busses instead of through a PCI bridge.  It would be nice to
use the standard PCI drivers, but right now I have to hack up something
custom because the PCI configuration functions don't make sense.  I
think it would be useful to have these functions return something useful
and use the standard driver.  Anyone else see this type of board design?

> .......  The only intrusive thing I add is is a
> CONFIG_EMBEDDED which arch/ppc/kernel/Makefile keys off of to not link

Thank you.  That seems like a good thing.

> One sore point is that MACH_<board> is defined as a single bit flag so we
> will run out of those with the many MACH types that want to be in the
> kernel in the near future.  That should probably get fixed up to something
> with more longevity.

I could never understand why this was a bit flag.  I think it would
work equally well as a unique number, preferably monotonically increasing.
These are used in switch statements and tested for their value.  I
don't remember anything like 'if (_machine & MACH_<board>)'.

> The other thing that needs to happen is that the directory structure
> will need a reorg to avoid clutter

Think very carefully about this.  A while back we broke head.S into
head.S and head_8xx.S to avoid "clutter".  I wish we had not done that
now.  There have been changes in the memory management and context
switching that are done in head.S, and not to head_8xx.S (or attempted
and not completed).  When generic changes are made, you have to visit
all of the files affected and it is easy to miss them or ignore your
duty to do so when they are separated.  I am all for avoiding the
clutter in the files, but if you are in there making changes it should
serve as a reminder that you are affecting many things you may have
not considered.


	-- Dan

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

Re: QUERY: Embedded PowerPC Linux?

[Dan Malek]

Matt Porter wrote:

> >Good advice, and that's what I was doing. However -- head.S is
> >incredibly convuoluted and complicated -- it's like someone insisted on
> >shaving nanoseconds and bytes everywhere possible, which is silly given
> >the rest of Linux....
>
> head.S is the start of everything.


There is nothing that should be modified in kernel/head.S for any
board/system port.  This file looks convoluted and complicated because
we are working with limited resources, touching special processor
registers and changing processor state.  There may be situations where it
appears we are trying to shave nanoseconds, but this is often due to
alignment or other processor restrictions.  While the techniques may
look the same, the reasons are different.


> >My other problem is that I do not have any sort of boot ROM, and

> Again, we are talking about kernel/head.S, right?  Well, no.  Linux
> isn't going to be what you want it to be into you add to it.  The

I will continue to point out that the Linux kernel is not a boot rom.
You first argue that head.S is too complicated, and then want to make
it initialize your processor???  I don't get it.  This is not the place
for processor initialization beyond what is necessary for Linux to
operate.  There is software in arch/ppc/mbxboot that does a little
more processor initialization for embedded systems, but that still isn't
a boot rom.

Further, writing processor initilization functions is very tedious. I
certainly don't want to be downloading a half megabyte or more of kernel
just to test a few processor initialization instructions.  When the
kernel doesn't boot, where do you start?

For example, if you write some minimal boot rom to initialize an 8xx
or 82xx processor, verify that you can read/write memory, you can boot
a Linux kernel very quickly.  If you have a boot rom, I can have a Linux
kernel running in a day or two by changing a couple of lines of code
in arch/ppc/mbxboot/embed_config.c.  Set up an environment for Linux
to run, and it does so very easily.

> I have several ports in which I simply set the MSR to a known value, ...
> .....  I can simply load/boot vmlinux at this point with
> no problems.

Absolutely.  The code within the Linux kernel is known to work on
all of these processors.  The more you change it, the less likely this
is to happen.  Localize your initialization outside of the kernel,
make it look like something that exists as much as possible, and you
are running very quickly.

> >I think we need to separate the CPU from the machine....
>
> It's being worked on as far as making a framework for non-chrp/pmac/prep
> 6xx/7xx/74xx ports.  There just hasn't been a real pressing need until
> lately.

The CPU and system/board are separate.  Some boards imply a particular
CPU, or vice versa.  You have to specify both for the configuration,
and depending upon which you ask first, you can reduce the selection
set for the latter.  Updating the configuration choices is just part
of adding a new board or processor.



	-- Dan

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

RE: QUERY: Embedded PowerPC Linux?

[Jason Wohlgemuth]

Dan,

I actually modified head.S, not to get linux running, but to reboot the
system.  In our case, the gpio pin tied to the HRESET line actually reset
several boards, which would be a bad thing in some cases.  So I modified the
m8xx_gorom (I think), and messed with the PLPRCR to setup the auto-reset on
a checkstop, then cleared the DER and set something in the MSR to kick it
into a checkstop mode upon a machine check, and then caused a machine check
to reset it.  It was rather convoluted and I didn't really feel all that
great about it.  Do you think I should go back and do something else in the
m8xx_restart code inside m8xx_setup.c?  We used to use some code their that
just jumped to our bootrom's physical start address, but due to AMD's sector
protection idiosyncrocies, we had to move our bootrom and do some tricky
chip select changes and memory shadowing to get everything to boot correctly
and be able to independently sector protect the bootrom's sector; this
prevented us from jumping to the physical address at a later time.  Other
than that no changes were made, if I clean up that reset trick and it is
actually a good idea, rather than a crappy hack (in your opinion), I'll
clean it up a little and post it.  I probably should have gone to
ftp.mvista.com and looked what you all are currently doing.

Thanks,
Jason

-----Original Message-----
From: owner-linuxppc-embedded@lists.linuxppc.org
[mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf Of Dan
Malek
Sent: Wednesday, May 24, 2000 1:03 PM
To: mporter@mvista.com
Cc: tjroberts@lucent.com; linuxppc-embedded@lists.linuxppc.org
Subject: Re: QUERY: Embedded PowerPC Linux?



Matt Porter wrote:

> >Good advice, and that's what I was doing. However -- head.S is
> >incredibly convuoluted and complicated -- it's like someone insisted on
> >shaving nanoseconds and bytes everywhere possible, which is silly given
> >the rest of Linux....
>
> head.S is the start of everything.


There is nothing that should be modified in kernel/head.S for any
board/system port.  This file looks convoluted and complicated because
we are working with limited resources, touching special processor
registers and changing processor state.  There may be situations where it
appears we are trying to shave nanoseconds, but this is often due to
alignment or other processor restrictions.  While the techniques may
look the same, the reasons are different.


> >My other problem is that I do not have any sort of boot ROM, and

> Again, we are talking about kernel/head.S, right?  Well, no.  Linux
> isn't going to be what you want it to be into you add to it.  The

I will continue to point out that the Linux kernel is not a boot rom.
You first argue that head.S is too complicated, and then want to make
it initialize your processor???  I don't get it.  This is not the place
for processor initialization beyond what is necessary for Linux to
operate.  There is software in arch/ppc/mbxboot that does a little
more processor initialization for embedded systems, but that still isn't
a boot rom.

Further, writing processor initilization functions is very tedious. I
certainly don't want to be downloading a half megabyte or more of kernel
just to test a few processor initialization instructions.  When the
kernel doesn't boot, where do you start?

For example, if you write some minimal boot rom to initialize an 8xx
or 82xx processor, verify that you can read/write memory, you can boot
a Linux kernel very quickly.  If you have a boot rom, I can have a Linux
kernel running in a day or two by changing a couple of lines of code
in arch/ppc/mbxboot/embed_config.c.  Set up an environment for Linux
to run, and it does so very easily.

> I have several ports in which I simply set the MSR to a known value, ...
> .....  I can simply load/boot vmlinux at this point with
> no problems.

Absolutely.  The code within the Linux kernel is known to work on
all of these processors.  The more you change it, the less likely this
is to happen.  Localize your initialization outside of the kernel,
make it look like something that exists as much as possible, and you
are running very quickly.

> >I think we need to separate the CPU from the machine....
>
> It's being worked on as far as making a framework for non-chrp/pmac/prep
> 6xx/7xx/74xx ports.  There just hasn't been a real pressing need until
> lately.

The CPU and system/board are separate.  Some boards imply a particular
CPU, or vice versa.  You have to specify both for the configuration,
and depending upon which you ask first, you can reduce the selection
set for the latter.  Updating the configuration choices is just part
of adding a new board or processor.



	-- Dan


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

Re: QUERY: Embedded PowerPC Linux?

[Dan Malek]

Jason Wohlgemuth wrote:
>
> Dan,
>
> I actually modified head.S, not to get linux running, but to reboot the
> system.  In our case, the gpio pin tied to the HRESET line actually reset
> several boards, which would be a bad thing in some cases.  So I modified the
> m8xx_gorom (I think),

Sure, pick on the one thing I constantly mess up across the various
releases and patches :-).  I don't even know why this function is
in this file, as it needs to be different for almost every board.
It is only a couple of lines of code, so have fun.

I am more concerned about messing up the kernel initialization
code.  There are many assumptions (valid) that are made here about
the rest of the kernel structure.  Similar to having unique processor
and board initialization somewhere, this is unique to the Linux
kernel.


	-- Dan

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

Re: QUERY: Embedded PowerPC Linux?

[Dan Malek]

Matt Porter wrote:

> I think an embedded 6xx/7xx bootloader will remain separate since
> most of these systems fall into mapping something close to PReP or CHRP

OK.  I guess what I was really trying to say is the 8xx and 8260
directory is focused on the processors with the integrated peripherals.
The other directories have loaders that try to map (more or less)
standard UARTs and other I/O through some bridge.

> ......  Off
> topic: any chance we can change the "mbxboot" name?  It's kinda funny
> since MBX is EOLed or on it's way to being EOLed.

I guess.  It is probably easier now with BitKeeper that it was before
with CVS.  Should we start a poll on LinuxDevices :-)?

> Hmmm...prepboot has 165xx support as well...which is what I've adapted for
> my ports.

OK.  I just remember that when I did the 8240/Sandpoint, it fit one of the
other loader directories better than the 8xx.  I didn't really understand
what was where, but I did get a compressed zImage with little trouble.


> I'm curious, what do you see as the disadvantages to enumerating the bus
> late in the game?

You have to actually build the Linux kernel with knowledge of the
specific devices that are on the bus and how you want them configured.
If you keep this out of the kernel, it is more "generic" (along the
lines of a workstation kernel) and you can configure the kernel with
more driver support flexibility.

> ....  I like just hooking up my indirect config space method
> and using those calls rather than building something new the independent
> bootloader.

I understand.  It's not a big deal, as it appears the kernel is taking
on more of the functions that a properly working BIOS should perform.
This process has to happen someplace, and since embedded boards tend to
have a rather simplistic boot rom (if any) it has to be further up the
food chain.

> Sounds neat.

Like lots of other things on my list :-).

> Exactly.  I can easily see over 32 MACH_<board>'s in the next year.

OK.  I guess that's two votes :-).  I recently removed the detailed
8xx processor type (you don't need to specificy 823, 850, 860, etc.,
just 8xx now).

> Whoops.  I should have elaborated a bit more.  I've discussed this in
> detail with Cort a while back and he seemed receptive to my idea of a
> mostly cosmetic restructuring (it's at least a first phase).

OK.  The PowerPC is certainly unique among the architectures for the
number of different kinds of boards and processors it has to support,
so we have to do something.  It would be nice to keep as much common
as possible, and try to avoid the temptation to just blow stuff into
a new directory rather than merge it.

> Since I've only done 6xx/7xx work I'm not real sure where the 8xx stuff
> fits into my view but the 6xx/7xx can probably be changed independently
> for the first cut at this.

The 8xx shouldn't be much different.  It follows the same structure
as other platforms in the kernel directory.  The challenge is the
8260 and some of the upcoming processors.  It is a hybrid that fits
nicely in the 8xx structure, but it is also a 603.....

> It would now have something like:
>
> arch/ppc/kernel/
>                 chrp
>                 gemini
>                 pmac
>                 prep
>                 <port a>
>                 <port b>
>
> The generic stuff would either stay in kernel/ or move to kernel/common/
> Since all of this is board/arch specific code, there is no maintainence
> concern like when you split head.S for a different processor architecture.

Go for it.  Assume an 8xx directory for now.  This will have all of the
8xx and 8260 stuff in it.  The differences among the 8xx/8260 board
implementations are small enough they don't require separate directories.
I am assuming (hoping :-) things like head.S will remain in the common
area.  I use head.S for the 8260.


> Next it would be great to abstract the find_end_of_memory calls from
> setup.c so it's not necessary to add a new condition to call a board
> specific routine if the kernel.

How about we just "ppc_md" this stuff and make that structure
initialized by the linker?  I think the ppc_md abstraction has proven
quite useful, and this seems like a logical thing to put there.

> In between deadlines I'm experimenting with some different layouts so
> eventually I'll pass something more solid in front of folks.

Have fun :-).


	-- Dan

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

Re: QUERY: Embedded PowerPC Linux?

[Matt Porter]

On Wed, May 24, 2000 at 12:30:21PM -0400, Dan Malek wrote:
> Matt Porter wrote:
> > I stub out all the chrp/pmac/prep garbage like "prom_init()" to make the
> > linker happy and have a reasonablly slim kernel for 29F040 boot flashes.
>
> We should try to find some common compressed boot image as well, or
> better define why they are different.  I started the 'mbxboot' long
> ago with the 8xx processors, and it has proved useful for the 8260
> as well.  It seems to be the place where all of the highly integrated
> processors boot because of their unique I/O devices.  The 'coffboot'
> directory is where all of the standard I/O (like PCI with 165xx serial
> ports) boards exist.

I think an embedded 6xx/7xx bootloader will remain separate since
most of these systems fall into mapping something close to PReP or CHRP
(even if they have a flexible bridge, unlike the Mot. Semi ones).  Off
topic: any chance we can change the "mbxboot" name?  It's kinda funny
since MBX is EOLed or on it's way to being EOLed.

Hmmm...prepboot has 165xx support as well...which is what I've adapted for
my ports.

> > I'm adding a (rather simplistic) PCI autoconfig routine to the pci_init()
> > call since a firmware/monitor is not always available or desired.
>
> Is this the right place for it, or should it be done prior to calling
> the Linux kernel?  I don't really know.  I have done this in both
> places, each has advantages and disadvantages.  For further discussion

I'm curious, what do you see as the disadvantages to enumerating the bus
late in the game?  I like just hooking up my indirect config space method
and using those calls rather than building something new the independent
bootloader.

> I am even considering a "PCI emulation" set of functions.  There are
> more and more boards with PCI type I/O devices, but attached to the
> processor busses instead of through a PCI bridge.  It would be nice to
> use the standard PCI drivers, but right now I have to hack up something
> custom because the PCI configuration functions don't make sense.  I
> think it would be useful to have these functions return something useful
> and use the standard driver.  Anyone else see this type of board design?

Sounds neat.

> > .......  The only intrusive thing I add is is a
> > CONFIG_EMBEDDED which arch/ppc/kernel/Makefile keys off of to not link
>
> Thank you.  That seems like a good thing.
>
> > One sore point is that MACH_<board> is defined as a single bit flag so we
> > will run out of those with the many MACH types that want to be in the
> > kernel in the near future.  That should probably get fixed up to something
> > with more longevity.
>
> I could never understand why this was a bit flag.  I think it would
> work equally well as a unique number, preferably monotonically increasing.
> These are used in switch statements and tested for their value.  I
> don't remember anything like 'if (_machine & MACH_<board>)'.

Exactly.  I can easily see over 32 MACH_<board>'s in the next year.

> > The other thing that needs to happen is that the directory structure
> > will need a reorg to avoid clutter
>
> Think very carefully about this.  A while back we broke head.S into
> head.S and head_8xx.S to avoid "clutter".  I wish we had not done that
> now.  There have been changes in the memory management and context
> switching that are done in head.S, and not to head_8xx.S (or attempted
> and not completed).  When generic changes are made, you have to visit
> all of the files affected and it is easy to miss them or ignore your
> duty to do so when they are separated.  I am all for avoiding the
> clutter in the files, but if you are in there making changes it should
> serve as a reminder that you are affecting many things you may have
> not considered.

Whoops.  I should have elaborated a bit more.  I've discussed this in
detail with Cort a while back and he seemed receptive to my idea of a
mostly cosmetic restructuring (it's at least a first phase).

Since I've only done 6xx/7xx work I'm not real sure where the 8xx stuff
fits into my view but the 6xx/7xx can probably be changed independently
for the first cut at this.

I'm basically looking at reorganizing directories plus the necessary
Makefile changes to reduce the klutter in arch/ppc/kernel/

It would now have something like:

arch/ppc/kernel/
		chrp
		gemini
		pmac
		prep
		<port a>
		<port b>

The generic stuff would either stay in kernel/ or move to kernel/common/
Since all of this is board/arch specific code, there is no maintainence
concern like when you split head.S for a different processor architecture.

I'm thinking that bootloaders should possibly move a little bit but
they're the least of my concern.

The next thing that goes with this is to free some of the independent
code from board specific files.  A good example is the m48t35 RTC driver
that is buried in the gemini_time.c.  Why not make it obvious to a
developer that the building block already exists?  I've already done
this for my current project but there are more things like that.

Next it would be great to abstract the find_end_of_memory calls from
setup.c so it's not necessary to add a new condition to call a board
specific routine if the kernel. Same thing in mm/init.c where the BATS
are set on non-8xx's.  The idea is to get to a point where it's only
necessary to add a few make rules and a directory of implement calls
for an existing processor family.

In between deadlines I'm experimenting with some different layouts so
eventually I'll pass something more solid in front of folks.

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

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

Re: QUERY: Embedded PowerPC Linux?

[Matt Porter]

On Wed, May 24, 2000 at 01:03:25PM -0400, Dan Malek wrote:
> I will continue to point out that the Linux kernel is not a boot rom.
> You first argue that head.S is too complicated, and then want to make
> it initialize your processor???  I don't get it.  This is not the place
> for processor initialization beyond what is necessary for Linux to
> operate.  There is software in arch/ppc/mbxboot that does a little
> more processor initialization for embedded systems, but that still isn't
> a boot rom.

I think you got the attributions confused...Tom was trying use kernel/head.S
to init the processor.

> Further, writing processor initilization functions is very tedious. I
> certainly don't want to be downloading a half megabyte or more of kernel
> just to test a few processor initialization instructions.  When the
> kernel doesn't boot, where do you start?

I think it's even more difficult for 7xx than on 8xx/82xx stuff since
varying bridges and potentially an ISA bridge (shudder) make it a completely
different game on every system.

> For example, if you write some minimal boot rom to initialize an 8xx
> or 82xx processor, verify that you can read/write memory, you can boot
> a Linux kernel very quickly.  If you have a boot rom, I can have a Linux
> kernel running in a day or two by changing a couple of lines of code
> in arch/ppc/mbxboot/embed_config.c.  Set up an environment for Linux
> to run, and it does so very easily.

No argument.  Obviously, having bootrom/monitor/firmware takes a _vast_
amount of the difficult work out of a port.

> > >I think we need to separate the CPU from the machine....
> >
> > It's being worked on as far as making a framework for non-chrp/pmac/prep
> > 6xx/7xx/74xx ports.  There just hasn't been a real pressing need until
> > lately.
>
> The CPU and system/board are separate.  Some boards imply a particular
> CPU, or vice versa.  You have to specify both for the configuration,
> and depending upon which you ask first, you can reduce the selection
> set for the latter.  Updating the configuration choices is just part
> of adding a new board or processor.

So it seems on the surface, but I was referring to shortcuts made where
ifndef 8XX conditionals are used to conditionally build things like
the drivers/macintosh/ archive when that is not processor specific action.
Similar things happen in the Makefiles to achieve a slimmer kernel.

The point being that the approach taken by the gemini architecture boards
is not a great one since it simply tacks it's objects onto the bloated
chrp/pmac/prep kernel image.  Not pretty and not a suitable approach
when many 6xx/7xx boards need to boot directly from a 512KB flash.

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

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

Re: QUERY: Embedded PowerPC Linux?

[Murray Jensen]

On Wed, 7 Jun 2000 22:56:17 -0700, Matt Porter <mmporter@home.com> writes:
>I'm basically looking at reorganizing directories plus the necessary
>Makefile changes to reduce the klutter in arch/ppc/kernel/
>
>It would now have something like:
>
>arch/ppc/kernel/
>		chrp
>		gemini
>		pmac
>		prep
>		<port a>
>		<port b>
>
>The generic stuff would either stay in kernel/ or move to kernel/common/

How about this:

	arch/ppc/
		boot/
		io/
		kernel/
		mm/

		4xx/
			boot/
			io/
			kernel/
			mm/
		8xx/
			boot/
			io/
			kernel/
			mm/
		8260/
			boot/
			io/
			kernel/
			mm/
		chrp/
			boot/
			io/
			kernel/
			mm/
		gemini/
			boot/
			io/
			kernel/
			mm/
		pmac/
			boot/
			io/
			kernel/
			mm/
		prep/
			boot/
			io/
			kernel/
			mm/

Not all the directories would exist in all the platform directories, of
course. Some platforms might use another's directory - or bits therein
(e.g. if I had a cogent directory, I'd have a boot/ and io/ directory,
but no kernel/ or mm/ directory - for these I'd use 8xx/kernel/ and 8xx/mm/
with a few #ifdefs in there (if I had the 8xx cpu module, if I had the
cogent CMA282 8260 cpu module, I would use 8260/kernel/ and 8260/mm/). The
cogent/boot/ directory would only have a tty.c driver, the rest would come
from 8xx/boot/ - and the tty driver might not be used if you were to use the
devices on the cpu module, not on the motherboard. I might use both 8xx/io/
and cogent/io/ directories for generic 8xx commproc devices, and cogent
motherboard devices. For cpu module specific cogent devices - i.e. devices
on the cpu module, not the motherboard, I might have cogent/io/8xx/ and
cogent/io/8260/ etc.).

Each <port>/kernel/ directory might have some or all of: head.S, nvram.c,
pci.c, pic.c, prom.c, setup.c, time.c. The <port>/mm directory might have
fault.c, init.c, tlb.c (actually, there might not be any <port>/mm/
directories, there doesn't appear to be enough differences to warrant it -
but the option is there).

I'm not sure I like this - just throwing it into the air. Others that have
been hacking this stuff longer might have a better feel for how difficult
such a structure would be to maintain, and whether the advantages (if any)
are worth it. Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@cmst.csiro.au  (old address was mjj@mlb.dmt.csiro.au)


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