Basic questions about PPC embedded developement under Linux

Basic questions about PPC embedded developement under Linux

[Ron Flory]

hi-

 I've just joined this mailing list, and have a few basic questions
about PPC embedded developement under Linux.

 My application is not to run Linux on the ppc, but to use x86 Linux as
a cross-developement platform, thus allowing me to get away from
expensive, and substandard wondoze-based environments.

 I've set up cross-compilers, etc before, so that doesn't scare me too
much.  In my last job (after a some work) I was able to dump NT, and do
all my VxWorks developement under Linux.  It made life bearable.

 My primary concern is how to use GDB (or better yet, DDD) with a PPC
board via the DBM port.  Is there a Linux tool that permits initial
program download, register access, and debugging via the Moto standard
PPC BDM port ?

 If so, I'll push very hard to ensure Linux is the developement platform
for our next project-

ron flory

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

Re: Basic questions about PPC embedded developement under Linux

[Wolfgang Denk]

In message <38E8A5C1.349EE908@adtran.com> you wrote:
>
>  My primary concern is how to use GDB (or better yet, DDD) with a PPC
> board via the DBM port.  Is there a Linux tool that permits initial
> program download, register access, and debugging via the Moto standard
> PPC BDM port ?

You have several options, mostly  depending  on  how  much  work/time
and/or money you want to spend.

There are several do-it-yourself BDM kits available with interfaces
to GDB (and thus DDD), see for instance
http://www.vas-gmbh.de/software/mpcbdm/
The main problem with thse solutions is  usually  that  they  require
some soldering work, are not very fast, and don't support programming
FLASH memory.

There are also some vendors offerin full-grown BDM debuggers that run
in a Linux environment, for  instance  VisionICE  by  EST.  The  main
problem  with  these tools is that they don't integrate too well with
the Linux toolchain, i. e. you can't just get the  hardware  and  use
GDB  /  DDD,  but  instead you have to buy their commercial debugger.
This makes these solutions pretty expensive.


