[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [microblaze-uclinux] Question
Hi All,
Thanks for the quick responses!
I will see how I get on!
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!
It is surprising that the bitstream itself can download so fast, while
the image data is so slow.
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?)
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!!!!
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
#endif
/* Start and size of external RAM */
#define ERAM_ADDR 0x80000000
#define ERAM_SIZE 0x0100000
If I wanted to put data into the SRAM, would I write to the location
0x80000000 or via the controller 0xFFFF0000?
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?
my proposed change would be:
/* Memory controller */
#ifndef MICROBLAZE_MEMCON_BASE_ADDR
#define MICROBLAZE_MEMCON_BASE_ADDR 0x80000000
#endif
/* Start and size of external RAM */
#define ERAM_ADDR 0x80000000
#define ERAM_SIZE 0x00800000 /* 8MB */
Cheers, and thanks for all the advice!
John
John Williams wrote:
> Hi John
>
> Just adding to Aurash's excellent advice:
>
> Aurelian Lazarut wrote:
>
>> On Wed, 2004-02-04 at 19:15, John McGrath wrote:
>
>
>>> Does anyone know of certain features I can cut out to improve this?
>>> Do the default settigns when I configure uClinux choose minimal
>>> options?
>>
>>
>> You will have an already "shrink" version if you run without net support
>> (you don't have the ethernet on AFX right?)
>
>
> A bare-bones kernel without networking support comes in at around
> 600-800K. Add say 200k for a minimal userland distribution (busybox +
> little else), and it's perfectly feasible to squeeze in under 1Mbyte.
>
> Once you start adding other things like login support, it grows from
> there.
>
> One thing that people should know about - uClinux supports compressed
> application binaries. In the /vendors/xxxx/Makefile, when running
> mb-elf2flt on the user programs, add the -z flag to compress them.
> Savings of 50% are normal. The kernel automatically expands the
> application code when executing.
>
>>> What is the memory controller (defined in the mbvanilla.h) ? I do
>>> not have one of these in my design. I simply have some SRAM directly
>>> onto the OPB bus, which is at base address 0x81800000 - I dont think
>>> I need a separate memory controller for this, so how do I set this
>>> parameter so it will work - do I simply set it to the base address
>>> of my SRAM? (this is also defined in that file).
>>
>
> The memcon peripheral referred to in the mbvanilla.h is the opb_memcon
> core that comes with EDK. In mbvanilla it connects the external SRAM
> and flash to the OPB.
>
>> in your case it will be easier to make the base address 0x80000000 (by
>> reimplementing the design in EDK) and then you don't have to modify
>> mbvanilla.h
>
>
> This is good advice! It *should* be sufficient to adjust the
> ERAM_SIZE and ERAM_ADDR #defines in mbvanila.h, but definitely keeping
> the start address the same, will make life a lot easier.
>
>>> c) Does the uClinux compress the kernel and expand it when running -
>>> if not, is this an option?
>>
>
> It is supported in uclinux, in fact a kernel/image build of mb-uclinux
> already produces a compressed image file (images/imagez.bin).
> However, the bootloader (distributed with mbvanilla targets) doesn't
> support it.
>
> The trick is writing a bootloader small enough to fit into BRAM.
> You don't want to waste all of your FPGA BRAM resources on a
> bootloader that only executes for a few seconds on startup...
>
> One way to get a fully-featured bootloader is a two-step boot process
> - minimal bootloader in BRAM, pulls the real bootloader from flash,
> which then decompresses the kernel from flash, and starts up... Or
> even better, link the flash-based bootloader in such a way that it can
> execute directly from flash.... Then you just set the power-on startup
> vector (at 0x00000000) to point to the appropriate flash address, and
> off you go. A bit of link-script tinkering required, but not impossible.
>
> Plus, if Xilinx reveal (or include) a Microblaze parameter that allows
> you to specify the processor boot address at synthesis time
> (C_BOOT_ADDR perhaps?), you could have a self-booting microblaze
> system using no BRAM resources at all.... ;-)
>
>>> d) Is it possible to get the impact tool to download data to the
>>> SRAM? it is very fast at downloading the ~1MB bistream, so if this
>>> was an option perhaps this could be a way of bypassing the ~1 hour
>>> kernel download time I am experiencing with XMD & debugger.
>>
>
> hmmm - 1 hr, that's an awfully long time. are you using the jtag uart
> for this?
>
>> you can use the uart as the connection for XMD at 115200bps, I know is
>> not much but you can download the the image in ~4min
>
>
> This is the better approach. 4 minutes is still pretty slow, but it's
> workable.
>
> An aside: Has anybody tried increasing the uartlite beyond 115200
> baud? The EDK docs say any speed up to OPB_Clk/16 is possible, but
> I've never been able to connect beyond 115200.
>
>> In my opinion you should ... change the DDR memory contoller with a
>> SDRAM memory controller keeping the same base_address (0x80000000) and
>> get rid of the ethernet MAC. I think with this approach you will save
>> time and ... coffee
>
>
> Good advice! At this stage, there's still a few kernel changes
> required to support new boards, and the changes are distributed around
> the kernel. One of the development priorities is finding a way of
> managing this better... but for now, the first step in porting is to
> make your hardware platform as close as possible to mbvanilla... (at
> least in address map and IRQ assignments etc).
>
> Regards,
>
> 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/