* [PATCH -mm 3/4] x86_64 ia32 ptrace: use compat_ptrace_request for siginfo
From: Roland McGrath @ 2008-03-13 8:33 UTC (permalink / raw)
To: Paul Mackerras, Anton Blanchard
Cc: linuxppc-dev, Ingo Molnar, Thomas Gleixner, Andrew Morton,
linux-kernel
In-Reply-To: <20080313083107.8BDE926F992@magilla.localdomain>
This removes the special-case handling for PTRACE_GETSIGINFO
and PTRACE_SETSIGINFO from x86_64's sys32_ptrace. The generic
compat_ptrace_request code handles these.
Signed-off-by: Roland McGrath <roland@redhat.com>
---
arch/x86/kernel/ptrace.c | 30 +-----------------------------
1 files changed, 1 insertions(+), 29 deletions(-)
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 77d9ddd..42305fa 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1184,32 +1184,6 @@ static int genregs32_set(struct task_struct *target,
return ret;
}
-static long ptrace32_siginfo(unsigned request, u32 pid, u32 addr, u32 data)
-{
- siginfo_t __user *si = compat_alloc_user_space(sizeof(siginfo_t));
- compat_siginfo_t __user *si32 = compat_ptr(data);
- siginfo_t ssi;
- int ret;
-
- if (request == PTRACE_SETSIGINFO) {
- memset(&ssi, 0, sizeof(siginfo_t));
- ret = copy_siginfo_from_user32(&ssi, si32);
- if (ret)
- return ret;
- if (copy_to_user(si, &ssi, sizeof(siginfo_t)))
- return -EFAULT;
- }
- ret = sys_ptrace(request, pid, addr, (unsigned long)si);
- if (ret)
- return ret;
- if (request == PTRACE_GETSIGINFO) {
- if (copy_from_user(&ssi, si, sizeof(siginfo_t)))
- return -EFAULT;
- ret = copy_siginfo_to_user32(si32, &ssi);
- }
- return ret;
-}
-
asmlinkage long sys32_ptrace(long request, u32 pid, u32 addr, u32 data)
{
struct task_struct *child;
@@ -1255,11 +1229,9 @@ asmlinkage long sys32_ptrace(long request, u32 pid, u32 addr, u32 data)
case PTRACE_SETFPXREGS:
case PTRACE_GETFPXREGS:
case PTRACE_GETEVENTMSG:
- break;
-
case PTRACE_SETSIGINFO:
case PTRACE_GETSIGINFO:
- return ptrace32_siginfo(request, pid, addr, data);
+ break;
}
child = ptrace_get_task_struct(pid);
^ permalink raw reply related
* [PATCH -mm 4/4] x86_64 ia32 ptrace: convert to compat_arch_ptrace
From: Roland McGrath @ 2008-03-13 8:34 UTC (permalink / raw)
To: Paul Mackerras, Anton Blanchard
Cc: linuxppc-dev, Ingo Molnar, Thomas Gleixner, Andrew Morton,
linux-kernel
In-Reply-To: <20080313083107.8BDE926F992@magilla.localdomain>
Now that there are no more special cases in sys32_ptrace, we
can convert to using the generic compat_sys_ptrace entry point.
The sys32_ptrace function gets simpler and becomes compat_arch_ptrace.
Signed-off-by: Roland McGrath <roland@redhat.com>
---
arch/x86/ia32/ia32entry.S | 2 +-
arch/x86/kernel/ptrace.c | 65 +++++---------------------------------------
include/asm-x86/ptrace.h | 2 +
3 files changed, 11 insertions(+), 58 deletions(-)
diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index 8022d3c..b42d009 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -426,7 +426,7 @@ ia32_sys_call_table:
.quad sys_setuid16
.quad sys_getuid16
.quad compat_sys_stime /* stime */ /* 25 */
- .quad sys32_ptrace /* ptrace */
+ .quad compat_sys_ptrace /* ptrace */
.quad sys_alarm
.quad sys_fstat /* (old)fstat */
.quad sys_pause
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 42305fa..e36c0f3 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -1184,67 +1184,16 @@ static int genregs32_set(struct task_struct *target,
return ret;
}
-asmlinkage long sys32_ptrace(long request, u32 pid, u32 addr, u32 data)
+long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
+ compat_ulong_t caddr, compat_ulong_t cdata)
{
- struct task_struct *child;
- struct pt_regs *childregs;
+ unsigned long addr = caddr;
+ unsigned long data = cdata;
void __user *datap = compat_ptr(data);
int ret;
__u32 val;
switch (request) {
- case PTRACE_TRACEME:
- case PTRACE_ATTACH:
- case PTRACE_KILL:
- case PTRACE_CONT:
- case PTRACE_SINGLESTEP:
- case PTRACE_SINGLEBLOCK:
- case PTRACE_DETACH:
- case PTRACE_SYSCALL:
- case PTRACE_OLDSETOPTIONS:
- case PTRACE_SETOPTIONS:
- case PTRACE_SET_THREAD_AREA:
- case PTRACE_GET_THREAD_AREA:
- case PTRACE_BTS_CONFIG:
- case PTRACE_BTS_STATUS:
- case PTRACE_BTS_SIZE:
- case PTRACE_BTS_GET:
- case PTRACE_BTS_CLEAR:
- case PTRACE_BTS_DRAIN:
- return sys_ptrace(request, pid, addr, data);
-
- default:
- return -EINVAL;
-
- case PTRACE_PEEKTEXT:
- case PTRACE_PEEKDATA:
- case PTRACE_POKEDATA:
- case PTRACE_POKETEXT:
- case PTRACE_POKEUSR:
- case PTRACE_PEEKUSR:
- case PTRACE_GETREGS:
- case PTRACE_SETREGS:
- case PTRACE_SETFPREGS:
- case PTRACE_GETFPREGS:
- case PTRACE_SETFPXREGS:
- case PTRACE_GETFPXREGS:
- case PTRACE_GETEVENTMSG:
- case PTRACE_SETSIGINFO:
- case PTRACE_GETSIGINFO:
- break;
- }
-
- child = ptrace_get_task_struct(pid);
- if (IS_ERR(child))
- return PTR_ERR(child);
-
- ret = ptrace_check_attach(child, request == PTRACE_KILL);
- if (ret < 0)
- goto out;
-
- childregs = task_pt_regs(child);
-
- switch (request) {
case PTRACE_PEEKUSR:
ret = getreg32(child, addr, &val);
if (ret == 0)
@@ -1290,12 +1239,14 @@ asmlinkage long sys32_ptrace(long request, u32 pid, u32 addr, u32 data)
sizeof(struct user32_fxsr_struct),
datap);
+ case PTRACE_GET_THREAD_AREA:
+ case PTRACE_SET_THREAD_AREA:
+ return arch_ptrace(child, request, addr, data);
+
default:
return compat_ptrace_request(child, request, addr, data);
}
- out:
- put_task_struct(child);
return ret;
}
diff --git a/include/asm-x86/ptrace.h b/include/asm-x86/ptrace.h
index bc44246..b57dc69 100644
--- a/include/asm-x86/ptrace.h
+++ b/include/asm-x86/ptrace.h
@@ -230,6 +230,8 @@ extern int do_get_thread_area(struct task_struct *p, int idx,
extern int do_set_thread_area(struct task_struct *p, int idx,
struct user_desc __user *info, int can_allocate);
+#define __ARCH_WANT_COMPAT_SYS_PTRACE
+
#endif /* __KERNEL__ */
#endif /* !__ASSEMBLY__ */
^ permalink raw reply related
* Re: fsldma seems to be buggy, noticed in loop mode
From: Sebastian Siewior @ 2008-03-13 9:13 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-embedded
In-Reply-To: <ABF87B0B6A38C0458E319AC973ED68AED32DD2@zch01exm26.fsl.freescale.net>
* Zhang Wei | 2008-03-13 15:03:54 [+0800]:
>Could you please apply these two patches and test again?
>
>http://lkml.org/lkml/2008/3/10/64
>http://lkml.org/lkml/2008/3/13/36
Ui, that fast. Did you find this on your own or after me reporting that
bug?
It solves my FIFO problem, thanks.
>Thanks!
>Wei.
Sebastian
^ permalink raw reply
* RE: fsldma seems to be buggy, noticed in loop mode
From: Zhang Wei @ 2008-03-13 9:17 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: linuxppc-embedded
In-Reply-To: <20080313091308.GA17132@Chamillionaire.breakpoint.cc>
> -----Original Message-----
> From: Sebastian Siewior [mailto:linuxppc-embedded@ml.breakpoint.cc]=20
>=20
> * Zhang Wei | 2008-03-13 15:03:54 [+0800]:
>=20
> >Could you please apply these two patches and test again?
> >
> >http://lkml.org/lkml/2008/3/10/64
> >http://lkml.org/lkml/2008/3/13/36
> Ui, that fast. Did you find this on your own or after me=20
> reporting that
> bug?
> It solves my FIFO problem, thanks.
>=20
Just after you reported. :)
Cheers!
Wei.
^ permalink raw reply
* Re: fsldma seems to be buggy, noticed in loop mode
From: Sebastian Siewior @ 2008-03-13 9:20 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-embedded
In-Reply-To: <ABF87B0B6A38C0458E319AC973ED68AED32E67@zch01exm26.fsl.freescale.net>
* Zhang Wei | 2008-03-13 17:17:31 [+0800]:
>Just after you reported. :)
okey. Do you want me to add a tested by on lkml?
>
>Cheers!
>Wei.
Sebastian
^ permalink raw reply
* RE: fsldma seems to be buggy, noticed in loop mode
From: Zhang Wei @ 2008-03-13 9:23 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: linuxppc-embedded
In-Reply-To: <20080313092008.GA17404@Chamillionaire.breakpoint.cc>
> -----Original Message-----
> From: Sebastian Siewior [mailto:linuxppc-embedded@ml.breakpoint.cc]=20
>=20
> * Zhang Wei | 2008-03-13 17:17:31 [+0800]:
>=20
> >Just after you reported. :)
> okey. Do you want me to add a tested by on lkml?
>=20
it's my pleasure!
Thanks!
Wei
^ permalink raw reply
* Re: [PATCH] ppc: Export empty_zero_page
From: Christoph Hellwig @ 2008-03-13 10:12 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: linuxppc-dev
In-Reply-To: <E1JZGwo-0000vf-2v@closure.thunk.org>
On Tue, Mar 11, 2008 at 10:44:06PM -0400, Theodore Ts'o wrote:
> Stephen Rothwell discovered this issue in the linux-next tree:
>
> >Today's powerpc allmodconfig build of linux-next failed with:
> >
> >ERROR: "empty_zero_page" [fs/ext4/ext4dev.ko] undefined!
> >
> >This is because commit dde5f2130096f8469eb1aa1ad250cd2a39fee3f5 ("ext4:
> >ENOSPC error handling for writing to an uninitialized extent") uses
> >ZERO_PAGE() which on powerpc uses empty_zero_page which is not
> >EXPORT_SYMBOLed on powerpc. I have reverted that commit and a later
> >one (1ae53f35fea49a9013353078e019469551d2ad74 "ext4: zero out
> >small extents when writing to prealloc area.") which depended on it.
>
> Any chance you could get this pushed to Linus ASAP? It would be nice if
> this could get pushed before the merge window, since it could be argued
> that rationalizing whether or not empty_zero_page is exported is a bug
> fix, and anyway this is pretty much a zero-risk patch. Thanks!!
The real fix is that ext4 shouldn't be using ZERO_PAGE(). Please use
the same zeroing helpers all the other filesystems and drivers use.
^ permalink raw reply
* Re: Driver for Freescale Display Interface Unit (A LCD controller)
From: Geert Uytterhoeven @ 2008-03-13 10:17 UTC (permalink / raw)
To: York Sun
Cc: Linux/PPC Development, Linux Frame Buffer Device Development,
Linux Kernel Development
In-Reply-To: <12053582234100-git-send-email-yorksun@freescale.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1007 bytes --]
On Wed, 12 Mar 2008, York Sun wrote:
> The following patches are for Freescale DIU. The first patch is a DIU driver.
> The second patch is the platform code to support the driver. It is a frame
> buffer driver for DIU. Descriptions can be found in the patches.
>
> It is a new feature targeting 2.6.26 kernel.
Please CC linux-fbdev-devel@lists.sourceforge.net when submitting new frame
buffer device drivers. Thx!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [BUG] 2.6.25-rc5-mm1 kernel panic with "Exception: 501 " on powerpc
From: Kamalesh Babulal @ 2008-03-13 13:02 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linux-kernel, linuxppc-dev, Andrew Morton, pbadari
In-Reply-To: <20080312223300.GE613@parisc-linux.org>
Matthew Wilcox wrote:
> On Thu, Mar 13, 2008 at 09:26:09AM +1100, Michael Ellerman wrote:
>> down() looks OK, but there's still a spin_lock_irq() in __down_common(),
>> although I don't know if it makes sense for us to be in __down() at that
>> stage.
>
> The spin_lock_irq in __down_common is correct. We're going to schedule(),
> so we spin_unlock_irq() to save us passing the flags into the helper
> function. If we had interrupts disabled on entry, there's an Aieee
> for that.
>
Hi All,
Sorry for all the noise made :-(, something wrong in the test setup from my end,
the kernel was 2.6.25-rc3-mm1 not 2.6.25-rc5-mm1. This bug is not seen in the
2.6.25-rc5-mm1 kernel.
--
Thanks & Regards,
Kamalesh Babulal,
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Luis Machado @ 2008-03-13 13:13 UTC (permalink / raw)
To: Jens Osterkamp
Cc: linuxppc-dev, Paul Mackerras, Roland McGrath, Arnd Bergmann,
Jan Kratochvil
In-Reply-To: <200803122330.36905.jens@de.ibm.com>
On Wed, 2008-03-12 at 23:30 +0100, Jens Osterkamp wrote:
> > Just to make sure, i tested the binary against the 2.6.25-rc4 kernel. It
> > still fails. So this is really an open bug for PPC.
>
> On a Cell- or 970-based machine ?
>
> Gruß,
> Jens
On a 970-based machine.
Regards,
--
Luis Machado
Software Engineer
IBM Linux Technology Center
^ permalink raw reply
* Re: Interrupt handling documentation
From: Laurent Pinchart @ 2008-03-13 13:56 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1205283088.7544.8.camel@concordia.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]
Hi Michael,
On Wednesday 12 March 2008 01:51, Michael Ellerman wrote:
> On Tue, 2008-03-11 at 11:58 +0100, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > is there any documentation describing interrupt handling for the powerpc
> > architecture ? I'm writing a driver for a cascaded interrupt controller
> > and the only source of information I found was the code.
>
> I don't think there's much documentation.
I feared so :-)
> You might want to look at arch/powerpc/platforms/cell/axon_msi.c, it's a
> reasonably simple example of how to setup an irq_host and so on - well I
> think so :D
Thanks for the pointer.
> > I'm particularly interested in information about irq hosts (allocation
> > and initialisation, especially the map and unmap callbacks) and irq
> > chaining. Different drivers seem to implement cascaded irqs differently
> > (for instance arch/powerpc/sysdev/uic.c uses setup_irq to register the
> > cascaded irq handler, while arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
> > uses set_irq_chained_handler) so I'm a bit lost here.
>
> uic.c uses set_irq_chained_handler() now, so that probably answers that
> question. I don't think it makes all that much difference if you set it
> up by hand, but set_irq_chained_handler() is the neat way to do it.
That pretty much answers my question. It's always a bit disturbing when
different drivers use different APIs to accomplish the same task, especially
when the lack of documentation doesn't clearly state which API should be used
and which API is internal/deprecated.
Thanks for your answer.
Cheers,
--
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: Help needed to describe a custom bus in the device tree
From: Laurent Pinchart @ 2008-03-13 14:12 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080311225427.GD7642@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 8406 bytes --]
Hi Dave,
On Tuesday 11 March 2008 23:54, David Gibson wrote:
> On Tue, Mar 11, 2008 at 03:27:26PM +0100, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > the migration process from ARCH=ppc to ARCH=powerpc is easier than I
> > thought in some parts, but a few devices are still giving me
> > headaches. This should hopefully be one of my last major requests
> > for help (I'm sure most of you will be happy to see traffic on this
> > list going down when I'll be done :-))
> >
> > I'm having trouble describing a custom bus named MS bus (completely
> > unrelated to a well-known software company) in the device tree. The
> > hardware is MPC8248-based and has the following hardware topology.
> >
> > MPC8248 <-- localbus --> FPGA <-- ms bus --> Custom peripherals
> >
> > The bus interrupt controller, serial access (SPI) controller and
> > status registers are accessed through memory-mapped registers in the
> > FPGA. Parallel access to the MS bus is handled transparently by the
> > FPGA which handles address mapping.
> >
> > The FPGA is mapped on the locabus at address 0xf4000000. Bus control
> > registers are at 0xf4002000 - 0xf4003000. The parallel bus memory
> > window on the localbus is located at 0xf5000000.
> >
> > My current dts draft describes that topology as follows (unrelated
> > devices on the local bus such as flash memory are removed for
> > clarity).
> >
> > localbus@f0010100 {
> > compatible = "fsl,pq2-localbus";
> > #address-cells = <2>;
> > #size-cells = <1>;
> > reg = <f0010100 40>;
> >
> > ranges = <0 0 40000000 01000000
> > 2 0 f2000000 00100000
> > 3 0 f3000000 00100000
> > 4 0 f4000000 00100000
> > 5 0 f5000000 00100000>;
> >
> > fpga@4,0 {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > ranges = <4 0 0 00010000>;
> >
> > msbus-arbitrer@2000 {
> > compatible = "tbox,cp11-msbus-arbitrer";
> > reg = <2000 4>;
> > };
> >
> > msbus_pic: interrupt-controller@2100 {
> > compatible = "tbox,cp11-msbus-pic";
> > reg = <2100 8>;
> > interrupts = <17 2>;
> > interrupt-parent = <&cpm_pic>;
> > #interrupt-cells = <1>;
> > interrupt-controller;
> > };
> >
> > msbus-spi@2200 {
> > compatible = "tbox,cp11-msbus-spi";
> > reg = <2200 100>;
> > interrupts = <18 8>;
> > interrupt-parent = <&cpm_pic>;
> > };
> >
> > sdhc@5000 {
> > compatible = "tbox,sdhci";
> > reg = <5000 1000>;
> > interrupts = <16 8>;
> > interrupt-parent = <&cpm_pic>;
> > };
> > };
> >
> > msbus@5,0 {
> > compatible = "tbox,cp11-msbus";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > #interrupt-cells = <1>;
> > reg = <5 0 0 00000400>;
> > interrupt-parent = <&msbus_pic>;
> > };
> > };
> >
> > The device tree reflects the physical topology but makes driver
> > access to the bus quite complex. An OF platform device driver
> > matching on compatible = "tbox,cp11-msbus" will not have the bus
> > FPGA registers described in its device node.
> >
> > Having a look at the various device trees included in the kernel
> > sources, it seems platforms with a PCI bus experience a similar
> > problem. To solve it the PCI bus node address and registers describe
> > the configuration registers, and the memory window to access PCI
> > devices is described by the ranges property. Applying that to my
> > custom bus would lead to the following tree.
> >
> > localbus@f0010100 {
> > compatible = "fsl,pq2-localbus";
> > #address-cells = <2>;
> > #size-cells = <1>;
> > reg = <f0010100 40>;
> >
> > ranges = <0 0 40000000 01000000
> > 2 0 f2000000 00100000
> > 3 0 f3000000 00100000
> > 4 0 f4000000 00100000
> > 4 1 f4002000 00000100
> > 5 0 f5000000 00100000>;
> >
> > fpga@4,0 {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > ranges = <4 0 0 00010000>;
> >
> > msbus_pic: interrupt-controller@2100 {
> > compatible = "tbox,cp11-msbus-pic";
> > reg = <2100 8>;
> > interrupts = <17 2>;
> > interrupt-parent = <&cpm_pic>;
> > #interrupt-cells = <1>;
> > interrupt-controller;
> > };
> >
> > msbus-spi@2200 {
> > compatible = "tbox,cp11-msbus-spi";
> > reg = <2200 100>;
> > interrupts = <18 8>;
> > interrupt-parent = <&cpm_pic>;
> > };
> >
> > sdhc@5000 {
> > compatible = "tbox,sdhci";
> > reg = <5000 1000>;
> > interrupts = <16 8>;
> > interrupt-parent = <&cpm_pic>;
> > };
> > };
> >
> > msbus@4,1 {
> > compatible = "tbox,cp11-msbus";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > #interrupt-cells = <1>;
> > reg = <4 1 4>;
> > interrupt-parent = <&msbus_pic>;
> > ranges = <5 0 0 00000400>;
> > };
> > };
> >
> > Is this correct ? Is that the best way to describe my custom bus in
> > the device tree ?
>
> Your second example looks closer to right. Certainly you should use
> 'reg' only for bus control registers, and 'ranges' for windows into
> the bus address space itself.
Ok.
> The device tree describes hardware from a functional point of view, so
> I don't know that it's relevant that all the bus control functions are
> implemented in an FPGA. Each of the subnodes are more-or-less
> independent devices, so they could just have separate nodes.
>
> Or, if this seems more sensible, you could decide that they're
> sufficiently closely related to put them all as one node, with
> multiple register blocks listed in the 'reg' property. That would
> probably get messy for your PIC at the very least though.
I suppose I could implement PIC support in the bus driver itself, but having
separate nodes with separate OF devices and separate drivers seems cleaner to
me (although it can make dependencies a bit more difficult to handle).
> > How would the relationships between the bus and
> > its PIC and SPI controller be handled in the drivers ?
>
> If the msbus driver needs to work with the associated PIC and SPI
> controllers, then you should put properties in the msbus node giving
> their phandles.
The PIC can live pretty much by itself, but the SPI controller is used to
enumerate devices on the bus (and perform some other tasks at runtime). I
plan to have the SPI device and driver be self-contained, and have the bus
node reference the SPI device through its phandle. I will just have to make
sure the bus driver is initialised after the SPI driver.
> > I also don't
> > understand how interrupt mappings are supposed to be handled. PCI
> > busses have two CPM interrupt lines, one for the PCI PIC and one for
> > the PCI bus, with the PCI bus having the CPM PIC as its interrupt
> > controller. My bus PIC uses a single interrupt line. Is there some
> > documentation explaining how PICs and interrupt mappings should be
> > described ?
>
> Are interrupts from devices on the msbus routed over the msbus, or are
> they routed independently to the mspic or the cpm PIC?
There is a single active low interrupt line on the msbus. When the mspic
detects an interrupt condition, it will read the interrupt source registers
from all devices on the bus and generate a host interrupt to the cpm PIC. The
mspic driver then process the CPM interrupt in its demux handler, reads the
interrupt sources from the mspic registers and dispatch the interrupts to the
msbus device drivers.
If I understand things correctly, the mspic node should have an 'interrupts'
attribute describing the cascaded interrupt line (mspic -> cpm PIC irq), and
the msbus node should have an 'interrupts' attribute describing the interrupt
line used to report bus-related events (hotplug events for instance). Is that
right ?
To make things a bit more complex, the msbus interrupt and the bus-related
events interrupt share the same CPM irq line. Can I use the same virq number
in both nodes, or do I have to demux the interrupts in a separate driver ? If
I have to demux the interrupts in a separate PIC driver, how do I know what
virtual irq number will be assigned to each device so that I can reference
them in the device tree ?
Thanks a lot for your help.
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: [PATCH -mm 2/4] ptrace: compat_ptrace_request siginfo
From: Jeff Dike @ 2008-03-13 14:42 UTC (permalink / raw)
To: Roland McGrath
Cc: Thomas Gleixner, linux-kernel, linuxppc-dev, Paul Mackerras,
Anton Blanchard, Andrew Morton, Ingo Molnar
In-Reply-To: <20080313083243.E551A26F992@magilla.localdomain>
On Thu, Mar 13, 2008 at 01:32:43AM -0700, Roland McGrath wrote:
> On powerpc, this fixes a longstanding regression of 32-bit ptrace
> calls on 64-bit kernels vs native calls (64-bit calls or 32-bit
> kernels). This can be seen in a 32-bit call using PTRACE_GETSIGINFO
> to examine e.g. siginfo_t.si_addr from a signal that sets it.
> (This was broken as of 2.6.24 and, I presume, many or all prior versions.)
BTW, this also fixes a long-standing bug in x86_64 ptrace32_siginfo:
ret = sys_ptrace(request, pid, addr, (unsigned long)si);
if (ret)
return ret;
if (request == PTRACE_GETSIGINFO) {
if (copy_from_user(&ssi, si, sizeof(siginfo_t)))
return -EFAULT;
ret = copy_siginfo_to_user32(si32, &ssi);
}
si comes back with the upper bits of si_code missing, courtesy of
copy_siginfo_to_user:
err |= __put_user((short)from->si_code, &to->si_code);
causing copy_siginfo_to_user32 to not copy any fields of the union
past the first word because the upper 16 bits are used to figure out
what needs copying.
Jeff
--
Work email - jdike at linux dot intel dot com
^ permalink raw reply
* Re: [PATCH] ibm_newemac: emac_tx_csum typo fix.patch
From: Stefan Roese @ 2008-03-13 15:42 UTC (permalink / raw)
To: linuxppc-dev, netdev
In-Reply-To: <20080222192139.GA26126@ru.mvista.com>
On Friday 22 February 2008, Valentine Barshak wrote:
> Move the "&& skb->ip_summed == CHECKSUM_PARTIAL" part out of
> emac_has_feature parameters.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Acked-by: Stefan Roese <sr@denx.de>
I think this is 2.6.25 material. I just stumbled over this problem too while
enabling TAH on 440GX and 460EX/GT.
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Hi,friends, the question about the u-boot and device tree?
From: 郭劲 @ 2008-03-13 15:31 UTC (permalink / raw)
To: support.asia, linuxppc-embedded, u-boot-users
Hi,friends,
I make all the frequency(timebase-frequency;bus-frequency;clock-frequency) value
on device tree file equal to zero, I think those frequency will filled by u-boot
during bootm, but in fact, the u-boot did not fill any frequency. after bootm,
crashed. Why?
Why so many document point out that the zero value will be filled by u-boot?
^ permalink raw reply
* Using GDB with Abatron's BDI2000 and the ppc405 in the Xilinx Virtex II Pro
From: Wood, Robert (GE EntSol, Intelligent Platforms) @ 2008-03-13 15:47 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
Hi, sorry for what is probably previously covered subject., I am
searching the archives.
We need a simple description of how to get GDB running with the BDI2000.
We have the '2000 communicating and can access the registers and like
through the telnet link but don't know how to configure the unit or GDB
to work together.
Robert Wood
Senior Engineer
GE Fanuc Intelligent Platforms
T +613 749 9241 x270
F +613 749 9461
E robert.wood@gefanuc.com
www.ge.com
5430 Canotek Road
Ottawa, Ontario
Canada K1J 9G2
General Electric Company
[-- Attachment #2: Type: text/html, Size: 5166 bytes --]
^ permalink raw reply
* [PATCH] net: NEWEMAC: Add compatible "ibm,tah" to tah matching table
From: Stefan Roese @ 2008-03-13 15:59 UTC (permalink / raw)
To: linuxppc-dev, netdev
Add "ibm,tah" to the compatible matching table of the ibm_newemac
tah driver. The type "tah" is still preserved for compatibility reasons.
New dts files should use the compatible property though.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/tah.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_newemac/tah.c b/drivers/net/ibm_newemac/tah.c
index 96417ad..b023d10 100644
--- a/drivers/net/ibm_newemac/tah.c
+++ b/drivers/net/ibm_newemac/tah.c
@@ -155,6 +155,10 @@ static int __devexit tah_remove(struct of_device *ofdev)
static struct of_device_id tah_match[] =
{
{
+ .compatible = "ibm,tah",
+ },
+ /* For backward compat with old DT */
+ {
.type = "tah",
},
{},
--
1.5.4.4
^ permalink raw reply related
* [PATCH] [POWERPC] Add TAH support to taishan dts
From: Stefan Roese @ 2008-03-13 16:00 UTC (permalink / raw)
To: linuxppc-dev
This patch adds TAH (TCP/IP Acceleration Hardware) support to the
taishan 440GX dts. It depends on the NEWEMAC/tah patch that adds the
compatible "ibm,tah" property to the matching table.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/taishan.dts | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/taishan.dts b/arch/powerpc/boot/dts/taishan.dts
index 8278068..b5aad74 100644
--- a/arch/powerpc/boot/dts/taishan.dts
+++ b/arch/powerpc/boot/dts/taishan.dts
@@ -232,6 +232,15 @@
reg = <40000790 8>;
};
+ TAH0: emac-tah@40000b50 {
+ compatible = "ibm,tah-440gx", "ibm,tah";
+ reg = <40000b50 30>;
+ };
+
+ TAH1: emac-tah@40000d50 {
+ compatible = "ibm,tah-440gx", "ibm,tah";
+ reg = <40000d50 30>;
+ };
EMAC0: ethernet@40000800 {
unused = <1>;
@@ -297,6 +306,8 @@
rgmii-channel = <0>;
zmii-device = <&ZMII0>;
zmii-channel = <2>;
+ tah-device = <&TAH0>;
+ tah-channel = <0>;
};
EMAC3: ethernet@40000e00 {
@@ -320,6 +331,8 @@
rgmii-channel = <1>;
zmii-device = <&ZMII0>;
zmii-channel = <3>;
+ tah-device = <&TAH1>;
+ tah-channel = <0>;
};
--
1.5.4.4
^ permalink raw reply related
* Re: slow Kilauea TCP throughput?
From: Stefan Roese @ 2008-03-13 16:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Donasch, Ingo @ SDS
In-Reply-To: <9E33F44949583B4597BDA2D06042567003734A0F@FLS-EXCHANGE.corp.sds.l-3com.com>
On Wednesday 12 March 2008, Donasch, Ingo @ SDS wrote:
> I have a project where I would like to use the AMC405EX under Linux for
> high speed data acquisition. I have the Kilauea board in the lab but
> measured only 150Mbit/s TCP throughput (outbound) with iperf. I need
> twice of that and actually expecting 3x higher bandwidth from that
> architecture.
I'm not sure if 3 times the performace will be possible. Why did you expect
such a performance btw?
> what is it that I'm missing?
> can anybody confirm my results or tell me what am I doing wrong?
I just ran some iperf tests and they show similar results. I'll currently
comparing them to other 4xx platforms. Perhaps this gives some infos on what
is happening here and where the bottleneck lies.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* RE: Using GDB with Abatron's BDI2000 and the ppc405 in the Xilinx VirtexII Pro
From: Sugathan, Rupesh @ 2008-03-13 16:51 UTC (permalink / raw)
To: Wood, Robert (GE EntSol, Intelligent Platforms),
linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
We need a simple description of how to get GDB running with the BDI2000.
We have the '2000 communicating and can access the registers and like
through the telnet link but don't know how to configure the unit or GDB
to work together.
See if these helps
http://www.unimax.co.kr/unimax_2003_11/products/datasheets/ManGDBPPC-200
0C5.pdf
http://microcross.com/Debugging_Linux_Kernel.pdf
<http://microcross.com/Debugging_Linux_Kernel.pdf>
http://ultsol.com/pdfs/ <http://ultsol.com/pdfs/>
Thanks
--
Rupesh Sugathan
[-- Attachment #2: Type: text/html, Size: 4116 bytes --]
^ permalink raw reply
* RE: Using GDB with Abatron's BDI2000 and the ppc405 in the Xilinx VirtexII Pro
From: John Linn @ 2008-03-13 17:11 UTC (permalink / raw)
To: Wood, Robert (GE EntSol, Intelligent Platforms),
linuxppc-embedded
In-Reply-To: <0F3B2CB6574F1A488E62523706BF8A7703F295E7@LOUMLVEM03.e2k.ad.ge.com>
[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]
Hi Robert,
Here's a link to an app note on it. I'm using it on the 405 right now as
we speak. I used the app note to get it working.
If you have problems, let me know.
http://www.xilinx.com/support/documentation/application_notes/xapp981.pd
f
Thanks,
John Linn
Xilinx Open Source Linux Engineer
________________________________
From: linuxppc-embedded-bounces+john.linn=xilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+john.linn=xilinx.com@ozlabs.org] On
Behalf Of Wood, Robert (GE EntSol,Intelligent Platforms)
Sent: Thursday, March 13, 2008 9:48 AM
To: linuxppc-embedded@ozlabs.org
Subject: Using GDB with Abatron's BDI2000 and the ppc405 in the Xilinx
VirtexII Pro
Hi, sorry for what is probably previously covered subject., I am
searching the archives.
We need a simple description of how to get GDB running with the BDI2000.
We have the '2000 communicating and can access the registers and like
through the telnet link but don't know how to configure the unit or GDB
to work together.
Robert Wood
Senior Engineer
GE Fanuc Intelligent Platforms
T +613 749 9241 x270
F +613 749 9461
E robert.wood@gefanuc.com
www.ge.com
5430 Canotek Road
Ottawa, Ontario
Canada K1J 9G2
General Electric Company
[-- Attachment #2: Type: text/html, Size: 14258 bytes --]
^ permalink raw reply
* RE: [PATCH] Ported Xilinx GPIO driver to OpenFirmware.
From: Stephen Neuendorffer @ 2008-03-13 17:18 UTC (permalink / raw)
To: Magnus Hjorth, git; +Cc: linuxppc-embedded
In-Reply-To: <001601c884e4$ef90bff0$ceb23fd0$@se>
Thanks Magnus...
Re: SPI I've been pondering some ideas along this line, but I haven't
done anything concrete. There are other cases where it makes sense to
have some information about the board-level design of the system (e.g.
ethernet PHYs.).
Steve
> -----Original Message-----
> From: Magnus Hjorth [mailto:mh@omnisys.se]
> Sent: Thursday, March 13, 2008 1:34 AM
> To: Stephen Neuendorffer; git
> Cc: linuxppc-embedded@ozlabs.org; 'Grant Likely'
> Subject: RE: [PATCH] Ported Xilinx GPIO driver to OpenFirmware.
>=20
> Hi,
>=20
> Thanks for the feedback. I'll have a look into refining the patch in a
few weeks when I get some
> more time.
>=20
> I have also been tinkering a little with the SPI driver, and that got
me thinking. Wouldn't it be
> great if SPI controllers and devices could be specified in the OF
device tree and registered on boot
> time? Even better if SPI worked as a true bus in EDK, with placeholder
IP-cores for each slave
> device, so such device entries could be autogenerated.
>=20
> Cheers,
> Magnus
>=20
> > -----Original Message-----
> > From: Stephen Neuendorffer [mailto:stephen.neuendorffer@xilinx.com]
> > Sent: den 11 mars 2008 18:36
> > To: Magnus Hjorth; git
> > Cc: linuxppc-embedded@ozlabs.org; Grant Likely
> > Subject: RE: [PATCH] Ported Xilinx GPIO driver to OpenFirmware.
> >
> >
> > Thanks Magnus!
> >
> > Generally speaking this looks reasonable. Some comments:
> >
> > > struct xgpio_instance {
> > > struct list_head link;
> > > unsigned long base_phys; /* GPIO base address - physical
> > */
> > > unsigned long remap_size;
> > > - u32 device_id;
> > > + u32 device_id; /* Dev ID for platform devices, 0 for OF
> > devices */
> > > + void *of_id; /* of_dev pointer for OF devices, NULL
> > for plat devices */
> >
> > Why have separate ids? I don't think the of_dev needs to be kept
around
> > here. This driver seems seems awkwardly written to have a local
list of
> > all the devices, rather than simply attaching the xgpio_instance as
the
> > private data of the file.
> >
> > For instance, in drivers/char/xilinx_hwicap.c:
> >
> > static ssize_t
> > hwicap_read(struct file *file, char __user *buf, size_t count,
loff_t
> > *ppos)
> > {
> > struct hwicap_drvdata *drvdata =3D file->private_data;
> >
> > and the drvdata is set in open:
> >
> > static int hwicap_open(struct inode *inode, struct file *file)
> > {
> > struct hwicap_drvdata *drvdata;
> > int status;
> >
> > drvdata =3D container_of(inode->i_cdev, struct hwicap_drvdata,
> > cdev);
> > ...
> > file->private_data =3D drvdata;
> >
> > Which would work if xgpio_instance directly contains the struct
> > miscdevice.
> > I think this is a much cleaner pattern (although it took me a while
to
> > figure out the magic that makes it work... )
> >
> > > +static struct of_device_id xgpio_of_match[] =3D {
> > > + {.compatible =3D "xlnx,xps-gpio-1.00.a"},
> >
> > This should also probably contain the corresponding strings for the
> > following as well:
> > opb_gpio_v1_00_a
> > opb_gpio_v2_00_a
> > opb_gpio_v3_01_a
> > opb_gpio_v3_01_b
> > plb_gpio_v1_00_b
> >
> > This would seem to be a relatively easy driver to clean up (by
pulling
> > it all into one file and converting the other code to the kernel
style)
> > and submit to mainline, if you're interested?
> >
> > Steve
^ permalink raw reply
* console kernel parameter problem
From: Fabio Ubaldi @ 2008-03-13 16:53 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm working with a board with a MPC8548 processor. I built the uboot,
the DTS file (myboard.dtb) and a kernel 2.6.21 .
When I try to boot the kernel via NFS I have some exception mode when
parsing the kernel parameters. Specifically I obtained an error during
the parsing of "console" parameter.
My host computer is connected to the board via console using a standard
8250 port.
I append the log in this post.
Has anyone any suggestion?
Thanks in advance for the reply.
root=/dev/nfs rw nfsroot=192.168.0.90:/home/ftpuser/workspace/rootfs
ip=192.168.0.11:192.168.0.90:192.168.0.90:255.255.255.0:MYBOARD:eth2:off
console=ttyS1,115200
=>
=>
=> run nfsboot
Enet starting in 1000BT/FD
Speed: 1000, full duplex
Using eTSEC2 device
TFTP from server 192.168.0.90; our IP address is 192.168.0.11
Filename 'uImage'.
Load address: 0x1000000
Loading: *\b
Enet starting in 1000BT/FD
Speed: 1000, full duplex
Using eTSEC2 device
TFTP from server 192.168.0.90; our IP address is 192.168.0.11
Filename 'myboard.dtb'.
Load address: 0x3000000
Loading: *\b
## Booting image at 01000000 ...
Image Name: Linux-2.6.21.7
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1509390 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using the fdt at 0x3000000
Loading Device Tree to 007fc000, end 007fd313 ... OK
Parsing ARGS: root=/dev/nfs rw
nfsroot=192.168.0.90:/home/ftpuser/workspace/rootfs
ip=192.168.0.11:192.168.0.90:192.168.0.90:255.255.255.0:MYBOARD:eth2:off
console=ttyS1,115200
early options: Parameter `root'
Unknown argument: calling c02dc5f0
return parse_one 0 early options: Parameter `root'
early options: Parameter `rw'
Unknown argument: calling c02dc5f0
return parse_one 0 early options: Parameter `rw'
early options: Parameter `nfsroot'
Unknown argument: calling c02dc5f0
return parse_one 0 early options: Parameter `nfsroot'
early options: Parameter `ip'
Unknown argument: calling c02dc5f0
return parse_one 0 early options: Parameter `ip'
early options: Parameter `console'
Unknown argument: calling c02dc5f0
return parse_one 0 early options: Parameter `console'
Using MYBOARD machine description
Memory CAM mapping: CAM0=256Mb, CAM1=256Mb, CAM2=256Mb residual: 256Mb
Linux version 2.6.21.7 (gcc version 4.1.2 ) #2 PREEMPT Thu Mar 13
16:30:01 GMT 2008
setup_arch: bootmem
setup_arch()
arch: exit
Zone PFN ranges:
DMA 0 -> 196608
Normal 196608 -> 196608
HighMem 196608 -> 262144
early_node_map[1] active PFN ranges
0: 0 -> 262144
Built 1 zonelists. Total pages: 260096
Kernel command line: root=/dev/nfs rw
nfsroot=192.168.0.90:/home/ftpuser/workspace/rootfs
ip=192.168.0.11:192.168.0.90:192.168.0.90:255.255.255.0:MYBOARD:eth2:off
console=ttyS1,115200
Parsing ARGS: root=/dev/nfs rw
nfsroot=192.168.0.90:/home/ftpuser/workspace/rootfs
ip=192.168.0.11:192.168.0.90:192.168.0.90:255.255.255.0:MYBOARD:eth2:off
console=ttyS1,115200
Booting kernel: Parameter `root'
Unknown argument: calling c02dc318
return parse_one 0 Booting kernel: Parameter `root=/dev/nfs'
Booting kernel: Parameter `rw'
Unknown argument: calling c02dc318
return parse_one 0 Booting kernel: Parameter `rw'
Booting kernel: Parameter `nfsroot'
Unknown argument: calling c02dc318
return parse_one 0 Booting kernel: Parameter
`nfsroot=192.168.0.90:/home/ftpuser/workspace/rootfs'
Booting kernel: Parameter `ip'
Unknown argument: calling c02dc318
return parse_one 0 Booting kernel: Parameter
`ip=192.168.0.11:192.168.0.90:192.168.0.90:255.255.255.0:MYBOARD:eth2:off'
Booting kernel: Parameter `console'
Unknown argument: calling c02dc318
Oops: Exception in kernel mode, sig: 4 [#1]
PREEMPT
Modules linked in:
NIP: C02E7B30 LR: C02E7C28 CTR: 00000000
REGS: c031be80 TRAP: 0700 Not tainted (2.6.21.7)
MSR: 00021000 <ME> CR: 24084022 XER: 00000000
TASK = c02fe5b8[0] 'swapper' THREAD: c031a000
GPR00: 00000000 C031BF30 C02FE5B8 C0332184 C031BF58 C035595A C031BF5E
C0300000
GPR08: 0000000A C0332184 00000001 C0332184 00000000 60000000 3FFFC400
03000000
GPR16: 00000001 00000000 007FFF00 00000000 00000000 007FFEB0 00000000
C02D6000
GPR24: 00000044 00021000 00000000 C035595A 00000001 C031BF58 C0332184
00000000
NIP [C02E7B30] add_preferred_console+0xac/0xd8
LR [C02E7C28] console_setup+0xcc/0xe4
Call Trace:
[C031BF30] [C03017C0] 0xc03017c0 (unreliable)
[C031BF50] [C02E7C28] console_setup+0xcc/0xe4
[C031BF70] [C02DC400] unknown_bootoption+0xe8/0x260
[C031BF90] [C003DDC8] parse_args+0x1f8/0x310
[C031BFC0] [C02DC7F4] start_kernel+0x16c/0x2b4
[C031BFF0] [C0000388] skpinv+0x2b8/0x2f4
Instruction dump:
48000048 3d20c030 38600000 93e9ff98 48000038 3d20c030 93e9ff98 3d20c033
39292184 57eb2036 7d6b4a14 38000000 <7d3d44aa> 7d2b45aa 38600000 938b0008
Kernel panic - not syncing: Attempted to kill the idle task!
Rebooting in 180 seconds..
^ permalink raw reply
* Linux/PPC leads needed
From: Sadakathullah Mohamed Ali (mohamali) @ 2008-03-13 17:57 UTC (permalink / raw)
To: linuxppc-dev
Hi LinuxPPC Guru's
I am sending these leads your way on behalf of Cisco's Embedded system
software manager.
Please send responses to mohamali@cisco.com
Cisco has 3 positions which are very similar 2 Technical lead positions
and 1 Sr. Software Engineer position(Linux, Power PC, Bring up and
Drivers, Diag software (U-boot) )=20
=20
Req 1: Technical Lead (New product) - (Driver, board bring up, Linux,
PowerPC)
------------------------------------------------------------------------
------
Location: San Jose, CA
Cisco is looking to hire a tech lead - Software engineer. This is a
highly skilled, high power team with a goal to make significant
contribution to the way Cisco designs and develops system software in
the datacenter.
Sr. System Software Engineer with the following experience/skills:=20
*8+ years C programming, embedded OS and device drivers *Solid grounding
in Linux/Unix internals *Hardware board bringup, ability to read
schematic drawings *PowerPC assembly, a plus *Familiarity with
Clearcase, cvs or other SCM systems *Ability to document and communicate
original designs *At least a BSCS or BSEE *Good communication skills
*Strong team player
Desirable Skills:
*Knowledge and understanding of networks and networking software *TCL ,
PERL, Python or other scripting language *Knowledge of Cisco's Data
Center OS is a Plus.
Req 2: Tech lead - Diag software development - Cisco's new digital video
product
------------------------------------------------------------------------
--------
The successful applicant must have a proven track record of bringing
products to market, and should possess the following particular skills
and experience:=20
* 7-10 years of experience working as a software engineer with a hi-tech
company * Experience with the bring-up of complex PC boards with
advanced CPU, DSP, and Ethernet chipsets.=20
* Experience with embedded processors (Intel, Freescale) * Linux
experience * UBoot experience * ATCA experience highly desirable *
Experience in managing and working with external developer resources.=20
* Demonstrated ability to successfully influence win-win
cross-functional dynamics.=20
* Applies high degree of ingenuity using broad parameters for foundation
of decisions.=20
* Makes product level decisions independently.=20
* Technical, Industry, Business and Cross-Functional Knowledge.=20
* Have outstanding communication, presentation and written skills as
well as an ability to deal effectively with both technologists and
business representatives and to sell and promote ideas across the
organization.=20
Education
* Requires BSEE, BSCS or equivalent training with 7-10+ yrs related exp.
Masters degree desired.
=09
Thanks and Regards
Mohamed Ali
mohamali@cisco.com
Mobile :510-402-7625
225 E Tasman Dr San Jose, CA United States
www.cisco.com=20
^ permalink raw reply
* Linux/PPC leads needed
From: Sadakathullah Mohamed Ali (mohamali) @ 2008-03-13 17:47 UTC (permalink / raw)
To: linuxppc-embedded
Hi LinuxPPC Guru's
I am sending these leads your way on behalf of Cisco's Embedded system
software manager.
Please send responses to mohamali@cisco.com
Cisco has 3 positions which are very similar 2 Technical lead positions
and 1 Sr. Software Engineer position(Linux, Power PC, Bring up and
Drivers, Diag software (U-boot) )=20
=20
Req 1: Technical Lead (New product) - (Driver, board bring up, Linux,
PowerPC)
------------------------------------------------------------------------
------
Location: San Jose, CA
Cisco is looking to hire a tech lead - Software engineer. This is a
highly skilled, high power team with a goal to make significant
contribution to the way Cisco designs and develops system software in
the datacenter.
Sr. System Software Engineer with the following experience/skills:=20
*8+ years C programming, embedded OS and device drivers
*Solid grounding in Linux/Unix internals
*Hardware board bringup, ability to read schematic drawings
*PowerPC assembly, a plus
*Familiarity with Clearcase, cvs or other SCM systems
*Ability to document and communicate original designs
*At least a BSCS or BSEE
*Good communication skills
*Strong team player
Desirable Skills:
*Knowledge and understanding of networks and networking software
*TCL , PERL, Python or other scripting language
*Knowledge of Cisco's Data Center OS is a Plus.
Req 2: Tech lead - Diag software development - Cisco's new digital video
product
------------------------------------------------------------------------
--------
The successful applicant must have a proven track record of bringing
products to market, and should possess the following particular skills
and experience:=20
* 7-10 years of experience working as a software engineer with a hi-tech
company=20
* Experience with the bring-up of complex PC boards with advanced CPU,
DSP, and Ethernet chipsets.=20
* Experience with embedded processors (Intel, Freescale)=20
* Linux experience=20
* UBoot experience=20
* ATCA experience highly desirable=20
* Experience in managing and working with external developer resources.=20
* Demonstrated ability to successfully influence win-win
cross-functional dynamics.=20
* Applies high degree of ingenuity using broad parameters for foundation
of decisions.=20
* Makes product level decisions independently.=20
* Technical, Industry, Business and Cross-Functional Knowledge.=20
* Have outstanding communication, presentation and written skills as
well as an ability to deal effectively with both technologists and
business representatives and to sell and promote ideas across the
organization.=20
Education=20
* Requires BSEE, BSCS or equivalent training with 7-10+ yrs related exp.
Masters degree desired.
=09
Thanks and Regards
Mohamed Ali
mohamali@cisco.com
Mobile :510-402-7625
225 E Tasman Dr San Jose, CA United States
www.cisco.com=20
^ 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