* [PATCH] Save NVGPRS in 32-bit signal frame
From: David Woodhouse @ 2005-11-24 12:51 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Somehow this one slipped through the cracks; when we ended up in
do_signal() on a 32-bit kernel but without having the caller-saved
registers into the regs, we didn't set the TIF_SAVE_NVGPRS flag to
ensure they got saved later.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -219,6 +218,15 @@ static inline int get_old_sigaction(stru
static inline int save_general_regs(struct pt_regs *regs,
struct mcontext __user *frame)
{
+ if (!FULL_REGS(regs)) {
+ /* Zero out the unsaved GPRs to avoid information
+ leak, and set TIF_SAVE_NVGPRS to ensure that the
+ registers do actually get saved later. */
+ memset(®s->gpr[14], 0, 18 * sizeof(unsigned long));
+ current_thread_info()->nvgprs_frame = &frame->mc_gregs;
+ set_thread_flag(TIF_SAVE_NVGPRS);
+ }
+
return __copy_to_user(&frame->mc_gregs, regs, GP_REGS_SIZE);
}
--
dwmw2
^ permalink raw reply
* Re: 8260ADS Ethernet compilation
From: Wolfgang Denk @ 2005-11-24 11:28 UTC (permalink / raw)
To: pritha.bhattacharya; +Cc: linuxppc-embedded
In-Reply-To: <OF8DE1E835.620AF9B1-ON652570C3.001D9C79-652570C3.003087C6@tcs.com>
In message <OF8DE1E835.620AF9B1-ON652570C3.001D9C79-652570C3.003087C6@tcs.com> you wrote:
>
> I have a custom board built around MPC8260ADS. I am trying to cross
I understand that this means you also use a custom board
configuration, right?
> m8260_setup.c:62: error: `bd_t' undeclared here (not in a function)
...
> m8260_setup.c:120: error: `binfo' undeclared (first use in this function)
...
> m8260_setup.c:229: error: `NR_SIU_INTS' undeclared (first use in this
> function)
Seems your port and/or board configuration is incomplete / broken.
> 1.I understand that bd_t is a board information structure. Which is
> defined in linux/include/asm-ppc/ppcboot.h. Somehow it is not visible to
> the linux/arch/kernel/m8260_setup.c I dont know what I may be doing
> wrong.
Bad configuration...
> 2.Similarly NR_SIU_INTS, which is defined in linux/include/asm/irq.h is
> also not visible.
Bad configuration...
> 3.I did not understand what __res[ ] is. I came across somewhere that it
> is the residual information which the bootloader is supposed to hand over
> to the linux. How would that be done. I could not identify in the code
> where __res is populated.
Use "grep"; __res points to the board information structure.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"The more data I punch in this card, the lighter it becomes, and the
lower the mailing cost."
- Stan Kelly-Bootle, "The Devil's DP Dictionary"
^ permalink raw reply
* RE: [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
From: Clement Fabien @ 2005-11-24 11:25 UTC (permalink / raw)
To: Pantelis Antoniou, Kumar Gala, Marcelo Tosatti, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 400 bytes --]
Here is a patch that builds.
-----Original Message-----
From: Pantelis Antoniou [mailto:panto@intracom.gr]
Sent: jeudi 24 novembre 2005 12:04
To: Clement Fabien; Kumar Gala; Marcelo Tosatti; linuxppc-embedded
Subject: [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
Hi all.
Alignments are currently handled bogusly for cpm2.
Please test.
Regards
Pantelis
[-- Attachment #2: cpm2-dpalloc_compiling.patch --]
[-- Type: application/octet-stream, Size: 2340 bytes --]
? arch/ppc/lib/.built-in.o.cmd
? arch/ppc/lib/.checksum.o.cmd
? arch/ppc/lib/.dec_and_lock.o.cmd
? arch/ppc/lib/.div64.o.cmd
? arch/ppc/lib/.rheap.o.cmd
? arch/ppc/lib/.strcase.o.cmd
? arch/ppc/lib/.string.o.cmd
? arch/ppc/lib/myrheap.c
? arch/ppc/lib/rheap.diff
? arch/ppc/lib/rheap_debug.c
Index: arch/ppc/lib/rheap.c
===================================================================
RCS file: /home/conf/tnp/linuxppc/linux/arch/ppc/lib/rheap.c,v
retrieving revision 1.1.1.1
diff -b -u -r1.1.1.1 rheap.c
--- arch/ppc/lib/rheap.c 6 Dec 2004 16:15:22 -0000 1.1.1.1
+++ arch/ppc/lib/rheap.c 24 Nov 2005 11:24:41 -0000
@@ -425,17 +425,22 @@
return (void *)s;
}
-void *rh_alloc(rh_info_t * info, int size, const char *owner)
+void *rh_alloc_align(rh_info_t * info, int size, int alignment, const char *owner)
{
struct list_head *l;
rh_block_t *blk;
rh_block_t *newblk;
void *start;
- /* Validate size */
- if (size <= 0)
+ /* Validate size, (must be power of two) */
+ printk(KERN_INFO"rh_alloc - Required size = %04X, align = %04X\n",size,alignment);
+ if (size <= 0 || (alignment & (alignment - 1)) != 0)
return ERR_PTR(-EINVAL);
+ /* given alignment larger that default rheap alignment */
+ if (alignment > info->alignment)
+ size += alignment - 1;
+
/* Align to configured alignment */
size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
@@ -453,6 +458,8 @@
if (blk == NULL)
return ERR_PTR(-ENOMEM);
+ printk(KERN_INFO"rh_alloc - Block size = %04X, start = %p\n",blk->size,blk->start);
+
/* Just fits */
if (blk->size == size) {
/* Move from free list to taken list */
@@ -478,9 +485,23 @@
attach_taken_block(info, newblk);
+ /* for larger alignment return fixed up pointer */
+ /* this is no problem with the deallocator since */
+ /* we scan for pointers that lie in the blocks */
+ if (alignment > info->alignment)
+ start = (void *)(((unsigned long)start + alignment - 1) &
+ ~(alignment - 1));
+
+ printk(KERN_INFO"rh_alloc - Alloc size = %04X, start = %p\n",size,start);
+
return start;
}
+void *rh_alloc(rh_info_t * info, int size, const char *owner)
+{
+ return rh_alloc_align(info, size, info->alignment, owner);
+}
+
/* allocate at precisely the given address */
void *rh_alloc_fixed(rh_info_t * info, void *start, int size, const char *owner)
{
^ permalink raw reply
* Re: [PATCH] I2C: Add I2C support for the MPC8260
From: Christoph Hellwig @ 2005-11-24 11:17 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev, lm-sensors
In-Reply-To: <AHEILKONAKAEJPHNMOPNEEMNCDAA.hs@denx.de>
> + * Release 0.1
please don't put such versaison comments in, the SCM has the history.
> +#include <linux/config.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/sched.h>
> +#include <linux/init.h>
> +#include <linux/pci.h>
> +#include <asm/io.h>
> +#include <linux/fsl_devices.h>
> +#include <linux/i2c.h>
> +#include <linux/interrupt.h>
> +#include <linux/delay.h>
> +#include <asm/immap_cpm2.h>
> +#include <asm/mpc8260.h>
> +#include <asm/cpm2.h>
> +
> +#include <linux/i2c-algo-cpm2.h>
> +#include <linux/platform_device.h>
<asm/*.h> always after <linux/*.h> please.
> +#define CPM_MAX_READ 513
> +
> +static wait_queue_head_t iic_wait;
> +static ushort r_tbase, r_rbase;
> +
> +int cpm_scan = 0;
> +int cpm_debug = 0;
> +
> +struct mpc_i2c {
> + u32 interrupt;
> + wait_queue_head_t queue;
> + struct i2c_adapter adap;
> + int irq;
> + u32 flags;
> + struct i2c_algo_cpm2_data *data;
> +};
> +
> +static struct i2c_algo_cpm2_data cpm2_data;
> +
> +static void
> +cpm2_iic_init(struct i2c_algo_cpm2_data *data)
> +{
> + volatile cpm_cpm2_t *cp;
> + volatile cpm2_map_t *immap;
> +
> + cp = cpmp; /* Get pointer to Communication Processor */
> + immap = (cpm2_map_t *)CPM_MAP_ADDR; /* and to internal registers */
> +
> + *(ushort *)(&immap->im_dprambase[PROFF_I2C_BASE]) = PROFF_I2C;
> + data->iip = (iic_t *)&immap->im_dprambase[PROFF_I2C];
Please stop volatile abuse and use ioremap & friends to properly to access
I/O memory.
> + /* Chip bug, set enable here */
> + local_irq_save(flags);
> + i2c->i2c_i2cmr = 0x13; /* Enable some interupts */
> + i2c->i2c_i2cer = 0xff;
> + i2c->i2c_i2mod |= 1; /* Enable */
> + i2c->i2c_i2com = 0x81; /* Start master */
> +
> + /* Wait for IIC transfer */
> + interruptible_sleep_on(&iic_wait);
never use interruptible_sleep_on() and the local_irq_save usage here is
bogus aswell, please use proper irq disabling spinlocks and make sure
you don't sleep with interrupts disabled.
> + if (cpm_debug) {
> + int u;
> + for (u = 0; u < count; u++) {
> + printk(KERN_DEBUG "buf[%d] = 0x%x\n", u, buf[u]);
> + }
> + }
broken indentation.
> + if (cpm_debug)
> + printk(KERN_DEBUG "i2c-cpm2.o: wrote %d\n", ret);
could you please use dev_dbg() instead of all this if (cpm_debug) mess?
> + if (ret < pmsg->len ) {
> + return (ret<0) ? ret : -EREMOTEIO;
indentation problems again.
> + int result = 0;
> + struct mpc_i2c *i2c;
> + struct platform_device *pdev = to_platform_device(device);
> + struct fsl_i2c_platform_data *pdata;
> +
> + pdata = (struct fsl_i2c_platform_data *) pdev->dev.platform_data;
generally no need to cast here. Also please use platform_get_drvdata()
> +
> + if (!(i2c = kmalloc(sizeof(*i2c), GFP_KERNEL))) {
> + return -ENOMEM;
> + }
> + memset(i2c, 0, sizeof(*i2c));
please use kzalloc()
> + if ((result = i2c_add_adapter(&i2c->adap)) < 0) {
please split such lines into two.
> + fail_add:
goto lables should either be in column 0 or 1 (and that consitantly
through a source file)
^ permalink raw reply
* [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
From: Pantelis Antoniou @ 2005-11-24 11:03 UTC (permalink / raw)
To: Clement Fabien, Kumar Gala, Marcelo Tosatti, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 94 bytes --]
Hi all.
Alignments are currently handled bogusly for cpm2.
Please test.
Regards
Pantelis
[-- Attachment #2: cpm2-dpalloc.patch --]
[-- Type: text/x-patch, Size: 4155 bytes --]
diff --git a/arch/ppc/lib/rheap.c b/arch/ppc/lib/rheap.c
--- a/arch/ppc/lib/rheap.c
+++ b/arch/ppc/lib/rheap.c
@@ -425,17 +425,21 @@ void *rh_detach_region(rh_info_t * info,
return (void *)s;
}
-void *rh_alloc(rh_info_t * info, int size, const char *owner)
+void *rh_alloc(rh_info_t * info, int size, int alignment, const char *owner)
{
struct list_head *l;
rh_block_t *blk;
rh_block_t *newblk;
void *start;
- /* Validate size */
- if (size <= 0)
+ /* Validate size, (must be power of two) */
+ if (size <= 0 || (alignment & (alignment - 1)) != 0)
return ERR_PTR(-EINVAL);
+ /* given alignment larger that default rheap alignment */
+ if (alignment > info->alignment)
+ size += alignement - 1;
+
/* Align to configured alignment */
size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
@@ -478,9 +482,21 @@ void *rh_alloc(rh_info_t * info, int siz
attach_taken_block(info, newblk);
+ /* for larger alignment return fixed up pointer */
+ /* this is no problem with the deallocator since */
+ /* we scan for pointers that lie in the blocks */
+ if (alignment > info->alignment)
+ start = (void *)(((unsigned long)start + alignment - 1) &
+ ~(alignment - 1));
+
return start;
}
+void *rh_alloc(rh_info_t * info, int size, const char *owner)
+{
+ return rh_alloc_align(info, size, info->alignment, owner);
+}
+
/* allocate at precisely the given address */
void *rh_alloc_fixed(rh_info_t * info, void *start, int size, const char *owner)
{
diff --git a/arch/ppc/syslib/cpm2_common.c b/arch/ppc/syslib/cpm2_common.c
--- a/arch/ppc/syslib/cpm2_common.c
+++ b/arch/ppc/syslib/cpm2_common.c
@@ -148,8 +148,7 @@ uint cpm_dpalloc(uint size, uint align)
unsigned long flags;
spin_lock_irqsave(&cpm_dpmem_lock, flags);
- cpm_dpmem_info.alignment = align;
- start = rh_alloc(&cpm_dpmem_info, size, "commproc");
+ start = rh_alloc_align(&cpm_dpmem_info, size, align, "commproc");
spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
return (uint)start;
@@ -170,13 +169,12 @@ int cpm_dpfree(uint offset)
EXPORT_SYMBOL(cpm_dpfree);
/* not sure if this is ever needed */
-uint cpm_dpalloc_fixed(uint offset, uint size, uint align)
+uint cpm_dpalloc_fixed(uint offset, uint size)
{
void *start;
unsigned long flags;
spin_lock_irqsave(&cpm_dpmem_lock, flags);
- cpm_dpmem_info.alignment = align;
start = rh_alloc_fixed(&cpm_dpmem_info, (void *)offset, size, "commproc");
spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
diff --git a/include/asm-ppc/commproc.h b/include/asm-ppc/commproc.h
--- a/include/asm-ppc/commproc.h
+++ b/include/asm-ppc/commproc.h
@@ -74,7 +74,7 @@ static inline long IS_DPERR(const uint o
extern cpm8xx_t *cpmp; /* Pointer to comm processor */
extern uint cpm_dpalloc(uint size, uint align);
extern int cpm_dpfree(uint offset);
-extern uint cpm_dpalloc_fixed(uint offset, uint size, uint align);
+extern uint cpm_dpalloc_fixed(uint offset, uint size);
extern void cpm_dpdump(void);
extern void *cpm_dpram_addr(uint offset);
extern void cpm_setbrg(uint brg, uint rate);
diff --git a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
--- a/include/asm-ppc/cpm2.h
+++ b/include/asm-ppc/cpm2.h
@@ -112,7 +112,7 @@ extern cpm_cpm2_t *cpmp; /* Pointer to
extern uint cpm_dpalloc(uint size, uint align);
extern int cpm_dpfree(uint offset);
-extern uint cpm_dpalloc_fixed(uint offset, uint size, uint align);
+extern uint cpm_dpalloc_fixed(uint offset, uint size);
extern void cpm_dpdump(void);
extern void *cpm_dpram_addr(uint offset);
extern void cpm_setbrg(uint brg, uint rate);
diff --git a/include/asm-ppc/rheap.h b/include/asm-ppc/rheap.h
--- a/include/asm-ppc/rheap.h
+++ b/include/asm-ppc/rheap.h
@@ -62,6 +62,10 @@ extern int rh_attach_region(rh_info_t *
/* Detach a free region */
extern void *rh_detach_region(rh_info_t * info, void *start, int size);
+/* Allocate the given size from the remote heap (with alignment) */
+extern void *rh_alloc_align(rh_info_t * info, int size, int alignment,
+ const char *owner);
+
/* Allocate the given size from the remote heap */
extern void *rh_alloc(rh_info_t * info, int size, const char *owner);
^ permalink raw reply
* 8260ADS Ethernet compilation
From: pritha.bhattacharya @ 2005-11-24 8:50 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3244 bytes --]
Hi,
I have a custom board built around MPC8260ADS. I am trying to cross
compile linux 2.4.25 for ethernet on FCC1 connected to LXT971 for the
board.
Installed the toolchains from Denx site. Built linux for ppc architecture.
Then for ethernet, after selecting the proper options from the menuconfig,
while compiling the source code gives the following error:
m8260_setup.c:62: error: `bd_t' undeclared here (not in a function)
m8260_setup.c:106: warning: `abort' was declared `extern' and later
`static'
m8260_setup.c: In function `m8260_calibrate_decr':
m8260_setup.c:120: error: `bd_t' undeclared (first use in this function)
m8260_setup.c:120: error: (Each undeclared identifier is reported only
once
m8260_setup.c:120: error: for each function it appears in.)
m8260_setup.c:120: error: `binfo' undeclared (first use in this function)
m8260_setup.c:120: error: parse error before ')' token
m8260_setup.c: In function `m8260_restart':
m8260_setup.c:163: error: parse error before '*' token
m8260_setup.c:163: warning: function declaration isn't a prototype
m8260_setup.c: In function `m8260_show_percpuinfo':
m8260_setup.c:201: error: `bd_t' undeclared (first use in this function)
m8260_setup.c:201: error: `bp' undeclared (first use in this function)
m8260_setup.c:203: error: parse error before ')' token
m8260_setup.c: In function `m8260_init_IRQ':
m8260_setup.c:229: error: `NR_SIU_INTS' undeclared (first use in this
function)
m8260_setup.c: In function `m8260_find_end_of_memory':
m8260_setup.c:261: error: `bd_t' undeclared (first use in this function)
m8260_setup.c:261: error: `binfo' undeclared (first use in this function)
m8260_setup.c:264: error: parse error before ')' token
m8260_setup.c:262: warning: unused variable `__res'
m8260_setup.c: In function `platform_init':
m8260_setup.c:288: error: `bd_t' undeclared (first use in this function)
m8260_setup.c: At top level:
m8260_setup.c:106: warning: `abort' defined but not used
make[1]: *** [m8260_setup.o] Error 1
make: *** [_dir_arch/ppc/kernel] Error 2
1.I understand that bd_t is a board information structure. Which is
defined in linux/include/asm-ppc/ppcboot.h. Somehow it is not visible to
the linux/arch/kernel/m8260_setup.c I dont know what I may be doing
wrong.
2.Similarly NR_SIU_INTS, which is defined in linux/include/asm/irq.h is
also not visible.
the third query is not on compilation errors:
3.I did not understand what __res[ ] is. I came across somewhere that it
is the residual information which the bootloader is supposed to hand over
to the linux. How would that be done. I could not identify in the code
where __res is populated.
Would be of great help to get your suggestions.
Thanks & Regards
Pritha
Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
[-- Attachment #2: Type: text/html, Size: 4917 bytes --]
^ permalink raw reply
* Re: [Patch] CPM allocation mechanism in 2.6.13
From: Pantelis Antoniou @ 2005-11-24 10:25 UTC (permalink / raw)
To: Clement Fabien; +Cc: linuxppc-embedded
In-Reply-To: <9C1918067C3BC14C9C351C206D8A843701F54B1A@rennsmail03.eu.thmulti.com>
Clement Fabien wrote:
> Hello
>
> I found out that the rh_alloc mechanism used in 2.6.xx does not always
> provide aligned blocks.
> I'm using a 8275 and try to start the SAR driver of Alex Zeffert.
>
> Here is a trace of allocations at linux startup of the code that gives
> me problems:
>
> <...>
> rh_alloc Required size = 8, align = 16
> rh_alloc Block available, blk->size = 00003f40 - Start = 000000c0
> rh_alloc Alloc size = 16, align = 16 - Start = 000000c0
>
> rh_alloc Required size = 6144, align = 32
> rh_alloc Block available, blk->size = 00003f30 - Start = 000000d0
> rh_alloc Alloc size = 6144, align = 32 - Start = 000000d0
> (!!!! WRONG ALIGNMENT !!!!)
>
> rh_alloc Required size = 264, align = 64
> rh_alloc Block available, blk->size = 00002730 - Start = 000018d0
> rh_alloc Alloc size = 320, align = 64 - Start = 000018d0
> (!!!! WRONG ALIGNMENT !!!!)
>
> rh_alloc Required size = 64, align = 16
> rh_alloc Block available, blk->size = 000025f0 - Start = 00001a10
> rh_alloc Alloc size = 64, align = 16 - Start = 00001a10
> <...>
>
> If we observe rh_alloc (arch/ppc/lib/rheap.c) function
>
> The following line only ensures that there is enough space to perform
> alignment:
> 1. size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
>
> But with the block start modification mechanism you cannot ensure that
> the next block will be aligned :
> 2. blk->start = (int8_t *)blk->start + size;
>
> The allocation mechanism must take into account the starting address, as
> it was in Linux 2.4 following code (3. extracted from commproc.c)
> 3. off = ((p->start_addr + align_mask) & (~align_mask)) -
> p->start_addr;
>
> I've had an initial discussion with Pantelis who suggests that alignment
> shall be unique for this heap:
>
>
>>>Excuse me, how do you modify the rheap's alignment at runtime?
>>>The allocators prototype is:
>
>
>>>void *rh_alloc(rh_info_t * info, int size, const char *owner)
>
>
>>>I don't see an alignment parameter.
>
>
>>>If you are modifying info->alignment by hand before calling you can't
>
>
>>>possibly expect this to work.
>
>
>>>The alignment is fixed after the creation of the rheap.
>>>If you need specific alignment you do it like this.
>
>
>>>u8 *p = rh_alloc(info, size + (align - 1), "owner");
>
>
>>>p = (void *)((unsigned long)p + (align - 1) & ~(align - 1));
>
>
> So I guess the problem is in the usage of the function in kernel: it is
> initialized with 1 byte alignment (in cpm2_dpinit in
> arch/ppc/syslib/cpm2_common.c), then the cpm_dpalloc manipulates the
> alignment like this:
>
> 4. cpm_dpmem_info.alignment = align;
> start = rh_alloc(&cpm_dpmem_info, size, "commproc");
>
>
> I do not have an exact idea whether to modify cpm_dpalloc or rh_alloc.
> Can someone provide inputs on this subject?
>
> Please see also the patch I suggest to correct the rh_alloc function
>
> Regards
> Fabien Clement
>
I'm on it.
Regards
Pantelis
^ permalink raw reply
* Re: USB Keyboard Support
From: David Jander @ 2005-11-24 10:30 UTC (permalink / raw)
To: Igor Luri; +Cc: linuxppc-embedded
In-Reply-To: <43858855.8080304@fagorautomation.es>
On Thursday 24 November 2005 10:31, Igor Luri wrote:
> the first console argument defines where is stdout and the second
> console argument defines where is the stdout and stdin. With this
> configuration you can duplicate stdout, you can see the output on two
> devices, screen and serial line.
Wow. Everyday we learn something new ;-)
Sorry, and thanks for the tip!
Greetings,
--
David Jander
^ permalink raw reply
* [Patch] CPM allocation mechanism in 2.6.13
From: Clement Fabien @ 2005-11-24 10:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2819 bytes --]
Hello
I found out that the rh_alloc mechanism used in 2.6.xx does not always
provide aligned blocks.
I'm using a 8275 and try to start the SAR driver of Alex Zeffert.
Here is a trace of allocations at linux startup of the code that gives
me problems:
<...>
rh_alloc Required size = 8, align = 16
rh_alloc Block available, blk->size = 00003f40 - Start = 000000c0
rh_alloc Alloc size = 16, align = 16 - Start = 000000c0
rh_alloc Required size = 6144, align = 32
rh_alloc Block available, blk->size = 00003f30 - Start = 000000d0
rh_alloc Alloc size = 6144, align = 32 - Start = 000000d0
(!!!! WRONG ALIGNMENT !!!!)
rh_alloc Required size = 264, align = 64
rh_alloc Block available, blk->size = 00002730 - Start = 000018d0
rh_alloc Alloc size = 320, align = 64 - Start = 000018d0
(!!!! WRONG ALIGNMENT !!!!)
rh_alloc Required size = 64, align = 16
rh_alloc Block available, blk->size = 000025f0 - Start = 00001a10
rh_alloc Alloc size = 64, align = 16 - Start = 00001a10
<...>
If we observe rh_alloc (arch/ppc/lib/rheap.c) function
The following line only ensures that there is enough space to perform
alignment:
1. size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
But with the block start modification mechanism you cannot ensure that
the next block will be aligned :
2. blk->start = (int8_t *)blk->start + size;
The allocation mechanism must take into account the starting address, as
it was in Linux 2.4 following code (3. extracted from commproc.c)
3. off = ((p->start_addr + align_mask) & (~align_mask)) -
p->start_addr;
I've had an initial discussion with Pantelis who suggests that alignment
shall be unique for this heap:
>> Excuse me, how do you modify the rheap's alignment at runtime?
>> The allocators prototype is:
>> void *rh_alloc(rh_info_t * info, int size, const char *owner)
>> I don't see an alignment parameter.
>> If you are modifying info->alignment by hand before calling you can't
>> possibly expect this to work.
>> The alignment is fixed after the creation of the rheap.
>> If you need specific alignment you do it like this.
>> u8 *p = rh_alloc(info, size + (align - 1), "owner");
>> p = (void *)((unsigned long)p + (align - 1) & ~(align - 1));
So I guess the problem is in the usage of the function in kernel: it is
initialized with 1 byte alignment (in cpm2_dpinit in
arch/ppc/syslib/cpm2_common.c), then the cpm_dpalloc manipulates the
alignment like this:
4. cpm_dpmem_info.alignment = align;
start = rh_alloc(&cpm_dpmem_info, size, "commproc");
I do not have an exact idea whether to modify cpm_dpalloc or rh_alloc.
Can someone provide inputs on this subject?
Please see also the patch I suggest to correct the rh_alloc function
Regards
Fabien Clement
[-- Attachment #2: rheap.patch --]
[-- Type: application/octet-stream, Size: 1863 bytes --]
Index: arch/ppc/lib/rheap.c
===================================================================
RCS file: /home/conf/tnp/linuxppc/linux/arch/ppc/lib/rheap.c,v
retrieving revision 1.1.1.1
diff -b -u -r1.1.1.1 rheap.c
--- arch/ppc/lib/rheap.c 6 Dec 2004 16:15:22 -0000 1.1.1.1
+++ arch/ppc/lib/rheap.c 24 Nov 2005 09:42:37 -0000
@@ -431,13 +431,15 @@
rh_block_t *blk;
rh_block_t *newblk;
void *start;
+ unsigned int off;
+ unsigned int align_mask = (info->alignment - 1);
/* Validate size */
if (size <= 0)
return ERR_PTR(-EINVAL);
/* Align to configured alignment */
- size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
+ size = (size + align_mask) & (~align_mask);
if (assure_empty(info, 1) < 0)
return ERR_PTR(-ENOMEM);
@@ -446,7 +448,11 @@
list_for_each(l, &info->free_list) {
blk = list_entry(l, rh_block_t, list);
if (size <= blk->size)
+ {
+ off = ((int)(blk->start + align_mask) & (~align_mask)) - (int)blk->start;
+ if (blk->size >= size + off)
break;
+ }
blk = NULL;
}
@@ -454,7 +460,7 @@
return ERR_PTR(-ENOMEM);
/* Just fits */
- if (blk->size == size) {
+ if (blk->size == (size + off)) {
/* Move from free list to taken list */
list_del(&blk->list);
blk->owner = owner;
@@ -462,21 +468,23 @@
attach_taken_block(info, blk);
- return start;
}
-
+ else
+ {
newblk = get_slot(info);
newblk->start = blk->start;
- newblk->size = size;
+ newblk->size = size + off;
newblk->owner = owner;
/* blk still in free list, with updated start, size */
- blk->start = (int8_t *)blk->start + size;
- blk->size -= size;
+ blk->start = (int8_t *)blk->start + size + off;
+ blk->size -= (size + off);
- start = newblk->start;
+ start = newblk->start + off;
attach_taken_block(info, newblk);
+ }
+
return start;
}
^ permalink raw reply
* Re: USB Keyboard Support
From: Igor Luri @ 2005-11-24 9:31 UTC (permalink / raw)
To: David Jander, linuxppc-embedded
In-Reply-To: <200511240925.21942.david.jander@protonic.nl>
David Jander wrote:
>>root=/dev/nfs rw ip=on console=tty console=ttyS0 init=/sbin/init
>>
>>
>
>I suppose putting two "console=" statements on the commandline doesn't do much
>more than just removing the first one.
>
>Greetings,
>
>
>
Dear David,
the first console argument defines where is stdout and the second
console argument defines where is the stdout and stdin. With this
configuration you can duplicate stdout, you can see the output on two
devices, screen and serial line.
Bye.
^ permalink raw reply
* Re: USB Keyboard Support
From: David Jander @ 2005-11-24 8:25 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4384921A.8010901@fagorautomation.es>
> root=/dev/nfs rw ip=on console=tty console=ttyS0 init=/sbin/init
I suppose putting two "console=" statements on the commandline doesn't do much
more than just removing the first one.
Greetings,
--
David Jander
^ permalink raw reply
* [PATCH] powerpc: Fix g5 build with xmon
From: Benjamin Herrenschmidt @ 2005-11-24 6:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, linuxppc-dev list
My previous patches inadvertently broke building a G5 kernel with
CONFIG_XMON enabled. This fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-serialfix/arch/powerpc/platforms/powermac/pic.c
===================================================================
--- linux-serialfix.orig/arch/powerpc/platforms/powermac/pic.c 2005-11-24 17:21:41.000000000 +1100
+++ linux-serialfix/arch/powerpc/platforms/powermac/pic.c 2005-11-24 17:36:07.000000000 +1100
@@ -459,7 +459,7 @@ void __init pmac_pic_init(void)
mpic_setup_cascade(irqctrler2->intrs[0].line,
pmac_u3_cascade, mpic2);
}
-#ifdef CONFIG_XMON
+#if defined(CONFIG_XMON) && defined(CONFIG_PPC32)
{
struct device_node* pswitch;
int nmi_irq;
@@ -471,7 +471,7 @@ void __init pmac_pic_init(void)
setup_irq(nmi_irq, &xmon_action);
}
}
-#endif /* CONFIG_XMON */
+#endif /* defined(CONFIG_XMON) && defined(CONFIG_PPC32) */
return;
}
irqctrler = NULL;
^ permalink raw reply
* Re: [PATCH] Fix USB suspend/resume crasher
From: Benjamin Herrenschmidt @ 2005-11-24 1:23 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Andrew Morton, Greg KH, linux-kernel, David Brownell,
linuxppc-dev list, Alan Stern
In-Reply-To: <200511240122.46125.rjw@sisk.pl>
> Unfortunately with this patch the EHCI controller in my box (Asus L5D,
> x86-64 kernel) does not resume from suspend. Appended is the relevant
> snippet from the serial console log (EHCI is the only device using IRQ #5).
Hrm... let me see... You are getting an interrupt for EHCI after it has
been resumed, so it should work.
/me double-checks the patch
> ehci_hcd 0000:00:02.2: lost power, restarting
Hrm... I can't find that line in the code...
/me rechecks with david's other patches
Ah ... I see it. There might have been some screwup between david's
patch and mine.
Make sure that
set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
Is still done before anything else in ehci_pci_resume(). It may be worth
following it with a memory barrier actually... just in case (due to the
absence of locks in that area).
Ben.
^ permalink raw reply
* Re: [PATCH] Fix USB suspend/resume crasher
From: Rafael J. Wysocki @ 2005-11-24 0:22 UTC (permalink / raw)
To: linux-kernel
Cc: Andrew Morton, David Brownell, linuxppc-dev list, Greg KH,
Alan Stern
In-Reply-To: <1132715288.26560.262.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 5195 bytes --]
Hi,
On Wednesday, 23 of November 2005 04:08, Benjamin Herrenschmidt wrote:
> This is my latest patch against current linus -git, it closes the IRQ
> race and makes various other OHCI & EHCI code path safer vs.
> suspend/resume. I've been able to (finally !) successfully suspend and
> resume various Mac models, with or without USB mouse plugged, or
> plugging while asleep, or unplugging while asleep etc... all without a
> crash. There are still some races here or there in the USB code, but at
> least the main cause of crash is now fixes by this patch (access to a
> controller that has been suspended, due to either shared interrupts or
> other code path).
>
> I haven't fixed UHCI as I don't have any HW to test, though I hope I
> haven't broken it neither. Alan, I would appreciate if you could have a
> look.
>
> This patch applies on top of the patch that moves the PowerMac specific
> code out of ohci-pci.c to hcd-pci.c where it belongs. This patch isn't
> upstream yet for reasons I don't fully understand (why does USB stuffs
> has such a high latency for going upstream ?), I'm sending it as a reply
> to this email for completeness.
>
> Without this patch, you cannot reliably sleep/wakeup any recent Mac, and
> I suspect PCs have some more sneaky issues too (they don't frankly crash
> with machine checks because x86 tend to silently swallow PCI errors but
> that won't last afaik, at least PCI Express will blow up in those
> situations, but the USB code may still misbehave).
Unfortunately with this patch the EHCI controller in my box (Asus L5D,
x86-64 kernel) does not resume from suspend. Appended is the relevant
snippet from the serial console log (EHCI is the only device using IRQ #5).
Greetings,
Rafael
PM: Image restored successfully.
ohci_hcd 0000:00:02.0: PCI D0, from previous PCI D3
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LUS0] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:02.0 to 64
ohci_hcd 0000:00:02.1: PCI D0, from previous PCI D3
ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [LUS1] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:02.1 to 64
ehci_hcd 0000:00:02.2: PCI D0, from previous PCI D3
ACPI: PCI Interrupt 0000:00:02.2[C] -> Link [LUS2] -> GSI 5 (level, low) -> IRQ 5
PCI: Setting latency timer of device 0000:00:02.2 to 64
ehci_hcd 0000:00:02.2: lost power, restarting
usb usb3: root hub lost power or was reset
ehci_hcd 0000:00:02.2: reset command 080b02 park=3 ithresh=8 period=1024 Reset HALT
ehci_hcd 0000:00:02.2: debug port 1
ehci_hcd 0000:00:02.2: capability 1000001 at a0
PCI: cache line size of 64 is not supported by device 0000:00:02.2
ehci_hcd 0000:00:02.2: reset command 080b02 park=3 ithresh=8 period=1024 Reset HALT
ehci_hcd 0000:00:02.2: init command 010009 (park)=0 ithresh=1 period=256 RUN
ehci_hcd 0000:00:02.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [LAUI] -> GSI 10 (level, low) -> IRQ 10
PCI: Setting latency timer of device 0000:00:06.0 to 64
irq 5: nobody cared (try booting with the "irqpoll" option)
Call Trace: <IRQ> <ffffffff80250c3e>{add_preempt_count+94} <ffffffff8015a878>{__report_bad_irq+56}
<ffffffff8015aab4>{note_interrupt+484} <ffffffff8015a317>{__do_IRQ+199}
<ffffffff801110f7>{do_IRQ+55} <ffffffff8010f100>{ret_from_intr+0}
<ffffffff8010fb02>{call_softirq+30} <ffffffff80138714>{__do_softirq+68}
<ffffffff801386ff>{__do_softirq+47} <ffffffff8010fb02>{call_softirq+30}
<ffffffff801110b5>{do_softirq+53} <ffffffff8013849f>{irq_exit+63}
<ffffffff801110fc>{do_IRQ+60} <ffffffff8010f100>{ret_from_intr+0}
<EOI> <ffffffff802c183a>{serial8250_console_write+186}
<ffffffff80132dad>{release_console_sem+333} <ffffffff80133587>{vprintk+775}
<ffffffff80133682>{printk+162} <ffffffff80133682>{printk+162}
<ffffffff8036003d>{_spin_unlock_irqrestore+29} <ffffffff80252c31>{pci_bus_read_config_byte+113}
<ffffffff802ed6fe>{pcibios_set_master+110} <ffffffff80255415>{pci_set_master+85}
<ffffffff88180eb7>{:snd_intel8x0:intel8x0_resume+39}
<ffffffff8812a9e7>{:snd:snd_card_pci_resume+55} <ffffffff80256c74>{pci_device_resume+36}
<ffffffff802d5cdd>{resume_device+157} <ffffffff802d5e23>{dpm_resume+147}
<ffffffff802d5e90>{device_resume+32} <ffffffff80153508>{pm_suspend_disk+296}
<ffffffff80150f10>{enter_state+112} <ffffffff80151147>{state_store+119}
<ffffffff801bfdd4>{subsys_attr_store+36} <ffffffff801c025a>{sysfs_write_file+202}
<ffffffff8017fb09>{vfs_write+233} <ffffffff8017fcb0>{sys_write+80}
<ffffffff8010eb5e>{system_call+126}
---------------------------
| preempt count: 00010103 ]
| 3 level deep critical section nesting:
----------------------------------------
.. [<ffffffff801332a4>] .... vprintk+0x24/0x360
.....[<ffffffff80133682>] .. ( <= printk+0xa2/0xb0)
.. [<ffffffff80360176>] .... _spin_lock+0x16/0x30
.....[<ffffffff8015a2fc>] .. ( <= __do_IRQ+0xac/0x120)
.. [<ffffffff80360176>] .... _spin_lock+0x16/0x30
.....[<ffffffff8015a2fc>] .. ( <= __do_IRQ+0xac/0x120)
handlers:
[<ffffffff80260970>] (usb_hcd_irq+0x0/0x70)
Disabling IRQ #5
[-- Attachment #2: lspci-v.log --]
[-- Type: text/x-log, Size: 6384 bytes --]
0000:00:00.0 Host bridge: nVidia Corporation nForce3 Host Bridge (rev a4)
Subsystem: ASUSTeK Computer Inc.: Unknown device 80c5
Flags: bus master, 66Mhz, fast devsel, latency 0
Memory at e8000000 (32-bit, prefetchable) [size=128M]
Capabilities: <available only to root>
0000:00:01.0 ISA bridge: nVidia Corporation nForce3 LPC Bridge (rev f6)
Subsystem: ASUSTeK Computer Inc.: Unknown device 80c5
Flags: bus master, 66Mhz, fast devsel, latency 0
0000:00:01.1 SMBus: nVidia Corporation nForce3 SMBus (rev a4)
Subsystem: ASUSTeK Computer Inc.: Unknown device 80c5
Flags: 66Mhz, fast devsel
I/O ports at 5000 [size=64]
I/O ports at 5040 [size=64]
Capabilities: <available only to root>
0000:00:02.0 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc.: Unknown device 1858
Flags: bus master, 66Mhz, fast devsel, latency 0, IRQ 11
Memory at febfb000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <available only to root>
0000:00:02.1 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc.: Unknown device 1858
Flags: bus master, 66Mhz, fast devsel, latency 0, IRQ 11
Memory at febfc000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <available only to root>
0000:00:02.2 USB Controller: nVidia Corporation nForce3 USB 2.0 (rev a2) (prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc.: Unknown device 1859
Flags: bus master, 66Mhz, fast devsel, latency 0, IRQ 5
Memory at febfdc00 (32-bit, non-prefetchable) [size=256]
Capabilities: <available only to root>
0000:00:06.0 Multimedia audio controller: nVidia Corporation nForce3 Audio (rev a2)
Subsystem: ASUSTeK Computer Inc.: Unknown device 1853
Flags: bus master, 66Mhz, fast devsel, latency 0, IRQ 10
I/O ports at e800 [size=256]
I/O ports at ec00 [size=128]
Memory at febff000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <available only to root>
0000:00:08.0 IDE interface: nVidia Corporation nForce3 IDE (rev a5) (prog-if 8a [Master SecP PriP])
Subsystem: ASUSTeK Computer Inc.: Unknown device 185a
Flags: bus master, 66Mhz, fast devsel, latency 0
I/O ports at ffa0 [size=16]
Capabilities: <available only to root>
0000:00:0a.0 PCI bridge: nVidia Corporation nForce3 PCI Bridge (rev a2) (prog-if 00 [Normal decode])
Flags: bus master, 66Mhz, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=04, sec-latency=128
I/O behind bridge: 0000b000-0000dfff
Memory behind bridge: f8a00000-feafffff
Prefetchable memory behind bridge: 40000000-43ffffff
0000:00:0b.0 PCI bridge: nVidia Corporation nForce3 AGP Bridge (rev a4) (prog-if 00 [Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 64
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
Memory behind bridge: f6900000-f89fffff
Prefetchable memory behind bridge: c6800000-e67fffff
0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
Flags: fast devsel
Capabilities: <available only to root>
0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
Flags: fast devsel
0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
Flags: fast devsel
0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
Flags: fast devsel
0000:01:00.0 VGA compatible controller: nVidia Corporation NV31M [GeForce FX Go5650] (rev a1) (prog-if 00 [VGA])
Subsystem: ASUSTeK Computer Inc.: Unknown device 1852
Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11
Memory at f7000000 (32-bit, non-prefetchable) [size=16M]
Memory at d0000000 (32-bit, prefetchable) [size=256M]
Expansion ROM at f89e0000 [disabled] [size=128K]
Capabilities: <available only to root>
0000:02:00.0 Ethernet controller: Marvell Technology Group Ltd. Gigabit Ethernet Controller (rev 13)
Subsystem: ASUSTeK Computer Inc. Marvell 88E8001 Gigabit Ethernet Controller (Asus)
Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 10
Memory at feaf8000 (32-bit, non-prefetchable) [size=16K]
I/O ports at d800 [size=256]
Expansion ROM at feac0000 [disabled] [size=128K]
Capabilities: <available only to root>
0000:02:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ab)
Subsystem: ASUSTeK Computer Inc.: Unknown device 1854
Flags: bus master, medium devsel, latency 168, IRQ 11
Memory at fd200000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
Memory window 0: 40000000-41fff000 (prefetchable)
Memory window 1: fc600000-fd1ff000
I/O window 0: 0000b000-0000b0ff
I/O window 1: 0000b400-0000b4ff
16-bit legacy interface ports at 0001
0000:02:01.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ab)
Subsystem: ASUSTeK Computer Inc.: Unknown device 1854
Flags: bus master, medium devsel, latency 168, IRQ 11
Memory at fa200000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=02, secondary=07, subordinate=0a, sec-latency=176
Memory window 0: 42000000-43fff000 (prefetchable)
Memory window 1: f9600000-fa1ff000
I/O window 0: 0000b800-0000b8ff
I/O window 1: 0000bc00-0000bcff
16-bit legacy interface ports at 0001
0000:02:01.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 03) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc.: Unknown device 1857
Flags: bus master, medium devsel, latency 64, IRQ 10
Memory at feafd000 (32-bit, non-prefetchable) [size=2K]
Capabilities: <available only to root>
0000:02:01.3 System peripheral: Ricoh Co Ltd: Unknown device 0576 (rev 01)
Subsystem: ASUSTeK Computer Inc.: Unknown device 185b
Flags: medium devsel, IRQ 11
Memory at feafd800 (32-bit, non-prefetchable) [size=256]
Capabilities: <available only to root>
0000:02:01.4 System peripheral: Ricoh Co Ltd: Unknown device 0592
Subsystem: ASUSTeK Computer Inc.: Unknown device 185c
Flags: medium devsel, IRQ 11
Memory at feafdc00 (32-bit, non-prefetchable) [size=256]
Capabilities: <available only to root>
0000:02:02.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)
Subsystem: ASUSTeK Computer Inc.: Unknown device 120f
Flags: bus master, fast devsel, latency 64, IRQ 11
Memory at feafe000 (32-bit, non-prefetchable) [size=8K]
Capabilities: <available only to root>
^ permalink raw reply
* Re: [PATCH] generate COFF zImage in arch/powerpc/boot
From: Paul Mackerras @ 2005-11-23 23:06 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20051123223827.GA20793@suse.de>
Olaf Hering writes:
> Maybe I miss the point, but if the src is unaligned, and we align it,
> dest will change as well and may be unaligned?
Yes, but in aligning the dest you will unalign the source. So with
your patch we will do something like copy 3 bytes, test, copy 1 byte,
test, go back, copy 3 bytes, test, copy 1 byte, etc., on and on until
the whole buffer is copied. With my patch we get into one loop
copying the whole buffer byte-by-byte.
The other alternative is to work out the appropriate rotate amounts
and masks so that the main loop does load word, rotate, AND, AND, OR,
store word (a bit like the 64-bit kernel memcpy does, except it works
on doublewords not words). That seems like a lot of trouble to go to
for the bootwrapper though.
Paul.
^ permalink raw reply
* Re: [PATCH] generate COFF zImage in arch/powerpc/boot
From: Olaf Hering @ 2005-11-23 22:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20051123223827.GA20793@suse.de>
On Wed, Nov 23, Olaf Hering wrote:
> On Thu, Nov 24, Paul Mackeras wrote:
>
> > Olaf Hering writes:
> >
> > > It just died while uncompressing vmlinux. Some unaligned load.
> > > So we either need a very simple byte by byte memcpy, or my version below.
> >
> > This should achieve the same effect and is quite a bit simpler. Your
> > version looks a bit strange - it copies 1-3 bytes to align the source
> > pointer, then copies 1-3 bytes to align the destination pointer, then
> > if the source pointer isn't aligned it goes back and tries again... :)
>
> Maybe I miss the point, but if the src is unaligned, and we align it,
> dest will change as well and may be unaligned?
Oh yes, it starts with dest. So everything is alright.
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: [PATCH] generate COFF zImage in arch/powerpc/boot
From: Olaf Hering @ 2005-11-23 22:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17284.61088.219693.162392@cargo.ozlabs.ibm.com>
On Thu, Nov 24, Paul Mackeras wrote:
> Olaf Hering writes:
>
> > It just died while uncompressing vmlinux. Some unaligned load.
> > So we either need a very simple byte by byte memcpy, or my version below.
>
> This should achieve the same effect and is quite a bit simpler. Your
> version looks a bit strange - it copies 1-3 bytes to align the source
> pointer, then copies 1-3 bytes to align the destination pointer, then
> if the source pointer isn't aligned it goes back and tries again... :)
Maybe I miss the point, but if the src is unaligned, and we align it,
dest will change as well and may be unaligned?
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: [PATCH] generate COFF zImage in arch/powerpc/boot
From: Paul Mackerras @ 2005-11-23 22:35 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20051123202115.GA17320@suse.de>
Olaf Hering writes:
> It just died while uncompressing vmlinux. Some unaligned load.
> So we either need a very simple byte by byte memcpy, or my version below.
This should achieve the same effect and is quite a bit simpler. Your
version looks a bit strange - it copies 1-3 bytes to align the source
pointer, then copies 1-3 bytes to align the destination pointer, then
if the source pointer isn't aligned it goes back and tries again... :)
Regards,
Paul.
diff -urN powerpc/arch/powerpc/boot/string.S merge-hack/arch/powerpc/boot/string.S
--- powerpc/arch/powerpc/boot/string.S 2005-11-16 15:55:17.000000000 +1100
+++ merge-hack/arch/powerpc/boot/string.S 2005-11-24 09:18:47.000000000 +1100
@@ -107,7 +107,7 @@
rlwinm. r7,r5,32-3,3,31 /* r7 = r5 >> 3 */
addi r6,r3,-4
addi r4,r4,-4
- beq 2f /* if less than 8 bytes to do */
+ beq 3f /* if less than 8 bytes to do */
andi. r0,r6,3 /* get dest word aligned */
mtctr r7
bne 5f
@@ -132,6 +132,11 @@
bdnz 4b
blr
5: subfic r0,r0,4
+ cmpw cr1,r0,r5
+ add r7,r0,r4
+ andi. r7,r7,3 /* will source be word-aligned too? */
+ ble cr1,3b
+ bne 3b /* do byte-by-byte if not */
mtctr r0
6: lbz r7,4(r4)
addi r4,r4,1
@@ -149,7 +154,7 @@
rlwinm. r7,r5,32-3,3,31 /* r7 = r5 >> 3 */
add r6,r3,r5
add r4,r4,r5
- beq 2f
+ beq 3f
andi. r0,r6,3
mtctr r7
bne 5f
@@ -171,7 +176,12 @@
stbu r0,-1(r6)
bdnz 4b
blr
-5: mtctr r0
+5: cmpw cr1,r0,r5
+ subf r7,r0,r4
+ andi. r7,r7,3
+ ble cr1,3b
+ bne 3b
+ mtctr r0
6: lbzu r7,-1(r4)
stbu r7,-1(r6)
bdnz 6b
^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Gaudenz Steinlin @ 2005-11-23 21:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <1131745946.24637.251.camel@gaston>
Hi Ben
Benjamin Herrenschmidt schrieb:
> The latest patch that is candidate for upstream is:
I have the same USB wakeup problem with my new powerbook 5,8 (oct 2005
15"). Without the patch I get a kernel oops on wakeup just like the
others. With this patch applied (and the pb 5,8 basic enablement patch)
the lcd gets distorted colors on wakeup. It looks quite insane, like a
broken lcd.
I'm useing a vanilla 2.6.14.2 kernel. CONFIG_USB_SUSPEND is set, PREEMPT
is disabled. Is there a newer version of the patch available for testing?
Gaudenz
^ permalink raw reply
* Re: 2.6.14 USB vs. sleep issues
From: Benjamin Herrenschmidt @ 2005-11-23 22:09 UTC (permalink / raw)
To: Gaudenz Steinlin; +Cc: linuxppc-dev list, debian-powerpc@lists.debian.org
In-Reply-To: <20051123215404.GB3401@soziologie.ch>
On Wed, 2005-11-23 at 22:55 +0100, Gaudenz Steinlin wrote:
> Hi Ben
>
> Benjamin Herrenschmidt schrieb:
> > The latest patch that is candidate for upstream is:
>
> I have the same USB wakeup problem with my new powerbook 5,8 (oct 2005
> 15"). Without the patch I get a kernel oops on wakeup just like the
> others. With this patch applied (and the pb 5,8 basic enablement patch)
> the lcd gets distorted colors on wakeup. It looks quite insane, like a
> broken lcd.
>
> I'm useing a vanilla 2.6.14.2 kernel. CONFIG_USB_SUSPEND is set, PREEMPT
> is disabled. Is there a newer version of the patch available for testing?
The USB patch has nothing to do with your screen problems. Does the
screen issue goes away after a couple of sleep/wakeup cycles ? i'm
waiting on the same machine model that I just ordered from Apple, so
I'll be able to fix remaining issues soon.
Ben.
^ permalink raw reply
* Re: [PATCH] ppc32: 8xx board-specific platform stuff for fs_enet
From: Marcelo Tosatti @ 2005-11-23 15:39 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded list, Paul Mackerras
In-Reply-To: <ddea89e58026c4f55f1a05af602cba60@embeddededge.com>
Hi Dan,
On Wed, Nov 23, 2005 at 03:18:17PM -0500, Dan Malek wrote:
>
> On Nov 23, 2005, at 7:00 AM, Marcelo Tosatti wrote:
>
> >The files in arch/ppc/8xx_io/ (which is what I think you refer to as
> >candidates for drivers/), are:
>
> I don't particularly like these macros, but I'm tired of fighting
> about it.
We did not fight about it, did we??? I don't understand what you mean.
We need to agree on technical points. If you see a problem with the
macros, you need to teach us about them.
The requirement for in/out inline functions is to force the compiler
not to reorder instructions, but I suppose you are talking about the
clrbit/setbit macros? Or about both?
> If you follow the usage path, you will see it's only
> used in the CPM drivers, and I wish people would just use
> the data structure pointers to access these ports/bits with
> standard C code and then place any synchronization
> instructions properly.
The in/out inline functions unify access to conf. registers.
Jeff Garzik gave me a list of reasons for using the inline macros
which is quite educational:
* Easier reviewing. One cannot easily distinguish between writing to
normal kernel virtual memory and "magic" memory that produces magicaly
side effects such as initiating DMA of a net packet.
* Compiler safety. As the code is written now, you have no guarantees
that the compiler won't combine two stores to the same location, etc.
Accessor macros are a convenient place to add compiler barriers or
'volatile' notations that the MPC8xx code lacks.
* Maintainable. foo_read[bwl] or foo_read{8,16,32} are preferred
because that's the way other bus accessors look like -- yes even
embedded SoC buses benefit from these code patterns. You want your
driver to look like other drivers as much as possible.
* Convenience. The accessors can be a zero overhead memory read/write
at a minimum. But they can also be convenient places to use special
memory read/write instructions that specify uncached memop, compiler
barriers, memory barriers, etc.
And Paulus wrote some important points:
Generally on PowerPC you need to use at least the eieio instruction to
prevent reordering of the loads and stores to the device. It's
possible that 8xx is sufficiently in-order that you get away without
putting in barrier instructions (eieio or sync), but it's not good
practice to omit them.
You can use accessors such as in_be32 and in_le32 in this situation,
when you have a kernel virtual address that is already mapped to the
device.
> There are some cases where you have to be quite careful about how you
> read and write some control registers, and I think this opens the
> possibility to just be sloppy and make mistakes since the read/write
> is hidden within the macro.
Here you're talking about the setbit/clrbit macros which combine
read/write.
Its simply for the sake of readability, since the C text for
"out_be32(xxx, in_be32(xxx) |& zzzz)" is quite large.
Do you think that the macro is a potential for introduction
of mistakes?
We don't have any synchronization between read-modify-write
operations to conf. registers now, can you mention the cases
where read and write need some sort of synchronization?
In any way, those can just not use the macros, right?
Sincerely, I don't care very much for setbit/clrbit macros,
I just think that they make the code easier to read.
> >Does anyone have hardware to test it? Dan?
>
> Yes, I have hardware to test it. I will do that one of these days.
OK ;)
^ permalink raw reply
* Re: [PATCH] 8xx PCMCIA: support for MPC885ADS and MPC866ADS
From: Marcelo Tosatti @ 2005-11-23 15:13 UTC (permalink / raw)
To: Dan Malek; +Cc: Vitaly Bordug, linuxppc-embedded list
In-Reply-To: <24aa4090f558206fa04f9d584c590034@embeddededge.com>
On Wed, Nov 23, 2005 at 03:22:40PM -0500, Dan Malek wrote:
>
> On Nov 23, 2005, at 7:53 AM, Marcelo Tosatti wrote:
>
> >Shouldnt you handle ioremap() failure? Most 85xx code written
> >by Kumar also does not.
>
> And do what if it fails? Chances are you don't have any
> way to report an error message or panic at this point. In
> fact, there are a few silly tests like this where the
> failure tries to panic or print some message that will never
> be seen. Fortunately, the code will never fail and we will
> never take such code paths.
OK! Was talking BS then.
^ permalink raw reply
* Re: [PATCH] 8xx PCMCIA: support for MPC885ADS and MPC866ADS
From: Dan Malek @ 2005-11-23 20:22 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Vitaly Bordug, linuxppc-embedded list
In-Reply-To: <20051123125326.GB4526@logos.cnet>
On Nov 23, 2005, at 7:53 AM, Marcelo Tosatti wrote:
> Shouldnt you handle ioremap() failure? Most 85xx code written
> by Kumar also does not.
And do what if it fails? Chances are you don't have any
way to report an error message or panic at this point. In
fact, there are a few silly tests like this where the
failure tries to panic or print some message that will never
be seen. Fortunately, the code will never fail and we will
never take such code paths.
-- Dan
^ permalink raw reply
* Re: [PATCH] generate COFF zImage in arch/powerpc/boot
From: Olaf Hering @ 2005-11-23 20:21 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20051119204742.GA17604@suse.de>
On Sat, Nov 19, Olaf Hering wrote:
> On Sat, Nov 19, Olaf Hering wrote:
>
> > On Sat, Nov 19, Olaf Hering wrote:
> >
> > > This patch on top of yours fixes it for me.
> >
> > Another Makefile fix to actually include the kernel in the zImage.coff.
It just died while uncompressing vmlinux. Some unaligned load.
So we either need a very simple byte by byte memcpy, or my version below.
0 > boot file: 1.1.1.3,coffloading XCOFF
tsize=4D84 dsize=1542B8 bsize=BC80 entry=500000
SECTIONS:
.text 00500000 00500000 00004D84 000000FC
.data 00505000 00505000 001542B8 00004E80
.bss 0065A000 0065A000 0000BC80 00000000
.note.GN 00000000 00000000 00000000 00000000
loading .text, done..
loading .data, done..
clearing .bss, done..
zImage starting: loaded at 0x00500000 (sp: 0x003fff00)
Allocating 0x4b4660 bytes for kernel ...
OF version = 'Open Firmware, 1.0.5'
old OF detected
gunzipping (0x700000 <- 0x505c44:0x6592b8)...DEFAULT CATCH!, code=FFF00600
ok
0 > .registers
Client's Fix Pt Regs:
00 00000001 003FFDF0 00000000 00662183 00629FF6 000039FC 006621C0 9D6528E2
08 7385808D 005023A0 00000002 005055C0 00000060 DEADBEEF DEADBEEF DEADBEEF
10 DEADBEEF DEADBEEF DEADBEEF DEADBEEF DEADBEEF 00662183 000039FD 00000000
18 003FFE80 0002F2FF 0065A45C 0062D9B6 00000000 00000000 0050DBC0 000039FD
Special Regs:
%IV: 00000600 %SRR0: 005001C8 %SRR1: 00003070 %MQ: 00000000
%CR: 50000055 %LR: 005023F4 %CTR: 00000737 %XER: E000BE6F
%DAR: 00629FFE %DSISR: 00004104 %SDR1: 004E0000
ok
0 > reset-all
00000000005001a8 <memcpy>:
5001a8: 54 a7 e8 ff rlinm. r7,r5,29,3,31
5001ac: 38 c3 ff fc cal r6,-4(r3)
5001b0: 38 84 ff fc cal r4,-4(r4)
5001b4: 41 82 00 28 beq 5001dc <memcpy+0x34>
5001b8: 70 c0 00 03 andil. r0,r6,3
5001bc: 7c e9 03 a6 mtctr r7
5001c0: 40 82 00 54 bne 500214 <memcpy+0x6c>
5001c4: 80 e4 00 04 l r7,4(r4)
5001c8: 85 04 00 08 lu r8,8(r4)
5001cc: 90 e6 00 04 st r7,4(r6)
5001d0: 95 06 00 08 stu r8,8(r6)
5001d4: 42 00 ff f0 bdn 5001c4 <memcpy+0x1c>
arch/powerpc/boot/string.S | 121 +++++++++++++++++++++++++---------------
Index: linux-2.6.15-rc1-olh/arch/powerpc/boot/string.S
===================================================================
--- linux-2.6.15-rc1-olh.orig/arch/powerpc/boot/string.S
+++ linux-2.6.15-rc1-olh/arch/powerpc/boot/string.S
@@ -98,88 +98,124 @@ memset:
.globl memmove
memmove:
+ cmpwi 0,r5,0
+ beqlr
cmplw 0,r3,r4
bgt backwards_memcpy
/* fall through */
.globl memcpy
memcpy:
+ cmpwi 0,r5,0
+ beqlr
+ andi. r0,r4,3 /* get src word aligned */
+ beq 20f
+10: subfic r0,r0,4
+ cmpd r0,r5
+ blt 11f
+ mr r0,r5
+11: mtctr r0
+12: lbz r7,0(r4)
+ stb r7,0(r3)
+ addi r4,r4,1
+ addi r3,r3,1
+ bdnz 12b
+ subf. r5,r0,r5
+ beqlr
+20: andi. r0,r3,3 /* get dest word aligned */
+ beq 30f
+ subfic r0,r0,4
+ cmpd r0,r5
+ blt 21f
+ mr r0,r5
+21: mtctr r0
+22: lbz r7,0(r4)
+ stb r7,0(r3)
+ addi r4,r4,1
+ addi r3,r3,1
+ bdnz 22b
+ subf. r5,r0,r5
+ beqlr
+ andi. r0,r4,3 /* get src word aligned */
+ bne 10b
+30:
rlwinm. r7,r5,32-3,3,31 /* r7 = r5 >> 3 */
addi r6,r3,-4
addi r4,r4,-4
- beq 2f /* if less than 8 bytes to do */
- andi. r0,r6,3 /* get dest word aligned */
+ beq 32f /* if less than 8 bytes to do */
mtctr r7
- bne 5f
-1: lwz r7,4(r4)
+31: lwz r7,4(r4)
lwzu r8,8(r4)
stw r7,4(r6)
stwu r8,8(r6)
- bdnz 1b
+ bdnz 31b
andi. r5,r5,7
-2: cmplwi 0,r5,4
- blt 3f
+32: cmplwi 0,r5,4
+ blt 33f
lwzu r0,4(r4)
addi r5,r5,-4
stwu r0,4(r6)
-3: cmpwi 0,r5,0
+33: cmpwi 0,r5,0
beqlr
mtctr r5
addi r4,r4,3
addi r6,r6,3
-4: lbzu r0,1(r4)
+34: lbzu r0,1(r4)
stbu r0,1(r6)
- bdnz 4b
+ bdnz 34b
blr
-5: subfic r0,r0,4
- mtctr r0
-6: lbz r7,4(r4)
- addi r4,r4,1
- stb r7,4(r6)
- addi r6,r6,1
- bdnz 6b
- subf r5,r0,r5
- rlwinm. r7,r5,32-3,3,31
- beq 2b
- mtctr r7
- b 1b
.globl backwards_memcpy
backwards_memcpy:
- rlwinm. r7,r5,32-3,3,31 /* r7 = r5 >> 3 */
add r6,r3,r5
add r4,r4,r5
- beq 2f
- andi. r0,r6,3
+
+ andi. r0,r4,3 /* get src word aligned */
+ beq 20f
+10: cmpd r0,r5
+ blt 11f
+ mr r0,r5
+11: mtctr r0
+12: lbzu r7,-1(r4)
+ stbu r7,-1(r6)
+ bdnz 12b
+ subf. r5,r0,r5
+ beqlr
+20: andi. r0,r6,3 /* get dest word aligned */
+ beq 30f
+ cmpd r0,r5
+ blt 21f
+ mr r0,r5
+21: mtctr r0
+22: lbzu r7,-1(r4)
+ stbu r7,-1(r6)
+ bdnz 22b
+ subf. r5,r0,r5
+ beqlr
+ andi. r0,r4,3 /* get src word aligned */
+ bne 10b
+30:
+ rlwinm. r7,r5,32-3,3,31 /* r7 = r5 >> 3 */
+ beq 32f
mtctr r7
- bne 5f
-1: lwz r7,-4(r4)
+31: lwz r7,-4(r4)
lwzu r8,-8(r4)
stw r7,-4(r6)
stwu r8,-8(r6)
- bdnz 1b
+ bdnz 31b
andi. r5,r5,7
-2: cmplwi 0,r5,4
- blt 3f
+32: cmplwi 0,r5,4
+ blt 33f
lwzu r0,-4(r4)
subi r5,r5,4
stwu r0,-4(r6)
-3: cmpwi 0,r5,0
+33: cmpwi 0,r5,0
beqlr
mtctr r5
-4: lbzu r0,-1(r4)
+34: lbzu r0,-1(r4)
stbu r0,-1(r6)
- bdnz 4b
+ bdnz 34b
blr
-5: mtctr r0
-6: lbzu r7,-1(r4)
- stbu r7,-1(r6)
- bdnz 6b
- subf r5,r0,r5
- rlwinm. r7,r5,32-3,3,31
- beq 2b
- mtctr r7
- b 1b
.globl memcmp
memcmp:
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: [PATCH] ppc32: 8xx board-specific platform stuff for fs_enet
From: Dan Malek @ 2005-11-23 20:18 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded list, Paul Mackerras
In-Reply-To: <20051123120033.GA3551@logos.cnet>
On Nov 23, 2005, at 7:00 AM, Marcelo Tosatti wrote:
> The files in arch/ppc/8xx_io/ (which is what I think you refer to as
> candidates for drivers/), are:
I don't particularly like these macros, but I'm tired of fighting
about it. If you follow the usage path, you will see it's only
used in the CPM drivers, and I wish people would just use
the data structure pointers to access these ports/bits with
standard C code and then place any synchronization
instructions properly. There are some cases where you
have to be quite careful about how you read and write
some control registers, and I think this opens the possibility
to just be sloppy and make mistakes since the read/write
is hidden within the macro.
> Does anyone have hardware to test it? Dan?
Yes, I have hardware to test it. I will do that one of these days.
Thanks.
-- Dan
^ 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