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

["Leonid" <Leonid@xxxxxxxxx>]

Hi, John:

On Thursday, June 14, 2007 11:26 PM John Williams wrote:
> > May I also ask how do you resolve a "naming" problem in XILINX
drivers?
> > Petalogix v0.10 naming scheme was to use CONFIG_XILINX_...
constants,
> > being generated by your BSP while all Xilinx drivers so far use
> > constants with XPAR_... names. In 0.10 version you modified Xilinx
code,
> > creating for example in u-boot board/petalogix directory which is
> > essentially parallel to board/xilinx.
> > 
> > Did you come up (together with PPC folks) with better solution in
v0.20
> > and if yes, what is it?

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

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

> > Another question: now, when your 2.6.20 is not on kernel.org yet
(when
> > this pleasant even is expected BTW) what is the best choice of
kernel
> > source, I can use for different architectures? I have here:
> > - Microblaze on Spartan-2 and Spartan-3 - I use uClinux 2.4 from
> > Petalinux
> > - PPC405 on Virtex-4 - I use standard 2.6.19 with TMAC driver ported
> > manually
> > - AMCC PPC440EPx - standard kernel.
> > - Atmel (ARM9) at91rm9200 CPU - standard kernel.

> Yes - well to get into kernel.org we'll have to catch up to the head, 
> 2.6.22.?? I think.  That's not such a big deal, the bigger deal is 
> getting the sources in such a shape that they'll pass gatekeeping.
> 
> Unification into a single kernel.org tree is critical, but this is an 
> effort we (with this community hopefully) have to do ourselves -
there's 
> no funding coming from anywhere to pay for it.

[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.
 
> Xilinx is moving slowly towards hosting a Git tree, and one of their 
> Linux engineers (hi Wolfgang!) is working hard to try and use that at 
> least as a  staging point.  But, there' still a lot of push required
to 
> get microblaze into mainline.  We've got bills to pay and customers to

> keep happy, so it's a juggling of priorities.
 
[Leonid] Which Wolfgang from Xilinx you are talking about? May I have a
full name of this gentleman?

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

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

Regards,

Leonid. 

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