* Re: Fix small race in 44x tlbie function
From: Kumar Gala @ 2007-08-08 15:20 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras, Todd Inglett, Volkmar Uhlig
In-Reply-To: <20070807042050.GJ13522@localhost.localdomain>
On Aug 6, 2007, at 11:20 PM, David Gibson wrote:
> The 440 family of processors don't have a tlbie instruction. So, we
> implement TLB invalidates by explicitly searching the TLB with tlbsx.,
> then clobbering the relevant entry, if any. Unfortunately the PID for
> the search needs to be stored in the MMUCR register, which is also
> used by the TLB miss handler. Interrupts were enabled in _tlbie(), so
> an interrupt between loading the MMUCR and the tlbsx could cause
> incorrect search results, and thus a failure to invalide TLB entries
> which needed to be invalidated.
>
> This patch fixes the problem in both arch/ppc and arch/powerpc by
> inhibiting interrupts (even critical and debug interrupts) across the
> relevant instructions.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> Paul, this one's a bugfix, which I think should go into 2.6.23.
Did you actually see this happen?
- k
^ permalink raw reply
* Re: Fix small race in 44x tlbie function
From: Josh Boyer @ 2007-08-08 14:49 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras, Todd Inglett, Volkmar Uhlig
In-Reply-To: <20070807042050.GJ13522@localhost.localdomain>
On Tue, 7 Aug 2007 14:20:50 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> The 440 family of processors don't have a tlbie instruction. So, we
> implement TLB invalidates by explicitly searching the TLB with tlbsx.,
> then clobbering the relevant entry, if any. Unfortunately the PID for
> the search needs to be stored in the MMUCR register, which is also
> used by the TLB miss handler. Interrupts were enabled in _tlbie(), so
> an interrupt between loading the MMUCR and the tlbsx could cause
> incorrect search results, and thus a failure to invalide TLB entries
> which needed to be invalidated.
>
> This patch fixes the problem in both arch/ppc and arch/powerpc by
> inhibiting interrupts (even critical and debug interrupts) across the
> relevant instructions.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
And I agree this should go into 2.6.23.
josh
^ permalink raw reply
* Re: pci in arch/powerpc vs arch/ppc
From: Alexandros Kostopoulos @ 2007-08-08 14:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <op.twqn4vtsnhx3hy@phoenix>
Hi all,
I've noticed the following: In function pci_process_bridge_OF_ranges, wh=
en =
parsing the ranges for MEM and I/O space, the res->start for mem is =
correctly set to ranges[na+2], which is the cpu address in the ranges =
property. However, in I/O related code, res->start is set to ranges[2], =
=
which is in the PCI address field of the ranges property (and in my case=
=
is 0, as is also for the mpc8272ads case as well). Thus, the res->start =
of =
the I/O of the bridge is 0, which leads to the first device with I/O spa=
ce =
(a davicom ethernet device) been also assigned a I/O region starting at =
0. =
Finally, the dmfe (davicom ethernet driver over PCI) fails with "dmfe: I=
/O =
base is zero". So, is the implementation of pci_process_bridge_OF_ranges=
=
correct ? shouldn't res->start =3D ranges[na+2] for I/O as well?
thank you
Alex
^ permalink raw reply
* Re: [PATCH] ehca: map 4k firmware context of cq, qp to user space
From: Hoang-Nam Nguyen @ 2007-08-08 14:13 UTC (permalink / raw)
To: Roland Dreier
Cc: Arnd Bergmann, linux-kernel, linuxppc-dev, paulus, general,
stefan.roscher
In-Reply-To: <200708031036.20859.hnguyen@linux.vnet.ibm.com>
Hello Roland!
Haven't got any ack for this updated patch yet. Anyway, since it contains
another bug as shown below, please ignore this patch. We'll send a patch
set that includes the proper version of this patch later.
> @@ -109,7 +109,7 @@ static int ehca_mmap_fw(struct vm_area_struct *vma, struct h_galpas *galpas,
> u64 vsize, physical;
>
> vsize = vma->vm_end - vma->vm_start;
> - if (vsize != EHCA_PAGESIZE) {
> + if (vsize >= EHCA_PAGESIZE) {
should be
> + if (vsize < EHCA_PAGESIZE) {
which is sort of invalid arg.
Thanks
Nam
On Friday 03 August 2007 10:36, Hoang-Nam Nguyen wrote:
> From: Hoang-Nam Nguyen <hnguyen at de.ibm.com>
> Date: Fri, 3 Aug 2007 09:44:56 +0200
> Subject: [PATCH] ehca: map 4k firmware context of cq, qp to user space
> This patch utilizes remap_4k_pfn() as introduced by Paul M.,
> for details see http://patchwork.ozlabs.org/linuxppc/patch?id=10281,
> to map ehca cq, qp firmware context (4k) to user space if kernel page
> size is 64k. For reason, why this is required, see also Paul's patch.
> In addition to that the kernel page offset of firmware context needs
> to be set in cq and qp response block so that user space can assemble
> the proper virtual address to use.
> An appropriate patch for libehca will follow for ofed-1.3.
>
> Signed-off-by: Hoang-Nam Nguyen <hnguyen@de.ibm.com>
> ---
> drivers/infiniband/hw/ehca/ehca_classes.h | 4 +++-
> drivers/infiniband/hw/ehca/ehca_cq.c | 2 ++
> drivers/infiniband/hw/ehca/ehca_qp.c | 2 ++
> drivers/infiniband/hw/ehca/ehca_uverbs.c | 6 +++---
> 4 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h b/drivers/infiniband/hw/ehca/ehca_classes.h
> index b5e9603..206d4eb 100644
> --- a/drivers/infiniband/hw/ehca/ehca_classes.h
> +++ b/drivers/infiniband/hw/ehca/ehca_classes.h
> @@ -337,6 +337,8 @@ struct ehca_create_cq_resp {
> u32 cq_number;
> u32 token;
> struct ipzu_queue_resp ipz_queue;
> + u32 fw_handle_ofs;
> + u32 dummy;
> };
>
> struct ehca_create_qp_resp {
> @@ -347,7 +349,7 @@ struct ehca_create_qp_resp {
> u32 qkey;
> /* qp_num assigned by ehca: sqp0/1 may have got different numbers */
> u32 real_qp_num;
> - u32 dummy; /* padding for 8 byte alignment */
> + u32 fw_handle_ofs;
> struct ipzu_queue_resp ipz_squeue;
> struct ipzu_queue_resp ipz_rqueue;
> };
> diff --git a/drivers/infiniband/hw/ehca/ehca_cq.c b/drivers/infiniband/hw/ehca/ehca_cq.c
> index 81aff36..ed5d67f 100644
> --- a/drivers/infiniband/hw/ehca/ehca_cq.c
> +++ b/drivers/infiniband/hw/ehca/ehca_cq.c
> @@ -276,6 +276,8 @@ struct ib_cq *ehca_create_cq(struct ib_device *device, int cqe, int comp_vector,
> resp.ipz_queue.queue_length = ipz_queue->queue_length;
> resp.ipz_queue.pagesize = ipz_queue->pagesize;
> resp.ipz_queue.toggle_state = ipz_queue->toggle_state;
> + resp.fw_handle_ofs = (u32)
> + (my_cq->galpas.user.fw_handle & (PAGE_SIZE - 1));
> if (ib_copy_to_udata(udata, &resp, sizeof(resp))) {
> ehca_err(device, "Copy to udata failed.");
> goto create_cq_exit4;
> diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c b/drivers/infiniband/hw/ehca/ehca_qp.c
> index b178cba..66f632c 100644
> --- a/drivers/infiniband/hw/ehca/ehca_qp.c
> +++ b/drivers/infiniband/hw/ehca/ehca_qp.c
> @@ -745,6 +745,8 @@ static struct ehca_qp *internal_create_qp(
> queue2resp(&resp.ipz_squeue, &my_qp->ipz_squeue);
> if (HAS_RQ(my_qp))
> queue2resp(&resp.ipz_rqueue, &my_qp->ipz_rqueue);
> + resp.fw_handle_ofs = (u32)
> + (my_qp->galpas.user.fw_handle & (PAGE_SIZE - 1));
>
> if (ib_copy_to_udata(udata, &resp, sizeof resp)) {
> ehca_err(pd->device, "Copy to udata failed");
> diff --git a/drivers/infiniband/hw/ehca/ehca_uverbs.c b/drivers/infiniband/hw/ehca/ehca_uverbs.c
> index 4bc687f..be062f1 100644
> --- a/drivers/infiniband/hw/ehca/ehca_uverbs.c
> +++ b/drivers/infiniband/hw/ehca/ehca_uverbs.c
> @@ -109,7 +109,7 @@ static int ehca_mmap_fw(struct vm_area_struct *vma, struct h_galpas *galpas,
> u64 vsize, physical;
>
> vsize = vma->vm_end - vma->vm_start;
> - if (vsize != EHCA_PAGESIZE) {
> + if (vsize >= EHCA_PAGESIZE) {
> ehca_gen_err("invalid vsize=%lx", vma->vm_end - vma->vm_start);
> return -EINVAL;
> }
> @@ -118,8 +118,8 @@ static int ehca_mmap_fw(struct vm_area_struct *vma, struct h_galpas *galpas,
> vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> ehca_gen_dbg("vsize=%lx physical=%lx", vsize, physical);
> /* VM_IO | VM_RESERVED are set by remap_pfn_range() */
> - ret = remap_pfn_range(vma, vma->vm_start, physical >> PAGE_SHIFT,
> - vsize, vma->vm_page_prot);
> + ret = remap_4k_pfn(vma, vma->vm_start, physical >> EHCA_PAGESHIFT,
> + vma->vm_page_prot);
> if (unlikely(ret)) {
> ehca_gen_err("remap_pfn_range() failed ret=%x", ret);
> return -ENOMEM;
^ permalink raw reply
* Re: pci in arch/powerpc vs arch/ppc
From: Alexandros Kostopoulos @ 2007-08-08 13:03 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <op.twqn4vtsnhx3hy@phoenix>
On Wed, 08 Aug 2007 14:42:34 +0300, Alexandros Kostopoulos =
<akostop@inaccessnetworks.com> wrote:
> On Tue, 07 Aug 2007 18:20:12 +0300, Scott Wood <scottwood@freescale.co=
m> =
> wrote:
>
>> Alexandros Kostopoulos wrote:
>>> Except from some macros arch/powerpc/include/asm/io.h / =
>>> mpc8260_pci9.h, I can seem to find anywhere the code regarding PCI =
=
>>> Erratum 9. The defined macros(in io.h) for read/write are sufficien=
t =
>>> as a workaround for PCI9? Who does DMA and register initialization =
=
>>> for this (it used to be done in arch/ppc/syslib/m8260_pci_erratum9.=
c =
>>> in arc/ppc). Maybe u-boot or the bootwrapper?
>>
>> I don't think the workaround exists yet in arch/powerpc, despite the =
=
>> config option.
>>
>
> Is there a plan to be implemented on arch/powerpc, or devices with the=
=
> erratum will have to keep on using the legacy arch/ppc code?
>
>>> Another question regarding resource allocation: when =
>>> alloc_resource(pci_32.c), called from pcibios_allocate_resources(), =
=
>>> during pcibios init, attempts to allocate resources using =
>>> request_resource(), the request fails. This seems to happen because=
=
>>> the previously scanned PCI devices request resources in the form, =
>>> e.g. 00000- 0000f (i.e. starting from zero), and this should be =
>>> mapped somewhere else in cpu mem space. My question (in order to fi=
nd =
>>> my bug) is, who performs this mapping, from PCI space to CPU space,=
=
>>> the kernel (and if yes, where?) or the host bridge (in which case, =
=
>>> I've probably failed to configure it properly).
>>
>> If the error message is the one I'm thinking of (it always helps to =
>> post the actual messages), that's normal for when the PCI bus hasn't =
=
>> been probed by the firmware. Linux first tries to use the BARs as =
>> they're already set, which will obviously fail because they haven't =
>> been set, and then it will properly allocated them. It's harmless =
>> verbosity, though it'd be nice to have a flag to tell the PCI layer t=
o =
>> not bother trying to preserve any existing BARs.
>>
>
> Well, the error message is:
> PCI:0000:00:16.0: Resource 0: 0000000000000000-0000000000000fff (f=3D2=
00)
> PCI: Cannot allocate resource region 0 of device 0000:00:16.0
> PCI: parent is c03c4058: 0000000080000000-00000000bfffffff (f=3D200)
>
> The thing is, POBARs are already setup by uboot. However the resource =
=
> allocation for the PCI devices (not the host bridge) fails in =
> request_resource (which seems to use the region requested by the devic=
e =
> as is and not some mapped region in the cpu address space), and I can =
=
> not find where in the code happens the mapping from PCI to local bus m=
em =
> region. I mean, each PCI device requests some region, e.g. from =
> 0000-00ff and this is mapped to some region in the PCI outbound window=
, =
> right. For some reason this fails in my case, and I cannot find where =
in =
> the code this mapping should happen.
>
> Thank you for your help
>
> Alex
Oops, I think I found it. I think resources are allocated properly in =
pci_assign_resource(), and you were probably talking about the PCI devic=
e =
BAR, not the host bridge POBARs, right. So the error message in my =
previous mail is the one you say it's ok?
>
>> -Scott
>
^ permalink raw reply
* RE: TEMAC support of Uboot on ML403
From: Ming Liu @ 2007-08-08 12:10 UTC (permalink / raw)
To: sharonf; +Cc: Linuxppc-embedded
In-Reply-To: <8506C3905ED0764F889ADEB33E3A9E8062D0CC@MAIA.scopus.net>
Dear Sharon,
Sorry that I don't know the detail of what you suggested. Could you say
something more on that? Shall I patch U-boot to add the driver for TEMAC in
U-boot? and where is the patch? Or I just modify some parameters in the
existing files? Thanks for your detailed information and sharing your
experience.
BR
Ming
>From: "Sharon Feldman" <sharonf@scopus.net>
>To: "Ming Liu" <eemingliu@hotmail.com>
>Subject: RE: TEMAC support of Uboot on ML403
>Date: Wed, 8 Aug 2007 14:11:22 +0300
>
>YES IT DOES WORK WITH TEMAC. YOU NEED TO MAKE THE RIGHT ADAPTATIONS
>
>-----Original Message-----
>From: linuxppc-embedded-bounces+sharonf=scopus.net@ozlabs.org
[mailto:linuxppc-embedded-bounces+sharonf=scopus.net@ozlabs.org]On Behalf
Of Ming Liu
>Sent: Wednesday, August 08, 2007 1:08 PM
>To: linuxppc-embedded@ozlabs.org
>Subject: TEMAC support of Uboot on ML403
>
>
>Dear all,
>Does anyone know that whether U-boot can support Xilinx TEMAC core to tftp
>the Linux kernel or not. In my design I am using TEMAC instead of the
>normal enet. While I found that in the Xilinx u-boot tree, there is only a
>directory for xilinx_enet instead of xilinx_temac. I am not sure if I am
>right, but I remember a long time before, there was a patch for supporting
>Xilinx TEMAC in U-boot.
>
>Any suggestion will be appreciated a lot for this topic. Thank you in
>advance for your telling.
>
>BR
>Ming
>
>_________________________________________________________________
>享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Re: [patch 0/3] PS3 bugfix patches for 2.6.23
From: Michael Ellerman @ 2007-08-08 12:06 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070808174740.8426f5f6.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 780 bytes --]
On Wed, 2007-08-08 at 17:47 +1000, Stephen Rothwell wrote:
> Hi Geoff,
>
> On Wed, 8 Aug 2007 17:17:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au>
> wrote:
> >
> > LD .tmp_vmlinux1
> > arch/powerpc/platforms/built-in.o: In function `of_has_vicinity':
> > /home/sfr/kernels/linus/arch/powerpc/platforms/cell/spu_base.c:681:
> > undefined reference to `.spu_devnode'
>
> Ben pointed out patch "[PATCH v2] cell: move SPU affinity init to
> spu_management_of_ops" to me.
Can someone please merge it!
:)
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: pci in arch/powerpc vs arch/ppc
From: Alexandros Kostopoulos @ 2007-08-08 11:42 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <46B88DAC.70005@freescale.com>
On Tue, 07 Aug 2007 18:20:12 +0300, Scott Wood <scottwood@freescale.com>=
=
wrote:
> Alexandros Kostopoulos wrote:
>> Except from some macros arch/powerpc/include/asm/io.h / mpc8260_pci9.=
h, =
>> I can seem to find anywhere the code regarding PCI Erratum 9. The =
>> defined macros(in io.h) for read/write are sufficient as a workaroun=
d =
>> for PCI9? Who does DMA and register initialization for this (it used=
=
>> to be done in arch/ppc/syslib/m8260_pci_erratum9.c in arc/ppc). Mayb=
e =
>> u-boot or the bootwrapper?
>
> I don't think the workaround exists yet in arch/powerpc, despite the =
> config option.
>
Is there a plan to be implemented on arch/powerpc, or devices with the =
erratum will have to keep on using the legacy arch/ppc code?
>> Another question regarding resource allocation: when =
>> alloc_resource(pci_32.c), called from pcibios_allocate_resources(), =
>> during pcibios init, attempts to allocate resources using =
>> request_resource(), the request fails. This seems to happen because =
=
>> the previously scanned PCI devices request resources in the form, e.=
g. =
>> 00000- 0000f (i.e. starting from zero), and this should be mapped =
>> somewhere else in cpu mem space. My question (in order to find my bu=
g) =
>> is, who performs this mapping, from PCI space to CPU space, the kern=
el =
>> (and if yes, where?) or the host bridge (in which case, I've probabl=
y =
>> failed to configure it properly).
>
> If the error message is the one I'm thinking of (it always helps to po=
st =
> the actual messages), that's normal for when the PCI bus hasn't been =
> probed by the firmware. Linux first tries to use the BARs as they're =
=
> already set, which will obviously fail because they haven't been set, =
=
> and then it will properly allocated them. It's harmless verbosity, =
> though it'd be nice to have a flag to tell the PCI layer to not bother=
=
> trying to preserve any existing BARs.
>
Well, the error message is:
PCI:0000:00:16.0: Resource 0: 0000000000000000-0000000000000fff (f=3D200=
)
PCI: Cannot allocate resource region 0 of device 0000:00:16.0
PCI: parent is c03c4058: 0000000080000000-00000000bfffffff (f=3D200)
The thing is, POBARs are already setup by uboot. However the resource =
allocation for the PCI devices (not the host bridge) fails in =
request_resource (which seems to use the region requested by the device =
as =
is and not some mapped region in the cpu address space), and I can not =
find where in the code happens the mapping from PCI to local bus mem =
region. I mean, each PCI device requests some region, e.g. from 0000-00f=
f =
and this is mapped to some region in the PCI outbound window, right. For=
=
some reason this fails in my case, and I cannot find where in the code =
this mapping should happen.
Thank you for your help
Alex
> -Scott
^ permalink raw reply
* no output to serial console from /init process on ml405
From: Anton Kowalski @ 2007-08-08 11:28 UTC (permalink / raw)
To: linuxppc-embedded
Hi All:
I'm trying to bring up linux 2.6.21.1 on an ml405 board. The kernel
boots fine but the init process does not produce any output. The /init
program resides in an initramfs file system and I believe the /dev
device files have been set up correctly. Here's an excerpt from my
initramfs specification:
dir /dev 755 0 0
nod /dev/console 644 0 0 c 5 1
nod /dev/ttyS0 644 0 0 c 4 64
(I am able to open these files from the init program. I tested this by
sleeping for a specified time on success.)
Also, printk continues to function after /init terminates and before
the kernel panics.
Here are the last few lines of the console output:
[ 0.507478] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports,
IRQ sharing disabled
[ 0.513862] serial8250.0: ttyS0 at MMIO 0x80201003 (irq = 3) is a 16550A
[ 2.927509] RAMDISK driver initialized: 1 RAM disks of 8192K size
1024 blocksize
[ 3.018391] tun: Universal TUN/TAP device driver, 1.6
[ 3.079115] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 3.154919] mice: PS/2 mouse device common for all mice
[ 3.218021] TCP cubic registered
[ 3.257034] NET: Registered protocol family 1
[ 3.309405] NET: Registered protocol family 17
[ 3.363462] Freeing unused kernel memory: 300k init
[ 23.488277] Kernel panic - not syncing: Attempted to kill init!
[ 23.559517] Rebooting in 180 seconds..<NULL>
I'm using the plb uart and the 8250.c driver. (The obp uartlite driver
didn't work so I switched.) The kernel and the init program were
compiled with eldk.
Any insights into resolving this problem are greatly appreciated.
Anton
^ permalink raw reply
* TEMAC support of Uboot on ML403
From: Ming Liu @ 2007-08-08 10:08 UTC (permalink / raw)
To: linuxppc-embedded
Dear all,
Does anyone know that whether U-boot can support Xilinx TEMAC core to tftp
the Linux kernel or not. In my design I am using TEMAC instead of the
normal enet. While I found that in the Xilinx u-boot tree, there is only a
directory for xilinx_enet instead of xilinx_temac. I am not sure if I am
right, but I remember a long time before, there was a patch for supporting
Xilinx TEMAC in U-boot.
Any suggestion will be appreciated a lot for this topic. Thank you in
advance for your telling.
BR
Ming
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ permalink raw reply
* Re: signals handling in the kernel
From: Mirek23 @ 2007-08-08 8:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46B8BA93.8020909@ovro.caltech.edu>
Hi Dave,
I have found the book by Rubini you have mentioned:
http://www.oreilly.com/catalog/linuxdrive3/book/index.csp
I did not find however what would be the best way to propagate interrupt
signals to the USER level / notify the client that interrupt has occurred.
I have checked also in the kernel 2.4 kernel/signal.c file and
kill_proc_info symbol was there exported but in the kernel 2.6 it is not a
case. I have modified the kernel/signal.c file inserting the line:
EXPORT_SYMBOL(kill_proc_info);
and I use the kill_proc_info straight from the interrupt handler routine. I
do not know however if it is a safe
solution. This what does not work with kill_proc_info is that (struct
siginfo *) pInfo->si_value.sival_int
is not passed to the user space. To pass an integer value I use (struct
siginfo *) pInfo->si_code instead.
This works but it is not an elegant solution since the si_code is meant to
be used for something else.
Best Regards
Mirek
David Hawkins-3 wrote:
>
>
> Hi Mirek,
>
>>> I would like to send signals from the interrupt handler
>>> routine (in the kernel) to the user application (in user space).
>>> I have googled on that net and I have found that it could be done with
>>> the
>>> function: kill_proc_info.
>>
>> Look in Rubini for the section regarding asynchronous
>> notification, Ch 6.
>>
>> The callback to generate SIGIO is fasync.
>>
>
> Actually, before you go off and implement something, can
> you describe why you want to use signals.
>
> I mistakenly used signals once to indicate notification of
> an event. Then when I wanted multiple events from multiple
> boards I found the problem with signals; you don't know
> who sent it.
>
> Using select() on multiple file descriptors ended up being
> a more appropriate solution for my application. That
> solution also works nicely with the ACE C++ ACE_Reactor
> pattern.
>
> Cheers,
> Dave
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/signals-handling-in-the-kernel-tf4229566.html#a12048974
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix more section mismatches in head_64.S
From: Geert Uytterhoeven @ 2007-08-08 7:51 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus
In-Reply-To: <20070731164413.0421b430.sfr@canb.auug.org.au>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1429 bytes --]
On Tue, 31 Jul 2007, Stephen Rothwell wrote:
> WARNING: vmlinux.o(.text+0x8174): Section mismatch: reference to .init.text:.prom_init (between '.__boot_from_prom' and '.__after_prom_start')
> WARNING: vmlinux.o(.text+0x8498): Section mismatch: reference to .init.text:.early_setup (between '.start_here_multiplatform' and '.start_here_common')
> WARNING: vmlinux.o(.text+0x8514): Section mismatch: reference to .init.text:.setup_system (between '.start_here_common' and 'system_call_common')
> WARNING: vmlinux.o(.text+0x8530): Section mismatch: reference to .init.text:.start_kernel (between '.start_here_common' and 'system_call_common')
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Nice, the last few section warnings in my PS3 build went away!
Acked-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
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: [patch 2/3] PS3: Remove incomplete message
From: Geert Uytterhoeven @ 2007-08-08 7:49 UTC (permalink / raw)
To: geoffrey.levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070808033120.055823394@am.sony.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1779 bytes --]
On Tue, 7 Aug 2007 geoffrey.levand@am.sony.com wrote:
> Remove the Kconfig message that indicates the PS3 platform support is
> incomplete.
>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
> ---
> arch/powerpc/platforms/ps3/Kconfig | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> --- a/arch/powerpc/platforms/ps3/Kconfig
> +++ b/arch/powerpc/platforms/ps3/Kconfig
> @@ -1,5 +1,5 @@
> config PPC_PS3
> - bool "Sony PS3 (incomplete)"
> + bool "Sony PS3"
> depends on PPC_MULTIPLATFORM && PPC64
> select PPC_CELL
> select USB_ARCH_HAS_OHCI
> @@ -10,10 +10,10 @@ config PPC_PS3
> select MEMORY_HOTPLUG
> help
> This option enables support for the Sony PS3 game console
> - and other platforms using the PS3 hypervisor.
> - Support for this platform is not yet complete, so
> - enabling this will not result in a bootable kernel on a
> - PS3 system.
> + and other platforms using the PS3 hypervisor. Enabling this
> + option will allow building otheros.bld, a kernel image suitable
> + for programming into flash memory, and vmlinux, a kernel image
> + suitable loading via kexec.
^
for
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: [patch 0/3] PS3 bugfix patches for 2.6.23
From: Stephen Rothwell @ 2007-08-08 7:47 UTC (permalink / raw)
To: geoffrey.levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070808171738.40d99505.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 516 bytes --]
Hi Geoff,
On Wed, 8 Aug 2007 17:17:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au>
wrote:
>
> LD .tmp_vmlinux1
> arch/powerpc/platforms/built-in.o: In function `of_has_vicinity':
> /home/sfr/kernels/linus/arch/powerpc/platforms/cell/spu_base.c:681:
> undefined reference to `.spu_devnode'
Ben pointed out patch "[PATCH v2] cell: move SPU affinity init to
spu_management_of_ops" to me.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Device tree aware EMAC driver
From: Benjamin Herrenschmidt @ 2007-08-08 7:34 UTC (permalink / raw)
To: David Gibson; +Cc: LinuxPPC-dev
In-Reply-To: <20070808050937.GF20482@localhost.localdomain>
On Wed, 2007-08-08 at 15:09 +1000, David Gibson wrote:
>
> Eh, all the c++ comments are FIXMEs anyway. I'm inclined to leave
> them.
Ahah... maybe I -did- add some of those then :-) I do use C++ comments
for FIXME's on purpose, because they are ugly, it improves the changes
that I actually get to fix whatever needs fixing :-)
Ben.
^ permalink raw reply
* Re: Device tree aware EMAC driver
From: Benjamin Herrenschmidt @ 2007-08-08 7:33 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, David Gibson
In-Reply-To: <20070808031643.GK10345@bakeyournoodle.com>
> * c++ style comments
Ouch... I haven't removed them all ? I promise I didn't -add- any :-)
> * in emac_probe():
> + /* Wait for dependent devices */
> + err = -ENODEV;
> + err = emac_wait_deps(dev);
> The initialisation to -ENODEV is pointless right?
Leftover from when it was coded differently yes.
> * s/get_property/of_get_property/g or you'll make sfr grumpy ;)
> * In drivers/net/ibm_newemac/Makefile, I think the preferred method is
> to use ibm_newemac-y rather than ibm_newemac-objs.
>
> Is there any reason to leave config IBM_NEW_EMAC (and IBM_EMAC) in
> drivers/net/Kconfig ? It seems to me they'd be nicer to in the
> appropriate drivers/net/*Kconfig.
Probably.
Ben.
^ permalink raw reply
* Re: signals handling in the kernel
From: Mirek23 @ 2007-08-08 7:32 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46B8BA93.8020909@ovro.caltech.edu>
Hi Dave,
I run embedded Linux on ppc405 (ml403 xilinx evaluation board). I use
the GPIO based device build on FPGA part of the xilinx chip. My gpio device
generates interrupts whenever it changes its state.
I use Montavista gpio driver with some modifications to react on interrupts.
Each time when interrupt occurs the interrupt handler routine is called.
This routine sends the signal to the application in user space to trigger
it. When the application is triggered it reads the data from the GPIO
device.
I read that in this situation the best is to use signals. In my case the
ideal would be to use kill_proc_info which sends to the application the
Signal with info data were I intended to put just one integer value. Such a
value determines how to react for the signal on the application level.
Would you have some other suggestion better then the kill_proc_info function
use or even different technique then signaling.
Could you please direct me to the Rubini documentation which you have
mentioned in your last post.
Many thanks
Mirek
David Hawkins-3 wrote:
>
>
> Hi Mirek,
>
>>> I would like to send signals from the interrupt handler
>>> routine (in the kernel) to the user application (in user space).
>>> I have googled on that net and I have found that it could be done with
>>> the
>>> function: kill_proc_info.
>>
>> Look in Rubini for the section regarding asynchronous
>> notification, Ch 6.
>>
>> The callback to generate SIGIO is fasync.
>>
>
> Actually, before you go off and implement something, can
> you describe why you want to use signals.
>
> I mistakenly used signals once to indicate notification of
> an event. Then when I wanted multiple events from multiple
> boards I found the problem with signals; you don't know
> who sent it.
>
> Using select() on multiple file descriptors ended up being
> a more appropriate solution for my application. That
> solution also works nicely with the ACE C++ ACE_Reactor
> pattern.
>
> Cheers,
> Dave
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/signals-handling-in-the-kernel-tf4229566.html#a12048448
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [patch 0/3] PS3 bugfix patches for 2.6.23
From: Stephen Rothwell @ 2007-08-08 7:17 UTC (permalink / raw)
To: geoffrey.levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070808033119.833895506@am.sony.com>
[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]
Hi Geoff,
On Tue, 07 Aug 2007 20:31:19 -0700 geoffrey.levand@am.sony.com wrote:
>
> This small set of PS3 bugfix patches for 2.6.23.
>
> [patch 1/3] PS3: Fix storage probe logic
> [patch 2/3] PS3: Remove incomplete message
> [patch 3/3] PS3: Update ps3_defconfig
>
> Patch 1 fixes a cold startup timing bug in the hard disk probe logic.
>
> Patch 2 removes the 'incomplete' message in the PS3 Kconfig. We now
> have all drivers and platform support needed to build a kernel for the
> PS3. The only major thing missing is wireless networking support, which
> we plan to have ready for 2.6.24.
$ mkdir ../ps3
$ make O=../ps3 ps3_defconfig
$ make O=../ps3
.
.
LD .tmp_vmlinux1
arch/powerpc/platforms/built-in.o: In function `of_has_vicinity':
/home/sfr/kernels/linus/arch/powerpc/platforms/cell/spu_base.c:681: undefined reference to `.spu_devnode'
arch/powerpc/platforms/built-in.o: In function `init_aff_fw_vicinity_node':
/home/sfr/kernels/linus/arch/powerpc/platforms/cell/spu_base.c:726: undefined reference to `.spu_devnode'
arch/powerpc/platforms/built-in.o: In function `aff_devnode_spu':
/home/sfr/kernels/linus/arch/powerpc/platforms/cell/spu_base.c:690: undefined reference to `.spu_devnode'
arch/powerpc/platforms/built-in.o: In function `aff_node_next_to':
/home/sfr/kernels/linus/arch/powerpc/platforms/cell/spu_base.c:703: undefined reference to `.spu_devnode'
/home/sfr/kernels/linus/arch/powerpc/platforms/cell/spu_base.c:705: undefined reference to `.spu_devnode'
arch/powerpc/platforms/built-in.o:/home/sfr/kernels/linus/arch/powerpc/platforms/cell/spu_base.c:649: more undefined references to `.spu_devnode' follow
make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [_all] Error 2
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Fix size check for hugetlbfs
From: Benjamin Herrenschmidt @ 2007-08-08 5:44 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: Paul Mackerras, stable
My "slices" address space management code that was added in 2.6.22
implementation of get_unmapped_area() doesn't properly check that the
size is a multiple of the requested page size. This allows userland to
create VMAs that aren't a multiple of the huge page size with hugetlbfs
(since hugetlbfs entirely relies on get_unmapped_area() to do that
checking) which leads to a kernel BUG() when such areas are torn down.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
This should go to 2.6.22.x stable in addition to current 2.6.23-*
Index: linux-work/arch/powerpc/mm/slice.c
===================================================================
--- linux-work.orig/arch/powerpc/mm/slice.c 2007-08-08 15:16:06.000000000 +1000
+++ linux-work/arch/powerpc/mm/slice.c 2007-08-08 15:16:41.000000000 +1000
@@ -405,6 +405,8 @@ unsigned long slice_get_unmapped_area(un
if (len > mm->task_size)
return -ENOMEM;
+ if (len & ((1ul << pshift) - 1))
+ return -EINVAL;
if (fixed && (addr & ((1ul << pshift) - 1)))
return -EINVAL;
if (fixed && addr > (mm->task_size - len))
^ permalink raw reply
* Re: Device tree aware EMAC driver
From: David Gibson @ 2007-08-08 5:09 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev
In-Reply-To: <20070808031643.GK10345@bakeyournoodle.com>
On Wed, Aug 08, 2007 at 01:16:43PM +1000, Tony Breeds wrote:
> On Tue, Aug 07, 2007 at 04:22:31PM +1000, David Gibson wrote:
> > Based on BenH's earlier work, this is a new version of the EMAC driver
> > for the built-in ethernet found on PowerPC 4xx embedded CPUs. The
> > same ASIC is also found in the Axon bridge chip. This new version is
> > designed to work in the arch/powerpc tree, using the device tree to
> > probe the device, rather than the old and ugly arch/ppc OCP layer.
>
> <snip>
>
> Hi David,
> I had a look over the patch FWIW, asside from the points below
> looks good.
>
> Minor nits:
> * Shouldn't ndev->priv accesses, use netdev_priv() ? if not a comment
> somewhere about why not will keep the janators off your back.
netdev_priv() hey? Hadn't heard of that before. I guess
so... Changed.
> * c++ style comments
Eh, all the c++ comments are FIXMEs anyway. I'm inclined to leave
them.
> * in emac_probe():
> + /* Wait for dependent devices */
> + err = -ENODEV;
> + err = emac_wait_deps(dev);
> The initialisation to -ENODEV is pointless right?
Yes, I think so. Removed.
> * s/get_property/of_get_property/g or you'll make sfr grumpy ;P
Oops, yes.
> * In drivers/net/ibm_newemac/Makefile, I think the preferred method is
> to use ibm_newemac-y rather than ibm_newemac-objs.
>
> Is there any reason to leave config IBM_NEW_EMAC (and IBM_EMAC) in
> drivers/net/Kconfig ? It seems to me they'd be nicer to in the
> appropriate drivers/net/*Kconfig.
Yes, and that also seems to be how it's done for tulip. Moved.
--
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
* [patch 3/3] PS3: Update ps3_defconfig
From: geoffrey.levand @ 2007-08-08 3:31 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070808033119.833895506@am.sony.com>
Update ps3_defconfig.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/configs/ps3_defconfig | 200 ++++++++++++-------------------------
1 file changed, 65 insertions(+), 135 deletions(-)
--- a/arch/powerpc/configs/ps3_defconfig
+++ b/arch/powerpc/configs/ps3_defconfig
@@ -1,9 +1,23 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.22-rc6
-# Tue Jun 26 14:15:19 2007
+# Linux kernel version: 2.6.23-rc2
+# Tue Aug 7 19:17:26 2007
#
CONFIG_PPC64=y
+
+#
+# Processor support
+#
+# CONFIG_POWER4_ONLY is not set
+CONFIG_POWER3=y
+CONFIG_POWER4=y
+CONFIG_PPC_FPU=y
+CONFIG_ALTIVEC=y
+CONFIG_PPC_STD_MMU=y
+# CONFIG_PPC_MM_SLICES is not set
+CONFIG_VIRT_CPU_ACCOUNTING=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=2
CONFIG_64BIT=y
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
@@ -15,6 +29,7 @@ CONFIG_ARCH_HAS_ILOG2_U64=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
+CONFIG_ARCH_NO_VIRT_TO_BUS=y
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_COMPAT=y
@@ -22,50 +37,32 @@ CONFIG_SYSVIPC_COMPAT=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
+CONFIG_OF=y
# CONFIG_PPC_UDBG_16550 is not set
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_DEFAULT_UIMAGE is not set
-
-#
-# Processor support
-#
-# CONFIG_POWER4_ONLY is not set
-CONFIG_POWER3=y
-CONFIG_POWER4=y
-CONFIG_PPC_FPU=y
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
# CONFIG_PPC_OF_PLATFORM_PCI is not set
-CONFIG_ALTIVEC=y
-CONFIG_PPC_STD_MMU=y
-# CONFIG_PPC_MM_SLICES is not set
-CONFIG_VIRT_CPU_ACCOUNTING=y
-CONFIG_SMP=y
-CONFIG_NR_CPUS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
-# Code maturity level options
+# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
-
-#
-# General setup
-#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
-# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
-# CONFIG_UTS_NS is not set
+# CONFIG_USER_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
@@ -100,10 +97,6 @@ CONFIG_SLAB=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
-
-#
-# Loadable module support
-#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
@@ -111,12 +104,9 @@ CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
-
-#
-# Block layer
-#
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_IO_TRACE is not set
+CONFIG_BLK_DEV_BSG=y
#
# IO Schedulers
@@ -136,7 +126,9 @@ CONFIG_DEFAULT_IOSCHED="anticipatory"
#
CONFIG_PPC_MULTIPLATFORM=y
# CONFIG_EMBEDDED6xx is not set
-# CONFIG_APUS is not set
+# CONFIG_PPC_82xx is not set
+# CONFIG_PPC_83xx is not set
+# CONFIG_PPC_86xx is not set
# CONFIG_PPC_PSERIES is not set
# CONFIG_PPC_ISERIES is not set
# CONFIG_PPC_MPC52xx is not set
@@ -223,6 +215,7 @@ CONFIG_MEMORY_HOTPLUG_SPARSE=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
+CONFIG_BOUNCE=y
CONFIG_ARCH_MEMORY_PROBE=y
# CONFIG_PPC_HAS_HASH_64K is not set
# CONFIG_PPC_64K_PAGES is not set
@@ -241,6 +234,7 @@ CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
# CONFIG_PCI is not set
# CONFIG_PCI_DOMAINS is not set
+# CONFIG_PCI_SYSCALL is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
#
@@ -365,6 +359,7 @@ CONFIG_WIRELESS_EXT=y
# CONFIG_MAC80211 is not set
# CONFIG_IEEE80211 is not set
# CONFIG_RFKILL is not set
+# CONFIG_NET_9P is not set
#
# Device Drivers
@@ -379,26 +374,11 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
-
-#
-# Connector - unified userspace <-> kernelspace linker
-#
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
-
-#
-# Parallel port support
-#
+CONFIG_OF_DEVICE=y
# CONFIG_PARPORT is not set
-
-#
-# Plug and Play support
-#
-# CONFIG_PNPACPI is not set
-
-#
-# Block devices
-#
+CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
@@ -411,11 +391,8 @@ CONFIG_BLK_DEV_RAM_SIZE=65535
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
-
-#
-# Misc devices
-#
-# CONFIG_BLINK is not set
+CONFIG_MISC_DEVICES=y
+# CONFIG_EEPROM_93CX6 is not set
# CONFIG_IDE is not set
#
@@ -423,6 +400,7 @@ CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
+CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y
@@ -455,37 +433,22 @@ CONFIG_SCSI_WAIT_SCAN=m
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
-
-#
-# SCSI low-level drivers
-#
-# CONFIG_ISCSI_TCP is not set
-# CONFIG_SCSI_DEBUG is not set
+# CONFIG_SCSI_LOWLEVEL is not set
# CONFIG_ATA is not set
-
-#
-# Multi-device support (RAID and LVM)
-#
# CONFIG_MD is not set
# CONFIG_MACINTOSH_DRIVERS is not set
-
-#
-# Network device support
-#
CONFIG_NETDEVICES=y
+# CONFIG_NETDEVICES_MULTIQUEUE is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
+# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
-
-#
-# Ethernet (10 or 100Mbit)
-#
# CONFIG_NET_ETHERNET is not set
CONFIG_MII=m
CONFIG_NETDEV_1000=y
-CONFIG_NETDEV_10000=y
CONFIG_GELIC_NET=y
+# CONFIG_NETDEV_10000 is not set
#
# Wireless LAN
@@ -518,15 +481,7 @@ CONFIG_USB_NET_MCS7830=m
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
-
-#
-# ISDN subsystem
-#
# CONFIG_ISDN is not set
-
-#
-# Telephony Support
-#
# CONFIG_PHONE is not set
#
@@ -604,10 +559,6 @@ CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=16
-
-#
-# IPMI
-#
# CONFIG_IPMI_HANDLER is not set
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
@@ -616,10 +567,6 @@ CONFIG_GEN_RTC=y
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set
-
-#
-# TPM devices
-#
# CONFIG_TCG_TPM is not set
# CONFIG_I2C is not set
@@ -628,11 +575,8 @@ CONFIG_GEN_RTC=y
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
-
-#
-# Dallas's 1-wire bus
-#
# CONFIG_W1 is not set
+# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
#
@@ -657,6 +601,7 @@ CONFIG_GEN_RTC=y
#
# CONFIG_DISPLAY_SUPPORT is not set
# CONFIG_VGASTATE is not set
+CONFIG_VIDEO_OUTPUT_CONTROL=m
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
@@ -691,11 +636,13 @@ CONFIG_FB_PS3_DEFAULT_SIZE_M=18
# CONFIG_VGA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
+CONFIG_FB_LOGO_EXTRA=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
@@ -709,6 +656,8 @@ CONFIG_SOUND=y
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
+CONFIG_SND_TIMER=y
+CONFIG_SND_PCM=y
# CONFIG_SND_SEQUENCER is not set
# CONFIG_SND_MIXER_OSS is not set
# CONFIG_SND_PCM_OSS is not set
@@ -735,6 +684,12 @@ CONFIG_SND_VERBOSE_PROCFS=y
#
#
+# ALSA PowerPC devices
+#
+CONFIG_SND_PS3=y
+CONFIG_SND_PS3_DEFAULT_START_DELAY=2000
+
+#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
@@ -747,13 +702,14 @@ CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_SOC is not set
#
-# Open Sound System
+# SoC Audio support for SuperH
#
-# CONFIG_SOUND_PRIME is not set
#
-# HID Devices
+# Open Sound System
#
+# CONFIG_SOUND_PRIME is not set
+CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
@@ -770,10 +726,7 @@ CONFIG_USB_HID=m
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
-
-#
-# USB support
-#
+CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
@@ -803,6 +756,7 @@ CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_BIG_ENDIAN_MMIO=y
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
# CONFIG_USB_SL811_HCD is not set
+# CONFIG_USB_R8A66597_HCD is not set
#
# USB Device Class drivers
@@ -879,31 +833,8 @@ CONFIG_USB_MON=y
#
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set
-
-#
-# LED devices
-#
# CONFIG_NEW_LEDS is not set
-
-#
-# LED drivers
-#
-
-#
-# LED Triggers
-#
-
-#
-# InfiniBand support
-#
-
-#
-# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
-#
-
-#
-# Real Time Clock
-#
+# CONFIG_EDAC is not set
# CONFIG_RTC_CLASS is not set
#
@@ -920,6 +851,11 @@ CONFIG_USB_MON=y
#
#
+# Userspace I/O
+#
+# CONFIG_UIO is not set
+
+#
# File systems
#
CONFIG_EXT2_FS=m
@@ -948,8 +884,8 @@ CONFIG_QUOTA=y
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
-# CONFIG_AUTOFS_FS is not set
-CONFIG_AUTOFS4_FS=y
+CONFIG_AUTOFS_FS=m
+CONFIG_AUTOFS4_FS=m
# CONFIG_FUSE_FS is not set
#
@@ -1030,7 +966,6 @@ CONFIG_CIFS=m
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
-# CONFIG_9P_FS is not set
#
# Partition Types
@@ -1096,6 +1031,7 @@ CONFIG_BITREVERSE=y
# CONFIG_CRC16 is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
+# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
@@ -1120,6 +1056,7 @@ CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DETECT_SOFTLOCKUP=y
+CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_SLAB is not set
@@ -1150,10 +1087,6 @@ CONFIG_IRQSTACKS=y
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
-
-#
-# Cryptographic options
-#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
@@ -1191,7 +1124,4 @@ CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_TEST is not set
-
-#
-# Hardware crypto devices
-#
+CONFIG_CRYPTO_HW=y
--
^ permalink raw reply
* [patch 1/3] PS3: Fix storage probe logic
From: geoffrey.levand @ 2007-08-08 3:31 UTC (permalink / raw)
To: paulus; +Cc: Geert Uytterhoeven, linuxppc-dev
In-Reply-To: <20070808033119.833895506@am.sony.com>
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Fix the PS3 storage probe logic to properly find device regions on cold
startup.
o Change the storage probe event mask from notify_device_ready
to notify_region_update.
o Improve the storage probe error handling.
o Change ps3_storage_wait_for_device() to use a temporary variable to hold
the buffer address.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/platforms/ps3/device-init.c | 34 +++++++++++++++----------------
1 file changed, 17 insertions(+), 17 deletions(-)
--- a/arch/powerpc/platforms/ps3/device-init.c
+++ b/arch/powerpc/platforms/ps3/device-init.c
@@ -273,55 +273,57 @@ static int ps3stor_wait_for_completion(u
static int ps3_storage_wait_for_device(const struct ps3_repository_device *repo)
{
+ int error = -ENODEV;
int result;
const u64 notification_dev_id = (u64)-1LL;
const unsigned int timeout = HZ;
u64 lpar;
u64 tag;
+ void *buf;
+ enum ps3_notify_type {
+ notify_device_ready = 1,
+ notify_region_update = 2,
+ };
struct {
u64 operation_code; /* must be zero */
- u64 event_mask; /* 1 = device ready */
+ u64 event_mask; /* OR of ps3_notify_type */
} *notify_cmd;
struct {
- u64 event_type; /* notify_device_ready */
+ u64 event_type; /* enum ps3_notify_type */
u64 bus_id;
u64 dev_id;
u64 dev_type;
u64 dev_port;
} *notify_event;
- enum {
- notify_device_ready = 1
- };
pr_debug(" -> %s:%u: bus_id %u, dev_id %u, dev_type %u\n", __func__,
__LINE__, repo->bus_id, repo->dev_id, repo->dev_type);
- notify_cmd = kzalloc(512, GFP_KERNEL);
- notify_event = (void *)notify_cmd;
- if (!notify_cmd)
+ buf = kzalloc(512, GFP_KERNEL);
+ if (!buf)
return -ENOMEM;
- lpar = ps3_mm_phys_to_lpar(__pa(notify_cmd));
+ lpar = ps3_mm_phys_to_lpar(__pa(buf));
+ notify_cmd = buf;
+ notify_event = buf;
result = lv1_open_device(repo->bus_id, notification_dev_id, 0);
if (result) {
printk(KERN_ERR "%s:%u: lv1_open_device %s\n", __func__,
__LINE__, ps3_result(result));
- result = -ENODEV;
goto fail_free;
}
/* Setup and write the request for device notification. */
- notify_cmd->operation_code = 0; /* must be zero */
- notify_cmd->event_mask = 0x01; /* device ready */
+ notify_cmd->operation_code = 0; /* must be zero */
+ notify_cmd->event_mask = notify_region_update;
result = lv1_storage_write(notification_dev_id, 0, 0, 1, 0, lpar,
&tag);
if (result) {
printk(KERN_ERR "%s:%u: write failed %s\n", __func__, __LINE__,
ps3_result(result));
- result = -ENODEV;
goto fail_close;
}
@@ -332,13 +334,11 @@ static int ps3_storage_wait_for_device(c
if (result) {
printk(KERN_ERR "%s:%u: write not completed %s\n", __func__,
__LINE__, ps3_result(result));
- result = -ENODEV;
goto fail_close;
}
/* Loop here processing the requested notification events. */
- result = -ENODEV;
while (1) {
memset(notify_event, 0, sizeof(*notify_event));
@@ -386,9 +386,9 @@ static int ps3_storage_wait_for_device(c
fail_close:
lv1_close_device(repo->bus_id, notification_dev_id);
fail_free:
- kfree(notify_cmd);
+ kfree(buf);
pr_debug(" <- %s:%u\n", __func__, __LINE__);
- return result;
+ return error;
}
static int ps3_setup_storage_dev(const struct ps3_repository_device *repo,
--
^ permalink raw reply
* [patch 2/3] PS3: Remove incomplete message
From: geoffrey.levand @ 2007-08-08 3:31 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070808033119.833895506@am.sony.com>
Remove the Kconfig message that indicates the PS3 platform support is
incomplete.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/platforms/ps3/Kconfig | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/arch/powerpc/platforms/ps3/Kconfig
+++ b/arch/powerpc/platforms/ps3/Kconfig
@@ -1,5 +1,5 @@
config PPC_PS3
- bool "Sony PS3 (incomplete)"
+ bool "Sony PS3"
depends on PPC_MULTIPLATFORM && PPC64
select PPC_CELL
select USB_ARCH_HAS_OHCI
@@ -10,10 +10,10 @@ config PPC_PS3
select MEMORY_HOTPLUG
help
This option enables support for the Sony PS3 game console
- and other platforms using the PS3 hypervisor.
- Support for this platform is not yet complete, so
- enabling this will not result in a bootable kernel on a
- PS3 system.
+ and other platforms using the PS3 hypervisor. Enabling this
+ option will allow building otheros.bld, a kernel image suitable
+ for programming into flash memory, and vmlinux, a kernel image
+ suitable loading via kexec.
menu "PS3 Platform Options"
depends on PPC_PS3
--
^ permalink raw reply
* [patch 0/3] PS3 bugfix patches for 2.6.23
From: geoffrey.levand @ 2007-08-08 3:31 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul,
This small set of PS3 bugfix patches for 2.6.23.
[patch 1/3] PS3: Fix storage probe logic
[patch 2/3] PS3: Remove incomplete message
[patch 3/3] PS3: Update ps3_defconfig
Patch 1 fixes a cold startup timing bug in the hard disk probe logic.
Patch 2 removes the 'incomplete' message in the PS3 Kconfig. We now
have all drivers and platform support needed to build a kernel for the
PS3. The only major thing missing is wireless networking support, which
we plan to have ready for 2.6.24.
-Geoff
--
^ permalink raw reply
* Re: Linux with data2mem
From: jozsef imrek @ 2007-08-08 3:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <OF56B29E3B.75AC018C-ON85257330.0055CDE0-85257330.0056CDD1@ct.wec.com>
On Tue, 7 Aug 2007 Glenn.G.Hart@us.westinghouse.com wrote:
> ERROR:Data2MEM:33 - Matching ADDRESS_SPACE for code segment #0 not found in
> 'sys
> tem_bd.bmm'.
> Code segment #0 occupies [0x00400000:0x0062AFFF]
>
...
> ///////////////////////////////////////////////////////////////////////////////
>
> ADDRESS_SPACE plb_bram_if_cntlr_1_bram_combined RAMB16
> [0xFFFFC000:0xFFFFFFFF]
make sure that the memory range your software wants to use is backed
by real memory. it seems that your elf expects itself to be loaded at
0x00400000:0x0062AFFF, but you block memory is at 0xFFFFC000:0xFFFFFFFF
(use readelf -l to find out what address ranges does your software want
to use).
probably what you want is a boot loader in the bram, not the kernel image
(the zImage). the boot loader would load the linux kernel into the main
memory (starting at memory address 0x00000000).
--
mazsi
----------------------------------------------------------------
strawberry fields forever! imrek@atomki.hu
----------------------------------------------------------------
^ 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