Visopsys 0.91 - Return of the RAMdisk?

[qmastery]

Good day, Andy! How are you doing? Hope you are in a great health and everything is going well in your life.
Recently we've discovered that Lenovo G505S has bad IRQ routing in a coreboot BIOS, and found the way to fix it!
Now I've re-tested your special 2019-08-09 0.84 floppy with a RAMdisk support from https://visopsys.org/forums/viewtopic.php?f=3&t=338
and the results are really spectacular! Discovering this wasn't a Visopsys fault I'm really sorry I bothered you with debug logs a while ago ,
although it helped to resolve some other problems so it wasn't in vain. After adding the same floppy to a new coreboot BIOS G505S build as a RAMdisk
1) I'm able to access the HDD and see its' partition table
2) USB is working fine: tested a USB mouse and USB flash drive. Mouse also helped me to discover that a "Visopsys freeze problem"
was actually a touchpad breaking down on some conditions. under Linux, sometimes I'm seeing the messages like these at dmesg kernel log:

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 it seems that Linux (and KolibriOS) could find a way around this "broken hardware" since it's continuing to work under these OS.

Considering this great success:
Please, could you return the RAMdisk support (Visopsys floppy being used as a RAMdisk) at the next version of Visopsys?
I've tried your earlier suggestion of simply creating a "/ramdisk" at the floppy's root, it didn't work but maybe I misunderstood something?

[andymc]

Hi qmastery

That /ramdisk feature ought to still work, in theory. The code went into the latest release. But to be honest I doubt I tested it in the newer version. I'll have to give it a go here and see what it's doing. I'll need to look back at some of the guidance you gave me previously.

[qmastery]

I'll need to look back at some of the guidance you gave me previously.

Thank you. I just re-tested these instructions at https://visopsys.org/forums/viewtopic.php?p=1536#p1536 : almost everything works fine, except that ./cbfstool.sh for wgetting a minimal set of sources & building your own cbfstool (used for adding a floppy to coreboot.rom) - doesn't work anymore because a new version of it grew in dependencies. So you'd need to either trust the old cbfstool binary which I put to this archive 1 year ago, or git clone the whole coreboot repo for building it from source. Other than that, the only thing I needed to do is to remove a -localtime argument from a qemu.sh launch command (guess it depends on a qemu version)

Code: Select all

#!/bin/sh
# qemu.sh script
qemu-system-x86_64 -L . -m 256 -vga vmware -net nic,model=rtl8139 \
 -net user -soundhw ac97 -usb -usbdevice tablet -bios ./coreboot.rom -serial stdio

Hope this could provide you a smooth debugging experience and RAMdisk feature is just one inch from working again

P.S. I re-read your instruction and it says

So the current plan is: if there's a file /ramdisk in the boot floppy, the OS loader will load the entire boot medium into RAM, and pass a new kernel parameter to tell the kernel about it. The kernel will create a RAMdisk for this memory during initialization, which is treated the same as any physical disk, and the disk initialization code should be able to locate it as the boot disk.

My mistake was that I created a directory with the same name, but sadly replacing it with a file didn't activate RAMdisk

[andymc]

Hi qmastery, sorry for the delay. I haven't had much spare time lately, and I've been working on a couple of Visopsys things already that required all my attention. I got a minute just now and tried the /ramdisk. It seems like the RAM disk loading fails for me in the bootloader? The progress bar stops. Is that what you saw?

I wasn't trying the coreboot yet, just a floppy image booting into vmware with /ramdisk

[qmastery]

I got a minute just now and tried the /ramdisk. It seems like the RAM disk loading fails for me in the bootloader? The progress bar stops. Is that what you saw?

No, when a RAMdisk feature doesn't work - I see the error log identical on top of https://visopsys.org/forums/viewtopic.php?p=1536#p1536 thread, which ends with "Initialization failed. Press any key (or the "reset" button) to reboot."

I wasn't trying the coreboot yet, just a floppy image booting into vmware with /ramdisk

Since the vmware is using a different (their own proprietary) BIOS, the only quick way to reproduce this - is QEMU using a coreboot.rom image above as the BIOS. I hope the quick instructions above are working for you; if not - please let me know and I'll try my best to help you. I really hope that custom ramdisk code from your "2019-08-09 0.84" floppy, which ended up really working, hasn't been lost

