Do I shoot myself in the foot first or HEAD.S?

Do I shoot myself in the foot first or HEAD.S?

[clark]

        Hey,

        Any tips for a new guy? I just about ready to start trying to port
linux to our custom MPC850 board.

        This is where I stand right now. I have at my disposal a MBX860
which I have managed to get linuxPPC to boot on. I have a copy of Hard Hat
Linux Journeyman Edition. I also have an EST VisionICE in circuit emulator.

        Now for the questions.

1. Is there a FAQ or Doc on porting the kernel to a new design? (please mail
or direct me to it)

2. Does anyone know if Hard Hat has any problems with Mandrake 7.0 linux?

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 )?

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?


Many many thanks if you can answer any of these questions for me.

        Conn Clark


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

Re: Do I shoot myself in the foot first or HEAD.S?

[Graham Stoney]

Hi Conn,

I'll have a shot at the ones I know about:

clark@esteem.com writes:
>         Any tips for a new guy? I just about ready to start trying to port
> linux to our custom MPC850 board.

You mentioned head.S; you shouldn't need to modify it at all. We didn't on our
custom 855T design.

> 1. Is there a FAQ or Doc on porting the kernel to a new design? (please mail
> or direct me to it)

There's 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 )?

I suggest porting PPCBOOT to it rather than starting from scratch yourself.
See:
    http://ppcboot.sourceforge.net/

Regards,
Graham

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

Re: Do I shoot myself in the foot first or HEAD.S?

[Wolfgang Denk]

In message <20000719013006.DDA67211@elph.research.canon.com.au>
Graham Stoney wrote:
>
> I suggest porting PPCBOOT to it rather than starting from scratch yourself.
> See:
>     http://ppcboot.sourceforge.net/

Please give me one more day to  write  at  least  a  minimal  set  of
documentation,  then  I'll put a completely new version of PPCBOOT on
the CVS serever at Sourceforge.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
To be a winner, all you need to give is all you have.

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

Re: Do I shoot myself in the foot first or HEAD.S?

[Wolfgang Denk]

Hi Clark,

in message <1.5.4.32.20000719011945.006845c0@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@denx.de
Lack of skill dictates economy of style.                - Joey Ramone

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

Re: Do I shoot myself in the foot first or HEAD.S?

[Steve Rossi]

clark@esteem.com wrote:

>
> 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?
>

We did use EST's VisionICE box to download linux kernel images to our target
hardware before we had a rom monitor with network loading. It was also helpful
to debug the early boot stuff when we were porting to custom hardware - before
the memory management is enabled. Once the memory manager is enabled, the
VisionICE becomes mostly useless, because as has been said many times on this
list - most BDM debuggers don't understand virtual addresses. Nevertheless the
VisionICE did offer some utility to us.
I wrote a little app that slaps an EST .bin file header on a linux image
(zvmlinux or zvmlinux.inird). I can send that to you if you want it. Then I use
Download to Target from VisionClick and that sticks the whole image in RAM. You
do need to disable VisionICE's interception of software breakpoint emulation
interrupts - do 'cf sbe special'. That should be it.

--
-------------------------------------------------------
Steven K. Rossi                     srossi@ccrl.mot.com
Staff Engineer
Multimedia Communications Research Laboratory
Motorola Labs
-------------------------------------------------------


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

Re: Do I shoot myself in the foot first or HEAD.S?

[Wolfgang Denk]

In message <3975B697.63313411@ccrl.mot.com> Steve Rossi wrote:
>
> I wrote a little app that slaps an EST .bin file header on a linux image
> (zvmlinux or zvmlinux.inird). I can send that to you if you want it. Then I use
> Download to Target from VisionClick and that sticks the whole image in RAM. You
> do need to disable VisionICE's interception of software breakpoint emulation
> interrupts - do 'cf sbe special'. That should be it.

BTW - included with the upcoming first public version of PPCBOOT is a
small tool (img2srec) which creates a srecord  file  from  zImage  or
zImage.initrd  files,  omitting unneeded stuff which is included when
just stripping the ELF header and then converting to S-records.  This
saves just another few bytes on the target :-)

Thanks to Ruedi Dummermuth of Abatron who provided this tool.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
There's no future in time travel.

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

Re: Do I shoot myself in the foot first or HEAD.S?

[Tom Roberts]

clark@esteem.com wrote:
> 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 )?

My startup code at 0xFFF00100 simply loads values into r3-r7 and then
jumps to physical address 0 (where vmlinux was loaded). But our hardware
is initialized from the host, not the on-board CPUs.


> 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 never figured out how to use any of that stuff. I debugged head.S
by using r11 and r12 (otherwise unused) to poke cookies into low
memory, and traced through head.S until it took off (:-)). But my
architecture may be different from yours -- I have a PPC board which
plugs into a host which can read/write the on-board RAM via the PCI
bus. So I could always dump memory on the board.

I had to develop custom console and network drivers using that PCI
memory-to-memory interface. I debugged them using our proprietary OS,
so once I threaded through head.S it was a short trip to a bash console
prompt. Once you get to start_kernel() I doubt any debugger will be of
much use (gdb perhaps, because it understands memory mapping, but the
ICE won't).


Several people have said "don't change head.S". I found I had to,
because my board is not anything like any of the CONFIG choices.
I did, at least, move it into my private directory and symlink it
back where it belongs; ditto for the half-dozen other files I had
to change.


Tom Roberts	tjroberts@lucent.com

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