add phy-handle property for fec_mpc52xx

add phy-handle property for fec_mpc52xx

[Olaf Hering]

The new network driver fec_mpc52xx will not work on efika because the
firmware does not provide all required properties.
http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to
create more properties. But only the phy stuff is required to get a
working network.

This should go into the kernel because its appearently
impossible to boot the script via tftp and then load the real boot
binary (yaboot or zimage).

---
 arch/powerpc/kernel/prom_init.c |   28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1487,6 +1487,34 @@ static void __init prom_find_mmu(void)
 	else if (strncmp(version, "FirmWorks,3.", 12) == 0) {
 		of_workarounds = OF_WA_CLAIM | OF_WA_LONGTRAIL;
 		call_prom("interpret", 1, 1, "dev /memory 0 to allow-reclaim");
+#ifdef CONFIG_PPC_MPC52xx
+	} else if (strcmp(version, "EFIKA5K2") == 0) {
+		call_prom("interpret", 1, 1,
+			" .\" Adding EFIKA5K2 Ethernet PHY\" cr"
+			" s\" /builtin\" find-device"
+			" new-device"
+				" 1 encode-int s\" #address-cells\" property"
+				" 0 encode-int s\" #size-cells\" property"
+				" s\" mdio\" 2dup device-name device-type"
+				" s\" mpc5200b-fec-phy\" encode-string s\" compatible\" property"
+				" 0xf0003000 0x400 reg"
+				" 0x2 encode-int"
+				" 0x5 encode-int encode+"
+				" 0x3 encode-int encode+"
+				" s\" interrupts\" property"
+				" new-device"
+					" s\" ethernet-phy\" 2dup device-name device-type"
+					" 0x10 encode-int s\" reg\" property"
+					" my-self"
+					" ihandle>phandle"
+				" finish-device"
+			" finish-device"
+			" s\" /builtin/ethernet\" find-device"
+				" encode-int"
+				" s\" phy-handle\" property"
+			" device-end"
+			);
+#endif
 	} else
 		return;
 	_prom->memory = call_prom("open", 1, 1, ADDR("/memory"));

Re: add phy-handle property for fec_mpc52xx

[Grant Likely]

Woo!  Thanks Olaf.  I was just about to sit down and write something
like this myself.  Looks good to me.  I'll pick this up (but I'm going
to move it to the fixup_device_tree_efika() function)

Cheers,
g.


On 1/9/08, Olaf Hering <olaf@aepfle.de> wrote:
>
> The new network driver fec_mpc52xx will not work on efika because the
> firmware does not provide all required properties.
> http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to
> create more properties. But only the phy stuff is required to get a
> working network.
>
> This should go into the kernel because its appearently
> impossible to boot the script via tftp and then load the real boot
> binary (yaboot or zimage).
>
> ---
>  arch/powerpc/kernel/prom_init.c |   28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
>
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -1487,6 +1487,34 @@ static void __init prom_find_mmu(void)
>         else if (strncmp(version, "FirmWorks,3.", 12) == 0) {
>                 of_workarounds = OF_WA_CLAIM | OF_WA_LONGTRAIL;
>                 call_prom("interpret", 1, 1, "dev /memory 0 to allow-reclaim");
> +#ifdef CONFIG_PPC_MPC52xx
> +       } else if (strcmp(version, "EFIKA5K2") == 0) {
> +               call_prom("interpret", 1, 1,
> +                       " .\" Adding EFIKA5K2 Ethernet PHY\" cr"
> +                       " s\" /builtin\" find-device"
> +                       " new-device"
> +                               " 1 encode-int s\" #address-cells\" property"
> +                               " 0 encode-int s\" #size-cells\" property"
> +                               " s\" mdio\" 2dup device-name device-type"
> +                               " s\" mpc5200b-fec-phy\" encode-string s\" compatible\" property"
> +                               " 0xf0003000 0x400 reg"
> +                               " 0x2 encode-int"
> +                               " 0x5 encode-int encode+"
> +                               " 0x3 encode-int encode+"
> +                               " s\" interrupts\" property"
> +                               " new-device"
> +                                       " s\" ethernet-phy\" 2dup device-name device-type"
> +                                       " 0x10 encode-int s\" reg\" property"
> +                                       " my-self"
> +                                       " ihandle>phandle"
> +                               " finish-device"
> +                       " finish-device"
> +                       " s\" /builtin/ethernet\" find-device"
> +                               " encode-int"
> +                               " s\" phy-handle\" property"
> +                       " device-end"
> +                       );
> +#endif
>         } else
>                 return;
>         _prom->memory = call_prom("open", 1, 1, ADDR("/memory"));
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: add phy-handle property for fec_mpc52xx

[Sven Luther]

On Wed, Jan 09, 2008 at 07:44:58AM -0700, Grant Likely wrote:
> Woo!  Thanks Olaf.  I was just about to sit down and write something
> like this myself.  Looks good to me.  I'll pick this up (but I'm going
> to move it to the fixup_device_tree_efika() function)

