mpc8xx-2.2.13 kernel hangs during boot.

mpc8xx-2.2.13 kernel hangs during boot.

[Brendan John Simon]

I am trying to get mpc8xx-2.2.13 booting.  As far as I can tell, it is
hanging just after the kernel is decompressed into RAM and tries to
execute.  I get the following console output

    loaded at:     FF801000 FF80C1F0
    Relocate to:   00100000 0010B1F0
    Board Data at: 001001C4 001001E0
    relocated to:  00200100 0020011C
    Boot args at:  00200000 00200200
    zimage at:     FF807000 FF8676C8
    avail ram:     00201000 01000000

    Linux/PPC load:
    Uncompressing Linux... done.
    Now booting the kernel

I'm a little concerned about the overlap of BootArgs and the relocated
BoardData.  Does this seem right or wrong to anyone ?

I had previously had similar problem when using embedded-2.2.5.  It was
hanging during the boot.  It was suggested to me that I disable the
caches.  I did that in arch/ppc/mbxboot/head.S and
arch/ppc/kernel/head.S and I never had a problem booting embedded-2.2.5
since.  It was suggested to me that the UPM was probably incorrect and
that's why it fails with the caches enabled.
I have disabled the caches in mpc8xx-2.2.13 but I still get the same
results.  I have tried with 4 different UPM settings for a 25MHz bus
with 60ns EDO DRAM.  I got the values from the ADS manual, SDS Single
Step debugger and a commercial operating system.  I even tried with the
burst inhibit flag set/cleared in the chip select option registers.

I'm not sure if it is my bootloader or kernel.  In the bootloader I
basically setup the clocks, ports, chip selects for flash and dram and
that's about it.  Is there anything else the kernel expects to be setup
?

I've run out of ideas now and need some advice.
What could be causing the kernel not to boot ?
How can I tell where it is failing ?  I don't think I can use printk as
the console is not setup yet.  Is this correct ?

Getting a little desperate now.
Brendan Simon.


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

Re: mpc8xx-2.2.13 kernel hangs during boot.

[Dan Malek]

Brendan John Simon wrote:

>     Board Data at: 001001C4 001001E0
>     relocated to:  00200100 0020011C
>     Boot args at:  00200000 00200200

> I'm a little concerned about the overlap of BootArgs and the relocated
> BoardData.  Does this seem right or wrong to anyone ?

No, that is the way it is supposed to work.  I doubled the
size of the boot arguments (it is only 256 bytes), and placed
the board information structure there.  I just didn't update
the messages to further describe what is going on.  This
information is really only useful when debugging the boot
code, and it seems to be working now.

The command line and board information structure must reside
within the first 8Mbytes, and it seemed somewhat logical to
me to just use the same buffer space.


> ....  It was suggested to me that the UPM was probably incorrect and
> that's why it fails with the caches enabled.


I was the one that probably suggested that.  If all of the
memory mapping is correct (IMMR > 0xd0000000, and such) this
is usually where I start looking, since the code is known to
operate on other platforms.


> ....  I have tried with 4 different UPM settings for a 25MHz bus
> with 60ns EDO DRAM.


Although others may be more talented, I have never been able
to program the UPM without the actual DRAM specifications,
schematics and a logic analyzer connected to the processor bus.
Guessing at UPM values is kind of like playing the lottery.


> ....  Is there anything else the kernel expects to be setup
> ?

Not much.  Obviously the DRAM must be configured because the
kernel is loaded there.  Beyond that it just reads the IMMR
and maps it.


> How can I tell where it is failing ?  I don't think I can use printk as
> the console is not setup yet.  Is this correct ?


Here is a hint.  Look at the symbol table from System.map and
convert the address of log_buf to a physical address (mask the
upper couple of bits).  Dump this area of memory, as all of the
printk() messages end up in this buffer before they are sent to
the console.


> Getting a little desperate now.


Are those ready-for-production boards looking any better yet :-)?
The world is passing you by........


	-- Dan

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

Re: mpc8xx-2.2.13 kernel hangs during boot.

[Brendan John Simon]

Dan Malek wrote:

> > ....  It was suggested to me that the UPM was probably incorrect and
> > that's why it fails with the caches enabled.
>
> I was the one that probably suggested that.  If all of the
> memory mapping is correct (IMMR > 0xd0000000, and such) this
> is usually where I start looking, since the code is known to
> operate on other platforms.

