Help booting MBX through bootd
wd at denx.muc.de
Fri Jun 11 06:24:11 EST 1999
in message <375FB1BE.1789E049 at switchboard.ericsson.se> Magnus Damm
> There are a few problems today with 8xx linux.
> People out there: Correct me if I'm wrong.
Ok, I'll comment on this; I intended to summarize my experience with
my firsrt port of 2.2p7 and 2.2.5 to a custom board anyway, so here
> I blame some of the strange problems on silicon bugs
> in the mpc860 chip. Read the chip errata.
This is indeed a problem. Many (old) MBX boards have old revisions of
the 860, which have some severe problems. Especially the data cache
corruption bug hits hard. Make sure that you have a silicon revision
C1 at least.
> My MBX board has a XPC860ENZPA.
Maybe it's a A. The mask revision is encoded in the low 8 bits of the
IMMR. Check there!
> I think I have a C1 chip on a other board which works better.
> The memory management is a bit strange.
> On some boards is it neccesary to reserve a few tlb entries.
I haven't seen this so far. But all my CPU's were mask revision C1.
> One other problem is that the 8xx series don't have a fpu.
> That is not a kernel problem, more a libc problem.
No, this *is* a kernel problem. When running some applications you
will find quite a lot that will produce "Bad emulation" / "Illegal
Instruction" exceptions. So far the suggested solution is to compile
the relevant code with `-mcpu=860'. But this solves only some
Linux on the 860 makes only sense for a certain class of projects:
embedded systems, especially in telecomminucations. While it *is*
easy to compile the target application so that it does not need the
FP emulation, we also must provide a *development* environment, both
for application and driver code. In many cases the easiest solution
is native development on the target, running with a complete Linux
environment using a NFS mounted root filesystem. And this implies
that *every* application must run on the 860, may it be perl or awk
or date or anything else.
Either we can use any standard PPC distribution for that, or we would
have to recompile *everything*, from the standard libraries to the
last tool anybody might ever use. Is there anybody who volunteers to
provide up-to-date MPC8xx Linux releases? No, this doesn't make
The FP emulation should be fixed so that it allows to run *any* PPC
Linux binary on the 8xx, too.
Leif Lindholm <Leif.Lindholm at uab.ericsson.se> volunteers to implement
the missing instructions, starting a couple of weeks from now.
> The last problem I know is that the 8xx has a smaller
> (4 words) cahce line length compared to 60x.
Is this really a problem?
I noticed some other problems in the (2.2.5) MBX8xx code:
* There are multiple versions of the same functions, for instance
udelay (for the kernel as assembler inline in include/asm-ppc/delay.h,
for the boot code in arch/ppc/mbxboot/head.S).
* I don't think the udelay in arch/ppc/mbxboot/head.S provides really
the timing it's supposed to give; not even on 66 MHz systems.
* The whole file arch/ppc/mbxboot/head.S is a complex mix of
#ifdef'ed and #ifndef'ed code - trying to add yet another bard
architecture is a nightmare. It was much easier to me to _remove_
all the unneeded cases and write a new version for my own board
* We should keep in mind that we will have to support a growing
number of custom boards. IMHO we *must* find a way to separate
hardware dependend code into asmalls et of configuration files -
something like the BSP's (board support packages) you get for
commercial RTOS. Just to give an example: how many files do you
have to change when you want to run your MBX860 board with another
console speed than the default 9600 bps? And how do you find all
those places? Are you sure you didn't forget a few places where the
bus clock is hard coded?
There is already provision for the board information data -
something like that should be used for all hardware versions. [This
is what I did for my ports; once done, it saved me a lot of work.]
Another are of problems is port pin assignement and CPM configu-
ration in general. Which SCC is used for your ethernet interface?
Which BRG's does it use? Is your console on a SMC or a SCC? Which
port pins have to be used? Which clocks? Etc. etc. - right now this
configuration is distributed to many places in the code, which
makes changes in the configuration difficult.
I don't think I'm the first who notices this problem. Is there
already any work being done in this direction?
* Does the reset code in m8xx_gorom() [arch/ppc/kernel/head.S] work
for somebody? I could not get it working on the MBX board, nor did
it work on the custom 860 boards I've seen so far. In all cases the
system just hangs, I have to manually reset them. Any ideas why?
Phone: (+49)-8142-4596-87 Fax: -88 Home: -86 Email: wd at denx.muc.de
The only person who always got his work done by Friday
was Robinson Crusoe.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
More information about the Linuxppc-dev