Indeed, thanks, this makes the efika kernel again work out of the box.
Would it be possible to merge this upstream asap ? 

Friendly,

Sven Luther

Re: add phy-handle property for fec_mpc52xx

[Grant Likely]

On 1/9/08, Sven Luther <sven@powerlinux.fr> wrote:
> On Wed, Jan 09, 2008 at 07:44:58AM -0700, Grant Likely wrote:
> > Woo!  Thanks Olaf.  I was just about to sit down and write something
> > like this myself.  Looks good to me.  I'll pick this up (but I'm going
> > to move it to the fixup_device_tree_efika() function)
>
> Indeed, thanks, this makes the efika kernel again work out of the box.
> Would it be possible to merge this upstream asap ?

I'll see if paulus will pick it up for 2.6.24

g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: add phy-handle property for fec_mpc52xx

[Sven Luther]

On Wed, Jan 09, 2008 at 07:50:14AM -0700, Grant Likely wrote:
> On 1/9/08, Sven Luther <sven@powerlinux.fr> wrote:
> > On Wed, Jan 09, 2008 at 07:44:58AM -0700, Grant Likely wrote:
> > > Woo!  Thanks Olaf.  I was just about to sit down and write something
> > > like this myself.  Looks good to me.  I'll pick this up (but I'm going
> > > to move it to the fixup_device_tree_efika() function)
> >
> > Indeed, thanks, this makes the efika kernel again work out of the box.
> > Would it be possible to merge this upstream asap ?
> 
> I'll see if paulus will pick it up for 2.6.24

Cool, this would mean the only thing missing the patchset i have been
carrying is the sound driver. Do you see something else that has been
added since then ? 

Friendly,

Sven Luther

Re: add phy-handle property for fec_mpc52xx

[Matt Sealey]

I'd also say that the sound driver isn't ready for production use and it
misuses the BestComm task for generic bidirectional buffer copies by
forcing it to 32-bit transfers (this obviously involves some software
upsampling at some point as nearly all common sound data is 16-bit,
also twice the bandwidth to achieve). The Freescale docs for this task
(and the one provided by the firmware, no doubt, is identical in
operation) clearly state that the transfer size is configurable, so
saying it only accepts 32-bit sample data is simply inefficient and
lazy.

Someone needs to sit down and look at these, after a year of simple
stagnation since Sylvain lost the time to maintain them. I don't think
it is at all a good idea to think "oh it has been in the wild for a
year and nobody maintains it so we will mainline it now". That's a
ridiculous development philosophy. And, since nobody seems to give a
shit, it will stay as bad as it is right now (a quick hack) whether
in the wild or mainlined..

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Sven Luther wrote:
> On Wed, Jan 09, 2008 at 07:50:14AM -0700, Grant Likely wrote:
>> On 1/9/08, Sven Luther <sven@powerlinux.fr> wrote:
>>> On Wed, Jan 09, 2008 at 07:44:58AM -0700, Grant Likely wrote:
>>>> Woo!  Thanks Olaf.  I was just about to sit down and write something
>>>> like this myself.  Looks good to me.  I'll pick this up (but I'm going
>>>> to move it to the fixup_device_tree_efika() function)
>>> Indeed, thanks, this makes the efika kernel again work out of the box.
>>> Would it be possible to merge this upstream asap ?
>> I'll see if paulus will pick it up for 2.6.24
> 
> Cool, this would mean the only thing missing the patchset i have been
> carrying is the sound driver. Do you see something else that has been
> added since then ? 
> 
> Friendly,
> 
> Sven Luther
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: add phy-handle property for fec_mpc52xx

[Matt Sealey]

NO.

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Sven Luther wrote:
> On Wed, Jan 09, 2008 at 07:44:58AM -0700, Grant Likely wrote:
>> Woo!  Thanks Olaf.  I was just about to sit down and write something
>> like this myself.  Looks good to me.  I'll pick this up (but I'm going
>> to move it to the fixup_device_tree_efika() function)
> 
> Indeed, thanks, this makes the efika kernel again work out of the box.
> Would it be possible to merge this upstream asap ? 
> 
> Friendly,
> 
> Sven Luther
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: add phy-handle property for fec_mpc52xx

[Grant Likely]

On 1/9/08, Matt Sealey <matt@genesi-usa.com> wrote:
> NO.

please elaborate

>
> --
> Matt Sealey <matt@genesi-usa.com>
> Genesi, Manager, Developer Relations
>
> Sven Luther wrote:
> > On Wed, Jan 09, 2008 at 07:44:58AM -0700, Grant Likely wrote:
> >> Woo!  Thanks Olaf.  I was just about to sit down and write something
> >> like this myself.  Looks good to me.  I'll pick this up (but I'm going
> >> to move it to the fixup_device_tree_efika() function)
> >
> > Indeed, thanks, this makes the efika kernel again work out of the box.
> > Would it be possible to merge this upstream asap ?
> >
> > Friendly,
> >
> > Sven Luther
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: add phy-handle property for fec_mpc52xx

