* Re: crash in init_ipic_sysfs on efika
From: Olaf Hering @ 2008-03-20 6:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18400.41990.995316.729968@cargo.ozlabs.ibm.com>
On Wed, Mar 19, Paul Mackerras wrote:
> Olaf Hering writes:
>
> > I cant reproduce this bug on my board, but:
> >
> > The global primary_ipic in arch/powerpc/sysdev/ipic.c can remain NULL if
> > ipic_init() fails. init_ipic_sysfs() will crash in that case.
> >
> > Something like this may fix it:
>
> Is this needed for 2.6.25? Is the system at all usable if ipic_init
> fails?
CONFIG_PPC_MPC51* needs to be disabled for pmac/chrp/bplan .configs.
A full featured ppc32_defconfig will probably catch such errors.
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] Add PPC4xx L2-cache support (440GX & 460EX/GT)
From: Benjamin Herrenschmidt @ 2008-03-20 6:54 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1205847389-17771-1-git-send-email-sr@denx.de>
On Tue, 2008-03-18 at 14:36 +0100, Stefan Roese wrote:
> This patch adds support for the 256k L2 cache found on some IBM/AMCC
> 4xx PPC's. It introduces a common 4xx SoC file (sysdev/ppc4xx_soc.c)
> which currently "only" adds the L2 cache init code. Other common 4xx
> stuff can be added later here.
>
> The L2 cache handling code is just a copy of Eugene's code in arch/ppc
> with small modifications.
>
> Tested on AMCC Taishan 440GX and Canyonlands 460EX.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
It's my understanding that on some 44x platforms, the l2 needs to be
explicitely invalidated on DMAs. Do we know more about that ? I think it
depends on something like the number of masters on the PLB4 or so. I
don't remember the details.
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] Add PPC4xx L2-cache support (440GX & 460EX/GT)
From: Stefan Roese @ 2008-03-20 7:12 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1205996092.26869.420.camel@pasglop>
On Thursday 20 March 2008, Benjamin Herrenschmidt wrote:
> On Tue, 2008-03-18 at 14:36 +0100, Stefan Roese wrote:
> > This patch adds support for the 256k L2 cache found on some IBM/AMCC
> > 4xx PPC's. It introduces a common 4xx SoC file (sysdev/ppc4xx_soc.c)
> > which currently "only" adds the L2 cache init code. Other common 4xx
> > stuff can be added later here.
> >
> > The L2 cache handling code is just a copy of Eugene's code in arch/ppc
> > with small modifications.
> >
> > Tested on AMCC Taishan 440GX and Canyonlands 460EX.
> >
> > Signed-off-by: Stefan Roese <sr@denx.de>
>
> It's my understanding that on some 44x platforms, the l2 needs to be
> explicitely invalidated on DMAs.
Correct.
> Do we know more about that ? I think it
> depends on something like the number of masters on the PLB4 or so. I
> don't remember the details.
The L2 cache on the 440GX is cache coherent (via snooping). On the
440SP/440SPe the L2 cache is partially coherent. The LL (Low Latency) PLB
segment is coherent and the HB (High Bandwidth) PLB segment is unfortunately
not. Here an except from the 440SPe users manual:
"
Cache coherency is limited to the Low Latency (LL) PLB bus and is managed by a
hardware snoop mechanism or software (software that is similar to the
existing CPU L1 cache)
"
So we will need to add something to handle the L2 cache on those platforms
correctly. Not needed on 440GX though.
As for 460EX/GT this is currently not clear yet. I'm working on it with AMCC
right now.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 2/2] Force 4K IOPages when eHEA is present in the machine.
From: Nathan Lynch @ 2008-03-20 7:18 UTC (permalink / raw)
To: Tony Breeds
Cc: Johansson, linuxppc-dev, Paul Mackerras, Olof, Jan-Bernd Themann
In-Reply-To: <262bc32afdde978922b9500c2a83f7c7ed6e4043.1205987625.git.tony@bakeyournoodle.com>
Tony Breeds wrote:
>
> +#if defined(CONFIG_PPC_PSERIES) && defined(CONFIG_PPC_64K_PAGES)
> +static int __init scan_dt_for_ehea(unsigned long node, const char *uname,
> + int depth, void *data)
> +{
> + if (depth != 0)
> + return 0;
> +
> + if (of_flat_dt_search(node, "HEA ", "ibm,drc-names"))
> + return 1;
> +
> + return 0;
> +}
> +#endif
Searching ibm,drc-names is necessary, but is it sufficient? That is,
can there be a system that has an HEA adapter without that property
being present? Thinking in particular about single-partition systems
that run without an HMC attached.
> static void __init htab_init_page_sizes(void)
> {
> int rc;
> +#ifdef CONFIG_PPC_64K_PAGES
> + int has_ehea = 0;
> +#endif
>
> /* Default to 4K pages only */
> memcpy(mmu_psize_defs, mmu_psize_defaults_old,
> sizeof(mmu_psize_defaults_old));
>
> +#if defined(CONFIG_PPC_PSERIES) && defined(CONFIG_PPC_64K_PAGES)
> + /* Scan to see if this system can have an EHEA, if so we'll
> + * demote io_psize to 4K */
> + has_ehea = of_scan_flat_dt(scan_dt_for_ehea, NULL);
> +#endif
I'm wondering if some of the ifdef stuff could be avoided if you used
a firmware feature bit to signify the limitation (or the lack of it).
The bit could be set during pSeries_probe. Just an idea; I don't feel
that strongly about it.
^ permalink raw reply
* Re: [PATCH 6/8] ptrace: arch_ptrace -ENOSYS return
From: Christoph Hellwig @ 2008-03-20 7:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-arch, tony.luck, linux-ia64, linux-kernel, David Miller,
linuxppc-dev, Thomas Gleixner, sparclinux, Paul Mackerras,
Andrew Morton, Ingo Molnar, Roland McGrath, Richard Henderson
In-Reply-To: <alpine.LFD.1.00.0803191935080.3020@woody.linux-foundation.org>
On Wed, Mar 19, 2008 at 07:40:25PM -0700, Linus Torvalds wrote:
>
> And I have to say, I really hate that
>
> ret = arch_ptrace(child, request, addr, data);
> if (ret == -ENOSYS && !forced_successful_syscall_return())
> ret = ptrace_request(child, request, addr, data);
>
> thing. Instead of doing it that ugly way (return value and a special
> per-arch forced_successful_syscall_return() thing), this really smells
> like you just want to change the calling conventions for "arch_ptrace()"
> instead.
>
> Wouldn't it be nicer to just let "arch_ptrace()" return a flag saying
> whether it handled things or not?
I think the easiest and cleanest would be to just drop this whole
series. There's no inherent advantage of
ret = -ENOSYS;
in the arch_ptrace default case over
ret = ptrace_request(...);
^ permalink raw reply
* Re: unprivileged use of MSR_SE
From: Roland McGrath @ 2008-03-20 7:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18401.58282.992971.923754@cargo.ozlabs.ibm.com>
> No and no.
Good and good!
> On ppc32 there is a sys_debug_setcontext system call that is there to
> allow a process to debug itself. It does a setcontext and optionally
> sets the MSR_SE or MSR_BE bit. We don't have it on ppc64 for some
> reason (we should add it).
Wacky. I only looked in signal_64.c, so I didn't notice this.
> The only MSR bit that sigreturn copies from the signal frame back into
> the MSR is the MSR_LE (little-endian) bit.
So it is. I looked right at that and saw something different. It must
have been my psychic abilities trying to tell me about sys_debug_setcontext.
> > Or could sigreturn ignore the MSR_SE bit without breaking any strange user?
>
> It already does AFAICS.
But sys_debug_setcontext doesn't. That is, it has user semantics
(sig_dbg_op.dbg_value) that mean setting MSR_SE. I take it you mean to
preserve that user feature. For the issue I've been talking about that
makes it equivalent to the x86 popf case.
For example, use syscall tracing to stop at the exit from
sys_debug_setcontext (in a call with dbg->dbg_value!=0).
MSR_SE is set, as it should be. Now using PTRACE_CONT or PTRACE_SYSCALL
will clear MSR_SE and resume, breaking the user's behavior.
For the analogous problem on x86, we keep a flag saying whether MSR_SE was
set "artificially" by ptrace or was set "for real" in the user state. We
use a TIF bit, but whatever is optimal. In user_enable_single_step, set
the forced-SE flag if MSR_SE was clear and don't if it was already set.
In user_disable_single_step, clear the forced-SE flag and only if it was
set, clear MSR_SE. With that, debugger-step and user-self-step can cooexist.
> OK, I found MSR_DEBUGCHANGE, it's in ptrace.c. :) So it only applies
> to attempts to change the MSR of a process using ptrace. So, what you
> want is just to disallow changing MSR via PTRACE_POKEUSR or
> equivalent, then?
If there is no way like sys_debug_setcontext to set MSR_SE as proper user
state, then yes. If it is possible for a user task to set its own MSR_SE,
then I'd like the forced-SE flag as above. Then get_user_msr should mask
off MSR_SE when forced-SE is set, and set_user_msr should clear forced-SE
when MSR_SE is set via user_regset (ptrace). That way user_regset calls
can fetch and restore the complete user-visible state, including the state
just after executing a sys_debug_setcontext requesting self-step.
Thanks,
Roland
^ permalink raw reply
* [BUG] Linux 2.6.25-rc6 - kernel BUG at fs/mpage.c:476! on powerpc
From: Kamalesh Babulal @ 2008-03-20 7:43 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: jfs-discussion, linuxppc-dev, shaggy, Andrew Morton, linux-ext4,
Balbir Singh
In-Reply-To: <alpine.LFD.1.00.0803161651350.3020@woody.linux-foundation.org>
When filesystem stress on ext2/3 mounted partition with the 2.6.25-rc6 kernel
over the powerpc box, following calls traces are seen for more than 1000 times.
And when the file system stress in run on jfs mounted partition kernel bug is
seen.
INFO: task fsstress:30559 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Call Trace:
[c0000000ec09f580] [c0000000ec09f620] 0xc0000000ec09f620 (unreliable)
[c0000000ec09f750] [c0000000000108ec] .__switch_to+0x11c/0x154
[c0000000ec09f7e0] [c0000000004a644c] .schedule+0x7a4/0x888
[c0000000ec09f8d0] [c000000000111adc] .inode_wait+0x10/0x28multiple
[c0000000ec09f950] [c0000000004a6e64] .__wait_on_bit+0xa0/0x114
[c0000000ec09fa00] [c00000000011fc10] .__writeback_single_inode+0x124/0x360
[c0000000ec09faf0] [c000000000120308] .sync_sb_inodes+0x220/0x358
[c0000000ec09fba0] [c00000000012051c] .sync_inodes_sb+0xdc/0x120
[c0000000ec09fc80] [c000000000120614] .__sync_inodes+0xb4/0x164
[c0000000ec09fd20] [c00000000012419c] .do_sync+0x74/0xc0
[c0000000ec09fdb0] [c0000000001241fc] .sys_sync+0x14/0x28
[c0000000ec09fe30] [c000000000008734] syscall_exit+0x0/0x40
INFO: task fsstress:30853 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Call Trace:
[c000000096f1f1c0] [c000000096f1f280] 0xc000000096f1f280 (unreliable)
[c000000096f1f390] [c0000000000108ec] .__switch_to+0x11c/0x154
[c000000096f1f420] [c0000000004a644c] .schedule+0x7a4/0x888
[c000000096f1f510] [c0000000004a6a2c] .io_schedule+0x7c/0xe8
[c000000096f1f5a0] [c000000000126ce8] .sync_buffer+0x68/0x80
[c000000096f1f620] [c0000000004a6c80] .__wait_on_bit_lock+0x8c/0x110
[c000000096f1f6c0] [c0000000004a6d98] .out_of_line_wait_on_bit_lock+0x94/0xc0
[c000000096f1f7b0] [c000000000126fc0] .__lock_buffer+0x48/0x60
[c000000096f1f830] [c000000000128e24] .__bread+0x64/0x108
[c000000096f1f8b0] [c0000000001f0664] .ext2_get_inode+0xf8/0x194
[c000000096f1f950] [c0000000001f0764] .ext2_update_inode+0x64/0x4e4
[c000000096f1fa20] [c00000000011fcf0] .__writeback_single_inode+0x204/0x360
[c000000096f1fb10] [c000000000120af4] .sync_inode+0x44/0x88
[c000000096f1fba0] [c0000000001f0550] .ext2_sync_inode+0x44/0x60
[c000000096f1fc70] [c0000000001eee90] .ext2_sync_file+0x54/0x84
[c000000096f1fd00] [c000000000123f50] .do_fsync+0x90/0x10c
[c000000096f1fda0] [c000000000124000] .__do_fsync+0x34/0x60
[c000000096f1fe30] [c000000000008734] syscall_exit+0x0/0x40
INFO: task fsstress:30859 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Call Trace:
[c0000000b228f240] [c0000000b228f2e0] 0xc0000000b228f2e0 (unreliable)
[c0000000b228f410] [c0000000000108ec] .__switch_to+0x11c/0x154
[c0000000b228f4a0] [c0000000004a644c] .schedule+0x7a4/0x888
[c0000000b228f590] [c0000000004a6a2c] .io_schedule+0x7c/0xe8
[c0000000b228f620] [c000000000126ce8] .sync_buffer+0x68/0x80
[c0000000b228f6a0] [c0000000004a6e64] .__wait_on_bit+0xa0/0x114
[c0000000b228f750] [c0000000004a6f6c] .out_of_line_wait_on_bit+0x94/0xc0
[c0000000b228f840] [c000000000126bac] .__wait_on_buffer+0x30/0x48
[c0000000b228f8c0] [c00000000012a30c] .sync_dirty_buffer+0xf0/0x160
[c0000000b228f950] [c0000000001f0af8] .ext2_update_inode+0x3f8/0x4e4
[c0000000b228fa20] [c00000000011fcf0] .__writeback_single_inode+0x204/0x360
[c0000000b228fb10] [c000000000120af4] .sync_inode+0x44/0x88
[c0000000b228fba0] [c0000000001f0550] .ext2_sync_inode+0x44/0x60
[c0000000b228fc70] [c0000000001eee90] .ext2_sync_file+0x54/0x84
[c0000000b228fd00] [c000000000123f50] .do_fsync+0x90/0x10c
[c0000000b228fda0] [c000000000124000] .__do_fsync+0x34/0x60
[c0000000b228fe30] [c000000000008734] syscall_exit+0x0/0x40
INFO: task fsstress:30863 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Call Trace:
[c0000000b239f250] [c0000000b239f340] 0xc0000000b239f340 (unreliable)
[c0000000b239f420] [c0000000000108ec] .__switch_to+0x11c/0x154
[c0000000b239f4b0] [c0000000004a644c] .schedule+0x7a4/0x888
[c0000000b239f5a0] [c0000000004a6a2c] .io_schedule+0x7c/0xe8
[c0000000b239f630] [c000000000126ce8] .sync_buffer+0x68/0x80
[c0000000b239f6b0] [c0000000004a6c80] .__wait_on_bit_lock+0x8c/0x110
[c0000000b239f750] [c0000000004a6d98] .out_of_line_wait_on_bit_lock+0x94/0xc0
[c0000000b239f840] [c000000000126fc0] .__lock_buffer+0x48/0x60
[c0000000b239f8c0] [c00000000012a28c] .sync_dirty_buffer+0x70/0x160
[c0000000b239f950] [c0000000001f0af8] .ext2_update_inode+0x3f8/0x4e4
[c0000000b239fa20] [c00000000011fcf0] .__writeback_single_inode+0x204/0x360
[c0000000b239fb10] [c000000000120af4] .sync_inode+0x44/0x88
[c0000000b239fba0] [c0000000001f0550] .ext2_sync_inode+0x44/0x60
[c0000000b239fc70] [c0000000001eee90] .ext2_sync_file+0x54/0x84
[c0000000b239fd00] [c000000000123f50] .do_fsync+0x90/0x10c
[c0000000b239fda0] [c000000000124000] .__do_fsync+0x34/0x60
[c0000000b239fe30] [c000000000008734] syscall_exit+0x0/0x40
(gdb) p __switch_to
$1 = {struct task_struct *(struct task_struct *, struct task_struct *)} 0xc0000000000107d0 <__switch_to>
(gdb) p/x 0xc0000000000107d0+0x11c
$2 = 0xc0000000000108ec
(gdb) l *0xc0000000000108ec
0xc0000000000108ec is in __switch_to (arch/powerpc/kernel/process.c:356).
351
352 account_system_vtime(current);
353 account_process_vtime(current);
354 calculate_steal_time();
355
356 last = _switch(old_thread, new_thread);
357
358 local_irq_restore(flags);
359
360 return last;
(gdb) p schedule
$3 = {void (void)} 0xc0000000004a5ca8 <.schedule>
(gdb) p/x 0xc0000000004a5ca8+0x7a4
$4 = 0xc0000000004a644c
(gdb) l *0xc0000000004a644c
0xc0000000004a644c is at include/asm/current.h:22.
17
18 static inline struct task_struct *get_current(void)
19 {
20 struct task_struct *task;
21
22 __asm__ __volatile__("ld %0,%1(13)"
23 : "=r" (task)
24 : "i" (offsetof(struct paca_struct, __current)));
25
26 return task;
kernel BUG at fs/mpage.c:476!
cpu 0x0: Vector: 700 (Program Check) at [c0000000c28debd0]
pc: c00000000012f588: .__mpage_writepage+0xd0/0x618
lr: c0000000000c79c0: .write_cache_pages+0x228/0x3e8
sp: c0000000c28dee50
msr: 8000000000029032
current = 0xc000000060ac5850
paca = 0xc000000000663b00
pid = 5254, comm = fsstress
kernel BUG at fs/mpage.c:476!
enter ? for help
[c0000000c28df3d0] c0000000000c79c0 .write_cache_pages+0x228/0x3e8
[c0000000c28df540] c00000000012fb84 .mpage_writepages+0x54/0x8c
[c0000000c28df5e0] c0000000001fe748 .jfs_writepages+0x1c/0x34
[c0000000c28df660] c0000000000c7c20 .do_writepages+0x68/0xa4
[c0000000c28df6e0] c0000000000bfbc0 .__filemap_fdatawrite_range+0x88/0xb8
[c0000000c28df7d0] c0000000000bfe9c .filemap_write_and_wait+0x2c/0x68
[c0000000c28df860] c0000000000c0848 .generic_file_buffered_write+0x65c/0x6c8
[c0000000c28df9a0] c0000000000c0bb4 .__generic_file_aio_write_nolock+0x300/0x3ec
[c0000000c28dfaa0] c0000000000c0d20 .generic_file_aio_write+0x80/0x114
[c0000000c28dfb60] c0000000000f7d7c .do_sync_write+0xc4/0x124
[c0000000c28dfcf0] c0000000000f85b0 .vfs_write+0xd8/0x1a4
[c0000000c28dfd90] c0000000000f8f3c .sys_write+0x4c/0x8c
[c0000000c28dfe30] c000000000008734 syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000000000ff0d8c8
SP (ffb4c8a0) is in userspace
(gdb) p write_cache_pages
$1 = {int (struct address_space *, struct writeback_control *, writepage_t, void *)} 0xc0000000000c7798 <write_cache_pages>
(gdb) p/x 0xc0000000000c7798+0x228
$2 = 0xc0000000000c79c0
(gdb) l *0xc0000000000c79c0
0xc0000000000c79c0 is in write_cache_pages (mm/page-writeback.c:867).
862 !clear_page_dirty_for_io(page)) {
863 unlock_page(page);
864 continue;
865 }
866
867 ret = (*writepage)(page, wbc, data);
868
869 if (unlikely(ret == AOP_WRITEPAGE_ACTIVATE)) {
870 unlock_page(page);
871 ret = 0;
(gdb) p __mpage_writepage
$3 = {int (struct page *, struct writeback_control *, void *)} 0xc00000000012f4b8 <__mpage_writepage>
(gdb) p/x 0xc00000000012f4b8+0xd0
$4 = 0xc00000000012f588
(gdb) l *0xc00000000012f588
0xc00000000012f588 is in __mpage_writepage (fs/mpage.c:476).
471 struct buffer_head *bh = head;
472
473 /* If they're all mapped and dirty, do it */
474 page_block = 0;
475 do {
476 BUG_ON(buffer_locked(bh));
477 if (!buffer_mapped(bh)) {
478 /*
479 * unmapped dirty buffers are created by
480 * __set_page_dirty_buffers -> mmapped data
(gdb)
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: simple MPC5200B system
From: André Schwarz @ 2008-03-20 7:48 UTC (permalink / raw)
To: Wolfgang Denk, Andre Schwarz, linux-ppc list
In-Reply-To: <20080320002149.GD19616@localhost.localdomain>
David Gibson schrieb:
> On Thu, Mar 20, 2008 at 01:14:45AM +0100, Wolfgang Denk wrote:
>> In message <47DF821B.6090600@matrix-vision.de> you wrote:
>>> I've pulled the latest git and built a mpc5200_simple system with a=20
>>> minimal dts.
>>> There's not a single char put on the console ....
>> You did build your device tree with "-b 0", didn't you?
>=20
> Ugh.. I really need to fix dtc to pick the default boot cpu value more
> sensibly, don't I.
>=20
I didn't specify "-b 0". This shouldn't be neccessary on a single=20
processor system ! After all it's an option ... "0" should be default.
-->"./dtc -I dts -O dtb -o /mnt/tftpboot/mvbc.dtb -S 8192 dts/mvbc.dts"
The system is running fine (please see discussions with Grant).
regards,
Andr=E9 Schwarz
MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler - Registergeric=
ht: Amtsgericht Stuttgart, HRB 271090
Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* Re: [PATCH 6/8] ptrace: arch_ptrace -ENOSYS return
From: Roland McGrath @ 2008-03-20 8:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-arch, tony.luck, linux-ia64, linux-kernel, David Miller,
linuxppc-dev, Thomas Gleixner, sparclinux, Paul Mackerras,
Andrew Morton, Ingo Molnar, Richard Henderson
In-Reply-To: <alpine.LFD.1.00.0803191935080.3020@woody.linux-foundation.org>
> Hmm.. I see the whole series, and I see this patch, but I think it adds
> new code and new complexity, and I don't really see *why*.
The motivation is to get the arch function out of the code path for the
machine-independent request handling. I want to be able to change the
implementation later without touching the arch code again.
The arguments passed down to arch_ptrace are sufficient for what the arch
code itself needs and for the current implementation in ptrace_request.
In future, I'd like the option of changing the code for the standard
requests to use a local data structure set up at the start of ptrace, and
such like (so more pointers and the like would need to be passed down to
ptrace_request). These patches let me remove ptrace_request or change
its calling convention without touching the arch code again.
> Wouldn't it be nicer to just let "arch_ptrace()" return a flag saying
> whether it handled things or not?
It would certainly be nicer. I would prefer:
extern int arch_ptrace(struct task_struct *child, long request,
long addr, long data, long *retval);
where it returns an error code or it returns 0 and *retval is the value
or it returns 1 and it didn't do anything.
The reason I took the approach I did instead is incrementalism.
I can't change that signature without breaking about 22 arch builds.
I'm only really prepared to thoroughly verify a change on 2 of those
myself. It should be a simple enough change to make blind and get
right. But I've gotten a lot of things wrong before. On principle,
I wouldn't really expect anyone to sign off on stuff I won't even
claim to have tried. I did the forced_successful_syscall_return()
macro for arch's I don't try to build, and was just awful sure golly
that I hadn't got them wrong, because the generic change would break
those few arch's (not 20) without it.
So this ugliness seemed like a better bet than waiting for 20 more
arch sign-offs before any of it could go in. You are certainly in a
position to just change the generic signature and make every arch do
the update (or fix your typos if you just tweak them all blind), and
let them grumble. I did not presume to do so.
If you'd like a patch that changes this signature, updates all arch
implementations, and is actually verified to compile and work only
on x86 and powerpc, I'll be happy to provide that.
Thanks,
Roland
^ permalink raw reply
* Re: simple MPC5200B system
From: David Gibson @ 2008-03-20 8:20 UTC (permalink / raw)
To: André Schwarz; +Cc: linux-ppc list
In-Reply-To: <47E216DA.8080602@matrix-vision.de>
On Thu, Mar 20, 2008 at 08:48:42AM +0100, André Schwarz wrote:
> David Gibson schrieb:
>> On Thu, Mar 20, 2008 at 01:14:45AM +0100, Wolfgang Denk wrote:
>>> In message <47DF821B.6090600@matrix-vision.de> you wrote:
>>>> I've pulled the latest git and built a mpc5200_simple system with a
>>>> minimal dts.
>>>> There's not a single char put on the console ....
>>> You did build your device tree with "-b 0", didn't you?
>> Ugh.. I really need to fix dtc to pick the default boot cpu value more
>> sensibly, don't I.
>
> I didn't specify "-b 0". This shouldn't be neccessary on a single processor
> system ! After all it's an option ... "0" should be default.
Should, yes. But dtc's pretty new, and a sensible default for -b is
one thing that isn't there.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* RE: Linuxppc-embedded Digest, Vol 43, Issue 31
From: Antoine BRUNET @ 2008-03-20 8:43 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.838.1205857983.869.linuxppc-embedded@ozlabs.org>
I respond to the message numero 3, see and of the mail.
Send Linuxppc-embedded mailing list submissions to
linuxppc-embedded@ozlabs.org
To subscribe or unsubscribe via the World Wide Web, visit
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
or, via email, send a message with subject or body 'help' to
linuxppc-embedded-request@ozlabs.org
You can reach the person managing the list at
linuxppc-embedded-owner@ozlabs.org
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Linuxppc-embedded digest..."
Today's Topics:
1. RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
(Qin Lin)
2. RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
(Qin Lin)
3. RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
(Stephen Neuendorffer)
4. [PATCH] Add Fixed PHY support for ucc_geth (Joakim Tjernlund)
5. Re: [PATCH] Add Fixed PHY support for ucc_geth (Vitaly Bordug)
----------------------------------------------------------------------
Message: 1
Date: Mon, 17 Mar 2008 19:03:38 -0700 (PDT)
From: Qin Lin <linkinge@gmail.com>
Subject: RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
To: linuxppc-embedded@ozlabs.org
Message-ID: <16112213.post@talk.nabble.com>
Content-Type: text/plain; charset=us-ascii
Hi Steve,
I think the booting message tell me that the interrupt line is connect
OK,isn't it ?
> [ 1.151038] eth0: Xilinx 10/100 EMAC at 0x40C00000 mapped to
0xD0020000, irq=2
and if you can tell me what should be care about in hard design and in
kernel config with net?
Stephen Neuendorffer wrote:
>
>
> It should... (I use it regularly on the xup board) Did you remember
> to connect the interrupt line in your design?
>
> Steve
>
> .....
>> [ 1.151038] eth0: Xilinx 10/100 EMAC at 0x40C00000 mapped to
> 0xD0020000, irq=2
> ......
>
--
View this message in context:
http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-xlnx-
tp16089631p16112213.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
------------------------------
Message: 2
Date: Mon, 17 Mar 2008 19:17:01 -0700 (PDT)
From: Qin Lin <linkinge@gmail.com>
Subject: RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
To: linuxppc-embedded@ozlabs.org
Message-ID: <16112415.post@talk.nabble.com>
Content-Type: text/plain; charset=us-ascii
HI Steve:
when i design the system ,i chose opb_emac_1.04a ,No DMA, Use interrupt ?
Is it the correct setting for the current driver?
Thanks
Stephen Neuendorffer wrote:
>
>
> It should... (I use it regularly on the xup board)
> Did you remember to connect the interrupt line in your design?
>
> Steve
>
>> -----Original Message-----
>> From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org
> [mailto:linuxppc-embedded-
>> bounces+stephen=neuendorffer.name@ozlabs.org] On Behalf Of Qin Lin
>> Sent: Monday, March 17, 2008 12:36 AM
>> To: linuxppc-embedded@ozlabs.org
>> Subject: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
>>
>>
>> HI all,
>>
>> Is anyone have the opb_emac (no DMA) work with the kernel
> linux-2.6-xlnx
>> from git.xilinx.com.
>> the message seams that it does work ,but the command ping return
> nothing!
>>
>> Could you kindly suggest me what to do?
>>
>> ps:
>> the kernel booting message
>> [ 0.258674] net_namespace: 64 bytes
>> [ 0.269780] NET: Registered protocol family 16
>> [ 0.290415] Registering device xilinx_emac:0
>> [ 0.381687] NET: Registered protocol family 2
>> [ 0.392324] IP route cache hash table entries: 2048 (order: 1, 8192
>> bytes)
>> [ 0.399556] TCP established hash table entries: 8192 (order: 4,
> 65536
>> bytes)
>> [ 0.403403] TCP bind hash table entries: 8192 (order: 3, 32768
> bytes)
>> [ 0.405409] TCP: Hash tables configured (established 8192 bind
> 8192)
>> [ 0.405489] TCP reno registered
>> [ 0.412758] sysctl table check failed: /kernel/l2cr .1.31 Missing
>> strategy
>> [ 0.413189] Call Trace:
>> [ 0.413244] [cf41feb0] [c0008178] show_stack+0x48/0x184
> (unreliable)
>> [ 0.413467] [cf41fed0] [c00303c8] set_fail+0x50/0x68
>> [ 0.413640] [cf41fef0] [c0030b54] sysctl_check_table+0x64c/0x698
>> [ 0.413724] [cf41ff20] [c0030b68] sysctl_check_table+0x660/0x698
>> [ 0.413802] [cf41ff50] [c001e810] register_sysctl_table+0x64/0xb4
>> [ 0.414141] [cf41ff70] [c01e4b1c]
> register_ppc_htab_sysctl+0x18/0x2c
>> [ 0.414311] [cf41ff80] [c01de1e4] kernel_init+0xc8/0x284
>> [ 0.414384] [cf41fff0] [c0004ab8] kernel_thread+0x44/0x60
>>
>> [ 1.116395] xilinx_emac xilinx_emac.0: MAC address is now 2: 0: 0:
> 0: 0:
>> 0
>> [ 1.123790] XEmac: using fifo mode.
>> [ 1.128188] XEmac: Detected PHY at address 0, ManufID 0x0013, Rev.
>> 0x78e2.
>> [ 1.135715] eth0: Dropping NETIF_F_SG since no checksum feature.
>> [ 1.151038] eth0: Xilinx 10/100 EMAC at 0x40C00000 mapped to
> 0xD0020000,
>> irq=2
>> [ 1.158713] eth0: XEmac id 1.4a, block id 128, type 1
>> [ 1.194661] TCP cubic registered
>> [ 1.198647] NET: Registered protocol family 1
>> [ 1.203728] NET: Registered protocol family 17
>>
>>
>> #ping 192.168.26.1 &
>> # ifconfig eth0
>> eth0 Link encap:Ethernet HWaddr 02:00:00:00:00:00
>> inet addr:192.168.26.127 Bcast:192.168.26.255
> Mask:255.255.255.0
>> UP BROADCAST RUNNING MTU:1500 Metric:1
>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:0 (0.0 B) TX bytes:672 (672.0 B)
>> Interrupt:2 Memory:40c00000-40c0ffff
>>
>> Regards
>>
>> Qin Lin
>> --
>> View this message in context:
> http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-
>> xlnx-tp16089631p16089631.html
>> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context:
http://www.nabble.com/XUPV2P-board-opb_emac-cannot-work-with-linux-2.6-xlnx-
tp16089631p16112415.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
------------------------------
Message: 3
Date: Mon, 17 Mar 2008 21:30:23 -0700
From: "Stephen Neuendorffer" <stephen.neuendorffer@xilinx.com>
Subject: RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
To: "Qin Lin" <linkinge@gmail.com>, <linuxppc-embedded@ozlabs.org>
Message-ID: <20080318043128.DDDA0ED005E@mail85-dub.bigfish.com>
Content-Type: text/plain; charset="iso-8859-1"
Yes that should work...
Steve
-----Original Message-----
From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on
behalf of Qin Lin
Sent: Mon 3/17/2008 7:17 PM
To: linuxppc-embedded@ozlabs.org
Subject: RE: XUPV2P board opb_emac cannot work with linux-2.6-xlnx
HI Steve:
when i design the system ,i chose opb_emac_1.04a ,No DMA, Use interrupt ?
Is it the correct setting for the current driver?
Thanks
Hi,
I use ml403 board and Edk 9.1 and kernel linux-2.6-xlnx 2.6.24rc8.
My emac runs normally with this kernel 2.6.24rc8.
My emac is dysigned on my bsp project with interruption and reset :
.MHS :
BEGIN opb_ethernet
PARAMETER INSTANCE = Ethernet_MAC
PARAMETER HW_VER = 1.04.a
PARAMETER C_DMA_PRESENT = 1
PARAMETER C_IPIF_RDFIFO_DEPTH = 32768
PARAMETER C_IPIF_WRFIFO_DEPTH = 32768
PARAMETER C_OPB_CLK_PERIOD_PS = 10000
PARAMETER C_BASEADDR = 0x40c00000
PARAMETER C_HIGHADDR = 0x40c0ffff
BUS_INTERFACE SOPB = opb
PORT IP2INTC_Irpt = Ethernet_MAC_IP2INTC_Irpt
PORT PHY_tx_data = fpga_0_Ethernet_MAC_PHY_tx_data
PORT PHY_tx_en = fpga_0_Ethernet_MAC_PHY_tx_en
PORT PHY_tx_clk = fpga_0_Ethernet_MAC_PHY_tx_clk
PORT PHY_tx_er = fpga_0_Ethernet_MAC_PHY_tx_er
PORT PHY_rx_er = fpga_0_Ethernet_MAC_PHY_rx_er
PORT PHY_rx_clk = fpga_0_Ethernet_MAC_PHY_rx_clk
PORT PHY_dv = fpga_0_Ethernet_MAC_PHY_dv
PORT PHY_rx_data = fpga_0_Ethernet_MAC_PHY_rx_data
PORT PHY_Mii_clk = fpga_0_Ethernet_MAC_PHY_Mii_clk
PORT PHY_Mii_data = fpga_0_Ethernet_MAC_PHY_Mii_data
PORT PHY_rst_n = fpga_0_Ethernet_MAC_PHY_rst_n
END
Be carreful the reset pin is mandatory, at first i have ommitedd this IO ans
my emac didn't work.
I have just add this reset IO and emac works properly...
I dont know if the tall of tje fifo are important but i have always done
32768.
I hope i can help you...
Antoine BRUNET
^ permalink raw reply
* Re: simple MPC5200B system
From: André Schwarz @ 2008-03-20 9:11 UTC (permalink / raw)
To: linux-ppc list
In-Reply-To: <20080320082035.GA23860@localhost.localdomain>
David Gibson schrieb:
> On Thu, Mar 20, 2008 at 08:48:42AM +0100, Andr=E9 Schwarz wrote:
>> David Gibson schrieb:
>>> On Thu, Mar 20, 2008 at 01:14:45AM +0100, Wolfgang Denk wrote:
>>>> In message <47DF821B.6090600@matrix-vision.de> you wrote:
>>>>> I've pulled the latest git and built a mpc5200_simple system with a=
=20
>>>>> minimal dts.
>>>>> There's not a single char put on the console ....
>>>> You did build your device tree with "-b 0", didn't you?
>>> Ugh.. I really need to fix dtc to pick the default boot cpu value mor=
e
>>> sensibly, don't I.
>> I didn't specify "-b 0". This shouldn't be neccessary on a single proc=
essor=20
>> system ! After all it's an option ... "0" should be default.
>=20
> Should, yes. But dtc's pretty new, and a sensible default for -b is
> one thing that isn't there.
>=20
ok - but this has not caused my (solved) problem. dtc is working fine=20
for me :-)
MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler - Registergeric=
ht: Amtsgericht Stuttgart, HRB 271090
Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* Re: [PATCH 2/2] Force 4K IOPages when eHEA is present in the machine.
From: Paul Mackerras @ 2008-03-20 9:23 UTC (permalink / raw)
To: Nathan Lynch; +Cc: Olof Johansson, linuxppc-dev, Jan-Bernd Themann
In-Reply-To: <20080320071858.GS4712@localdomain>
Nathan Lynch writes:
> Searching ibm,drc-names is necessary, but is it sufficient? That is,
> can there be a system that has an HEA adapter without that property
> being present? Thinking in particular about single-partition systems
> that run without an HMC attached.
PAPR doesn't seem to say clearly one way or the other. For 2.6.25,
the best thing is probably just to force 4k pages on all pSeries
machines. Given that this is only for access to PCI devices, the
actual access is going to be slow enough that an extra TLB miss here
or there won't matter too much.
Paul.
^ permalink raw reply
* Re: simple MPC5200B system
From: Stefan Roese @ 2008-03-20 9:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: André Schwarz, David Gibson
In-Reply-To: <20080320082035.GA23860@localhost.localdomain>
On Thursday 20 March 2008, David Gibson wrote:
> >>> You did build your device tree with "-b 0", didn't you?
> >>
> >> Ugh.. I really need to fix dtc to pick the default boot cpu value more
> >> sensibly, don't I.
> >
> > I didn't specify "-b 0". This shouldn't be neccessary on a single
> > processor system ! After all it's an option ... "0" should be default.
>
> Should, yes. But dtc's pretty new, and a sensible default for -b is
> one thing that isn't there.
ACK. I have run into a problem on the Sequoia (440EPx) lately, where the FPU
was not initialized correctly because of the missing "-b 0". Please add this
as default.
Best regards,
Stefan
^ permalink raw reply
* [PATCH] [POWERPC] Add "amcc, haleakala" to the toplevel compatible property
From: Stefan Roese @ 2008-03-20 10:33 UTC (permalink / raw)
To: linuxppc-dev
Currently Haleakala uses the Kilauea platform code. This patch adds
"haleakala" to the compatible property, in case later kernel versions
will introduce a Haleakala platform code.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/haleakala.dts | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/haleakala.dts b/arch/powerpc/boot/dts/haleakala.dts
index ae68fef..02e4ba3 100644
--- a/arch/powerpc/boot/dts/haleakala.dts
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -12,7 +12,7 @@
#address-cells = <1>;
#size-cells = <1>;
model = "amcc,haleakala";
- compatible = "amcc,kilauea";
+ compatible = "amcc,haleakala", "amcc,kilauea";
dcr-parent = <&/cpus/cpu@0>;
aliases {
--
1.5.4.4
^ permalink raw reply related
* Re: [PATCH 1/2] Implement of_flat_dt_search() and use it for of_flat_dt_is_compatible.
From: Benjamin Herrenschmidt @ 2008-03-20 9:41 UTC (permalink / raw)
To: Tony Breeds
Cc: Olof Johansson, linuxppc-dev, Paul Mackerras, Jan-Bernd Themann
In-Reply-To: <63cdefde19cb2a4adc17ed771f21261673428ce7.1205987625.git.tony@bakeyournoodle.com>
On Thu, 2008-03-20 at 15:33 +1100, Tony Breeds wrote:
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
> ---
What about a comment ? :-)
> arch/powerpc/kernel/prom.c | 21 ++++++++++++++-------
> include/asm-powerpc/prom.h | 2 ++
> 2 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index eac97f4..f73e18b 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -205,25 +205,32 @@ void* __init of_get_flat_dt_prop(unsigned long node, const char *name,
> } while(1);
> }
>
> -int __init of_flat_dt_is_compatible(unsigned long node, const char *compat)
> +int __init of_flat_dt_search(unsigned long node, const char *str,
> + const char *prop_name)
> {
> - const char* cp;
> - unsigned long cplen, l;
> + const char *cp;
> + unsigned long plen, l;
>
> - cp = of_get_flat_dt_prop(node, "compatible", &cplen);
> + cp = of_get_flat_dt_prop(node, prop_name, &plen);
> if (cp == NULL)
> return 0;
> - while (cplen > 0) {
> - if (strncasecmp(cp, compat, strlen(compat)) == 0)
> + while (plen > 0) {
> + if (strncasecmp(cp, str, strlen(str)) == 0)
> return 1;
> l = strlen(cp) + 1;
> cp += l;
> - cplen -= l;
> + plen -= l;
> }
>
> return 0;
> }
>
> +int __init of_flat_dt_is_compatible(unsigned long node, const char *compat)
> +{
> +
> + return of_flat_dt_search(node, compat, "compatible");
> +}
> +
> static void *__init unflatten_dt_alloc(unsigned long *mem, unsigned long size,
> unsigned long align)
> {
> diff --git a/include/asm-powerpc/prom.h b/include/asm-powerpc/prom.h
> index 78b7b0d..7b587f1 100644
> --- a/include/asm-powerpc/prom.h
> +++ b/include/asm-powerpc/prom.h
> @@ -134,6 +134,8 @@ extern int __init of_scan_flat_dt(int (*it)(unsigned long node,
> void *data);
> extern void* __init of_get_flat_dt_prop(unsigned long node, const char *name,
> unsigned long *size);
> +extern int __init of_flat_dt_search(unsigned long node, const char *str,
> + const char *prop_name);
> extern int __init of_flat_dt_is_compatible(unsigned long node, const char *name);
> extern unsigned long __init of_get_flat_dt_root(void);
>
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: Matt Sealey @ 2008-03-20 11:32 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20080319152722.GA9208@aepfle.de>
This was a good catch. IPIC is the controller on the MPC83xx type boards (and
MPC5121E) so building a kernel with this controller code in there, but without
the controller present, should gladly fail.
However removing the boards from the config does not fix this obvious error. I
like your patch better than changing the config options to disable entire
swathes of board support :D
What I'm concerned about is that the IPIC code is registering with sysfs even
though there is no controller present. How on EARTH does it even get that far?
If ipic_init fails, no further code should be run from this file, in my view.
subsys_initcall(init_ipic_sysfs); <-- this, in my eyes, is the culprit. If
init_ipic() runs, init_ipic_sysfs should be called from that, not left for
some further subsystem to blindly try and register sysfs nodes for devices
which may not even be present..
I'd love someone to explain to me how this works and why, and why it isn't
braindead? :D
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Olaf Hering wrote:
> On Mon, Mar 17, Olaf Hering wrote:
>
>> The global primary_ipic in arch/powerpc/sysdev/ipic.c can remain NULL if
>> ipic_init() fails. init_ipic_sysfs() will crash in that case.
>>
>> Something like this may fix it:
>>
>> Index: linux-2.6.25-rc6/arch/powerpc/sysdev/ipic.c
>> ===================================================================
>> --- linux-2.6.25-rc6.orig/arch/powerpc/sysdev/ipic.c
>> +++ linux-2.6.25-rc6/arch/powerpc/sysdev/ipic.c
>> @@ -906,7 +906,7 @@ static int __init init_ipic_sysfs(void)
>> {
>> int rc;
>>
>> - if (!primary_ipic->regs)
>> + if (!primary_ipic || !primary_ipic->regs)
>> return -ENODEV;
>> printk(KERN_DEBUG "Registering ipic with sysfs...\n");
>
> ipic_init() is not called for every board.
> This change for the used config fixes the crash as well.
>
> @@ -168,14 +168,14 @@ CONFIG_PPC_MULTIPLATFORM=y
> # CONFIG_PPC_86xx is not set
> CONFIG_CLASSIC32=y
> CONFIG_PPC_CHRP=y
> -CONFIG_PPC_MPC512x=y
> -CONFIG_PPC_MPC5121=y
> -CONFIG_MPC5121_ADS=y
> +# CONFIG_PPC_MPC512x is not set
> +# CONFIG_PPC_MPC5121 is not set
> +# CONFIG_MPC5121_ADS is not set
> CONFIG_PPC_MPC52xx=y
> -CONFIG_PPC_MPC5200_SIMPLE=y
> +# CONFIG_PPC_MPC5200_SIMPLE is not set
> CONFIG_PPC_EFIKA=y
> # CONFIG_PPC_LITE5200 is not set
> -CONFIG_PPC_MPC5200_BUGFIX=y
> +# CONFIG_PPC_MPC5200_BUGFIX is not set
> CONFIG_PPC_PMAC=y
> # CONFIG_PPC_CELL is not set
> # CONFIG_PPC_CELL_NATIVE is not set
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Xenomai on TQ MPC5200
From: Thomas Häberle @ 2008-03-20 13:09 UTC (permalink / raw)
To: linuxppc-dev
Hello!
My target hardware is a MPC5200 on a TQ STK52xx.
I am developing in a Linked Setup with ELDK 3.1.1 under a Debian Linux
(Release 2.6.18-4-686 ; gcc 4.1.2).
The whole ELDK was already used in a former project with identical
hardware and some early tests I ran showed that it works fine (as far as
I can see).
My goal is to get a real time Linux OS running on the target (preferably
Xenomai) and establish a RT ethernet connection with a identical
hardware setup (planning to use RTnet). But I am somehow stuck in the
first place for I can't get the kernel built:
I tried quite a number of Kernel-Xenomai-Adeos-Version-combinations in
the past four days without any actual success.
Yesterday I downloaded the Linuxppc_2_4_develop-sources from the GIT
repository of the DENX site and set them to the exact point where the
Adeos-Patch coming along with Xenomai 2.4.2 is build for (commit # ).
The patch worked fine (ran trough), I configured the kernel and built
the dependencies, but I am still unable to crosscompile the kernel and
am also slowly running out of ideas.
I am relatively new to this part of the software world, so forgive me
for my maybe basic questions:
I found no explicit information on the web, whether Xenomai can be run
on my specific target at all:
Has anyone tried or knows something about that?
Or where could I check whether it is (besides asking TQ of course)?
Maybe the better way would be trying with RTAI?
Are there any known oddities of the STK52xx and/or MPC5200?
Do I have to adapt my ELDK in any further way to get things going and
using the DENX-sources (okay I guess this is hard to say without
detailed information about my ELDK setup...)?
Any other helpful experience, hints or tricks?
Thanks & Greetings,
Thomas
^ permalink raw reply
* Re: Trouble with SCC UART ports when moving from ppc to powerpc
From: Laurent Pinchart @ 2008-03-20 13:39 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080317153326.GA2644@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]
Hi Scott,
On Monday 17 March 2008 16:33, Scott Wood wrote:
> On Mon, Mar 10, 2008 at 01:17:01PM +0100, Laurent Pinchart wrote:
> > On Friday 07 March 2008 17:21, Scott Wood wrote:
> > > cpm2_reset() doesn't currently actually reset the CPM, for some reason
> > > (unlike cpm1). This should probably be fixed, though then we'd have to
> > > deal with assigning SMC parameter RAM addresses ourselves.
> >
> > I had overlooked that. Resetting the CPM in cpm2_reset() helps. Is there
> > any reason not to rset the CPM in cpm2_reset() ?
>
> The only issue I'm aware of other than the SMC parameter RAM relocation is
> that the reset can't happen if the early udbg printk is being used.
>
> > How should SMC parameter RAM assignment be handled ? I'm not very
> > familiar with the CPM1,
>
> CPM1 has hardcoded SMC parameter RAM addresses, so it's not relevant here.
>
> > but for CPM2 the cpm_uart driver could easily cpm_dpalloc() parameter
> > RAM.
>
> It can, yes. Patches welcome. :-)
I'm working on a patch. I'm not sure how to handle the early udbg printk
problem, so the first version will just ignore it.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Xenomai on TQ MPC5200
From: Wolfgang Grandegger @ 2008-03-20 13:34 UTC (permalink / raw)
To: Thomas Häberle; +Cc: linuxppc-dev
In-Reply-To: <47E2620C.4020406@vipco.de>
[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]
Thomas Häberle wrote:
> Hello!
>
> My target hardware is a MPC5200 on a TQ STK52xx.
> I am developing in a Linked Setup with ELDK 3.1.1 under a Debian Linux
> (Release 2.6.18-4-686 ; gcc 4.1.2).
> The whole ELDK was already used in a former project with identical
> hardware and some early tests I ran showed that it works fine (as far as
> I can see).
>
> My goal is to get a real time Linux OS running on the target (preferably
> Xenomai) and establish a RT ethernet connection with a identical
> hardware setup (planning to use RTnet). But I am somehow stuck in the
> first place for I can't get the kernel built:
> I tried quite a number of Kernel-Xenomai-Adeos-Version-combinations in
> the past four days without any actual success.
>
> Yesterday I downloaded the Linuxppc_2_4_develop-sources from the GIT
> repository of the DENX site and set them to the exact point where the
> Adeos-Patch coming along with Xenomai 2.4.2 is build for (commit # ).
> The patch worked fine (ran trough), I configured the kernel and built
> the dependencies, but I am still unable to crosscompile the kernel and
> am also slowly running out of ideas.
>
> I am relatively new to this part of the software world, so forgive me
> for my maybe basic questions:
> I found no explicit information on the web, whether Xenomai can be run
> on my specific target at all:
> Has anyone tried or knows something about that?
> Or where could I check whether it is (besides asking TQ of course)?
> Maybe the better way would be trying with RTAI?
> Are there any known oddities of the STK52xx and/or MPC5200?
> Do I have to adapt my ELDK in any further way to get things going and
> using the DENX-sources (okay I guess this is hard to say without
> detailed information about my ELDK setup...)?
> Any other helpful experience, hints or tricks?
I have a STK52xx on my desk running Xenomai and RTnet under DENX Linux
2.4.25. I have attached my installation README. But your request is
off-topic here. Please switch to an appropriate list for further
questions, e.g. Xenomai-help of RTnet.
Wolfgang.
[-- Attachment #2: README.rtnet --]
[-- Type: text/plain, Size: 3768 bytes --]
README on how to configure, build, install and use RTnet with Linux 2.4.25
==========================================================================
For cross development, please use the ELDK version 3.1.1. For further
information check http://www.denx.de/wiki/DULG/ELDK.
This README is for the TQM5200 evaluation board. I actually use an
EEPRO100 PCI NIC to boot Linux and mount the root file system via NFS.
Get and unfold sources:
-----------------------
$ cd <work-dir>
$ export WORKDIR=$PWD
- DENX Linux 2.4.25
$ cd $WORKDIR
$ git clone git://www.denx.de/git/linuxppc_2_4_devel.git
$ export KERNELDIR=$PWD/linuxppc_2_4_devel
- Xenomai 2.3.5
$ cd $WORKDIR
$ wget http://download.gna.org/xenomai/stable/xenomai-2.3.5.tar.bz2
$ tar xjf xenomai-2.3.5.tar.bz2
$ export XENODIR=$PWD/xenomai-2.3.5
- RTnet SVN trunk (>= 0.9.10rc1):
$ cd $WORKDIR
$ svn co https://rtnet.svn.sourceforge.net/svnroot/rtnet/trunk
$ export RTNETDIR=$PWD/trunk/rtnet
Configure, build and install kernel and user space binaries:
------------------------------------------------------------
- Required environment settings
$ export CROSS_COMPILE=ppc_6xx-
$ export DESTDIR=/opt/eldk/ppc_6xx
- Configure and build Xenomai patched kernel
$ cd $KERNELDIR
$ patch -p1 < <path>/linuxppc_2_4_devel-wait-event.patch
$ patch -p1 < <path>/linuxppc_2_4_devel-fec.patch
$ make TQM5200_config
$ cd $XENODIR
$ ./scripts/prepare-kernel.sh --linux=$KERNELDIR --arch=ppc --verbose
$ cd $KERNELDIR
$ make menuconfig
... check loadable module support ...
... disable FEC driver ...
MPC5xxx I/O Options --->
[*] Use USE Motorola BestComm API Implementation
[ ] FEC Ethernet
... enable EEPRO100 PCI driver ...
Network device support --->
Ethernet (10 or 100Mbit) --->
[*] EISA, VLB, PCI and on board controllers
<*> EtherExpressPro/100 support (eepro100, ...
... exit and save default configuration ...
$ make dep
$ make uImage
$ cp -pv arch/ppc/boot/images/uImage /tftpboot
- Configure, build and install Xenomai user space stuff
$ cd $XENODIR
$ ./configure --host=ppc-linux --prefix=/root/xenomai
$ make
$ make install
- Configure, build and install RTnet
$ cd $RTNETDIR
$ patch -p1 < <path>rt-mpc52xx-fec.patch
$ ./configure --host=ppc-linux \
--with-linux=$KERNELDIR \
--with-rtext-config=$DESTDIR/root/xenomai/bin/xeno-config \
--disable-e1000 --disable-8139 --disable-8139too \
--enable-mpc52xx-fec --enable-eepro100 \
--prefix=/root/xenomai --enable-proxy
$ make
$ make install
Load, configure and run RTnet on the target:
--------------------------------------------
Check if the device file /dev/rtnet exists. If not, create it with:
# mknod /dev/rtnet c 10 240
I use the following script to load the RTnet modules and to startup the
network:
# cat load-rtnet
export RTNET=/root/xenomai
moddir=$RTNET/modules
export PATH=$PATH:$RTNET/sbin:$RTNET/bin:$RTNET/examples/xenomai/posix
export LD_LIBRARY_PATH=$RTNET/lib
insmod -m $moddir/rtnet.o > /root/insmod.log
insmod -m $moddir/rtipv4.o >> /root/insmod.log
insmod -m $moddir/rt_mpc52xx_fec.o >> /root/insmod.log
rtifconfig rteth0 up 172.16.0.20
rtroute solicit 172.16.0.1 dev rteth0
rtifconfig
rtroute
Then you can use "rtping" to check the connection:
# rtping 172.16.0.1
Testing:
--------
For testing RTnet communication and response time, the example RTnet
applications rtt_sender and rtt_responder are quite useful. You can make
and install them as shown below:
$ cd $RTNETDIR/examples/xenomai/posix/
$ make
$ make install
In $DISTDIR/rtt-examples are the corresponding programs for plain
Linux.
^ permalink raw reply
* Oops with TQM5200 on TQM5200
From: Wolfgang Grandegger @ 2008-03-20 14:18 UTC (permalink / raw)
To: ppc-dev
[-- Attachment #1: Type: text/plain, Size: 152 bytes --]
Hello,
I just tried Linux 2.6.25-rc6 on my TQM5200 module and got the attached
oops. Are there any known patches fixing the problems?
TIA.
Wolfgang.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: oops.log --]
[-- Type: text/x-log; name="oops.log", Size: 6537 bytes --]
## Booting image at 00200000 ...
Image Name: Linux-2.6.25-rc6-01058-gf8937ce-
Created: 2008-03-20 13:19:36 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1697503 Bytes = 1.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using the fdt at 0x400000
[ 0.000000] Using mpc5200-simple-platform machine description
[ 0.000000] Linux version 2.6.25-rc6-01058-gf8937ce-dirty (wolf@lancy.lan.de) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #14 Thu Mar 20 14:19:25 CET 2008
[ 0.000000] PCI host bridge /pci@f0000d00 (primary) ranges:
[ 0.000000] MEM 0x0000000080000000..0x000000008fffffff -> 0x0000000080000000 Prefetch
[ 0.000000] MEM 0x0000000090000000..0x000000009fffffff -> 0x0000000090000000
[ 0.000000] IO 0x00000000a0000000..0x00000000a0ffffff -> 0x0000000000000000
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 16384
[ 0.000000] Normal 16384 -> 16384
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0 -> 16384
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256
[ 0.000000] Kernel command line: root=/dev/nfs rw nfsroot=10.0.30.2:/opt/eldk/ppc_6xx ip=10.0.30.210:10.0.30.2:::tqm5200:eth0:off panic=1 console=ttyPSC0,115200
[ 0.000000] MPC52xx PIC is up and running!
[ 0.000000] PID hash table entries: 256 (order: 8, 1024 bytes)
[ 0.000014] clocksource: timebase mult[79364d9] shift[22] registered
[ 0.000241] console [ttyPSC0] enabled
[ 0.004376] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.008573] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.021186] Memory: 61236k/65536k available (3328k kernel code, 4236k reserved, 120k data, 149k bss, 180k init)
[ 0.024179] SLUB: Genslabs=12, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
[ 0.120160] Mount-cache hash table entries: 512
[ 0.128111] net_namespace: 152 bytes
[ 0.133162] NET: Registered protocol family 16
[ 0.150957] PCI: Probing PCI hardware
[ 0.168836] SCSI subsystem initialized
[ 0.174379] usbcore: registered new interface driver usbfs
[ 0.176629] usbcore: registered new interface driver hub
[ 0.180942] usbcore: registered new device driver usb
[ 0.200000] Time: timebase clocksource has been installed.
[ 0.208268] NET: Registered protocol family 2
[ 0.252350] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.260660] TCP established hash table entries: 2048 (order: 2, 16384 bytes)
[ 0.268181] TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.272125] TCP: Hash tables configured (established 2048 bind 2048)
[ 0.276028] TCP reno registered
[ 0.338145] JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
[ 0.342627] io scheduler noop registered
[ 0.344114] io scheduler anticipatory registered (default)
[ 0.348032] io scheduler deadline registered
[ 0.352847] io scheduler cfq registered
[ 0.778513] Generic RTC Driver v1.07
[ 0.780658] Serial: MPC52xx PSC UART driver
[ 0.784474] f0002000.serial: ttyPSC0 at MMIO 0xf0002000 (irq = 129) is a MPC52xx PSC
[ 0.793028] f0002200.serial: ttyPSC1 at MMIO 0xf0002200 (irq = 130) is a MPC52xx PSC
[ 0.797297] f0002400.serial: ttyPSC2 at MMIO 0xf0002400 (irq = 131) is a MPC52xx PSC
[ 0.814501] brd: module loaded
[ 0.823106] loop: module loaded
[ 0.824132] vcan: Virtual CAN interface driver
[ 0.828033] slcan: serial line CAN interface driver
[ 0.832030] slcan: 10 dynamic interface channels.
[ 0.840408] mpc52xx-mscan mpc52xx-mscan.0: probe for port at 0xC5062900 done (irq 145)
[ 0.846001] mpc52xx-mscan mpc52xx-mscan.1: probe for port at 0xC5064980 done (irq 146)
[ 0.852251] Unable to handle kernel paging request for data at address 0x0000000c
[ 0.860026] Faulting instruction address: 0xc0017fec
[ 0.864036] Oops: Kernel access of bad area, sig: 11 [#1]
[ 0.868000] mpc5200-simple-platform
[ 0.868000] Modules linked in:
[ 0.868000] NIP: c0017fec LR: c0019064 CTR: 00000010
[ 0.868000] REGS: c381fd20 TRAP: 0300 Not tainted (2.6.25-rc6-01058-gf8937ce-dirty)
[ 0.868000] MSR: 00009032 <EE,ME,IR,DR> CR: 28000028 XER: 2000005f
[ 0.868000] DAR: 0000000c, DSISR: 20000000
[ 0.868000] TASK = c3812400[1] 'swapper' THREAD: c381e000
[ 0.868000] GPR00: 00000010 c381fdd0 c3812400 00000100 00000008 00000008 fcff7000 c382ca00
[ 0.868000] GPR08: 00002000 00000000 00000000 f00035a9 f0003000 fefd7f7f 07fb3000 04000000
[ 0.868000] GPR16: 00000000 007fff00 00000000 c02c0000 c0340000 c0330000 07fb2678 00000000
[ 0.868000] GPR24: c0330000 00000008 c0360000 00000100 00000008 f0003184 000005f2 00000000
[ 0.868000] NIP [c0017fec] bcom_task_alloc+0x30/0x198
[ 0.868000] LR [c0019064] bcom_fec_rx_init+0x24/0x74
[ 0.868000] Call Trace:
[ 0.868000] [c381fdd0] [c006863c] __get_vm_area_node+0x80/0x1b8 (unreliable)
[ 0.868000] [c381fe00] [c0019064] bcom_fec_rx_init+0x24/0x74
[ 0.868000] [c381fe20] [c028428c] 0xc028428c
[ 0.868000] [c381fe60] [c01ea26c] of_platform_device_probe+0x58/0x80
[ 0.868000] [c381fe80] [c017ddd0] driver_probe_device+0xb8/0x1cc
[ 0.868000] [c381fea0] [c017e0bc] __driver_attach+0xcc/0xf8
[ 0.868000] [c381fec0] [c017c93c] bus_for_each_dev+0x58/0x94
[ 0.868000] [c381fef0] [c017db00] driver_attach+0x24/0x34
[ 0.868000] [c381ff00] [c017d9c0] bus_add_driver+0x188/0x250
[ 0.868000] [c381ff20] [c017e598] driver_register+0x48/0x130
[ 0.868000] [c381ff40] [c01ea48c] of_register_driver+0x54/0x70
[ 0.868000] [c381ff50] [c032c6b4] mpc52xx_fec_init+0x64/0x80
[ 0.868000] [c381ff70] [c0313858] kernel_init+0x98/0x28c
[ 0.868000] [c381fff0] [c001229c] kernel_thread+0x44/0x60
[ 0.868000] Instruction dump:
[ 0.868000] 7c0802a6 9421ffd0 bf210014 3f40c036 7c7b1b78 7c992378 90010034 38000010
[ 0.868000] 7cbc2b78 813a5224 7c0903a6 3be00000 <8129000c> 80090004 57fd2834 2f800000
[ 0.868081] ---[ end trace ab0c326e02602f58 ]---
[ 0.872036] Kernel panic - not syncing: Attempted to kill init!
[ 0.876034] Rebooting in 1 seconds..
U-Boot 1.3.1-g5f7f945a-dirty (Dec 19 2007 - 16:58:01)
CPU: MPC5200B v2.2, Core v1.4 at 396 MHz
Bus 132 MHz, IPB 132 MHz, PCI 66 MHz
Board: TQM5200 (TQ-Components GmbH)
on a STK52xx carrier board
I2C: 85 kHz, ready
DRAM: 128 MB
^ permalink raw reply
* Re: Oops with TQM5200 on TQM5200
From: Grant Likely @ 2008-03-20 14:41 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: ppc-dev
In-Reply-To: <47E2723D.1090101@grandegger.com>
On Thu, Mar 20, 2008 at 8:18 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
> Hello,
>
> I just tried Linux 2.6.25-rc6 on my TQM5200 module and got the attached
> oops. Are there any known patches fixing the problems?
>
> TIA.
Hmm, I haven't seen this issue on any of my 5200 boards. To state the
obvious, it's an issue in the bestcomm code. What source line is
"bcom_task_alloc+0x30/0x198" on?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH 0/3] [POWERPC] [RFC] of_serial and boot patches introduction
From: John Linn @ 2008-03-20 14:42 UTC (permalink / raw)
To: linuxppc-dev, grant.likely, jwboyer
In-Reply-To: <12060236493879-git-send-email-john.linn@xilinx.com>
I am sending a series of patches that fix the OF serial driver and add
support to it and the boot for the Xilinx UART 16550.
I think we have tried to satisfy previous concerns about UARTs which are
non-standard as the Xilinx 16550 is (register spacing and offset).
We would like to have these pulled into 2.6.26.
Thanks,
John
^ permalink raw reply
* [PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart 16550.
From: John Linn @ 2008-03-20 14:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: John Linn
In-Reply-To: <12060242324116-git-send-email-john.linn@xilinx.com>
The Xilinx 16550 uart core is not a standard 16550, because it uses
word-based addressing rather than byte-based addressing. As a result,
it is not compatible with the open firmware 'ns16550' compatible
binding. This code introduces new bindings, which pass the correct
register base and regshift properties to the uart driver to enable
this core to be used. Doing this cleanly required some refactoring of
the existing code.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Signed-off-by: John Linn <john.linn@xilinx.com>
---
drivers/serial/of_serial.c | 47 ++++++++++++++++++++++++++++++-------------
1 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 2efb892..910c94f 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -20,13 +20,15 @@
struct of_serial_info {
int type;
int line;
+ int regshift;
+ int regoffset;
};
/*
* Fill a struct uart_port for a given device node
*/
static int __devinit of_platform_serial_setup(struct of_device *ofdev,
- int type, struct uart_port *port)
+ struct of_serial_info *info, struct uart_port *port)
{
struct resource resource;
struct device_node *np = ofdev->node;
@@ -48,17 +50,16 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
}
spin_lock_init(&port->lock);
- port->mapbase = resource.start;
+ port->mapbase = resource.start + info->regoffset;
port->irq = irq_of_parse_and_map(np, 0);
port->iotype = UPIO_MEM;
- port->type = type;
+ port->type = info->type;
+ port->regshift = info->regshift;
port->uartclk = *clk;
port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
| UPF_FIXED_PORT;
port->dev = &ofdev->dev;
- /* If current-speed was set, then try not to change it. */
- if (spd)
- port->custom_divisor = *clk / (16 * (*spd));
+ port->custom_divisor = *clk / (16 * (*spd));
return 0;
}
@@ -81,8 +82,9 @@ static int __devinit of_platform_serial_probe(struct of_device *ofdev,
if (info == NULL)
return -ENOMEM;
- port_type = (unsigned long)id->data;
- ret = of_platform_serial_setup(ofdev, port_type, &port);
+ memcpy(info, id->data, sizeof(struct of_serial_info));
+ port_type = info->type;
+ ret = of_platform_serial_setup(ofdev, info, &port);
if (ret)
goto out;
@@ -100,7 +102,6 @@ static int __devinit of_platform_serial_probe(struct of_device *ofdev,
if (ret < 0)
goto out;
- info->type = port_type;
info->line = ret;
ofdev->dev.driver_data = info;
return 0;
@@ -128,15 +129,33 @@ static int of_platform_serial_remove(struct of_device *ofdev)
return 0;
}
+static struct of_serial_info __devinitdata ns8250_info = { .type = PORT_8250 };
+static struct of_serial_info __devinitdata ns16450_info = { .type = PORT_16450 };
+static struct of_serial_info __devinitdata ns16550_info = { .type = PORT_16550 };
+static struct of_serial_info __devinitdata ns16750_info = { .type = PORT_16750 };
+static struct of_serial_info __devinitdata xilinx_16550_info = {
+ .type = PORT_16550,
+ .regshift = 2,
+ .regoffset = 3,
+};
+static struct of_serial_info __devinitdata unknown_info = { .type = PORT_UNKNOWN };
+
/*
* A few common types, add more as needed.
*/
static struct of_device_id __devinitdata of_platform_serial_table[] = {
- { .type = "serial", .compatible = "ns8250", .data = (void *)PORT_8250, },
- { .type = "serial", .compatible = "ns16450", .data = (void *)PORT_16450, },
- { .type = "serial", .compatible = "ns16550", .data = (void *)PORT_16550, },
- { .type = "serial", .compatible = "ns16750", .data = (void *)PORT_16750, },
- { .type = "serial", .data = (void *)PORT_UNKNOWN, },
+ { .type = "serial", .compatible = "ns8250", .data = &ns8250_info, },
+ { .type = "serial", .compatible = "ns16450", .data = &ns16450_info, },
+ { .type = "serial", .compatible = "ns16550", .data = &ns16550_info, },
+ { .type = "serial", .compatible = "ns16750", .data = &ns16750_info, },
+ { .type = "serial", .compatible = "xlnx,opb-uart16550-1.00.c", .data = &xilinx_16550_info, },
+ { .type = "serial", .compatible = "xlnx,opb-uart16550-1.00.d", .data = &xilinx_16550_info, },
+ { .type = "serial", .compatible = "xlnx,opb-uart16550-1.00.e", .data = &xilinx_16550_info, },
+ { .type = "serial", .compatible = "xlnx,plb-uart16550-1.00.c", .data = &xilinx_16550_info, },
+ { .type = "serial", .compatible = "xlnx,xps-uart16550-1.00.a", .data = &xilinx_16550_info, },
+ { .type = "serial", .compatible = "xlnx,xps-uart16550-2.00.a", .data = &xilinx_16550_info, },
+ { .type = "serial", .compatible = "xlnx,xps-uart16550-2.00.b", .data = &xilinx_16550_info, },
+ { .type = "serial", .data = &unknown_info, },
{ /* end of list */ },
};
--
1.5.2.1
^ permalink raw reply related
* [PATCH 1/3] [POWERPC] of_serial: Fix possible null dereference.
From: John Linn @ 2008-03-20 14:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: John Linn
From: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
The of_serial driver queries the current-speed property and attempts
to use it to register the custom_divisor property of the uart_port.
However, if current-speed is not set, then this code will dereference
a bad pointer. The fix is to only set custom_divisor when a
current-speed property appears in the device tree.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Signed-off-by: John Linn <john.linn@xilinx.com>
---
drivers/serial/of_serial.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index a64d858..2efb892 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -56,7 +56,9 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
| UPF_FIXED_PORT;
port->dev = &ofdev->dev;
- port->custom_divisor = *clk / (16 * (*spd));
+ /* If current-speed was set, then try not to change it. */
+ if (spd)
+ port->custom_divisor = *clk / (16 * (*spd));
return 0;
}
--
1.5.2.1
^ 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