I based my port on the BSEIP board as it is the simplest.
The IMMR is at 0xff000000 and all peripherals are mapped above 0x80000000
except for DRAM which is mapped at 0x00000000.


> > ....  I have tried with 4 different UPM settings for a 25MHz bus
> > with 60ns EDO DRAM.
>
> Although others may be more talented, I have never been able
> to program the UPM without the actual DRAM specifications,
> schematics and a logic analyzer connected to the processor bus.
> Guessing at UPM values is kind of like playing the lottery.

I think I have to agree with you :(


> > ....  Is there anything else the kernel expects to be setup
> > ?
>
> Not much.  Obviously the DRAM must be configured because the
> kernel is loaded there.  Beyond that it just reads the IMMR
> and maps it.

I didn't think so.  The embedded-2.2.5 kernel works fine with the same
bootloader.  I forgot to mention the the embedded-2.2.5 kernel is compiled
with binutils-2.9.1.0.19a/egcs-1.1.2 and the mpc8xx-2.2.12 kernel is
compiled with binutils-2.9.5.0.24/gcc-2.95.2.  I'm not sure if it makes any
difference.  I'm recompiling the embedded-2.2.5 kernel with my new tools to
see if that makes any difference ?  The embedded-2.2.5 does not having an
floating point emulation where as the mpc8xx-2.2.13 does.  I will also try
without the floating point emulation patches to see if that makes any
difference.


> > How can I tell where it is failing ?  I don't think I can use printk as
> > the console is not setup yet.  Is this correct ?
>
> Here is a hint.  Look at the symbol table from System.map and
> convert the address of log_buf to a physical address (mask the
> upper couple of bits).  Dump this area of memory, as all of the
> printk() messages end up in this buffer before they are sent to
> the console.

How can I look at this memory area ?  With a BDM debugger ?  I thought BDM
can't be used.
Can a serial debugger be used ?


> > Getting a little desperate now.
>
> Are those ready-for-production boards looking any better yet :-)?
> The world is passing you by........

No pain, no gain :)
Yes I know the off the shelf boards will get me going on the application
sides of things, but I still need to get it running on our custom board/s
too.

Brendan Simon.


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

Re: mpc8xx-2.2.13 kernel hangs during boot.

[dony]

Hi, Brendan:
       Have you solved your 2.2.13 kernel problem hanging yet?
       Now I have the similar problem as you.
       First I cross-compile the kernel under the following environment:
          [binutils-2.9.1.0.19a] [egcs-1.1.2] [glibc-2.1(including crypt and
linuxthreads)]
      Then the kernel can run correctly and don't hang.
      Then I destroy all above environment and rebuild my new environment:
              [binutils-2.9.5.0.22] [gcc-2.95.2] [gcc-core-2.95.2]
              [glibc-2.1.2(including crypt and linuxthreads)]
       and recompile my kernel. This time it hangs when showing "Now booting
the kernel..."
Anyone knows why?
Thank you very much.
dony

Brendan John Simon wrote:

> Dan Malek wrote:
>
> > > ....  It was suggested to me that the UPM was probably incorrect and
> > > that's why it fails with the caches enabled.
> >
> > I was the one that probably suggested that.  If all of the
> > memory mapping is correct (IMMR > 0xd0000000, and such) this
> > is usually where I start looking, since the code is known to
> > operate on other platforms.
>
> I based my port on the BSEIP board as it is the simplest.
> The IMMR is at 0xff000000 and all peripherals are mapped above 0x80000000
> except for DRAM which is mapped at 0x00000000.
>
> > > ....  I have tried with 4 different UPM settings for a 25MHz bus
> > > with 60ns EDO DRAM.
> >
> > Although others may be more talented, I have never been able
> > to program the UPM without the actual DRAM specifications,
> > schematics and a logic analyzer connected to the processor bus.
> > Guessing at UPM values is kind of like playing the lottery.
>
> I think I have to agree with you :(
>
> > > ....  Is there anything else the kernel expects to be setup
> > > ?
> >
> > Not much.  Obviously the DRAM must be configured because the
> > kernel is loaded there.  Beyond that it just reads the IMMR
> > and maps it.
>
> I didn't think so.  The embedded-2.2.5 kernel works fine with the same
> bootloader.  I forgot to mention the the embedded-2.2.5 kernel is compiled
> with binutils-2.9.1.0.19a/egcs-1.1.2 and the mpc8xx-2.2.12 kernel is
> compiled with binutils-2.9.5.0.24/gcc-2.95.2.  I'm not sure if it makes any
> difference.  I'm recompiling the embedded-2.2.5 kernel with my new tools to
> see if that makes any difference ?  The embedded-2.2.5 does not having an
> floating point emulation where as the mpc8xx-2.2.13 does.  I will also try
> without the floating point emulation patches to see if that makes any
> difference.
>
> > > How can I tell where it is failing ?  I don't think I can use printk as
> > > the console is not setup yet.  Is this correct ?
> >
> > Here is a hint.  Look at the symbol table from System.map and
> > convert the address of log_buf to a physical address (mask the
> > upper couple of bits).  Dump this area of memory, as all of the
> > printk() messages end up in this buffer before they are sent to
> > the console.
>
> How can I look at this memory area ?  With a BDM debugger ?  I thought BDM
> can't be used.
> Can a serial debugger be used ?
>
> > > Getting a little desperate now.
> >
> > Are those ready-for-production boards looking any better yet :-)?
> > The world is passing you by........
>
> No pain, no gain :)
> Yes I know the off the shelf boards will get me going on the application
> sides of things, but I still need to get it running on our custom board/s
> too.
>
> Brendan Simon.


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