[Sven Luther]

On Wed, Jan 09, 2008 at 03:21:35PM +0000, Matt Sealey wrote:
> NO.

YES :)

Friendly,

Sven Luther

Re: add phy-handle property for fec_mpc52xx

[Grant Likely]

On 1/9/08, Olaf Hering <olaf@aepfle.de> wrote:
>
> The new network driver fec_mpc52xx will not work on efika because the
> firmware does not provide all required properties.
> http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to
> create more properties. But only the phy stuff is required to get a
> working network.

Question: What will happen with this code if the mdio and phy nodes
have already been created by the forth script?  There is not checking
to see if the phy node already exists.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: add phy-handle property for fec_mpc52xx

[Matt Sealey]

Clarification: I really have to disagree with this patch, and Sven.

The whole point of removing the stuff from the Linux kernel (as the
efika.forth script and the associated patch performs) is that it means
the Linux kernel is no longer a "moving target" for our firmware
development.

If users require these kernels they can run efika.forth - the major
stumbling block being this is quite ugly to do right now. This is our
problem - bplan, Genesi, myself whoever you want to target - it should
not be made into a Linux problem by creating this "moving target" that
needs constant patching to maintain driver coherency.

There is a clever way to load in a forth script to nvramrc on the
Efika through exploitation of an exposed internal firmware structure
(not security critical, just very useful). Unfortunately right now I
am not willing to shoulder the entire burden of writing, testing and
further development of a suite of tools to bridge the gap between the
current firmware which misses certain features, and a new firmware
which may not be released in a timely fashion.

If anyone wants to help/assist/suggest any updates to efika.forth,
create binary tools which assist the installation of the script for
users and for placement on Linux distro CDs etc. I would be very
grateful, but it seems we have hit the Wall of Apathy where users
complain for a feature but are not willing to work for it.

(I am invoking the Open Source Fallacy of that if the source is
available you can patch it, I say that patching Linux is not the
solution, but patching the firmware is. But nobody is willing to
work on patching the firmware and keeping Linux entirely independant
of our so-deemed "crappy" firmware)

Please let's keep the nature of our firmware and the Linux codebase
independant, and move the burden of support to Genesi, and not the
Linux PowerPC team. After all, what is next, after phy-handle do
you want to add i2c, irda, missing xlb/cdm entries in the patch so
that other things work? Does everyone have to custom compile their
own kernel? What happens if we do another firmware release and
the Linux kernel overwrites important values without checking as
it does now? It simply causes problems.

Therefore I heartily do not acknowledge this patch. Olaf, if you
would like to assist in the development of an easy installer for
the device tree supplement for users, please feel free... save
these guys from having to maintain support for a broken device
tree by providing a correct one :D

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Olaf Hering wrote:
> The new network driver fec_mpc52xx will not work on efika because the
> firmware does not provide all required properties.
> http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to
> create more properties. But only the phy stuff is required to get a
> working network.
> 
> This should go into the kernel because its appearently
> impossible to boot the script via tftp and then load the real boot
> binary (yaboot or zimage).
> 
> ---
>  arch/powerpc/kernel/prom_init.c |   28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -1487,6 +1487,34 @@ static void __init prom_find_mmu(void)
>  	else if (strncmp(version, "FirmWorks,3.", 12) == 0) {
>  		of_workarounds = OF_WA_CLAIM | OF_WA_LONGTRAIL;
>  		call_prom("interpret", 1, 1, "dev /memory 0 to allow-reclaim");
> +#ifdef CONFIG_PPC_MPC52xx
> +	} else if (strcmp(version, "EFIKA5K2") == 0) {
> +		call_prom("interpret", 1, 1,
> +			" .\" Adding EFIKA5K2 Ethernet PHY\" cr"
> +			" s\" /builtin\" find-device"
> +			" new-device"
> +				" 1 encode-int s\" #address-cells\" property"
> +				" 0 encode-int s\" #size-cells\" property"
> +				" s\" mdio\" 2dup device-name device-type"
> +				" s\" mpc5200b-fec-phy\" encode-string s\" compatible\" property"
> +				" 0xf0003000 0x400 reg"
> +				" 0x2 encode-int"
> +				" 0x5 encode-int encode+"
> +				" 0x3 encode-int encode+"
> +				" s\" interrupts\" property"
> +				" new-device"
> +					" s\" ethernet-phy\" 2dup device-name device-type"
> +					" 0x10 encode-int s\" reg\" property"
> +					" my-self"
> +					" ihandle>phandle"
> +				" finish-device"
> +			" finish-device"
> +			" s\" /builtin/ethernet\" find-device"
> +				" encode-int"
> +				" s\" phy-handle\" property"
> +			" device-end"
> +			);
> +#endif
>  	} else
>  		return;
>  	_prom->memory = call_prom("open", 1, 1, ADDR("/memory"));
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: add phy-handle property for fec_mpc52xx

