Visopsys 0.91 - Return of the RAMdisk?

[andymc]

Hi Qmastery,

Ok, that sounds like the best solution for the time being -- making it 2.88. Of course the binaries I'm building now with GCC 9 have some kind of bug in them; they crash on kernel startup. I'm trying to debug that first. But also, I'm in the middle of moving house, so it'll be a little bit longer before I have time to sort it all out. When I do, I'll do a proper 0.91 release for it, with whatever fix might be needed for RAM disk booting.

Andy

[andymc]

Just an update: I'm experimenting with using clang now, in place of gcc. It looks promising, size-wise, but the kernel still crashes on startup, in what looks like the same sort of way. I think it's probably a linking issue.

[andymc]

I'm getting there, slowly. Yes, the newer GNU ld outputs a kernel executable that's quite different. Most notably, it has moved the read-only data out of the code section, and into its own loadable section. My BIOS OS loader isn't equipped; it's necessarily fairly simple-minded w/r/t ELF layout, as it only ever has to load a single, known file. I'll work on fixing that up, so that it works with both the older ld layout, and the new. Or at least the new!

[andymc]

Unfortunately, it gets worse. Even with a custom linker script, the kernel that I'm building is not usable as a kernel.

I think there's too much Linux optimization going on here now -- the latest GCC on Mint creates an executable that's effectively relocatable and requires runtime loader fixups (which the OS loader does not and should not do). This may be the reason for the inexplicably increased file size, as well.

I've tried further fiddling with the compiler args, but I'm not sure I can get this GCC to create the executable I need. I may have to finally bite the bullet and implement a GCC cross-compiler target for Visopsys. It's probably something I should have done a while ago; although after creation it has to be maintained, without it you're vulnerable to these changes.

Andy

[andymc]

Breakthrough!

I took the plunge and integrated a GCC cross-compiler into the Visopsys build system. I'm back to being able to build a working system, and the executable size problem is solved. I should be able to investigate this RAMdisk thing now, and should be able to (still) fit the result on a 1.44M floppy image.

In the end, I *think* the issue was PIE (position-independent executables) being on by default in the current GCC on my system. Had I understood that sooner, I probably could have solved my problems with a compile-time argument. But in the end, this is better, and probably something I should have done a long time ago. Now I'll be building with a compiler that's a known quantity, and be in complete control of what gets built (and linked).

[andymc]

I think I've got this whole RAMdisk booting thing sorted out now. I'm not quite sure why it stopped working between the custom version I made you, or version 0.85, or version 0.9, but anyway, I've made some fixes and hopefully improvements:

https://visopsys.org/files/misc/visopsy ... py-img.zip

Can you give this one a try if you're still following along with this thread? (I myself would probably have wandered off from boredom at this point, so I wouldn't blame you if you weren't!)

[andymc]

I went ahead and released version 0.91 with these fixes
https://visopsys.org/download/

[qmastery]

Can you give this one a try if you're still following along with this thread?

Hi there Andy! Sorry it took me such a long time to reach this thread and reply to you (my e-mail is flooded with spam and even if there were notifications I might have missed them). But finally I'm back and ready for more tests!

Thank you for releasing a new 0.91 version. While there is some progress (judging by the slightly changed error messages) - 0.91 floppy still doesn't boot as a virtual floppy inside a BIOS, neither on a real hardware nor in a QEMU. Please see both logs in the attachments.

However, maybe it's just an inch away from working. To reproduce these results with QEMU, you can use a convenient instruction+archive from my earlier post https://visopsys.org/forums/viewtopic.php?f=3&t=338 . Just run a

Code: Select all

./visopsys.sh ./path_to/visopsys-0.91-x86-floppy.img

after unpacking this archive, and after it a

Code: Select all

./qemu.sh

. If it complains about

Code: Select all

-localtime

option - please remove it from a script.

Hopefully this convenient QEMU workflow could help you to debug this problem further and finally defeat it

[andymc]

Hi Qmastery, no worries.

I will give those instructions a try. But just to double-check: you created the file /ramdisk in your floppy image? These error messages look like the kernel doesn't know it's supposed to be booting from a RAM disk.

Andy

[qmastery]

just to double-check: you created the file /ramdisk in your floppy image? These error messages look like the kernel doesn't know it's supposed to be booting from a RAM disk.

Oops, my bad - I totally forgot about this! Now, after I made this empty file on a floppy and updated it in a BIOS, it boots OK after giving a few errors:

Detecting hardware: PIC interrupt controller Warning::kernelInterrupt.c:intHandlerUnimp(83):
Unimplemented interrupt handler called
Detecting hardware: USB bus controller | Error::kernelInterrupt.c:kernelInterruptNextHandler(260):
| No next handler for interrupt 18
|--- x6 times total

Andy, thank you very much for adding the RAMdisk support to Visopsys! It delivers an unique ability of disk partitioning right from a BIOS - really awesome! Hopefully one day you'd stumble upon a coreboot-supported PC (list) and it would benefit you as well

Just got a couple of small ideas and wonder if they're possible to implement without too much effort:

1) Is there a way for Visopsys to detect that we're running as a RAMdisk, or - alternatively - to try booting as a RAMdisk if a regular boot didn't work? Asking because my friend Mike is going to add Visopsys into ./csb_patcher.sh script which - among the other things - lets the coreboot'ers to easily get various floppy-based OS, - and it will be wonderful if we could use a fresh Visopsys floppy as-is without repackaging it by ourselves

2) On some unlucky boots, an internal touchpad of a laptop might freeze at Visopsys very soon after boot. This is probably seen at Linux as:

Code: Select all

psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6
psmouse serio1: Touchpad at isa0060/serio1/input0 - driver resynced.

but Linux survives this problem and a touchpad continues to work. Interesting if Visopsys could detect it and try to fix by i.e. re-initializing this input device