* 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: [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: 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: [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: 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: 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 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: [RFC/PATCH 2/2] Generic clockevents and no-idle-HZ for PowerPC
From: Olof Johansson @ 2007-09-06 20:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20070906191516.GA20090@lixom.net>
Hi again,
On Thu, Sep 06, 2007 at 02:15:16PM -0500, Olof Johansson wrote:
> I don't think that set_dec() is needed any more. I get a very long
> delay during "Calibrating delay loop..." with it there.
>
> Looks like decrementer_set_next_event() already sets a reasonable
> decementer value, it's called through the notify chain set off
> from register_decrementer_clockevent() -> ... -> tick_notify() ->
> tick_setup_periodic() -> clockevents_program_event().
One more problem for at least PA6T is that we'll keep taking decrementer
exceptions as long as DEC contains a negative value, and there seems
to be cases where this happens, i.e. it's not reset for other reasons.
I ended up adding a set_dec(DECREMENTER_MAX) at the start of
timer_interrupt() to avoid the case where none of the code paths through
timer_interrupt() resets the decrementer. I didn't have time to fully
dig down and figure out what paths causes this and why, so I suppose it's
more of a workaround than a solution.
I think 970 behaves the same, but I haven't verified.
-Olof
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Scott Wood @ 2007-09-06 19:56 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <43ad9218d498e2d01922a57ebfee2327@kernel.crashing.org>
On Thu, Sep 06, 2007 at 09:36:07PM +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". Even if you want to quibble about the manner in which the
manufacturer is specified, that's quite different from leaving it out.
> > A manufacturer-dependent string that generally specifies the model
> >name
> > and number (including revision level) for this device. The format of
> > the text string is arbitrary, although in conventional usage the
> >string
> > begins with the name of the device's manufacturer as with the name
> > property.
>
> 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".
That "random string" is more useful for the intended purpose than the
first half of a MAC address.
> > Although there is no standard interpretation for the value of the
> >model
> > property, a specific device driver might use it to learn, for
> >instance,
> > the revision level of its particular device.
>
> 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, other than to pass it to /proc/cpuinfo (i.e.
human consumption).
-Scott
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Segher Boessenkool @ 2007-09-06 19:36 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070906192025.GA22775@ld0162-tx32.am.freescale.net>
> BTW, IEEE1275 seems to disagree:
No it doesn't.
> A manufacturer-dependent string that generally specifies the model
> name
> and number (including revision level) for this device. The format of
> the text string is arbitrary, although in conventional usage the
> string
> begins with the name of the device's manufacturer as with the name
> property.
That would be "0ABCDEF,Adder MPC875" or "VWXYZ,Adder MPC875" --
not "some random string without a comma Adder MPC875".
> Although there is no standard interpretation for the value of the
> model
> property, a specific device driver might use it to learn, for
> instance,
> the revision level of its particular device.
i.e., it is machine readable.
Segher
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Segher Boessenkool @ 2007-09-06 19:32 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070906191255.GA22663@ld0162-tx32.am.freescale.net>
>>>>>>> + model = "Analogue & Micro Adder MPC875";
>>>>>>
>>>>>> This should probably be just "MPC875".
>>>>>
>>>>> There's more than one board with an MPC875 on it.
>>>>
>>>> "model" is the model name the vendor uses. It isn't supposed to
>>>> be unique globally, nor does it say what CPU is on the board.
>>>
>>> The name the vendor uses is "Adder MPC875". The name of the vendor
>>> is
>>> "Analogue & Micro", which seems useful to include, even if it's not
>>> mandatory that it be globally unique.
>>
>> So it should be "Adder MPC875", then :-)
>
> Any particular reason to leave out potentially useful information in a
> field that is for human consumption?
Because it isn't for human consumption (only), and has well-defined
semantics (although slightly fuzzy).
> Other than Because Segher Says So(tm). :-)
"Because the OF standard says so" :-)
Segher
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Scott Wood @ 2007-09-06 19:20 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <20070906191255.GA22663@ld0162-tx32.am.freescale.net>
On Thu, Sep 06, 2007 at 02:12:55PM -0500, Scott Wood wrote:
> On Thu, Sep 06, 2007 at 08:48:12PM +0200, Segher Boessenkool wrote:
> > So it should be "Adder MPC875", then :-)
>
> Any particular reason to leave out potentially useful information in a
> field that is for human consumption?
>
> Other than Because Segher Says So(tm). :-)
BTW, IEEE1275 seems to disagree:
"model"
Standard property name to define a manufacturer's model number.
prop-encoded-array:
Text string, encoded with encode-string.
A manufacturer-dependent string that generally specifies the model name
and number (including revision level) for this device. The format of
the text string is arbitrary, although in conventional usage the string
begins with the name of the device's manufacturer as with the name
property.
Although there is no standard interpretation for the value of the model
property, a specific device driver might use it to learn, for instance,
the revision level of its particular device.
See also: property, model.
Used as: " XYZCO,1416-02" encode-string " model" property
-Scott
^ permalink raw reply
* Re: finding out the processor frequency
From: Josh Boyer @ 2007-09-06 19:15 UTC (permalink / raw)
To: Scott Wood; +Cc: Leisner, Martin, linuxppc-embedded
In-Reply-To: <20070906184308.GA22380@ld0162-tx32.am.freescale.net>
On Thu, 6 Sep 2007 13:43:08 -0500
Scott Wood <scottwood@freescale.com> wrote:
> On Thu, Sep 06, 2007 at 02:24:30PM -0400, Leisner, Martin wrote:
> > What exactly do we mean by "timebase"?
> >
> > There a symbol in arch/powerpc/time.c:ppc_proc_freq which looks like the
> > processor frequency (derived from the dts). But its not exported.
> >
> > There's also ppc_tb_freq.
>
> The timebase is the rate at which the timebase and decrementer registers
> tick. It is not the same as the CPU core frequency.
Unless your timebase and decrementer clock source is tied to the CPU
clock. :)
So it depends on the board, and it can even depend on how the board is
initialized. Some boards can change the timebase clock source on the
fly.
josh
^ permalink raw reply
* PCI target implementation on AMCC PPC CPUs
From: Leonid @ 2007-09-06 19:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070906184308.GA22380@ld0162-tx32.am.freescale.net>
Hi:
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?
Thanks,
Leonid.
^ permalink raw reply
* Re: [RFC/PATCH 2/2] Generic clockevents and no-idle-HZ for PowerPC
From: Olof Johansson @ 2007-09-06 19:15 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18144.4702.673658.336384@cargo.ozlabs.ibm.com>
Hi,
Nice! I've been looking forward to these patches. Should help keep power
consumption down on machines with powersavings support for idle.
On Fri, Sep 07, 2007 at 12:44:46AM +1000, Paul Mackerras wrote:
> @@ -749,6 +805,8 @@ void __init clocksource_init(void)
> printk(KERN_INFO "clocksource: %s mult[%x] shift[%d] registered\n",
> clocksource_timebase.name,
> clocksource_timebase.mult, clocksource_timebase.shift);
> +
> + init_decrementer_clockevent();
> }
>
> /* This function is only called on the boot processor */
> @@ -874,8 +932,7 @@ void __init time_init(void)
> /* Register the clocksource */
> clocksource_init();
>
> - /* Not exact, but the timer interrupt takes care of this */
> - set_dec(tb_ticks_per_jiffy);
> + set_dec(DECREMENTER_MAX);
> }
I don't think that set_dec() is needed any more. I get a very long
delay during "Calibrating delay loop..." with it there.
Looks like decrementer_set_next_event() already sets a reasonable
decementer value, it's called through the notify chain set off
from register_decrementer_clockevent() -> ... -> tick_notify() ->
tick_setup_periodic() -> clockevents_program_event().
-Olof
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Scott Wood @ 2007-09-06 19:12 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <598e0baf0dc1ca63b91f2a80ec8abe19@kernel.crashing.org>
On Thu, Sep 06, 2007 at 08:48:12PM +0200, Segher Boessenkool wrote:
> >>>>>+ model = "Analogue & Micro Adder MPC875";
> >>>>
> >>>>This should probably be just "MPC875".
> >>>
> >>>There's more than one board with an MPC875 on it.
> >>
> >>"model" is the model name the vendor uses. It isn't supposed to
> >>be unique globally, nor does it say what CPU is on the board.
> >
> >The name the vendor uses is "Adder MPC875". The name of the vendor is
> >"Analogue & Micro", which seems useful to include, even if it's not
> >mandatory that it be globally unique.
>
> So it should be "Adder MPC875", then :-)
Any particular reason to leave out potentially useful information in a
field that is for human consumption?
Other than Because Segher Says So(tm). :-)
-Scott
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Segher Boessenkool @ 2007-09-06 18:48 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070906180922.GA18750@ld0162-tx32.am.freescale.net>
>>>>> + model = "Analogue & Micro Adder MPC875";
>>>>
>>>> This should probably be just "MPC875".
>>>
>>> There's more than one board with an MPC875 on it.
>>
>> "model" is the model name the vendor uses. It isn't supposed to
>> be unique globally, nor does it say what CPU is on the board.
>
> The name the vendor uses is "Adder MPC875". The name of the vendor is
> "Analogue & Micro", which seems useful to include, even if it's not
> mandatory that it be globally unique.
So it should be "Adder MPC875", then :-)
Segher
^ permalink raw reply
* Re: finding out the processor frequency
From: Scott Wood @ 2007-09-06 18:43 UTC (permalink / raw)
To: Leisner, Martin; +Cc: linuxppc-embedded
In-Reply-To: <556445368AFA1C438794ABDA8901891C06460054@USA0300MS03.na.xerox.net>
On Thu, Sep 06, 2007 at 02:24:30PM -0400, Leisner, Martin wrote:
> What exactly do we mean by "timebase"?
>
> There a symbol in arch/powerpc/time.c:ppc_proc_freq which looks like the
> processor frequency (derived from the dts). But its not exported.
>
> There's also ppc_tb_freq.
The timebase is the rate at which the timebase and decrementer registers
tick. It is not the same as the CPU core frequency.
-Scott
^ permalink raw reply
* RE: Newbie on embedded linux on PPC: error: cannot find boot.o
From: Stephen Neuendorffer @ 2007-09-06 18:39 UTC (permalink / raw)
To: Thomas Gerlach; +Cc: linuxppc-embedded
In-Reply-To: <20070904213339.D3DB7788046@mail56-fra.bigfish.com>
=20
You can also build a ppc405 toolchain using Crosstool, and it works
fine..
http://kegel.com/crosstool
Steve
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> =20
> [mailto:linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@oz
labs.org] On Behalf Of Wolfgang Reissnegger
> Sent: Tuesday, September 04, 2007 2:33 PM
> To: Thomas Gerlach
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Newbie on embedded linux on PPC: error: cannot=20
> find boot.o
>=20
> Hi Thomas,
>=20
> Xilinx is building the tools in the EDK to work with VxWorks=20
> and for Standalone systems. In order to compile a Linux=20
> kernel you need to get a toolchain from one of the Third=20
> Party vendors, such as MontaVista. They have the correct=20
> linker scripts for building a kernel.
>=20
> Cheers,
> Wolfgang
>=20
> Thomas Gerlach wrote:
> > hi folks,
> >=20
> >=20
> > my name is thomas trying to make embedded linux run on a=20
> powerpc, but
> > we've got special boards here, although we use a xilinx virtex4
> > fpga...
> >=20
> > as you said in the nabble-thread (see subject), i set up edk9.1
> > software platform settings und ran libgen to get the xparameters*
> > files. i copied those bsp files into the kernel tree (i use your
> > kernel linux-2.6-virtex from git.secretlabs.ca/git). after
> > configuring the kernel settigs, i try
> >=20
> > $ make ARCH=3Dppc CROSS_COMPILE=3Dpowerpc-eabi-
> >=20
> > what i get is the following output:
> >=20
> >> CHK include/linux/version.h
> >> CHK include/linux/utsrelease.h
> >> CALL scripts/checksyscalls.sh
> >> CHK include/linux/compile.h
> >> LD init/mounts.o
> >> powerpc-eabi-ld: cannot find boot.o
> >> make[1]: *** [init/mounts.o] Error 1
> >> make: *** [init] Error 2
> >=20
> > so, i searched for boot.o (it exists) and even copied it=20
> into several
> > dirs of the linux kernel tree (where i thought i would make sense),
> > but the problem still remains.
> >=20
> > googling results in
> >=20
> >=20
> http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=3D1&g
etPagePath=3D17462&BV_SessionID=3D@@@@1197140711.1188909240>
@@@@&BV_EngineID=3Dcccgaddllgmfkflcefeceihdffhdfkf.0
> >=20
> >=20
> > and this, too, doesn't take me further in solving the problem.
> >=20
> > i hope you can help me.
> >=20
> > many thanks in advance,
> >=20
> > kind regards
> > thomas gerlach
> >=20
> >=20
> >=20
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
^ permalink raw reply
* RE: Kernel Debug on Virtex4-FX
From: Stephen Neuendorffer @ 2007-09-06 18:37 UTC (permalink / raw)
To: Robert Woodworth, linuxppc-embedded
In-Reply-To: <1189103551.6185.66.camel@PisteOff>
It believe it should work fine:
You just need to set breakpoints in the kernel proper=20
using virtual memory addresses.
I've never actually tried tracing through the enabling of the MMU,
however...
Steve
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> =20
> [mailto:linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@oz
labs.org] On Behalf Of Robert Woodworth
> Sent: Thursday, September 06, 2007 11:33 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Kernel Debug on Virtex4-FX
>=20
> Is it possible to debug the kernel via Xilinx JTAG Platform USB cable?
>=20
> If so, how?
> I can debug through the embedded-config.c and boot loader,=20
> but once the
> kernel boots, (VM on) I cannot debug anymore. =20
>=20
>=20
> Or do I have to use kgdb through serial?=20
>=20
>=20
>=20
>=20
> Rob.
>=20
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
^ permalink raw reply
* Kernel Debug on Virtex4-FX
From: Robert Woodworth @ 2007-09-06 18:32 UTC (permalink / raw)
To: linuxppc-embedded
Is it possible to debug the kernel via Xilinx JTAG Platform USB cable?
If so, how?
I can debug through the embedded-config.c and boot loader, but once the
kernel boots, (VM on) I cannot debug anymore.
Or do I have to use kgdb through serial?
Rob.
^ permalink raw reply
* finding out the processor frequency
From: Leisner, Martin @ 2007-09-06 18:24 UTC (permalink / raw)
To: linuxppc-embedded
What exactly do we mean by "timebase"?
There a symbol in arch/powerpc/time.c:ppc_proc_freq which looks like the
processor frequency (derived from the dts). But its not exported.
There's also ppc_tb_freq.
marty
^ permalink raw reply
* Re: [RFC/PATCH 1/2] Basic generic time/clocksource code for PowerPC
From: Paul Mackerras @ 2007-09-06 18:20 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev
In-Reply-To: <20070906165535.GA11420@iram.es>
Gabriel Paubert writes:
> On Fri, Sep 07, 2007 at 12:41:38AM +1000, Paul Mackerras wrote:
> > This changes PowerPC to use the generic time infrastructure for
> > gettimeofday et al. We register a clocksource which uses the timebase
> > register, or the RTC on the 601.
> >
> > It also gets rid of the RTC update stuff. IIRC we discussed removing
> > this some time ago but never actually did it.
>
> So who will be in charge of updating the RTC now? The update
> every 11 min is there to stay on x86(-64) it seems.
I had an impression that ntpd would do it, but that seems to be wrong.
I also have been unable to find where in the kernel source there is
code for x86[-64] to do the RTC updates. Do you know where it is?
Doing the updates from timer_interrupt will no longer really be
suitable since it is not called at regular intervals any more. The
best thing would be for the ntp code to set up a timer when it reaches
synchronization.
> Removing this will have strange side effects: as an example,
> your laptop clock will be good if it synchronized on NTP,
> then you put it to sleep, disconnect the network and RTC read
> on wake up returns a wrong value, giving wrong timestamps.
No, the suspend/resume code reads the RTC on both suspend and resume,
and advances xtime by the difference between the two readings. So the
time might be out by up to a second after resume, but it shouldn't be
way off, assuming that your RTC is advancing at the right speed.
> As someone who has a network of tens of machines using
> NTP for synchornisation I think it is a very bad idea
> unless we have a replacement.
OK, but I think that doing it in timer_interrupt is the wrong place.
Paul.
^ permalink raw reply
* Re: [PATCH 8/9] 8xx: Adder 875 support
From: Scott Wood @ 2007-09-06 18:09 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <f26578467468e38345e795ea5f1f7c42@kernel.crashing.org>
On Thu, Sep 06, 2007 at 07:50:32PM +0200, Segher Boessenkool wrote:
> >>>+ model = "Analogue & Micro Adder MPC875";
> >>
> >>This should probably be just "MPC875".
> >
> >There's more than one board with an MPC875 on it.
>
> "model" is the model name the vendor uses. It isn't supposed to
> be unique globally, nor does it say what CPU is on the board.
The name the vendor uses is "Adder MPC875". The name of the vendor is
"Analogue & Micro", which seems useful to include, even if it's not
mandatory that it be globally unique.
-Scott
^ permalink raw reply
* [PATCH 3/3] powerpc: setup_64 comment cleanup.
From: Linas Vepstas @ 2007-09-06 17:47 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev
In-Reply-To: <20070906174615.GB21800@austin.ibm.com>
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));
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)
{
^ 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