[Sven Luther]

On Wed, Jan 09, 2008 at 03:26:04PM +0000, Matt Sealey wrote:
> Clarification: I really have to disagree with this patch, and Sven.
> 
> The whole point of removing the stuff from the Linux kernel (as the
> efika.forth script and the associated patch performs) is that it means
> the Linux kernel is no longer a "moving target" for our firmware
> development.

What firmware development ? 

> If users require these kernels they can run efika.forth - the major
> stumbling block being this is quite ugly to do right now. This is our
> problem - bplan, Genesi, myself whoever you want to target - it should
> not be made into a Linux problem by creating this "moving target" that
> needs constant patching to maintain driver coherency.

Then get the firmware fixed, and everyone would be happy. I don't see
that happening in the near future, just as there has been no pegasos
firmware release in ages, and my work on it has been scratched, and
ignored for the efika firmware which has lot of regression compared to
the latest pegasos beta releases.

A new efika firmware upgrade has been promised in, what was it, marsch
last year or so, where is it ? 

Let's just fix this in the kernel, until we get a fixed efika firmware,
then we can drop it easily enough. But until this happens, we need to be
able to boot the kernel without any extra work on the users part.

Friendly,

Sven Luther

Re: add phy-handle property for fec_mpc52xx

[Matt Sealey]

Sven Luther wrote:
> 
> Let's just fix this in the kernel, until we get a fixed efika firmware,
> then we can drop it easily enough. But until this happens, we need to be
> able to boot the kernel without any extra work on the users part.

That is exactly why I don't like the idea. Yes, it makes it easier for users
and easier for distro managers to say "it supports the Efika" but it makes
the Forth fixing, and any further firmware development (ignore the lack of
releases, it means nothing) much harder.

It should not be a function of Linux to fix firmware problems. This was
the FIRM line by Ben, Segher and the rest of the LinuxPPC guys when we
released the Efika - fix the firmware, not Linux, don't hack drivers, don't
rely on fixups. I disagreed at the time due to the urgency to release the
board, but now, we have the luxury of not having to rush it through to get
a product on sale.

I would much rather the Linux kernel did not implement fixups for firmware
which we can fix. The phy-handle part that Olaf specifies in his patch
can be added by a user to nvramrc, BY HAND, in around 10 lines of Forth
code. Those 6 lines are in the efika.forth script, and in fact Olaf is
simply running "interpret" over an encoded version of this! (I say 10 lines
because the efika.forth script is needlessly verbose for the purpose of
being readable by humans).

It is not scary or difficult to do this if you need ethernet to work, and
not beyond the scope of the installation documentation or an Efika wiki
page. The Forth stuff will work fine for *all* operating systems.

If you don't like not having your Linux distro or a default kernel working
on our default firmware, PLEASE FEEL FREE TO BLAME US. PROFUSELY.

Alternatively I'd love to work with people to create a comprehensive
pre-update binary fix (not a boot loader but an installer) for the Forth
script so that users can run it before they boot any distro disk, and then
the kernel on the CD, the kernel in the distro repositories, will not have
the burden of tracking firmware releases, and the Linux team will not have
the burden of maintaining tiny fixes for things which may always be fixed.

After all, there is no profit or benefit in fixing something 5 times just
in case the user only has 4 of them installed.

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: add phy-handle property for fec_mpc52xx

[Sven Luther]

On Wed, Jan 09, 2008 at 04:30:13PM +0000, Matt Sealey wrote:
> 
> Sven Luther wrote:
> >
> >Let's just fix this in the kernel, until we get a fixed efika firmware,
> >then we can drop it easily enough. But until this happens, we need to be
> >able to boot the kernel without any extra work on the users part.
> 
> That is exactly why I don't like the idea. Yes, it makes it easier for users
> and easier for distro managers to say "it supports the Efika" but it makes
> the Forth fixing, and any further firmware development (ignore the lack of
> releases, it means nothing) much harder.

efika firmware development is dead. Until we see a release we should
assume that the efika is a firmware with breakage, and no upstream
support at all. 

Friendly,

Sven Luther

Re: add phy-handle property for fec_mpc52xx

[Matt Sealey]

Sven Luther wrote:
> On Wed, Jan 09, 2008 at 04:30:13PM +0000, Matt Sealey wrote:
>> Sven Luther wrote:
>>> Let's just fix this in the kernel, until we get a fixed efika firmware,
>>> then we can drop it easily enough. But until this happens, we need to be
>>> able to boot the kernel without any extra work on the users part.
>> That is exactly why I don't like the idea. Yes, it makes it easier for users
>> and easier for distro managers to say "it supports the Efika" but it makes
>> the Forth fixing, and any further firmware development (ignore the lack of
>> releases, it means nothing) much harder.
> 
> efika firmware development is dead. Until we see a release we should
> assume that the efika is a firmware with breakage, and no upstream

