From: Alan Curry <hidden> Date: 2007-08-02 04:41:16
Matt Sealey writes the following:
Yeah please do a fixup for the boot wrapper.
Or, if you have trouble, go into the firmware and type "nvedit", add
these lines;
" /isa/8042" find-device
" 8042" encode-string device-type
(then ctrl-c to exit and nvstore to run it on next reboot. Try it without
the patch first, on the firmware console, just to be sure I got it right,
because I can't test it here)
It works from the ok prompt but in the nvramrc it doesn't find the device.
(pci/isa nodes not created yet?)
But the larger point:
You don't need to patch Linux at all. In fact for silly things like this
I would recommend against it :)
If the workaround doesn't go into the kernel, everybody with affected
hardware has to individually find out about the bug (probably by experiencing
an annoying keyboardless boot) and fix it himself. Is that worth the
reduction in kernel clutter?
--
Alan Curry
pacman@world.std.com
You don't need to patch Linux at all. In fact for silly things like
this
I would recommend against it :)
If the workaround doesn't go into the kernel, everybody with affected
hardware has to individually find out about the bug (probably by
experiencing
an annoying keyboardless boot) and fix it himself.
That's one of the reasons why this should go into a bootwrapper.
Segher
From: Matt Sealey <hidden> Date: 2007-08-06 21:39:53
Okay before you add to the nvramrc you also need to add probe-all to build the
device tree first; I assumed this was common knowledge.
probe-all
" /pci/isa/8042" find-device
" 8042" encode-string device-type
install-console
banner
That should do it. Without probe-all/install-console/banner in the nvramrc they
will be run by the boot process (this is documented in the IEEE 1275 specs)
Yeah it will break for people on their first boot but let's put a few things
across;
1) Pegasos has been discontinued. The number of people with this bug are in
the low thousands - if they upgrade to 2.6.22 at all.
2) The fix was in the wrong place anyway, if it was going to be done anywhere
at all it needs to be in arch/powerpc/kernel/prom_init.c:fixup_device_tree_chrp()
like the ISA ranges breakage (which is on Briq) and IDE IRQ misnumbering fix.
Not the keyboard platform driver.
3) In any case this should be something that is fixed in the firmware, as any
stalwart, stubborn Linux developer will rant at you about. If you can't get a
firmware update or it's not fixed, this is the best place to do it.
As for Segher, bootwrapper not such a good place as that's still mussing up
the kernel with these fixes. Let the boot loader do it for the OS, and don't
mess up the OS with device-tree fixups. After all it may not just be Linux
that stumbles on it. Why have the same patch in every OS?
With nvramrc, the fix is done for EVERY operating system from firmware upwards.
The semi-official Genesi line of support and what I have been told by the board
designer is if you need to fix something in the device tree, that is what nvramrc
is for, and that is why Open Firmware runs Forth scripts.
I have a fixup script for Pegasos and one for Efika which I may publish at some
point in the very near future. We may ship a small patch for Marcin Kurek's
"BootCreator" (http://tbs-software.com/morgoth/projects.html) which includes
all the stuff. We may write our own binary bootloader.. I am waiting for the
result of the new firmware feature requests before we waste time on stuff
bplan is silently fixing.
--
Matt Sealey [off-list ref]
Genesi, Manager, Developer Relations
Alan Curry wrote:
Matt Sealey writes the following:
quoted
Yeah please do a fixup for the boot wrapper.
Or, if you have trouble, go into the firmware and type "nvedit", add
these lines;
" /isa/8042" find-device
" 8042" encode-string device-type
(then ctrl-c to exit and nvstore to run it on next reboot. Try it without
the patch first, on the firmware console, just to be sure I got it right,
because I can't test it here)
It works from the ok prompt but in the nvramrc it doesn't find the device.
(pci/isa nodes not created yet?)
But the larger point:
quoted
You don't need to patch Linux at all. In fact for silly things like this
I would recommend against it :)
If the workaround doesn't go into the kernel, everybody with affected
hardware has to individually find out about the bug (probably by experiencing
an annoying keyboardless boot) and fix it himself. Is that worth the
reduction in kernel clutter?
2) The fix was in the wrong place anyway, if it was going to be done
anywhere
at all it needs to be in
arch/powerpc/kernel/prom_init.c:fixup_device_tree_chrp()
like the ISA ranges breakage (which is on Briq) and IDE IRQ
misnumbering fix.
Not the keyboard platform driver.
Yeah. In the bootwrapper.
3) In any case this should be something that is fixed in the firmware,
as any
stalwart, stubborn Linux developer will rant at you about.
Sure, if you *can* get a fix for the firmware. Until every
user has this update, fixing it in the kernel wrapper helps
users.
As for Segher, bootwrapper not such a good place as that's still
mussing up
the kernel with these fixes. Let the boot loader do it for the OS, and
don't
mess up the OS with device-tree fixups.
Sure, the bootloader can do it too, but then we need to fix
every bootloader that's used with Linux on this platform.
Maybe that's just one, that would make things simple :-)
After all it may not just be Linux
that stumbles on it. Why have the same patch in every OS?
This is just pragmatics: Linux needs the workaround -> Linux
implements the workaround. Sure it is not a _proper_ fix, but
a correctly implemented workaround "fixes" it for all users,
forever.
With nvramrc, the fix is done for EVERY operating system from firmware
upwards.
But it's something every user has to do separately.
The semi-official Genesi line of support and what I have been told by
the board
designer is if you need to fix something in the device tree, that is
what nvramrc
is for, and that is why Open Firmware runs Forth scripts.
That's hardly the only reason. But yeah, that's one way to
implement the workaround, but _we_ (the Linux community) cannot
do it like that (easily) for all users.
Segher
From: Matt Sealey <hidden> Date: 2007-08-07 16:20:35
Segher Boessenkool wrote:
That's hardly the only reason. But yeah, that's one way to
implement the workaround, but _we_ (the Linux community) cannot
do it like that (easily) for all users.
But you're the guy who told us our firmware sucks and we should fix our
firmware rather than clutter Linux with too many fixups. There are about
200 lines of code required to bring the Efika device tree up to the
Linux "specification" of a 5200B device tree, which will never make it
into code. Pegasos is ostensibly the same way.
Linux is already a bad enough moving target, and none of these fixes help
other operating systems or developers, if we only patch Linux, and only
say, you must run the latest Linux kernel version, and the latest U-Boot,
and the latest FDT binary, and encourage users to upgrade it all regardless
of your worries.
So, there are two opinions here;
1) the reports as we had when Efika was released and continually levied
against Pegasos firmware, that the firmware is broken and must be fixed
to comply, and no fixes will be considered because "bplan sucks and must
fix it"
2) As long as the patches are 2 lines big, you will allow them in, because
it is too much for a user to update firmware or run a script to boot?
Would you guys rather we shipped a boot script that ran the OS, fixed
all these issues in-place in-firmware, so Linux did not have to have these
workarounds, or are you accepting patches now? Because I can write those
200 lines of code to work around Efika device tree mistakes you yourself
complained about at Christmas last year..
--
Matt Sealey [off-list ref]
Genesi, Manager, Developer Relations
That's hardly the only reason. But yeah, that's one way to
implement the workaround, but _we_ (the Linux community) cannot
do it like that (easily) for all users.
But you're the guy who told us our firmware sucks and we should fix our
firmware
Yes, and? You _should_ fix your firmware, it is buggy after all.
Esp. back then as it wasn't shipping yet.
rather than clutter Linux with too many fixups.
Also, putting fixups in the wrapper is a wholly different thing from
putting fixups deep inside the kernel code proper.
Linux is already a bad enough moving target, and none of these fixes
help
other operating systems or developers, if we only patch Linux,
But that's not Linux' concern. You might care, we don't. Is
this so hard to understand?
1) the reports as we had when Efika was released and continually levied
against Pegasos firmware, that the firmware is broken and must be fixed
to comply, and no fixes will be considered because "bplan sucks and
must
fix it"
2) As long as the patches are 2 lines big, you will allow them in,
because
it is too much for a user to update firmware or run a script to boot?
Our only two concerns are what is best on technical grounds, and what
is best for our users.
Would you guys rather we shipped a boot script that ran the OS, fixed
all these issues in-place in-firmware, so Linux did not have to have
these
workarounds,
Sure, if you can do that, that would be great.
Segher
From: Matt Sealey <hidden> Date: 2007-08-09 16:45:34
Segher Boessenkool wrote:
quoted
Would you guys rather we shipped a boot script that ran the OS, fixed
all these issues in-place in-firmware, so Linux did not have to have
these
workarounds,
Sure, if you can do that, that would be great.
Right, so don't accept that keyboard fix, and we will work on the script
instead.
--
Matt Sealey [off-list ref]
Genesi, Manager, Developer Relations