Lylo: just another of my fool ideas

[AlfaOmega08]

I've had to many problems setting up Grub/Grub2 to work with x86_64 kernels. And I guess I'm not the only one here. Hence my idea of a new great bootloader, named Lylo (Lymph Loader, Lymph being my os). My plan is to extend the Multiboot Specification v1 to make the life of os-developers easier. In particular I'd like to extend the Multiboot Header and the Multiboot Information Structures to give a lot more informations about the machine to the os.

Features in my bootloader not present in the Mb v1 specification:
* Support for x86_64 images
* Long mode setup upon request in the Mb header
* Paging and higher half setup upon request
* Pic can be mapped by the boot loader
* PCI, ACPI, MPTables (maybe something other) are detected and enumerated and their pointers passed to the os image
* Cpuid informations for the BSP are read and passed to the os
* Any suggestion is appreciated

The multiboot info structure I'm planning to create is like this:

Code: Select all

struct MultibootInfo
{
  uint32 Flags;
  uint32 MemLower;
  uint32 MemUpper;
  /* other Mb v1 fields */
  uint16 VbeInterfaceLen;

  /* Additional fields */
  uint64 MemTotal;                     // Total size of Memory in bytes, rounded down the nearest page-boundary
  /* Flags[13] == true */
  uint64 PciDevices;                    // A table containing all the PCI devices on the machine. This way the Os is not required to perform the time-consuming pci-enumeration
  uint32 PciDevicesCount;
  /* Flags[14] == true */
  uint64 AcpiTables;
  uint32 AcpiTablesCount;           // A table with pointers to all the ACPI tables found on the system. 0 if no ACPI.
  /* Flags[15] == true */
  uint64 Processors;                    // A table containing informations about the processors on the system (Num of cores, number of threads, apic id, lapic address, etc)
  uint32 ProcessorsCount;
  uint64 MPTable;                       // A pointer to the MP table structure
  /* Flags[16] == true */
  uint64 Cr3Value;                      // If the loader was requested to setup paging, here is the (Pml4, Pdpt, PageDirectory) pointer
  /* Flags[17] == true */
  uint64 Cpuid;                           // A pointer to a structure with Cpuid-extracted data for the BSP
};

And here is the new header:

Code: Select all

struct MultibootHeader
{
	uint32 Magic;
	uint32 Flags;
	uint32 Checksum;

	/* Flags[16] == true */
	uint32 HeaderAddr;
	uint32 LoadAddr;
	uint32 LoadEndAddr;
	uint32 BssEndAddr;
	/* Flags[2] == true */
	uint32 ModeType;
	uint32 Width;
	uint32 Height;
	uint32 Depth;

	/* Flags[13] == true */
	uint32 PicBaseInt;               // Where the master pic should be mapped. The slave is mapped at PicBaseInt + 8
	/* Flags[14] == true */
	uint64 VirtualBase;             // If paging is requested, this is the base address to map (0xC0000000 and 0xFFFFFFFF80000000 are just examples)
};

A standard Mb v1 compliant bootloader would always be able to boot an os compiled using these structures, it would just ignore unknown flags...

Anyone is interested into this project?

[Solar]

My plan is to extend the Multiboot Specification v1 to make the life of os-developers easier.

In that case, the right place to go would be the GRUB project / the FSF, joining their mailing lists and making your suggestions there.

Simply forking something that was designed to be a standard in some other corner of the 'net is a "good" way to:

• p*ss off the designers of the original standard, reducing your chances of actually getting your suggestions merged into the official standard,
• reducing the value of both the original standard and your "extended" fork as both would be battling for support / acceptance.

Don't do it, at least until your suggestions are rejected by the standard maintainers and, after considering their arguments, you still think there should be an update.

Anyone is interested into this project?

As I said, ask the Multiboot maintainers first. It's their standard.

[b.zaar]

I would be interested in helping create a new boot loader but as Solar says you shouldnt extend the multiboot header. A better way would be to support mb1 and create a newer native data struct for this boot loader. I have a few ideas I'd like included in a boot loader and have started work on one of my own but would contribute to yours if it was open source.

[Solar]

Apparently I was not clear enough.

If you think extending on the Multiboot standard is a good idea, talk to the people who did the Multiboot standard. Instead of doing "custom boot format XYZ extending on Multiboot v1" you might be creating "Multiboot v2", see your suggestions become part of the Multiboot standard and be officially supported by GRUB et al.

[b.zaar]

I was thinking something totally different I'm not a fan of grub or multiboot but would support it because it exists. It's the same reason I would support fat12 but use ext2 or similar. I like the idea of blocks like the png image files use and planned to use it for inject which was already partly written in to venom.