* Re: [PATCH] Fix interrupt distribution in ppc970
From: Milton Miller @ 2007-06-15 16:35 UTC (permalink / raw)
To: mohan; +Cc: ppcdev, Paul Mackerras, kexec
In-Reply-To: <20070612145157.GA7562@in.ibm.com>
On Jun 12, 2007, at 9:51 AM, Mohan Kumar M wrote:
>
> Attached patch uses cpumask_scnprintf function.
> In some of the PPC970 based systems, interrupt would be distributed to
> offline cpus also even when booted with "maxcpus=1". So check whether
> cpu online map and cpu present map are equal or not. If they are equal
> default_distrib_server is used as interrupt server otherwise boot cpu
> (default_server) used as interrupt server.
>
> In addition to this, if an interrupt is assigned to a specific cpu (ie
> smp affinity) and if that cpu is not online, the earlier code used to
> return the default_distrib_server as interrupt server. This patch
> introduces an additional paramter to the get_irq function ie
> strict_check, based on this parameter, if the cpu is not online either
> default_distrib_server or -1 is returned.
>
> Cc: Milton Miller <miltonm@bga.com>,
> Michael Ellerman <michael@ellerman.id.au>
> Signed-off-by: Mohan Kumar M <mohan@in.ibm.com>
>
Acked-by: Milton Miller <miltonm@bga.com>
^ permalink raw reply
* Re: for-2.6.23 branch in powerpc.git created
From: Dave Jiang @ 2007-06-15 16:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18034.6787.951861.623265@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> The patches I put in are listed below. If you have a patch that
> should go in but isn't listed, remind me about it.
Paul, can these go in? Thx!
1 patch to setup marvell EDAC platform devices
http://patchwork.ozlabs.org/linuxppc/patch?q=Dave%20Jiang&id=11275
1 patch for publishing 85xx soc dts entries as of_device so EDAC can use them
http://patchwork.ozlabs.org/linuxppc/patch?q=Dave%20Jiang&id=11276
2 patches for BOOKE watchdog handler
http://patchwork.ozlabs.org/linuxppc/patch?q=Dave%20Jiang&id=11392
http://patchwork.ozlabs.org/linuxppc/patch?q=Dave%20Jiang&id=11393
--
------------------------------------------------------
Dave Jiang
Software Engineer
MontaVista Software, Inc.
http://www.mvista.com
------------------------------------------------------
^ permalink raw reply
* Re: for-2.6.23 branch in powerpc.git created
From: Nathan Lynch @ 2007-06-15 17:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18034.6787.951861.623265@cargo.ozlabs.ibm.com>
Hi Paul-
Paul Mackerras wrote:
>
> If you have a patch that should go in but isn't listed, remind me
> about it.
Please consider picking up "remove spinlock from struct
cpu_purr_data" for 2.6.23:
http://patchwork.ozlabs.org/linuxppc/patch?id=11291
^ permalink raw reply
* Re: for-2.6.23 branch in powerpc.git created
From: Guennadi Liakhovetski @ 2007-06-15 17:47 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18034.6787.951861.623265@cargo.ozlabs.ibm.com>
On Fri, 15 Jun 2007, Paul Mackerras wrote:
> I have created a for-2.6.23 branch in the powerpc.git repository
> (git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git)
> where I have started queueing up patches to go in once the 2.6.23
> merge window opens. For now at least it's the same as the master
> branch.
>
> The patches I put in are listed below. If you have a patch that
> should go in but isn't listed, remind me about it.
How about this one:
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036319.html
Don't think linking timer.o if CONFIG_RTC_CLASS is defined presents a
problem now, but it will later, when platforms appear, that wish to use PM
and use generic rtc.
These two i2c patches:
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037327.html
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037328.html
also would be nice to get in, although, they only make sense with an ack
from Scott Wood and another patch from him, as explained in links above...
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: [patch 4/6] ps3: Disk Storage Driver
From: Geert Uytterhoeven @ 2007-06-15 18:05 UTC (permalink / raw)
To: Alan Cox
Cc: Jens Axboe, James E.J. Bottomley, linux-scsi, linux-kernel,
linuxppc-dev, Paul Mackerras, David Woodhouse
In-Reply-To: <20070615171545.316dfac7@the-village.bc.nu>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1046 bytes --]
On Fri, 15 Jun 2007, Alan Cox wrote:
> > > Any particular reason why this is done as a separate block device driver
> > > rather than as SCSI?
> >
> > Because no new fake SCSI drivers are accepted anymore.
>
> Where did drivers/ata come from ;)
I was told that one got in just before the moratorium on fake SCSI.
> How about making it a fake ata driver if James is being fussy 8)
I don't think Christoph likes fake ATA drivers neither ;-)
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: for-2.6.23 branch in powerpc.git created
From: Scott Wood @ 2007-06-15 18:12 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0706151915580.5979@poirot.grange>
Guennadi Liakhovetski wrote:
> These two i2c patches:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037327.html
This looks OK as an interim measure, though at some point I'd like to
get around to letting both devices and drivers specify a list of match
names.
> http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037328.html
I'd leave out the device_type, and the "rtc" in "rtc-r5c372" is
redundant if that's all the r5c372 chip does, but other than that it
looks good.
> also would be nice to get in, although, they only make sense with an ack
> from Scott Wood and another patch from him, as explained in links above...
I assume you mean "Call of_register_i2c_devices() for fsl-i2c"
(http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036333.html)?
-Scott
^ permalink raw reply
* Re: for-2.6.23 branch in powerpc.git created
From: Guennadi Liakhovetski @ 2007-06-15 18:18 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4672D694.5060701@freescale.com>
On Fri, 15 Jun 2007, Scott Wood wrote:
> Guennadi Liakhovetski wrote:
> > These two i2c patches:
> >
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037327.html
>
> This looks OK as an interim measure, though at some point I'd like to get
> around to letting both devices and drivers specify a list of match names.
>
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037328.html
>
> I'd leave out the device_type, and the "rtc" in "rtc-r5c372" is redundant if
No, it is not redundant, it has to match rs5c372_driver.driver.name.
> that's all the r5c372 chip does, but other than that it looks good.
>
> > also would be nice to get in, although, they only make sense with an ack
> > from Scott Wood and another patch from him, as explained in links above...
>
> I assume you mean "Call of_register_i2c_devices() for fsl-i2c"
> (http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036333.html)?
Yes.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: PowerPC boot wrapper and seperate initrd images
From: Milton Miller @ 2007-06-15 18:25 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppcdev
In-Reply-To: <ff25e225fd11b8189ea922a33b71f164@kernel.crashing.org>
On Fri Jun 15 20:54:10 EST 2007, Segher Boessenkool wrote:
>> Matt Sealey wrote:
>>
>> However what I
>> am looking to do is have it so that a first stage bootloader (Forth
>> script or binary like Yaboot) loads in the initrd into memory via the
>> client interface or whatever other method, then just fires up the
>> kernel.
>
> Reasonable.
I had the same idea years ago but never took the time to write it;
using my own kernels I just built zImage.initrd although my apple cube
limits the size of that.
In other words, please post your script when you have it working.
>> This is simply because.. yaboot doesn't work here yet (Pegasos/Efika).
>
> Yeah yaboot is a royal pain.
yep doesn't trust OF and has its own assumptions ...
>> This is causing problems with distributions as they like to ship a
>> kernel and seperate initrd - and expect a boot loader like BootX or
>> Yaboot or Quick (pick one) to do all it's heavy lifting.
>>
>> However we CAN get the data into the right place, with a tiny Forth
>> script, and there are some standard properties to reference it.
>>
>> The linux,initrd-size and linux,initrd-start properties would
>> be set in the device tree by this tiny forth boot loader.
>>
>> That means of.c needs to pick them up, and main.c needs not to trash
>> them.
>
> Yes.
already does.
>> What I am asking, then, if all that information is correct, is if it
>> would be acceptable in any terms to add this code to the boot wrapper;
>> in platform_init, it would get the properties out of the tree and
>> assign them in the loader_info structure (maybe only if the r3 and
>> r4 values are invalid).
I've already written a routine to pick this up as part of my kexec
zImage. I needed it because I am extracting the kernel elf from a
gzipped cpio using initramfs. I split it into a separate file last
night, I'll post shortly.
One suability is before 2.6.22, the properties had to be 64 bits, but
now they can be 32 or 64 bits. The wrapper only stores 32 bit
numbers.
>>
>> Then in main.c perhaps NOT set those values if they are already in
>> the device tree.. but I am not sure if any manipulation of the
>> values is going on. I assume they're absolute, real-mode addresses
>> and not being weirdly relocated or as an offset to the kernel
>> (I didn't look to hard).
The property contains a physical address.
Older yaboot passed an assumed virtual address in r3 (__va() isn't
available outside the kernel) so prom_check_initrd checks
is_kernel_address(); this means OF can't use r3 to store the initrd
above 3GB or whatever maybe 2GB.
Both the code in boot/main.c and the code in kernel/prom_init.c will
not overwrite the properties if r4 (size) is 0.
If you set the properties today it will just work. If you claim the
memory then of.c malloc won't overwrite it.
However, calling this routine will tell the boot wrapper about it,
where it prep_initrd() can memmove() it out of the way of 0 to kernel
mem size so it will not be overwritten, although this will result in
two copies being claimed.
>>
>> Is it an insane or stupid idea, that everyone hates and thinks
>> we should just fix our broken firmware, or do you think it would
>> come in handy? I'm considering it's a 20-line patch that wouldn't
>> harm anyone..
>>
>> Any comments?
Another consideration is selecting your initrd load address. prom_init
will start will flatten the device tree starting at the larger of the
loaded (offset in memory) kernel _end + 0x4000 or the end of the initrd
(if it knows about it) rounded up to a page boundary and will not
consider memory above 768MB. It must be able to claim space for the
flattened tree at that address.
>
> It's not a bad plan, but show us the code so we can see
> if it turns out nasty or not :-)
>
> Segher
milton
^ permalink raw reply
* Re: [patch 00/13] CPU selection Kconfig cleanup, take 3
From: Kim Phillips @ 2007-06-15 18:28 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus, arnd, sfr
In-Reply-To: <B4E893D5-A61E-4A91-B31C-AF9B7C0B116D@kernel.crashing.org>
On Thu, 14 Jun 2007 08:33:19 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jun 13, 2007, at 8:46 PM, Paul Mackerras wrote:
>
> > Most of this series of patches touch 8xxx or 5xxx stuff in one way or
> > another, so I'll leave it to Kumar to make the decision about them.
> > I'll put in 1/13.
>
> Arnd,
>
> I'm a little hesitant to move the embedded ppc's over to
> multiplatform quite yet. One feature I wanted was in Kconfig a way
> to enforce the selection of at least one choice, as well as being
> able to optimize things since we only had one choice selected.
>
> See the following thread for discussion I had with Sam & Roman on the
> subject:
>
> http://marc.info/?t=117156757000002&r=1&w=2
>
FWIW, this patchseries tests ok on 83xx, and I didn't have a problem
selecting at least one choice ;)
Kim
^ permalink raw reply
* [PATCH] numa: enforce iommu-off memory address limit
From: Milton Miller @ 2007-06-15 17:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
Don't short circuit the lmb_end_of_DRAM if iommu_is_off.
If linux,iommu-off is in /chosen (because iommu=off was on the command
line), we limit the memory when adding it to the lmbs and page tables,
but not when numa parses the device tree for numa affinity. When we
free bootmem, we then try to use these pages without mapping them or
allocating supporting data structures resulting in bad_page and/or data
storage interrupts.
Signed-off-by: Milton Miller <miltonm@bga.com>
---
Paul, I think this can wait for 2.6.23 although its small enough
if you want to send it for 2.6.22.
Index: kernel/arch/powerpc/mm/numa.c
===================================================================
--- kernel.orig/arch/powerpc/mm/numa.c 2007-06-15 01:10:19.000000000 -0500
+++ kernel/arch/powerpc/mm/numa.c 2007-06-15 01:41:32.000000000 -0500
@@ -21,6 +21,7 @@
#include <asm/lmb.h>
#include <asm/system.h>
#include <asm/smp.h>
+#include <asm/iommu.h>
static int numa_enabled = 1;
@@ -286,7 +287,7 @@ static unsigned long __init numa_enforce
* having memory holes below the limit.
*/
- if (! memory_limit)
+ if (!memory_limit && !iommu_is_off)
return size;
if (start + size <= lmb_end_of_DRAM())
^ permalink raw reply
* [PATCH] boot: find initrd location from device-tree
From: Milton Miller @ 2007-06-15 17:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, david
Some platforms have a boot agent that can create or modifiy
properties in the device-tree and load images into memory.
Provide a helper to set the loader-info used by prep_initrd().
The code supports the 8-byte properties required by kernels
before 2.6.22 and 4-byte properties generated by prep_initrd()
and current 32 bit kernels (new kernels will read either size).
The types.h header now includes libgcc limits.h for UINT_MAX.
Signed-off-by: Milton Miller <miltonm@bga.com>
---
The file name dtscan reflects the possibility that simiar functions
like the rmo_top might be added to the file.
This is the first patch in a series of 18 that udpates and rediffs
of my kexec zImage support against 2.6.22-rc4. Unfornately I left
the series file behind but I wanted to get this first patch sent
for Matt to use.
Index: kernel/arch/powerpc/boot/dtscan.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ kernel/arch/powerpc/boot/dtscan.c 2007-06-15 03:45:16.000000000 -0500
@@ -0,0 +1,86 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright (C) 2007 IBM Corporation.
+ *
+ * Authors: Milton Miller <miltonm@bga.com>
+ *
+ */
+
+#include "ops.h"
+#include "stdio.h"
+
+/**
+ * dt_find_initrd - set loader initrd location based on existing properties
+ *
+ * finds the linux,initrd-start and linux,initrd-end properties in
+ * the /chosen node and sets the loader initrd fields accordingly.
+ *
+ * Use this if your loader sets the properties to allow other code to
+ * relocate the tree and/or cause r3 and r4 to be set on true OF
+ * platforms.
+ */
+
+void dt_find_initrd(void)
+{
+ int rc;
+ unsigned long long initrd_start, initrd_end;
+ void *devp;
+ static const char start_prop[] = "linux,initrd-start";
+ static const char end_prop[] = "linux,initrd-end";
+
+ devp = finddevice("/chosen");
+ if (! devp) {
+ return;
+ }
+
+ /* The properties had to be 8 bytes until 2.6.22 */
+ rc = getprop(devp, start_prop, &initrd_start, sizeof(initrd_start));
+ if (rc < 0)
+ return;
+ if (rc == sizeof(unsigned long)) {
+ unsigned long tmp;
+ memcpy(&tmp, &initrd_start, rc);
+ initrd_start = tmp;
+ } else if (rc != sizeof(initrd_start)) {
+ printf("unexpected length of %s in /chosen!\n\r", start_prop);
+ return;
+ }
+
+ rc = getprop(devp, end_prop, &initrd_end, sizeof(initrd_end));
+ if (rc < 0) {
+ printf("chosen has %s but no %s!\n\r", start_prop, end_prop);
+ return;
+ }
+ if (rc == sizeof(unsigned long)) {
+ unsigned long tmp;
+ memcpy(&tmp, &initrd_end, rc);
+ initrd_end = tmp;
+ } else if (rc != sizeof(initrd_end)) {
+ printf("unexpected length of %s in /chosen!\n\r", end_prop);
+ return;
+ }
+
+ if (!initrd_start)
+ return;
+
+ /* if the initrd is above 4G, its untouchable in 32 bit mode */
+ if (initrd_end <= UINT_MAX && initrd_start < initrd_end) {
+ loader_info.initrd_addr = initrd_start;
+ loader_info.initrd_size = initrd_end - initrd_start;
+ } else {
+ printf("ignoring loader supplied initrd parameters\n");
+ }
+}
Index: kernel/arch/powerpc/boot/ops.h
===================================================================
--- kernel.orig/arch/powerpc/boot/ops.h 2007-06-15 03:43:36.000000000 -0500
+++ kernel/arch/powerpc/boot/ops.h 2007-06-15 03:44:34.000000000 -0500
@@ -151,6 +151,7 @@ static inline void *find_node_by_devtype
return find_node_by_prop_value_str(prev, "device_type", type);
}
+void dt_find_initrd(void);
void dt_fixup_memory(u64 start, u64 size);
void dt_fixup_cpu_clocks(u32 cpufreq, u32 tbfreq, u32 busfreq);
void dt_fixup_clock(const char *path, u32 freq);
Index: kernel/arch/powerpc/boot/Makefile
===================================================================
--- kernel.orig/arch/powerpc/boot/Makefile 2007-06-15 03:43:36.000000000 -0500
+++ kernel/arch/powerpc/boot/Makefile 2007-06-15 03:44:34.000000000 -0500
@@ -43,7 +43,7 @@ $(addprefix $(obj)/,$(zlib) gunzip_util.
src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
ns16550.c serial.c simple_alloc.c div64.S util.S \
- gunzip_util.c elf_util.c $(zlib) devtree.c \
+ gunzip_util.c elf_util.c $(zlib) devtree.c dtscan.c \
44x.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c
src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c
Index: kernel/arch/powerpc/boot/types.h
===================================================================
--- kernel.orig/arch/powerpc/boot/types.h 2007-06-15 03:36:21.000000000 -0500
+++ kernel/arch/powerpc/boot/types.h 2007-06-15 03:44:34.000000000 -0500
@@ -1,6 +1,9 @@
#ifndef _TYPES_H_
#define _TYPES_H_
+#define _LIBC_LIMITS_H_ /* don't recurse to system's headers */
+#include <limits.h> /* MAX_UINT, etc */
+
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
typedef unsigned char u8;
^ permalink raw reply
* Re: for-2.6.23 branch in powerpc.git created
From: Milton Miller @ 2007-06-15 19:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppcdev
In-Reply-To: <18034.6787.951861.623265@cargo.ozlabs.ibm.com>
Paul,
Please add "kexec: send slaves to new kernel earlier" It should
apply offset about 40 lines.
http://patchwork.ozlabs.org/linuxppc/patch?id=10399
I've updated my kexec zImage support to 2.6.22-rc4 and made some
fixes, so I'll resend those. The Makefile diffs always break, so
I might wait until you merge some of the other pending boot patches.
milton
^ permalink raw reply
* [PATCH] [POWERPC] Add cputable entry for PowerPC 440SPe Rev. B
From: Roland Dreier @ 2007-06-15 19:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18034.6787.951861.623265@cargo.ozlabs.ibm.com>
When adding the cputable entry for 440SPe Rev. B, we also need to
adjust the existing entries for 440SP Rev. A and 440SPe Rev. B so that
they look more bits of the PVR. The 440SPe Rev. B has PVR 53421891,
which would match the current 440SP Rev. A pattern of 53xxx891. To
distinguish between 440SP and 440SPe, we need to use the first three
digits of the PVR, which are respectively 532 and 534.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
---
Here's a patch I've had for a while -- I think it may as well go in,
although I haven't had a chance to put much work into moving
Yucca/Katmai 440SPe support to arch/powerpc, so I'll probably miss
2.6.23 for the rest of it.
arch/powerpc/kernel/cputable.c | 20 +++-
arch/ppc/syslib/ppc440spe_pcie.c | 219 +++++++++++++++++++++++++++-----------
2 files changed, 172 insertions(+), 67 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index b2b5d66..157e6e3 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1178,8 +1178,8 @@ static struct cpu_spec cpu_specs[] = {
.platform = "ppc440",
},
{ /* 440SP Rev. A */
- .pvr_mask = 0xff000fff,
- .pvr_value = 0x53000891,
+ .pvr_mask = 0xfff00fff,
+ .pvr_value = 0x53200891,
.cpu_name = "440SP Rev. A",
.cpu_features = CPU_FTRS_44X,
.cpu_user_features = COMMON_USER_BOOKE,
@@ -1188,9 +1188,19 @@ static struct cpu_spec cpu_specs[] = {
.platform = "ppc440",
},
{ /* 440SPe Rev. A */
- .pvr_mask = 0xff000fff,
- .pvr_value = 0x53000890,
- .cpu_name = "440SPe Rev. A",
+ .pvr_mask = 0xfff00fff,
+ .pvr_value = 0x53400890,
+ .cpu_name = "440SPe Rev. A",
+ .cpu_features = CPU_FTRS_44X,
+ .cpu_user_features = COMMON_USER_BOOKE,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .platform = "ppc440",
+ },
+ { /* 440SPe Rev. B */
+ .pvr_mask = 0xfff00fff,
+ .pvr_value = 0x53400891,
+ .cpu_name = "440SPe Rev. B",
.cpu_features = CPU_FTRS_44X,
.cpu_user_features = COMMON_USER_BOOKE,
.icache_bsize = 32,
^ permalink raw reply related
* [PATCH] boot: find initrd location from device-tree
From: Milton Miller @ 2007-06-15 18:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, david
Some platforms have a boot agent that can create or modifiy
properties in the device-tree and load images into memory.
Provide a helper to set the loader-info used by prep_initrd().
The code supports the 8-byte properties required by kernels
before 2.6.22 and 4-byte properties generated by prep_initrd()
and current 32 bit kernels (new kernels will read either size).
The types.h header now includes libgcc limits.h for UINT_MAX.
Signed-off-by: Milton Miller <miltonm@bga.com>
---
Please reply to this message with the correct email account.
The file name dtscan reflects the possibility that simiar functions
like the rmo_top might be added to the file.
This is the first patch in a series of 18 that udpates and rediffs
of my kexec zImage support against 2.6.22-rc4. Unfornately I left
the series file behind but I wanted to get this first patch sent
for Matt to use.
Index: kernel/arch/powerpc/boot/dtscan.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ kernel/arch/powerpc/boot/dtscan.c 2007-06-15 03:45:16.000000000 -0500
@@ -0,0 +1,86 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright (C) 2007 IBM Corporation.
+ *
+ * Authors: Milton Miller <miltonm@bga.com>
+ *
+ */
+
+#include "ops.h"
+#include "stdio.h"
+
+/**
+ * dt_find_initrd - set loader initrd location based on existing properties
+ *
+ * finds the linux,initrd-start and linux,initrd-end properties in
+ * the /chosen node and sets the loader initrd fields accordingly.
+ *
+ * Use this if your loader sets the properties to allow other code to
+ * relocate the tree and/or cause r3 and r4 to be set on true OF
+ * platforms.
+ */
+
+void dt_find_initrd(void)
+{
+ int rc;
+ unsigned long long initrd_start, initrd_end;
+ void *devp;
+ static const char start_prop[] = "linux,initrd-start";
+ static const char end_prop[] = "linux,initrd-end";
+
+ devp = finddevice("/chosen");
+ if (! devp) {
+ return;
+ }
+
+ /* The properties had to be 8 bytes until 2.6.22 */
+ rc = getprop(devp, start_prop, &initrd_start, sizeof(initrd_start));
+ if (rc < 0)
+ return;
+ if (rc == sizeof(unsigned long)) {
+ unsigned long tmp;
+ memcpy(&tmp, &initrd_start, rc);
+ initrd_start = tmp;
+ } else if (rc != sizeof(initrd_start)) {
+ printf("unexpected length of %s in /chosen!\n\r", start_prop);
+ return;
+ }
+
+ rc = getprop(devp, end_prop, &initrd_end, sizeof(initrd_end));
+ if (rc < 0) {
+ printf("chosen has %s but no %s!\n\r", start_prop, end_prop);
+ return;
+ }
+ if (rc == sizeof(unsigned long)) {
+ unsigned long tmp;
+ memcpy(&tmp, &initrd_end, rc);
+ initrd_end = tmp;
+ } else if (rc != sizeof(initrd_end)) {
+ printf("unexpected length of %s in /chosen!\n\r", end_prop);
+ return;
+ }
+
+ if (!initrd_start)
+ return;
+
+ /* if the initrd is above 4G, its untouchable in 32 bit mode */
+ if (initrd_end <= UINT_MAX && initrd_start < initrd_end) {
+ loader_info.initrd_addr = initrd_start;
+ loader_info.initrd_size = initrd_end - initrd_start;
+ } else {
+ printf("ignoring loader supplied initrd parameters\n");
+ }
+}
Index: kernel/arch/powerpc/boot/ops.h
===================================================================
--- kernel.orig/arch/powerpc/boot/ops.h 2007-06-15 03:43:36.000000000 -0500
+++ kernel/arch/powerpc/boot/ops.h 2007-06-15 03:44:34.000000000 -0500
@@ -151,6 +151,7 @@ static inline void *find_node_by_devtype
return find_node_by_prop_value_str(prev, "device_type", type);
}
+void dt_find_initrd(void);
void dt_fixup_memory(u64 start, u64 size);
void dt_fixup_cpu_clocks(u32 cpufreq, u32 tbfreq, u32 busfreq);
void dt_fixup_clock(const char *path, u32 freq);
Index: kernel/arch/powerpc/boot/Makefile
===================================================================
--- kernel.orig/arch/powerpc/boot/Makefile 2007-06-15 03:43:36.000000000 -0500
+++ kernel/arch/powerpc/boot/Makefile 2007-06-15 03:44:34.000000000 -0500
@@ -43,7 +43,7 @@ $(addprefix $(obj)/,$(zlib) gunzip_util.
src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
ns16550.c serial.c simple_alloc.c div64.S util.S \
- gunzip_util.c elf_util.c $(zlib) devtree.c \
+ gunzip_util.c elf_util.c $(zlib) devtree.c dtscan.c \
44x.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c
src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c
Index: kernel/arch/powerpc/boot/types.h
===================================================================
--- kernel.orig/arch/powerpc/boot/types.h 2007-06-15 03:36:21.000000000 -0500
+++ kernel/arch/powerpc/boot/types.h 2007-06-15 03:44:34.000000000 -0500
@@ -1,6 +1,9 @@
#ifndef _TYPES_H_
#define _TYPES_H_
+#define _LIBC_LIMITS_H_ /* don't recurse to system's headers */
+#include <limits.h> /* MAX_UINT, etc */
+
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
typedef unsigned char u8;
^ permalink raw reply
* Re: [PATCH] boot: find initrd location from device-tree
From: Scott Wood @ 2007-06-15 19:55 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, paulus, david
In-Reply-To: <111819314606b8b45671.846930886.miltonm@bga.com>
Milton Miller wrote:
> The file name dtscan reflects the possibility that simiar functions
> like the rmo_top might be added to the file.
Aren't these kind of things what devtree.c is for?
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] Add cputable entry for PowerPC 440SPe Rev. B
From: Olof Johansson @ 2007-06-15 20:44 UTC (permalink / raw)
To: Roland Dreier; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <adawsy5ggcf.fsf@cisco.com>
Hi,
On Fri, Jun 15, 2007 at 12:36:32PM -0700, Roland Dreier wrote:
> When adding the cputable entry for 440SPe Rev. B, we also need to
> adjust the existing entries for 440SP Rev. A and 440SPe Rev. B so that
> they look more bits of the PVR. The 440SPe Rev. B has PVR 53421891,
> which would match the current 440SP Rev. A pattern of 53xxx891. To
> distinguish between 440SP and 440SPe, we need to use the first three
> digits of the PVR, which are respectively 532 and 534.
I can see why you need to distinguish between 440SP and SPe, but do you
really need separate cputable entries for rev A and B? Revisions are
normally reported separately and the cputable entries look identical?
-Olof
^ permalink raw reply
* Re: [patch 4/6] ps3: Disk Storage Driver
From: David Miller @ 2007-06-15 21:17 UTC (permalink / raw)
To: Geert.Uytterhoeven
Cc: axboe, James.Bottomley, linux-scsi, linux-kernel, linuxppc-dev,
paulus, dwmw2
In-Reply-To: <Pine.LNX.4.62.0706151642010.8248@pademelon.sonytel.be>
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Date: Fri, 15 Jun 2007 16:43:05 +0200 (CEST)
> On Fri, 15 Jun 2007, David Woodhouse wrote:
> > On Fri, 2007-06-15 at 13:39 +0200, Geert Uytterhoeven wrote:
> > > Add a Disk Storage Driver for the PS3:
> > > - Implemented as a block device driver with a dynamic major
> > > - Disk names (and partitions) are of the format ps3d%c(%u)
> > > - Uses software scatter-gather with a 64 KiB bounce buffer as the hypervisor
> > > doesn't support scatter-gather
> >
> > Any particular reason why this is done as a separate block device driver
> > rather than as SCSI?
>
> Because no new fake SCSI drivers are accepted anymore.
I'm strongly divided on this issue as I'm about to hit the same exact
thing for Sun Logical Domains on sparc64 Niagara systems.
In fact the interface I get to use allows SCSI commands to be sent
pass-through to the device, even though the basic virtual I/O API is
purely block I/O based.
It's senseless to make people build new major/minor numbers for
all these new quirky storage drivers. People have to add support
for the new major number to installers and all kinds of other
tools.
If the SCSI guys were smart, there would be a totally generic helper
layer that allows anyone to hook into the SCSI layer as a virtual SCSI
disk provider in like 10 lines of code. :-)
^ permalink raw reply
* Re: [patch 4/6] ps3: Disk Storage Driver
From: David Miller @ 2007-06-15 21:19 UTC (permalink / raw)
To: alan
Cc: axboe, James.Bottomley, linux-scsi, linux-kernel, linuxppc-dev,
paulus, Geert.Uytterhoeven, dwmw2
In-Reply-To: <20070615171545.316dfac7@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Fri, 15 Jun 2007 17:15:45 +0100
> > > Any particular reason why this is done as a separate block device driver
> > > rather than as SCSI?
> >
> > Because no new fake SCSI drivers are accepted anymore.
>
> Where did drivers/ata come from ;)
>
> How about making it a fake ata driver if James is being fussy 8)
That sounds like a good idea for my virtual I/O case on
Niagara too actually :-)
Another quirk I have to deal with is that under LDOMs you
can export full disks and also just slices. So I'll have
to get down into the partition machinery to support that
somehow.
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: MPC7450 L2 HW cache flush feature utilization
From: Mark A. Greer @ 2007-06-15 21:20 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev list
In-Reply-To: <6c416bf9f79a648fc82f64619aca86de@kernel.crashing.org>
On Fri, Jun 15, 2007 at 10:14:24AM +0200, Segher Boessenkool wrote:
> > I've double checked this. All processors considered 7450 in the kernel
> > are covered by MPC7450 RISC Microprocessor Family Reference Manual
> > where hardware cache flushing procedure is described.
>
> Nice. Now all that remains to be done is for the patch to
> be tested on actual hardware for at least a few of those
> other CPUs. Any volunteers?
I just booted & played around on a prpmc2800e (7447A, 512MB) with
this patch and it seemed to work fine.
I *may* have some old sandpoint 745x modules that still work but
I'll have to get the sandpoint working in arch/powerpc again.
I'll try to get to that in a week or so.
Mark
^ permalink raw reply
* Re: for-2.6.23 branch in powerpc.git created
From: Scott Wood @ 2007-06-15 21:22 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0706152016150.5979@poirot.grange>
Guennadi Liakhovetski wrote:
> On Fri, 15 Jun 2007, Scott Wood wrote:
>>I'd leave out the device_type, and the "rtc" in "rtc-r5c372" is redundant if
>
> No, it is not redundant, it has to match rs5c372_driver.driver.name.
Sorry, I meant if you had control over what the driver calls itself...
I'd misread the name, and thus my grep failed, so I assumed it was a new
driver.
-Scott
^ permalink raw reply
* Re: [patch 4/6] ps3: Disk Storage Driver
From: Jeff Garzik @ 2007-06-15 21:28 UTC (permalink / raw)
To: David Miller, Geert.Uytterhoeven
Cc: axboe, James.Bottomley, linux-scsi, linux-kernel, linuxppc-dev,
paulus, dwmw2
In-Reply-To: <20070615.141720.112626963.davem@davemloft.net>
David Miller wrote:
> From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
>> Because no new fake SCSI drivers are accepted anymore.
If you can access the firmware/hypervisor code, have that provide SCSI.
Then the Linux driver piece is easy, obvious and flexible SCSI, and is
not "fake."
> If the SCSI guys were smart, there would be a totally generic helper
> layer that allows anyone to hook into the SCSI layer as a virtual SCSI
> disk provider in like 10 lines of code. :-)
The SCSI target code gives you the capability to do that (the SCSI
transport part, the virtual storage part is easy from there).
Jeff
^ permalink raw reply
* Re: [patch 4/6] ps3: Disk Storage Driver
From: David Miller @ 2007-06-15 21:37 UTC (permalink / raw)
To: jeff
Cc: axboe, James.Bottomley, linux-scsi, linux-kernel, linuxppc-dev,
paulus, Geert.Uytterhoeven, dwmw2
In-Reply-To: <4673047F.30808@garzik.org>
From: Jeff Garzik <jeff@garzik.org>
Date: Fri, 15 Jun 2007 17:28:31 -0400
> David Miller wrote:
> > If the SCSI guys were smart, there would be a totally generic helper
> > layer that allows anyone to hook into the SCSI layer as a virtual SCSI
> > disk provider in like 10 lines of code. :-)
>
> The SCSI target code gives you the capability to do that (the SCSI
> transport part, the virtual storage part is easy from there).
I don't get to control the server side in my case, I'm a client
talking to something with a pre-determined interface.
^ permalink raw reply
* Re: [patch 4/6] ps3: Disk Storage Driver
From: Jeff Garzik @ 2007-06-15 21:50 UTC (permalink / raw)
To: David Miller
Cc: axboe, James.Bottomley, linux-scsi, linux-kernel, linuxppc-dev,
paulus, Geert.Uytterhoeven, dwmw2
In-Reply-To: <20070615.141720.112626963.davem@davemloft.net>
David Miller wrote:
> It's senseless to make people build new major/minor numbers for
> all these new quirky storage drivers. People have to add support
> for the new major number to installers and all kinds of other
> tools.
FWIW that's why libata followed the path it did: faking SCSI required
the least amount of code for the maximal amount of existing storage
driver and platform installer support.
Well, that and the fact that ATAPI is really SCSI, but that's offtopic
for this thread. :)
Jeff
^ permalink raw reply
* Re: [patch 4/6] ps3: Disk Storage Driver
From: David Miller @ 2007-06-15 21:55 UTC (permalink / raw)
To: jeff
Cc: axboe, James.Bottomley, linux-scsi, linux-kernel, linuxppc-dev,
paulus, Geert.Uytterhoeven, dwmw2
In-Reply-To: <467309BA.8000009@garzik.org>
From: Jeff Garzik <jeff@garzik.org>
Date: Fri, 15 Jun 2007 17:50:50 -0400
> FWIW that's why libata followed the path it did: faking SCSI required
> the least amount of code for the maximal amount of existing storage
> driver and platform installer support.
>
> Well, that and the fact that ATAPI is really SCSI, but that's offtopic
> for this thread. :)
Yep I absolutely understand that, and for my case as well it's
nearly always SCSI underneath that's why you can send SCSI
commands passthru to the virtual disk server if you like.
^ permalink raw reply
* [patch 02/33] PS3: Rename IPI symbols
From: Geoff Levand @ 2007-06-15 21:17 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070615204749.629571012@am.sony.com>
Rename the PS3 static symbol virqs to ps3_ipi_virqs to aid in
debugging.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/platforms/ps3/smp.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/arch/powerpc/platforms/ps3/smp.c
+++ b/arch/powerpc/platforms/ps3/smp.c
@@ -39,11 +39,11 @@ static irqreturn_t ipi_function_handler(
}
/**
- * virqs - a per cpu array of virqs for ipi use
+ * ps3_ipi_virqs - a per cpu array of virqs for ipi use
*/
#define MSG_COUNT 4
-static DEFINE_PER_CPU(unsigned int, virqs[MSG_COUNT]);
+static DEFINE_PER_CPU(unsigned int, ps3_ipi_virqs[MSG_COUNT]);
static const char *names[MSG_COUNT] = {
"ipi call",
@@ -62,7 +62,7 @@ static void do_message_pass(int target,
return;
}
- virq = per_cpu(virqs, target)[msg];
+ virq = per_cpu(ps3_ipi_virqs, target)[msg];
result = ps3_send_event_locally(virq);
if (result)
@@ -94,13 +94,13 @@ static int ps3_smp_probe(void)
static void __init ps3_smp_setup_cpu(int cpu)
{
int result;
- unsigned int *virqs = per_cpu(virqs, cpu);
+ unsigned int *virqs = per_cpu(ps3_ipi_virqs, cpu);
int i;
DBG(" -> %s:%d: (%d)\n", __func__, __LINE__, cpu);
/*
- * Check assumptions on virqs[] indexing. If this
+ * Check assumptions on ps3_ipi_virqs[] indexing. If this
* check fails, then a different mapping of PPC_MSG_
* to index needs to be setup.
*/
@@ -132,7 +132,7 @@ static void __init ps3_smp_setup_cpu(int
void ps3_smp_cleanup_cpu(int cpu)
{
- unsigned int *virqs = per_cpu(virqs, cpu);
+ unsigned int *virqs = per_cpu(ps3_ipi_virqs, cpu);
int i;
DBG(" -> %s:%d: (%d)\n", __func__, __LINE__, cpu);
--
^ 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