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 at lists.linuxppc.org
[mailto:owner-linuxppc-embedded at lists.linuxppc.org]On Behalf Of Dan
Malek
Sent: Wednesday, May 24, 2000 1:03 PM
To: mporter at mvista.com
Cc: tjroberts at lucent.com; linuxppc-embedded at 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/