Re: [microblaze-uclinux] PetaLinux 0.20, including 2.6.20 kernel

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Hi Leonid,

Leonid wrote:

>>The solution is that all drivers in 2.6 will (or shold) use the 
>>platform_device constructs, meaning that there are no hard coded base 
>>addresses, IRQ numbers, core parameters, or anything like that in 
>>drivers.  Instead, it's all accessed through the platform device 
>>infrastructure, which is configured instead in the 
>>arch/xxx/platforms/yyy initialisation (platform_device_register()).
> 
> 
> [Leonid] This is way to go, but it assumes modifying of Xilinx sources
> which make their upgrade more difficult in future unless Xilinx will
> embrace the same approach.

There's no future in kernel.org for the Xilinx drivers (_l, _g etc).
The only way drivers will make it to kernel.org is if they are rewritten
in correct kernel style, as has happed for the uartlite and recently
system ace driver.

There are some drivers in the petalinux 2.6 tree that are in the old
style, but I won't even attempt to push them to kernel.org, it is a
waste of time.

>>So, drivers can now be truly cross platform, with no
> 
> CONFIG_XILINX/XPAR 
> 
>>rubbish.
> 
> 
>>That instead is being pushed down into board setup, and will hopefully
> 
> 
>>disappear completely one day.
> 
> 
> [Leonid] But board setup code still needs such "rubbish" - how it will
> get EDK project parameters otherwise? I don't really see how can it
> disappear - you don't suggest use just numbers instead of defines,
> aren't you?

They are still #defines, in an exactly analogous way to how it was done
in 2.4.  But, because these #defines are concentrated in one place,
rather than scattered throughout the source tree, they are a lot easier
to manage, document and so on.

> If I am right, the "rubbish" under consideration still needs to be
> standardized somehow - CONFIG_XILINX_... or XPAR_...

Well, currently the PPC folks have a fairly yucky
xparameters_boardname.h file, that maps the XPAR names onto standard,
but still XPAR_ prefixed names.

Since it's isolated inside arch/ppc, and microblaze inside
arch/microblaze, it really isn't that much of an issue.

> [Leonid] I cannot agree more and because we are dealing here with
> several architectures simultaneously we may make some useful
> contribution to the public cause. I'm just looking for the best starting
> point preferring not to re-invite bicycle.

Well, revving the 2.6.20 tree in PetaLinux up to 2.6.21/20, or even
backwards to 2.6.19 will be almost trivial I think.  So, if you want to
merge the microblaze support from our tree into one of your other trees,
there's a relatively straight forward path there.

Of course, the way I'd really like you to help is assist in getting the
microblaze support ready for a push to kernel.org! :)

> [Leonid] Which Wolfgang from Xilinx you are talking about? May I have a
> full name of this gentleman?

Wolfgang Reissnegger - he's active on the ppc-embedded-devel list.

>>This doesn't answer your question of course.  You'll see that the
> 
> 2.6.20 
> 
>>tree in petalinux is a stock 2.6.20 tree, with MicroBlaze support
> 
> added.
> 
> [Leonid] I take it that for PPC405 some cores (like TMAC) are not
> supported there, right? Or you included Grant Likely's patches?

We don't have any TEMAC support in there yet, I'm not sure there is a
mature (or even core-complete) driver for it for 2.6 yet.

> Also, do you have any "unified" file system suggestions?

Not quite sure what you mean there?

John

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/