Re: [microblaze-uclinux] Question

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

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/