Then there is the BDI2000 by Abatron; it is pretty fast, you can  use
a  telnet  interface  for  low  level things, and it talks GDB Remote
Protocol (see http://www.abatron.ch/Manuals/ManGDBCOP-2000B.pdf). For
me this was the optimum solution - YMMV.

Additional goodies: Abatron is really responsive; within a  few  days
they  provided a configuration tool for the BDI2000 for Linux (so far
you had to configure the box using a Windows  box)  and  an  extended
firmware   version   which   understands  the  Linux  "zImage"  resp.
"zImage.initrd" formats.

[Disclaimer: No, I'm not payed  by  Abaron,  but  I  am  a  satisfied
customer.]

>  If so, I'll push very hard to ensure Linux is the developement platform
> for our next project-

Go for it!

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
I am a computer. I am dumber than any human and smarter than any  ad-
ministrator.

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

Re: Basic questions about PPC embedded developement under Linux

[Wolfgang Denk]

In message <38EA0716.47AA17BA@sympatico.ca> you wrote:
>
> What do you gain by "understanding" the linux image?

On the MPC8xx a Linux kernel image is usually an ELF binary file with
several sections, for instance like that:

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00004854  00180000  00180000  00010000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       000007bc  00184860  00184860  00014860  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         0000031c  00186000  00186000  00016000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .data.init    00000000  00187000  00187000  00017000  2**0
                  CONTENTS
  4 .bss          000031f8  00187000  00187000  00017000  2**2
                  ALLOC
  5 image         0007135d  00000000  00000000  00017000  2**0
                  CONTENTS, READONLY
  6 initrd        0008a502  00000000  00000000  0008835d  2**0
                  CONTENTS, READONLY

Most BDM debuggers I know will load only those sections  into  memory
(RAM or FLASH) that have the LOAD flag set (which is perfectly OK for
normal  binaries).  So  they will load only the text, rodata and data
sections which just contain the boot loader code - they will not load
the kernel image, nor the initial ramdisk image.

There are several tricks to work around this  (for  instance  packing
everything  into another ELF file where everything appears to be part
of the text segment, or stripping the ELF header and load as "unknown
binary format" when your tool supports it),  but  I  find  it  really
"nice"  that  the  Abatron  loads  the  whole Linux image without any
further tricks on my side.

> Another question, how useful is the BDM interface once the kernel has
> started running?  Can you leave GDB/BDI2000 connected to the target

That depends on what you want to do. You will probably NOT be able to
use it for source level kernel debigging - as soon as the MMU  is  on
(which happens really early) you need to know what your addresses are
"by hand".

> while the linux kernel is running?  I've seen in previous messages on
> the mailing list (by Dan Malek I believe) that a BDM debugger could
> interfere with the kernel operation.

This depends only on the configuration of the DER  register.  If  you
set it to a sensible value (for instance, 0x2002000F) it is perfectly
fine to keep the BDM debugger attached while running Linux (I'm doing
this all the time).

> I'm asking because I'd like to get a BDM debugger to help with writing
> the boot code of a custom MPC860 platform and I'm wondering if the BDM
> could thereafter be used to help debugging the linux kernel and user
> mode modules.  Today, I'm assuming that the BDM can only be used for
> boot code debugging and that a combination of xmon/gdbserver is better
> for the rest.
>
> Am I right?

Probably yes. However, you still have a  few  options  with  the  BDM
debugger  like  setting  breakpoints on whole ranges of addresses you
might want to "watch", etc.

IMHO both approaches have their advantages, so I get best  efficiency
by using both.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Real programmers don't comment their code. It was hard to  write,  it
should be hard to understand.

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

Re: Basic questions about PPC embedded developement under Linux

[Marcus Sundberg]

Wolfgang Denk <wd@denx.de> writes:

> In message <38EA0716.47AA17BA@sympatico.ca> you wrote:
> >
> > What do you gain by "understanding" the linux image?
>
> On the MPC8xx a Linux kernel image is usually an ELF binary file with
> several sections, for instance like that:
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         00004854  00180000  00180000  00010000  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   1 .rodata       000007bc  00184860  00184860  00014860  2**4
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   2 .data         0000031c  00186000  00186000  00016000  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
>   3 .data.init    00000000  00187000  00187000  00017000  2**0
>                   CONTENTS
>   4 .bss          000031f8  00187000  00187000  00017000  2**2
>                   ALLOC
>   5 image         0007135d  00000000  00000000  00017000  2**0
>                   CONTENTS, READONLY
>   6 initrd        0008a502  00000000  00000000  0008835d  2**0
>                   CONTENTS, READONLY
>
> Most BDM debuggers I know will load only those sections  into  memory
> (RAM or FLASH) that have the LOAD flag set (which is perfectly OK for
> normal  binaries).  So  they will load only the text, rodata and data
> sections which just contain the boot loader code - they will not load
> the kernel image, nor the initial ramdisk image.

Hmm, sounds like a bug in the zImage linking.
To me it would seem apropriate to have the ALLOC, LOAD and DATA flags
set for data.init, image and initrd sections.

//Marcus
--
Signature under construction, please come back later.

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

Re: Basic questions about PPC embedded developement under Linux

[Wolfgang Denk]

In message <000601bfa383$92e508b0$4f689ec0@w-shanta.india.tek.com> you wrote:
>
> I have a small question regarding the "bdiGDB".
> I need to first flash the kernel image into the flash memory. Can this be
> done with the debugger??

Yes. Using the telnet interface, you can  use  the  LOAD  command  to
download an image to RAM, and the PROG command to write it to FLASH:

LOAD   [<offset>] [<file> [<format>]] load program file to target memory
...
PROG   [<offset>] [<file>]   program flash memory

> Also the boot monitor needs to load the kernel image from the flash memory
> to the RAM and start executing it.
> Can this be traced with "bdiGDB"??

You can use a "target remote" command in GDB to attach to the  BDI200
debugger;  then  you  can use GDB; or you can do everything "by hand"
using the telnet interface and commands like these:

...
GO    [<pc>]                 set PC and start target system
TI    [<pc>]                 trace on instuction (single step)
TC    [<pc>]                 trace on change of flow
HALT                         force target to enter debug mode
BI  <from> [<to>] [<count>]  set instruction breakpoint
CI  [<id>]                   clear instruction breakpoint(s)
BD  [R|W] <addr> [<count>] [<data>] set data breakpoint (32bit access)
BDH [R|W] <addr> [<count>] [<data>] set data breakpoint (16bit access)
BDB [R|W] <addr> [<count>] [<data>] set data breakpoint ( 8bit access)
BDR <from> <to> [<count>]    set data breakpoint on a range
CD [<id>]                    clear data breakpoint(s)
...

Hope this helps.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
The game of life is a game of boomerangs.  Our  thoughts,  deeds  and
words return to us sooner or later with astounding accuracy.

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