Re: mpc8xx-2.2.13 kernel hangs during boot.

[Brendan John Simon]

szg98@mail.zhongxing.com wrote:

> Hi,
>      I don't think you have an incorrect UPM setting. When the kernel was
> being decompressed , decompress_kernel() has use ram as stack.

Yes but the kernel isn't running yet.  It runs after it is decompressed.  When
it starts running it normally enables the caches (I commented out this code)
and sets up the MMU.  Maybe the MMU requires the caches ?
]
Thanks,
Brendan Simon.


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

Re: mpc8xx-2.2.13 kernel hangs during boot.

[Dan Malek]

Brendan John Simon wrote:


> .....  Maybe the MMU requires the caches ?

No, but the MMU control registers contain cache modes to use
when the MMU is disabled.....which reminds me there could be
a bug if we are running copyback.....


	-- Dan

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

Re: mpc8xx-2.2.13 kernel hangs during boot.

[Brendan John Simon]

Wolfgang Denk wrote:

> In message <3896BF04.55AD7C4F@ctam.com.au> you write:
> >
> > I based my port on the BSEIP board as it is the simplest.
> > The IMMR is at 0xff000000 and all peripherals are mapped above 0x80000000
> > except for DRAM which is mapped at 0x00000000.
>
> Do youmean you have  any  peripherals  mapped  at  addresses  in  the
> 0x80000000 ... 0xC0000000 range? I don't think this will work...

Sorry about my ignornace but why can't I use the address range
0x80000000-0xBFFFFFFF for my peripherals ?
Is 0xC0000000-0xFFFFFFFF ok ?  What address range would be recommended ?


> > I didn't think so.  The embedded-2.2.5 kernel works fine with the same
> > bootloader.  I forgot to mention the the embedded-2.2.5 kernel is compiled
>
> What does "works fine" mean? Can you  run  any  serious  applications
> which *use* (nearly) all your available memory?

No I haven't tried any serious applications.  I just got a simple test app
working with dynamic linking using the embedded-2.2.5 kernel compiled with
binutils-2.9.5.0.24/gcc-2.95.2.  I would prefer to use mpc8xx-2.2.13.
I now have to put some serious applications together such as telnetd, snmpd,
etc.


> > How can I look at this memory area ?  With a BDM debugger ?  I thought BDM
> > can't be used.
>
> Of course this will work with a BDM debugger. Why should it fail???

There have been many postings to this list stating that BDM will not work after
the kernel is running.  I think it has something to do with the MMU.  The
debugger does not know how to translate VMA to PMA.  Do you believe this
statement is correct ?  Can you confirm that the kernel can be debugged using a
BDM ?


> > Can a serial debugger be used ?
>
> What is a serial debugger? Do you have any type of boot monitor  with
> debugging features, or what?

I was thinking of gdb with a serial connection.  I do not have a boot monitor
with debugging features but I can write some gdb stubs if it is possible.  I
was basically asking whether it is possible or not to debug the kernel and/or
apps via a serial connection.

Thanks,
Brendan Simon.


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

Re: mpc8xx-2.2.13 kernel hangs during boot.

