Re: [microblaze-uclinux] (RNH) Real Novice Here, Again

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Hi Wade,

Wade.Maxfield@computalog.com wrote:

>     I pulled up the "debug the kernel" page, and had to work around a few
> of its issues.  I'm using EDK 6.2 from Xilinx.
> 
>    Since I am running using dynamic ram, I had to have the microblaze with
> the dynamic ram controller running (for refresh) before I loaded anything
> else.  I have a "g" command in the microblaze internal code space to go to
> the kernel once I'm ready to execute.

Typically the way people boot microblaze uClinux systems is to have a 
bootloader that is initialised into the on-chip RAM as part of the 
bitstream.  Its job is then to copy the kernel image from somewhere 
(flash, serial port, network, whatever), into the off-chip RAM, and 
launch the kernel.  This approach is fully compatible with xmd / 
mdm-based debugging.

What's this 'g' command you are talking about?  Is it for your own 
bootloader or something?

>     First, I couldn't get a good environment by starting xmd.exe from a cmd
> prompt.  Running it from the Xilinx Platform Studio did provide a good
> environment, however.

What do you mean by good environment?  BTW Once you get the parallel 
port drivers sorted, xmd under linux is pretty solid.

>     Second, image.elf does not load using gdb or XMD.  Instead I loaded
> image.bin using XMD.  Then I started mb-gdb

mb-gdb will load the elf file properly, but xmd won't.  It's a "feature" 
of the elf loader in XMD (sort of, see the archives for the whole story)

>     Third, I only did a "sym image.elf" in the GDB console window, since
> image.bin was already loaded previously.

That's reasonable.

>     After that, I was able to run the kernel  by doing a "cont" in the gdb
> console window.  This executed the current block ram code in the Xilinx.
> Then, I ran the kernel using the "g" statement in my console (Hyperterm
> over RS232),

There's that 'g' command again - is this your own bootloader or something?

>    I was able to break the kernel by pressing "stop" button on the gdb gui.
> I was able to see the instruction address.  However I got a statement:
> 
> "Unable to Read Instructions at 0x8000413c"
> 
>   The gdb window shows "process.c" and "default_idle" in the drop down list
> boxes, so I know that the symbols are loaded and the processor knows where
> it is.  The call stack can be shown.   I can  show memory at the current
> $pc!   (that puzzles me) I can use the function browser and see functions
> within the files in the window, but I can't "view source."  I can see the
> registers.

I've seen this before with the window/graphical version of mb-gdb. 
Eventually I gave up on it - just launch mb-gdb with the "--nw" (no 
windows) option and use the gdb command line interface.  It's not as 
pretty, but it's just as functional, and it's also quite a bit more 
responsive.

> Here is the environment per the gdb show environment command:
> 
> !C:=C:\tools\edk_projects\nh3s400

[snip].

OK so I guess you're doing all this under Xygwin?

Do yourself a favour and just do it all under Linux.

<rant>

I really struggle to understand why people try to do uClinux development 
under Cygwin.  If you are building a uClinux product, you should live, 
breath, eat and sleep linux, during its development.

If an organisation is willing to spend tens of thousands of $$ on labour 
costs, hardware development, blah blah blah, in developing a uClinux 
product, the cost of a linux box for the OS/SW development is barely a 
blip on the radar.

</rant>

>    Attached is the mhs file we are using.  We aren't using the fsl bus.
> The hardware engineer does not think it is needed, and since gdb can read
> the memory at the $pc, I'm assuming it isn't needed either.   Are we wrong?

The FSL bus facilitates fast download of kernel images via XMD (and thus 
also mb-gdb).  It's not required for hardware debugging, but it makes 
kernel download many times faster than using the serial port or whatever.

Cheers,

John
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/