Re: Lenny/armel with Debian kernel on Buffalo Linkstation Pro v2
* Tim Small [EMAIL PROTECTED] [2008-06-21 18:35]: The problem turns out to be with the initramfs code - whereas in the case of an initrd, only a single gzip archive is looked for, the initramfs code overlays the contents of multiple concatenated gziped cpio archives, and so expects the whole 15M to be filled with valid gzip data Yeah, it's a feature in the sense that it allows you to simply cat multiple gzipped cpio archives together and have all of them loaded. However, I wonder whether it would be possible to modify the code so it won't ignore the ramdisk it has found if it finds invalid data later on. I've come up with the attached patch to ignore it, which WorksForMe (tm). It maybe that this bogus parameter also exists on other Buffalo hardware (and as such the patch should be expanded to include other hardware numbers), but I don't have any to test on. Such a specific patch has about zero change to be accepted in the mainline kernel (although a patch that would do the thing would imho be a good idea). But anyway, what's the problem with simply padding the ramdisk to 15MB with zeros? -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lenny/armel with Debian kernel on Buffalo Linkstation Pro v2
Martin Michlmayr wrote:
.. Remove the initrd=0x00800040,15M parameter (check that your env look like
those below), and verify
The reason is probably that it tells the kernel that the ramdisk is
15M long, but the Debian ramdisk will be much smaller. You could try
padding the Debian ramdisk to 15 MB with zeros to see if that works.
The problem turns out to be with the initramfs code - whereas in the
case of an initrd, only a single gzip archive is looked for, the
initramfs code overlays the contents of multiple concatenated gziped
cpio archives, and so expects the whole 15M to be filled with valid gzip
data Whilst it would be theoretically possible to make up a file
which is padded with valid empty gzipped cpio archives up to a size of
exactly 15M, this sounds quite hard, and in fact, it doesn't seem that
the uboot firmware is able to load a file of this size either from disk,
or by tftp - 12M or so seems to be the limit.
The only reasonable thing I can think of (assuming you don't want to
delete this env setting, which is pointless anyway) is to modify the
command line, or ignore it...
I've come up with the attached patch to ignore it, which WorksForMe
(tm). It maybe that this bogus parameter also exists on other Buffalo
hardware (and as such the patch should be expanded to include other
hardware numbers), but I don't have any to test on.
Cheers,
Tim.
Signed-off-by: [EMAIL PROTECTED]
--- fresh/linux-2.6-2.6.26~rc6/arch/arm/kernel/setup.c 2008-04-17 02:49:44.0 +
+++ linux-2.6-2.6.26~rc6/arch/arm/kernel/setup.c 2008-06-21 16:49:39.0 +
@@ -447,9 +447,12 @@
start = memparse(*p, p);
if (**p == ',') {
size = memparse((*p) + 1, p);
-
- phys_initrd_start = start;
- phys_initrd_size = size;
+ if (start == 0x800040 size == 0xf0 machine_arch_type == 0x0631) {
+ printk(KERN_WARNING Ignoring bogus Buffalo Linkstation Pro/Live initrd=0x00800040,15M parameter\n);
+ } else {
+ phys_initrd_start = start;
+ phys_initrd_size = size;
+ }
}
}
__early_param(initrd=, early_initrd);
Re: Lenny/armel with Debian kernel on Buffalo Linkstation Pro v2
* Tim Small [EMAIL PROTECTED] [2008-04-09 12:54]: n.b. devio fixes up the machine ID, and this currently needs to be 0x05e5 (not 0x0630 etc. until the kernel has been fixed). FWIW, I've put the Linkstation patch into SVN in the meantime. .. Modify the boot environment (default boot prevents the initramfs loading - the kernel says checking if image is initramfs...it isn't (bad gzip magic numbers); looks like an initrd - however I'm not really sure why). ... .. Remove the initrd=0x00800040,15M parameter (check that your env look like those below), and verify The reason is probably that it tells the kernel that the ramdisk is 15M long, but the Debian ramdisk will be much smaller. You could try padding the Debian ramdisk to 15 MB with zeros to see if that works. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
