AW: [microblaze-uclinux] Question

["Schunke Jan-Hendrik" <Schunke@xxxxxxxxxxxxxxxxxxxx>]

Hi John & John,

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

I have been using the mdm and as far as I remember from the
documentation it uses the
Jtag Uart to connect to xmd. This might be the reason it is slower than
the connection using a 
uartlite at 115KBPs for debug access. I would strongly suggest using a
uartlite for data transfer.

Hope this information helps a little. 

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

Regards
Jan

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