[Brendan John Simon]

Dan Malek wrote:

> Brendan John Simon wrote:
>
> > Sorry about my ignornace but why can't I use the address range
> > 0x80000000-0xBFFFFFFF for my peripherals ?
> > Is 0xC0000000-0xFFFFFFFF ok ?  What address range would be recommended ?
>
> I posted this before.....I hope this matches previous messages :-).
>
> If you map (i.e. ioremap()) physical memory prior to the
> kernel VM initialization, the mapping is 1:1 virtual to physical.
> This happens in mm/init.c for things like the IMMR and some
> other board control registers.  In this case, mapping below
> something like 0xd0000000 causes problems with VM collision in
> kernel or user process space.
>
> After the kernel VM is initialized, you can ioremap() any
> physical space, as the mapping isn't 1:1.

The memory controller is setup in my boot loader.  It knows nothing about VMA, only
PMA.
I currently have CS0 mapped to 0xFF800000 for flash, CS1/2 mapped to 0x00000000 and
CS4 to 0x80000000 for DRAM.
Both Dan and Wolfgang have suggested that all peripherals should be at 0xD0000000
and above.  I am happy with this but am not sure what the DRAM address should be.
Should I map CS1 and CS2 to 0x00000000 or 0xC0000000 ?

I have not changed any code in the linux source tree with regards to memory
mapping.  ie. not use of ioremap as I do not use any of the peripherals yet.  I've
got a very vague idea of what ioremap() does and will read more on it.  I sounds
like I will probably need it to access my peripherals from within linux.  Is this
correct ?


> At this stage, nothing beats a simple rom monitor that can display
> memory after a processor reset.

I'll look into adding this support to my bootloader.

Thanks,
Brendan Simon.


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

Re: mpc8xx-2.2.13 kernel hangs during boot.

[Dan Malek]

Brendan John Simon wrote:


> The memory controller is setup in my boot loader.  It knows nothing about VMA, only
> PMA.

This has nothing to do with the 8xx memory controller.  It is the
way the Linux kernel maps its virtual space.


> I am happy with this but am not sure what the DRAM address should be.
> Should I map CS1 and CS2 to 0x00000000 or 0xC0000000 ?

DRAM should map to 0.

> ...  I sounds
> like I will probably need it to access my peripherals from within linux.  Is this
> correct ?

Yes.  It is simply the kernel memory mapping function, similar
to what mmap() does in a user application.



	-- Dan

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

Re: mpc8xx-2.2.13 kernel hangs during boot.

[Brendan John Simon]

Alan Mimms wrote:

> Brendan,
>
> We use a serial connection to debug our applications with GDB all the time
> using stubs that are part of our "OS".  It certainly is possible.  We put the
> devices on the end of a 24 port Livingston Portmaster terminal server and then
> setup the ports as raw data ports to which we connect with GDB running on our
> main build/debug box.  That way the user can debug something in another room or
> across the planet very easily through the network.

Cool.  A little overkill never hurt anybody :)
I'll assume one build/debug box connected directly to the target via a serial cable
or ethernet for now.


> I debugged my initial port of the linux kernel to our platform using just this
> kind of interface.  You have to commandeer the serial hardware away from the
> driver - I simply didn't tell the kernel there was a device there and
> configured it "manually" from the GDB nub initialization function which I
> called early in main.c.  This works fine for KERNEL debugging.

When you say configured manually what exactly do you mean.
Is this in the kernel itself ?
When you say main.c do you mean init/main.c in the linux kernel source tree ?
Has this got anything to do with the kgdb option in the "make config" process ?
Can ethernet be used to debug the kernel or is a serial port the only or best way to
go ?


> For application debugging, you probably want to live in user space.  You COULD
> use gdbserver, I think, although I have no experience or knowledge of this.

I'm pretty sure gdbserver is the way to go for debugging applications.  A TCP
connection is a nice way to debug this.

Thanks,
Brendan Simon.


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

Re: mpc8xx-2.2.13 kernel hangs during boot.

[Alan Mimms]

On Tue, 01 Feb 2000, Brendan John Simon wrote:
> Alan Mimms wrote:
>
> > Brendan,
> >
> > We use a serial connection to debug our applications with GDB all the time
> > using stubs that are part of our "OS".  It certainly is possible.  We put the
> > devices on the end of a 24 port Livingston Portmaster terminal server and then
> > setup the ports as raw data ports to which we connect with GDB running on our
> > main build/debug box.  That way the user can debug something in another room or
> > across the planet very easily through the network.
>
> Cool.  A little overkill never hurt anybody :)
> I'll assume one build/debug box connected directly to the target via a serial cable
> or ethernet for now.

