From: Matt Porter <hidden> Date: 2000-05-23 05:10:56
[This message has also been posted.]
On Sun, 21 May 2000 20:46:47 -0500, Tom Roberts [off-list ref]
wrote:
Matt Porter wrote:
quoted
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.
quoted
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/
From: Dan Malek <hidden> Date: 2000-05-24 17:03:25
Matt Porter wrote:
quoted
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.
quoted
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.
quoted
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/
From: Jason Wohlgemuth <hidden> Date: 2000-05-24 23:54:49
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:
quoted
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.
quoted
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.
quoted
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/
From: Dan Malek <hidden> Date: 2000-05-25 01:54:10
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/