* Re: PCI target implementation on AMCC PPC CPUs
From: David Hawkins @ 2007-09-06 20:15 UTC (permalink / raw)
To: Leonid; +Cc: linuxppc-embedded
In-Reply-To: <406A31B117F2734987636D6CCC93EE3C022417D2@ehost011-3.exch011.intermedia.net>
Hi Leonid,
> Does somebody have any experience of using AMCC PPC chips (such as
> PPC440ep) or any other PPC at all as PCI target (slave)? PPC440ep has
> PCI-PLB bridge which certainly can be configured as slave. CPU will need
> to do configuration and then I assume another CPU (PCI host) will be
> able to access all memories via the bridge including peripherals'
> controllers. Slave CPU involvement would be minimal then.
>
> Can anybody point me to design like this or to that end to any SW design
> where PPC CPU works as PCI slave?
I have an application where I want to communicate with up
to 20 cPCI slaves per cPCI chassis, where the slave devices
each use a PowerPC based processor. (The masters happen
to be x86 CPUs; because I have them).
I looked at the 440EP using the Yosemite board
http://www.ovro.caltech.edu/~dwh/powerpc_440ep.pdf
and the Freescale MPC8349E
http://www.ovro.caltech.edu/~dwh/powerpc_mpc8349e.pdf
I had some trouble the with AMCC chips; the DMA controller
operation was weird, and AMCC tech support was pretty
much useless.
Freescale's technical (design) support is great, and they
(the software developers; Kim, Timur, etc) are actively
maintaining/contributing to git trees for u-boot and Linux.
If you can change processors, I'd recommend any Freescale
part over an AMCC part.
I'm working on a cPCI board design at the moment, you're
welcome to look at the design;
* PowerPC
* Altera Stratix II FPGAs
* dual 8-bit 1GHz ADCs
http://www.ovro.caltech.edu/~dwh/carma_board/
Regards,
Dave
^ permalink raw reply
* Re: PCI target implementation on AMCC PPC CPUs
From: David Hawkins @ 2007-09-06 20:26 UTC (permalink / raw)
To: Leonid; +Cc: linuxppc-embedded
In-Reply-To: <406A31B117F2734987636D6CCC93EE3C022417D2@ehost011-3.exch011.intermedia.net>
Hi Leonid,
In case they are not in the document:
There are several fundamental problems with the AMCC 440EP
acting as a PCI target/slave;
1. As a PCI target, there is only one way to generate
an interrupt to a host; you basically toggle the
interrupt pin. This makes it tricky to develop a
host-to-slave communications protocol, eg. its
hard to use the single interrupt to indicate various
interrupt states, eg. target-to-host buffer has
data versus host-to-target buffer has been emptied.
Ideally AMCC should have implemented mailboxes and/or
doorbell registers like any other sane PCI target
device (eg. some the Freescale processors, or any of
the PLX technologies chips).
2. Look in the data sheet and see if you can figure out
how the host processor can generate an interrupt to
the PowerPC core ... oops, you can't. That kind of
makes it difficult to work with doesn't it.
A work around would be to have the host write to the
GPIO register and wire a GPIO pin back to an external
interrupt pin. Then you would not be able to use any
other GPIO pin in that GPIO register since there is
no way to arbitrate host access versus PowerPC core
access.
This was the other reason I ditched the AMCC part in
favor of the Freescale part.
If you are looking at other parts, make sure you look
in the PCI configuration space of the processor reference
manual. Many processors have the interrupt pin register
hardwired to zero, i.e., they can not be used as target
devices, only hosts. In that case you'd have to add an
intel 21555 non-transparent bridge to make the device
a target.
Cheers,
Dave
^ permalink raw reply
* Re: PCI I/O space -- reg or ranges?
From: Gerhard Pircher @ 2007-09-06 20:51 UTC (permalink / raw)
To: Scott Wood, segher; +Cc: linuxppc-dev, david
In-Reply-To: <20070906141501.GA16353@ld0162-tx32.am.freescale.net>
-------- Original-Nachricht --------
> Datum: Thu, 6 Sep 2007 09:15:01 -0500
> Von: Scott Wood <scottwood@freescale.com>
> An: Segher Boessenkool <segher@kernel.crashing.org>
> CC: linuxppc-dev@ozlabs.org, David Gibson <david@gibson.dropbear.id.au>
> Betreff: PCI I/O space -- reg or ranges?
> > Sure, it can be encoded like that. But does it make sense?
> > You cannot use legacy I/O space as normal memory space.
>
> Why does it not make sense? I'm not sure what you mean by using it as
> "normal memory space", but if the PCI bridge does a straightforward
> linear mapping of I/O into memory space (like most non-x86 bridges do),
> it seems to make sense to me to reuse the existing ranges mechanism
> rather than require each driver to have extra glue code.
Well, pci_process_bridge_OF_ranges() only looks at the ranges property to
ioremap() I/O space.
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Segher Boessenkool @ 2007-09-06 20:57 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070906195614.GA23333@ld0162-tx32.am.freescale.net>
>>> BTW, IEEE1275 seems to disagree:
>>
>> No it doesn't.
>
> "...in conventional usage the string begins with the name of the
> device's
> manufacturer".
You cut that sentence short here, it continues: "as with the name
property."
> Even if you want to quibble about the manner in which the
> manufacturer is specified, that's quite different from leaving it out.
The text of the standard says that often people start the model
property contents with an "XYZ,". It doesn't say that is required
(though it hints it might be a good idea to do so). It doesn't say
it is okay to just put some arbitrary text there.
>> That would be "0ABCDEF,Adder MPC875" or "VWXYZ,Adder MPC875" --
>> not "some random string without a comma Adder MPC875".
>
> "the text string is arbitrary" and "conventional usage".
It doesn't say that. It says _the format_ is arbitrary, it is
quite specific about the contents: model name and number.
> That "random string" is more useful for the intended purpose than the
> first half of a MAC address.
What, an OUI isn't useful for uniquely identifying a manufacturer?
That's news to me.
>> i.e., it is machine readable.
>
> No, it *can* be machine usable in certain circumstances. I'm 100% sure
> that there is no code out there that cares what's in the model field of
> this board's device tree,
Why would that matter?
> other than to pass it to /proc/cpuinfo (i.e.
> human consumption).
It's not my fault that /proc/cpuinfo uses strings that are meant
for machine consumption by directly showing them to the user,
without some level of massaging by the platform code first. It
definitely is no argument for doing bad things in your device
tree now, instead of fixing the kernel code.
Anyway, I've said enough about this, I think I've made my point --
and this is very minor stuff after all.
Segher
^ permalink raw reply
* Re: PCI I/O space -- reg or ranges?
From: Segher Boessenkool @ 2007-09-06 21:01 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, david
In-Reply-To: <20070906205137.299990@gmx.net>
>>> Sure, it can be encoded like that. But does it make sense?
>>> You cannot use legacy I/O space as normal memory space.
>>
>> Why does it not make sense? I'm not sure what you mean by using it as
>> "normal memory space", but if the PCI bridge does a straightforward
>> linear mapping of I/O into memory space (like most non-x86 bridges
>> do),
>> it seems to make sense to me to reuse the existing ranges mechanism
>> rather than require each driver to have extra glue code.
> Well, pci_process_bridge_OF_ranges() only looks at the ranges property
> to
> ioremap() I/O space.
That's because it is the function that process the "ranges"
property, like its name shows ;-)
Segher
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: Gerhard Pircher @ 2007-09-06 21:09 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, david
In-Reply-To: <3acb0846724373a8f9edcf4650cc5455@kernel.crashing.org>
-------- Original-Nachricht --------
> Datum: Thu, 6 Sep 2007 15:36:30 +0200
> Von: Segher Boessenkool <segher@kernel.crashing.org>
> An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org, david@gibson.dropbear.id.au
> Betreff: Re: [RFC] AmigaOne device tree source v2
> >> PCI legacy I/O is not direct mapped: there is no legacy I/O on a
> >> PowerPC system bus. So, it can not be mentioned in the "ranges"
> >> property, but the PHB registers used to access it should be shown
> >> in the "reg" property. It could be a simple linear window (it
> >> sounds like it is here?), but it could for example also be implemented
> >> via an address/data register pair.
> > Yes, it is a simple linear address window. I'll remove its address
> > range from the reg property.
>
> No, please remove it from the "ranges" property, instead.
What about the PCI2ISA bridge? I map the first 64k PCI I/O address space
as ISA I/O space by using a ranges property. Would that be incorrect,
too?
Gerhard
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Scott Wood @ 2007-09-06 21:30 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <143f0a1c76539260fd41fe953e6d1bdf@kernel.crashing.org>
On Thu, Sep 06, 2007 at 10:57:28PM +0200, Segher Boessenkool wrote:
> >>>BTW, IEEE1275 seems to disagree:
> >>
> >>No it doesn't.
> >
> >"...in conventional usage the string begins with the name of the
> >device's
> >manufacturer".
>
> You cut that sentence short here, it continues: "as with the name
> property."
You ignored the next sentence, which addressed exactly that point.
> >Even if you want to quibble about the manner in which the
> >manufacturer is specified, that's quite different from leaving it out.
>
> The text of the standard says that often people start the model
> property contents with an "XYZ,". It doesn't say that is required
> (though it hints it might be a good idea to do so). It doesn't say
> it is okay to just put some arbitrary text there.
It says exactly that. They used so many words like "generally",
"arbitrary", "no standard interpretation", "conventional usage", "might",
"for instance", "manufacturer-dependent", etc. that it's fairly clear
that they're merely providing hints as to how the property might be used.
> >>That would be "0ABCDEF,Adder MPC875" or "VWXYZ,Adder MPC875" --
> >>not "some random string without a comma Adder MPC875".
> >
> >"the text string is arbitrary" and "conventional usage".
>
> It doesn't say that. It says _the format_ is arbitrary, it is
> quite specific about the contents: model name and number.
"A manufacturer-dependent string that *generally* specifies the model
name and number".
Besides, that's what I did specify, plus the manufacturer.
> >That "random string" is more useful for the intended purpose than the
> >first half of a MAC address.
>
> What, an OUI isn't useful for uniquely identifying a manufacturer?
> That's news to me.
Not for human consumption.
> >>i.e., it is machine readable.
> >
> >No, it *can* be machine usable in certain circumstances. I'm 100% sure
> >that there is no code out there that cares what's in the model field of
> >this board's device tree,
>
> Why would that matter?
It matters because machine consumption is obviously not how this
particular model property is being used.
> >other than to pass it to /proc/cpuinfo (i.e.
> >human consumption).
>
> It's not my fault that /proc/cpuinfo uses strings that are meant for
> machine consumption by directly showing them to the user, without some
> level of massaging by the platform code first. It definitely is no
> argument for doing bad things in your device tree now, instead of
> fixing the kernel code.
I am not going to add some completely useless layer of indirection
because it suits your odd interpretation of the standard. The
/proc/cpuinfo output of the model property is useful. Descriptive model
properties are useful. Deal with it.
> Anyway, I've said enough about this, I think I've made my point --
> and this is very minor stuff after all.
Whatever, you brought it up.
-Scott
^ permalink raw reply
* Re: PCI target implementation on AMCC PPC CPUs
From: Wolfgang Denk @ 2007-09-06 23:30 UTC (permalink / raw)
To: David Hawkins; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <46E05FFD.3020605@ovro.caltech.edu>
In message <46E05FFD.3020605@ovro.caltech.edu> you wrote:
>
> Freescale's technical (design) support is great, and they
> (the software developers; Kim, Timur, etc) are actively
> maintaining/contributing to git trees for u-boot and Linux.
> If you can change processors, I'd recommend any Freescale
> part over an AMCC part.
But then, a lot of people with in-depth experience with AMCC
processors hang out on the lists and on IRC, too. AMCC is pretty well
supported at least as far as U-Boot and Linux (and the ELDK) go.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If a group of N persons implements a COBOL compiler, there will be
N-1 passes. Someone in the group has to be the manager. - T. Cheatham
^ permalink raw reply
* Re: PCI target implementation on AMCC PPC CPUs
From: David Hawkins @ 2007-09-06 23:39 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <20070906233021.59D1C247AF@gemini.denx.de>
Hi Wolfgang,
>> Freescale's technical (design) support is great, and they
>> (the software developers; Kim, Timur, etc) are actively
>> maintaining/contributing to git trees for u-boot and Linux.
>> If you can change processors, I'd recommend any Freescale
>> part over an AMCC part.
>
> But then, a lot of people with in-depth experience with AMCC
> processors hang out on the lists and on IRC, too. AMCC is pretty well
> supported at least as far as U-Boot and Linux (and the ELDK) go.
Thats good to know.
I was just trying to relay my experience with the two
company's support and with two comparable processors
(440EP vs MPC8349EA).
The nice thing about this group, and open-source in
general, is the 'open' part, everyone can share their
experiences :)
Cheers,
Dave
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Olof Johansson @ 2007-09-06 23:45 UTC (permalink / raw)
To: Scott Wood, Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <20070906213023.GA6399@ld0162-tx32.am.freescale.net>
On Thu, Sep 06, 2007 at 04:30:23PM -0500, Scott Wood wrote:
> On Thu, Sep 06, 2007 at 10:57:28PM +0200, Segher Boessenkool wrote:
> > >>>BTW, IEEE1275 seems to disagree:
> > >>
> > >>No it doesn't.
> > >
> > >"...in conventional usage the string begins with the name of the
> > >device's
> > >manufacturer".
> >
> > You cut that sentence short here, it continues: "as with the name
> > property."
>
> You ignored the next sentence, which addressed exactly that point.
Give it up guys.
Segher, can you please stop riding everybody for every single little
detail in the device trees. Noone will be hurt by the fact that a company
name is part of a machine model string.
This is just a huge productivity sink. How about spending the time
(and bandwidth) on something useful instead?
Thanks,
-Olof
^ permalink raw reply
* Re: [PATCH 3/3] powerpc: setup_64 comment cleanup.
From: Michael Ellerman @ 2007-09-06 23:54 UTC (permalink / raw)
To: Linas Vepstas; +Cc: ppc-dev, Paul Mackerras
In-Reply-To: <20070906174729.GC21800@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2415 bytes --]
On Thu, 2007-09-06 at 12:47 -0500, Linas Vepstas wrote:
> Gramatical corrections to comments.
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
>
> ----
>
> arch/powerpc/kernel/prom.c | 8 +++++---
> arch/powerpc/kernel/setup_64.c | 6 +++---
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> Index: linux-2.6.22-git2/arch/powerpc/kernel/setup_64.c
> ===================================================================
> --- linux-2.6.22-git2.orig/arch/powerpc/kernel/setup_64.c 2007-09-04 17:29:36.000000000 -0500
> +++ linux-2.6.22-git2/arch/powerpc/kernel/setup_64.c 2007-09-05 14:12:23.000000000 -0500
> @@ -181,9 +181,9 @@ void __init early_setup(unsigned long dt
> DBG(" -> early_setup(), dt_ptr: 0x%lx\n", dt_ptr);
>
> /*
> - * Do early initializations using the flattened device
> - * tree, like retreiving the physical memory map or
> - * calculating/retreiving the hash table size
> + * Do early initialization using the flattened device
> + * tree, such as retrieving the physical memory map or
> + * calculating/retrieving the hash table size.
> */
> early_init_devtree(__va(dt_ptr));
That's a little pedantic ..
> Index: linux-2.6.22-git2/arch/powerpc/kernel/prom.c
> ===================================================================
> --- linux-2.6.22-git2.orig/arch/powerpc/kernel/prom.c 2007-09-05 14:23:06.000000000 -0500
> +++ linux-2.6.22-git2/arch/powerpc/kernel/prom.c 2007-09-05 14:24:49.000000000 -0500
> @@ -433,9 +433,11 @@ static int __init early_parse_mem(char *
> }
> early_param("mem", early_parse_mem);
>
> -/*
> - * The device tree may be allocated below our memory limit, or inside the
> - * crash kernel region for kdump. If so, move it out now.
> +/**
> + * move_device_tree - move tree to an unused area, if needed.
> + *
> + * The device tree may be allocated beyond our memory limit, or inside the
> + * crash kernel region for kdump. If so, move it out of the way.
> */
> static void move_device_tree(void)
.. but that looks good. Although it's a semantic change, not just
grammatical as your changelog says.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: David Gibson @ 2007-09-07 0:20 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <22dc6fa3382b591fe721c1b9dee88097@kernel.crashing.org>
On Thu, Sep 06, 2007 at 03:56:38PM +0200, Segher Boessenkool wrote:
> > That looks totally bogus. Unlike Segher, I think there are a few
> > cases where overlapping reg and ranges can make sense
>
> That's not unlike me -- I may have lower tolerance for it though :-)
I see. Can't imagine how I got another impression... :-p
: Date: Thu, 19 Jul 2007 17:51:17 +0200
: From: Segher Boessenkool <segher@kernel.crashing.org>
: Subject: Re: [PATCH] Add 8548CDS with Arcadia 3.0 support
...
: "reg" and "ranges" overlap, that can't be right.
: Date: Tue, 7 Aug 2007 18:51:04 +0200
: From: Segher Boessenkool <segher@kernel.crashing.org>
: Subject: Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
...
: > To be honest this looks rather to me like another case where having
: > overlapping 'reg' and 'ranges' would actually make sense.
:
: It never makes sense. You should give the "master" device
: the full "reg" range it covers, and have it define its own
...
> > (PCI bridges
> > where config space is accessed indirectly via MMIO registers which lie
> > in the legacy ISA IO space is an example).
>
> That's a good example yes.
>
> > But this doesn't look like
> > such a case - it just looks like whoever did the device tree
> > misunderstood the distinction between reg and ranges.
>
> Indeed.
>
> >>> PCI legacy I/O is not direct mapped: there is no legacy I/O on a
> >>> PowerPC system bus. So, it can not be mentioned in the "ranges"
> >>> property, but the PHB registers used to access it should be shown
> >>> in the "reg" property. It could be a simple linear window (it
> >>> sounds like it is here?), but it could for example also be
> >>> implemented
> >>> via an address/data register pair.
> >
> > Err... huh? The legacy IO space is assigned a block of addresses in
> > 3-word "OF-PCI-space by the PCI binding. When that is translated into
> > an MMIO range by the bridge, there's no reason that can't be encoded
> > into the ranges property.
>
> Sure, it can be encoded like that. But does it make sense?
> You cannot use legacy I/O space as normal memory space.
Well, no, but you can't use *any* MMIO space as normal memory space,
and that's handled routinely by 'ranges'.
> On an arch like x86, where "I/O addresses" exist on the system
> bus as well, it would make sense, since you can translate I/O
> addresses to I/O addresses that way (except on x86 even it cannot
> be done either, since I/O addresses cannot be encoded on the root
> bus -- at least not in existing device trees. There is no official
> x86 binding yet though).
What!? This is nuts, Segher. Why should the binding have to define
some bridge-specific way of encoding the legacy I/O information, when
the PCI-binding's address encoding plus 'ranges' provides a perfectly
unambiguous way of doing so. *And* it makes the normal semantics of
ranges do just the right thing for a subordinate PCI<->ISA bridge.
> Also, from a driver standpoint, a PHB driver needs to find out
> two main things about the bridge: a) how and where to generate
> config cycles; b) how and where to generate legacy I/O cycles.
> It is told "how" by the "compatible" property, and "where" by
> the "reg" property, normally.
>
> But yes, you _can_ use "ranges" for this purpose on PHBs where
> legacy I/O is linearly mapped. It just doesn't make much sense.
> The binding for your specific PHB should tell you what to do.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: David Gibson @ 2007-09-07 0:21 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <3acb0846724373a8f9edcf4650cc5455@kernel.crashing.org>
On Thu, Sep 06, 2007 at 03:36:30PM +0200, Segher Boessenkool wrote:
[snip]
> >> PCI legacy I/O is not direct mapped: there is no legacy I/O on a
> >> PowerPC system bus. So, it can not be mentioned in the "ranges"
> >> property, but the PHB registers used to access it should be shown
> >> in the "reg" property. It could be a simple linear window (it
> >> sounds like it is here?), but it could for example also be implemented
> >> via an address/data register pair.
> > Yes, it is a simple linear address window. I'll remove its address
> > range
> > from the reg property.
>
> No, please remove it from the "ranges" property, instead.
No, don't. Removing it from reg is just fine.
> >> The order of the "reg" entries depends on the exact model of PCI
> >> bridge, so a device binding for it has to be written.
> > Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it
> > should
> > be enough to check for the board type, but a compatible property
> > doesn't
> > hurt.
>
> Please always use "compatible" to probe any devices.
Do do that, though.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 03/10] bootwrapper: flatdevtree fixes
From: David Gibson @ 2007-09-07 0:49 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192104.GC32113@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 02:21:04PM -0500, Scott Wood wrote:
> 1. ft_create_node was returning the internal pointer rather than a phandle.
> 2. ft_find_device_rel was treating a "top" phandle of NULL as an error,
> rather than as the root of the tree. The old, absolute ft_find_device
> is removed, and the relative version is renamed to ft_find_device().
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Although I'm getting really close to obsoleting flatdevtree.c
anyway...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 04/10] bootwrapper: Add strtoull().
From: David Gibson @ 2007-09-07 0:50 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192110.GD32113@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 02:21:10PM -0500, Scott Wood wrote:
> This will be needed by PlanetCore firmware support.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 06/10] bootwrapper: Move strncmp() from flatdevtree_env.h to string.S/string.h.
From: David Gibson @ 2007-09-07 0:51 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192114.GF32113@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 02:21:14PM -0500, Scott Wood wrote:
> It will be needed for PlanetCore firmware support.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
I still have a patch that already does this, plus strchr() as well,
pending...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 05/10] bootwrapper: Add get_path().
From: David Gibson @ 2007-09-07 0:52 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192112.GE32113@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 02:21:12PM -0500, Scott Wood wrote:
> This will be used by the PlanetCore firmware support to construct
> a linux,stdout-path from the serial node that it finds.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Although I'm planning to obsolete it RSN..
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 09/10] bootwrapper: Only print MAC addresses when the node is actually present.
From: David Gibson @ 2007-09-07 0:52 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192118.GI32113@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 02:21:18PM -0500, Scott Wood wrote:
> Some firmwares (such as PlanetCore) only provide a base MAC address, and
> expect the kernel to set certain bits to generate the addresses for the
> other ports. As such, MAC addresses are generated that may not correspond
> to actual hardware.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 10/10] bootwrapper: Add fsl_get_immr() and 8xx/pq2 clock functions.
From: David Gibson @ 2007-09-07 0:53 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192119.GJ32113@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 02:21:19PM -0500, Scott Wood wrote:
> fsl_get_immr() is equivalent to the kernel's get_immrbase() function.
>
> mpc885_get_clock() transforms a crystal frequency into a system frequency
> according to the PLL register settings.
>
> pq2_get_clocks() does the same as the above for the PowerQUICC II,
> except that it produces several different clocks.
>
> The mpc8xx/pq2 set_clocks() functions modify common properties in
> the device tree based on the given clock data.
>
> The mpc885/pq2 fixup_clocks() functions call get_clocks(), and
> pass the results to set_clocks().
Uh... doesn't this need to go in the series *before* the patch that
uses fsl_get_immr() for the pq2 code..?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 08/10] bootwrapper: Add a firmware-independent "raw" target.
From: David Gibson @ 2007-09-07 0:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192116.GH32113@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 02:21:16PM -0500, Scott Wood wrote:
> This target produces a flat binary rather than an ELF file,
> fixes the entry point at the beginning of the image, and takes
> a complete device tree with no fixups needed.
>
> The device tree must have labels on /#address-cells, the timebase
> frequency, and the memory size.
Hrm... the actual contents of this patch are less about producing an
unheadered binary image than they are about introducing the "raw"
platform. I don't mind the idea of a "raw" platform (although I'm not
sure I like that name for it), but the patch comment needs work.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 07/10] bootwrapper: Add PlanetCore firmware support.
From: David Gibson @ 2007-09-07 1:03 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192115.GG32113@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 02:21:15PM -0500, Scott Wood wrote:
> This is a library that board code can use to extract information from the
> PlanetCore configuration keys. PlanetCore is used on various boards from
> Embedded Planet.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
[snip]
> +void planetcore_set_mac_addrs(const char *table)
> +{
> + char addr[4][6];
> + u64 int_addr;
> + int i, j;
> +
> + if (!planetcore_get_hex(table, PLANETCORE_KEY_MAC_ADDR, &int_addr))
> + return;
> +
> + for (i = 0; i < 4; i++) {
> + u64 this_dev_addr = int_addr | mac_table[i];
> +
> + for (j = 5; j >= 0; j--) {
> + addr[i][j] = this_dev_addr & 0xff;
> + this_dev_addr >>= 8;
> + }
> + }
> +
> + dt_fixup_mac_addresses(addr[0], addr[1], addr[2], addr[3]);
> +}
It seems a bit silly to loop generating the MAC addresses, then loop
again assigning them to the device nodes. Better, I think, to extract
the loop innards from dt_fixup_mac_addresses(), taking the
network-index as a parameter, then call that from within your loop
here.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Document and implement an improved flash device binding
From: David Gibson @ 2007-09-07 1:04 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <a8b4282d0c58f1090c64591d387dae97@kernel.crashing.org>
On Thu, Sep 06, 2007 at 03:28:35PM +0200, Segher Boessenkool wrote:
> >>> + - bank-width : Width (in bytes) of the flash bank. Equal to
> >>> the
> >>> + device width times the number of interleaved chips.
> >>> + - device-width : (optional) Width of a single flash chip. If
> >>> + omitted, assumed to be equal to 'bank-width'.
> >>
> >> Let's have bank-width optional instead, it's more natural
> >> that way for the common case of just one chip. Or, you can
> >> say that either is optional.
> >
> > No, I'm disinclined to do that since bank-width is the primary bit of
> > information that the driver needs.
>
> Bzzzzt. That's not what the device tree is about; it should
> describe the hardware, it shouldn't be just a config file for
> the current Linux drivers.
Yes, yes, so you've said many times.
But where there are multiple ways of encoding exactly the same
information, I don't see that we can't use driver convenience as a
deciding factor.
> Besides, like I said, for the common case where your flash
> chips aren't interleaved, it makes way more sense to talk
> about device-width than it does to call it bank-width.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: David Gibson @ 2007-09-07 1:15 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20070905132106.GB24637@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 08:21:06AM -0500, Scott Wood wrote:
> On Wed, Sep 05, 2007 at 03:40:23PM +0400, Anton Vorontsov wrote:
> > On Tue, Sep 04, 2007 at 01:20:28PM -0500, Scott Wood wrote:
> > > The kernel is of course welcome to do so -- and this may be a valid
> > > reason to attach pin information to specific device nodes, if it actually
> > > saves a non-negligible amount of power -- but it's not a reason to force
> > > the kernel to have to care by not setting things up in the firmware.
> >
> > Well, I might agree here. But to me it seems unnatural that I have to
> > upgrade bootloader to use SPI -- I can already boot the kernel.
>
> Sure -- the firmware should have been done right the first time.
>
> Unfortunately, it very often doesn't, and thus fixups in the kernel's
> platform code are warranted, but the firmware is still the preferred
> place to do it.
Appealing though it is, I think the whole "firmware is the preferred
place to do it" approach is a lost cause (for nearly every value of
"it").
Firmwares are, more often than not, crap, and that's unlikely to
change. For a lot of things, having the kernel or bootwrapper cope as
a special case with a handful of crap firmwares which don't set things
up properly isn't actually any easier than having it set them up
itself, always.
Which is why I err strongly in favour of having the kernel set things
up rather than rely on firmware setup, unless there's a very strong
reason why we *have* to respect the firmware's setup.
(Incidentally, this reasoning is why although the approach is very
neat-looking, I'm actually quite uncomfortable with firmwares directly
supplying flattened device trees to the kernel, rather than having the
tree in the bootwrapper.)
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 2/6] cuimage for Bamboo board
From: David Gibson @ 2007-09-07 1:06 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1188971635.3223.9.camel@localhost.localdomain>
On Wed, Sep 05, 2007 at 12:53:54AM -0500, Josh Boyer wrote:
> On Wed, 2007-09-05 at 15:46 +1000, David Gibson wrote:
> > > > > > There must surely be a way to get the MAC addresses out of OpenBIOS...
> > > > >
> > > > > Probably. I just need to find out where they are stored.
> > > >
> > > > It's not buried somewhere in the arch/ppc/boot code?
> > >
> > > It's not OpenBIOS, it's PIBS. And the arch/ppc port uses __res, which
> > > I'd rather avoid. But I did find where it's stored in flash, so I can
> > > read it from there. I just need to do a little more work to get it in a
> > > manner that can be used.
> >
> > Hrm.. is that address actually guaranteed to be stable across PIBS
> > versions? If arch/ppc uses __res, I think we should do that too. It
> > shouldn't be any worse than what we already do fot cuboot.
>
> The address should be stable for all versions of PIBS that come on the
> Bamboo boards, yes. And after looking at it a bit more, the wrapper in
> arch/ppc for PIBS essentially mocks up __res by reading the values out
> of flash. So the way I'm doing it is the way it was already done.
Ah, ok. Fine then.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 3/6] Walnut DTS
From: David Gibson @ 2007-09-07 1:07 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070905113317.630ee687@weaponx.rchland.ibm.com>
On Wed, Sep 05, 2007 at 11:33:17AM -0500, Josh Boyer wrote:
> Updated DTS below
>
> Device tree source file for the PPC405 Walnut evaluation board.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox