Hi,
I am using 2.6.23-rc3 kernel. In this kernel immap_86xx.h file was
loacted in the path: include/asm-powerpc/immap_86xx.h.
This file contains only PCI and Global utility Regsiters
Declarations. LocalBus Controller, Local Access Registers and Rapid IO
Register Declara
Segher Boessenkool wrote:
> This kind of thing is typically hardcoded into the firmware (just like
> the device tree is) -- just put it somewhere _next to_ the device tree,
> not _in_ it.
What is next to the device tree? AFAIK, there is no other standard data
structure that could take place of
I have used ml403 reference board recently, and now I am porting the
opb_ethernet driver downloaded from the net onto the board. I use the EDK9.1
developing environment, and the driver files like "xemac.c" are copied from the
EDK drivers lib. My opb_ethernet driver can work in the "No DMA mode",
With kernel commit eff2ebd207af9f501af0ef667a7d14befcb36c1b, we
clarified that in the flattened tree format, a particular nodes
properties are required to precede its subdnodes.
At present however, both dtc and libfdt will process trees which don't
meet this condition. This patch simplifies the c
On Tue, Sep 04, 2007 at 12:52:02AM +0200, Segher Boessenkool wrote:
> >>> Yeah, PCI is a special case for Linux. Maybe add a "pciclass,"
> >>> compatible property though, for good measure. Anything else isn't
> >>> all that useful I think.
> > Wouldn't that be the same as the class-code prope
> I expect very few things from the bootloader: setup memory controller,
Setup CPUs, clocks and voltages, system busses, system controllers,
memory controllers, memory itself, _and system GPIOs_ :-)
You know, all the basic and/or board-specific stuff that is needed to
run a system. This kind of
>> Not at all. The device tree describe how the hardware _is_
>> set up (after firmware, bootloader etc.); now how it _should
>> be_ set up by the kernel.
>
> I agree with this general sentiment, but in the case of QE pin
> configuration, then device tree, in a sense, does contain how the
> hard
>>> Yeah, PCI is a special case for Linux. Maybe add a "pciclass,"
>>> compatible property though, for good measure. Anything else isn't
>>> all that useful I think.
> Wouldn't that be the same as the class-code property?
Sure, except it is a different property. If you use the "class-code"
>>> [EMAIL PROTECTED] {
>>> device_type = "pci";
>>> bus-frequency = <01fca055>; // 33.3MHz
>>> bus-range = <0 1>;
>>> reg = <8000 7f00>; //
>>> Whole PCI space.
>>
>> 'reg' and 'ranges' should not
On Thu, Aug 30, 2007 at 02:42:41PM -0500, Brent Casavant wrote:
> On Thu, 30 Aug 2007, Nick Piggin wrote:
>
> > I don't know whether this is exactly a correct implementation of
> > Linux's barrier semantics. On one hand, wmb _is_ ordering the stores
> > as they come out of the CPU; on the other, i
Hi,
Original-Nachricht
> Datum: Mon, 3 Sep 2007 20:12:34 +1000
> Von: David Gibson <[EMAIL PROTECTED]>
> An: Segher Boessenkool <[EMAIL PROTECTED]>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: [RFC] AmigaOne device tree source v2
> On Mon, Sep 03, 2007 at 12:02:58PM +0200, Seghe
On Mon, Sep 03, 2007 at 08:55:56AM -0500, Timur Tabi wrote:
[...]
> Besides, every other board does it's par_io configuration based on the
> device tree.
My words. ;-) See
http://ozlabs.org/pipermail/linuxppc-dev/2007-August/040685.html
Also, see how it was made initially:
http://ozlabs.org/pipe
Hi,
Original-Nachricht
> Datum: Mon, 3 Sep 2007 11:34:31 +1000
> Von: David Gibson <[EMAIL PROTECTED]>
> An: Gerhard Pircher <[EMAIL PROTECTED]>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: [RFC] AmigaOne device tree source v2
> Interrupt routing information is really necessary.
Segher Boessenkool wrote:
> Not at all. The device tree describe how the hardware _is_
> set up (after firmware, bootloader etc.); now how it _should
> be_ set up by the kernel.
I agree with this general sentiment, but in the case of QE pin configuration,
then device tree, in a sense, does cont
On Mon, 2007-09-03 at 11:01 +1000, David Gibson wrote:
> On Fri, Aug 31, 2007 at 03:04:51PM -0500, Josh Boyer wrote:
> > Add a cuboot wrapper for the Bamboo board. This also removes some obsoleted
> > linker declarations that have been moved into ops.h
> >
> > Signed-off-by: Josh Boyer <[EMAIL PR
On Mon, 2007-09-03 at 11:08 +1000, David Gibson wrote:
> On Fri, Aug 31, 2007 at 03:04:52PM -0500, Josh Boyer wrote:
> > Device tree source file for the PPC405 Walnut evaluation board.
> >
> > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
> >
> > ---
> > arch/powerpc/boot/dts/walnut.dts | 183
On Mon, 2007-09-03 at 11:11 +1000, David Gibson wrote:
> On Fri, Aug 31, 2007 at 03:04:54PM -0500, Josh Boyer wrote:
> > Board support for the PPC405 Walnut evaluation board
> >
> > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
>
> [snip]
> > --- linux-2.6.orig/arch/powerpc/platforms/40x/Kconfig
On Mon, 2007-09-03 at 11:13 +1000, David Gibson wrote:
> On Fri, Aug 31, 2007 at 03:04:55PM -0500, Josh Boyer wrote:
> > Add zImage wrapper for walnut board
> >
> > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
>
> [snip]
> > --- /dev/null
> > +++ linux-2.6/arch/powerpc/boot/treeboot-walnut.c
> >
> + j) CFI or JEDEC memory-mapped NOR flash
>
> Flash chips (Memory Technology Devices) are often used for solid
> state
> file systems on embedded devices.
Well, almost everything has a NOR flash on it, not just
embedded boards ;-)
> + - bank-width : Width (in bytes) of the flas
On Mon, Sep 03, 2007 at 12:02:58PM +0200, Segher Boessenkool wrote:
> >>> [EMAIL PROTECTED] {
> >>
> >> The unit address (after the @) should be derived from the first range
> >> listed in the 'reg' property. It's a bus address, not a slot number.
> >
> > Actually... on PCI, the unit add
>>> [EMAIL PROTECTED] {
>>
>> The unit address (after the @) should be derived from the first range
>> listed in the 'reg' property. It's a bus address, not a slot number.
>
> Actually... on PCI, the unit address is often the slot number, or
> rather, "slot,function" with the second pa
> 'reg' and 'ranges' should not typically overlap. 'reg' should only
> encode control registers for the bridge, not the whole PCI space (not
> that I'm even entirely sure what you mean by that).
>
> > ranges = <0100 0 fe00 0 00c0 // PCI
> > I/O
> >
22 matches
Mail list logo
