Visopsys 0.83 - [OLD THREAD] init failed (virtual floppy at coreboot/SeaBIOS)

[qmastery]

Finally I put Visopsys 0.83 inside that open source coreboot BIOS of AMD Lenovo G505S laptop - https://visopsys.org/forums/viewtopic.php?f=3&t=281 - and tried booting it ! However I am getting the errors below (re-typed from a screen by hand), - and I can help you to debug them if you could provide your instructions :

Code: Select all

Visopsys 0.83
Copyright (C) 1998-2018 J. Andrew McLaughlin
Starting, one moment please...

Detecting hardware: SATA disk controller Error::kernelSataAhciDriver.c:issueCommand(1404):
Command failed - timeout
Error::kernelSataAhciDriver.c:detectDisks(1587):
Identify device command failed for port 0
Error::kernelSataAhciDriver.c:issueCommand(1404):
Command failed - timeout
Error::kernelSataAhciDriver.c:detectDisks(1587):
Identify device command failed for port 1
Error:kernel process:kernelFloppyDriver.c:waitOperationComplete(180):
Command timed out
Error:kernel process:kernelFloppyDriver.c:readWriteSectors(566):
Seek error: Unknown error
Error:kernel process:kernelDisk.c:realReadWrite(400):
Error -24 reading 1 sectors at 0, disk fd0
Error:kernel process:kernelFloppyDriver.c:waitOperationComplete(180):
Command timed out
Error:kernel process:kernelFloppyDriver.c:readWriteSectors(566):
Seek error: Unknown error
Error:kernel process:kernelDisk.c:realReadWrite(400):
Error -24 reading 1 sectors at 0, disk fd1
Error:kernel process:kernelDisk.c:identifyBootDisk(2081):
The boot device could not be identified
Error:kernel process:kernelInitialize.c:kernelInitialize(351):
Disk functions initialization failed
Error:kernel process:kernelMain.c:kernelMain(90):
Initialization failed.  Press any key (or the "reset" button) to reboot.

[andymc]

Hi again qmastery

Well, one thing I can see there, is that different drivers - all for disks and disk controllers, but that's just what's happening at that point of the boot - all seem to be getting timeouts. That seems to suggest a problem receiving interrupts. I assume there's no /system/kernel.log file because of this

Does Visopsys boot on this machine in any other boot configuration, such as from a USB stick? I'd be interested to see what it thinks is going on with the interrupt controllers. PIC? APIC? etc.

Also, are there any constraints about what kind of code can run within this firmware environment? Is it OK/possible to do things like take over control of various bits of hardware? (such as the interrupt controllers, say)

Andy

[qmastery]

are there any constraints about what kind of code can run within this firmware environment? Is it OK/possible to do things like take over control of various bits of hardware? (such as the interrupt controllers, say)

Hi Andy,

There are completely no restrictions: after SeaBIOS jumps to a "virtual floppy" it has complete control over PC and can do anything. I also tested some other floppy-based OS as the virtual floppies inside this BIOS (i.e. KolibriOS) and they work relatively fine aside from some driver incompatibilities (e.g. KolibriOS USB and SATA are buggy)

I just tested Visopsys again at the same laptop/BIOS, but now booting from a USB stick.
Visopsys gave me exactly the same beginning of error log as above, but instead of this ending part from the previous log:

Code: Select all

Error:kernel process:kernelDisk.c:identifyBootDisk(2081):
The boot device could not be identified
Error:kernel process:kernelInitialize.c:kernelInitialize(351):
Disk functions initialization failed
Error:kernel process:kernelMain.c:kernelMain(90):
Initialization failed.  Press any key (or the "reset" button) to reboot.

it boots successfully to the welcome screen! Although I noticed that if you'd stay on this welcome screen for some minutes the computer will freeze, but after I click "Continue" I could work in this OS for a long time without freezing

It seems to me that this

Code: Select all

Error:kernel process:kernelDisk.c:identifyBootDisk(2081):
The boot device could not be identified

is the main problem that causes to fail kernelInitialize(351) and kernelMain(90). Please could we just print a warning message for the identification of BootDisk and just continue booting from it? And if you could make a special build with this identification changed as "error -> warning", or - if it's absolutely necessary - which prints more debug info for it - then I could test it as a part of my BIOS again

EDIT: /system/kernel.log is attached! Perhaps this is what we'd get if we treat identifyBootDisk failure as warning not error

Best regards,
qmastery

[qmastery]

.

It seems that PorkChops had a similar problem:

https://visopsys.org/forums/viewtopic.php?f=4&p=1433

[andymc]

It seems to me that this

Code: Select all

Error:kernel process:kernelDisk.c:identifyBootDisk(2081):
The boot device could not be identified

