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 <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