I see what you mean, but I still think it's a necessity.  It's not overkill if
it means I don't have to wander across the hall every 5 minutes to dink with the
platform or sit in a room full of LOUD fans to work and debug.

>
> > I debugged my initial port of the linux kernel to our platform using just this
> > kind of interface.  You have to commandeer the serial hardware away from the
> > driver - I simply didn't tell the kernel there was a device there and
> > configured it "manually" from the GDB nub initialization function which I
> > called early in main.c.  This works fine for KERNEL debugging.
>
> When you say configured manually what exactly do you mean.
> Is this in the kernel itself ?
> When you say main.c do you mean init/main.c in the linux kernel source tree ?
> Has this got anything to do with the kgdb option in the "make config" process ?
> Can ethernet be used to debug the kernel or is a serial port the only or best way to
> go ?

I DO mean init/main.c.  I mean "manually" in the sense that the low level
driver I used in my gdb nub has an "init" call made from init/main.c to
setup the UART registers properly (baud rate, etc.).  The nub UART driver simply
polls the UART and does simple one byte read/write operations to it.  The nub
has the necessary (simple) hex/unhex conversion routines for the GDB serial
protocol.  Doesn't use anything else so you can theoretically debug the
kernel's version of printf with breakpoints and everything without screwing up
the debugger by debugging code it depends upon.


> > For application debugging, you probably want to live in user space.  You COULD
> > use gdbserver, I think, although I have no experience or knowledge of this.
>
> I'm pretty sure gdbserver is the way to go for debugging applications.  A TCP
> connection is a nice way to debug this.
>
> Thanks,
> Brendan Simon.
--
Alan Mimms     Packet Engines, Inc.     Spokane, Washington [99214-0497]
  USA, Earth, Sol, Milky Way, The Local Group, Virgo Supercluster, U0
Despite the cost of living, have you noticed how popular it remains?
  -- Steven Wright?

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

Re: mpc8xx-2.2.13 kernel hangs during boot.

[Brendan John Simon]

Alan Mimms wrote:

> > > We use a serial connection to debug our applications with GDB all the time
> > > using stubs that are part of our "OS".  It certainly is possible.  We put the
> > > devices on the end of a 24 port Livingston Portmaster terminal server and then
> > > setup the ports as raw data ports to which we connect with GDB running on our
> > > main build/debug box.  That way the user can debug something in another room or
> > > across the planet very easily through the network.
> >
> > Cool.  A little overkill never hurt anybody :)
> > I'll assume one build/debug box connected directly to the target via a serial cable
> > or ethernet for now.
>
> I see what you mean, but I still think it's a necessity.  It's not overkill if
> it means I don't have to wander across the hall every 5 minutes to dink with the
> platform or sit in a room full of LOUD fans to work and debug.

I was being a bit sarchy.  It is not overkill.  Infact I will probably setup some kind of
server for compile and debug too so some other engineers can work on linux from there
MS-Win machines (poor buggers).  I have cross-compiled Insight to work with the cygwin
environment so that might be an option with gdbserver.  I may even compile the entire
tool chain for cygwin and see if I can compile the kernel and apps from the MS-Win
machines (I'm just asking for trouble aren't I).  If it works I will ask Dan to put the
tools on the ftp server.


> > > I debugged my initial port of the linux kernel to our platform using just this
> > > kind of interface.  You have to commandeer the serial hardware away from the
> > > driver - I simply didn't tell the kernel there was a device there and
> > > configured it "manually" from the GDB nub initialization function which I
> > > called early in main.c.  This works fine for KERNEL debugging.
> >
> > When you say configured manually what exactly do you mean.
> > Is this in the kernel itself ?
> > When you say main.c do you mean init/main.c in the linux kernel source tree ?
> > Has this got anything to do with the kgdb option in the "make config" process ?
> > Can ethernet be used to debug the kernel or is a serial port the only or best way to
> > go ?
>
> I DO mean init/main.c.  I mean "manually" in the sense that the low level
> driver I used in my gdb nub has an "init" call made from init/main.c to
> setup the UART registers properly (baud rate, etc.).  The nub UART driver simply
> polls the UART and does simple one byte read/write operations to it.  The nub
> has the necessary (simple) hex/unhex conversion routines for the GDB serial
> protocol.  Doesn't use anything else so you can theoretically debug the
> kernel's version of printf with breakpoints and everything without screwing up
> the debugger by debugging code it depends upon.

