On 09/07/18 23:21, Scott Wood wrote:
Thanks for your email. The device in question ships an old uboot (a
vendor fork of U-Boot 2010.12-svn15934).
This was added by commit 6b70ffb9d1b2e, committed in July 2008... maybe
there's a problem with the old U-Boot finding the crypto node on this
parti
tree properly...
>
> or:
>
> In the case (such as OpenWRT) where the preferred installation method is
> to retain the vendor bootloader, then the distro kernel should handle
> the device tree fixup itself?
The NXP PPC device trees in the kernel are meant to be complet
On 06/07/18 19:41, Scott Wood wrote:
My openwrt patch
just does a:
/delete-node/ crypto@3;
after the p1010si-post.dtsi include.
U-Boot should already be removing the node on non-E chips -- see
ft_cpu_setup() in arch/powerpc/cpu/mpc85xx/fdt.c
Hi Scott,
Thanks for your email. The devic
without the SEC4 module.
The P1010 errata at:
https://media.digikey.com/pdf/PCNs/Freescale/P1010CE_RevL.pdf
(table 2 on page 2), says that the P1010 and P1014 don't have the SEC4
module, only the P1010E and P1014E models do.
So, I think there should probably be device trees for p101xE (wit
the P1010 and P1014 don't have the SEC4
> module, only the P1010E and P1014E models do.
>
> So, I think there should probably be device trees for p101xE (with SEC)
> and p101x (without SEC).
>
> Any thoughts? Not really sure how best to do that... My openwrt patch
>
kexec_file_load needs to set up the device tree that will be used
by the next kernel and check whether it provides a console
that can be used by the purgatory.
[a...@linux-foundation.org: coding-style fixes]
Signed-off-by: Thiago Jung Bauermann
Signed-off-by: Andrew Morton
---
arch/powerpc/incl
kexec_file_load needs to set up the device tree that will be used
by the next kernel and check whether it provides a console
that can be used by the purgatory.
[a...@linux-foundation.org: coding-style fixes]
Signed-off-by: Thiago Jung Bauermann
Signed-off-by: Andrew Morton
---
arch/powerpc/incl
kexec_file_load needs to set up the device tree that will be used
by the next kernel and check whether it provides a console
that can be used by the purgatory.
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/include/asm/kexec.h | 3 +
arch/powerpc/kernel/machine_kexec_64.c | 220 ++
kexec_file_load needs to set up the device tree that will be used
by the next kernel and check whether it provides a console
that can be used by the purgatory.
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/include/asm/kexec.h | 3 +
arch/powerpc/kernel/machine_kexec_64.c | 222 ++
On Thu, Jan 28, 2016 at 06:47:39PM +0530, Ashish kumar wrote:
> B4860 has 1 PPC core cluster and 3 DSP core clusters.
> Similarly B4420 has 1 PPC core cluster and 1 DSP core cluster.
>
> Each DSP core cluster consists of 2 SC3900 cores and a shared L2 cache.
>
> Add DSP clusters for B4420
> The L
B4860 has 1 PPC core cluster and 3 DSP core clusters.
Similarly B4420 has 1 PPC core cluster and 1 DSP core cluster.
Each DSP core cluster consists of 2 SC3900 cores and a shared L2 cache.
Add DSP clusters for B4420
The L2 cache nodes such that they now appear in only the
soc specific dtsi files(
/B4420qds: Updates to device trees for B4860 for DSP
clusters and their L2 caches
B4860 has 1 PPC core cluster and 3 DSP core clusters.
Similarly B4420 has 1 PPC core cluster and 1 DSP core cluster.
Each DSP core cluster consists of 2 SC3900 cores and a shared L2 cache.
1. Add DSP clusters for
B4860 has 1 PPC core cluster and 3 DSP core clusters.
Similarly B4420 has 1 PPC core cluster and 1 DSP core cluster.
Each DSP core cluster consists of 2 SC3900 cores and a shared L2 cache.
1. Add DSP clusters for B4420
2. Reorganized the L2 cache nodes such that they now appear in only the
soc sp
From: Diana Craciun
Updated the device trees according to the corenet-cf
binding definition.
Signed-off-by: Diana Craciun
---
arch/powerpc/boot/dts/b4860emu.dts | 7 ++-
arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 4
arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 2
On 04/19/2014 01:07 AM, Scott Wood wrote:
On Fri, 2014-04-18 at 18:21 +0300, Diana Craciun wrote:
From: Diana Craciun
Updated the device trees according to the corenet-cf
binding definition.
Signed-off-by: Diana Craciun
---
arch/powerpc/boot/dts/b4860emu.dts | 2 +-
arch/powerpc
On Fri, 2014-04-18 at 18:21 +0300, Diana Craciun wrote:
> From: Diana Craciun
>
> Updated the device trees according to the corenet-cf
> binding definition.
>
> Signed-off-by: Diana Craciun
> ---
> arch/powerpc/boot/dts/b4860emu.dts | 2 +-
> arch/p
From: Diana Craciun
Updated the device trees according to the corenet-cf
binding definition.
Signed-off-by: Diana Craciun
---
arch/powerpc/boot/dts/b4860emu.dts | 2 +-
arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 4
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 4
arch
On Jul 26, 2012, at 10:08 AM, Timur Tabi wrote:
> From: Kim Phillips
>
> Add device tree (dtsi) files for the Freescale P5040 SOC. Since this
> SOC introduces SEC v5.2, add the dtsi file for that also.
>
> Signed-off-by: Kim Phillips
> Signed-off-by: Timur Tabi
> ---
> arch/powerpc/boot/dts
From: Kim Phillips
Add device tree (dtsi) files for the Freescale P5040 SOC. Since this
SOC introduces SEC v5.2, add the dtsi file for that also.
Signed-off-by: Kim Phillips
Signed-off-by: Timur Tabi
---
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 320 +
arch/pow
On Jul 25, 2012, at 5:38 PM, "Phillips Kim-R1AAHA" wrote:
> On Wed, 25 Jul 2012 16:59:49 -0500
> Timur Tabi wrote:
>
>> Add device tree (dtsi) files for the Freescale P5040 SOC. Since this
>> SOC introduces SEC v5.2, add the dtsi file for that also.
>>
>> Signed-off-by: Timur Tabi
>> ---
>
On Wed, 25 Jul 2012 16:59:49 -0500
Timur Tabi wrote:
> Add device tree (dtsi) files for the Freescale P5040 SOC. Since this
> SOC introduces SEC v5.2, add the dtsi file for that also.
>
> Signed-off-by: Timur Tabi
> ---
mind retaining the original authors' signoffs?
Kim
Add device tree (dtsi) files for the Freescale P5040 SOC. Since this
SOC introduces SEC v5.2, add the dtsi file for that also.
Signed-off-by: Timur Tabi
---
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 320 +
arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi| 111 +
On Jul 13, 2012, at 5:40 PM, Timur Tabi wrote:
> We only need two examples of CAMP device trees in the upstream kernel.
>
> Co-operative Asymmetric Multi-Processing (CAMP) is a technique where two
> or more operating systems (typically multiple copies of the same Linux kernel)
>
We only need two examples of CAMP device trees in the upstream kernel.
Co-operative Asymmetric Multi-Processing (CAMP) is a technique where two
or more operating systems (typically multiple copies of the same Linux kernel)
are loaded into memory, and each kernel is given a subset of the available
On Thu, Nov 17, 2011 at 01:16:00AM -0600, Kumar Gala wrote:
> Utilize new split between board & SoC, and new SoC device trees split
> into pre & post utilizing 'template' includes for SoC IP blocks.
>
> Other changes include:
> * Moved to specifying interrupt-par
Utilize new split between board & SoC, and new SoC device trees split
into pre & post utilizing 'template' includes for SoC IP blocks.
Other changes include:
* Adding of MPIC timer blocks
* Dropping "fsl,p4080-IP..." from compatibles for standard blocks
* Removed mpi
Utilize new split between board & SoC, and new SoC device trees split
into pre & post utilizing 'template' includes for SoC IP blocks.
Other changes include:
* Moved to a standard 2 #address-cells & #size-cells at top-level
* Moved to specifying interrupt-parent for mpic at
Utilize new split between board & SoC, and new SoC device trees split
into pre & post utilizing 'template' includes for SoC IP blocks.
Other changes include:
* Moved to specifying interrupt-parent for mpic at root
* Moved to 4-cell mpic interrupt cells to support MPIC timers
* A
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 342
arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 145 +
arch/powerpc/boot/dts/p4080ds.dts | 14 +-
arch/powerpc/boot/dts/p4080si.dtsi | 755 ---
4 files c
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/fsl/mpc8548si-post.dtsi | 143 +++
arch/powerpc/boot/dts/fsl/mpc8548si-pre.dtsi | 62 +++
arch/powerpc/boot/dts/mpc8548cds.dts | 505 ++---
3 files changed, 327 insertions(+), 383 deletions(-)
create mode 1
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi | 248 ++
arch/powerpc/boot/dts/fsl/mpc8536si-pre.dtsi | 63
arch/powerpc/boot/dts/mpc8536ds.dts | 456 +
arch/powerpc/boot/dts/mpc8536ds.dtsi | 141 ++
Posting this to get any feedback and review while I cleanup commit messages
and the such.
The general idea is to split out the SoC and IP blocks into their own files
that can be included to build up a board level device tree. This allows us
to reduce overall duplication and forward looking mainte
On Sep 16, 2011, at 10:36 AM, Kumar Gala wrote:
> From: Stephen George
>
> Adding new device tree binding file for the DCSR node. Modifying device
> tree dtsi files to add DCSR node for P2041, P3041, P3060, P4080, & P5020.
>
> Signed-off-by: Stephen George
> Signed-off-by: Kumar Gala
> ---
From: Stephen George
Adding new device tree binding file for the DCSR node. Modifying device
tree dtsi files to add DCSR node for P2041, P3041, P3060, P4080, & P5020.
Signed-off-by: Stephen George
Signed-off-by: Kumar Gala
---
v3:
* fix IRQs #, (should be +16 because of external IRQs starting
From: Stephen George
Adding new device tree binding file for the DCSR node. Modifying device
tree dtsi files to add DCSR node for P2041, P3041, P3060, P4080, & P5020.
Signed-off-by: Stephen George
Signed-off-by: Kumar Gala
---
v2:
* include dscr.txt binding spec
* moved around dcsr nodes to k
From: Stephen George
Adding new device tree binding file for the DCSR node. Modifying device
tree dtsi files to add DCSR node for P2041, P3041, P3060, P4080, & P5020.
Signed-off-by: Stephen George
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/p2041rdb.dts |4 ++
arch/powerpc/boot/d
On Mon, Jul 26, 2010 at 11:22:58PM -0500, Matthew McClintock wrote:
>
> On Jul 26, 2010, at 9:55 PM, Simon Horman wrote:
>
> > [Cced linuxppc-dev]
> >
> > On Tue, Jul 20, 2010 at 11:42:57PM -0500, Matthew McClintock wrote:
> >> This patch series adds full support for booting with a flat device t
On Jul 26, 2010, at 9:55 PM, Simon Horman wrote:
> [Cced linuxppc-dev]
>
> On Tue, Jul 20, 2010 at 11:42:57PM -0500, Matthew McClintock wrote:
>> This patch series adds full support for booting with a flat device tree
>> with either uImage or elf file formats. Kexec and Kdump should work, and
>>
2010/7/27 Simon Horman
> [Cced linuxppc-dev]
>
> On Tue, Jul 20, 2010 at 11:42:57PM -0500, Matthew McClintock wrote:
> > This patch series adds full support for booting with a flat device tree
> > with either uImage or elf file formats. Kexec and Kdump should work, and
> > you should also be able
[Cced linuxppc-dev]
On Tue, Jul 20, 2010 at 11:42:57PM -0500, Matthew McClintock wrote:
> This patch series adds full support for booting with a flat device tree
> with either uImage or elf file formats. Kexec and Kdump should work, and
> you should also be able to use ramdisks or reuse your curre
On Mon, May 10, 2010 at 02:55:03PM +1000, Michael Neuling wrote:
>
>
> In message <4be78e06.6080...@ozlabs.org> you wrote:
> >
> > ppc64's fs2dt used to use a fixed-size array into which the device tree
> > was parsed. There was no bounds checking, so with a large device tree other
> > heap dat
In message <4be78e06.6080...@ozlabs.org> you wrote:
>
> ppc64's fs2dt used to use a fixed-size array into which the device tree
> was parsed. There was no bounds checking, so with a large device tree other
> heap data ended up getting stomped -- SIGSEGV time.
>
> This patch adds a function, 'd
David Gibson wrote:
>>
>> It is not THE dtb, it is A dtb. Our systems support and typically use
>> multiple FPGA bit streams.
>>
>
> Ah, ok. And those multiple bitstreams all inhabit the same NOR flash?
> From what I read below I'm guessing not..
>
In my work they virtually always do,
On Wed, May 13, 2009 at 02:11:22PM -0400, David H. Lynch Jr. wrote:
> David Gibson wrote:
> >
> >
> > Ok. If you have NOR flash, why couldn't you just put the dtb in a
> > separate partition of the NOR?
> >
> >
> It is not THE dtb, it is A dtb. Our systems support and typically use
> multiple F
David Gibson wrote:
>
>
> Ok. If you have NOR flash, why couldn't you just put the dtb in a
> separate partition of the NOR?
>
>
It is not THE dtb, it is A dtb. Our systems support and typically use
multiple FPGA bit streams.
Clients are
That means each bitstream must have its own dtb, clients
>> Um.. one thing I'm missing in this discussion of attaching the dtb to
>> the bitstream: I don't see how the bitstream becomes accessible to
>> the kernel at runtime. Unless you were exposing the dtb as part of
>> the fpga programming, but I thought you explicitly weren't doing that
>> because
On Wed, May 13, 2009 at 02:11:33AM -0400, David H. Lynch Jr. wrote:
> David Gibson wrote:
> > On Tue, May 12, 2009 at 05:10:46PM -0700, Stephen Neuendorffer wrote:
> >
> >> Another possibility is to pad the DTB with a DESYNC command and the
> >> correct pad frame, just in case it cannot be preve
David Gibson wrote:
> On Tue, May 12, 2009 at 05:10:46PM -0700, Stephen Neuendorffer wrote:
>
>> Another possibility is to pad the DTB with a DESYNC command and the
>> correct pad frame, just in case it cannot be prevented.
>>
>
> Um.. one thing I'm missing in this discussion of attaching t
On Tue, May 12, 2009 at 8:36 PM, David Gibson
wrote:
> On Tue, May 12, 2009 at 05:10:46PM -0700, Stephen Neuendorffer wrote:
>>
>> Another possibility is to pad the DTB with a DESYNC command and the
>> correct pad frame, just in case it cannot be prevented.
>
> Um.. one thing I'm missing in this d
es,
but if someone could enlighten me...?
> > -Original Message-
> > From: Grant Likely [mailto:grant.lik...@secretlab.ca]
> > Sent: Monday, May 11, 2009 10:30 PM
> > To: Stephen Neuendorffer
> > Cc: David H. Lynch Jr.; linuxppc-dev@ozlabs.org
> > Subje
On Tue, May 12, 2009 at 08:13:19PM -0400, David H. Lynch Jr. wrote:
>
>
> Are we all using the same meaning of firmware ?
>
> While firmware == BIOS is the norm for PC's
Well, BIOS, or bootloader is what I'm meaning here.
> atleast in the embedded FPGA space firmware could mean th
Whenever I say firmware I mean executable code that executes when the
processor comes out of reset.
When I mean the FPGA bitstream, I say bitstream. :-)
g.
On Tue, May 12, 2009 at 6:13 PM, David H. Lynch Jr. wrote:
>
>
> Are we all using the same meaning of firmware ?
>
> While firmware
Are we all using the same meaning of firmware ?
While firmware == BIOS is the norm for PC's
atleast in the embedded FPGA space firmware could mean the FPGA
programing that creates the hardware.
For an FPGA based system a dtb generated by the same software that
created the "firmw
gt; Cc: David H. Lynch Jr.; linuxppc-dev@ozlabs.org
> Subject: Re: device trees.
>
> On Mon, May 11, 2009 at 10:27 PM, Stephen Neuendorffer
> wrote:
> >> > OK, so the key question seems to be *when* the bitstream is
> > associated
> >> > with the
>
On Tue, May 12, 2009 at 5:24 PM, David Gibson
wrote:
> On Mon, May 11, 2009 at 11:22:21PM -0600, Grant Likely wrote:
>> ... but I do agree that hard linking the .dtb into firmware, or making
>> the .dtb hard to upgrade is the way of madness.
>
> Ah, we're talking at cross purposes a bit then. Yea
On Mon, May 11, 2009 at 11:22:21PM -0600, Grant Likely wrote:
> On Mon, May 11, 2009 at 7:12 PM, David Gibson
> wrote:
> > On Mon, May 11, 2009 at 05:09:27PM -0600, Grant Likely wrote:
> >> In other words; having your bootloader support FDT is preferred, but
> >> not required.
> >
> > I wouldn't e
On Mon, May 11, 2009 at 06:04:16PM -0600, Grant Likely wrote:
> > David: If you would like to have a discussion regarding particular
> > design tradeoffs, I'd be happy to, but since I doubt there is anyone on
> > this list who is interested in the vagaries of FPGA configuration
> > methods, I sugg
On Mon, May 11, 2009 at 10:27 PM, Stephen Neuendorffer
wrote:
>> > OK, so the key question seems to be *when* the bitstream is
> associated
>> > with the
>> > device tree. If at bitstream generation time, you can prepend the
> .dtb
>> > to the bitstream. As long as the dtb doesn't contain the ma
On Mon, May 11, 2009 at 7:12 PM, David Gibson
wrote:
> On Mon, May 11, 2009 at 05:09:27PM -0600, Grant Likely wrote:
>> In other words; having your bootloader support FDT is preferred, but
>> not required.
>
> I wouldn't even go so far as to say it's preferred. IMO, people have
> gone a bit prema
> -Original Message-
> From: David H. Lynch Jr. [mailto:dh...@dlasys.net]
> Sent: Monday, May 11, 2009 7:35 PM
> To: Stephen Neuendorffer; linuxppc-dev@ozlabs.org
> Subject: Re: device trees.
>
> Stephen Neuendorffer wrote:
> >
> >> Many of our sys
Stephen Neuendorffer wrote:
>
>> Many of our systems are LX systems but currently we are not running
>> Linux on them.
>>
>
> Master SelectMap, I presume? What FPGA family?
> Does the FPGA have access to the CPLD after boot, other than through the
> configuration pins?
>
>
One of the skill
Rather than starting from scratch.
> > >>I am not looking to be convinced that I am approaching this all wrong.
> > >>If you are happy with what you have - great. I am not.
> > >> While I was not looking to restart a great debate over device trees
> >
>> it can be generated from scratch (like with real OpenFirmware). There
> >> is lots of flexibility on how to handle it.
> >>
> >>
> > First device trees are now the ONLY means of passing information to the
> > kernel.
> > By defini
t does not meet a number of our needs,
> and would require significant architectural changes to do so. The
> difference between it and devicetrees is that u-boot is avaiable to us
> if we want, I did port u-boot to our hardware at one point and it did
> everything it promised, but u-boo
y the time the kernel is started the device tree
> > must be fully formed and populated. It can be completely pre-canned
> > (like simpleImage), it can be modified by firmware (like u-boot), or
> > it can be generated from scratch (like with real OpenFirmware). There
> > i
On Mon, May 11, 2009 at 5:19 PM, Stephen Neuendorffer
wrote:
>
>> >> The best alternative to creating the device tree dynamically
> would
>> >> be to
>> >> append the devicetree to the bitimage in a way the boot loader
> could
>> >> always find it.
>> >>
>> >
>> > That sounds like a good sol
> >>The best alternative to creating the device tree dynamically
would
> >> be to
> >>append the devicetree to the bitimage in a way the boot loader
could
> >> always find it.
> >>
> >
> > That sounds like a good solution to me.
> >
> I am glad you like it. If Xilinx would like to offe
the kernel is started the device tree
>> must be fully formed and populated. It can be completely pre-canned
>> (like simpleImage), it can be modified by firmware (like u-boot), or
>> it can be generated from scratch (like with real OpenFirmware). There
>> is lots of flexibilit
On Mon, 2009-05-11 at 17:38 -0400, David H. Lynch Jr. wrote:
> Not only is the device tree expected to pass static hardware
> configuration information, but it is the sole means of passing
> anything.
> As an example Command lines are to be in the device tree.
> Everything is supposed to be in the
> > Not pretty, but it does more or less what you're talking about. Would
> > need some work to get it going on !pseries obviously.
>
> Heh, I didn't even know this existed. :-)
>
> Thinking about this more, it seems to me that the tricky bit would be
> figuring out how to drop all references t
be completely pre-canned
> (like simpleImage), it can be modified by firmware (like u-boot), or
> it can be generated from scratch (like with real OpenFirmware). There
> is lots of flexibility on how to handle it.
>
>
First device trees are now the ONLY means of passing informati
I was not specifically trying to criticize simple image.
> My problem is not with specific means of handling device trees.
> It is that it is a one size fits all solution, and it is not
> sufficiently flexible for that.
What do you mean by "one size fits all solution?"
T
and devicetrees is that u-boot is avaiable to us
if we want, I did port u-boot to our hardware at one point and it did
everything it promised, but u-boot is optional, device trees are not.
I do not have to re-architect u-boot to fit into 16k of bram, or
load bit files or .
If I want to
dtb is passed to it.
>
I was not aware that u-boot was currently doing that, but I was
aware that was possible.
It is the most useful alternative to simple image.
I was not specifically trying to criticize simple image.
My problem is not with specific means of handling device
Stephen Neuendorffer wrote:
>> You *could* generate the device tree dynamically, but I think that is
>> a path of diminishing returns considering that generating a .dts at
>> the same time as bitstream creation time is cheap and it is small. At
>> one time Steven Neuendorffer was playing with a sc
> You *could* generate the device tree dynamically, but I think that is
> a path of diminishing returns considering that generating a .dts at
> the same time as bitstream creation time is cheap and it is small. At
> one time Steven Neuendorffer was playing with a scheme to preload a
> section of
On Mon, May 11, 2009 at 1:32 AM, David H. Lynch Jr. wrote:
> We are very actively headed in the opposite direction. It is my/our
> intention to have a single linux executable that works accross
> everyone of our cards and everyone of our bitfiles.
This is the same direction that "we" are he
On Mon, May 11, 2009 at 12:32 AM, David H. Lynch Jr. wrote:
> But partial reconfiguration is not the only way to encounter a
> dynamic environment.
> A typical pico system has multiple bit files and multiple
> executables stored in its flash file system.
> Power up and soft resets might e
I will have to look at the code referenced below,
But my objective is not to address partial reconfiguration at this time.
At Pico we have come to the conclusion that as it is currently done
partial reconfiguration has extremely limited use.
We are actively looking at other techniq
On Sun, May 10, 2009 at 8:00 PM, Michael Ellerman
wrote:
> On Sat, 2009-05-09 at 14:51 -0600, Grant Likely wrote:
>> On Fri, May 8, 2009 at 10:03 AM, David H. Lynch Jr. wrote:
>> > Is there an example somewhere that shows building a device tree on
>> > the fly ?
>> >
>> > As our products mo
On Sat, 2009-05-09 at 14:51 -0600, Grant Likely wrote:
> On Fri, May 8, 2009 at 10:03 AM, David H. Lynch Jr. wrote:
> >Is there an example somewhere that shows building a device tree on
> > the fly ?
> >
> >As our products move forward it becomes increasingly clear that
> > static configur
story, I assume you're talking about FPGA device trees
here. Are you doing partial reconfiguration at runtime? Or are you
talking about generating a device tree to match the FPGA design?
For the later, there is a tool which works with EDK to generate a
device tree based on an EDK design. Yo
you can look at the source to SLOF or u-boot to see cases of building
nodes on the fly.
- k
On May 8, 2009, at 11:03 AM, David H. Lynch Jr. wrote:
Is there an example somewhere that shows building a device tree on
the fly ?
As our products move forward it becomes increasingly clear th
On Fri, May 8, 2009 at 11:03 AM, David H. Lynch Jr. wrote:
> Is there an example somewhere that shows building a device tree on
> the fly ?
A whole device tree? I don't think so. U-Boot does manipulate quite
a few properties, but it assume that the DTS lists all the devices.
Remember, one o
Is there an example somewhere that shows building a device tree on
the fly ?
As our products move forward it becomes increasingly clear that
static configurations are not going to work.
--
Dave Lynch DLA Systems
Software Development:
>lock);
> > isf->ioaddr = ioremap(phys_addr.start,
> > phys_addr.end - phys_addr.start);
>
> That looks good -- I'd have expected of_address_to_resource to fail,
> though, when the ranges property was missing. The kernel's device tree
(&isf->lock);
isf->ioaddr = ioremap(phys_addr.start,
phys_addr.end - phys_addr.start);
That looks good -- I'd have expected of_address_to_resource to fail,
though, when the ranges property was missing. The kernel's device tree
parsing code c
d (and with
some other issues).
> Compatible should be of the form "vendor,device" -- and does "isf"
> uniquely identify the specific FPGA logic, or are there other versions
> out there (or likely to exist in the future)? Note that there are some
> bad examples in existin
clock-frequency, and device_type.
Compatible should be of the form "vendor,device" -- and does "isf"
uniquely identify the specific FPGA logic, or are there other versions
out there (or likely to exist in the future)? Note that there are some
bad examples in existing device trees
printk(KERN_ERR "Could not find ISF PIC\n");
return;
}
and thereafter calling a custom setup function for the FPGA interrupt
controller. That appears to work fine, but I'm wondering how to get the
serial ports detected properly by of_serial.
I suppose I c
d in this
> madness. Editorial changes were made to keep the all the
> mpc5200 board device trees as similar as possible so that diffs
> between them only show the real differences between the boards.
> The pcm030 device tree was most affected by this because many
> of the comments h
property out of device nodes and
into top level parent node.
This patch also include what looks to be just trivial editorial
whitespace/format changes, but there is real method in this
madness. Editorial changes were made to keep the all the
mpc5200 board device trees as similar as possible so that
Now that get_immrbase knows about immr aliases.
Some chip docs call this ccsr for 8[56]xx platforms
but we stick with immr for consistency across 8xxx.
Signed-off-by: John Rigby <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/ksi8560.dts |3 ++-
arch/powerpc/boot/dts/mpc8536ds.dts
Now that get_immrbase knows about immr aliases.
Signed-off-by: John Rigby <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8313erdb.dts|3 ++-
arch/powerpc/boot/dts/mpc8315erdb.dts|3 ++-
arch/powerpc/boot/dts/mpc832x_mds.dts|3 ++-
arch/powerpc/boot/dts/mpc832x_rdb.dts
On Fri, 28 Mar 2008 14:37:51 -0500
Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On Mar 28, 2008, at 11:44 AM, Anton Vorontsov wrote:
> > On Fri, Mar 28, 2008 at 10:51:25AM -0500, Kim Phillips wrote:
> >> the mpc837x rdb board uses low pin count interfaces (ULPI) to connect
> >> to the USB PHY.
> >
>
On Mar 28, 2008, at 11:44 AM, Anton Vorontsov wrote:
On Fri, Mar 28, 2008 at 10:51:25AM -0500, Kim Phillips wrote:
the mpc837x rdb board uses low pin count interfaces (ULPI) to connect
to the USB PHY.
I've sent this fix two weeks ago...
http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052
On Fri, Mar 28, 2008 at 10:51:25AM -0500, Kim Phillips wrote:
> the mpc837x rdb board uses low pin count interfaces (ULPI) to connect
> to the USB PHY.
I've sent this fix two weeks ago...
http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052926.html
> Signed-off-by: Kim Phillips <[EMAIL PROTEC
the mpc837x rdb board uses low pin count interfaces (ULPI) to connect
to the USB PHY.
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8377_rdb.dts |2 +-
arch/powerpc/boot/dts/mpc8378_rdb.dts |2 +-
arch/powerpc/boot/dts/mpc8379_rdb.dts |2 +-
3 files chan
This isn't a problem with this device tree, but it's probably time we
started establishing some conventional generic names for nand flash
and board-control devices.
So, to start the ball rolling, I've seen several names for nand flash
nodes, I'd suggest we standardise on "nand-flash".
What's wr
On Tue, Mar 11, 2008 at 01:43:49AM +0100, Arnd Bergmann wrote:
> On Tuesday 11 March 2008, David Gibson wrote:
> > On Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote:
> > > > This isn't a problem with this device tree, but it's probably time we
> > > > started establishing some conv
1 - 100 of 171 matches
Mail list logo
