Re: [microblaze-uclinux] Questions on auto-config build flow

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Hi David,

David Banas wrote:

> Thanks for the auto-config flow!

A lot of thanks must also go to Sathya from the Xilinx EDK group - he 
did most of the hard work in creating the MLD/Tcl scripts - I just told 
him what I needed, and did the kernel revamp to support it :)

> Then, I noticed your mention of the 'system.mhs' file in the first paragraph
> of your README, where you're explaining the historical problem of doing
> custom builds of uClinux. It occurred to me that the idea might be to
> overwrite the 'system.mhs' file from your tarball with the one from my FPGA
> project directory and then run the 'make ...' commands. Is that correct?
> 
> If so, it raises the question: what other files should be over-written
> before running the 'make ...' commands. Can you provide a list of these?
> 
> If I'm completely off track here, can you point me towards the light?

My hastily crafted README is to blame here.  The real magic of the 
autoconfiguration is contained in the bsp/ subdirectory of the archive. 
  In the same way that an EDK project contains custom cores in the 
pcores subdir, so the bsp subdirectory contains a package to allow the 
generation of the auto-config.in file, from your MSS and MHS files.

My thinking was that at first, particuarly in the absence of decent 
documentation, it would be easiest (as before) to morph the uclinux-auto 
platform that I've provided, to your own requirements.  Running "make 
libs" will then cause the generation of the correct auto-config.in file, 
that will then configure the kernel accordingly.

However, if you want to start from scratch (or simply auto-ify your 
existing hardware), then just copy the bsp subdirectory out of the 
uclinux-auto project, into your own, adjust your MSS file using the 
original MSS/MHS pair as a guide, and proceed from there.

Note that the uclinux MLD/Tcl support is still pretty preliminary - it 
will automatically export all parameters of all IP cores, such as base 
addresses, HW version numbesr etc, as well as IRQ numbers for any 
peripherals connected to the interrupt controller.  This is a good 
thing.  Note you have to have a mention of each core in the MSS file, 
even just using the generic driver, otherwise it won't get picked up in 
the auto-config.

Its major weakness is probably that it doesn't support the newer version 
of the DDR (and maybe SDRAM) controllers - you'll note the uclinux-auto 
platform uses the deprecated version of the DDR controller.  This is 
because the newer version of the core uses multipel banks, and stuff 
like that, which the MLD/Tcl doesn't support yet.  It should be pretty 
simple to add, I'm just waiting on some doco from Xilinx to help me make 
the modifications.

As you can imagine, the scope for what this could do is tremendous. 
Part of the problem is managing the complexity, and deciding where the 
boundaries should be.  For example, should the MHS/MSS platform 
description specify which uart to use as the Linux console?  What about 
flash memory - should the MSS contain a description of how you want the 
flash memory partitioned, or should that be done in the kernel?  There 
are no easy answers - it principle you could entirely replace the kernel 
config process by using the MLD/Tcl, but that would be a lot of work for 
little real gain.  It will be interesting to see how people use this, 
and how it evolves.

I expect ultimately I'll distribute the MLD/Tcl BSP package seperately 
from any specific hardware platform, but in the first instance it made 
more sense to bundle them together.

Hope this clears things up a bit for you.

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/