[andymc]

Hi qmastery

Sorry again for being so slow. Lots going on around here. I also re-installed my OS on my dev workstation, to the latest Mint, and now I have to figure out why I can't build my sources with gcc 9 and the usual gcc-multilib package. It's rejecting my inline assembly bits, trying to build as x86-64

I re-read older stuff in our coreboot threads and saw that I was going to put your ramdisk boot feature into the 0.85 release, which it looks like I did. Have you tried that one?

The same code will have gone into 0.9, but I guess it's not working for some other reason I'll need to figure out (when I can compile again)

[andymc]

Argh. I've sorted out my differences with gcc 9, but the kernel it generates is about 10% bigger , so the filesystem gets filled up, and making a boot floppy is going to require some fancy footwork. If I can't get the latest gcc to make a smaller kernel, continuing to provide a boot floppy image is going to become less plausible.

[qmastery]

Hi there Andy,

I re-read older stuff in our coreboot threads and saw that I was going to put your ramdisk boot feature into the 0.85 release, which it looks like I did. Have you tried that one?

Yes, I think I tried your more recent floppy versions, but for some reason only your special 2019-08-09 0.84 floppy had this feature working. I wonder why it broke down and will be happy to assist you in debugging - and not just for this particular feature but for the others as well. It's just a lack of "live floppy" which is blocking me an easier & faster access to Visopsys, and after we resolve this - a Visopsys could be included to Mike's floppy-based hobby OS collection for coreboot-supported PCs, widening your audience

I've sorted out my differences with gcc 9, but the kernel it generates is about 10% bigger , so the filesystem gets filled up, and making a boot floppy is going to require some fancy footwork. If I can't get the latest gcc to make a smaller kernel, continuing to provide a boot floppy image is going to become less plausible.

Maybe you've already fixed that (I'm also a little slow in replying ), but - in case you still need some ideas, and LZMA compression is already used for a filesystem - I think it could be that some new options got added to gcc 9 which don't have a sane (size-optimized) defaults. I wonder if you could do a couple of builds with older & newer gcc with the debug info included to the build, and print this debug info to compare the sets of gcc flags used by old vs new gcc's

[andymc]

Hi qmastery

I've tried gcc down to version 7, which is the lowest binary version available from the mint repos, and the resulting binaries are smaller, but still much too large to build a working, graphical version of the OS that fits on a 1.44M floppy.

I've also tried various size optimization tricks that I've found online (some of which seem dubious) and still no joy.

All recent floppy versions of Visopsys have really strained the seams of a 1.44M floppy image, what with a 500K kernel, various programs and libraries, and bits of graphics (like icons) already pared down to a bare minimum working set. It seems like newer gcc versions (and the newest versions seem worser and worser) have given up much interest in producing small output, at least for 32-bit code.

Short of designing a build system that runs in VMs or containers (which seems like a lot of work and also a bummer) or requiring people to install particular old versions of gcc (another bummer), I don't see a good way through this. Compressing some things in the filesystem could also work, but ... yuck. Are 2.88M floppy images a possibility for you?

Lately in the limited time I've had, I've been focusing on getting software task switching working in the multitasker, as a prelude to x86_64 and UEFI booting. All of that stuff is in various stages of development. I'm not sure I want to hold things up indefinitely while I fight with the latest compiler to produce the same small binaries it used to make (I already pass it lots of args to try and get exactly the output I want, without a dedicated cross-compiler target, so I'm not convinced it's just a case of undesirable defaults slipping through).

[qmastery]

Compressing some things in the filesystem could also work, but ... yuck.

Yes, a compression - i.e. of filesystem's part not used while booting a kernel - could work: seeing that a LZMA-compressed Visopsys takes just 451KB, there's a really a room. But I understand the live decompression could be tiresome to implement even with some examples available online.

Are 2.88M floppy images a possibility for you?

Yes, since 2.88M floppies are supported by coreboot's SeaBIOS payload, I even tested a couple of rare 2.88MB floppy images found online and they booted fine. So, if you can build a more complete 2.88M floppy image (with a ramdisk support, for it to be able to boot) - I will be happy to test it as a part of BIOS on a real hardware. Luckily, since the IRQ routing got fixed, now more devices could become accessible to Visopsys and tested together.