visopsys.org

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

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

Thanks Ron, I hope you and yours have been keeping well. There's a new way to compile: first building a cross-compiling toolchain (binutils and gcc) from sources, as a kind of one-time operation. It's described in the updated BUILDING.txt. The vagaries of relying on whatever compiler configuration i...

Available on the download page. https://visopsys.org/download/ From the change log (https://visopsys.org/download/change-log/): Overview: This maintenance release fixes RAM disk boot support, adds sparse file support to the EXT filesystem driver, and updates various build-related things. Added suppo...

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

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/visopsys-2021-07-26-x86-flo...

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

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

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

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.