On Mon, 2008-09-29 at 14:38 -0700, Tirumala Reddy Marri wrote:
Could you please point me to the which does the Critical error (Machine
Check) recovery. BTW I am successful booting the Linux until rootfs is
being mounted. It fails to mount the Linux saying that blocks are
corrupted in file
On Mon, 2008-09-29 at 10:26 -0700, Remi Machet wrote:
I also removed the HIGHMEM support in dma_sync since memory allocated for
DMA transfer should always be in ZONE_DMA (ie not in ZONE_HIGHMEM).
While I like the idea of simplifying that stuff, the above sentence is
incorrect unfortunately.
On Mon, 2008-09-29 at 13:03 -0500, Kumar Gala wrote:
We really should change this code over to the new dma changes Becky's
introduced so we just have a non-coherent set of DMA ops (thus we can
do both non-coherent and coherent in the same system).
Yes :-)
Ben.
Becky Bruce (5):
powerpc: Rename dma_64.c to dma.c
powerpc: Move iommu dma ops from dma.c to dma-iommu.c
powerpc: Drop archdata numa_node
powerpc: Merge 32 and 64-bit dma code
powerpc: Make dma_addr_t a u64 if CONFIG_PHYS_64BIT is set
Paul,
poke..
On Sep 29, 2008, at 3:04 PM, Sebastian Siewior wrote:
* Milton Miller | 2008-09-23 20:24:02 [-0500]:
If you have any questions about kdump or what needs to happen,
please feel free to contact me
I copied most of the 64bit code to parse the device tree without the
pci
nodes moved it to
* Jeremy Kerr [EMAIL PROTECTED] wrote:
Mathieu,
We need a marker_synchronize_unregister() before the end of exit() to
make sure every probe callers have exited the non preemptible section
and thus are not executing the probe code anymore.
Looks good - added to spufs.git.
that wont
André,
On Tue, Sep 30, 2008 at 12:05 AM, Leon Woestenberg
[EMAIL PROTECTED] wrote:
Since you also have to assert HRESET when you assert PORESET
But when I assert PORESET, the processor will assert HRESET itself
AFAIK, so why do this?
you can wire-or them with a low drop schottky diode.
Ingo,
that wont work very well as the patch relies on the new
marker_synchronize_unregister() facility.
d'oh, right you are. Should I leave this in your hands to merge?
Cheers,
Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
* Jeremy Kerr [EMAIL PROTECTED] wrote:
Ingo,
that wont work very well as the patch relies on the new
marker_synchronize_unregister() facility.
d'oh, right you are. Should I leave this in your hands to merge?
would be nice if you could give your Acked-by for the sputrace bits,
then we
Ingo,
would be nice if you could give your Acked-by for the sputrace bits,
then we can merge it. It's a oneliner so it shouldnt cause merging
trouble in linux-next.
Sure!
Acked-by: Jeremy Kerr [EMAIL PROTECTED]
Jeremy
___
Linuxppc-dev mailing
On Tue, Sep 23, 2008 at 06:12:19PM +0400, Anton Vorontsov wrote:
of/base.c matches on the first (most specific) entries, which isn't
quite practical but it was discussed[1] that this won't change.
The bindings specifies verbose information for the devices, but
it doesn't fit in the I2C ID's
Remove legacy kdump kernel build support
This patch removes legacy kdump kernel build support(i.e compiling a
kdump kernel at a fixed hardcoded address 32MB). With the relocatable
kernel support its now possible to use the regular kernel binary for
capturing the dump also. Relocatable kdump
Support for relocatable kdump kernel
This patch adds relocatable kernel support for kdump. With this one can
use the same regular kernel to capture the kdump. A signature (0xfeed1234)
is passed in r8 from panic code to the next kernel through kexec_sequence
and purgatory code. The signature is
Relocatable kdump kernel support in kexec-tools
This patch adds relocatable kernel support for kdump in the kexec-tools
code. A signature (0xfeed1234) is passed in r6 from panic code to the
purgatory code through kexec_sequence function. The signature is used to
differentiate between relocatable
Support for the SBC610 VPX Single Board Computer from GE Fanuc (PowerPC
MPC8641D).
A number of MPC8641D based route interrupts for on-board interrupts through
a FPGA based interrupt controller, which is chained with the
MPC8641D's mpic. This patch provides a basic driver to allow basic routing
On Sep 30, 2008, at 9:29 AM, Martyn Welch wrote:
arch/powerpc/boot/dts/gef_sbc610.dts | 38
arch/powerpc/platforms/86xx/gef_sbc610.c | 25 +++
arch/powerpc/sysdev/Makefile |2
arch/powerpc/sysdev/gef_pic.c| 258 +
+
If there are multiple reserved memory blocks via lmb_reserve() that are
contiguous addresses and on different numa nodes we are losing track of which
address ranges to reserve in bootmem on which node. I discovered this
when I only recently got to try 16GB huge pages on a system with more
On Tue, 30 Sep 2008 09:50:58 -0500
Kumar Gala [EMAIL PROTECTED] wrote:
On Sep 30, 2008, at 9:29 AM, Martyn Welch wrote:
arch/powerpc/boot/dts/gef_sbc610.dts | 38
arch/powerpc/platforms/86xx/gef_sbc610.c | 25 +++
arch/powerpc/sysdev/Makefile |2
David Gibson wrote:
This, of course, is exactly why I *don't* recommend embedded platforms
move to including the device tree in the flashed firmware. Keeping
the device tree in the bootwrapper means that it *is* updated with the
kernel and we don't have to mess around with as much backwards
Jon Smirl wrote:
Efika has this:
compatible = fsl,mpc5200b-ohci,fsl,mpc5200-ohci;
It doesn't :D
My system, running production firmware, says
ohci-bigendian,ohci-be,mpc5200-ohci,mpc5200-usb
This is what we were recommended to use at the time. There is a patch
on www.powerdeveloper.org
Sergei Shtylyov wrote:
Hello.
Sébastien Chrétien wrote:
Hello,
I have a question about Device Tree.
Is Device Tree found only only on Linux Powerpc ?
Not only Linux as it's a part of Open Firmware which is also used at
least on SPARC.
The Toshiba TOPAS910 ARM development board also
Support for the SBC610 VPX Single Board Computer from GE Fanuc (PowerPC
MPC8641D).
A number of MPC8641D based route interrupts for on-board interrupts through
a FPGA based interrupt controller, which is chained with the
MPC8641D's mpic. This patch provides a basic driver to allow basic routing
This seems like the right approach to me. I have pointed out a few
stylistic issues below.
On Tue, 2008-09-30 at 09:53 -0500, Jon Tollefson wrote:
snip
+ /* Mark reserved regions */
+ for (i = 0; i lmb.reserved.cnt; i++) {
+ unsigned long physbase =
On Tue, 2008-09-30 at 17:21 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2008-09-29 at 10:26 -0700, Remi Machet wrote:
I also removed the HIGHMEM support in dma_sync since memory allocated for
DMA transfer should always be in ZONE_DMA (ie not in ZONE_HIGHMEM).
While I like the idea of
Ben,
Thanks for the response. I am wondering how user space would get
affected by absence of L1 Dcache.
Thanks,
Marri
-Original Message-
From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2008 12:16 AM
To: Tirumala Reddy Marri
Cc: Olof Johansson;
On Tue, Sep 30, 2008 at 03:29:42PM +0100, Martyn Welch wrote:
+ gef_pic: [EMAIL PROTECTED],4000 {
+ #interrupt-cells = 2;
What is the second interrupt cell for, given that all interrupts are
level-triggered and you don't implement .set_type?
-Scott
Milton Miller wrote:
|load: entry = 0x80053c flags = 0
|nr_segments = 2
|segment[0].buf = 0x1002b8f0
|segment[0].bufsz = 80
|segment[0].mem = (nil)
|segment[0].memsz = 1000
|segment[1].buf = 0x4803f008
|segment[1].bufsz = 3a3138
|segment[1].mem = 0x80
|segment[1].memsz = 3b
I
On Tue, Sep 30, 2008 at 06:18:28PM +0530, Mohan Kumar M wrote:
Remove legacy kdump kernel build support
This patch removes legacy kdump kernel build support(i.e compiling a
kdump kernel at a fixed hardcoded address 32MB). With the relocatable
kernel support its now possible to use the
Hi All,
The following patches have been added to the 4xx 'next' branch
Josh Boyer (3):
ibm_newemac: Allow the no flow control EMAC feature to work
ibm_newemac: Introduce mal_has_feature
ibm_newemac: MAL support for PowerPC 405EZ
Matthias Fuchs (1):
ppc4xx: Allow 4xx PCI
On Tue, 2008-09-30 at 09:57 -0700, Tirumala Reddy Marri wrote:
Ben,
Thanks for the response. I am wondering how user space would get
affected by absence of L1 Dcache.
You didn't answer my question :-)
Well, as I said, things like lwarx/stwcx not working, dcbz taking
alignment exceptions,
Ben,
I got to bring up Linux on one of the 440 processors with out L1
dcache to do some bench marking and compare with L1 d-cache enabled.
I am avoiding any references to dcbz ,dcbt and dcbst . Also the TLB's
are created with cache inhibited. I looked at lwarx/stwcx description,
there
Matt Sealey wrote:
Sergei Shtylyov wrote:
Hello.
Sébastien Chrétien wrote:
Hello,
I have a question about Device Tree.
Is Device Tree found only only on Linux Powerpc ?
Not only Linux as it's a part of Open Firmware which is also used at
least on SPARC.
The Toshiba TOPAS910 ARM
On Tue, 2008-09-30 at 15:26 -0700, Tirumala Reddy Marri wrote:
Ben,
I got to bring up Linux on one of the 440 processors with out L1
dcache to do some bench marking and compare with L1 d-cache enabled.
I am avoiding any references to dcbz ,dcbt and dcbst . Also the TLB's
are
Gerald Van Baren wrote:
Matt Sealey wrote:
The Toshiba TOPAS910 ARM development board also runs Open Firmware and
contains patches to support OF device trees.
I dare say there might be an x86 box or two out there, too. But they
have ACPI tables too which is far more common..
More than a
On Tue, Sep 30, 2008 at 04:34:56PM +0100, Martyn Welch wrote:
Support for the SBC610 VPX Single Board Computer from GE Fanuc (PowerPC
MPC8641D).
A number of MPC8641D based route interrupts for on-board interrupts through
a FPGA based interrupt controller, which is chained with the
On Tue, 2008-09-30 at 18:08 -0500, Matt Sealey wrote:
It's far more common than people might think at first glance. With x86
I am sure it would benefit the platform a little more if the OF support
was in-line with the shared code between PPC and SPARC (and now I guess,
ARM) but nevertheless
This is what we were recommended to use at the time. There is a patch
on www.powerdeveloper.org which tweaks the tree to make it ultra-compliant
with the Linux version of things, which implements every variation. It
also implements a suggested patch which added a big-endian property
(not
On Sep 30, 2008, at 12:21 PM, Sebastian Siewior wrote:
Milton Miller wrote:
|load: entry = 0x80053c flags = 0
|nr_segments = 2
|segment[0].buf = 0x1002b8f0
|segment[0].bufsz = 80
|segment[0].mem = (nil)
|segment[0].memsz = 1000
|segment[1].buf = 0x4803f008
|segment[1].bufsz = 3a3138
38 matches
Mail list logo