The link that Olaf presented, www.powerdeveloper.org/asset/by-id/46 *is*
the upstream support for now. What his patch does is say, the upstream
support exists, but we don't like it, so we will supplement the patch..

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: add phy-handle property for fec_mpc52xx

[Sven Luther]

On Wed, Jan 09, 2008 at 04:36:19PM +0000, Matt Sealey wrote:
> 
> Sven Luther wrote:
> >On Wed, Jan 09, 2008 at 04:30:13PM +0000, Matt Sealey wrote:
> >>Sven Luther wrote:
> >>>Let's just fix this in the kernel, until we get a fixed efika firmware,
> >>>then we can drop it easily enough. But until this happens, we need to be
> >>>able to boot the kernel without any extra work on the users part.
> >>That is exactly why I don't like the idea. Yes, it makes it easier for 
> >>users
> >>and easier for distro managers to say "it supports the Efika" but it makes
> >>the Forth fixing, and any further firmware development (ignore the lack of
> >>releases, it means nothing) much harder.
> >
> >efika firmware development is dead. Until we see a release we should
> >assume that the efika is a firmware with breakage, and no upstream
> 
> The link that Olaf presented, www.powerdeveloper.org/asset/by-id/46 *is*
> the upstream support for now. What his patch does is say, the upstream
> support exists, but we don't like it, so we will supplement the patch..

Matt, your work on efika.forth is laudable, and it is nice that you took
the time to support it.

*BUT* it is not acceptable for a distribution, or for someone who will
have to do user support, to have to launch a second binary before
launching the kernel. Especially when netbooting for example.

Friendly,

Sven Luther

Re: add phy-handle property for fec_mpc52xx

[Matt Sealey]

Sven Luther wrote:
> On Wed, Jan 09, 2008 at 04:36:19PM +0000, Matt Sealey wrote:
>> The link that Olaf presented, www.powerdeveloper.org/asset/by-id/46 *is*
>> the upstream support for now. What his patch does is say, the upstream
>> support exists, but we don't like it, so we will supplement the patch..
> 
> Matt, your work on efika.forth is laudable, and it is nice that you took
> the time to support it.
> 
> *BUT* it is not acceptable for a distribution, or for someone who will
> have to do user support, to have to launch a second binary before
> launching the kernel. Especially when netbooting for example.

Then I think you are all missing the fact that I said there *IS A REALLY
CUTE WAY OF INSTALLING IT ONCE* by uploading it into nvramrc, it will not
be a runnable script, but executed on boot, because it'll be flashed into
nvramrc.

However I don't have the time to go into making this app, creating the
tools to munge efika.forth into a correct more uploadable format, and
creating the install tool. I barely have enough time to track this list
and make sure any drivers requiring firmware tree changes are taken care
of (I definitely lost the plot with the USB one, I haven't even checked
it even though I was asked to 2 weeks ago..)

Unfortunately one guy who already has a significant amount of work to do
all day, who is not the responsible person for firmware issues, and is
not being assisted by anyone in the community either generated and
maintained by Genesi or existing around Linux, poses some serious problems
with timeliness of updates.

If anyone wants to stop patching Linux and instead make efika.forth easier
to use, feel free, REALLY. Sven, are you volunteering for this REALLY
tiny task? It will probably take all of a day for a couple of guys to
work up the tools to do it based on very simple instructions and data
provided.. the work is probably worth the price of a pizza, so no
contracts are going to be worked out for it.

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: add phy-handle property for fec_mpc52xx

[Sven Luther]

On Wed, Jan 09, 2008 at 05:17:52PM +0000, Matt Sealey wrote:
> 
> Sven Luther wrote:
> >On Wed, Jan 09, 2008 at 04:36:19PM +0000, Matt Sealey wrote:
> >>The link that Olaf presented, www.powerdeveloper.org/asset/by-id/46 *is*
> >>the upstream support for now. What his patch does is say, the upstream
> >>support exists, but we don't like it, so we will supplement the patch..
> >
> >Matt, your work on efika.forth is laudable, and it is nice that you took
> >the time to support it.
> >
> >*BUT* it is not acceptable for a distribution, or for someone who will
> >have to do user support, to have to launch a second binary before
> >launching the kernel. Especially when netbooting for example.
> 
> Then I think you are all missing the fact that I said there *IS A REALLY
> CUTE WAY OF INSTALLING IT ONCE* by uploading it into nvramrc, it will not
> be a runnable script, but executed on boot, because it'll be flashed into
> nvramrc.
> 
> However I don't have the time to go into making this app, creating the
> tools to munge efika.forth into a correct more uploadable format, and
> creating the install tool. I barely have enough time to track this list
> and make sure any drivers requiring firmware tree changes are taken care
> of (I definitely lost the plot with the USB one, I haven't even checked
> it even though I was asked to 2 weeks ago..)
> 
> Unfortunately one guy who already has a significant amount of work to do
> all day, who is not the responsible person for firmware issues, and is
> not being assisted by anyone in the community either generated and
> maintained by Genesi or existing around Linux, poses some serious problems
> with timeliness of updates.
> 
> If anyone wants to stop patching Linux and instead make efika.forth easier
> to use, feel free, REALLY. Sven, are you volunteering for this REALLY
> tiny task? It will probably take all of a day for a couple of guys to
> work up the tools to do it based on very simple instructions and data
> provided.. the work is probably worth the price of a pizza, so no
> contracts are going to be worked out for it.

