* Re: [PATCH 02/10] cpm2: Fix off-by-one error in setbrg().
From: Scott Wood @ 2007-09-10 21:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <5275D8E2-1DF2-4E2E-B9AC-7E085E69BF72@kernel.crashing.org>
Kumar Gala wrote:
>
> On Sep 10, 2007, at 2:44 PM, Scott Wood wrote:
>
>> Kumar Gala wrote:
>>> On Sep 5, 2007, at 2:29 PM, Scott Wood wrote:
>>>> The hardware adds one to the BRG value to get the divider, so it must
>>>> be subtracted by software. Without this patch, characters will
>>>> occasionally
>>>> be corrupted.
>>>>
>>>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>>>> ---
>>>> arch/powerpc/sysdev/cpm2_common.c | 2 +-
>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>> What was this patch against?
>>> I ended up applying it by hand for 2.6.23 since its fixing a bug..
>>> But, I'm wondering if there was a base set of changes this patchset
>>> was against?
>>
>> It was against head-of-your-tree as of the time I sent it.
>
> Odd, my top of tree doesn't use out_be32() for cpm_setbrg().
That was done by patch 01/10. :-)
-Scott
^ permalink raw reply
* Re: [PATCH 02/10] cpm2: Fix off-by-one error in setbrg().
From: Kumar Gala @ 2007-09-10 21:07 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <46E59E9E.30707@freescale.com>
On Sep 10, 2007, at 2:44 PM, Scott Wood wrote:
> Kumar Gala wrote:
>> On Sep 5, 2007, at 2:29 PM, Scott Wood wrote:
>>> The hardware adds one to the BRG value to get the divider, so it
>>> must
>>> be subtracted by software. Without this patch, characters will
>>> occasionally
>>> be corrupted.
>>>
>>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>>> ---
>>> arch/powerpc/sysdev/cpm2_common.c | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>> What was this patch against?
>> I ended up applying it by hand for 2.6.23 since its fixing a
>> bug.. But, I'm wondering if there was a base set of changes this
>> patchset was against?
>
> It was against head-of-your-tree as of the time I sent it.
Odd, my top of tree doesn't use out_be32() for cpm_setbrg().
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Don't use generic machine check parsing everywhere
From: Paul Mackerras @ 2007-09-10 20:58 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20070905024159.GB27139@lixom.net>
Olof Johansson writes:
> If a platform provide it's own machine check handler, assume that code
> will handle the reason parsing and reporting the error. The current
> default fall-though only makes sense on a few 32-bit platforms that
> lack individual handlers.
Might be nice to put that code into a function of its own, called
print_6xx_machine_check or something similar.
Paul.
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: Jon Loeliger @ 2007-09-10 20:39 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppc-dev
In-Reply-To: <b976a70bd1942da7e31b9a409b2de569@kernel.crashing.org>
On Thu, 2007-09-06 at 09:09, Segher Boessenkool wrote:
> >> Either way, it's a bit late to change this, no?
> >
> > Sure, I was just whining due to having been bitten by this sort of bug
> > in
> > the past. :-)
>
> Write a song about it, it's therapeutical it seems!
One of these things is not like the others,
One of these things just doesn't belong,
Can you tell which thing is not like the others
By the time I finish my song?
Never mind.
jdl
^ permalink raw reply
* Re: [PATCH 02/10] cpm2: Fix off-by-one error in setbrg().
From: Scott Wood @ 2007-09-10 19:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <EDF5D1CF-E423-449F-A435-9BD044206F4F@kernel.crashing.org>
Kumar Gala wrote:
>
> On Sep 5, 2007, at 2:29 PM, Scott Wood wrote:
>
>> The hardware adds one to the BRG value to get the divider, so it must
>> be subtracted by software. Without this patch, characters will
>> occasionally
>> be corrupted.
>>
>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>> ---
>> arch/powerpc/sysdev/cpm2_common.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> What was this patch against?
>
> I ended up applying it by hand for 2.6.23 since its fixing a bug.. But,
> I'm wondering if there was a base set of changes this patchset was against?
It was against head-of-your-tree as of the time I sent it.
-Scott
^ permalink raw reply
* Re: [PATCH 02/10] cpm2: Fix off-by-one error in setbrg().
From: Kumar Gala @ 2007-09-10 19:46 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192910.GA32462@ld0162-tx32.am.freescale.net>
On Sep 5, 2007, at 2:29 PM, Scott Wood wrote:
> The hardware adds one to the BRG value to get the divider, so it must
> be subtracted by software. Without this patch, characters will
> occasionally
> be corrupted.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/sysdev/cpm2_common.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
What was this patch against?
I ended up applying it by hand for 2.6.23 since its fixing a bug..
But, I'm wondering if there was a base set of changes this patchset
was against?
- k
> diff --git a/arch/powerpc/sysdev/cpm2_common.c b/arch/powerpc/
> sysdev/cpm2_common.c
> index dbef50c..99ad1ed 100644
> --- a/arch/powerpc/sysdev/cpm2_common.c
> +++ b/arch/powerpc/sysdev/cpm2_common.c
> @@ -102,7 +102,7 @@ cpm_setbrg(uint brg, uint rate)
> brg -= 4;
> }
> bp += brg;
> - out_be32(bp, ((BRG_UART_CLK / rate) << 1) | CPM_BRG_EN);
> + out_be32(bp, (((BRG_UART_CLK / rate) - 1) << 1) | CPM_BRG_EN);
>
> cpm2_unmap(bp);
> }
> --
> 1.5.3
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-09-10 19:13 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
There are four bug-fixes there. Three of them are to fix problems on
PS3 and the fourth is to fix a problem on POWER6 machines.
Thanks,
Paul.
arch/powerpc/kernel/ibmebus.c | 30 +++++++++---------------------
arch/powerpc/platforms/cell/spu_base.c | 24 +++++++++++++++---------
arch/powerpc/platforms/ps3/platform.h | 1 +
arch/powerpc/platforms/ps3/repository.c | 29 +++++++++++++++++++++++++++++
arch/powerpc/platforms/ps3/spu.c | 2 ++
include/asm-powerpc/spu.h | 2 +-
6 files changed, 57 insertions(+), 31 deletions(-)
commit d8612417b2f78767b96ca434b50d23e5cdfcde07
Author: Joachim Fenkes <fenkes@de.ibm.com>
Date: Wed Aug 29 18:15:17 2007 +0200
[POWERPC] ibmebus: Prevent bus_id collisions
Previously, ibmebus derived a device's bus_id from its location code.
The location code is not guaranteed to be unique, so we might get bus_id
collisions if two devices share the same location code. The OFDT
full_name, however, is unique, so we use that instead (truncating it
on the left if it is too long).
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit d51dd3de87026cb0ea1ea5f873f08e930053bfc5
Author: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Date: Thu Sep 6 18:14:57 2007 +0200
[POWERPC] cell/PS3: Ignore storage devices that are still being probed
On PS3, A storage device may show up in the repository before the hypervisor
has finished probing:
- If its type is not yet known, it shows up as PS3_DEV_TYPE_STOR_DUMMY,
- If its regions are being probed, it shows up as having zero regions.
If any of these happen, consider the device not yet present. The storage
probe thread will retry later.
This fixes the timing-dependent problem where a kernel booted from FLASH ROM
sometimes cannot find the hard disk.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Acked-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit ef8034d01a080e81488e9cf74052acf1e2a37bd0
Author: Jeremy Kerr <jk@ozlabs.org>
Date: Fri Sep 7 18:28:27 2007 +1000
[POWERPC] cell/PS3: Always set master run control bit in mfc_sr1_set
At present, running any SPE program on the ps3 will trigger a BUG_ON
when spufs_run_spu tries to clear the master run control bit, as lv1
does not make the master run control available to Linux.
This change makes SPE apps work again by disabling changes to the
master run control on PS3. Although we don't have the facility to
disable a SPE with supervisor-level privileges, it's better than
hitting the BUG_ON unconditionally.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Acked-by: Masato Noguchi <Masato.Noguchi@jp.sony.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit b7f90a406ff72d6698b619210c205e3375dd099a
Author: Masato Noguchi <Masato.Noguchi@jp.sony.com>
Date: Fri Sep 7 18:28:27 2007 +1000
[POWERPC] cell/PS3: Fix a bug that causes the PS3 to hang on the SPU Class 0 interrupt.
The Cell BE Architecture spec states that the SPU MFC Class 0 interrupt
is edge-triggered. The current spu interrupt handler assumes this
behavior and does not clear the interrupt status.
The PS3 hypervisor visualizes all SPU interrupts as level, and on return
from the interrupt handler the hypervisor will deliver a new virtual
interrupt for any unmasked interrupts which for which the status has not
been cleared. This fix clears the interrupt status in the interrupt
handler.
Signed-off-by: Masato Noguchi <Masato.Noguchi@jp.sony.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* RE: futex priority based wakeup
From: Benedict, Michael @ 2007-09-10 18:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000e01c7f177$05ab1990$3a0d10ac@Radstone.Local>
Ilya Lipovsky wrote:
> Yes, I am uncertain. If it isn't a major headache, I think
> you can try the
> newest version (I think it's 2.6.1) and see if you get some
> resolution.=20
<snip>
> Please do share the outcome!!
>=20
> -Ilya
No luck with 2.6.1:
~ $ /lib/libc.so.6
GNU C Library stable release version 2.6.1, by Roland McGrath et al.
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.1.1.
Compiled on a Linux 2.6.12 system on 2007-09-10.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
~ $ ./bar
unimportant waiting for mutex
important waiting for mutex
main unlocking mutex
unimportant got mutex!
important got mutex!
I will continue investigating and follow up on this thread if I come
across anything.
-Michael
^ permalink raw reply
* Need confirmation on MP8349 configuration problem
From: Grant Likely @ 2007-09-10 18:28 UTC (permalink / raw)
To: Timur Tabi, linuxppc-embedded
Hey Timur,
As we talked about on IRC, I'm having problems getting the BDI-2000 to
configure the MPC8349 when CFG_RESET_SOURCE is set to a hard coded
config (Like 100 or 111).
Can you please confirm what I'm seeing on one of your boards?
Steps to reproduce:
1. Set BDI config to override default RCW and initialize FLASH/RAM
2. Power up board and verify that BDI can read DDR and FLASH (using md commands)
3. Power down and remove jumpers A, B & C.
4. Power up and read DDR/FLASH again. At this point I get '# SAP:
read access failed' from the BDI-2000.
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Which 2.6 kernel for MPC5200
From: Grant Likely @ 2007-09-10 18:20 UTC (permalink / raw)
To: Babarovic Ivica; +Cc: linuxppc-embedded
In-Reply-To: <46E57A9D.2020506@asist.si>
On 9/10/07, Babarovic Ivica <ivica.babarovic@asist.si> wrote:
> Hi!
>
> What kernel should I get/pull for MPC5200 clone board.
> I've been away from coding on mpc5200 for quite some time now.
> I've read some archives from ML.
> Git repo on Sylvain Munauts url:
> http://gitbits.246tNt.com/gitbits/linux-2.6-mpc52xx.gitpage
> isn't working. Nothing on http://*git*.secretlab.ca/cgi-bin/*gitweb*.cgi
> <http://git.secretlab.ca/cgi-bin/gitweb.cgi> to.
>
> I've pulled the sources from kernel.org git server.
> git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> linux-2.6-mpc52xx
My 52xx git tree became way out of date, so I dropped it from the
server. Best bet is to use mainline which gives your everything
except the drivers that use the bestcomm DMA engine (like Ethernet).
Then you need to apply the bestcomm patches. You can get them here:
http://www.246tnt.com/mpc52xx/dev_full/
Have fun,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: 2.6.23-rc4-mm1 -- powerpc per_cpu__cpu_sibling_map compile failure
From: Andy Whitcroft @ 2007-09-10 17:43 UTC (permalink / raw)
To: Andrew Morton; +Cc: mel, linuxppc-dev, linux-kernel
In-Reply-To: <20070831215822.26e1432b.akpm@linux-foundation.org>
Am seeing the following compile error on all of my powerpc platforms:
CC kernel/sched.o
kernel/sched.c: In function `cpu_to_phys_group':
kernel/sched.c:5937: error: `per_cpu__cpu_sibling_map' undeclared (first use in this function)
kernel/sched.c:5937: error: (Each undeclared identifier is reported only once
kernel/sched.c:5937: error: for each function it appears in.)
kernel/sched.c:5937: warning: type defaults to `int' in declaration of `type name'
kernel/sched.c:5937: error: invalid type argument of `unary *'
kernel/sched.c: In function `build_sched_domains':
kernel/sched.c:6172: error: `per_cpu__cpu_sibling_map' undeclared (first use in this function)
kernel/sched.c:6172: warning: type defaults to `int' in declaration of `type name'
kernel/sched.c:6172: error: invalid type argument of `unary *'
kernel/sched.c:6183: warning: type defaults to `int' in declaration of `type name'
kernel/sched.c:6183: error: invalid type argument of `unary *'
make[1]: *** [kernel/sched.o] Error 1
make: *** [kernel] Error 2
-apw
^ permalink raw reply
* Which 2.6 kernel for MPC5200
From: Babarovic Ivica @ 2007-09-10 17:10 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
What kernel should I get/pull for MPC5200 clone board.
I've been away from coding on mpc5200 for quite some time now.
I've read some archives from ML.
Git repo on Sylvain Munauts url:
http://gitbits.246tNt.com/gitbits/linux-2.6-mpc52xx.gitpage
isn't working. Nothing on http://*git*.secretlab.ca/cgi-bin/*gitweb*.cgi
<http://git.secretlab.ca/cgi-bin/gitweb.cgi> to.
I've pulled the sources from kernel.org git server.
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
linux-2.6-mpc52xx
How recent are these sources?
Regards,
I.
^ permalink raw reply
* SPI driver?
From: Hesam Kohanteb @ 2007-09-10 16:16 UTC (permalink / raw)
To: linuxppc-embedded
We need a Linux based SPI driver for MPC885. Do you know where can I
possibly find the code.
Regards. --Hesam
--
Hesam Yehuda Kohanteb
(Netra Systems & Networking),
M/S USCA12-216 4120 Network Circle
Santa Clara, CA 95054
(W) 408-276-7329 X17329, Fax 408-276-4552
^ permalink raw reply
* Re: [PATCH 08/10] bootwrapper: Add a firmware-independent "raw" target.
From: Milton Miller @ 2007-09-10 16:09 UTC (permalink / raw)
To: Scott Wood; +Cc: ppcdev, David Gibson
In-Reply-To: <20070910142513.GB21670@ld0162-tx32.am.freescale.net>
On Sep 10, 2007, at 9:25 AM, Scott Wood wrote:
>>>> +static inline void disable_irq(void)
>>>> +{
>>>> + int dummy;
>>>> + asm volatile("mfmsr %0; rlwinm %0, %0, 0, ~(1<<15); mtmsr
>>>> %0"
>>>> :
>>>> + "=r" (dummy) : : "memory");
>>>> +}
>>
>> This will fail (mtmsr illegal instruction) on 64 bit processors that
>> do
>> not implement the bridge facility (POWER4, 5, 6, PPC970, ...)
>
> Ouch... And given the One wrapper.a To Rule Them All mandate, we can't
> ifdef it here, but instead must make separate platform files. :-P
Rather than a seperate c file, I think this should go in your
_zimage_start, renaming fixed-head.S.
milton
^ permalink raw reply
* Re: [PATCH 08/10] bootwrapper: Add a firmware-independent "raw" target.
From: Milton Miller @ 2007-09-10 16:01 UTC (permalink / raw)
To: Scott Wood; +Cc: ppcdev, David Gibson
In-Reply-To: <20070910143006.GD21670@ld0162-tx32.am.freescale.net>
On Sep 10, 2007, at 9:30 AM, Scott Wood wrote:
> On Mon, Sep 10, 2007 at 09:25:13AM -0500, Scott Wood wrote:
>>> (5) space below load to decompress vmlinux (no vmlinux_alloc to
>>> fallback to malloc)
>>> (6) all space above load address available to hold malloc region
>>> (7) for console output (or input) from wrapper, on most cpus, some
>>> magic setup
>>
>> For #5, I really need to get around to implementing setting the load
>> address at build-time based on the size of vmlinux...
>
> Actually, this isn't needed for raw images -- you can just load them
> wherever you want (and thus yes, it should be documented). cuboot
> needs
> it, though.
Yea, raw doesn't really care about the linked address.
>>> It's on my short list to rediff and repost those anyways.
>>
>> Where can I find the existing patches?
The last rediff is patchwork id 12168-12181 posted Jul 11. They get
context rejects in the Makefile and ops.h, and I plan to change the
property name from boot-file in patch 12. Also, I need to make the
search for rmo_end be based on device_type "memory", looking for the
extent starting at 0.
milton
^ permalink raw reply
* Re: [POWERPC] pasemi: Move pasemi_idle_init() to late_initcall()
From: Olof Johansson @ 2007-09-10 16:00 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070910154443.GK32388@localdomain>
On Mon, Sep 10, 2007 at 10:44:43AM -0500, Nathan Lynch wrote:
> Olof Johansson wrote:
> > commit 6a30bd1e2160e921a8fb051b472dfaf068f4f386
> > Author: Olof Johansson <olof@lixom.net>
> > Date: Tue Sep 4 21:53:30 2007 -0500
> >
> > [POWERPC] pasemi: Move pasemi_idle_init() to late_initcall()
> >
> > Move pasemi_idle_init() to be a late_initcall instead of being called from
> > setup_arch(). This way the cpufreq driver has a chance to initialize and
> > save away the boot time astate before we go to idle for the first time.
>
> The patch looks fine, but while I was reviewing this I noticed that
> the pasemi cpufreq code is bool in Kconfig, but it has stuff like
> module_init() etc in it. It's not hurting anything, but it did
> temporarily make me wonder "what happens if the cpufreq driver is
> modular"?
Good point. I actually kept it from being modular for the very reason
that it's needed in the idle loop to restore the cpu frequency when
coming out of power savings modes.
The whole idle/cpufreq dependencies should be overhauled at some point,
to avoid this, or at least allow the cpufreq driver to be a module
(and make idle default to spin when it's not loaded).
-Olof
^ permalink raw reply
* Re: [POWERPC] pasemi: Move pasemi_idle_init() to late_initcall()
From: Nathan Lynch @ 2007-09-10 15:44 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070905020945.GF25900@lixom.net>
Olof Johansson wrote:
> commit 6a30bd1e2160e921a8fb051b472dfaf068f4f386
> Author: Olof Johansson <olof@lixom.net>
> Date: Tue Sep 4 21:53:30 2007 -0500
>
> [POWERPC] pasemi: Move pasemi_idle_init() to late_initcall()
>
> Move pasemi_idle_init() to be a late_initcall instead of being called from
> setup_arch(). This way the cpufreq driver has a chance to initialize and
> save away the boot time astate before we go to idle for the first time.
The patch looks fine, but while I was reviewing this I noticed that
the pasemi cpufreq code is bool in Kconfig, but it has stuff like
module_init() etc in it. It's not hurting anything, but it did
temporarily make me wonder "what happens if the cpufreq driver is
modular"?
^ permalink raw reply
* Re: [PATCH 08/10] bootwrapper: Add a firmware-independent "raw" target.
From: Scott Wood @ 2007-09-10 14:30 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev, David Gibson
In-Reply-To: <20070910142513.GB21670@ld0162-tx32.am.freescale.net>
On Mon, Sep 10, 2007 at 09:25:13AM -0500, Scott Wood wrote:
> > (5) space below load to decompress vmlinux (no vmlinux_alloc to
> > fallback to malloc)
> > (6) all space above load address available to hold malloc region
> > (7) for console output (or input) from wrapper, on most cpus, some
> > magic setup
>
> For #5, I really need to get around to implementing setting the load
> address at build-time based on the size of vmlinux...
Actually, this isn't needed for raw images -- you can just load them
wherever you want (and thus yes, it should be documented). cuboot needs
it, though.
-Scott
^ permalink raw reply
* Re: [PATCH 08/10] bootwrapper: Add a firmware-independent "raw" target.
From: Scott Wood @ 2007-09-10 14:25 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev, David Gibson
In-Reply-To: <d16e868937a1f77cbf080754f5742ad9@bga.com>
On Sun, Sep 09, 2007 at 06:29:11PM -0500, Milton Miller wrote:
> >>diff --git a/arch/powerpc/boot/io.h b/arch/powerpc/boot/io.h
> >>index ccaedae..ec57ec9 100644
> >>--- a/arch/powerpc/boot/io.h
> >>+++ b/arch/powerpc/boot/io.h
> >>@@ -99,4 +99,11 @@ static inline void barrier(void)
> >> asm volatile("" : : : "memory");
> >> }
> >>
> >>+static inline void disable_irq(void)
> >>+{
> >>+ int dummy;
> >>+ asm volatile("mfmsr %0; rlwinm %0, %0, 0, ~(1<<15); mtmsr %0"
> >>:
> >>+ "=r" (dummy) : : "memory");
> >>+}
>
> This will fail (mtmsr illegal instruction) on 64 bit processors that do
> not implement the bridge facility (POWER4, 5, 6, PPC970, ...)
Ouch... And given the One wrapper.a To Rule Them All mandate, we can't
ifdef it here, but instead must make separate platform files. :-P
> >>+ timebase_period_ns = 1000000000 / timebase;
> >>+ simple_alloc_init(_end, memsize64 - (unsigned long)_end, 32,
> >>64);
> >>+ ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
> >>
>
> only 64 malloc slots?
That was copied from other platforms; it should probably be higher.
> So the labels are linked against to find the memory size to allocate
> all above the load address to malloc ...
>
> We can eliminate the need for the labels by calling simple_alloc_init
> twice: the first time on a small bss region, read the properties, then
> call it again with the full memory, and then call ft_init again. That
> is the trick I used in the kexec series. When dtlib merges, we can
> read the tree without malloc and avoid the extra dance.
OK.
> >>+ serial_console_init();
>
> I'm not sure I consider serial_console firemware independent: our
> wrapper IO macros simply do normal loads and stores, and rely on
> firmware to setup either tlbs, virtural mappings, or other to make the
> IO cache inhibited ...
The intent wasn't to run without firmware (that's require memory
initialization and other fun stuff that isn't here, and certainly isn't
generic), but to run without caring what the firmware is. It's assumed
that whatever firmware is there has initialized the serial port to meet
the needs of whatever serial port the device tree points at.
> yea, i realize it doesn't have to find a console, and it all works
> without it. But this is why I pulled the call from my kexec patches.
That option is available, by not specifying linux,stdout-path at all.
> Just to clarify: this should go in the Kconfig help:
> This platform requires
> (1) device tree fully filled out, including memory size and timebase
> frequency
> (2) (currently) labels
> (3) firmware that jumps to start of image (this is like old kernels)
> (4) after its in ram (we must have writable data/bss)
> (5) space below load to decompress vmlinux (no vmlinux_alloc to
> fallback to malloc)
> (6) all space above load address available to hold malloc region
> (7) for console output (or input) from wrapper, on most cpus, some
> magic setup
For #5, I really need to get around to implementing setting the load
address at build-time based on the size of vmlinux...
> >>+if [ -n "$binary" ]; then
> >>+ mv "$ofile" "$ofile".elf
> >>+ ${CROSS}objcopy -O binary "$ofile".elf "$ofile"
> >>+fi
>
> I'm not sure how putting a binary flag test here will help other
> platforms. Even those that want a .elf left behind, if they need ohter
> processing they will done the move already. I'd say just make this
> part of the platform case just above, although I could accept it being
> moved ahead of that case.
Well, it's also used by planetcore platforms...
> Actually, looking at the current case, treeboot, cuboot, and ps3 all
> (could) start with this rename and objcopy, so lets put it above the
> final platform fixup case, and update those platforms to use this
> feature (adjusting the calls to nm, dd, gzip, etc accordingly).
...but moving it earlier and letting other platforms use the result in
this way would be better, yes.
> Bottom line: This looks like a very simple platform, but it has hidden
> assumptions in its environment (mtmsr, laod in the middle of memory,
> others?) and takes the wrapper script in directions i'd rather it not
> go. I'd like you to look at my kexec platform series, and see if
> reusing some of that code would give us a more robust "raw" image.
> (even if you don't need the detached kernel, initramfs parsing, and
> detached initrd; I was thinking more like memranges and the
> vmlinuz_alloc. The policy about not using memory to end can be
> relaxed, and find_end_of_ram made to search memory). It's on my short
> list to rediff and repost those anyways.
Where can I find the existing patches?
-Scott
^ permalink raw reply
* Re: random panic and freezes on mpc8349 itx
From: Nicolas Schichan @ 2007-09-10 13:48 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BAF8B1E0BB28024A90895E746A3B610D1C2BDF@twx-exch01.twacs.local>
On Friday 07 September 2007 23:16:35 Benedict, Michael wrote:
> What version of U-boot are you using?
Until recently I was using the u-boot-1.2.0 available on the
ftp://ftp.denx.de/pub/u-boot/ apparently there since january 2007.
I now use the git tree of today, and everything seems to work fine. I dit not
notice any freeze or random panic. "stress --cpu 256" is running on the board
and after 10 minutes it is still alive.
Thank you for the hint :)
Regards,
--
Nicolas Schichan
^ permalink raw reply
* Re: [RFC/PATCH 1/2] Basic generic time/clocksource code for PowerPC
From: Gabriel Paubert @ 2007-09-10 9:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18147.49943.182399.64990@cargo.ozlabs.ibm.com>
On Sun, Sep 09, 2007 at 07:55:35PM +1000, Paul Mackerras wrote:
> Gabriel Paubert writes:
>
> > The solution now used by i386/x86-64/sparc64 is
> > CONFIG_GENERIC_CMOS_UPDATE. Maybe powerpc should be switched
> > to use something similar, but the generic code has some
>
> Yes. I'll turn on CONFIG_GENERIC_CMOS_UPDATE. Do you think it needs
> to be a config option that can be turned on and off in the kernel
> config, or should it just be always on as on x86[-64]?
I believe that it can be turned on systematically. But
I only have 32 bit, non HV machines (basically 603e, 750,
and 74xx processors).
>
> > problems (it assumes that you have to set the clock
> > on a half-second, which is not the case of the RTC on
> > my boards to start with).
>
> Let's get the generic code fixed to do what we need then. Care to
> send a patch?
I'm unsure on how to implement it in a way acceptable
upstream, the problem is that the following lines:
if (abs(xtime.tv_nsec - (NSEC_PER_SEC / 2)) <= tick_nsec / 2)
fail = update_persistent_clock(now);
next.tv_nsec = (NSEC_PER_SEC / 2) - now.tv_nsec;
are hardwired to half a second. Can it be transformed into
a per arch static inline function defined in asm-${arch}?
There is also a possible problem in notify_cmos_timer, I believe
that the logic is wrong and the condition is reversed and should
be "if (!no_sync_cmos_clock)".
Otherwise the clock update timer will never be started! This boolean
really should be called disable_persistent_clock_updates or something
similar.
I'm really wondering how much testing all this code has had. The
more I look at the timekeeping code changes in the last months,
the less I understand them.
Gabriel
^ permalink raw reply
* Interrupt-problem mpc5200
From: S. Fricke @ 2007-09-10 9:03 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]
Hello all.
What are the steps to configure an MPC500B-Board to react on an IRQ (2)?
I have written a test-driver with this code-snippets, but the prozessor
hangs when loading the driver.
my __init-function looks like:
static int __init mod_init( void )
{
volatile static struct mpc52xx_intr __iomem *intr;
u32 intr_ctrl;
// ...
printk( "intmod.ko: interrupt init ");
if (request_irq(MPC52xx_IRQ2, intmod_isr, IRQF_SHARED , "intmod",
INTMOD_IRQ_BOARD) == -EBUSY)
printk("KO\n");
else
printk("OK\n");
intr = ioremap(MPC52xx_MBAR+MPC52xx_INTR_OFFSET, MPC52xx_INTR_SIZE);
// read - modify - write
intr_ctrl = in_be32(&intr->ctrl);
intr_ctrl &= 0xfff3ffff;
intr_ctrl |= 0x00080200;
out_be32(&intr->ctrl, intr_ctrl); // ERROR!
if(intr) iounmap(intr);
// ...
}
On the Line, marked with "ERROR!" the prozessor hangs and the kernel drops
out.
TIA: Silvio
Mit freundlichen Gruessen
Silvio Fricke
--
-- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
Diplom-Informatiker (FH)
Linux-Entwicklung JABBER: fricke@jabber.org
----------------------------------------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* linux can't read pci bus configure space of a scsi controller (lsi53c1020)
From: yuan tian @ 2007-09-10 7:03 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]
Hi,
I have a board based on ocotea(ppc440gx) as reference.
Without PCI bus,the linux system can run successfully on
the board. when the PCI bus is used,the system hung.
on the pci bus ,there are two pci devices.one is a scsi
controller,the other is a fpga. i found the system hung at
indirect_pci.c.
indirect_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
int len, u32 *val)
{
struct pci_controller *hose = bus->sysdata;
volatile void __iomem *cfg_data;
u8 cfg_type = 0;
if (ppc_md.pci_exclude_device)
if (ppc_md.pci_exclude_device(bus->number, devfn))
return PCIBIOS_DEVICE_NOT_FOUND;
if (hose->set_cfg_type)
if (bus->number != hose->first_busno)
cfg_type = 1;
PCI_CFG_OUT(hose->cfg_addr,
(0x80000000 | ((bus->number - hose->bus_offset) << 16)
| (devfn << 8) | ((offset & 0xfc) | cfg_type)));
/*
* Note: the caller has already checked that offset is
* suitably aligned and that len is 1, 2 or 4.
*/
cfg_data = hose->cfg_data + (offset & 3);
switch (len) {
case 1:
*val = in_8(cfg_data);
break;
case 2:
*val = in_le16(cfg_data);
break;
default:
*val = in_le32(cfg_data);
break;
}
return PCIBIOS_SUCCESSFUL;
}
the system run to *val = in_le32(cfg_data) , the board hung.
when i get out scsi controller,the system can run successfully.
the vxworks run successfully on the board with these two pci devices.
so i think the board have no problem on the hardware.
my question is :
why can linux read fpga pci configure space and can't read scsi
controller(lsi 53c1020)?
any help will be appreciated!
Regards,
--
Tom
[-- Attachment #2: Type: text/html, Size: 2224 bytes --]
^ permalink raw reply
* Re: [PATCH 08/10] bootwrapper: Add a firmware-independent "raw" target.
From: Milton Miller @ 2007-09-09 23:29 UTC (permalink / raw)
To: Scott Wood; +Cc: ppcdev, David Gibson
In-Reply-To: <20070907005803.GJ26079@localhost.localdomain>
On Fri Sep 7 10:58:03 EST 2007, David Gibson wrote:
>> 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.
Plus, its not quite as generic as you think.
>> Signed-off-by: Scott Wood <scottwood at freescale.com>
>> ---
>> arch/powerpc/Kconfig | 12 +++++++++++
>> arch/powerpc/boot/Makefile | 4 ++-
>> arch/powerpc/boot/fixed-head.S | 4 +++
>> arch/powerpc/boot/io.h | 7 ++++++
>> arch/powerpc/boot/raw-platform.c | 41
>> ++++++++++++++++++++++++++++++++++++++
>> arch/powerpc/boot/wrapper | 21 ++++++++++++++----
>> 6 files changed, 83 insertions(+), 6 deletions(-)
>> create mode 100644 arch/powerpc/boot/fixed-head.S
>> create mode 100644 arch/powerpc/boot/raw-platform.c
>>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index 00099ef..251d0c3 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -358,6 +358,18 @@ config WANT_DEVICE_TREE
>> bool
>> default n
>>
>> +config BUILD_RAW_IMAGE
>> + bool "Build firmware-independent image"
>> + select WANT_DEVICE_TREE
>> + help
>> + If this is enabled, a firmware independent "raw" image will
>> be
>> + built, as zImage.raw. This requires a completely filled-in
>> + device tree, with the following labels:
>> +
>> + mem_size_cells: on /#address-cells
>> + memsize: on the size portion of /memory/reg
>> + timebase: on the boot CPU's timebase property
>>
You need these labels on (in) the data not on the property struct ...
(one can label either today, but only properties in the not to distant
past).
>> +
>> config DEVICE_TREE
>> string "Static device tree source file"
>> depends on WANT_DEVICE_TREE
>> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
>> index 02f0fe0..2a6a4c6 100644
>> --- a/arch/powerpc/boot/Makefile
>> +++ b/arch/powerpc/boot/Makefile
>> @@ -48,7 +48,8 @@ src-wlib := string.S crt0.S stdio.c main.c
>> flatdevtree.c flatdevtree_misc.c \
>> cpm-serial.c stdlib.c planetcore.c
>> src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
>> cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
>> - ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c
>> cuboot-8xx.c cuboot-pq2.c
>> + ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c \
>> + cuboot-8xx.c cuboot-pq2.c fixed-head.S raw-platform.c
>> src-boot := $(src-wlib) $(src-plat) empty.c
>>
>> src-boot := $(addprefix $(obj)/, $(src-boot))
>> @@ -146,6 +147,7 @@ image-$(CONFIG_PPC_83xx) +=
>> cuImage.83xx
>> image-$(CONFIG_PPC_85xx) += cuImage.85xx
>> image-$(CONFIG_EBONY) += treeImage.ebony
>> cuImage.ebony
>> image-$(CONFIG_BAMBOO) += treeImage.bamboo
>> +image-$(CONFIG_BUILD_RAW_IMAGE) += zImage.raw
>> endif
>>
>> # For 32-bit powermacs, build the COFF and miboot images
>> diff --git a/arch/powerpc/boot/fixed-head.S
>> b/arch/powerpc/boot/fixed-head.S
>> new file mode 100644
>> index 0000000..8e14cd9
>> --- /dev/null
>> +++ b/arch/powerpc/boot/fixed-head.S
>> @@ -0,0 +1,4 @@
>> + .text
>> + .global _zimage_start
>> +_zimage_start:
>> + b _zimage_start_lib
>> diff --git a/arch/powerpc/boot/io.h b/arch/powerpc/boot/io.h
>> index ccaedae..ec57ec9 100644
>> --- a/arch/powerpc/boot/io.h
>> +++ b/arch/powerpc/boot/io.h
>> @@ -99,4 +99,11 @@ static inline void barrier(void)
>> asm volatile("" : : : "memory");
>> }
>>
>> +static inline void disable_irq(void)
>> +{
>> + int dummy;
>> + asm volatile("mfmsr %0; rlwinm %0, %0, 0, ~(1<<15); mtmsr %0"
>> :
>> + "=r" (dummy) : : "memory");
>> +}
This will fail (mtmsr illegal instruction) on 64 bit processors that do
not implement the bridge facility (POWER4, 5, 6, PPC970, ...)
>> +
>> #endif /* _IO_H */
>> diff --git a/arch/powerpc/boot/raw-platform.c
>> b/arch/powerpc/boot/raw-platform.c
>> new file mode 100644
>> index 0000000..b9caeee
>> --- /dev/null
>> +++ b/arch/powerpc/boot/raw-platform.c
>> @@ -0,0 +1,41 @@
>> +/*
>> + * The "raw" platform -- for booting from a complete dtb without
>> + * any fixups.
>> + *
>> + * Author: Scott Wood <scottwood at freescale.com>
>> + *
>> + * Copyright (c) 2007 Freescale Semiconductor, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> modify it
>> + * under the terms of the GNU General Public License version 2 as
>> published
>> + * by the Free Software Foundation.
>> + */
>> +
>> +#include "ops.h"
>> +#include "types.h"
>> +#include "io.h"
>> +
>> +BSS_STACK(4096);
>> +
>> +/* These are labels in the device tree. */
>> +extern u32 memsize[2], timebase, mem_size_cells;
>> +
>> +void platform_init(unsigned long r3, unsigned long r4, unsigned long
>> r5,
>> + unsigned long r6, unsigned long r7)
>> +{
>> + u64 memsize64 = memsize[0];
>> +
>> + if (mem_size_cells == 2) {
>> + memsize64 <<= 32;
>> + memsize64 |= memsize[1];
>> + }
>> +
>> + if (sizeof(void *) == 4 && memsize64 >= 0x100000000ULL)
>> + memsize64 = 0xffffffff;
>> +
>> + disable_irq();
see above, only works on some processors.
>> + timebase_period_ns = 1000000000 / timebase;
>> + simple_alloc_init(_end, memsize64 - (unsigned long)_end, 32,
>> 64);
>> + ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
>>
only 64 malloc slots?
So the labels are linked against to find the memory size to allocate
all above the load address to malloc ...
We can eliminate the need for the labels by calling simple_alloc_init
twice: the first time on a small bss region, read the properties, then
call it again with the full memory, and then call ft_init again. That
is the trick I used in the kexec series. When dtlib merges, we can
read the tree without malloc and avoid the extra dance.
>> + serial_console_init();
I'm not sure I consider serial_console firemware independent: our
wrapper IO macros simply do normal loads and stores, and rely on
firmware to setup either tlbs, virtural mappings, or other to make the
IO cache inhibited ...
yea, i realize it doesn't have to find a console, and it all works
without it. But this is why I pulled the call from my kexec patches.
>> +}
Just to clarify: this should go in the Kconfig help:
This platform requires
(1) device tree fully filled out, including memory size and timebase
frequency
(2) (currently) labels
(3) firmware that jumps to start of image (this is like old kernels)
(4) after its in ram (we must have writable data/bss)
(5) space below load to decompress vmlinux (no vmlinux_alloc to
fallback to malloc)
(6) all space above load address available to hold malloc region
(7) for console output (or input) from wrapper, on most cpus, some
magic setup
Except for this supplying the dt instead of looking for one passed in
r3, it is very similar to my kexec platform. That platform has a few
more features, however
(1) support for SMP with 64 bit kernel (6xx would require small patch)
(2) support for finding available space above or below, via memregions
(3) support for avoiding memroy blocks (rtas, etc)
I think that code could be tweaked to be used by both.
>> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
>> index 65f6854..a6501e9 100755
>> --- a/arch/powerpc/boot/wrapper
>> +++ b/arch/powerpc/boot/wrapper
>> @@ -30,6 +30,7 @@ dtb=
>> dts=
>> cacheit=
>> gzip=.gz
>> +binary=
>>
>> # cross-compilation prefix
>> CROSS=
>> @@ -107,10 +108,11 @@ while [ "$#" -gt 0 ]; do
>> done
>>
>> if [ -n "$dts" ]; then
>> - if [ -z "$dtb" ]; then
>> - dtb="$platform.dtb"
>> - fi
>> - dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts" || exit 1
>> + dtasm="$object/$platform.dtb.S"
>> + dto="$object/$platform.dtb.o"
>> + echo '.section .kernel:dtb,"a"' > "$dtasm"
>> + dtc -O asm -b 0 -V 16 "$dts" >> "$dtasm" || exit 1
>> + ${CROSS}gcc "$dtasm" -c -o "$dto"
>> fi
If we are going to start calling gcc from the wrapper (even if it is on
a .S) ...
and synthesizing the input file from pieces ...
and not checking if you need -m32 or if its disallowed ...
not sanitizing preprocessor include environment ...
and if one passes dts and dtb you changed behavior ...
If we need the asm label, I'd rather add the call to dtc->asm and
asm->.o in the makefile and link it into the platform, maybe using a
raw-* rule like cuboot and treeboot, or just hardcode the output to be
dtb.o (since we only have one dts). If we want it to show up in the
.dtb instead of .text then we can use objcopy to rename the section or
do your cat of echo and dtc in a gen_ rule).
... but I think minimal alloc/peek at tree/full alloc is the way to go
for now.
>>
>> if [ -z "$kernel" ]; then
>> @@ -153,6 +155,10 @@ ps3)
>> ksection=.kernel:vmlinux.bin
>> isection=.kernel:initrd
>> ;;
>> +raw)
>> + platformo="$object/fixed-head.o $object/raw-platform.o"
>> + binary=y
>> + ;;
>> esac
>>
>> vmz="$tmpdir/`basename \"$kernel\"`.$ext"
>> @@ -216,7 +222,7 @@ fi
>>
>> if [ "$platform" != "miboot" ]; then
>> ${CROSS}ld -m elf32ppc -T $lds -o "$ofile" \
>> - $platformo $tmp $object/wrapper.a
>> + $platformo $tmp $dto $object/wrapper.a
>> rm $tmp
>> fi
>>
>> @@ -295,3 +301,8 @@ ps3)
>> gzip --force -9 --stdout "$ofile.bin" > "$object/otheros.bld"
>> ;;
>> esac
>> +
>> +if [ -n "$binary" ]; then
>> + mv "$ofile" "$ofile".elf
>> + ${CROSS}objcopy -O binary "$ofile".elf "$ofile"
>> +fi
I'm not sure how putting a binary flag test here will help other
platforms. Even those that want a .elf left behind, if they need ohter
processing they will done the move already. I'd say just make this
part of the platform case just above, although I could accept it being
moved ahead of that case.
Actually, looking at the current case, treeboot, cuboot, and ps3 all
(could) start with this rename and objcopy, so lets put it above the
final platform fixup case, and update those platforms to use this
feature (adjusting the calls to nm, dd, gzip, etc accordingly).
Bottom line: This looks like a very simple platform, but it has hidden
assumptions in its environment (mtmsr, laod in the middle of memory,
others?) and takes the wrapper script in directions i'd rather it not
go. I'd like you to look at my kexec platform series, and see if
reusing some of that code would give us a more robust "raw" image.
(even if you don't need the detached kernel, initramfs parsing, and
detached initrd; I was thinking more like memranges and the
vmlinuz_alloc. The policy about not using memory to end can be
relaxed, and find_end_of_ram made to search memory). It's on my short
list to rediff and repost those anyways.
milton
^ permalink raw reply
* Re: [PATCH 2/5] Add Freescale DMA engine driver maintainer.
From: David Gibson @ 2007-09-10 3:27 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus
In-Reply-To: <11891624382764-git-send-email-wei.zhang@freescale.com>
On Fri, Sep 07, 2007 at 06:53:53PM +0800, Zhang Wei wrote:
> This patch adds Freescale DMA engine driver maintainer.
This is meaningless without the actual driver, so it shouldn't be a
separate patch. Fold it into the patch that actually adds the driver
support.
--
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