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
|segme
> 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
> (n
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
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
> MPC
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, 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
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 T
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 se
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,
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, 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 r
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 w
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
__
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; linux
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 i
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:
> + /* Mark reserved regions */
> + for (i = 0; i < lmb.reserved.cnt; i++) {
> + unsigned long physbase = lmb.reserved.region[i].
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
of
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 runs
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 w
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
co
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
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
then
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 +
+
arch/power
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
of
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 k
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 use
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 kerne
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 I
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
* 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,
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
https://
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 d
* 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.
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 3
> > 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,
>
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.
_
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 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 s
38 matches
Mail list logo
