Re: mmio_nvram.c users ?
On Tue, May 25, 2010 at 05:43:59PM +1000, Benjamin Herrenschmidt wrote: Anybody aware of anything other than Cell using that driver ? I'd like to make it a platform driver instead of having something that pokes at anything that has a device_type set to nvram (which is gross and bogus). But I need to know what platforms to fixup... The PowerStation is also using it. Adrian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Endian/__BYTE_ORDER question
On Thu, Feb 11, 2010 at 05:17:37PM +0100, Joakim Tjernlund wrote: I am getting confused about on how to test for Endian in the kernel code. In user space one uses #if __BYTE_ORDER == __LITTLE_ENDIAN or #if __BYTE_ORDER == __BIG_ENDIAN I can see lots of kernel headers using this test too, but it doesn't seem to be an arch specific file #defining __BYTE_ORDER. Instead I find files like: arch/alpha/math-emu/sfp-util.h arch/powerpc/include/asm/sfp-machine.h arch/s390/include/asm/sfp-util.h arch/sh/math-emu/sfp-util.h How is this supposed to work? I have no idea how it is actually done in the kernel code... but gcc defines it: gcc -dM -E -x c - '' | grep ENDIAN #define __BIG_ENDIAN__ 1 #define _BIG_ENDIAN 1 Adrian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] Fix RTAS watchdog driver temperature read functionality
I forgot about this patch. Can this still be merged?
On Thu, Mar 26, 2009 at 01:05:42PM +0100, Adrian Reber wrote:
Using the RTAS watchdog driver to read out the temperature crashes
on a PXCAB:
Unable to handle kernel paging request for data at address 0xfe347b50
Faulting instruction address: 0xc001af64
Oops: Kernel access of bad area, sig: 11 [#1]
The wrong usage of (void *)__pa(temperature) in rtas_call() is
removed by using the function rtas_get_sensor() which does the
right thing.
Signed-off-by: Adrian Reber adr...@lisas.de
---
v2: use rtas_get_sensor(); typo fixed
---
drivers/watchdog/wdrtas.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/watchdog/wdrtas.c b/drivers/watchdog/wdrtas.c
index 5d3b1a8..a9f00dc 100644
--- a/drivers/watchdog/wdrtas.c
+++ b/drivers/watchdog/wdrtas.c
@@ -214,16 +214,14 @@ static void wdrtas_timer_keepalive(void)
*/
static int wdrtas_get_temperature(void)
{
- long result;
+ int result;
int temperature = 0;
- result = rtas_call(wdrtas_token_get_sensor_state, 2, 2,
-(void *)__pa(temperature),
-WDRTAS_THERMAL_SENSOR, 0);
+ result = rtas_get_sensor(WDRTAS_THERMAL_SENSOR, 0, temperature);
if (result 0)
printk(KERN_WARNING wdrtas: reading the thermal sensor
-faild: %li\n, result);
+failed: %i\n, result);
else
temperature = ((temperature * 9) / 5) + 32; /* fahrenheit */
--
1.5.6.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] Fix RTAS watchdog driver temperature read functionality
Using the RTAS watchdog driver to read out the temperature crashes
on a PXCAB:
Unable to handle kernel paging request for data at address 0xfe347b50
Faulting instruction address: 0xc001af64
Oops: Kernel access of bad area, sig: 11 [#1]
The wrong usage of (void *)__pa(temperature) in rtas_call() is
removed by using the function rtas_get_sensor() which does the
right thing.
Signed-off-by: Adrian Reber adr...@lisas.de
---
v2: use rtas_get_sensor(); typo fixed
---
drivers/watchdog/wdrtas.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/watchdog/wdrtas.c b/drivers/watchdog/wdrtas.c
index 5d3b1a8..a9f00dc 100644
--- a/drivers/watchdog/wdrtas.c
+++ b/drivers/watchdog/wdrtas.c
@@ -214,16 +214,14 @@ static void wdrtas_timer_keepalive(void)
*/
static int wdrtas_get_temperature(void)
{
- long result;
+ int result;
int temperature = 0;
- result = rtas_call(wdrtas_token_get_sensor_state, 2, 2,
- (void *)__pa(temperature),
- WDRTAS_THERMAL_SENSOR, 0);
+ result = rtas_get_sensor(WDRTAS_THERMAL_SENSOR, 0, temperature);
if (result 0)
printk(KERN_WARNING wdrtas: reading the thermal sensor
- faild: %li\n, result);
+ failed: %i\n, result);
else
temperature = ((temperature * 9) / 5) + 32; /* fahrenheit */
--
1.5.6.6
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix RTAS watchdog driver temperature read functionality
On Tue, Mar 24, 2009 at 03:27:18PM +1100, Benjamin Herrenschmidt wrote:
On Mon, 2009-03-16 at 13:35 +0100, Adrian Reber wrote:
Using the RTAS watchdog driver to read out the temperature crashes
on a PXCAB:
Unable to handle kernel paging request for data at address 0xfe347b50
Faulting instruction address: 0xc001af64
Oops: Kernel access of bad area, sig: 11 [#1]
This (removing (void *)__pa) fixes it.
Looks correct, but why not use rtas_get_sensor() instead ? (Exported by
arch/powerpc/kernel/rtas.c
Ah, you mean something like?
drivers/watchdog/wdrtas.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/watchdog/wdrtas.c b/drivers/watchdog/wdrtas.c
index 5d3b1a8..af2bbfa 100644
--- a/drivers/watchdog/wdrtas.c
+++ b/drivers/watchdog/wdrtas.c
@@ -214,16 +214,14 @@ static void wdrtas_timer_keepalive(void)
*/
static int wdrtas_get_temperature(void)
{
- long result;
+ int result;
int temperature = 0;
- result = rtas_call(wdrtas_token_get_sensor_state, 2, 2,
- (void *)__pa(temperature),
- WDRTAS_THERMAL_SENSOR, 0);
+ result = rtas_get_sensor(WDRTAS_THERMAL_SENSOR, 0, temperature);
if (result 0)
printk(KERN_WARNING wdrtas: reading the thermal sensor
- faild: %li\n, result);
+ faild: %i\n, result);
else
temperature = ((temperature * 9) / 5) + 32; /* fahrenheit */
Adrian
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/wdrtas: Update wdrtas_get_interval to use rtas_data_buf
On Tue, Mar 24, 2009 at 05:30:41PM +1100, Mark Nelson wrote:
The buffer passed to the ibm,get-system-parameter RTAS call must be
in the RMA. To ensure we pass an address in the RMA use rtas_data_buf
for the actual RTAS call and then copy the result to value. We can't
just make it static because this can be compiled in as a module.
Also add the WDRTAS_SP_SPI_LEN so we don't litter '4' throughout the
function.
Signed-off-by: Mark Nelson ma...@au1.ibm.com
---
Adrian, does this patch cause any problems for your pxcabs?
No, it even helps. I have no tried the watchdog until now, but without the
patch I get:
wdrtas: could not get sp_spi watchdog timeout (0). Continuing
and with the patch it reads the correct value. So only with your patch
it works like it is supposed to. Thanks!
Tested-by: Adrian Reber adr...@lisas.de
Thanks!
Mark
drivers/watchdog/wdrtas.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
Index: upstream/drivers/watchdog/wdrtas.c
===
--- upstream.orig/drivers/watchdog/wdrtas.c
+++ upstream/drivers/watchdog/wdrtas.c
@@ -106,6 +106,8 @@ static int wdrtas_set_interval(int inter
return result;
}
+#define WDRTAS_SP_SPI_LEN 4
+
/**
* wdrtas_get_interval - returns the current watchdog interval
* @fallback_value: value (in seconds) to use, if the RTAS call fails
@@ -119,10 +121,17 @@ static int wdrtas_set_interval(int inter
static int wdrtas_get_interval(int fallback_value)
{
long result;
- char value[4];
+ char value[WDRTAS_SP_SPI_LEN];
+ spin_lock(rtas_data_buf_lock);
+ memset(rtas_data_buf, 0, WDRTAS_SP_SPI_LEN);
result = rtas_call(wdrtas_token_get_sp, 3, 1, NULL,
-WDRTAS_SP_SPI, (void *)__pa(value), 4);
+WDRTAS_SP_SPI, __pa(rtas_data_buf),
+WDRTAS_SP_SPI_LEN);
+
+ memcpy(value, rtas_data_buf, WDRTAS_SP_SPI_LEN);
+ spin_unlock(rtas_data_buf_lock);
+
if (value[0] != 0 || value[1] != 2 || value[3] != 0 || result 0) {
printk(KERN_WARNING wdrtas: could not get sp_spi watchdog
timeout (%li). Continuing\n, result);
Adrian
--
Adrian Reber adr...@lisas.dehttp://lisas.de/~adrian/
There's coffee in that nebula!
-- Capt. Kathryn Janeway, Star Trek: Voyager, The Cloud
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix RTAS watchdog driver temperature read functionality
Using the RTAS watchdog driver to read out the temperature crashes on a PXCAB: Unable to handle kernel paging request for data at address 0xfe347b50 Faulting instruction address: 0xc001af64 Oops: Kernel access of bad area, sig: 11 [#1] This (removing (void *)__pa) fixes it. Signed-off-by: Adrian Reber adr...@lisas.de --- drivers/watchdog/wdrtas.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) Fix for: Unable to handle kernel paging request for data at address 0xfe347b50 Faulting instruction address: 0xc001af64 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=4 NUMA Cell Modules linked in: NIP: c001af64 LR: c001af28 CTR: c0281888 REGS: c000fe3477a0 TRAP: 0300 Not tainted (2.6.29-rc6-11955-g2450cf5) MSR: 90001032 ME,IR,DR CR: 22000422 XER: DAR: fe347b50, DSISR: 4200 TASK = c000fe4886f0[1184] 'a.out' THREAD: c000fe344000 CPU: 1 GPR00: 002a c000fe347a20 c0ab2160 c0007bc0 GPR04: 22000422 c0281888 041e6138 GPR08: 0008 c0b23ce4 0008 fe347b54 GPR12: 82000424 c0b23680 c03b37b0 c0441620 GPR16: c04412e0 c0441130 0e154ec8 c03b4580 GPR20: 100a0370 100a0390 c0b23cc8 GPR24: 0001 0002 fe347b50 0002 GPR28: 0010 c0b23cb0 c0a59588 0002 NIP [c001af64] .rtas_call+0x1ac/0x1f8 LR [c001af28] .rtas_call+0x170/0x1f8 Call Trace: [c000fe347a20] [c001af28] .rtas_call+0x170/0x1f8 (unreliable) [c000fe347ae0] [c02812e8] .wdrtas_get_temperature+0x48/0xa8 [c000fe347b70] [c0281948] .wdrtas_ioctl+0xc0/0x300 [c000fe347c00] [c00f58a4] .vfs_ioctl+0x54/0x138 [c000fe347c90] [c00f5a20] .do_vfs_ioctl+0x98/0x738 [c000fe347d80] [c00f6114] .SyS_ioctl+0x54/0xc8 [c000fe347e30] [c00074b4] syscall_exit+0x0/0x40 Instruction dump: 2fba 419e0034 3939fffe 3944 79290020 39290002 79281764 e93d0070 7d7a5214 7c09502e 394a0004 7faa4000 900bfffc 409effe8 e93d0070 ebe90002 ---[ end trace 084fb7ab3feda750 ]--- diff --git a/drivers/watchdog/wdrtas.c b/drivers/watchdog/wdrtas.c index 5d3b1a8..30ee1f2 100644 --- a/drivers/watchdog/wdrtas.c +++ b/drivers/watchdog/wdrtas.c @@ -218,8 +218,7 @@ static int wdrtas_get_temperature(void) int temperature = 0; result = rtas_call(wdrtas_token_get_sensor_state, 2, 2, - (void *)__pa(temperature), - WDRTAS_THERMAL_SENSOR, 0); + temperature, WDRTAS_THERMAL_SENSOR, 0); if (result 0) printk(KERN_WARNING wdrtas: reading the thermal sensor -- 1.5.6.6 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Add support to access the flash on SLOF based systems
This adds support for a simple character device to access the
flash for SLOF based systems like the PowerStation, QS2x and
PXCAB. In the SLOF git there is a user space program with
which the content of the flash for SLOF based systems can
be displayed and modified. This can be used to add a Linux
image to the flash and then directly boot the kernel from the
flash.
Signed-off-by: Adrian Reber adr...@lisas.de
---
This is based on the mmio NVRAM driver. I am not sure how useful this
is for anybody else but I am posting it anyway, hoping to get some
feedback. Also hoping it can be included at one point.
arch/powerpc/platforms/Kconfig |8 ++
arch/powerpc/sysdev/Makefile |2 +
arch/powerpc/sysdev/slof_flash.c | 174 ++
include/linux/miscdevice.h |1 +
4 files changed, 185 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/slof_flash.c
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 47fe2be..7f436e0 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -301,6 +301,14 @@ config OF_RTC
Uses information from the OF or flattened device tree to instatiate
platform devices for direct mapped RTC chips like the DS1742 or
DS1743.
+config SLOF_FLASH
+ bool SLOF flash device
+ depends on PPC_MAPLE || PPC_IBM_CELL_BLADE
+ default y
+ help
+ Provide a read-only device to read out the flash
+ for SLOF based systems.
+
source arch/powerpc/sysdev/bestcomm/Kconfig
config MPC8xxx_GPIO
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index b33b28a..298485d 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -50,3 +50,5 @@ obj-$(CONFIG_UCODE_PATCH) += micropatch.o
ifeq ($(CONFIG_SUSPEND),y)
obj-$(CONFIG_6xx) += 6xx-suspend.o
endif
+
+obj-$(CONFIG_SLOF_FLASH) += slof_flash.o
diff --git a/arch/powerpc/sysdev/slof_flash.c b/arch/powerpc/sysdev/slof_flash.c
new file mode 100644
index 000..bc94d48
--- /dev/null
+++ b/arch/powerpc/sysdev/slof_flash.c
@@ -0,0 +1,174 @@
+/*
+ * SLOF flash access
+ *
+ * (C) Copyright MATRIX VISION GmbH 2009
+ *
+ * Authors : Adrian Reber adr...@lisas.de
+ *
+ * Based on mmio NVRAM driver
+ *
+ * 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, 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, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+
+#include linux/miscdevice.h
+#include asm/uaccess.h
+#include asm/prom.h
+#include asm/machdep.h
+
+static void __iomem *slof_flash_start;
+static long slof_flash_len;
+static DEFINE_SPINLOCK(slof_flash_lock);
+
+static loff_t slof_flash_llseek(struct file *file, loff_t offset, int origin)
+{
+ switch (origin) {
+ case 1:
+ offset += file-f_pos;
+ break;
+ case 2:
+ offset += slof_flash_len;
+ break;
+ }
+ if (offset 0)
+ return -EINVAL;
+ file-f_pos = offset;
+ return file-f_pos;
+}
+
+
+static ssize_t slof_flash_read(struct file *file, char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ unsigned long flags;
+ char *tmp;
+ int rc;
+
+ if (*ppos = slof_flash_len)
+ return 0;
+ if (*ppos + count slof_flash_len)
+ count = slof_flash_len - *ppos;
+
+ count = min(count, PAGE_SIZE);
+ tmp = kzalloc(count, GFP_KERNEL);
+
+ if (!tmp)
+ return -ENOMEM;
+
+ spin_lock_irqsave(slof_flash_lock, flags);
+
+ memcpy_fromio(tmp, slof_flash_start + *ppos, count);
+
+ spin_unlock_irqrestore(slof_flash_lock, flags);
+
+ rc = count;
+ if (copy_to_user(buf, tmp, count)) {
+ rc = -EFAULT;
+ goto out;
+ }
+
+ *ppos += count;
+out:
+ kfree(tmp);
+ return rc;
+}
+
+const struct file_operations slof_flash_fops = {
+ .owner = THIS_MODULE,
+ .llseek = slof_flash_llseek,
+ .read = slof_flash_read,
+};
+
+static struct miscdevice slof_flash_dev = {
+ SLOF_FLASH_MINOR,
+ slof_flash,
+ slof_flash_fops
+};
+
+
+static int __init slof_flash_init(void)
+{
+ struct device_node *slof_flash;
+ struct device_node *compatible;
+ struct resource r;
+ int rc;
+ unsigned long slof_flash_addr
Re: [PATCH] powerpc: Add support to access the flash on SLOF based systems
On Sat, Jan 10, 2009 at 11:52:56AM -0600, Milton Miller wrote:
On Sun Jan 11 at 02:31:22 EST in 2009, Adrian Reber wrote:
This adds support for a simple character device to access the
flash for SLOF based systems like the PowerStation, QS2x and
PXCAB. In the SLOF git there is a user space program with
which the content of the flash for SLOF based systems can
be displayed and modified. This can be used to add a Linux
image to the flash and then directly boot the kernel from the
flash.
Signed-off-by: Adrian Reber adrian at lisas.de
---
This is based on the mmio NVRAM driver. I am not sure how useful this
is for anybody else but I am posting it anyway, hoping to get some
feedback. Also hoping it can be included at one point.
Normally such drivers are written and mtd drivers.
If slof were not an of implementation I would just say put the right
properties on the node in the device tree, but the kernel should adapt
to real OF. It should be easy to write a driver to hook up a mtd
platform device if this is a direct mapped flash.
The reason why I did not use mtd is that part of the flash is used by
the firmware image and I do not know if that works with mtd, if only a
part of the flash can be used. SLOF does also a CRC check over the
firmware image, so that image must have valid SLOF CRC. The flash is
a direct mapped flash, but the size of the firmware can vary.
+
+static void __iomem *slof_flash_start;
+static long slof_flash_len;
+static DEFINE_SPINLOCK(slof_flash_lock);
+
+
+static ssize_t slof_flash_read(struct file *file, char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ unsigned long flags;
+ char *tmp;
+ int rc;
+
+ spin_lock_irqsave(slof_flash_lock, flags);
+
+ memcpy_fromio(tmp, slof_flash_start + *ppos, count);
+
+ spin_unlock_irqrestore(slof_flash_lock, flags);
+
Why do you need a spinlock? Why does it need to be irq safe?
I must confess I copied that code from the nvram driver and I do not
know if it is necessary.
This decision is also driving the malloc of the temporary buffer, and
you are intentionally returning a short read to userspace.
+
+const struct file_operations slof_flash_fops = {
+ .owner = THIS_MODULE,
+ .llseek = slof_flash_llseek,
+ .read = slof_flash_read,
+};
+
You mentioned userspace reflashing the image, but this driver seems to
be read only access.
This driver is read only. I am writing the new flash image using the
RTAS functionality to update the firmware flash. Using this device I can
use a userspace tool to add a file to the flash. The tool puts the
result on the local filesystem. Then using the normal RTAS flash update
it can be rewritten. That way I can add a kernel (with a ramdisk) to the
flash and then let SLOF boot that kernel. This is especially interesting
for the PXCAB Cell based PCI Express card.
+static struct miscdevice slof_flash_dev = {
+ SLOF_FLASH_MINOR,
+ slof_flash,
+ slof_flash_fops
+};
+
+
+static int __init slof_flash_init(void)
+{
+ struct device_node *slof_flash;
+ struct device_node *compatible;
+ struct resource r;
+ int rc;
+ unsigned long slof_flash_addr;
+ /* SLOF is known to run on systems with following values
+* for the compatible property: */
+ char *compstrs[] = {IBM,Bimini, IBM,JS21, IBM,JS20,
IBM,CBEA };
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(compstrs); i++) {
+ compatible = of_find_compatible_node(NULL, NULL,
compstrs[i]);
+
+ if (compatible)
+ break;
+ }
Can you identify slof from the information in the /openprom node? I
Yes I can identify SLOF from the model property in the /openprom node. I
did not do it because there is almost no code accessing the /openprom
node and therefore I did not read it.
don't think all js20 and 21 use slof, although the IBM provided firmware
may also work with this driver.
There are probably only very few js20/js21 which are using SLOF. I do
not think the original IBM product firmware for those blades mentions
anything about js20/js21 in the compatible node. I do not have access to
such a system but the compatible node usually has some product number,
if I remember it correctly.
I am pretty sure that the original js20/js21 firmware does not have the
flash in the device tree, because RTAS is supposed to be the only valid
way to access the flash.
+
+ /* not a system with a SLOF flash */
+ if (!compatible)
+ return -ENODEV;
+
+ of_node_put(compatible);
+
+ slof_flash = of_find_node_by_type(NULL, flash);
+ if (!slof_flash) {
+ printk(KERN_WARNING SLOF FLASH:
+ no flash node found in device-tree\n);
+ return -ENODEV;
+ }
+ rc = of_address_to_resource(slof_flash, 0, r
Re: starting with 2.6.26-rc1 cell_defconfig fails on QS22
On Wed, Jun 25, 2008 at 05:59:33PM +0200, Segher Boessenkool wrote: D'oh. I spent so much time and the solution is so easy. Thanks everybody. I have updated to binutils-2.18.50.0.6-2.ppc and now it works again on QS22 and JS21. So I checked your binary, and the only differences between working and not-working are a) some section offsets in the file, and b) the load address of the segment (0 vs. 0xc000...). a) should be harmless, and b) likely is a binutils bug that got fixed. What is the exact binutils version you used for the non-working? Should I had two old Fedora installations. Both installations have been updated, but looking at the installation tree it must have been something like 2.16.91.0.6 and 2.17.50.0.3 we test for it in our Makefile? If we require 2.18, we can drop the tests for 2.12 and 2.14 ;-) Adrian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: starting with 2.6.26-rc1 cell_defconfig fails on QS22
On Tue, Jun 24, 2008 at 09:45:32AM +1000, Jeremy Kerr wrote: Somehow I expect that I am doing something wrong, because nobody else has reported something like this yet. Seems to work fine here - just booted 945754a on a QS22 with cell_defconfig: [EMAIL PROTECTED] ~]$ cat /proc/version Linux version 2.6.26-rc7-09992-g945754a ([EMAIL PROTECTED]) (gcc version 4.1.3 20080114 (prerelease) (Debian 4.1.2-19)) #154 SMP Tue Jun 24 09:32:59 EST 2008 Reverting that commit definitely fixes the problem for you? Perhaps a binutils problem then? D'oh. I spent so much time and the solution is so easy. Thanks everybody. I have updated to binutils-2.18.50.0.6-2.ppc and now it works again on QS22 and JS21. Adrian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/1] Change the default link address for pSeries zImage kernels.
On Mon, Jun 23, 2008 at 06:13:23PM +1000, Tony Breeds wrote: Currently we set the start of the .text section to be 4Mb for pSeries. In situations where the zImage is 8Mb we'll fail to boot (due to overlapping with OF). Move .text in a zImage from 4MB to 64MB (well past OF). We still will not be able to load large zImage unless we also move OF, to that end, add a note to the zImage ELF to move OF to 32Mb. If this is the very first kernel booted then we'll need to moev OF manually by setting real-base. Does this change also affect kernels for SLOF based systems (JS20, JS21, Bimini/Powerstation, QS21, QS22)? To avoid exactly that problem SLOF moved to a bit below 256MB on all those platforms (about 220MB). There should be still enough space between 64MB and 220MB to boot large kernels. It is, however, decreased by 60MB. Adrian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
starting with 2.6.26-rc1 cell_defconfig fails on QS22
I have a custom config to build a kernel which runs on JS21/QS21/QS22. Starting with 2.6.26-rc1 that fails on JS21 (with SLOF). Bisecting lead me to the following commit: commit 366234f657879aeb7a1e2ca582f2f24f3fae9269 Author: Kumar Gala [EMAIL PROTECTED] Date: Wed Apr 16 05:52:28 2008 +1000 [POWERPC] Update linker script to properly set physical addresses I then tried it with cell_defconfig and it fails with almost the same error on QS22. I have not restared the bisecting on QS22 because the error is so similar: zImage starting: loaded at 0x0040 (sp: 0x0e16aea0) Allocating 0x6790c8 bytes for kernel ... OF version = 'IBM,SLOF,HEAD' gunzipping (0x0140 - 0x00407000:0x0062ce4a)...done 0x60405a bytes Linux/PowerPC load: Finalizing device tree... using OF tree (promptr=0e1004c4) ( 700 ) Program Exception [ e1004c4 ] R0 .. R7 R8 .. R15 R16 .. R23 R24 .. R31 014073b0 0e974200 0e16aea0 00638c04 019e2b98 0e974200 0140 b0003000 00638804 2000 0e96f3c0 0e1004c4 0e1004c4 0e96f3c0 00638804 0eac5d70 CR / XER LR / CTR SRR0 / SRR1DAR / DSISR 8022 014073e8 0189e99c 2000 0140 90083000 I have tried it with gcc-3.4.2, gcc-4.1.1 and gcc-4.2.4. Somehow I expect that I am doing something wrong, because nobody else has reported something like this yet. It looks like 2.6.25 was the last version which worked on SLOF based systems. Adrian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.23-rc1 breaks on JS20 w/SLOF
On Tue, Jul 24, 2007 at 08:06:18AM +1000, Benjamin Herrenschmidt wrote: On Mon, 2007-07-23 at 16:47 +0200, Adrian Reber wrote: On a JS20 with SLOF (pretending to be Maple) 2.6.23-rc1 breaks with following oops. 2.6.22 is working. Let me know if I can help debug this. That would be my fault... looks like it tries to access IO ports before the IO space is mapped by the PCI code, and without a legacy ISA range. The later is now the only case where IO ports are available before the main PCI setup. I can add some tweak to the maple code to map the ISA stuff even when the isa node is missing... This also happens on JS21 (with SLOF) in a pretty similar way. Adrian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
