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

[Wade.Maxfield@xxxxxxxxxxxxxx]

John,

  Thanks for the help!   I've answered your questions, and have a question
of my own.

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?


--------------yes, I added this to our own bootloader.   It jumps to the
kernel which is now residing at 0x80000000.

    I understand what you are saying about copying from flash to ram, and
that is our next step.  However, I wanted to debug the kernel under the gui
gdb first, so I could debug what I was doing wrong.

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

-------------I'm guessing the environment variables are toast, as I can't
run mb-gdb, or anything I need to run.


BTW Once you get the parallel
port drivers sorted, xmd under linux is pretty solid.

--------------OK. I'm puzzled.  How do I get the Linux version of XMD and
the Xilinx Platform Studio?  I've had this toolkit for about 10 days, and I
don't know what you are talking about. I've only seen the windows version.


<snip>

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

-------------THANKS!


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

--------------------It is a bit of a political situation here.  The head of
Software got Linux shoved down his throat about 4 years ago, against his
will and without his input, and is now firmly a Microsoft man.  Very
firmly. He dislikes Linux now. It is called hate in some other circles.

  Even though his group is supporting a Linux platform, the only reason I
get away with doing Linux is that I've been very successful at it, and I
don't step on his toes.  My part of the system runs with very, very few
software/firmware issues.  His part has a lot of software issues, and some
hardware/Linux compatibility issues that can be killers at times.  To his
credit, he does not try to crater the product and blame it on Linux, but he
still hates Linux.

  I have to develop both Linux and Windows debug tools, so VMWARE under w2k
with a hot box is very acceptable.  I've got 2 monitors, and I move
software back and forth between machines a lot.


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

------------I'll see about getting that added, though it may not be as big
an issue once I download from flash.


Cheers,

John



***CONFIDENTIALITY NOTICE***
This communication (and any attachment) is confidential. It should only be
read by the person(s) to whom
it is addressed.  If you have received this communication in error, please
notify the sender by reply and delete this communication.
*****************************************

___________________________
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/