lilo vs. diskonchip (again, sorry)
Dear MTD users and maintainers,
first of all I'd like to apologize for asking for help while I still work with Linux 2.4 - I guess my problem could be unrelated to the minor kernel version.
I'm having trouble with Lilo on a 32meg DiskOnChip.
I'm using a homebrew boot CD with some scripts starting with sfdisk and mkfs.ext2, then unpacking a prepared system tarball onto the diskonchip, then running Lilo.
I have an old kernel, maybe a year and a half old, it's 2.4.21 with a MTD patch from those days, that works just fine.
Then I have several recent kernels (2.4.26, 2.4.28, 2.4.29) with recent MTD patches: 2.4.29 with the "last 2.4-compatible MTD snapshot".
These use the NAND-based re-implemented diskonchip driver and appear to consistently hamper Lilo installation for some reason.
If I boot the ancient kernel from CD and install Lilo on the DoC, the recent kernel installed on the DoC is able to boot and accesses the DoC just fine.
If I boot the recent kernel from CD and install Lilo, although the filesystem appears to be created just fine, Lilo refuses to boot, saying
L 40 40 40 40 40 40 40... etc. a million times.
I'm using the bios=0x80 option, to no avail - it works that way with the old kernel, but not with the new ones.
I've tried switching between a vanilla lilo (+boot.b) and the M-Systems hacked lilo - no difference there. I'm not surprised though, as the OS MTD drivers use a different major number than the M-Systems semi-closed-source driver.
I take care to run a full graceful system shutdown after each install, though I'm sure Lilo does a sync() before and after it messes with the MBR on the DoC, so a plain cold reset should work just fine.
I'm puzzled.
Is this something intrinsic to the re-implemented DoC driver? Is "use docboot" the only right answer? Or should the block device abstraction work to the extent that Lilo should work, using BIOS services to load the kernel?
BTW, is docboot only intended for inftl devices, or does it work for nftl DoC's too?
Thanks for any ideas
Frank Rysanek
Quoted 3 lines · Frantisek Rysanek
first of all I'd like to apologize for asking for help while I still work with Linux 2.4 - I guess my problem could be unrelated to the minor kernel version.
:)
Quoted 5 lines
Is this something intrinsic to the re-implemented DoC driver? Is "use docboot" the only right answer? Or should the block device abstraction work to the extent that Lilo should work, using BIOS services to load the kernel?
Never tried lilo with DoC.
Quoted 2 lines
BTW, is docboot only intended for inftl devices, or does it work for nftl DoC's too?
Docboot seems to be written for and tested on INFTL devices, but it should be not that hard to make it work on NFTL DoCs.
Dan ??
tglx
Quoted 8 lines · Thomas Gleixner
Quoted 2 lines
BTW, is docboot only intended for inftl devices, or does it work for nftl DoC's too?
Docboot seems to be written for and tested on INFTL devices, but it should be not that hard to make it work on NFTL DoCs.
Dan ??
Yeah, this issue keeps coming up. I keep hoping someone else will volunteer, since I don't use NFTL-based devices anymore in my project. No such luck :(
However, since I keep claiming it should be easy to add this support to DOCboot, I'll go ahead and put something together over the next week or so.
-Dan