Do I shoot myself in the foot first or HEAD.S?
Wolfgang Denk
wd at denx.de
Wed Jul 19 18:13:11 EST 2000
Hi Clark,
in message <1.5.4.32.20000719011945.006845c0 at pop.esteem.com> you wrote:
>
> Any tips for a new guy? I just about ready to start trying to port
> linux to our custom MPC850 board.
Welcome aboard :-)
> 1. Is there a FAQ or Doc on porting the kernel to a new design? (please mail
> or direct me to it)
You mean additional to the sources? :-) See the HOWTO at
http://members.xoom.com/greyhams/linux/PowerPC-Embedded-HOWTO.html
> 3. What do I need to do in the ROM before jumping to HEAD.S other than
> programming the ram timmings in the UPM( I assume HEAD.S is where everything
> starts )?
This depends on which head.S you mean. If you're talking about
arch/ppc/mbxboot/head.S, then you're right (do NOT modify
arch/ppc/kernel/head.S!)
Yoou will have to modify either your boot ROM or the code in
arch/ppc/mbxboot/ to work with each other.
If you have the option to use a different firmware, and if you can wait a day
I'd suggest you have a look at PPCBOOT; see http://ppcboot.sourceforge.net/.
I have a completely new, redesigned version of PPCBOOT. Right now I'm
typing some documentation to the new code; I'll put it on the CVS
server later this day.
Major changes:
* All the code in arch/ppc/mbxboot/ is now obsolete, since it has
been integrated in PPCBOOT. You need a serial driver for the
monitor anyway to provide some sort of console interface, so why
duplicate this work in the Linux boot loader code?
Now we don't need to build zImage's; instead we use the "raw"
(usually compressed) Linux kernel in arch/ppc/coffboot/vmlinux.gz .
["usually compressed" because you can trade time for space, and use
an uncompressed kernel - this needs more Flash memory, but boots up
faster. The same is true for initrd images.]
* Linux kernel and ramdisk images are kept separate. You don't have
to rebuild a Linux kernel image just to change a file in your
initrd image. You can run the same kernel image with several
versions of initrd images. If you're designing a field-upgradable
system, you have separated packages, etc.
Of course this is work in progress, with lots of things missing or
not ready (booting over ethernet is in the works, PCMCIA/IDE support
will follow, etc.).
> 4. Has any one managed to get an EST VisionICE in circuit emulator to work
> with linuxPPc? If so How? Would I be better off using the GNU Debuger?
I think it VisionICE should work fine for the monitor and boot loader
code; I don't think it will be really useful for the Linux kernel
with MMU turned on (please correct me when I'm wrong).
I'm using the Abatron BDI200 because this fits really well in my
Linux environment: it speaks GDB remote protocol over ethernet, and
it supports the MMU for LInux, so you can even debug the Linux kernel
with it. And yes, the price is competitive, too.
I also use the MPCBDM which provides nearly the same features
(restrictions on type and bus interface for flash chip programming,
attaches to the parallel port so you need a LInux PC close to your
target) - let me know if you're interested in this tool but don't
feel like building one yourself.
Wolfgang
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
Lack of skill dictates economy of style. - Joey Ramone
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-embedded
mailing list