QUERY: Embedded PowerPC Linux?

[Matt Porter]

[This message has also been posted.]
On Sun, 21 May 2000 20:46:47 -0500, Tom Roberts <TomRoberts at 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 at mvista.com

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