* RE: Kernel oops while duming user core.
From: Rune Torgersen @ 2008-01-31 19:23 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <504DF4A9-6ED5-4208-84B4-FECC3FC90C0D@kernel.crashing.org>
Kumar Gala wrote:
> Can you git-bisect to narrow this down further.
Not easilly, as the board port to arch/powerpc was done on 2.6.24-rc7
and up.
Is there an somewhat esy way in git to apply the differences from master
branch to our board branch to a branch created by bisect?
And I don't even know where this started to happen.
Would trying arch/ppc help any? I have our arch/ppc port in a
semiworking state for kernels up to 2.6.23
^ permalink raw reply
* Re: build fails for adder875 for new pulls of powerpc.git
From: Jochen Friedrich @ 2008-01-31 18:36 UTC (permalink / raw)
To: Rognlien Dag Kristian; +Cc: linuxppc-dev
In-Reply-To: <47A2118B.2060808@scram.de>
Hi Rognlien,
> Hi Rognlien,
>
>> The latest commits to powerpc.git removes commproc.h files used by arch/powerpc/platforms/8xx/adder875.c
>>
>> The kernel fails to build for the adder configs.
>
> This should fix it:
>
> diff --git a/arch/powerpc/platforms/8xx/adder875.c b/arch/powerpc/platforms/8xx/adder875.c
> index c6bc078..b49d62a 100644
> --- a/arch/powerpc/platforms/8xx/adder875.c
> +++ b/arch/powerpc/platforms/8xx/adder875.c
> @@ -15,12 +15,12 @@
>
> #include <asm/time.h>
> #include <asm/machdep.h>
> -#include <asm/commproc.h>
> +#include <asm/cpm1.h>
> #include <asm/fs_pd.h>
> #include <asm/udbg.h>
> #include <asm/prom.h>
>
> -#include <sysdev/commproc.h>
> +#include "mpc8xx.h"
>
> struct cpm_pin {
> int port, pin, flags;
sorry, this fix was incomplete. Scott Wood just posted a correct fix.
Thanks,
Jochen
^ permalink raw reply
* Kernel oops in MPC8568MDS BSP
From: mike zheng @ 2008-01-31 19:28 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I am using MPC8568MDS BSP on my board, which has same memory map with
MPC8568MDS board. However I have kernel Ooop at
free_bootmem_with_active_regions() within do_init_bootmem(). Any idea
on this issue?
Thanks,
Mike
bootm 0x1000000 0x2000000 0x400000
## Booting image at 01000000 ...
Image Name: Linux-2.6.23
Created: 2008-01-31 18:52:45 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1370100 Bytes = 1.3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 02000000 ...
Image Name: uboot ext2 ramdisk rootfs
Created: 2007-11-26 2:28:38 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 4001113 Bytes = 3.8 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Booting using flat device tree at 0x400000
Loading Ramdisk to 1fb6e000, end 1ff3ed59 ... OK
Using MPC85xx MDS machine description
Memory CAM mapping: CAM0=256Mb, CAM1=256Mb, CAM2=0Mb residual: 0Mb
Linux version 2.6.23 () (gcc version 4.1.2) #3 Thu Jan 31 13:52:40 EST 2008
Found initrd at 0xdfb6e000:0xdff3ed59
console [udbg0] enabled
Kernel BUG at c0296a68 [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
MPC85xx MDS
Modules linked in:
NIP: c0296a68 LR: c0298100 CTR: 00001c00
REGS: c02c7ec0 TRAP: 0700 Not tainted (2.6.23)
MSR: 00021000 <ME> CR: 24002028 XER: 20000000
TASK = c02ac5e0[0] 'swapper' THREAD: c02c6000
GPR00: 00000001 c02c7f70 c02ac5e0 c02daa2c 0001e401 20000000 00000000
00000356
GPR08: 00000001 00000000 25e90000 25e90000 24002022 60000000 1ffbd400
007fff00
GPR16: 00000000 1ffb9824 00000004 1fffc830 00800000 00000000 007ffeb0
003d0d59
GPR24: 00000000 1ff3fe50 00001140 c02b0000 00000000 c02a5320 00020000
00000000
Call Trace:
[c02c7f90] [c0291144]
[c02c7fb0] [c028f250]
[c02c7fc0] [c028681c]
[c02c7ff0] [c0000388]
Instruction dump:
5489e8fa 7d000030 7d295a14 7d604828 7d6a0078 7d40492d 40a2fff4
7c095839
38840001 4182000c 4200ffd0 4e800020 <0fe00000> 48000000 3d20c02b
7c601b78
Kernel panic - not syncing: Attempted to kill the idle task!
^ permalink raw reply
* Kernel oops in MPC8568MDS BSP
From: mike zheng @ 2008-01-31 19:29 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am using MPC8568MDS BSP on my board, which has same memory map as
MPC8568MDS board has. However I have kernel oops at
free_bootmem_with_active_regions() within do_init_bootmem(). Any idea
on this issue?
Thanks,
Mike
bootm 0x1000000 0x2000000 0x400000
## Booting image at 01000000 ...
Image Name: Linux-2.6.23
Created: 2008-01-31 18:52:45 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1370100 Bytes = 1.3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 02000000 ...
Image Name: uboot ext2 ramdisk rootfs
Created: 2007-11-26 2:28:38 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 4001113 Bytes = 3.8 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Booting using flat device tree at 0x400000
Loading Ramdisk to 1fb6e000, end 1ff3ed59 ... OK
Using MPC85xx MDS machine description
Memory CAM mapping: CAM0=256Mb, CAM1=256Mb, CAM2=0Mb residual: 0Mb
Linux version 2.6.23 () (gcc version 4.1.2) #3 Thu Jan 31 13:52:40 EST 2008
Found initrd at 0xdfb6e000:0xdff3ed59
console [udbg0] enabled
Kernel BUG at c0296a68 [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
MPC85xx MDS
Modules linked in:
NIP: c0296a68 LR: c0298100 CTR: 00001c00
REGS: c02c7ec0 TRAP: 0700 Not tainted (2.6.23)
MSR: 00021000 <ME> CR: 24002028 XER: 20000000
TASK = c02ac5e0[0] 'swapper' THREAD: c02c6000
GPR00: 00000001 c02c7f70 c02ac5e0 c02daa2c 0001e401 20000000 00000000
00000356
GPR08: 00000001 00000000 25e90000 25e90000 24002022 60000000 1ffbd400
007fff00
GPR16: 00000000 1ffb9824 00000004 1fffc830 00800000 00000000 007ffeb0
003d0d59
GPR24: 00000000 1ff3fe50 00001140 c02b0000 00000000 c02a5320 00020000
00000000
Call Trace:
[c02c7f90] [c0291144]
[c02c7fb0] [c028f250]
[c02c7fc0] [c028681c]
[c02c7ff0] [c0000388]
Instruction dump:
5489e8fa 7d000030 7d295a14 7d604828 7d6a0078 7d40492d 40a2fff4
7c095839
38840001 4182000c 4200ffd0 4e800020 <0fe00000> 48000000 3d20c02b
7c601b78
Kernel panic - not syncing: Attempted to kill the idle task!
^ permalink raw reply
* Re: Kernel oops while duming user core.
From: Nathan Lynch @ 2008-01-31 19:54 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B03EE4869@ismail.innsys.innovsys.com>
Rune Torgersen wrote:
> Kumar Gala wrote:
> > Can you git-bisect to narrow this down further.
>
> Not easilly, as the board port to arch/powerpc was done on 2.6.24-rc7
> and up.
> Is there an somewhat esy way in git to apply the differences from master
> branch to our board branch to a branch created by bisect?
>
> And I don't even know where this started to happen.
> Would trying arch/ppc help any? I have our arch/ppc port in a
> semiworking state for kernels up to 2.6.23
Well, we know this happens on other 32-bit powerpc machines (pmac at
least)... perhaps someone could arrange to bisect on a machine that
works with older powerpc kernels (assuming they have a good repro
case).
^ permalink raw reply
* Re: [PATCH] [POWERPC] Xilinx: hwicap driver
From: Grant Likely @ 2008-01-31 19:58 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev
In-Reply-To: <20080131184722.B5E1C1A600C4@mail138-dub.bigfish.com>
On 1/31/08, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
> This includes code for new fifo-based xps_hwicap in addition to the
> older opb_hwicap, which has a significantly different interface. The
> common code between the two drivers is largely shared.
>
> Significant differences exists between this driver and what is
> supported in the EDK drivers. In particular, most of the
> architecture-specific code for reconfiguring individual FPGA resources
> has been removed. This functionality is likely better provided in a
> user-space support library. In addition, read and write access is
> supported. In addition, although the xps_hwicap cores support
> interrupt-driver mode, this driver only supports polled operation, in
> order to make the code simpler, and since the interrupt processing
> overhead is likely to slow down the throughput under Linux.
>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Comments below...
Also, I'm not sure if drivers/char/xilinx_hwicap is the best place for
this driver. drivers/misc/ might be better (but I'm not sure; poll
other people on this)
Finally, buffer_icap and fifo_icap are not huge blocks of code. Will
they be used by any other drivers? Can they be rolled into the
xilinx_hwicap.c file?
> +static int buffer_icap_device_read(struct hwicap_drvdata *drvdata,
> + u32 offset, u32 count)
> +{
> +
> + s32 retries = 0;
> + void __iomem *base_address = drvdata->base_address;
> +
> + if (buffer_icap_busy(base_address))
> + return -EBUSY;
> +
> + if ((offset + count) <= XHI_MAX_BUFFER_INTS) {
> + /* setSize count*4 to get bytes. */
> + buffer_icap_set_size(base_address, (count << 2));
> + buffer_icap_set_offset(base_address, offset);
> + buffer_icap_set_rnc(base_address, XHI_READBACK);
> +
> + while (buffer_icap_busy(base_address)) {
> + retries++;
> + if (retries > XHI_MAX_RETRIES)
> + return -EBUSY;
> + }
> + } else {
> + return -EINVAL;
> + }
Style comment: reverse the condition and bail with return -EINVAL at
the test point. It will simplify the code and better match with
common practice in the kernel.
> + return 0;
> +
> +};
> +
> +/**
> + * buffer_icap_device_write: Transfer bytes from ICAP to the storage buffer.
> + * @parameter drvdata: a pointer to the drvdata.
> + * @parameter offset: The storage buffer start address.
> + * @parameter count: The number of words (32 bit) to read from the
> + * device (ICAP).
> + **/
> +static int buffer_icap_device_write(struct hwicap_drvdata *drvdata,
> + u32 offset, u32 count)
> +{
> +
> + s32 retries = 0;
> + void __iomem *base_address = drvdata->base_address;
> +
> + if (buffer_icap_busy(base_address))
> + return -EBUSY;
> +
> + if ((offset + count) <= XHI_MAX_BUFFER_INTS) {
> + /* setSize count*4 to get bytes. */
> + buffer_icap_set_size(base_address, count << 2);
> + buffer_icap_set_offset(base_address, offset);
> + buffer_icap_set_rnc(base_address, XHI_CONFIGURE);
> +
> + while (buffer_icap_busy(base_address)) {
> + retries++;
> + if (retries > XHI_MAX_RETRIES)
> + return -EBUSY;
> + }
> + } else {
> + return -EINVAL;
> + }
Ditto
> +/**
> + * buffer_icap_set_configuration: Load a partial bitstream from system memory.
> + * @parameter drvdata: a pointer to the drvdata.
> + * @parameter data: Kernel address of the partial bitstream.
> + * @parameter size: the size of the partial bitstream in 32 bit words.
> + **/
> +int buffer_icap_set_configuration(struct hwicap_drvdata *drvdata, u32 *data,
> + u32 size)
> +{
> + int status;
> + s32 buffer_count = 0;
> + s32 num_writes = 0;
> + bool dirty = 0;
> + u32 i;
> + void __iomem *base_address = drvdata->base_address;
> +
> + /* Loop through all the data */
> + for (i = 0, buffer_count = 0; i < size; i++) {
> +
> + /* Copy data to bram */
> + buffer_icap_set_bram(base_address, buffer_count, data[i]);
> + dirty = 1;
> +
> + if (buffer_count == XHI_MAX_BUFFER_INTS - 1) {
> + /* Write data to ICAP */
> + status = buffer_icap_device_write(
> + drvdata,
> + XHI_BUFFER_START,
> + XHI_MAX_BUFFER_INTS);
> + if (status != 0) {
> + /* abort. */
> + buffer_icap_reset(drvdata);
> + return status;
> + }
> +
> + buffer_count = 0;
> + num_writes++;
> + dirty = 0;
> + } else {
> + buffer_count++;
> + }
Nit: Consider reversing the test condition and using 'buffer_count++; continue'
> +static ssize_t
> +hwicap_read(struct file *file, char *buf, size_t count, loff_t *ppos)
> +{
> + struct hwicap_drvdata *drvdata = file->private_data;
> + ssize_t bytes_to_read = 0;
> + u32 *kbuf;
> + u32 words;
> + u32 bytes_remaining;
> + int status;
> +
> + if (drvdata->is_accessing)
> + return -EBUSY;
> +
> + drvdata->is_accessing = 1;
Race condition, you need to use a semaphore. Otherwise it is possible
to get two processes (or even two threads of the same process) in the
read() hook.
> +static int hwicap_open(struct inode *inode, struct file *file)
> +{
> + struct hwicap_drvdata *drvdata;
> + int status;
> +
> + drvdata = container_of(inode->i_cdev, struct hwicap_drvdata, cdev);
> + if (drvdata->is_open)
> + return -EBUSY;
> +
> + drvdata->is_open = 1;
Also a race condition. Use a semaphore.
Also, this isn't sufficient to prevent 2 processes from having the
device open. If a process has already opened it and then calls
fork(), then *both* processes will have it opened even though the open
fop was only called once. (It might not matter for this particular
driver as the use case is limited; but it is something you should be
aware of.)
> +static int __devinit hwicap_setup(struct device *dev, int id,
> + const struct resource *regs_res,
> + const struct hwicap_driver_config *config,
> + const struct config_registers *config_regs)
> +{
> + dev_t devt;
> + struct hwicap_drvdata *drvdata = NULL;
> + int retval = 0;
> +
> + dev_info(dev, "Xilinx icap port driver\n");
> +
> + if (id < 0) {
> + for (id = 0; id < HWICAP_DEVICES; id++)
> + if (!probed_devices[id])
> + break;
> + }
> + if (id < 0 || id >= HWICAP_DEVICES) {
> + dev_err(dev, "%s%i too large\n", DRIVER_NAME, id);
> + return -EINVAL;
> + }
> + if (probed_devices[id]) {
> + dev_err(dev, "cannot assign to %s%i; it is already in use\n",
> + DRIVER_NAME, id);
> + return -EBUSY;
> + }
> +
> + probed_devices[id] = 1;
Hmmm, I'm not thrilled with the fixed array of HWICAP devices. That
sort of thing just ends up causing headaches down the road. Can the
driver just allocate a new structure and the next available ID at
probe time? (I hold my nose every time I write something like the
above because I know I'm going to regret it later). sysfs/udev can
provide details about which one is which.
> +
> +static int __devexit hwicap_remove(struct device *dev)
> +{
> + struct hwicap_drvdata *drvdata;
> +
> + drvdata = (struct hwicap_drvdata *)dev_get_drvdata(dev);
> +
> + if (drvdata) {
if (!drvdata)
return 0;
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Kernel oops while duming user core.
From: Scott Wood @ 2008-01-31 20:16 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B03EE47A4@ismail.innsys.innovsys.com>
On Thu, Jan 31, 2008 at 11:40:04AM -0600, Rune Torgersen wrote:
> Unable to handle kernel paging request for data at address 0x48024000
> Faulting instruction address: 0xc000f0a0
> Oops: Kernel access of bad area, sig: 11 [#1]
> PREEMPT Innovative Systems ApMax
Does it happen without preempt?
> Modules linked in: drv_wd(P) drv_scc devcom drv_pcir tipc drv_ss7
> drv_auxcpu drv_leds(P) drv_ethsw proc_sysinfo(P) i2c_8266(P)
> NIP: c000f0a0 LR: c0011fec CTR: 00000080
> REGS: eebe9b70 TRAP: 0300 Tainted: P (2.6.24-test)
Does it happen without the modules?
> MSR: 00009032 <EE,ME,IR,DR> CR: 24004442 XER: 00000000
> DAR: 48024000, DSISR: 20000000
Hmm, this doesn't look like a valid DSISR, so I'm guessing this was a TLB
miss that got redirected to DataAccess (or is there something that causes
DSRISR[2] to be set on 8280? I didn't see anything in the manual...).
However, SRR1 in that case seems to indicate a store, which dcbst shouldn't
generate (except on 8xx, according to the comment in update_mmu_cache).
Do you have a simple test case that we could try to reproduce? I tried a
simple core dump on an 8280, and it worked.
Failing that, I'd add code to the page fault handler to dump what is (or
isn't) supposed to be mapped at the faulting address, and something to track
which (if any) TLB miss exception it came through.
-Scott
^ permalink raw reply
* RE: Kernel oops while duming user core.
From: Rune Torgersen @ 2008-01-31 20:19 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <20080131201601.GA10501@loki.buserror.net>
Scott Wood wrote:
> Does it happen without preempt?
Will try shortly, just updated my git to HEAD of Linus's tree
>=20
>> Modules linked in: drv_wd(P) drv_scc devcom drv_pcir tipc drv_ss7
>> drv_auxcpu drv_leds(P) drv_ethsw proc_sysinfo(P) i2c_8266(P)
>> NIP: c000f0a0 LR: c0011fec CTR: 00000080
>> REGS: eebe9b70 TRAP: 0300 Tainted: P (2.6.24-test)
>=20
> Does it happen without the modules?
Cannot test without most of them.
> Do you have a simple test case that we could try to
> reproduce? I tried a
> simple core dump on an 8280, and it worked.
I do not have a testcase, except a app for our board that does this
reliably after about 10 seconds.
> Failing that, I'd add code to the page fault handler to dump what is
> (or isn't) supposed to be mapped at the faulting address, and
> something to track which (if any) TLB miss exception it came through.
I can test code.
^ permalink raw reply
* Re: Reminder: removal of arch/ppc
From: Brian Waite @ 2008-01-31 20:20 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <E83C3B2F-0FC4-4248-B718-0C45B56E969A@kernel.crashing.org>
On Friday 25 January 2008, Kumar Gala wrote:
> Just a reminder that the plan is to remove arch/ppc this summer (June
> 2008). The following boards still existing over in arch/ppc. Some of
> them have been ported over to arch/powerpc. If you care about one of
> these boards and its not ported speak up (it helps if you have access
> to the board). Also, if you know a given board is free to die of
> bitrot let us know so we know not to worry about it:
>
> PREP
> PQ2ADS
> TQM8260
> CPCI690
> EV64260
> CHESTNUT
> LOPEC
> KATANA
> HDPU
HDPU can die. The company is not maintaining the platform anymore.
Thanks
Brian
^ permalink raw reply
* RE: Kernel oops while duming user core.
From: Rune Torgersen @ 2008-01-31 20:38 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <20080131201601.GA10501@loki.buserror.net>
Scott Wood wrote:
> Does it happen without preempt?
Yes
^ permalink raw reply
* Re: Kernel oops while duming user core.
From: Nathan Lynch @ 2008-01-31 20:41 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080131201601.GA10501@loki.buserror.net>
Scott Wood wrote:
> On Thu, Jan 31, 2008 at 11:40:04AM -0600, Rune Torgersen wrote:
> > Unable to handle kernel paging request for data at address 0x48024000
> > Faulting instruction address: 0xc000f0a0
> > Oops: Kernel access of bad area, sig: 11 [#1]
> > PREEMPT Innovative Systems ApMax
>
> Does it happen without preempt?
>
> > Modules linked in: drv_wd(P) drv_scc devcom drv_pcir tipc drv_ss7
> > drv_auxcpu drv_leds(P) drv_ethsw proc_sysinfo(P) i2c_8266(P)
> > NIP: c000f0a0 LR: c0011fec CTR: 00000080
> > REGS: eebe9b70 TRAP: 0300 Tainted: P (2.6.24-test)
>
> Does it happen without the modules?
I doubt the modules are the problem; there was a practically identical
report from someone with an untainted 2.6.24-rc kernel a few weeks ago
(see my first reply to Rune).
>
> > MSR: 00009032 <EE,ME,IR,DR> CR: 24004442 XER: 00000000
> > DAR: 48024000, DSISR: 20000000
>
> Hmm, this doesn't look like a valid DSISR, so I'm guessing this was a TLB
> miss that got redirected to DataAccess (or is there something that causes
> DSRISR[2] to be set on 8280? I didn't see anything in the manual...).
> However, SRR1 in that case seems to indicate a store, which dcbst shouldn't
> generate (except on 8xx, according to the comment in update_mmu_cache).
>
> Do you have a simple test case that we could try to reproduce? I tried a
> simple core dump on an 8280, and it worked.
Is the crashing program multithreaded? The first report had firefox
triggering the oops.
^ permalink raw reply
* RE: Kernel oops while duming user core.
From: Rune Torgersen @ 2008-01-31 20:45 UTC (permalink / raw)
To: Nathan Lynch, Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080131204158.GV14201@localdomain>
Nathan Lynch wrote:
> Scott Wood wrote:
>> Do you have a simple test case that we could try to reproduce? I
>> tried a simple core dump on an 8280, and it worked.
>=20
> Is the crashing program multithreaded? The first report had firefox
> triggering the oops.
The crashing program has 10 threads. (NPTL pthreads, glibc-2.5, gcc
4.1.2)
^ permalink raw reply
* Re: Kernel oops while duming user core.
From: Scott Wood @ 2008-01-31 20:55 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20080131204158.GV14201@localdomain>
Nathan Lynch wrote:
> I doubt the modules are the problem; there was a practically identical
> report from someone with an untainted 2.6.24-rc kernel a few weeks ago
> (see my first reply to Rune).
I didn't think they were; I was just trying to eliminate the low hanging
fruit and get a simpler testcase. :-)
>> Do you have a simple test case that we could try to reproduce? I tried a
>> simple core dump on an 8280, and it worked.
>
> Is the crashing program multithreaded? The first report had firefox
> triggering the oops.
OK, I've got a test program that triggers it now. I'll see if I can
figure out what's going on.
-Scott
^ permalink raw reply
* [PATCH] [POWERPC] Remove dead code at KernelAltiVec
From: Dale Farnsworth @ 2008-01-31 21:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
---
This code doesn't seem to be referenced anywhere.
arch/powerpc/kernel/head_32.S | 17 -----------------
arch/ppc/kernel/head.S | 17 -----------------
2 files changed, 0 insertions(+), 34 deletions(-)
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index 0f4fac5..c16d135 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -763,23 +763,6 @@ load_up_altivec:
b fast_exception_return
/*
- * AltiVec unavailable trap from kernel - print a message, but let
- * the task use AltiVec in the kernel until it returns to user mode.
- */
-KernelAltiVec:
- lwz r3,_MSR(r1)
- oris r3,r3,MSR_VEC@h
- stw r3,_MSR(r1) /* enable use of AltiVec after return */
- lis r3,87f@h
- ori r3,r3,87f@l
- mr r4,r2 /* current */
- lwz r5,_NIP(r1)
- bl printk
- b ret_from_except
-87: .string "AltiVec used in kernel (task=%p, pc=%x) \n"
- .align 4,0
-
-/*
* giveup_altivec(tsk)
* Disable AltiVec for the task given as the argument,
* and save the AltiVec registers in its thread_struct.
diff --git a/arch/ppc/kernel/head.S b/arch/ppc/kernel/head.S
index 1b0ec72..e7e642b 100644
--- a/arch/ppc/kernel/head.S
+++ b/arch/ppc/kernel/head.S
@@ -701,23 +701,6 @@ load_up_altivec:
b fast_exception_return
/*
- * AltiVec unavailable trap from kernel - print a message, but let
- * the task use AltiVec in the kernel until it returns to user mode.
- */
-KernelAltiVec:
- lwz r3,_MSR(r1)
- oris r3,r3,MSR_VEC@h
- stw r3,_MSR(r1) /* enable use of AltiVec after return */
- lis r3,87f@h
- ori r3,r3,87f@l
- mr r4,r2 /* current */
- lwz r5,_NIP(r1)
- bl printk
- b ret_from_except
-87: .string "AltiVec used in kernel (task=%p, pc=%x) \n"
- .align 4,0
-
-/*
* giveup_altivec(tsk)
* Disable AltiVec for the task given as the argument,
* and save the AltiVec registers in its thread_struct.
^ permalink raw reply related
* Re: [RFC] [POWERPC] bootwrapper: build multiple cuImages
From: Geoff Levand @ 2008-01-31 21:12 UTC (permalink / raw)
To: Grant Likely; +Cc: scottwood, linuxppc-dev
In-Reply-To: <20080131003347.5779.96112.stgit@trillian.secretlab.ca>
On 01/30/2008 04:34 PM, Grant Likely wrote:
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
...
> $(obj)/zImage.ps3: vmlinux $(wrapper) $(wrapperbits) $(srctree)/$(src)/dts/ps3.dts
Seems like this could use $(dtstree).
> $(STRIP) -s -R .comment $< -o vmlinux.strip
> - $(call cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,)
> + $(call cmd,wrap,ps3,$(dtstree)/ps3.dts,,)
>
> $(obj)/zImage.initrd.ps3: vmlinux $(wrapper) $(wrapperbits) $(srctree)/$(src)/dts/ps3.dts $(obj)/ramdisk.image.gz
Same here.
> - $(call cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,$(obj)/ramdisk.image.gz)
> + $(call cmd,wrap,ps3,$(dtstree)/ps3.dts,,$(obj)/ramdisk.image.gz)
^ permalink raw reply
* Re: Kernel oops while duming user core.
From: Scott Wood @ 2008-01-31 21:58 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <47A235AD.9050107@freescale.com>
Scott Wood wrote:
> Nathan Lynch wrote:
>> Is the crashing program multithreaded? The first report had firefox
>> triggering the oops.
>
> OK, I've got a test program that triggers it now. I'll see if I can
> figure out what's going on.
The problem seems to be that update_mmu_cache() is called on a guard
page with no access rights.
Changing update_mmu_cache() to always call flush_dcache_icache_page()
fixes it, though a better performing fix would probably be to add an
exception table entry for the dcbst.
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] Add RapidIO node into MPC8641HPCN dts file
From: Jon Loeliger @ 2008-01-31 16:28 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev
In-Reply-To: <12017656032841-git-send-email-wei.zhang@freescale.com>
Zhang Wei wrote:
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8641_hpcn.dts | 13 +++++++++++++
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> index 556a9ca..1a0fce5 100644
> --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> @@ -25,6 +25,7 @@
> serial1 = &serial1;
> pci0 = &pci0;
> pci1 = &pci1;
> + rapidio0 = &rapidio0;
> };
>
> cpus {
> @@ -499,4 +500,16 @@
> 0 00100000>;
> };
> };
> +
> + rapidio0: rapidio@f80c0000 {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + compatible = "fsl,rapidio-delta";
> + reg = <f80c0000 20000>;
> + ranges = <0 0 c0000000 0 20000000>;
> + interrupt-parent = <&mpic>;
> + /* err_irq bell_outb_irq bell_inb_irq
> + msg1_tx_irq msg1_rx_irq msg2_tx_irq msg2_rx_irq */
> + interrupts = <30 2 31 2 32 2 35 2 36 2 37 2 38 2>;
> + };
> };
The 8641 DTS file has been converted to /dts-v1/ format now.
Please rewrite this patch with explicit hex numbers for
addresses, even if 0x0, and decimal for IRQs.
Thanks,
jdl
^ permalink raw reply
* RE: Kernel oops while duming user core.
From: Rune Torgersen @ 2008-01-31 22:10 UTC (permalink / raw)
To: Scott Wood, Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <47A24480.8060103@freescale.com>
Scott Wood wrote:
> Scott Wood wrote:
>> Nathan Lynch wrote:
>>> Is the crashing program multithreaded? The first report had firefox
>>> triggering the oops.
>>=20
>> OK, I've got a test program that triggers it now. I'll see if I can
>> figure out what's going on.
>=20
> The problem seems to be that update_mmu_cache() is called on a guard
> page with no access rights.=20
>=20
> Changing update_mmu_cache() to always call flush_dcache_icache_page()
> fixes it, though a better performing fix would probably be to add an
> exception table entry for the dcbst.
I can confirm that this seems to fix it.
^ permalink raw reply
* RE: [PATCH] [POWERPC] Xilinx: hwicap driver
From: Stephen Neuendorffer @ 2008-01-31 22:39 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801311158u470981e9o6862767dea881f4b@mail.gmail.com>
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of
Grant Likely
> Sent: Thursday, January 31, 2008 11:59 AM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org; jacmet@sunsite.dk
> Subject: Re: [PATCH] [POWERPC] Xilinx: hwicap driver
>=20
> On 1/31/08, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
wrote:
> > This includes code for new fifo-based xps_hwicap in addition to the
> > older opb_hwicap, which has a significantly different interface.
The
> > common code between the two drivers is largely shared.
> >
> > Significant differences exists between this driver and what is
> > supported in the EDK drivers. In particular, most of the
> > architecture-specific code for reconfiguring individual FPGA
resources
> > has been removed. This functionality is likely better provided in a
> > user-space support library. In addition, read and write access is
> > supported. In addition, although the xps_hwicap cores support
> > interrupt-driver mode, this driver only supports polled operation,
in
> > order to make the code simpler, and since the interrupt processing
> > overhead is likely to slow down the throughput under Linux.
> >
> > Signed-off-by: Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com>
>=20
> Comments below...
>=20
> Also, I'm not sure if drivers/char/xilinx_hwicap is the best place for
> this driver. drivers/misc/ might be better (but I'm not sure; poll
> other people on this)
I don't have strong opinions on this... If someone wants to say it
should be in drivers/misc, I'm more than happy to move it. However, it
doesn't seem like there is anything else that is a pure character device
there.
> Finally, buffer_icap and fifo_icap are not huge blocks of code. Will
> they be used by any other drivers? Can they be rolled into the
> xilinx_hwicap.c file?
They're not huge, but they are really independent from eachother.
Furthermore, I expect that future cores will have DMA capability to
increase bandwidth, which would result in a dma_icap file.
> Style comment: reverse the condition and bail with return -EINVAL at
> the test point. It will simplify the code and better match with
> common practice in the kernel.
good point, I'll fix them all.
> > +static ssize_t
> > +hwicap_read(struct file *file, char *buf, size_t count, loff_t
*ppos)
> > +{
> > + struct hwicap_drvdata *drvdata =3D file->private_data;
> > + ssize_t bytes_to_read =3D 0;
> > + u32 *kbuf;
> > + u32 words;
> > + u32 bytes_remaining;
> > + int status;
> > +
> > + if (drvdata->is_accessing)
> > + return -EBUSY;
> > +
> > + drvdata->is_accessing =3D 1;
>=20
> Race condition, you need to use a semaphore. Otherwise it is possible
> to get two processes (or even two threads of the same process) in the
> read() hook.
good point. On thinking about this more, does the whole function need
to be in a semaphore to protect against PREEMPT kernels?
> > +static int hwicap_open(struct inode *inode, struct file *file)
> > +{
> > + struct hwicap_drvdata *drvdata;
> > + int status;
> > +
> > + drvdata =3D container_of(inode->i_cdev, struct =
hwicap_drvdata,
cdev);
> > + if (drvdata->is_open)
> > + return -EBUSY;
> > +
> > + drvdata->is_open =3D 1;
>=20
> Also a race condition. Use a semaphore.
>=20
> Also, this isn't sufficient to prevent 2 processes from having the
> device open. If a process has already opened it and then calls
> fork(), then *both* processes will have it opened even though the open
> fop was only called once. (It might not matter for this particular
> driver as the use case is limited; but it is something you should be
> aware of.)
The fork I'm somewhat less concerned about, I think. If someone calls
fork(), then it's up to them to synchronize their code correctly and
only call close() once. The only reason to block the open is that it's
the simplest way to keep track of the state between reads and writes.
> > +static int __devinit hwicap_setup(struct device *dev, int id,
> > + const struct resource *regs_res,
> > + const struct hwicap_driver_config *config,
> > + const struct config_registers *config_regs)
> > +{
> > + dev_t devt;
> > + struct hwicap_drvdata *drvdata =3D NULL;
> > + int retval =3D 0;
> > +
> > + dev_info(dev, "Xilinx icap port driver\n");
> > +
> > + if (id < 0) {
> > + for (id =3D 0; id < HWICAP_DEVICES; id++)
> > + if (!probed_devices[id])
> > + break;
> > + }
> > + if (id < 0 || id >=3D HWICAP_DEVICES) {
> > + dev_err(dev, "%s%i too large\n", DRIVER_NAME, id);
> > + return -EINVAL;
> > + }
> > + if (probed_devices[id]) {
> > + dev_err(dev, "cannot assign to %s%i; it is already
in use\n",
> > + DRIVER_NAME, id);
> > + return -EBUSY;
> > + }
> > +
> > + probed_devices[id] =3D 1;
>=20
> Hmmm, I'm not thrilled with the fixed array of HWICAP devices. That
> sort of thing just ends up causing headaches down the road. Can the
> driver just allocate a new structure and the next available ID at
> probe time? (I hold my nose every time I write something like the
> above because I know I'm going to regret it later). sysfs/udev can
> provide details about which one is which.
Can you suggest a good driver to crib?
> Cheers,
> g.
Thanks!
^ permalink raw reply
* Re: Reminder: removal of arch/ppc
From: Mark A. Greer @ 2008-01-31 22:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <E83C3B2F-0FC4-4248-B718-0C45B56E969A@kernel.crashing.org>
On Fri, Jan 25, 2008 at 10:55:25AM -0600, Kumar Gala wrote:
> Just a reminder that the plan is to remove arch/ppc this summer (June
> 2008). The following boards still existing over in arch/ppc. Some of
> them have been ported over to arch/powerpc. If you care about one of
> these boards and its not ported speak up (it helps if you have access
> to the board). Also, if you know a given board is free to die of
> bitrot let us know so we know not to worry about it:
I guess I'm just not a nice guy but I say let them die. No need
to worry. The code really isn't going anywhere -- git-checkout
v2.6.<pick your favorite version> and its back.
/me's $0.02.
Mark
^ permalink raw reply
* Re: [PATCH] [POWERPC] Xilinx: hwicap driver
From: Grant Likely @ 2008-01-31 23:12 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev
In-Reply-To: <20080131223933.4DC0115B937D@mail113-dub.bigfish.com>
On 1/31/08, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
> > Also, this isn't sufficient to prevent 2 processes from having the
> > device open. If a process has already opened it and then calls
> > fork(), then *both* processes will have it opened even though the open
> > fop was only called once. (It might not matter for this particular
> > driver as the use case is limited; but it is something you should be
> > aware of.)
>
> The fork I'm somewhat less concerned about, I think. If someone calls
> fork(), then it's up to them to synchronize their code correctly and
> only call close() once. The only reason to block the open is that it's
> the simplest way to keep track of the state between reads and writes.
<interesting trivia> You're thinking of threads; not fork. When fork
is called you get a whole new process which has all the same file
descriptors open as the parent process. This is what the timeline
would look like:
p1: open(/dev/hwcap0)
--- open fop called here (and struct file is allocated)
p1: fork()
--- p2 is created
p1: do stuff
p2: do stuff
p1: close()
p2: do more stuff
p2: close()
--- release fop called here (and struct file is released)
Notice how close is called twice (the correct behavour) yet release is
only called once? :-) That means there are 2 processes sharing the
same file structure.
> > > +static int __devinit hwicap_setup(struct device *dev, int id,
> > > + const struct resource *regs_res,
> > > + const struct hwicap_driver_config *config,
> > > + const struct config_registers *config_regs)
> > > +{
> > > + dev_t devt;
> > > + struct hwicap_drvdata *drvdata = NULL;
> > > + int retval = 0;
> > > +
> > > + dev_info(dev, "Xilinx icap port driver\n");
> > > +
> > > + if (id < 0) {
> > > + for (id = 0; id < HWICAP_DEVICES; id++)
> > > + if (!probed_devices[id])
> > > + break;
> > > + }
> > > + if (id < 0 || id >= HWICAP_DEVICES) {
> > > + dev_err(dev, "%s%i too large\n", DRIVER_NAME, id);
> > > + return -EINVAL;
> > > + }
> > > + if (probed_devices[id]) {
> > > + dev_err(dev, "cannot assign to %s%i; it is already
> in use\n",
> > > + DRIVER_NAME, id);
> > > + return -EBUSY;
> > > + }
> > > +
> > > + probed_devices[id] = 1;
> >
> > Hmmm, I'm not thrilled with the fixed array of HWICAP devices. That
> > sort of thing just ends up causing headaches down the road. Can the
> > driver just allocate a new structure and the next available ID at
> > probe time? (I hold my nose every time I write something like the
> > above because I know I'm going to regret it later). sysfs/udev can
> > provide details about which one is which.
>
> Can you suggest a good driver to crib?
What I would do is use a static struct list_head to hold a list of all
instantiated devices. When you register a new device you can use
list_for_each_entry to look for a free id. That way you don't have to
preallocate an array for all the possible device numbers.
OTOH, how many of these devices are likely to be present on any one
bitstream? If it is only 1 or 2 then it might be that the overhead
isn't worth the savings. I won't complain if you decide it's better
the way it is now.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: x86/non-x86: percpu, node ids, apic ids x86.git fixup
From: Luck, Tony @ 2008-01-31 23:28 UTC (permalink / raw)
To: Luck, Tony, Ingo Molnar
Cc: sparclinux, linux-ia64, Linux Kernel Development, Mike Travis,
Linux/PPC Development, Geert Uytterhoeven, Thomas Gleixner,
Linus Torvalds
In-Reply-To: <1FE6DD409037234FAB833C420AA843EC78C75A@orsmsx424.amr.corp.intel.com>
> So the percpu changes are innocent ... something else since 2.6.24 is
> to blame. Only 5749 commits :-) I'll start bisecting.
12 bisections later ... nothing! I think I got lost in the
maze. Bisection #5 had a crash, but it looked to be a very
differnt crash (and looked to happen later than the bug I was
hunting). So I marked that as "good" on the theory that it
looked like this bug wasn't in the kernel. Same thing happened
at bisection #9. But I ended up with:
commit bfada697bd534d2c16fd07fbef3a4924c4d4e014
Author: Pavel Emelyanov <xemul@openvz.org>
Date: Sun Dec 2 00:57:08 2007 +1100
[IPV4]: Use ctl paths to register devinet sysctls
Which just looks too improbable to be the cause of the UP
crash. Git won't revert it out from top of tree automatically
so I can't easily test whether some weird magic means that
this is the buggy commit.
Perhaps the issue is another offset of object X in kernel w.r.t.
object Y ... and so the good/bad choices in the bisection are
actually pretty random depending on how much code is stuffed
between X & Y at each bisection point.
-Tony
^ permalink raw reply
* [PATCH] [POWERPC] pasemi: Fix thinko in dma_direct_ops setup
From: Olof Johansson @ 2008-01-31 23:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, torvalds
In-Reply-To: <20080131064130.GA32344@lixom.net>
[POWERPC] pasemi: Fix thinko in dma_direct_ops setup
The first patch will just fall through and still set dma_data to a bad
value, make it return directly instead.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
Linus, thanks for picking up the patch so quickly. Unfortunately I
messed it up. Please apply this on top.
Thanks,
Olof
diff --git a/arch/powerpc/platforms/pasemi/iommu.c b/arch/powerpc/platforms/pasemi/iommu.c
index c5cfd4b..5803f11 100644
--- a/arch/powerpc/platforms/pasemi/iommu.c
+++ b/arch/powerpc/platforms/pasemi/iommu.c
@@ -184,7 +184,7 @@ static void pci_dma_dev_setup_pasemi(struct pci_dev *dev)
if (dev->vendor == 0x1959 && dev->device == 0xa007 &&
!firmware_has_feature(FW_FEATURE_LPAR)) {
dev->dev.archdata.dma_ops = &dma_direct_ops;
- dev->dev.archdata.dma_data = 0;
+ return;
}
#endif
^ permalink raw reply related
* RE: [PATCH] [POWERPC] Xilinx: hwicap driver
From: Stephen Neuendorffer @ 2008-01-31 23:51 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801311512l16b31df8q4d5bf940210389e@mail.gmail.com>
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of
Grant Likely
> Sent: Thursday, January 31, 2008 3:13 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org; jacmet@sunsite.dk
> Subject: Re: [PATCH] [POWERPC] Xilinx: hwicap driver
>=20
> On 1/31/08, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
wrote:
> > > Also, this isn't sufficient to prevent 2 processes from having the
> > > device open. If a process has already opened it and then calls
> > > fork(), then *both* processes will have it opened even though the
open
> > > fop was only called once. (It might not matter for this
particular
> > > driver as the use case is limited; but it is something you should
be
> > > aware of.)
> >
> > The fork I'm somewhat less concerned about, I think. If someone
calls
> > fork(), then it's up to them to synchronize their code correctly and
> > only call close() once. The only reason to block the open is that
it's
> > the simplest way to keep track of the state between reads and
writes.
>=20
> <interesting trivia> You're thinking of threads; not fork. When fork
> is called you get a whole new process which has all the same file
> descriptors open as the parent process. This is what the timeline
> would look like:
>=20
> p1: open(/dev/hwcap0)
> --- open fop called here (and struct file is allocated)
> p1: fork()
> --- p2 is created
> p1: do stuff
> p2: do stuff
> p1: close()
> p2: do more stuff
> p2: close()
> --- release fop called here (and struct file is released)
>=20
> Notice how close is called twice (the correct behavour) yet release is
> only called once? :-) That means there are 2 processes sharing the
> same file structure.
Hmm... hadn't realized that. In most uses of fork I've seen/thought
of, the return value of fork is used to identify the parent and child
processes and typically the child code avoids accessing the open files
in order to avoid colliding output (and relies on the implicit close()
on exit). In any event, regardless of when close is called, all we
really care about is the release fop... Regardless, I'll be more
careful about distinguishing the close and the release in the future,
though :)
> > > > +static int __devinit hwicap_setup(struct device *dev, int id,
> > > > + const struct resource *regs_res,
> > > > + const struct hwicap_driver_config *config,
> > > > + const struct config_registers *config_regs)
> > > > +{
> > > > + dev_t devt;
> > > > + struct hwicap_drvdata *drvdata =3D NULL;
> > > > + int retval =3D 0;
> > > > +
> > > > + dev_info(dev, "Xilinx icap port driver\n");
> > > > +
> > > > + if (id < 0) {
> > > > + for (id =3D 0; id < HWICAP_DEVICES; id++)
> > > > + if (!probed_devices[id])
> > > > + break;
> > > > + }
> > > > + if (id < 0 || id >=3D HWICAP_DEVICES) {
> > > > + dev_err(dev, "%s%i too large\n", DRIVER_NAME,
id);
> > > > + return -EINVAL;
> > > > + }
> > > > + if (probed_devices[id]) {
> > > > + dev_err(dev, "cannot assign to %s%i; it is
already
> > in use\n",
> > > > + DRIVER_NAME, id);
> > > > + return -EBUSY;
> > > > + }
> > > > +
> > > > + probed_devices[id] =3D 1;
> > >
> > > Hmmm, I'm not thrilled with the fixed array of HWICAP devices.
That
> > > sort of thing just ends up causing headaches down the road. Can
the
> > > driver just allocate a new structure and the next available ID at
> > > probe time? (I hold my nose every time I write something like the
> > > above because I know I'm going to regret it later). sysfs/udev
can
> > > provide details about which one is which.
> >
> > Can you suggest a good driver to crib?
>=20
> What I would do is use a static struct list_head to hold a list of all
> instantiated devices. When you register a new device you can use
> list_for_each_entry to look for a free id. That way you don't have to
> preallocate an array for all the possible device numbers.
>=20
> OTOH, how many of these devices are likely to be present on any one
> bitstream? If it is only 1 or 2 then it might be that the overhead
> isn't worth the savings. I won't complain if you decide it's better
> the way it is now.
In this case, it is highly likely that there will be only 1 in the
system, and since the code is properly parameterized with respect to the
number of devices that are registered, I don't think it's worth it.
Steve
^ permalink raw reply
* [RFC/PATCH v2] [POWERPC] bootwrapper: build multiple cuImages
From: Grant Likely @ 2008-02-01 0:07 UTC (permalink / raw)
To: jwboyer, linuxppc-dev, scotwood, galak, stephen.neuendorffer,
jochen, geoffrey.levand
From: Grant Likely <grant.likely@secretlab.ca>
Currently, the kernel uses CONFIG_DEVICE_TREE to wrap a kernel image
with a fdt blob which means for any given configuration only one dts
file can be selected and so support for only one board can be built
This patch moves the selection of the default .dts file out of the kernel
config and into the bootwrapper makefile. The makefile chooses which
images to build based on the kernel config and the dts source file
name is taken directly from the image name. For example "cuImage.ebony"
will use "ebony.dts" as the device tree source file.
In addition, this patch allows a specific image to be requested from the
command line by adding "cuImage.%" and "treeImage.%" targets to the list
of valid built targets in arch/powerpc/Makefile. This allows the default
dts selection to be overridden.
Another advantage to this change is it allows a single defconfig to be
supplied for all boards using the same chip family and only differing in
the device tree.
Important note: This patch adds two new zImage targets; zImage.dtb.% and
zImage.dtb.initrd.% for zImages with embedded dtb files. Currently
there are 5 platforms which require this: ps3, ep405, mpc885ads, ep88xc,
adder875-redboot and ep8248e. This patch *changes the zImage filenames*
for those platforms. ie. 'zImage.ps3' is now 'zImage.dtb.ps3'.
This new zImage.dtb targets were added so that the .dts file could be
part of the dependancies list for building them.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Please review and comment. I have not exhaustively tested this patch
and I'm sure to have missed some boards. However, I think the concept
is sound and will be a good change.
This version fixes some bugs and adds new zImage.dtb and zImage.initrd.dtb
targets.
g.
---
arch/powerpc/Kconfig | 19 -----
arch/powerpc/Makefile | 9 +-
arch/powerpc/boot/Makefile | 132 ++++++++++++++++++++------------
arch/powerpc/boot/cuboot-hpc2.c | 48 ------------
arch/powerpc/boot/cuboot-mpc7448hpc2.c | 48 ++++++++++++
arch/powerpc/boot/wrapper | 23 ++++++
6 files changed, 157 insertions(+), 122 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 2bf2f3f..4903796 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -415,25 +415,6 @@ config WANT_DEVICE_TREE
bool
default n
-config DEVICE_TREE
- string "Static device tree source file"
- depends on WANT_DEVICE_TREE
- help
- This specifies the device tree source (.dts) file to be
- compiled and included when building the bootwrapper. If a
- relative filename is given, then it will be relative to
- arch/powerpc/boot/dts. If you are not using the bootwrapper,
- or do not need to build a dts into the bootwrapper, this
- field is ignored.
-
- For example, this is required when building a cuImage target
- for an older U-Boot, which cannot pass a device tree itself.
- Such a kernel will not work with a newer U-Boot that tries to
- pass a device tree (unless you tell it not to). If your U-Boot
- does not mention a device tree in "help bootm", then use the
- cuImage target and specify a device tree here. Otherwise, use
- the uImage target and leave this field blank.
-
endmenu
config ISA_DMA_API
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index f70df9b..6845482 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -151,14 +151,11 @@ core-$(CONFIG_XMON) += arch/powerpc/xmon/
drivers-$(CONFIG_OPROFILE) += arch/powerpc/oprofile/
# Default to zImage, override when needed
-defaultimage-y := zImage
-defaultimage-$(CONFIG_DEFAULT_UIMAGE) := uImage
-KBUILD_IMAGE := $(defaultimage-y)
-all: $(KBUILD_IMAGE)
+all: zImage
CPPFLAGS_vmlinux.lds := -Upowerpc
-BOOT_TARGETS = zImage zImage.initrd uImage
+BOOT_TARGETS = zImage zImage.initrd uImage treeImage.% cuImage.%
PHONY += $(BOOT_TARGETS)
@@ -180,7 +177,7 @@ define archhelp
endef
install: vdso_install
- $(Q)$(MAKE) $(build)=$(boot) BOOTIMAGE=$(KBUILD_IMAGE) install
+ $(Q)$(MAKE) $(build)=$(boot) install
vdso_install:
ifeq ($(CONFIG_PPC64),y)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 122a270..bd2b98d 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -60,8 +60,9 @@ src-wlib := string.S crt0.S stdio.c main.c \
src-plat := of.c cuboot-52xx.c cuboot-824x.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 cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c \
- fixed-head.S ep88xc.c cuboot-hpc2.c ep405.c cuboot-taishan.c \
+ cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c \
+ cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
+ fixed-head.S ep88xc.c ep405.c \
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
cuboot-warp.c cuboot-85xx-cpm2.c
src-boot := $(src-wlib) $(src-plat) empty.c
@@ -123,6 +124,8 @@ targets += $(patsubst $(obj)/%,%,$(obj-boot) wrapper.a)
extra-y := $(obj)/wrapper.a $(obj-plat) $(obj)/empty.o \
$(obj)/zImage.lds $(obj)/zImage.coff.lds $(obj)/zImage.ps3.lds
+dtstree := $(srctree)/$(src)/dts
+
wrapper :=$(srctree)/$(src)/wrapper
wrapperbits := $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree dtc) \
$(wrapper) FORCE
@@ -181,7 +184,7 @@ quiet_cmd_wrap = WRAP $@
image-$(CONFIG_PPC_PSERIES) += zImage.pseries
image-$(CONFIG_PPC_MAPLE) += zImage.pseries
image-$(CONFIG_PPC_IBM_CELL_BLADE) += zImage.pseries
-image-$(CONFIG_PPC_PS3) += zImage.ps3
+image-$(CONFIG_PPC_PS3) += zImage.dtb.ps3
image-$(CONFIG_PPC_CELLEB) += zImage.pseries
image-$(CONFIG_PPC_CHRP) += zImage.chrp
image-$(CONFIG_PPC_EFIKA) += zImage.chrp
@@ -191,33 +194,73 @@ image-$(CONFIG_PPC_PRPMC2800) += zImage.prpmc2800
image-$(CONFIG_PPC_ISERIES) += zImage.iseries
image-$(CONFIG_DEFAULT_UIMAGE) += uImage
-ifneq ($(CONFIG_DEVICE_TREE),"")
-image-$(CONFIG_PPC_8xx) += cuImage.8xx
-image-$(CONFIG_PPC_EP88XC) += zImage.ep88xc
-image-$(CONFIG_EP405) += zImage.ep405
-image-$(CONFIG_8260) += cuImage.pq2
-image-$(CONFIG_EP8248E) += zImage.ep8248e
-image-$(CONFIG_PPC_MPC52xx) += cuImage.52xx
-image-$(CONFIG_STORCENTER) += cuImage.824x
-image-$(CONFIG_PPC_83xx) += cuImage.83xx
-image-$(CONFIG_PPC_85xx) += cuImage.85xx
-ifeq ($(CONFIG_CPM2),y)
-image-$(CONFIG_PPC_85xx) += cuImage.85xx-cpm2
-endif
-image-$(CONFIG_MPC7448HPC2) += cuImage.hpc2
+#
+# Targets which embed a device tree blob
+#
+# Theses are default targets to build images which embed device tree blobs.
+# They are only required on boards which do not have FDT support in firmware.
+# Boards with newish u-boot firmare can use the uImage target above
+#
+
+# Board ports in arch/powerpc/platform/40x/Kconfig
+image-$(CONFIG_EP405) += zImage.dtb.ep405
+image-$(CONFIG_WALNUT) += treeImage.walnut
+
+# Board ports in arch/powerpc/platform/44x/Kconfig
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
image-$(CONFIG_BAMBOO) += treeImage.bamboo cuImage.bamboo
image-$(CONFIG_SEQUOIA) += cuImage.sequoia
image-$(CONFIG_RAINIER) += cuImage.rainier
-image-$(CONFIG_WALNUT) += treeImage.walnut
image-$(CONFIG_TAISHAN) += cuImage.taishan
image-$(CONFIG_KATMAI) += cuImage.katmai
image-$(CONFIG_WARP) += cuImage.warp
-endif
-ifneq ($(CONFIG_REDBOOT),"")
-image-$(CONFIG_PPC_8xx) += zImage.redboot-8xx
-endif
+# Board ports in arch/powerpc/platform/8xx/Kconfig
+image-$(CONFIG_PPC_MPC86XADS) += cuImage.mpc866ads
+image-$(CONFIG_PPC_MPC885ADS) += zImage.dtb.mpc885ads
+image-$(CONFIG_PPC_EP88XC) += zImage.dtb.ep88xc
+image-$(CONFIG_PPC_ADDER875) += cuImage.adder875-uboot \
+ zImage.dtb.adder875-redboot
+
+# Board ports in arch/powerpc/platform/52xx/Kconfig
+image-$(CONFIG_PPC_LITE5200) += cuImage.lite5200 cuImage.lite5200b
+
+# Board ports in arch/powerpc/platform/82xx/Kconfig
+image-$(CONFIG_MPC8272_ADS) += cuImage.mpc8272ads
+image-$(CONFIG_PQ2FADS) += cuImage.pq2fads
+image-$(CONFIG_EP8248E) += zImage.dtb.ep8248e
+
+# Board ports in arch/powerpc/platform/83xx/Kconfig
+image-$(CONFIG_MPC8313_RDB) += cuImage.mpc8313erdb
+image-$(CONFIG_MPC832x_MDS) += cuImage.mpc832x_mds
+image-$(CONFIG_MPC832x_RDB) += cuImage.mpc832x_rdb
+image-$(CONFIG_MPC834x_ITX) += cuImage.mpc8349emitx \
+ cuImage.mpc8349emitxgp
+image-$(CONFIG_MPC834x_MDS) += cuImage.mpc834x_mds
+image-$(CONFIG_MPC836x_MDS) += cuImage.mpc836x_mds
+image-$(CONFIG_MPC837x_MDS) += cuImage.mpc8377_mds \
+ cuImage.mpc8378_mds \
+ cuImage.mpc8379_mds
+
+# Board ports in arch/powerpc/platform/85xx/Kconfig
+image-$(CONFIG_MPC8540_ADS) += cuImage.mpc8540ads
+image-$(CONFIG_MPC8560_ADS) += cuImage.mpc8560ads
+image-$(CONFIG_MPC85xx_CDS) += cuImage.mpc8541cds \
+ cuImage.mpc8548cds \
+ cuImage.mpc8555cds
+image-$(CONFIG_MPC85xx_MDS) += cuImage.mpc8568mds
+image-$(CONFIG_MPC85xx_DS) += cuImage.mpc8544ds \
+ cuImage.mpc8572ds
+image-$(CONFIG_TQM8540) += cuImage.tqm8540
+image-$(CONFIG_TQM8541) += cuImage.tqm8541
+image-$(CONFIG_TQM8555) += cuImage.tqm8555
+image-$(CONFIG_TQM8560) += cuImage.tqm8560
+image-$(CONFIG_SBC8548) += cuImage.tqm8548
+image-$(CONFIG_SBC8560) += cuImage.tqm8560
+
+# Board ports in arch/powerpc/platform/embedded6xx/Kconfig
+image-$(CONFIG_STORCENTER) += cuImage.storcenter
+image-$(CONFIG_MPC7448HPC2) += cuImage.mpc7448hpc2
# For 32-bit powermacs, build the COFF and miboot images
# as well as the ELF images.
@@ -233,24 +276,20 @@ targets += $(image-y) $(initrd-y)
$(addprefix $(obj)/, $(initrd-y)): $(obj)/ramdisk.image.gz
-# If CONFIG_WANT_DEVICE_TREE is set and CONFIG_DEVICE_TREE isn't an
-# empty string, define 'dts' to be path to the dts
-# CONFIG_DEVICE_TREE will have "" around it, make sure to strip them
-ifeq ($(CONFIG_WANT_DEVICE_TREE),y)
-ifneq ($(CONFIG_DEVICE_TREE),"")
-dts = $(if $(shell echo $(CONFIG_DEVICE_TREE) | grep '^/'),\
- ,$(srctree)/$(src)/dts/)$(CONFIG_DEVICE_TREE:"%"=%)
-endif
-endif
-
# Don't put the ramdisk on the pattern rule; when its missing make will try
# the pattern rule with less dependencies that also matches (even with the
# hard dependency listed).
-$(obj)/zImage.initrd.%: vmlinux $(wrapperbits) $(dts)
- $(call if_changed,wrap,$*,$(dts),,$(obj)/ramdisk.image.gz)
+$(obj)/zImage.initrd.dtb.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
+ $(call if_changed,wrap,$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
-$(obj)/zImage.%: vmlinux $(wrapperbits) $(dts)
- $(call if_changed,wrap,$*,$(dts))
+$(obj)/zImage.initrd.%: vmlinux $(wrapperbits)
+ $(call if_changed,wrap,$*,,,$(obj)/ramdisk.image.gz)
+
+$(obj)/zImage.dtb.%: vmlinux $(wrapperbits) $(dtstree)/%.dts
+ $(call if_changed,wrap,$*,$(dtstree)/$*.dts)
+
+$(obj)/zImage.%: vmlinux $(wrapperbits)
+ $(call if_changed,wrap,$*)
# This cannot be in the root of $(src) as the zImage rule always adds a $(obj)
# prefix
@@ -260,24 +299,17 @@ $(obj)/vmlinux.strip: vmlinux
$(obj)/zImage.iseries: vmlinux
$(STRIP) -s -R .comment $< -o $@
-$(obj)/zImage.ps3: vmlinux $(wrapper) $(wrapperbits) $(srctree)/$(src)/dts/ps3.dts
- $(STRIP) -s -R .comment $< -o vmlinux.strip
- $(call cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,)
-
-$(obj)/zImage.initrd.ps3: vmlinux $(wrapper) $(wrapperbits) $(srctree)/$(src)/dts/ps3.dts $(obj)/ramdisk.image.gz
- $(call cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,$(obj)/ramdisk.image.gz)
-
$(obj)/uImage: vmlinux $(wrapperbits)
$(call if_changed,wrap,uboot)
-$(obj)/cuImage.%: vmlinux $(dts) $(wrapperbits)
- $(call if_changed,wrap,cuboot-$*,$(dts))
+$(obj)/cuImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,cuboot-$*,$(dtstree)/$*.dts)
-$(obj)/treeImage.initrd.%: vmlinux $(dts) $(wrapperbits)
- $(call if_changed,wrap,treeboot-$*,$(dts),,$(obj)/ramdisk.image.gz)
+$(obj)/treeImage.initrd.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,treeboot-$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
-$(obj)/treeImage.%: vmlinux $(dts) $(wrapperbits)
- $(call if_changed,wrap,treeboot-$*,$(dts))
+$(obj)/treeImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,treeboot-$*,$(dtstree)/$*.dts)
# If there isn't a platform selected then just strip the vmlinux.
ifeq (,$(image-y))
@@ -286,8 +318,10 @@ endif
$(obj)/zImage: $(addprefix $(obj)/, $(image-y))
@rm -f $@; ln $< $@
+ @echo target images: $(image-y)
$(obj)/zImage.initrd: $(addprefix $(obj)/, $(initrd-y))
@rm -f $@; ln $< $@
+ @echo target images: $(initrd-y)
install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux System.map "$(INSTALL_PATH)" $<
diff --git a/arch/powerpc/boot/cuboot-hpc2.c b/arch/powerpc/boot/cuboot-hpc2.c
deleted file mode 100644
index 1b89532..0000000
--- a/arch/powerpc/boot/cuboot-hpc2.c
+++ /dev/null
@@ -1,48 +0,0 @@
-/*
- * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
- *
- * Author: Roy Zang <tie-fei.zang@freescale.com>
- *
- * Description:
- * Old U-boot compatibility for mpc7448hpc2 board
- * Based on the code of Scott Wood <scottwood@freescale.com>
- * for 83xx and 85xx.
- *
- * This 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.
- *
- */
-
-#include "ops.h"
-#include "stdio.h"
-#include "cuboot.h"
-
-#define TARGET_HAS_ETH1
-#include "ppcboot.h"
-
-static bd_t bd;
-extern char _dtb_start[], _dtb_end[];
-
-static void platform_fixups(void)
-{
- void *tsi;
-
- dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
- dt_fixup_mac_addresses(bd.bi_enetaddr, bd.bi_enet1addr);
- dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
- tsi = find_node_by_devtype(NULL, "tsi-bridge");
- if (tsi)
- setprop(tsi, "bus-frequency", &bd.bi_busfreq,
- sizeof(bd.bi_busfreq));
-}
-
-void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
- unsigned long r6, unsigned long r7)
-{
- CUBOOT_INIT();
- fdt_init(_dtb_start);
- serial_console_init();
- platform_ops.fixups = platform_fixups;
-}
diff --git a/arch/powerpc/boot/cuboot-mpc7448hpc2.c b/arch/powerpc/boot/cuboot-mpc7448hpc2.c
new file mode 100644
index 0000000..1b89532
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-mpc7448hpc2.c
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Roy Zang <tie-fei.zang@freescale.com>
+ *
+ * Description:
+ * Old U-boot compatibility for mpc7448hpc2 board
+ * Based on the code of Scott Wood <scottwood@freescale.com>
+ * for 83xx and 85xx.
+ *
+ * This 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.
+ *
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "cuboot.h"
+
+#define TARGET_HAS_ETH1
+#include "ppcboot.h"
+
+static bd_t bd;
+extern char _dtb_start[], _dtb_end[];
+
+static void platform_fixups(void)
+{
+ void *tsi;
+
+ dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+ dt_fixup_mac_addresses(bd.bi_enetaddr, bd.bi_enet1addr);
+ dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
+ tsi = find_node_by_devtype(NULL, "tsi-bridge");
+ if (tsi)
+ setprop(tsi, "bus-frequency", &bd.bi_busfreq,
+ sizeof(bd.bi_busfreq));
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+ fdt_init(_dtb_start);
+ serial_console_init();
+ platform_ops.fixups = platform_fixups;
+}
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 763a0c4..c317815 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -158,6 +158,29 @@ miboot|uboot)
cuboot*)
binary=y
gzip=
+ case "$platform" in
+ *-mpc885ads|*-adder875*|*-ep88xc)
+ platformo=$object/cuboot-8xx.o
+ ;;
+ *5200*|*-motionpro)
+ platformo=$object/cuboot-52xx.o
+ ;;
+ *-pq2fads|*-ep8248e|*-mpc8272*|*-storcenter)
+ platformo=$object/cuboot-pq2.o
+ ;;
+ *-mpc824*)
+ platformo=$object/cuboot-824x.o
+ ;;
+ *-mpc83*)
+ platformo=$object/cuboot-83xx.o
+ ;;
+ *-tqm8541|*-mpc8560*|*-tqm8560|*-tqm8555*)
+ platformo=$object/cuboot-85xx-cpm2.o
+ ;;
+ *-mpc85*)
+ platformo=$object/cuboot-85xx.o
+ ;;
+ esac
;;
ps3)
platformo="$object/ps3-head.o $object/ps3-hvcall.o $object/ps3.o"
^ permalink raw reply related
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