is the main problem that causes to fail kernelInitialize(351) and kernelMain(90). Please could we just print a warning message for the identification of BootDisk and just continue booting from it? And if you could make a special build with this identification changed as "error -> warning", or - if it's absolutely necessary - which prints more debug info for it - then I could test it as a part of my BIOS again

Thanks! I think that log file has got to be from a successful run, where you got to the desktop. That message about failing to identify the boot device is completely fatal - it doesn't know what to boot, where to find the root filesystem, etc. Or, more specifically, it has been told what media to boot from, but can't read from it.

My theory about not getting interrupts on this machine seems shaky, if it can get them from the EHCI USB controller. However, the APIC interrupt controller code is relatively new, so that seems like a reasonable place to look for problems of this type. There have been some problems here and there.

[andymc]

It seems that PorkChops had a similar problem:

https://visopsys.org/forums/viewtopic.php?f=4&p=1433

It's the same symptom/error message, but I suspect that it was a different cause in that case.

[qmastery]

It seems to me that this

Code: Select all

Error:kernel process:kernelDisk.c:identifyBootDisk(2081):
The boot device could not be identified

is the main problem that causes to fail kernelInitialize(351) and kernelMain(90). Please could we just print a warning message for the identification of BootDisk and just continue booting from it? And if you could make a special build with this identification changed as "error -> warning", or - if it's absolutely necessary - which prints more debug info for it - then I could test it as a part of my BIOS again

Hi Andy, perhaps I guess why Visopsys can't boot as a "virtual floppy" aka "ramdisk" inside coreboot+SeaBIOS, but could boot relatively fine to desktop (if we don't count those other error messages) if the same image is booted from USB.
It seems that Visopsys boot process is the following: first the kernel loads, and - after it loads - it tries to locate the media from which this kernel has just booted, and when it couldn't find it - expectable if it doesn't know about "ramdisks" - then it fails.
There was a similar problem with Fiwix , please check this post - https://github.com/mikaku/Fiwix/issues/ ... -450304007 - and it was eventually solved after Mikaku has added the "initial ramdisk support" for the kernel.

Is it possible to do something similar for Visopsys? If yes, that would open a road to me for more Visopsys debugging / testing / bugreporting and I will be able to easily test all your new builds by using a couple of cbfstool / flashrom commands to update Visopsys floppy inside the BIOS.

Wish you a Happy holidays!

Cheers,
qmastery

[andymc]

Hi qmastery

You've correctly described what the kernel does when it boots - the loader passes a media signature of the boot device, and once the kernel has initialized its disk drivers, it looks around for that thing.

The Visopsys kernel does have a ramdisk driver. Normally you request the creation of a ramdisk (allocates memory, etc) but I could add a function that takes existing memory and uses that.

I'd also have to add an extra kernel parameter to pass a memory address instead of a media signature, but again that's a minor change.

The difficulty as far as I can tell is for the loader to know that it's really loading from a 'virtual' disk, and not a physical floppy. Does coreboot have some hook, that a loader can detect this scenario?

Andy

[andymc]

I should add that I've never been attracted to the initial ramdisk idea that Linux uses (and Visopsys was never intended to be a Linux/UNIX lookalike) and there's no "kernel command line" to pass text arguments via Grub and friends.

I get that the initrd concept does allow for a lot of flexibility in terms of boot environments, etc., but I'm not fond of all the requirements and constraints that it introduces - the kernel requires an initrd, and an initrd has to have x, y, z in it, and be the correct version, and so on.

I prefer that the loader loads the kernel into memory, provides some information, sets up a few things that the kernel can't easily do for itself, and then the kernel pulls itself up by its own boot-straps, so to speak.

[qmastery]

The Visopsys kernel does have a ramdisk driver. Normally you request the creation of a ramdisk (allocates memory, etc) but I could add a function that takes existing memory and uses that.

I'd also have to add an extra kernel parameter to pass a memory address instead of a media signature, but again that's a minor change.

The difficulty as far as I can tell is for the loader to know that it's really loading from a 'virtual' disk, and not a physical floppy. Does coreboot have some hook, that a loader can detect this scenario?

Hi Andy, although I am not aware of any such hook, maybe it could be done the following way: if Visopsys can't find a boot media from which it has just booted, instead of "failure" it would try to switch to that memory address as a last resort because there's nothing to lose at this point, and in case of being a part of "coreboot+SeaBIOS" Visopsys will be able to continue booting successfully

I prefer that the loader loads the kernel into memory, provides some information, sets up a few things that the kernel can't easily do for itself, and then the kernel pulls itself up by its own boot-straps, so to speak.

Although Fiwix uses GRUB, there are some hobby OS like MikeOS ( http://mikeos.sourceforge.net/ ) / MichalOS ( https://sourceforge.net/projects/michalos/ ) / tatOS ( https://github.com/tatimmer/tatOS ) which are using their simple custom bootloader and are successfully working as "ramdisk"