lilo vs. diskonchip (again, sorry)

lilo vs. diskonchip (again, sorry)

[Frantisek Rysanek]

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

Re: lilo vs. diskonchip (again, sorry)

[Thomas Gleixner]

On Mon, 2005-03-14 at 18:06 +0100, Frantisek Rysanek wrote:
> 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.

:)

> 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. 

> 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

Re: lilo vs. diskonchip (again, sorry)

[Dan Brown]

Thomas Gleixner wrote:
>>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