Just fix it conditionally in linux, like it is being proposed, and
everyone is happy :)

Friendly,

Sven Luther

Re: add phy-handle property for fec_mpc52xx

[Grant Likely]

On 1/9/08, Matt Sealey <matt@genesi-usa.com> wrote:
> Please let's keep the nature of our firmware and the Linux codebase
> independant, and move the burden of support to Genesi, and not the
> Linux PowerPC team. After all, what is next, after phy-handle do
> you want to add i2c, irda, missing xlb/cdm entries in the patch so
> that other things work? Does everyone have to custom compile their
> own kernel? What happens if we do another firmware release and
> the Linux kernel overwrites important values without checking as
> it does now? It simply causes problems.

FWIW, I've got a patch in my tree that removes a bunch of the efika
fixups.  I've learned a lot over the past year and I'm taking a more
pragmatic approach.  So, fixups that are not absolutely required to
get a working Efika are going away.

However, I'm still inclined to pick up Olaf's patch with the
appropriate protections around it so it is only done if the nodes are
missing.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: add phy-handle property for fec_mpc52xx

[Matt Sealey]

Grant Likely wrote:
> On 1/9/08, Matt Sealey <matt@genesi-usa.com> wrote:
>> Please let's keep the nature of our firmware and the Linux codebase
>> independant, and move the burden of support to Genesi, and not the
>> Linux PowerPC team. After all, what is next, after phy-handle do
>> you want to add i2c, irda, missing xlb/cdm entries in the patch so
>> that other things work? Does everyone have to custom compile their
>> own kernel? What happens if we do another firmware release and
>> the Linux kernel overwrites important values without checking as
>> it does now? It simply causes problems.
> 
> FWIW, I've got a patch in my tree that removes a bunch of the efika
> fixups.  I've learned a lot over the past year and I'm taking a more
> pragmatic approach.  So, fixups that are not absolutely required to
> get a working Efika are going away.
> 
> However, I'm still inclined to pick up Olaf's patch with the
> appropriate protections around it so it is only done if the nodes are
> missing.

Eh.. yeah. Maybe. Seems like a cop-out to me. I would rather you removed
the patch and called us a bunch of idiots for coding bad firmware, than
have the fixups be dependant on what could turn into a very well coded
but essentially screen-long list of fixups for myriad firmware versions
where the properties may or may not be present or correct for various
firmware versions and devices.

Grant, are you any good at coding firmware-level stuff without utilizing
any preexisting code under the GPL? I'd like to collaborate on an installer
tool which can put efika.forth (and therefore all these fixes) in.

The end result would be efika_device_tree_fixups() reporting if you have
an old firmware and saying, things may not work. efika.forth is steering
towards hacking /openprom/built-on with an appropriate date for firmware
and device tree version checking, so any date lower than the appropriate
script or firmware version can be warned about.

(a similar tactic is employed by lmsensors if you have a Via SMB driver
loaded but the BIOS has left the SMB block in the southbridge disabled,
it says you need to update your BIOS or use force=1 and leaves it non
working. You will see this on Pegasos. I like this tactic, just not the
recommendation to update your BIOS when it may or may not exist.. a
simple warning that some devices may not work correctly is essential though)

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: add phy-handle property for fec_mpc52xx

[Grant Likely]

On 1/9/08, Matt Sealey <matt@genesi-usa.com> wrote:
> > However, I'm still inclined to pick up Olaf's patch with the
> > appropriate protections around it so it is only done if the nodes are
> > missing.
>
> Eh.. yeah. Maybe. Seems like a cop-out to me. I would rather you removed
> the patch and called us a bunch of idiots for coding bad firmware, than
> have the fixups be dependant on what could turn into a very well coded
> but essentially screen-long list of fixups for myriad firmware versions
> where the properties may or may not be present or correct for various
> firmware versions and devices.

I've come to the conclusion that Postel knew what he was talking
about; "Be conservative in what you do; be liberal in what you accept
from others."  :-)

I 100% agree that this stuff is better done in firmware.  However,
until that stuff is in place; it is 100% reasonable and desirable to
work around it in prom_init.  That being said, I will modify prom_init
to not blindly apply fixups if they have already been done in
firmware.

> Grant, are you any good at coding firmware-level stuff without utilizing
> any preexisting code under the GPL? I'd like to collaborate on an installer
> tool which can put efika.forth (and therefore all these fixes) in.

I'm good at firmware stuff, but time comes at a premium.  This level
of work would require a contract arrangement between our two
companies.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: add phy-handle property for fec_mpc52xx

[David Woodhouse]

