Feature request: support booting from memory mapped ISO

[Icecube]

Feature request: support booting from memory mapped ISO or support reading additional files from a cpio archive (memory mapped) (initramfs).

Would it be possible to support a ramdisk based filesystem?
MEMDISK of Syslinux can boot ISOs and floppy images (and provides INT13h access to this memory mapped disks).
This INT13h access will be lost when the Visopsys kernel is booted and tries to read the additional files.

This would be useful for including Visopsys or Partition Logic in existing bootable rescue projects in the form of an ISO or bootable USB stick.

memdiskfind.c contains info about how to detect the mBFT structure in the first MB of RAM:
http://git.zytor.com/?p=syslinux/syslin ... e9d532636f

ifmemdsk.c32 is a com32 module for Syslinux that is also able to detect MEMDISK:
- can also use the INT13h installation check (doesn't work for ISOs)
- mBFT scanning ==> recommended (works for floppy, hard disk and ISO
emulation), but you need a "recent" MEMDISK version (3.86 or higher, I think)
- Displays parameters passed to the MEMDISK (MEMDISK is in linux kernel format) append line (so might be useful to pass info to Visopsys)
http://git.zytor.com/?p=syslinux/syslin ... e9d532636f

Mdiskchk.com can use the same detection method as ifmemdisk.c32 (but made for DOS):
http://git.zytor.com/?p=syslinux/syslin ... e9d532636f

Alternatively, support for cpio as filesystem (initrd) so all Visopsys files can be stored inside a cpio archive, would be nice, to be able to load them directly with an INT13h based bootloader.

A few days ago, plans for Syslinux variant that is able use a cpio archive as initrd, appeared:
http://www.syslinux.org/archives/2011-S ... 16903.html

Syslinux has also a elf.c32 module, but currently fails to load the Visopsys kernel:

Code: Select all

LABEL visopsys
COM32 elf.c32
APPEND visopsys

Code: Select all

Memory segment at 0xc0000000 (len 0x0006b548) is unavailable
Invalid ELF file or insufficient memory
boot:

any idea why this is the case? Could it be related to this:

;; For the code segment, we simply place it at the entry point. The
;; entry point, in physical memory, should be KERNELCODEDATALOCATION.
;; Thus, all we do is move all code forward by CODE_OFFSET bytes.
;; This will have the side effect of deleting the ELF header and
;; program header from memory.

Syslinux is able to read files from ext2/3/4, fat12/16/32, ISO9660 and very soon also NTFS (now in test fase).
If the Visopsys kernel could be fixed so elf.c32 can load it properly (assuming that the problem is in the kernel), Syslinux could be used to support loading Visopsys from unsupported filesystems.

[Icecube]

At which address does vloader load the visopsys kernel. AFAI can tell, vloader skips the paddr field of the kernel.
I think elf.c32 of Syslinux, reads that address and tries to place the kernel at 0xc000000 (= 3 221 225 472 in decimal), but qemu has only 128MiB of memory available for the VM, and the loading will fail.

[andymc]

Hi Icecube,

Visopsys already supports RAM disks, but not as boot disks (yet). I haven't checked out those links of yours yet, but do they describe a method for setting up a RAM disk pre-kernel, and a way for the kernel to search for, and identify that? If so, that would probably be pretty easy for me to implement (the RAM disk driver could 'detect' such things during hardware detection, and register it with the kernel as a normal disk).

In the upcoming release, the bootsector/bootloader passes a boot sector signature, and then when the kernel has loaded, it examines all the disks it has detected to figure out which one it booted from (in the last release, the loader tells the kernel explicitly, but that was unreliable for various reasons).

Visopsys doesn't have the concept of an initrd for booting, a la Linux; the kernel ELF binary gets loaded into memory, and passed some bits of system info from the loader, and then it proceeds to do all of its own setup - detecting hardware, enumerating filesystems, loading the other parts, etc.

The kernel gets loaded by the loader at physical address 1Mb, using virtual address 0xC000000. The virtual address is specified at link time when the kernel is built (these are pretty standard values for OS kernels). The amount of physical RAM shouldn't matter as long as there's at least a couple of megabytes of physical RAM - the 0xC0000000 is virtual (the last gigabyte of the standard 4GB address space of x86 processors)

[andymc]

PS> Visopsys kernel really shouldn't be loaded explicitly by a 3rd party tool - it expects certain things that are done for it by the Visopsys OS loader (such as switching to protected mode, setting up paging, descriptors, passing hardware info, etc). Instead, the Visopsys boot sector should be "chain loaded" the way you would do with a DOS/Windows boot sector. Load the first sector at physical address 0xC700 and jump to it, preserving registers like DX and SI that the BIOS passed to the previous boot sector.

[Icecube]

Visopsys already supports RAM disks, but not as boot disks (yet). I haven't checked out those links of yours yet, but do they describe a method for setting up a RAM disk pre-kernel, and a way for the kernel to search for, and identify that?

Yes.

See the INT13h subsecton on the MEMDISK page for more info (Windows drivers for MEMDISK are WinVBlock and Firadisk; Linux driver is phram + memdiskfind):
http://www.syslinux.org/wiki/index.php/ ... pletely.21 (I can't reach it now, but google cache works)

Visopsys kernel really shouldn't be loaded explicitly by a 3rd party tool - it expects certain things that are done for it by the Visopsys OS loader (such as switching to protected mode, setting up paging, descriptors, passing hardware info, etc). Instead, the Visopsys boot sector should be "chain loaded" the way you would do with a DOS/Windows boot sector. Load the first sector at physical address 0xC700 and jump to it, preserving registers like DX and SI that the BIOS passed to the previous boot sector.

elf.c32 setups 32-bit protected mode AFAIK. Did you ever look at the multiboot specification? It is designed to make it easier to develop a kernel, without writing a bootloader from scratch.
http://www.gnu.org/software/grub/manual ... iboot.html

[costello]

<spam deleted>

[andymc]

Dunno mate, perhaps you should ask your question in some Windows-related forum.