On Wed, 22 Oct 2008 11:27:34 +1100, Benjamin Herrenschmidt wrote:
On Fri, 2008-10-17 at 11:21 +0200, Jean Delvare wrote:
Hi Anton,
On Thu, 16 Oct 2008 21:12:53 +0400, Anton Vorontsov wrote:
If present the info-archdata is copied into the dev-archdata.
Some (OpenFirmware) platforms
On Wed, 2008-10-22 at 08:50 +0200, Jean Delvare wrote:
On Wed, 22 Oct 2008 11:27:34 +1100, Benjamin Herrenschmidt wrote:
On Fri, 2008-10-17 at 11:21 +0200, Jean Delvare wrote:
Hi Anton,
On Thu, 16 Oct 2008 21:12:53 +0400, Anton Vorontsov wrote:
If present the info-archdata is
Hi Mark,
On Thu, 16 Oct 2008 13:04:16 +0100 Mark Brown [EMAIL PROTECTED] wrote:
On Thu, Oct 16, 2008 at 08:47:54PM +1100, Stephen Rothwell wrote:
Today's linux-next build (powerpc allyesconfig) failed like this:
drivers/mfd/wm8350-core.c:1131: error: __ksymtab_wm8350_create_cache causes
Hi Mark,
On Wed, 22 Oct 2008 10:37:22 +0100 Mark Brown [EMAIL PROTECTED] wrote:
On Wed, Oct 22, 2008 at 08:31:12PM +1100, Stephen Rothwell wrote:
I thought that this had been applied, but I have had to apply it to my
tree today again.
Samuel doesn't seem to have picked it up (though
On Wed, Oct 22, 2008 at 06:37:55PM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2008-10-22 at 08:50 +0200, Jean Delvare wrote:
On Wed, 22 Oct 2008 11:27:34 +1100, Benjamin Herrenschmidt wrote:
On Fri, 2008-10-17 at 11:21 +0200, Jean Delvare wrote:
Hi Anton,
On Thu, 16 Oct 2008
On Wed, Oct 22, 2008 at 02:36:41PM +0400, Anton Vorontsov wrote:
On Tue, Oct 21, 2008 at 09:22:48PM -0700, David Brownell wrote:
On Tuesday 21 October 2008, Benjamin Herrenschmidt wrote:
The notifier can be registered before the devices, though it's a little
bit fishy and fragile.
On Wed, 22 Oct 2008 14:08:13 +0400, Anton Vorontsov wrote:
On Wed, Oct 22, 2008 at 06:37:55PM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2008-10-22 at 08:50 +0200, Jean Delvare wrote:
On Wed, 22 Oct 2008 11:27:34 +1100, Benjamin Herrenschmidt wrote:
On Fri, 2008-10-17 at 11:21 +0200,
On Oct 22, 2008, at 3:59 AM, Régis Odeyé wrote:
Hello Everyone,
I'm looking for some information about the Extended Addressing Mode
(XAEN bit of HID0 register) of PPC32 support in Linux.
I do not see anything in the main kernel tree but there may be some
patches available ?
Any
Kumar Gala wrote:
On Oct 22, 2008, at 3:59 AM, Régis Odeyé wrote:
Hello Everyone,
I'm looking for some information about the Extended Addressing Mode
(XAEN bit of HID0 register) of PPC32 support in Linux.
I do not see anything in the main kernel tree but there may be some
patches available
On Oct 22, 2008, at 7:59 AM, Régis Odeyé wrote:
Kumar Gala wrote:
On Oct 22, 2008, at 3:59 AM, Régis Odeyé wrote:
Hello Everyone,
I'm looking for some information about the Extended Addressing
Mode (XAEN bit of HID0 register) of PPC32 support in Linux.
I do not see anything in the main
I'm extremely troubled that it is not used in the code,
surely device_type is checked as a legacy for Open Firmware
(otherwise a lot of devices may never be detected!), or does
device tree parsing/checking follow a different path for FDT?
(absolutely fine with it being removed from new DTS
Kumar Gala wrote:
So we have XAEN support in the tree.. however non-contiguous is
something you'll have to work on yourself. Patches are welcome for this
OK. I will let you know about this.
Where can I glance through Becky patches ?
This is the bulk:
Kumar Gala wrote:
On Oct 22, 2008, at 7:59 AM, Régis Odeyé wrote:
of ram. So I need 4GB+IOs (~1GB) of physical addressing space.
My plan is to put a part of this ram above of 4GB to keep accesses to
the IOs below the 4GB limit. It means non-contiguous ram addressing
and XAEN features to
On Wed, Oct 22, 2008 at 08:38:03AM -0500, Matt Sealey wrote:
I'm extremely troubled that it is not used in the code, surely
device_type is checked as a legacy for Open Firmware (otherwise a lot of
devices may never be detected!),
Checked where? Can you point out a code snippet? (Except for
On Oct 22, 2008, at 8:42 AM, Matt Sealey wrote:
Kumar Gala wrote:
On Oct 22, 2008, at 7:59 AM, Régis Odeyé wrote:
of ram. So I need 4GB+IOs (~1GB) of physical addressing space.
My plan is to put a part of this ram above of 4GB to keep accesses
to the IOs below the 4GB limit. It means
Matt Sealey wrote:
I'd also be interested in any work done to enable non-contiguous
memory areas. Reading the docs for the MPC8641D though I am not sure
you can set up LAWs for it?
One thing I wanted to try was installing 4GB in a system and
overlapping IO (since there is very little of it
Kumar Gala wrote:
On Oct 22, 2008, at 8:42 AM, Matt Sealey wrote:
So to confirm, XAEN support through Becky's patches does support the
MPC8641D/e600 cores?
Yes, its the only part that has XAEN.
Okay I saw a lot of e500/BookE support go past but nothing
specific :)
NOT supported
Kumar Gala wrote:
Your bigger issue is if you can setup the DDR controller for the hole
you want.
I just remembered;;
~~
The CCSR window always takes precedence over all local access
windows. However, the CCSR window must not overlap an LAW that
maps to the DDR controller. Otherwise,
Hi Ilya,
I just tried your patch on my 440 board because it would help us in our
environment.
Unfortunately I run into a bug on early boot (mark_bootmem).
A log can be found in this mail, this is the bug when running with 64k
page size.
I tried this with and without your 2/2 265k patch and
The 'ibm,interrupt-server#-size' properties are not cpu nodes properties,
but rather live under the interrupt source controller nodes (compatible
ibm,ppc-xics).
Therefore, this patch moves the detection of this property outside of
xics_update_irq_servers() and into xics_init_IRQ().
Also
On Oct 22, 2008, at 9:19 AM, Matt Sealey wrote:
Kumar Gala wrote:
On Oct 22, 2008, at 8:42 AM, Matt Sealey wrote:
So to confirm, XAEN support through Becky's patches does support
the MPC8641D/e600 cores?
Yes, its the only part that has XAEN.
Okay I saw a lot of e500/BookE support go
On Oct 22, 2008, at 9:22 AM, Matt Sealey wrote:
Kumar Gala wrote:
Your bigger issue is if you can setup the DDR controller for the
hole you want.
I just remembered;;
~~
The CCSR window always takes precedence over all local access
windows. However, the CCSR window must not overlap an
On Tue, Oct 21, 2008 at 10:58 PM, Paul Mackerras [EMAIL PROTECTED] wrote:
Stephen Rothwell writes:
On Tue, 21 Oct 2008 16:33:10 +1100 Paul Mackerras [EMAIL PROTECTED]
wrote:
It's a bug in older versions of ld (including 2.16.1) that's fixed in
the current version (2.18). However,
A new field has been added to the VPA as a method for
the client OS to communicate to firmware the number of
page ins it is performing when running collaborative
memory overcommit. The hypervisor will use this information
to better determine if a partition is experiencing memory
pressure and needs
* Nick Piggin [EMAIL PROTECTED] wrote:
Speed up generic mutex implementations.
- atomic operations which both modify the variable and return something imply
full smp memory barriers before and after the memory operations involved
(failing atomic_cmpxchg, atomic_add_unless, etc don't
Nick Piggin [EMAIL PROTECTED] wrote:
Speed up generic mutex implementations.
- atomic operations which both modify the variable and return something imply
full smp memory barriers before and after the memory operations involved
(failing atomic_cmpxchg, atomic_add_unless, etc don't imply
I just tried booting a post 2.6.27 -git on a Motorola ATCA6101 (very similar
to a Maple board). The first time I booted I got the first log below. I
rebooted and got as far as a login prompt. I was able to log in via the
serial console, but then got an almost identical oops again, as shown
Paul Mackerras wrote:
Chris, could you try just the following change (my previous patch
without the arch/powerpc/boot/wrapper change) and let me know if it
fixes things with the ld you use?
The build completes with no errors. Haven't actually booted it though.
Gets my vote...
Chris
Ilya, here the snippet you asked for with CONFIG_DEBUG_BUGVERBOSE
enabled and bootmem_debug set.
## Booting kernel from Legacy Image at 0400 ...
Image Name: Linux-2.6.27-dirty
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size:1521505 Bytes = 1.5 MB
Load
Kumar Gala wrote:
On Oct 22, 2008, at 9:19 AM, Matt Sealey wrote:
Kumar Gala wrote:
On Oct 22, 2008, at 8:42 AM, Matt Sealey wrote:
So to confirm, XAEN support through Becky's patches does support the
MPC8641D/e600 cores?
Yes, its the only part that has XAEN.
Okay I saw a lot of
Hollis Blanchard wrote:
binutils 2.16.1 is the most recent binutils that will build with
crosstool, so IMHO it's worth supporting. :)
I was wondering about thatwasted a bunch of time trying to build something
more recent.
Chris
___
Kumar Gala wrote:
On Oct 22, 2008, at 9:22 AM, Matt Sealey wrote:
~~
The CCSR window always takes precedence over all local access windows.
However, the CCSR window must not overlap an LAW that maps to the DDR
controller. Otherwise, undefined behavior occurs.
~~
So, it's not really
On Wed, Oct 22, 2008 at 02:46:06PM +0400, Anton Vorontsov wrote:
On Wed, Oct 22, 2008 at 02:36:41PM +0400, Anton Vorontsov wrote:
On Tue, Oct 21, 2008 at 09:22:48PM -0700, David Brownell wrote:
On Tuesday 21 October 2008, Benjamin Herrenschmidt wrote:
The notifier can be registered
Anton Vorontsov wrote:
On Wed, Oct 22, 2008 at 08:38:03AM -0500, Matt Sealey wrote:
I'm extremely troubled that it is not used in the code, surely
device_type is checked as a legacy for Open Firmware (otherwise a lot of
devices may never be detected!),
Checked where?
On Wed, Oct 22, 2008 at 01:40:50PM -0500, Matt Sealey wrote:
Anton Vorontsov wrote:
On Wed, Oct 22, 2008 at 08:38:03AM -0500, Matt Sealey wrote:
I'm extremely troubled that it is not used in the code, surely
device_type is checked as a legacy for Open Firmware (otherwise a lot
of devices
Anton Vorontsov wrote:
On Wed, Oct 22, 2008 at 01:40:50PM -0500, Matt Sealey wrote:
I think I got it. ;-) You think that I'm not aware of that we _can_
use the device_type for matching the nodes. Well, I'm aware of it,
sure we can. ;-)
I'm sure you are aware, I am just a little jumpy
On Wed, Oct 22, 2008 at 02:09:01PM -0500, Matt Sealey wrote:
Anton Vorontsov wrote:
On Wed, Oct 22, 2008 at 01:40:50PM -0500, Matt Sealey wrote:
I think I got it. ;-) You think that I'm not aware of that we _can_
use the device_type for matching the nodes. Well, I'm aware of it,
sure we can.
On Oct 22, 2008, at 1:11 PM, Matt Sealey wrote:
Kumar Gala wrote:
On Oct 22, 2008, at 9:19 AM, Matt Sealey wrote:
Kumar Gala wrote:
On Oct 22, 2008, at 8:42 AM, Matt Sealey wrote:
So to confirm, XAEN support through Becky's patches does support
the MPC8641D/e600 cores?
Yes, its the
On Oct 22, 2008, at 9:36 AM, Sebastien Dugue wrote:
The 'ibm,interrupt-server#-size' properties are not cpu nodes
properties,
but rather live under the interrupt source controller nodes (compatible
ibm,ppc-xics).
Therefore, this patch moves the detection of this property outside of
Matt Sealey wrote:
Anton Vorontsov wrote:
We don't want to encourage the device_type usage. It isn't used in the
code, so we can simply remove it from the dts files.
I'm extremely troubled that it is not used in the code,
surely device_type is checked as a legacy for Open Firmware
as of 4792adbac9eb41cea77a45ab76258ea10d411173
CONFIG_SPU_FS=n
CONFIG_PPC_CELL=y
CONFIG_PPC_CELL_NATIVE=y
CONFIG_PPC_IBM_CELL_BLADE=y
CONFIG_CBE_RAS=y
CONFIG_PPC_IBM_CELL_RESETBUTTON=y
CONFIG_CBE_THERM=y
rest mostly pseries_defconfig.
MODPOST vmlinux.o
WARNING: modpost: Found 8 section
The updates kexec-tools to match the kernel after the patches
kexec exit should not use magic numbers and
better flag for running relocatable are applied.
Signed-off-by: Milton Miller [EMAIL PROTECTED]
---
Still proposed change
Index: kexec-tools/purgatory/arch/ppc64/v2wrap.S
Every time add_segment is called, the segments are sorted. If the first
hole in memory is not big enough for the kernel then something besides
the kernel may be at
Signed-off-by: Milton Miller [EMAIL PROTECTED]
---
Found during custom environment testing with several reserved blocks of
memory,
The __kdump_flag ABI is overly constraining for future development.
As of 2.6.27, the kernel entry point has 4 constraints: Offset 0 is
the starting point for the master (boot) cpu (entered with r3 pointing
to the device tree structure), offset 0x60 is code for the slave cpus
(entered with r3
The relocatable kernel kdump patch (54622f10a6aabb8bb2bdacf3dd070046f03dc246)
added a magic flag value in a register to tell purgatory that it should
be a panic kernel. This part is wrong and is reverted by this patch.
The kernel gets a list of memory blocks and a entry point from user space.
On Oct 22, 2008, at 3:39 PM, Milton Miller wrote:
Every time add_segment is called, the segments are sorted. If the
first
hole in memory is not big enough for the kernel then something besides
the kernel may be at
info-segment[0].
---
Found during custom environment testing with several
On Wednesday 22 October 2008, Anton Vorontsov wrote:
The board info has another problem though. We can't remove it, thus
we can't implement module_exit() for the 'OF glue'.
That's not a problem. Why would you want to remove it?
And try to solve this problem... maybe then things will
On Wed, Oct 22, 2008 at 02:04:52PM -0700, David Brownell wrote:
On Wednesday 22 October 2008, Anton Vorontsov wrote:
The board info has another problem though. We can't remove it, thus
we can't implement module_exit() for the 'OF glue'.
That's not a problem. Why would you want to
On Wednesday 22 October 2008, Anton Vorontsov wrote:
So if we register the board infos after
the controller registered, then nobody will probe the board infos.
See above. If you're doing it right, there's no problem.
That is, scan the OF tables early. Just like PNP tables
get
On Wed, 2008-10-22 at 08:08 -0500, Kumar Gala wrote:
We are developing a board based on Freescale 8641D which can get
4GB
of ram. So I need 4GB+IOs (~1GB) of physical addressing space.
My plan is to put a part of this ram above of 4GB to keep accesses
to the IOs below the 4GB limit.
Becky Bruce wrote:
On Oct 22, 2008, at 1:11 PM, Matt Sealey wrote:
Yeah so I saw BookE and e500 stuff go past but nothing specific for
e600/XAEN. I mailed Becky and got no response. I'm glad to know it's
in there though, somewhere.
Huh? I have one mail from you, on Sep 1, to which I
Benjamin Herrenschmidt wrote:
On Wed, 2008-10-22 at 08:08 -0500, Kumar Gala wrote:
We are developing a board based on Freescale 8641D which can get
4GB
of ram. So I need 4GB+IOs (~1GB) of physical addressing space.
My plan is to put a part of this ram above of 4GB to keep accesses
to the
On Wed, Oct 22, 2008 at 02:52:46PM -0700, David Brownell wrote:
On Wednesday 22 October 2008, Anton Vorontsov wrote:
So if we register the board infos after
the controller registered, then nobody will probe the board infos.
See above. If you're doing it right, there's no
On Wed, 2008-10-22 at 17:21 -0500, Matt Sealey wrote:
Because we're Genesi! And we have a firmware solution that
kind of has to keep 32-bit pointers in the unlikely event that
someone actually uses the client interface (besides yaboot!).
Having I/O in the 36-bit range could cause all
(Oops, resending in plain text...)
On Tue, Oct 21, 2008 at 10:58 PM, Paul Mackerras [EMAIL PROTECTED] wrote:
Stephen Rothwell writes:
On Tue, 21 Oct 2008 16:33:10 +1100 Paul Mackerras [EMAIL PROTECTED] wrote:
It's a bug in older versions of ld (including 2.16.1) that's fixed in
the
thanks, applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
thanks, applied with a slightly expanded changelog.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[ Added Mohan Kumar to CC list ]
On Wed, Oct 22, 2008 at 03:39:18PM -0500, Milton Miller wrote:
The relocatable kernel kdump patch (54622f10a6aabb8bb2bdacf3dd070046f03dc246)
added a magic flag value in a register to tell purgatory that it should
be a panic kernel. This part is wrong and is
Hi all,
Things are getting better. Here are the messages from a ppc64_defconfig
build this morning (Linus' tree plus a merge of DaveM's pending network
tree):
kernel/trace/ring_buffer.c: In function 'rb_add_time_stamp':
kernel/trace/ring_buffer.c:969: warning: format '%llu' expects type 'long
On Wed, Oct 22, 2008 at 11:50:25AM -0600, Chris Friesen wrote:
Hollis Blanchard wrote:
binutils 2.16.1 is the most recent binutils that will build with
crosstool, so IMHO it's worth supporting. :)
I was wondering about thatwasted a bunch of time trying to build
something more recent.
On Tue, Oct 21, 2008 at 03:50:30PM -0700, Satya wrote:
On Tue, Oct 21, 2008 at 3:46 PM, Satya [EMAIL PROTECTED] wrote:
Ben,
Look here: http://www-unix.mcs.anl.gov/zeptoos/hugepages/
thanks,
./satya
On Tue, Oct 21, 2008 at 1:47 PM, Benjamin Herrenschmidt
[EMAIL PROTECTED]
In message [EMAIL PROTECTED] you wrote:
The __kdump_flag ABI is overly constraining for future development.
As of 2.6.27, the kernel entry point has 4 constraints: Offset 0 is
the starting point for the master (boot) cpu (entered with r3 pointing
to the device tree structure), offset 0x60
Milton Miller writes:
Move the flag to 0x5c, 1 word before the secondary cpu entry point at
0x60. Use the copy at address 0 not the one in the base kernel image to
make it easier on kexec-tools.
Why is it easier on kexec-tools? Doesn't kexec-tools know where it
put the kernel?
I'd much
Print physical start address for the relocatable kernel.
Also fixes this warning:
arch/powerpc/kernel/setup_64.c:447:5: warning: kernstart_addr is not defined
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
arch/powerpc/kernel/setup_64.c |6 +++---
1 file changed, 3 insertions(+), 3
Paul Mackerras writes:
Milton Miller writes:
Move the flag to 0x5c, 1 word before the secondary cpu entry point at
0x60. Use the copy at address 0 not the one in the base kernel image to
make it easier on kexec-tools.
Why is it easier on kexec-tools? Doesn't kexec-tools know where it
Commit 549e8152de8039506f69c677a4546e5427aa6ae7 (powerpc: Make the
64-bit kernel as a position-independent executable) added lines to
vmlinux.lds.S to add the extra sections needed to implement a
relocatable kernel. However, those lines seem to trigger a bug in
older versions of GNU ld (such as
On Wed, 2008-10-22 at 17:59 +0200, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
Speed up generic mutex implementations.
- atomic operations which both modify the variable and return something
imply
full smp memory barriers before and after the memory operations
On Wed, 2008-10-22 at 14:04 -0700, David Brownell wrote:
So if we register the board infos after
the controller registered, then nobody will probe the board infos.
See above. If you're doing it right, there's no problem.
That is, scan the OF tables early. Just like PNP tables
get
Hi Rusty,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
arch/powerpc/platforms/cell/spu_base.c: In function 'mm_needs_global_tlbie':
arch/powerpc/platforms/cell/spu_base.c:117: error: implicit declaration of
function '__cpus_setall'
Caused by commit
On Wednesday 22 October 2008, Anton Vorontsov wrote:
So have it live in the __init text section...
Won't work, unfortunately. I2C devices are created by the
i2c controllers, via drivers/of_i2c.c of_register_i2c_devices().
And I'm pointing out a way to have the normal I2C core code
flow
Print physical start address for the relocatable kernel.
Also fixes this warning:
arch/powerpc/kernel/setup_64.c:447:5: warning: kernstart_addr is not defin
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
arch/powerpc/kernel/setup_64.c |6 +++---
1 file changed, 3 insertions(+), 3
71 matches
Mail list logo
