[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: [microblaze-uclinux] Question
Hi John,
You could probably try to turn around the use of your "serial ports":
Use mdm as stdout and your other serial port for debugging with 115KBPs.
This could work using one xmd as your console and a second one for debug (I am pretty sure it does but have never tried this).
Regards
Jan
> -----Ursprüngliche Nachricht-----
> Von: John McGrath [mailto:john.mcgrath@xilinx.com]
> Gesendet: Donnerstag, 5. Februar 2004 15:29
> An: microblaze-uclinux@itee.uq.edu.au
> Betreff: Re: [microblaze-uclinux] Question
>
>
> Hi John,
>
> My board has just one 9-pin serial interface - which I am using for
> STDIN / STDOUT (console). I guess I could attach another serial
> interface for the debug - but this could be pretty tricky.
>
> The debug interface I am using is described as "hardware
> debug module",
> or MDM. It is accessed via the normal bitstream JTAG port.
>
> So in summary:
> a) All data / bitstream come over the parallel III / JTAG interface -
> via the MDM module on the OPB.
> b) The executing program stdin and stdout go over the single
> serial port.
>
> It seems like you have the advatnage of having two serial
> ports on your
> board, so perhaps I should add a second one?
>
> Cheers,
> John
>
>
> John Williams wrote:
>
> > Hi John,
> >
> > John McGrath wrote:
> >
> >> I was very interested to see that 4 minutes to download
> the image was
> >> considered slow. This means that my setup must be very far from
> >> optimal! Let me describe it:
> >>
> >> I download the bitstream (>1Mb) with a parallel III cable
> attached in
> >> JTAG / boundry scan mode to the FPGA board. This takes 10 seconds.
> >> I re-use this same cable to connected to xmd.
> >> I then use xmd (via the debugger interface) to download
> the image. It
> >> achieves about 1.5Kbytes / sec, which is terribly slow!
> >
> >
> > I haven't tried using the hardware debugger (are you talking about
> > MDM?) to download images. I would have expected it to be a
> lot faster
> > than that though!
> >
> >> Are you using the same cable to download the bistream and the image
> >> like me? I would have imagined the parallel cable would be
> faster. I
> >> am not using the JTAG UART, but accessing the SRAM via XMD which
> >> connects to the hardware debug module. (would the SW debug
> option be
> >> better?)
> >
> >
> > No, this is over a regular serial port, conencted between the
> > microblaze board and the host PC.
> >
> > There's an option to use an opb_uartlite peripheral as the debug
> > interface to microblaze - you still connect to it via xmd.
> >
> > Take a look at an mbvanilla system.mhs and system.mss.
> mbvanilla has
> > two uartlite instances, one at 56KBPs for the linux console
> > (consule_uart), and a second at 115KBPs for debug
> access(debug_uart).
> > This is for downloading kernel images etc (if you don't
> have flash or
> > ethernet).
> >
> > Does your board have a standard 9 pin serial socket?
> >
> > In system.mss, debug_uart is specified as the debug peripheral.
> >
> >> I had toyed with the idea of adding a separate perhiperhal
> to the OPB
> >> bus - or simply a temporary disconnection of the SRAM from the OPB
> >> and onto another SRAM controller interface just to download the
> >> image, which was directly connected to a parallel interface. This
> >> should be able to download at about 200kbytes/sec - but
> does require
> >> some soldering!!!!
> >
> >
> > It might end up a bit quicker than a serial download, but it's not
> > strictly necessary.
> >
> >> Finally, I am still a little unclear on the memory
> controler: here is
> >> my understanding:
> >
> >
> >> The default mbvanilla.h is as follows:
> >> /* Memory controller */
> >> #ifndef MICROBLAZE_MEMCON_BASE_ADDR
> >> #define MICROBLAZE_MEMCON_BASE_ADDR 0xFFFF0000
> >
> >
> >> /* Start and size of external RAM */
> >> #define ERAM_ADDR 0x80000000
> >> If I wanted to put data into the SRAM, would I write to
> the location
> >> 0x80000000 or via the controller 0xFFFF0000?
> >
> >
> > You write to the RAM address - 0x80000000.
> >
> >> Should I make the base address of the controller the same
> as that of
> >> the SRAM, or is it irrelevent if I dont have flash?
> >
> >
> > Just ignore the controller address 0xffff0000, it's the address
> > mapping of the controller core itself (not the RAM it manages).
> >
> >> my proposed change would be:
> >
> >
> > [snip]
> >
> > Not necessary - just make sure you map the actual RAM
> address range to
> > 0x80000000 in your system.mhs
> >
> > 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/
> >
>
> --
> **************************************************************
> *********
>
> / /\/ John McGrath
> \ \ Xilinx Inc.
>
> \_\/\
>
> Telephone: +353 21 4355 704
> FAX:
> John.McGrath@xilinx.com
> X I L I N X I N C.
> **************************************************************
> *********
>
>
>
> ___________________________
> 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/
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___________________________
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/