On Wed, 2008-01-09 at 15:26 +0000, Matt Sealey wrote:
> If anyone wants to help/assist/suggest any updates to efika.forth,
> create binary tools which assist the installation of the script for
> users and for placement on Linux distro CDs etc. I would be very
> grateful, but it seems we have hit the Wall of Apathy where users
> complain for a feature but are not willing to work for it.

We're already shipping efika.forth in Fedora rawhide, and in my updated
spins of Fedora 8. It's a pain in the arse, but it kind of works.

It would be much better if the kernel would 'just work'. The ideal way
of achieving that is for the firmware to be fixed -- but that's been
promised for a long time now, and we just don't believe you any more. So
working round it in the kernel seems to be the next best option.

> (I am invoking the Open Source Fallacy of that if the source is
> available you can patch it, I say that patching Linux is not the
> solution, but patching the firmware is. But nobody is willing to
> work on patching the firmware and keeping Linux entirely independant
> of our so-deemed "crappy" firmware)

/me looks at http://git.infradead.org/?p=openfirmware.git
/me looks at the Efika...

-- 
dwmw2

Re: add phy-handle property for fec_mpc52xx

[Matt Sealey]

David Woodhouse wrote:
> On Wed, 2008-01-09 at 15:26 +0000, Matt Sealey wrote:
>> If anyone wants to help/assist/suggest any updates to efika.forth,
>> create binary tools which assist the installation of the script for
>> users and for placement on Linux distro CDs etc. I would be very
>> grateful, but it seems we have hit the Wall of Apathy where users
>> complain for a feature but are not willing to work for it.
> 
> We're already shipping efika.forth in Fedora rawhide, and in my updated
> spins of Fedora 8. It's a pain in the arse, but it kind of works.

I already said I don't like that solution either :]

efika.forth may change between Fedora 8 spins and user downloading it,
meaning updated kernels in the repositories stop working or so. This is
what I am hoping to stop happening by having the kernel *really just not
do anything* so it is entirely the fault of efika.forth or firmware
releases not happening, and not a bastardised combination of both.

> It would be much better if the kernel would 'just work'. The ideal way
> of achieving that is for the firmware to be fixed -- but that's been
> promised for a long time now, and we just don't believe you any more. So
> working round it in the kernel seems to be the next best option.

I don't blame you for thinking that; announcing a firmware update was
a rather ill-thought-out decision not made by anyone who works on the
firmware or with firmware issues.

Don't rely on a real flashable firmware update any time soon, but don't
take that as a task to "fix" the Linux kernel instead.

Your firmware update is and will be for the time being, that Forth
script, which is easy enough to paste into a serial console into nvramrc,
or run from GRUB, or run manually and edit the boot line at the bottom..

When a new firmware appears, and for all you and I know this could
happen this afternoon, this patch will become obselete and needs to
be removed - even Grant's version, because there is no guarantee
whatsoever that Nico will call the device /builtin/mdio when the
search for the device in the driver is for a compatible of "ethernet-phy"
for example.

By hard coding these things into Linux you are shaping firmware
development and making it harder. You are fixing things in the
efika.forth script which needn't be fixed - now we will need to
keep the script entirely compatible with that patch, even if it's
wrong. I don't like this situation because it causes me more work.
The guys in Germany don't release new firmwares BECAUSE of the
chop and change of Linux device tree expectations. If we released
a firmware every time you have a new idea on how it should look,
there would be one every month, and no other bugs would have time
to be fixed due to the extensive regression testing firmware has
to go through on multiple current and future board revisions with
multiple current and future kernels.

>> (I am invoking the Open Source Fallacy of that if the source is
>> available you can patch it, I say that patching Linux is not the
>> solution, but patching the firmware is. But nobody is willing to
>> work on patching the firmware and keeping Linux entirely independant
>> of our so-deemed "crappy" firmware)
> 
> /me looks at http://git.infradead.org/?p=openfirmware.git
> /me looks at the Efika...

It would be quicker to update efika.forth with an installer (I already
told you how I would do it.. the whole technical detail!) than to
bring up SmartFirmware again for the Efika.

I really want to shift the burden to Genesi and not onto the Linux
kernel, as involving Linux patches means double the work, which will
delay firmware releases, delay efika.forth updates due to extended
testing with myriad different versions of patches etc.

It is better if the Linux kernel is simply a known quantity, non-working
without external assistance, if that be the case. It is not your fault
if the Linux kernel doesn't work on stock Efikas, it's OURS. However
without significant support behind fixing the firmware (Genesi is working
on it and efika.forth is PART of that - a good testing bed with no
flashing required!) and with patches being continually submitted to the
kernel to work around supposed firmware weaknesses, it is just going to
be too complicated.

After all, if Linux just trashes the firmware, replaces anything it
doesn't deem right, why bother releasing a new firmware ever? The
patch alone states the case that you do not need us to ever fix anything,
I don't think you really mean to go there.

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: add phy-handle property for fec_mpc52xx

[Paul Mackerras]

David Woodhouse writes:

> It would be much better if the kernel would 'just work'. The ideal way
> of achieving that is for the firmware to be fixed -- but that's been
> promised for a long time now, and we just don't believe you any more. So
> working round it in the kernel seems to be the next best option.

Does the efika use a boot wrapper?  If so then putting the fixup in
the boot wrapper might be better.

Paul.

Re: add phy-handle property for fec_mpc52xx

[Benjamin Herrenschmidt]

On Thu, 2008-01-10 at 13:21 +1100, Paul Mackerras wrote:
> David Woodhouse writes:
> 
> > It would be much better if the kernel would 'just work'. The ideal way
> > of achieving that is for the firmware to be fixed -- but that's been
> > promised for a long time now, and we just don't believe you any more. So
> > working round it in the kernel seems to be the next best option.
> 
> Does the efika use a boot wrapper?  If so then putting the fixup in
> the boot wrapper might be better.

It's standard OF boot process, the fixup belongs in prom_init. Grant has
a better version of the patch that puts the fixup along with other efika
related ones that are already there.

Cheers,
Ben.

Re: add phy-handle property for fec_mpc52xx

[David Woodhouse]

On Thu, 2008-01-10 at 13:21 +1100, Paul Mackerras wrote:
> David Woodhouse writes:
> 
> > It would be much better if the kernel would 'just work'. The ideal way
> > of achieving that is for the firmware to be fixed -- but that's been
> > promised for a long time now, and we just don't believe you any more. So
> > working round it in the kernel seems to be the next best option.
> 
> Does the efika use a boot wrapper?  If so then putting the fixup in
> the boot wrapper might be better.

No, it doesn't (at least for Fedora) -- we use yaboot. Perhaps we could
make yaboot run the fixups?

-- 
dwmw2

Re: add phy-handle property for fec_mpc52xx

[Olof Johansson]

On Wed, Jan 09, 2008 at 03:26:04PM +0000, Matt Sealey wrote:
> Clarification: I really have to disagree with this patch, and Sven.
> 
> The whole point of removing the stuff from the Linux kernel (as the
> efika.forth script and the associated patch performs) is that it means
> the Linux kernel is no longer a "moving target" for our firmware
> development.

But that's what this _accomplishes_. If linux needs something from the
firmware environment that it doesn't provide, it adds it itself. That
means that the firmware<>linux interface is no longer a moving target.

> If anyone wants to help/assist/suggest any updates to efika.forth,
> create binary tools which assist the installation of the script for
> users and for placement on Linux distro CDs etc. I would be very
> grateful, but it seems we have hit the Wall of Apathy where users
> complain for a feature but are not willing to work for it.

Amazing. Olaf just did that work for you, and he did it without providing
yet another tool for distros to pick up and maintain. And still you
complain. Is it really that strange that people aren't helping you out?!


-Olof

Re: add phy-handle property for fec_mpc52xx

[Grant Likely]

On 1/9/08, Olaf Hering <olaf@aepfle.de> wrote:
>
> The new network driver fec_mpc52xx will not work on efika because the
> firmware does not provide all required properties.
> http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to
> create more properties. But only the phy stuff is required to get a
> working network.
>
> This should go into the kernel because its appearently
> impossible to boot the script via tftp and then load the real boot
> binary (yaboot or zimage).
>

Signed-off-by?

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: add phy-handle property for fec_mpc52xx

[Paul Mackerras]

Olaf Hering writes:

> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -1487,6 +1487,34 @@ static void __init prom_find_mmu(void)
>  	else if (strncmp(version, "FirmWorks,3.", 12) == 0) {
>  		of_workarounds = OF_WA_CLAIM | OF_WA_LONGTRAIL;
>  		call_prom("interpret", 1, 1, "dev /memory 0 to allow-reclaim");
> +#ifdef CONFIG_PPC_MPC52xx
> +	} else if (strcmp(version, "EFIKA5K2") == 0) {

Why have you added this stuff in prom_find_mmu rather than putting it
in fixup_device_tree_efika()?

Paul.

Re: add phy-handle property for fec_mpc52xx

[Olaf Hering]

On Thu, Jan 10, Paul Mackerras wrote:

> Olaf Hering writes:
> 
> > --- a/arch/powerpc/kernel/prom_init.c
> > +++ b/arch/powerpc/kernel/prom_init.c
> > @@ -1487,6 +1487,34 @@ static void __init prom_find_mmu(void)
> >  	else if (strncmp(version, "FirmWorks,3.", 12) == 0) {
> >  		of_workarounds = OF_WA_CLAIM | OF_WA_LONGTRAIL;
> >  		call_prom("interpret", 1, 1, "dev /memory 0 to allow-reclaim");
> > +#ifdef CONFIG_PPC_MPC52xx
> > +	} else if (strcmp(version, "EFIKA5K2") == 0) {
> 
> Why have you added this stuff in prom_find_mmu rather than putting it
> in fixup_device_tree_efika()?

I just looked for a "model" check.