* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Kumar Gala @ 2006-10-20 14:18 UTC (permalink / raw)
To: Nicolas DET; +Cc: linuxppc-dev, tnt, sl
In-Reply-To: <453884F5.4000804@bplan-gmbh.de>
On Oct 20, 2006, at 3:12 AM, Nicolas DET wrote:
> Kumar Gala wrote:
> >
> > On Oct 19, 2006, at 7:39 AM, Nicolas DET wrote:
> >
> >> This 'big' patch adds support for CHRP/MPC52xx based platform.
> Here, this is the bPlan's Efika computer (http://www.bplan-gmbh.de/
> efika_spec_en.html)
> >
>
> > Some high level comments:
> > 1. lets stick with the 52xx naming, instead of 5k2
>
> Ok. Will be done
>
> > 2. PIC code needs to be updated for new interrupt model (as well
> as remove of pt_regs)
>
> Ok.
>
> > 3. use standard kernel debug macros
>
> Loads of changes in the pipe line ;-)
>
> > 4. look at replacing sram_allocator w/rheap
> >
>
> This SRAM allocator is the exact same from the original Linux one.
> In fact, it is the original one. Would it be possible to accept
> this code as it is and schedule rheap integration later ?
I dont follow, what do you mean by 'original Linux one' ?
> > if you repost the patch broken up into driver and platform bits
> it will be easier to provide more detailed comments.
>
> Ok. I'm alraedy working on it since I post the first one :-) .
> Thank you very much for your comments. I hope to re submit a much
> better patch today.
>
> Regads
> <nd.vcf>
^ permalink raw reply
* [PATCH] stop infinite loop in start_ldr due to unaligned sections
From: Olaf Hering @ 2006-10-20 13:57 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Quick fix for lack of memset(__bss_start,0,_end-__bss_start) in load_kernel()
If edata is unaligned, the loop will overwrite all memory because
r3 and r4 will never be equal.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
arch/ppc/boot/simple/relocate.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.19-rc2/arch/ppc/boot/simple/relocate.S
===================================================================
--- linux-2.6.19-rc2.orig/arch/ppc/boot/simple/relocate.S
+++ linux-2.6.19-rc2/arch/ppc/boot/simple/relocate.S
@@ -154,8 +154,8 @@ do_relocate_out:
start_ldr:
/* Clear all of BSS and set up stack for C calls */
- lis r3,edata@h
- ori r3,r3,edata@l
+ lis r3,__bss_start@h
+ ori r3,r3,__bss_start@l
lis r4,end@h
ori r4,r4,end@l
subi r3,r3,4
@@ -163,7 +163,7 @@ start_ldr:
li r0,0
50: stwu r0,4(r3)
cmpw cr0,r3,r4
- bne 50b
+ blt 50b
90: mr r9,r1 /* Save old stack pointer (in case it matters) */
lis r1,.stack@h
ori r1,r1,.stack@l
^ permalink raw reply
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Segher Boessenkool @ 2006-10-20 13:59 UTC (permalink / raw)
To: Olaf Hering; +Cc: akpm, linuxppc-dev, Sven Luther, tilmann
In-Reply-To: <20061020100010.GA5867@aepfle.de>
>> Yeah, that makes sense. Will the device-tree move to /sys some
>> day ? What
>
> Moving /proc/device-tree would be an insane change.
It should really be a separate filesystem, not part of procfs;
and then people can mount it wherever they want (in theory).
Segher
^ permalink raw reply
* Re: Correct way to format spufs file output.
From: Dwayne Grant McConnell @ 2006-10-20 13:54 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <200610201023.12796.arnd@arndb.de>
On Fri, 20 Oct 2006, Arnd Bergmann wrote:
> On Thursday 19 October 2006 05:30, Dwayne Grant McConnell wrote:
> > In a recent submission I added the lslr file and used "%llx" for the
> > format string. You mentioned that it should probably be "0x%llx" so it
> > would be clearly parsed as hex so I changed it in the next submission. But
> > I noticed that there seems to be some inconsistent usage of 0x as follows:
>
> Thanks for bringing this up, I guess I screwed up in some way here, so
> we should fix it up one way or another:
>
> > signal1_type (%llu)
> > signal2_type (%llu)
>
> These are fine, they can only ever be 1 or 0.
>
> > npc (%llx)
>
> I think we used to access this in _very_ old versions of libspe,
> before we move to a syscall based interface.
>
> > decr (%llx)
> > decr_status (%llx)
> > spu_tag_mask (%llx)
> > event_mask (%llx)
> > event_status (%llx)
> > srr0 (%llx)
>
> These are used exclusively for debugging purposes, and no publically
> available version of gdb accesses them, so I guess we can still change
> them, although it's not nice.
>
> > phys_id (0x%llx)
>
> This one is used in some forks of libspe, we should not change it.
>
> > object_id (0x%llx)
>
> This is used in libspe, gdb and oprofile, but only in fairly recent
> versions.
>
> > lslr (0x%llx)
>
> As this is introduced by your own patch, there is no precedent for
> it yet.
>
> Current kernels now also have 'cntl' (0x%08lx), which was introduced
> in 2.6.19 and is so far unused. I guess we should change that one
> to be consistant with the others as well.
>
> > Should all the %llx be changed to 0x%llx or should the 0x be dropped from
> > those that have it or is the inconsistency acceptable?
>
> I'd rather have it consistant. Moreover, I guess the "%llx" format is
> actually harmful, because that means you can not use the same format
> for read and write. The simple_attr_write function currently uses
> the simple_strtol helper to interpret the value written to it, and that
> requires the input to be wither decimal, or hexadecimal with a preceding
> 0x. I'd suggest we change all files to take a 0x%llx format on output.
I think %0xllx is the way to go. I would even advocate changing
signal1_type and signal2_type unless it is actually too dangerous. Is
there even a case where changing from %llu to %0xllx would break things?
Perhaps with the combination of a old library with a new kernel?
--
Dwayne Grant McConnell <decimal@us.ibm.com>
Lotus Notes Mail: Dwayne McConnell [Mail]/Austin/IBM@IBMUS
Lotus Notes Calendar: Dwayne McConnell [Calendar]/Austin/IBM@IBMUS
^ permalink raw reply
* Build openssl in ELDK 3.1.1
From: tran vanle @ 2006-10-20 12:46 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]
Thanks Wolfgang Denk
I'm reinstall ELDK 3.1.1 and it ok
I rebuild openssl like that
- Download openssl-0.9.7f-7.10_1.src.rpm in <project>/usr/src/denx/SRPMS
- Go to <project>/usr/src/denx/SRPMS and run
ppc_8xx-rpm -iv openssl-0.9.7f-7.10_1.src.rpm
- Go to <project>/usr/src/denx/SPECS and run
ppc_8xx-rpmbuild openssl.spec
Then I receive in <project>/usr/src/denx/openssl-0.9.7f/ libssl.so.0.9.7 and openssl in <project>/usr/src/denx/openssl-0.9.7f/apps
That's OK
But I don't know Was command openssl added in image in <project>/ppc_8xx/images? If no how i can do it ?
I also want to rebuild kernel but i only receive vmlinux in <project>/ppc_8xx/usr/src/linux/ Was vmlinux added in image in <project>/ppc_8xx/images? If no how i can do it ?
If I want to build an application but not in ftp://ftp.sunet.se/pub/Linux/distributions/eldk/3.1.1/ppc-linux-x86/sources/target/SRPMS/
how can I do?
Thanks
LeVan
---------------------------------
On Yahoo!7
Fuel Price Watch: Find the cheapest petrol in your area
[-- Attachment #2: Type: text/html, Size: 1342 bytes --]
^ permalink raw reply
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Paul Mackerras @ 2006-10-20 10:01 UTC (permalink / raw)
To: Olaf Hering; +Cc: akpm, linuxppc-dev, Sven Luther, tilmann
In-Reply-To: <20061020064456.GA3946@aepfle.de>
Olaf Hering writes:
> About 32bit/64bit, maybe VmallocTotal from /proc/meminfo can be used.
> incredible large numer == must be a 64bit kernel
> No idea how reliable it is. There are those 36bit systems, but I bet
> they dont run a distro.
They only have 32-bit effective addresses and therefore a similar
VmallocTotal to any other 32-bit powerpc machine.
Paul.
^ permalink raw reply
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Olaf Hering @ 2006-10-20 10:00 UTC (permalink / raw)
To: Sven Luther; +Cc: akpm, linuxppc-dev, Sven Luther, tilmann
In-Reply-To: <20061020085207.GA21103@powerlinux.fr>
On Fri, Oct 20, Sven Luther wrote:
> Yeah, that makes sense. Will the device-tree move to /sys some day ? What
Moving /proc/device-tree would be an insane change.
^ permalink raw reply
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Sven Luther @ 2006-10-20 8:52 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: akpm, Olaf Hering, Sven Luther, tilmann, linuxppc-dev
In-Reply-To: <D22CDFD1-C5A7-422E-9052-FFB5480AE06F@kernel.crashing.org>
On Fri, Oct 20, 2006 at 10:12:40AM +0200, Segher Boessenkool wrote:
> >>cpuinfo is about the cpu, not the board layout nor the firmware
> >>expectations.
> >
> >What is the machine: field doing there then ? Would it make sense
> >to provide a
> >machineinfo then ?
>
> Yes. Or better, don't use /proc, get all info from sysfs
> (with a nice userland tool to summarize the info, perhaps).
Yeah, that makes sense. Will the device-tree move to /sys some day ? What
about things like the /rtas node ?
But it will be years before all the distros move to it probably, see how most
of them still use parsing of the parted command line output for handling
partition table detection, and thus fail on anything not MBR.
Friendly,
Sven Luther
^ permalink raw reply
* Re: Correct way to format spufs file output.
From: Arnd Bergmann @ 2006-10-20 8:23 UTC (permalink / raw)
To: cbe-oss-dev, linux-kernel; +Cc: linuxppc-dev, Dwayne Grant McConnell
In-Reply-To: <Pine.WNT.4.64.0610182227120.6056@doodlebug>
On Thursday 19 October 2006 05:30, Dwayne Grant McConnell wrote:
> In a recent submission I added the lslr file and used "%llx" for the
> format string. You mentioned that it should probably be "0x%llx" so it
> would be clearly parsed as hex so I changed it in the next submission. But
> I noticed that there seems to be some inconsistent usage of 0x as follows:
Thanks for bringing this up, I guess I screwed up in some way here, so
we should fix it up one way or another:
> signal1_type (%llu)
> signal2_type (%llu)
These are fine, they can only ever be 1 or 0.
> npc (%llx)
I think we used to access this in _very_ old versions of libspe,
before we move to a syscall based interface.
> decr (%llx)
> decr_status (%llx)
> spu_tag_mask (%llx)
> event_mask (%llx)
> event_status (%llx)
> srr0 (%llx)
These are used exclusively for debugging purposes, and no publically
available version of gdb accesses them, so I guess we can still change
them, although it's not nice.
> phys_id (0x%llx)
This one is used in some forks of libspe, we should not change it.
> object_id (0x%llx)
This is used in libspe, gdb and oprofile, but only in fairly recent
versions.
> lslr (0x%llx)
As this is introduced by your own patch, there is no precedent for
it yet.
Current kernels now also have 'cntl' (0x%08lx), which was introduced
in 2.6.19 and is so far unused. I guess we should change that one
to be consistant with the others as well.
> Should all the %llx be changed to 0x%llx or should the 0x be dropped from
> those that have it or is the inconsistency acceptable?
I'd rather have it consistant. Moreover, I guess the "%llx" format is
actually harmful, because that means you can not use the same format
for read and write. The simple_attr_write function currently uses
the simple_strtol helper to interpret the value written to it, and that
requires the input to be wither decimal, or hexadecimal with a preceding
0x. I'd suggest we change all files to take a 0x%llx format on output.
Arnd <><
^ permalink raw reply
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Benjamin Herrenschmidt @ 2006-10-20 8:16 UTC (permalink / raw)
To: Sven Luther; +Cc: akpm, Olaf Hering, Sven Luther, tilmann, linuxppc-dev
In-Reply-To: <20061020073653.GB17286@powerlinux.fr>
> Why not say it directly in a standard way ? So we avoid all distros and/or
> different tools who need to know, to implement their own slightly different
> way ?
There is a standard way... uname
Ben.
^ permalink raw reply
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Nicolas DET @ 2006-10-20 8:13 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: akpm, linuxppc-dev, Sven Luther, tilmann
In-Reply-To: <200610180022.24631.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]
Arnd Bergmann wrote:
> On Tuesday 17 October 2006 15:22, Christoph Hellwig wrote:
>>> rtas_node = of_find_node_by_name(NULL, "rtas");
>>> if (rtas_node == NULL)
>>> return -ENODEV;
>> And given this check I wonder why we need the platform check at all. It
>> should be safe to just remove it.
>>
> One difference would be that it triggers on machines running SLOF
(QS20, some JS20/JS21) and maybe some older Macs, which is probably a good
> thing.
>
> I wonder if it should be a little stricter though:
>
>> rtas_node = of_find_node_by_path("/rtas");
>> if (!rtas_node)
>> return -ENODEV;
>
> In case there is a node called "rtas" somewhere else.
>
> Arnd <><
>
Maybe we could check for the RTAS revision. The CHRP manual define this
properties 'rtas-version' in /rtas/. This should be 1 for current
implementation.
You can find here a new patch. It does not create the /proc/rtas and the
symlink /proc/ppc64/rtas in arch/powerpc/kernel/proc_ppc64.c anymore
but rather create the entry (/proc/rtas) in
arch/powerpc/kernel/rtas-proc.c and only the ppc64/ratas link for 64bit
machine.
This has been tested on our PowerPC 32bit machine. It would be nice if
PowerPC64 developer could reveiw and test it.
I stay ready to test upcomming patch if required.
Regards
[-- Attachment #2: rtas_proc.patch --]
[-- Type: text/plain, Size: 2984 bytes --]
diff -uprN a/arch/powerpc/kernel/proc_ppc64.c b/arch/powerpc/kernel/proc_ppc64.c
--- a/arch/powerpc/kernel/proc_ppc64.c 2006-10-14 05:34:03.000000000 +0200
+++ b/arch/powerpc/kernel/proc_ppc64.c 2006-10-20 08:32:20.000000000 +0200
@@ -51,15 +51,6 @@ static int __init proc_ppc64_create(void
if (!root)
return 1;
- if (!of_find_node_by_path("/rtas"))
- return 0;
-
- if (!proc_mkdir("rtas", root))
- return 1;
-
- if (!proc_symlink("rtas", NULL, "ppc64/rtas"))
- return 1;
-
return 0;
}
core_initcall(proc_ppc64_create);
diff -uprN a/arch/powerpc/kernel/rtas-proc.c b/arch/powerpc/kernel/rtas-proc.c
--- a/arch/powerpc/kernel/rtas-proc.c 2006-10-14 05:34:03.000000000 +0200
+++ b/arch/powerpc/kernel/rtas-proc.c 2006-10-20 08:22:57.000000000 +0200
@@ -253,43 +253,60 @@ static void get_location_code(struct seq
static void check_location_string(struct seq_file *m, char *c);
static void check_location(struct seq_file *m, char *c);
+static int __init proc_rtas_create(void)
+{
+ struct proc_dir_entry *root;
+
+ root = proc_mkdir("rtas" , NULL);
+ if (!root)
+ return -1;
+
+
+#ifdef CONFIG_PPC64
+ if (!proc_symlink("rtas", NULL, "ppc64/rtas"))
+ return -1;
+#endif
+
+ return 0;
+}
+
static int __init proc_rtas_init(void)
{
struct proc_dir_entry *entry;
- if (!machine_is(pseries))
- return -ENODEV;
-
rtas_node = of_find_node_by_name(NULL, "rtas");
if (rtas_node == NULL)
return -ENODEV;
- entry = create_proc_entry("ppc64/rtas/progress", S_IRUGO|S_IWUSR, NULL);
+ if (proc_rtas_create() != 0)
+ return -ENODEV;
+
+ entry = create_proc_entry("/rtas/progress", S_IRUGO|S_IWUSR, NULL);
if (entry)
entry->proc_fops = &ppc_rtas_progress_operations;
- entry = create_proc_entry("ppc64/rtas/clock", S_IRUGO|S_IWUSR, NULL);
+ entry = create_proc_entry("/rtas/clock", S_IRUGO|S_IWUSR, NULL);
if (entry)
entry->proc_fops = &ppc_rtas_clock_operations;
- entry = create_proc_entry("ppc64/rtas/poweron", S_IWUSR|S_IRUGO, NULL);
+ entry = create_proc_entry("/rtas/poweron", S_IWUSR|S_IRUGO, NULL);
if (entry)
entry->proc_fops = &ppc_rtas_poweron_operations;
- entry = create_proc_entry("ppc64/rtas/sensors", S_IRUGO, NULL);
+ entry = create_proc_entry("/rtas/sensors", S_IRUGO, NULL);
if (entry)
entry->proc_fops = &ppc_rtas_sensors_operations;
- entry = create_proc_entry("ppc64/rtas/frequency", S_IWUSR|S_IRUGO,
+ entry = create_proc_entry("/rtas/frequency", S_IWUSR|S_IRUGO,
NULL);
if (entry)
entry->proc_fops = &ppc_rtas_tone_freq_operations;
- entry = create_proc_entry("ppc64/rtas/volume", S_IWUSR|S_IRUGO, NULL);
+ entry = create_proc_entry("/rtas/volume", S_IWUSR|S_IRUGO, NULL);
if (entry)
entry->proc_fops = &ppc_rtas_tone_volume_operations;
- entry = create_proc_entry("ppc64/rtas/rmo_buffer", S_IRUSR, NULL);
+ entry = create_proc_entry("/rtas/rmo_buffer", S_IRUSR, NULL);
if (entry)
entry->proc_fops = &ppc_rtas_rmo_buf_ops;
[-- Attachment #3: nd.vcf --]
[-- Type: text/x-vcard, Size: 249 bytes --]
begin:vcard
fn:Nicolas DET ( bplan GmbH )
n:DET;Nicolas
org:bplan GmbH
adr:;;;;;;Germany
email;internet:nd@bplan-gmbh.de
title:Software Entwicklung
tel;work:+49 6171 9187 - 31
x-mozilla-html:FALSE
url:http://www.bplan-gmbh.de
version:2.1
end:vcard
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Nicolas DET @ 2006-10-20 8:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, tnt, sl
In-Reply-To: <77AD49CA-69CB-4ADA-B8F3-3BC3A066BCF9@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]
Kumar Gala wrote:
>
> On Oct 19, 2006, at 7:39 AM, Nicolas DET wrote:
>
>> This 'big' patch adds support for CHRP/MPC52xx based platform. Here,
this is the bPlan's Efika computer
(http://www.bplan-gmbh.de/efika_spec_en.html)
>
> Some high level comments:
> 1. lets stick with the 52xx naming, instead of 5k2
Ok. Will be done
> 2. PIC code needs to be updated for new interrupt model (as well as
remove of pt_regs)
Ok.
> 3. use standard kernel debug macros
Loads of changes in the pipe line ;-)
> 4. look at replacing sram_allocator w/rheap
>
This SRAM allocator is the exact same from the original Linux one. In
fact, it is the original one. Would it be possible to accept this code
as it is and schedule rheap integration later ?
> if you repost the patch broken up into driver and platform bits it
will be easier to provide more detailed comments.
Ok. I'm alraedy working on it since I post the first one :-) . Thank you
very much for your comments. I hope to re submit a much better patch today.
Regads
[-- Attachment #2: nd.vcf --]
[-- Type: text/x-vcard, Size: 249 bytes --]
begin:vcard
fn:Nicolas DET ( bplan GmbH )
n:DET;Nicolas
org:bplan GmbH
adr:;;;;;;Germany
email;internet:nd@bplan-gmbh.de
title:Software Entwicklung
tel;work:+49 6171 9187 - 31
x-mozilla-html:FALSE
url:http://www.bplan-gmbh.de
version:2.1
end:vcard
^ permalink raw reply
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Segher Boessenkool @ 2006-10-20 8:12 UTC (permalink / raw)
To: Sven Luther; +Cc: akpm, linuxppc-dev, Olaf Hering, Sven Luther, tilmann
In-Reply-To: <20061020073745.GC17286@powerlinux.fr>
>> cpuinfo is about the cpu, not the board layout nor the firmware
>> expectations.
>
> What is the machine: field doing there then ? Would it make sense
> to provide a
> machineinfo then ?
Yes. Or better, don't use /proc, get all info from sysfs
(with a nice userland tool to summarize the info, perhaps).
Segher
^ permalink raw reply
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Olaf Hering @ 2006-10-20 7:49 UTC (permalink / raw)
To: Sven Luther; +Cc: akpm, Sven Luther, tilmann, linuxppc-dev
In-Reply-To: <20061020073745.GC17286@powerlinux.fr>
On Fri, Oct 20, Sven Luther wrote:
> On Fri, Oct 20, 2006 at 09:20:37AM +0200, Olaf Hering wrote:
> > On Fri, Oct 20, Sven Luther wrote:
> >
> > > Exact, it is not about poluting, but about rationalizing. The fact is that
> > > these are the two infos that are the most necessary to userland, then why
> > > disseminate the info in thousand different places, instead of making it easily
> > > available in a canonical place in a standard format for everyone ?
> >
> > cpuinfo is about the cpu, not the board layout nor the firmware
> > expectations.
>
> What is the machine: field doing there then ? Would it make sense to provide a
> machineinfo then ?
All historical bullshit. Use the device-tree.
^ permalink raw reply
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Sven Luther @ 2006-10-20 7:37 UTC (permalink / raw)
To: Olaf Hering; +Cc: akpm, Sven Luther, tilmann, linuxppc-dev
In-Reply-To: <20061020072037.GA4355@aepfle.de>
On Fri, Oct 20, 2006 at 09:20:37AM +0200, Olaf Hering wrote:
> On Fri, Oct 20, Sven Luther wrote:
>
> > Exact, it is not about poluting, but about rationalizing. The fact is that
> > these are the two infos that are the most necessary to userland, then why
> > disseminate the info in thousand different places, instead of making it easily
> > available in a canonical place in a standard format for everyone ?
>
> cpuinfo is about the cpu, not the board layout nor the firmware
> expectations.
What is the machine: field doing there then ? Would it make sense to provide a
machineinfo then ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Sven Luther @ 2006-10-20 7:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: akpm, Olaf Hering, Sven Luther, tilmann, linuxppc-dev
In-Reply-To: <1161328372.10524.170.camel@localhost.localdomain>
On Fri, Oct 20, 2006 at 05:12:52PM +1000, Benjamin Herrenschmidt wrote:
>
> > Exact, it is not about poluting, but about rationalizing. The fact is that
> > these are the two infos that are the most necessary to userland, then why
> > disseminate the info in thousand different places, instead of making it easily
> > available in a canonical place in a standard format for everyone ?
>
> Why would that be absolutely necessary to userland ? We've lived very
> well without that so far.
Because i already coded at least 4 times in 4 different places, code which
does the differentiation for userland, and it is only in debian. All other
distributions have this kind of code in their own individual way.
And if there is a new hardware coming out you didn't think about, it is not
enough to add support in the kernel, but you have to change all those userland
tools all over the place, with load of chances to forget something and break
them.
The kernel knows about this, and it would be easy enough to pass that
information clearly to userland. /proc/device-tree is indeed a solution for
this part.
> > > About 32bit/64bit, maybe VmallocTotal from /proc/meminfo can be used.
> > > incredible large numer == must be a 64bit kernel
> > > No idea how reliable it is. There are those 36bit systems, but I bet
> > > they dont run a distro.
> >
> > This sounds like the ugliest hack i have seen around, and is prone to break. A
> > proper /proc/cpuinfo flag would be most welcome to solve this cleanly.
>
> uname is your friend... damn, and if you want to be real sure, then just
> try to run a 64 bits binary and see what happens :)
Why not say it directly in a standard way ? So we avoid all distros and/or
different tools who need to know, to implement their own slightly different
way ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Benjamin Herrenschmidt @ 2006-10-20 7:36 UTC (permalink / raw)
To: Olaf Hering; +Cc: akpm, Sven Luther, tilmann, linuxppc-dev
In-Reply-To: <20061020071408.GA4325@aepfle.de>
On Fri, 2006-10-20 at 09:14 +0200, Olaf Hering wrote:
> On Fri, Oct 20, Benjamin Herrenschmidt wrote:
>
> > > /proc/device-tree/{model,device_type,compatible} is enough to map
> > > everything reliable in the installer. Dont pollute /proc/cpuinfo
> > > further. There has already enough stuff that doesnt belong there, like
> > > pmac-generation, 'pmac flags', 'detected as', motherboard and machine.
> > > Oh, and bogomips...
> >
> > Some powermac detection bits for older models are not actually available
> > via the device-tree :)
>
> What is missing?
Well, PowerBook 2400 vs. 3400 typically. There is more that we don't
even implement in the kernel yet but maybe one day ... :)
Ben.
^ permalink raw reply
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Olaf Hering @ 2006-10-20 7:20 UTC (permalink / raw)
To: Sven Luther; +Cc: akpm, Sven Luther, tilmann, linuxppc-dev
In-Reply-To: <20061020065849.GA17286@powerlinux.fr>
On Fri, Oct 20, Sven Luther wrote:
> Exact, it is not about poluting, but about rationalizing. The fact is that
> these are the two infos that are the most necessary to userland, then why
> disseminate the info in thousand different places, instead of making it easily
> available in a canonical place in a standard format for everyone ?
cpuinfo is about the cpu, not the board layout nor the firmware
expectations.
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Paul Mackerras @ 2006-10-20 7:18 UTC (permalink / raw)
To: Christoph Lameter; +Cc: akpm, linuxppc-dev, Anton Blanchard, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0610191527040.10880@schroedinger.engr.sgi.com>
Christoph Lameter writes:
> The page allocator must be running and able to serve pages from the boot
> node. This fails for some reason and the slab cannot bootstrap. The memory
> not available is the first guess. Could you trace the allocation in the
> page allocator (__alloc_pages) when the slab attempts to bootstrap and
> figure out why exactly the allocation fails?
What is happening is that all pages are getting their zone id field in
their page->flags set to point to zone for node 1 by memmap_init_zone
calling set_page_links (which does set_page_zone). Thus, when those
pages get freed by free_all_bootmem_node, they all end up in the zone
for node 1.
memmap_init_zone is called (as memmap_init, since we don't have
__HAVE_ARCH_MEMMAP_INIT defined) from init_currently_empty_zone, which
is called from free_area_init_core. Now the thing is that memmap_init
and init_currently_empty_zone are called with the node's start PFN and
size in pages, *including* holes. On the partition I'm using we have
these PFN ranges for the nodes:
1: 0 -> 32768
0: 32768 -> 278528
1: 278528 -> 524288
So node 0's start PFN is 32768 and its size is 245760 pages, and so we
correctly set pages 32786 to 278527 to be in the zone for node 0.
Then for node 1, we have the start PFN is 0 and the size is 524288, so
we then go through and set *all* pages of memory to be in the zone for
node 1, including the pages which are actually on node 0.
That's why we can't allocate any pages on node 0, and the kmem cache
bootstrapping blows up.
I don't know this code well enough to know what the correct fix is.
Clearly memmap_init_zone should only be touching the pages that are
actually present in the zone, but I don't know exactly what data
structures it should be using to know what those pages are.
Paul.
^ permalink raw reply
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Olaf Hering @ 2006-10-20 7:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: akpm, Sven Luther, tilmann, linuxppc-dev
In-Reply-To: <1161328314.10524.168.camel@localhost.localdomain>
On Fri, Oct 20, Benjamin Herrenschmidt wrote:
> > /proc/device-tree/{model,device_type,compatible} is enough to map
> > everything reliable in the installer. Dont pollute /proc/cpuinfo
> > further. There has already enough stuff that doesnt belong there, like
> > pmac-generation, 'pmac flags', 'detected as', motherboard and machine.
> > Oh, and bogomips...
>
> Some powermac detection bits for older models are not actually available
> via the device-tree :)
What is missing?
^ permalink raw reply
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Benjamin Herrenschmidt @ 2006-10-20 7:12 UTC (permalink / raw)
To: Sven Luther; +Cc: akpm, Olaf Hering, Sven Luther, tilmann, linuxppc-dev
In-Reply-To: <20061020065849.GA17286@powerlinux.fr>
> Exact, it is not about poluting, but about rationalizing. The fact is that
> these are the two infos that are the most necessary to userland, then why
> disseminate the info in thousand different places, instead of making it easily
> available in a canonical place in a standard format for everyone ?
Why would that be absolutely necessary to userland ? We've lived very
well without that so far.
> > About 32bit/64bit, maybe VmallocTotal from /proc/meminfo can be used.
> > incredible large numer == must be a 64bit kernel
> > No idea how reliable it is. There are those 36bit systems, but I bet
> > they dont run a distro.
>
> This sounds like the ugliest hack i have seen around, and is prone to break. A
> proper /proc/cpuinfo flag would be most welcome to solve this cleanly.
uname is your friend... damn, and if you want to be real sure, then just
try to run a 64 bits binary and see what happens :)
Ben.
^ permalink raw reply
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Benjamin Herrenschmidt @ 2006-10-20 7:11 UTC (permalink / raw)
To: Olaf Hering; +Cc: akpm, Sven Luther, tilmann, linuxppc-dev
In-Reply-To: <20061020064456.GA3946@aepfle.de>
On Fri, 2006-10-20 at 08:44 +0200, Olaf Hering wrote:
> On Fri, Oct 20, Sven Luther wrote:
>
> > Ben, would it make sense to add two informations to /proc/cpuinfo ?
> > It would be great to have a field there which will allow to check for the
> > kernel flavour to run, namely if the kernel/processor/whatever is running in
> > 32bit or 64bit mode. The second field would be a generalized machine field,
> > or plateform or whatever, which would easily allow to differentiate between an
> > apple machine, a ibm chrp, a pegasos or other genesi product, etc. Without
> > necessarily having to maintain a huge amount of userlanf mappings from all
> > those different machine: fields, which all have CHRP, true, but no finer
> > grained informations, while we do have it in the kernel.
>
> /proc/device-tree/{model,device_type,compatible} is enough to map
> everything reliable in the installer. Dont pollute /proc/cpuinfo
> further. There has already enough stuff that doesnt belong there, like
> pmac-generation, 'pmac flags', 'detected as', motherboard and machine.
> Oh, and bogomips...
Some powermac detection bits for older models are not actually available
via the device-tree :)
> About 32bit/64bit, maybe VmallocTotal from /proc/meminfo can be used.
> incredible large numer == must be a 64bit kernel
> No idea how reliable it is. There are those 36bit systems, but I bet
> they dont run a distro.
But why are you absolutely trying to defeat uname ?
If somebody is trying to fake it, then use the faked version !
Ben.
^ permalink raw reply
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Sven Luther @ 2006-10-20 6:58 UTC (permalink / raw)
To: Olaf Hering; +Cc: akpm, Sven Luther, tilmann, linuxppc-dev
In-Reply-To: <20061020064456.GA3946@aepfle.de>
On Fri, Oct 20, 2006 at 08:44:56AM +0200, Olaf Hering wrote:
> On Fri, Oct 20, Sven Luther wrote:
>
> > Ben, would it make sense to add two informations to /proc/cpuinfo ?
> > It would be great to have a field there which will allow to check for the
> > kernel flavour to run, namely if the kernel/processor/whatever is running in
> > 32bit or 64bit mode. The second field would be a generalized machine field,
> > or plateform or whatever, which would easily allow to differentiate between an
> > apple machine, a ibm chrp, a pegasos or other genesi product, etc. Without
> > necessarily having to maintain a huge amount of userlanf mappings from all
> > those different machine: fields, which all have CHRP, true, but no finer
> > grained informations, while we do have it in the kernel.
>
> /proc/device-tree/{model,device_type,compatible} is enough to map
Yeah, well.
> everything reliable in the installer. Dont pollute /proc/cpuinfo
> further. There has already enough stuff that doesnt belong there, like
> pmac-generation, 'pmac flags', 'detected as', motherboard and machine.
> Oh, and bogomips...
Exact, it is not about poluting, but about rationalizing. The fact is that
these are the two infos that are the most necessary to userland, then why
disseminate the info in thousand different places, instead of making it easily
available in a canonical place in a standard format for everyone ?
> About 32bit/64bit, maybe VmallocTotal from /proc/meminfo can be used.
> incredible large numer == must be a 64bit kernel
> No idea how reliable it is. There are those 36bit systems, but I bet
> they dont run a distro.
This sounds like the ugliest hack i have seen around, and is prone to break. A
proper /proc/cpuinfo flag would be most welcome to solve this cleanly.
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Olaf Hering @ 2006-10-20 6:44 UTC (permalink / raw)
To: Sven Luther; +Cc: akpm, Sven Luther, tilmann, linuxppc-dev
In-Reply-To: <20061020062431.GB14390@powerlinux.fr>
On Fri, Oct 20, Sven Luther wrote:
> Ben, would it make sense to add two informations to /proc/cpuinfo ?
> It would be great to have a field there which will allow to check for the
> kernel flavour to run, namely if the kernel/processor/whatever is running in
> 32bit or 64bit mode. The second field would be a generalized machine field,
> or plateform or whatever, which would easily allow to differentiate between an
> apple machine, a ibm chrp, a pegasos or other genesi product, etc. Without
> necessarily having to maintain a huge amount of userlanf mappings from all
> those different machine: fields, which all have CHRP, true, but no finer
> grained informations, while we do have it in the kernel.
/proc/device-tree/{model,device_type,compatible} is enough to map
everything reliable in the installer. Dont pollute /proc/cpuinfo
further. There has already enough stuff that doesnt belong there, like
pmac-generation, 'pmac flags', 'detected as', motherboard and machine.
Oh, and bogomips...
About 32bit/64bit, maybe VmallocTotal from /proc/meminfo can be used.
incredible large numer == must be a 64bit kernel
No idea how reliable it is. There are those 36bit systems, but I bet
they dont run a distro.
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Sven Luther @ 2006-10-20 6:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, sl, tnt
In-Reply-To: <77AD49CA-69CB-4ADA-B8F3-3BC3A066BCF9@kernel.crashing.org>
On Fri, Oct 20, 2006 at 01:06:14AM -0500, Kumar Gala wrote:
>
> On Oct 19, 2006, at 7:39 AM, Nicolas DET wrote:
>
> >This 'big' patch adds support for CHRP/MPC52xx based platform.
> >Here, this is the bPlan's Efika computer (http://www.bplan-gmbh.de/
> >efika_spec_en.html)
> >
> >We know this patch is not totaly compliant with Documentation/
> >CodingStyle/.
> >
> >We would like people to comment and review it. This way we would
> >provide a new patch with the changes required (if any) for an
> >upcomming merge in the kernel.
> >
> >This patch has been applied on the kernel 2.6.18.1.
> >
> >Signed-off-by: Nicolas DET <nd@bplan-gmbh.de>
> >Signed-off-by: Sven Luther <sl@bplan-gmbh.de>
>
> I think it would be extremely useful to get a dump of what the device-
> tree looks like. We have to be very careful to device nodes for 52xx
> components are competed consistent between this 'CHRP' style and a
> more embedded 52xx boards.
Well, the efika is a CHRP board, and thus more akin to the pegasos or IBM
boxes than the embedded 52xx boards with regard to the device trees. Nico will
provide you an lsprop output.
> Some high level comments:
> 2. PIC code needs to be updated for new interrupt model (as well as
> remove of pt_regs)
Notice that the efika does not have the interrupt tree bindings in the
firmware. I implemented those on pegasos last month, but linux refused to
boot, and i am currently waiting for comments from benh on the lsprop output.
Friendly,
Sven Luther
^ 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