[EFIKA] Really, don't pretend to be CHRP

[EFIKA] Really, don't pretend to be CHRP

[David Woodhouse]

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

Re: [EFIKA] Really, don't pretend to be CHRP

[Grant Likely]

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.

Re: [EFIKA] Really, don't pretend to be CHRP

[Matt Sealey]

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)) {
> 
> 
> 

Re: [EFIKA] Really, don't pretend to be CHRP

[David Woodhouse]

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

Re: [EFIKA] Really, don't pretend to be CHRP

[Matt Sealey]

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

Re: [EFIKA] Really, don't pretend to be CHRP

[David Woodhouse]

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

Re: [EFIKA] Really, don't pretend to be CHRP

[Matt Sealey]

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

Re: [EFIKA] Really, don't pretend to be CHRP

[Benjamin Herrenschmidt]

> 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.

Re: [EFIKA] Really, don't pretend to be CHRP

[David Gibson]

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

Re: [EFIKA] Really, don't pretend to be CHRP

[Benjamin Herrenschmidt]

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.

Re: [EFIKA] Really, don't pretend to be CHRP

[Matt Sealey]

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