What is "nub" ?
Have you have written the code to interpret the gdb serial protocol or are you using code
from gdb itself ?
Are your suggestions taken from the gdb howto or documentation ?

Thanks,
Brendan Simon.


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

Re: mpc8xx-2.2.13 kernel hangs during boot.

[Alan Mimms]

On Tue, 01 Feb 2000, Brendan John Simon wrote:
> Alan Mimms wrote:
>
> > > > We use a serial connection to debug our applications with GDB all the time
> > > > using stubs that are part of our "OS".  It certainly is possible.  We put the
> > > > devices on the end of a 24 port Livingston Portmaster terminal server and then
> > > > setup the ports as raw data ports to which we connect with GDB running on our
> > > > main build/debug box.  That way the user can debug something in another room or
> > > > across the planet very easily through the network.
> > >
> > > Cool.  A little overkill never hurt anybody :)
> > > I'll assume one build/debug box connected directly to the target via a serial cable
> > > or ethernet for now.
> >
> > I see what you mean, but I still think it's a necessity.  It's not overkill if
> > it means I don't have to wander across the hall every 5 minutes to dink with the
> > platform or sit in a room full of LOUD fans to work and debug.
>
> I was being a bit sarchy.  It is not overkill.  Infact I will probably setup some kind of
> server for compile and debug too so some other engineers can work on linux from there
> MS-Win machines (poor buggers).  I have cross-compiled Insight to work with the cygwin
> environment so that might be an option with gdbserver.  I may even compile the entire
> tool chain for cygwin and see if I can compile the kernel and apps from the MS-Win
> machines (I'm just asking for trouble aren't I).  If it works I will ask Dan to put the
> tools on the ftp server.
>
>
> > > > I debugged my initial port of the linux kernel to our platform using just this
> > > > kind of interface.  You have to commandeer the serial hardware away from the
> > > > driver - I simply didn't tell the kernel there was a device there and
> > > > configured it "manually" from the GDB nub initialization function which I
> > > > called early in main.c.  This works fine for KERNEL debugging.
> > >
> > > When you say configured manually what exactly do you mean.
> > > Is this in the kernel itself ?
> > > When you say main.c do you mean init/main.c in the linux kernel source tree ?
> > > Has this got anything to do with the kgdb option in the "make config" process ?
> > > Can ethernet be used to debug the kernel or is a serial port the only or best way to
> > > go ?
> >
> > I DO mean init/main.c.  I mean "manually" in the sense that the low level
> > driver I used in my gdb nub has an "init" call made from init/main.c to
> > setup the UART registers properly (baud rate, etc.).  The nub UART driver simply
> > polls the UART and does simple one byte read/write operations to it.  The nub
> > has the necessary (simple) hex/unhex conversion routines for the GDB serial
> > protocol.  Doesn't use anything else so you can theoretically debug the
> > kernel's version of printf with breakpoints and everything without screwing up
> > the debugger by debugging code it depends upon.
>
> What is "nub" ?
> Have you have written the code to interpret the gdb serial protocol or are you using code
> from gdb itself ?
> Are your suggestions taken from the gdb howto or documentation ?

The "nub" is the thing that interprets the GDB serial protocol (which is dead
simple BTW).  It gets called on any PowerPC exception and knows how to interact
with the context of the exception, letting GDB grab data from it and from other
machine state (RAM contents).  GDB can also change the state of registers from
the exception and say "GO", or whatever.  If you look in the GDB sources, there
are three or four of these implemented for many processors.  I looked at a few
of them then wrote my own for PowerPC.  The hard part was the wrapper in
assembly language to gobble up the exception state and store it in the GDB
prescribed register status block format.  That's pretty much what is being done
in Linux already when it calls the code in traps.c.

> Thanks,
> Brendan Simon.
--
Alan Mimms     Packet Engines, Inc.     Spokane, Washington [99214-0497]
  USA, Earth, Sol, Milky Way, The Local Group, Virgo Supercluster, U0
Despite the cost of living, have you noticed how popular it remains?
  -- Steven Wright?

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