Re: [microblaze-uclinux] Question

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

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/