From: "Stephen Neuendorffer" <stephen.neuendorffer@xilinx•com>
To: <dhlii@dlasys•net>
Cc: linuxppc-embedded <linuxppc-embedded@ozlabs•org>
Subject: RE: Xilinx PowerPC
Date: Fri, 22 Feb 2008 14:05:56 -0800 [thread overview]
Message-ID: <20080222220558.4CB0D1778052@mail117-sin.bigfish.com> (raw)
In-Reply-To: <47BF43CF.5050102@dlasys.lcl>
> -----Original Message-----
> From: David H. Lynch Jr. [mailto:dhlii@dlasys•lcl]
> Sent: Friday, February 22, 2008 1:51 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-embedded
> Subject: Re: Xilinx PowerPC
>=20
> Stephen Neuendorffer wrote:
> >
> >> -----Original Message-----
> >> From:
linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs•org
> >>
> > [mailto:linuxppc-embedded-
> >
> >> bounces+stephen=3Dneuendorffer.name@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.
>=20
> 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=3Dpowerpc. 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.
>=20
> 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
next prev parent reply other threads:[~2008-02-22 22:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-21 6:58 Xilinx PowerPC David H. Lynch Jr.
2008-02-21 17:50 ` Stephen Neuendorffer
2008-02-21 19:02 ` Grant Likely
2008-02-22 17:23 ` Alan Casey
2008-02-22 18:11 ` Stephen Neuendorffer
2008-02-22 18:58 ` Alan Casey
2008-02-22 19:07 ` Stephen Neuendorffer
[not found] ` <47BF43CF.5050102@dlasys.lcl>
2008-02-22 22:05 ` Stephen Neuendorffer [this message]
2008-03-02 18:25 ` Michal Simek
2008-03-03 19:53 ` Stephen Neuendorffer
[not found] <480BA36D.1080000@dlasys.net>
[not found] ` <fa686aa40804201314m27caf4fau72956df9dd5d350d@mail.gmail.com>
[not found] ` <480BA821.2030109@dlasys.net>
[not found] ` <fa686aa40804201548o503e9b19p4081cec653a1acd2@mail.gmail.com>
2008-04-20 23:48 ` David H. Lynch Jr.
2008-04-22 22:15 ` Koss, Mike (Mission Systems)
2008-04-23 21:37 ` David H. Lynch Jr.
2008-04-23 0:04 ` Yoshio Kashiwagi
2008-04-23 21:43 ` David H. Lynch Jr.
2008-05-17 15:36 ` David H. Lynch Jr.
2008-05-18 2:13 ` Yoshio Kashiwagi
2008-05-19 3:27 ` David H. Lynch Jr.
2008-05-19 4:09 ` Grant Likely
2008-05-19 4:18 ` Yoshio Kashiwagi
2008-05-19 4:59 ` Grant Likely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080222220558.4CB0D1778052@mail117-sin.bigfish.com \
--to=stephen.neuendorffer@xilinx$(echo .)com \
--cc=dhlii@dlasys$(echo .)net \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox