Xilinx PowerPC

[Stephen Neuendorffer]

> -----Original Message-----
> From: David H. Lynch Jr. [mailto:dhlii at dlasys.lcl]
> Sent: Friday, February 22, 2008 1:51 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-embedded
> Subject: Re: Xilinx PowerPC
> 
> Stephen Neuendorffer wrote:
> >
> >> -----Original Message-----
> >> From:
linuxppc-embedded-bounces+stephen=neuendorffer.name at ozlabs.org
> >>
> > [mailto:linuxppc-embedded-
> >
> >> bounces+stephen=neuendorffer.name at ozlabs.org] On Behalf Of David H.
> >>
> > Lynch Jr.
> >
> >> Sent: Wednesday, February 20, 2008 10:59 PM
> >> To: Grant Likely; linuxppc-embedded
> >> Subject: Xilinx PowerPC
> >>
> >>
> >>     So when you have Xilinx under powerpc working, do we pull it
from
> >>
> > your
> >
> >>     git tree or the xilinx one ?
> >>
> >>     Will there be an announcement ?
> >>
> >>     How about a one paragraph getting started guide to moving a
xilinx
> >> ppc bsp to
> >>     xilinx powerpc.
> >>
> >>     Like  ?
> >>
> >>     step 1).
> >>              Generate a dts - gen-mhs-devicetree ?
> >>              And pass it to through your boot loader to Linux ?
> >>
> >
> > http://git.xilinx.com/gen-mhs-devtree.git contains two utilities for
> > generating device trees from EDK projects.  The older option is a
python
> > script, originally written by Grant.  The newer (and probably more
> > mature at this point) option is an EDK BSP generator for u-boot,
> > originally written by Michal Simek.  Preferably this gets passed
from a
> > uboot, although it's also possible to compile it into the kernel.
> > Currently, the uboot option is somewhat annoying because there's not
a
> > good surefire way for getting uboot up and running on an EDK design.
> > (Unfortunately, the EDK BSP generator is incomplete, and the uboot
> > support for virtex needs some work to get it integrated as well).
> >
>     Thanks, I found the python script. Please do not fixate on u-boot.
>      it is not an option for us. We have our own bootloader.
>     it handles .elf files, fits in 16k or BRAM and just starts when
the
>      FPGA is loaded. We will have to added  device tree support to it.
>     I had thought you were talking about appending the device tree to
> the bitfile.
>      That sounds like a really good option for us.
> 
>     We also really don't have a great interest in the EDK BSP
generator.
>     We have our own BSP's for our cards for both GHS and Linux.
>     Except the rare instances - like right now while we are
> transitioning to the
>     newer LL_TEMAC,  we use normal linux drivers, either from the
> existing kernel
>     trees, or written inhouse.

The BSP generator is significantly different from the normal EDK Linux
BSP.  The key thing is that the device tree generated by the python
script is necessarily incomplete, since it does not have information
about default parameter values which appear in the core definitions.  I
would *highly recommend* using the uboot bsp to get a device tree.  You
can always ignore anything else that it does (or hack the code to your
hearts content to do what you want, such as incorporating it into your
own BSP).

> >>     Step 2).
> >>              the code in arch/powerpc/???? is the devicetree
equvalent
> >>
> > to
> >
> >>              arch/ppc/platforms/4xx/xilinx_ml410.c
> >>
> > http://git.xilinx.com/linux-2.6-xlnx.git contains a preliminary stab
at
> > the bootcode for Virtex.  I've been using this for a while with
> > ARCH=powerpc.  There isn't really much need for board specific
platform
> > code: This should (I think) be handled by the device tree.
>     So I have a device tree for my card somehow. Presumably I need the
> binary form.
>     My bootloader needs to pass a pointer to a copy in memory to
Linux.
> 
>     How do I config the linux from your git tree ?
>     Do I just config for a generic Xilinx card and the device tree
> handles the rest ?

Essentially.  There is a generic virtex configuration option.

>     Next we have a hosted pseudo serial port. Devict Trees could cope
> with that.
>     But We also have early serial support for both it and Uartlite,
>     Also our Linux BSP and UartLite drivers will work without a PIC.
>     And would even do ethernet (badly) with the earlier LL_TEMAC
without
>     DMA and interrupts.
>     So do I modify the device tree to choose a different uartlite
driver ?
>     I had to put a fair amount of patches in to support early serial
with
>     non-8250 serial ports. Do I have to patch your generic xilinx BSP
to
>     deal with that ?

Early serial on uartlite is works fine.  You have to add an explicit
reference to the uartlite to get it to work.  Early serial on uart16550
doesn't work yet, because the device has an unusual spacing between the
registers.

>     Please do not develop a u-boot only solution.

I don't believe Linux will never *require* uboot.

>     Just to clarify, am I correct in presuming that say the uartlite
> driver in the
>     xilinx git tree will handle either the arch/ppc style platform
> device initialization
>     or the arch/powerpc devicetree initialization ?

Yes.  drivers are capable of probing both the platform bus and the of
bus.  It is expected that each device is advertised on only one.  In
general, ppc will advertise platform devices and powerpc will advertise
of devices.

>     Is there some means of doing a phased transition ?
>     Can I lift the device tree BSP setup code into my own BSP,
>     and then remove the platform device code peice by peice as things
work ?
probably, although changing the drivers is not challenging, as long as
all the information you need is in the device tree.

>     Is there something magical about being physically located in
> arch/ppc or arch/powerpc ?

Well, ppc doesn't support of/device trees.  All of the of bus stuff is
#ifdef'd out of the drivers.

Steve