* [EFIKA] Really, don't pretend to be CHRP
@ 2008-04-13 16:52 David Woodhouse
2008-04-14 2:54 ` Grant Likely
2008-04-17 12:28 ` Matt Sealey
0 siblings, 2 replies; 11+ messages in thread
From: David Woodhouse @ 2008-04-13 16:52 UTC (permalink / raw
To: paulus; +Cc: linuxppc-dev
Fedora 9 works on Efika without the separate 'device-tree supplement',
thanks to the kernel's own fixups. With one exception -- because 'CHRP'
still appears on the 'machine:' line in /proc/cpuinfo, the installer
misdetects the platform and misconfigures yaboot, putting it into a PReP
boot partition instead of in the /boot filesystem where the Efika's
firmware could find it.
The kernel's fixups for Efika already correct one instance of 'chrp', in
the 'device_type' property. This fixes it in the 'CODEGEN,description'
property too, since that's what's exposed to userspace in /proc/cpuinfo.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 5ab4c84..723422e 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -2240,6 +2240,14 @@ static void __init fixup_device_tree_efika(void)
if (rv != PROM_ERROR && (strcmp(prop, "chrp") == 0))
prom_setprop(node, "/", "device_type", "efika", sizeof("efika"));
+ /* CODEGEN,description is exposed in /proc/cpuinfo so
+ fix that too */
+ rv = prom_getprop(node, "CODEGEN,description", prop, sizeof(prop));
+ if (rv != PROM_ERROR && (strstr(prop, "CHRP")))
+ prom_setprop(node, "/", "CODEGEN,description",
+ "Efika 5200B PowerPC System",
+ sizeof("Efika 5200B PowerPC System"));
+
/* Fixup bestcomm interrupts property */
node = call_prom("finddevice", 1, 1, ADDR("/builtin/bestcomm"));
if (PHANDLE_VALID(node)) {
--
dwmw2
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [EFIKA] Really, don't pretend to be CHRP
2008-04-13 16:52 [EFIKA] Really, don't pretend to be CHRP David Woodhouse
@ 2008-04-14 2:54 ` Grant Likely
2008-04-17 12:28 ` Matt Sealey
1 sibling, 0 replies; 11+ messages in thread
From: Grant Likely @ 2008-04-14 2:54 UTC (permalink / raw
To: David Woodhouse; +Cc: linuxppc-dev, paulus
On Sun, Apr 13, 2008 at 10:52 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> Fedora 9 works on Efika without the separate 'device-tree supplement',
> thanks to the kernel's own fixups. With one exception -- because 'CHRP'
> still appears on the 'machine:' line in /proc/cpuinfo, the installer
> misdetects the platform and misconfigures yaboot, putting it into a PReP
> boot partition instead of in the /boot filesystem where the Efika's
> firmware could find it.
>
> The kernel's fixups for Efika already correct one instance of 'chrp', in
> the 'device_type' property. This fixes it in the 'CODEGEN,description'
> property too, since that's what's exposed to userspace in /proc/cpuinfo.
>
> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Looks good to me. I don't see any reason not to pick this up.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index 5ab4c84..723422e 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -2240,6 +2240,14 @@ static void __init fixup_device_tree_efika(void)
> if (rv != PROM_ERROR && (strcmp(prop, "chrp") == 0))
> prom_setprop(node, "/", "device_type", "efika", sizeof("efika"));
>
> + /* CODEGEN,description is exposed in /proc/cpuinfo so
> + fix that too */
> + rv = prom_getprop(node, "CODEGEN,description", prop, sizeof(prop));
> + if (rv != PROM_ERROR && (strstr(prop, "CHRP")))
> + prom_setprop(node, "/", "CODEGEN,description",
> + "Efika 5200B PowerPC System",
> + sizeof("Efika 5200B PowerPC System"));
> +
> /* Fixup bestcomm interrupts property */
> node = call_prom("finddevice", 1, 1, ADDR("/builtin/bestcomm"));
> if (PHANDLE_VALID(node)) {
>
>
>
> --
> dwmw2
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [EFIKA] Really, don't pretend to be CHRP
2008-04-13 16:52 [EFIKA] Really, don't pretend to be CHRP David Woodhouse
2008-04-14 2:54 ` Grant Likely
@ 2008-04-17 12:28 ` Matt Sealey
2008-04-17 14:37 ` David Woodhouse
1 sibling, 1 reply; 11+ messages in thread
From: Matt Sealey @ 2008-04-17 12:28 UTC (permalink / raw
To: David Woodhouse; +Cc: linuxppc-dev, paulus
I thought we were using efika.forth for this in Fedora.
Why don't we just roll all those fixes into prom_efika.c or something
and make it a huge, unwieldy file nice and *seperate* from prom_init.c?
:)
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
David Woodhouse wrote:
> Fedora 9 works on Efika without the separate 'device-tree supplement',
> thanks to the kernel's own fixups. With one exception -- because 'CHRP'
> still appears on the 'machine:' line in /proc/cpuinfo, the installer
> misdetects the platform and misconfigures yaboot, putting it into a PReP
> boot partition instead of in the /boot filesystem where the Efika's
> firmware could find it.
>
> The kernel's fixups for Efika already correct one instance of 'chrp', in
> the 'device_type' property. This fixes it in the 'CODEGEN,description'
> property too, since that's what's exposed to userspace in /proc/cpuinfo.
>
> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index 5ab4c84..723422e 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -2240,6 +2240,14 @@ static void __init fixup_device_tree_efika(void)
> if (rv != PROM_ERROR && (strcmp(prop, "chrp") == 0))
> prom_setprop(node, "/", "device_type", "efika", sizeof("efika"));
>
> + /* CODEGEN,description is exposed in /proc/cpuinfo so
> + fix that too */
> + rv = prom_getprop(node, "CODEGEN,description", prop, sizeof(prop));
> + if (rv != PROM_ERROR && (strstr(prop, "CHRP")))
> + prom_setprop(node, "/", "CODEGEN,description",
> + "Efika 5200B PowerPC System",
> + sizeof("Efika 5200B PowerPC System"));
> +
> /* Fixup bestcomm interrupts property */
> node = call_prom("finddevice", 1, 1, ADDR("/builtin/bestcomm"));
> if (PHANDLE_VALID(node)) {
>
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [EFIKA] Really, don't pretend to be CHRP
2008-04-17 12:28 ` Matt Sealey
@ 2008-04-17 14:37 ` David Woodhouse
2008-04-17 15:17 ` Matt Sealey
0 siblings, 1 reply; 11+ messages in thread
From: David Woodhouse @ 2008-04-17 14:37 UTC (permalink / raw
To: Matt Sealey; +Cc: linuxppc-dev, paulus
On Thu, 2008-04-17 at 13:28 +0100, Matt Sealey wrote:
> I thought we were using efika.forth for this in Fedora.
We were, until you pointed out that the kernel actually works just fine
these days without it.
Now, the _only_ thing that goes wrong without it is that 'CHRP' in the
machine: line -- which is fixed by this patch. And so the user's life is
made easier -- all they have to work around now is the fact that we
can't set environment variables from within Linux (and yes, we can
probably improve on that too, but we let them setenv for themselves, for
now).
> Why don't we just roll all those fixes into prom_efika.c or something
> and make it a huge, unwieldy file nice and *seperate* from
> prom_init.c?
That might be a little cleaner than what we have at the moment, yes. But
what we have also works, so I'd rather concentrate on things like
getting audio support merged, before we faff around with what are
essentially cosmetics.
--
dwmw2
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [EFIKA] Really, don't pretend to be CHRP
2008-04-17 14:37 ` David Woodhouse
@ 2008-04-17 15:17 ` Matt Sealey
2008-04-17 16:37 ` David Woodhouse
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Matt Sealey @ 2008-04-17 15:17 UTC (permalink / raw
To: David Woodhouse; +Cc: linuxppc-dev, paulus
David Woodhouse wrote:
> On Thu, 2008-04-17 at 13:28 +0100, Matt Sealey wrote:
>> I thought we were using efika.forth for this in Fedora.
>
> We were, until you pointed out that the kernel actually works just fine
> these days without it.
I said the kernel has had braindead patches shoved into it that sort of
obviate the need for the most heinous of crimes committed in the Efika
device tree.
The Linux kernel fixups don't add the CDM or XLB arbiter or many other
components some out-of-mainline drivers will need (and should be able
to just access without writing a fixup first) to map to work properly.
Adding these will clean up things like the UART module, Sylvain's sleep
patches will work on Efika, etc.
> can't set environment variables from within Linux (and yes, we can
> probably improve on that too, but we let them setenv for themselves, for
> now).
You really won't be improving on it because there's no reliable way to
pass setenv back to the firmware from userland :D
> That might be a little cleaner than what we have at the moment, yes. But
> what we have also works, so I'd rather concentrate on things like
> getting audio support merged, before we faff around with what are
> essentially cosmetics.
My ideal situation is all this stuff is stripped from the kernel. You do
realise 90% of the Efika traffic on this list is submitting code that
fixes fixups for a firmware which has a seperated fixup script, putting
the responsibility firmly where Linux-PPC policy dictated it should be
(with the firmware).
I think it's stunting the development of the platform. In lieu of a
real, solid, flashable firmware update that fixes the problems, I don't
think patching the Linux kernel is the correct solution, and I do not
appreciate the 180 degree turn that Linux-PPC policy has taken with this.
If we could not commit fixes for it in the beginning and were lambasted
for shoving firmware bugfixes into the kernel, how should it be so
different now?
You do realise that once the fixes are in the kernel *you may never see
another firmware update*? There'll be no point..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [EFIKA] Really, don't pretend to be CHRP
2008-04-17 15:17 ` Matt Sealey
@ 2008-04-17 16:37 ` David Woodhouse
2008-04-18 15:33 ` Matt Sealey
2008-04-19 0:53 ` Benjamin Herrenschmidt
2008-04-18 0:17 ` David Gibson
2008-04-18 8:24 ` Benjamin Herrenschmidt
2 siblings, 2 replies; 11+ messages in thread
From: David Woodhouse @ 2008-04-17 16:37 UTC (permalink / raw
To: Matt Sealey; +Cc: linuxppc-dev, paulus
On Thu, 2008-04-17 at 16:17 +0100, Matt Sealey wrote:
> David Woodhouse wrote:
> > On Thu, 2008-04-17 at 13:28 +0100, Matt Sealey wrote:
> >> I thought we were using efika.forth for this in Fedora.
> >
> > We were, until you pointed out that the kernel actually works just fine
> > these days without it.
>
> I said the kernel has had braindead patches shoved into it that sort of
> obviate the need for the most heinous of crimes committed in the Efika
> device tree.
:)
> The Linux kernel fixups don't add the CDM or XLB arbiter or many other
> components some out-of-mainline drivers
I don't give a monkey's left testicle about code which isn't mainline.
If and when it's merged, we can make sure the device-tree fixups are
sufficient for it -- by whatever means.
> > can't set environment variables from within Linux (and yes, we can
> > probably improve on that too, but we let them setenv for themselves, for
> > now).
>
> You really won't be improving on it because there's no reliable way to
> pass setenv back to the firmware from userland :D
Except by putting it in a text file which is booted instead of yaboot,
the first time after install. The user just types 'boot hd:,\fixme.fth'
instead of having to set the variables manually.
> My ideal situation is all this stuff is stripped from the kernel. You do
> realise 90% of the Efika traffic on this list is submitting code that
> fixes fixups for a firmware which has a seperated fixup script, putting
> the responsibility firmly where Linux-PPC policy dictated it should be
> (with the firmware).
The fixup script is a fairly unwieldy hack for a distribution to try to
support. It turns our release/install notes for Efika from a few lines
of "Efika firmware is a bit crap" into twice as many lines of "Efika
firmware is entirely crap".
> I think it's stunting the development of the platform. In lieu of a
> real, solid, flashable firmware update that fixes the problems,
Bored now. Quit whining and give us a real, solid, flashable firmware
update that fixes the problems. Really.
> I don't think patching the Linux kernel is the correct solution, and I
> do not appreciate the 180 degree turn that Linux-PPC policy has taken
> with this.
> If we could not commit fixes for it in the beginning and were lambasted
> for shoving firmware bugfixes into the kernel, how should it be so
> different now?
Haven't we covered this? We were originally promised a firmware update
which would fix all this, about a year ago. It was quite reasonable at
the time to wait for it and avoid putting the hacks in the kernel.
Now we've come to the conclusion that it isn't going to happen, it's
also quite reasonable to change tack and work around it.
If there was a chance of policy, it was because we were promised
something which didn't appear.
> You do realise that once the fixes are in the kernel *you may never
> see another firmware update*? There'll be no point..
Except to fix the off-by-one problems and various other breakages other
than the device-tree, perhaps. But I thought we'd already reached the
conclusion that we may never see another firmware update?
OTOH, it probably wouldn't be _so_ hard to port Mitch's OpenFirmware to
mpc5200...
--
dwmw2
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [EFIKA] Really, don't pretend to be CHRP
2008-04-17 15:17 ` Matt Sealey
2008-04-17 16:37 ` David Woodhouse
@ 2008-04-18 0:17 ` David Gibson
2008-04-18 8:24 ` Benjamin Herrenschmidt
2 siblings, 0 replies; 11+ messages in thread
From: David Gibson @ 2008-04-18 0:17 UTC (permalink / raw
To: Matt Sealey; +Cc: linuxppc-dev, David Woodhouse, paulus
On Thu, Apr 17, 2008 at 04:17:20PM +0100, Matt Sealey wrote:
>
> David Woodhouse wrote:
>> On Thu, 2008-04-17 at 13:28 +0100, Matt Sealey wrote:
>>> I thought we were using efika.forth for this in Fedora.
>>
>> We were, until you pointed out that the kernel actually works just fine
>> these days without it.
>
> I said the kernel has had braindead patches shoved into it that sort of
> obviate the need for the most heinous of crimes committed in the Efika
> device tree.
>
> The Linux kernel fixups don't add the CDM or XLB arbiter or many other
> components some out-of-mainline drivers will need (and should be able
> to just access without writing a fixup first) to map to work properly.
> Adding these will clean up things like the UART module, Sylvain's sleep
> patches will work on Efika, etc.
>
>> can't set environment variables from within Linux (and yes, we can
>> probably improve on that too, but we let them setenv for themselves, for
>> now).
>
> You really won't be improving on it because there's no reliable way to
> pass setenv back to the firmware from userland :D
>
>> That might be a little cleaner than what we have at the moment, yes. But
>> what we have also works, so I'd rather concentrate on things like
>> getting audio support merged, before we faff around with what are
>> essentially cosmetics.
>
> My ideal situation is all this stuff is stripped from the kernel. You do
> realise 90% of the Efika traffic on this list is submitting code that
> fixes fixups for a firmware which has a seperated fixup script, putting
> the responsibility firmly where Linux-PPC policy dictated it should be
> (with the firmware).
That's not Linux-PPC policy as far as I'm concerned. It's nice if
firmware provides a more-or-less accurate device tree, but we're not
naive enough to think that's actually going to happen. Firmware
always is, and always will be, crap, so it's expected that the kernel
will have to workaround device tree inaccuracies in the firmware.
Sometimes the simplest way of doing that is just to have workarounds
in the drivers. Other times, doing that would be ugly and invasive,
so instead the bootwrapper should fixup the device tree before passing
it on to the kernel - this is one of the purposes of the bootwrapper.
--
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 [flat|nested] 11+ messages in thread
* Re: [EFIKA] Really, don't pretend to be CHRP
2008-04-17 15:17 ` Matt Sealey
2008-04-17 16:37 ` David Woodhouse
2008-04-18 0:17 ` David Gibson
@ 2008-04-18 8:24 ` Benjamin Herrenschmidt
2008-04-18 15:21 ` Matt Sealey
2 siblings, 1 reply; 11+ messages in thread
From: Benjamin Herrenschmidt @ 2008-04-18 8:24 UTC (permalink / raw
To: Matt Sealey; +Cc: linuxppc-dev, David Woodhouse, paulus
On Thu, 2008-04-17 at 16:17 +0100, Matt Sealey wrote:
>
> I said the kernel has had braindead patches shoved into it that sort
> of
> obviate the need for the most heinous of crimes committed in the Efika
> device tree.
>
> The Linux kernel fixups don't add the CDM or XLB arbiter or many other
> components some out-of-mainline drivers will need (and should be able
> to just access without writing a fixup first) to map to work properly.
> Adding these will clean up things like the UART module, Sylvain's
> sleep
> patches will work on Efika, etc.
What about you guys fix the firmware once for all instead of spamming
our mailboxes ?
> > can't set environment variables from within Linux (and yes, we can
> > probably improve on that too, but we let them setenv for themselves,
> for
> > now).
>
> You really won't be improving on it because there's no reliable way to
> pass setenv back to the firmware from userland :D
They aren't in nvram ? If they are and using the standard OF CHRP
format, then we can.
Ben.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [EFIKA] Really, don't pretend to be CHRP
2008-04-18 8:24 ` Benjamin Herrenschmidt
@ 2008-04-18 15:21 ` Matt Sealey
0 siblings, 0 replies; 11+ messages in thread
From: Matt Sealey @ 2008-04-18 15:21 UTC (permalink / raw
To: benh; +Cc: linuxppc-dev, David Woodhouse, paulus
Benjamin Herrenschmidt wrote:
>>> can't set environment variables from within Linux (and yes, we can
>>> probably improve on that too, but we let them setenv for themselves,
>> for
>>> now).
>> You really won't be improving on it because there's no reliable way to
>> pass setenv back to the firmware from userland :D
>
> They aren't in nvram ? If they are and using the standard OF CHRP
> format, then we can.
They aren't (especially on Pegasos) and they aren't, so you can't.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [EFIKA] Really, don't pretend to be CHRP
2008-04-17 16:37 ` David Woodhouse
@ 2008-04-18 15:33 ` Matt Sealey
2008-04-19 0:53 ` Benjamin Herrenschmidt
1 sibling, 0 replies; 11+ messages in thread
From: Matt Sealey @ 2008-04-18 15:33 UTC (permalink / raw
To: David Woodhouse; +Cc: linuxppc-dev, paulus
David Woodhouse wrote:
> OTOH, it probably wouldn't be _so_ hard to port Mitch's OpenFirmware to
> mpc5200...
Go for it.
I also give you permission to detail how our firmware is a bit crap in
the Fedora release notes. You will have to do that anyway to evangelize
the weird setenv hack you just proposed, so it will kill two birds with
one stone.
Also regarding your original patch; why not just fix the cpuinfo printout
so that it doesn't print the machine/vendor properties from firmware.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/powerpc/platforms/52xx/efika.c;h=a2068faef6ea9c7b5b4fb2db804a32f33e1598b1;hb=HEAD#l155
It's right there. I'd rather they were taken out than putting MORE
property changes into fixups.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [EFIKA] Really, don't pretend to be CHRP
2008-04-17 16:37 ` David Woodhouse
2008-04-18 15:33 ` Matt Sealey
@ 2008-04-19 0:53 ` Benjamin Herrenschmidt
1 sibling, 0 replies; 11+ messages in thread
From: Benjamin Herrenschmidt @ 2008-04-19 0:53 UTC (permalink / raw
To: David Woodhouse; +Cc: paulus, linuxppc-dev
> OTOH, it probably wouldn't be _so_ hard to port Mitch's OpenFirmware to
> mpc5200...
Yup, especially since it's pretty much just a 603 core which I would
expect is already supported by firmworks stuff...
Ben.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2008-04-19 0:53 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-13 16:52 [EFIKA] Really, don't pretend to be CHRP David Woodhouse
2008-04-14 2:54 ` Grant Likely
2008-04-17 12:28 ` Matt Sealey
2008-04-17 14:37 ` David Woodhouse
2008-04-17 15:17 ` Matt Sealey
2008-04-17 16:37 ` David Woodhouse
2008-04-18 15:33 ` Matt Sealey
2008-04-19 0:53 ` Benjamin Herrenschmidt
2008-04-18 0:17 ` David Gibson
2008-04-18 8:24 ` Benjamin Herrenschmidt
2008-04-18 15:21 ` Matt Sealey
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.