Page 2 of 2

Re: Detect the loaction of bootloader

Posted: Thu Nov 12, 2020 12:09 pm
by eekee
I recommend writing a little installer script. Automating repeated tasks can make a whole lot of difficulties easy. In this case, even a Windows batch file could run a simple tool to write the partition number to a specific location in the VBR, perhaps before the VBR is written to disk. Such a tool could be written in a few lines of C. Have it take a The script and the tool might need a little bit of debugging, but once that's done it's entirely out of the way and you can get on with other things.

Or you could have the VBR look for the active partition. I don't think that would play nice with Grub, but I don't imagine you have Grub on your USB stick. :) (There are boot managers which can set active partitions.)

Re: Detect the loaction of bootloader

Posted: Thu Nov 12, 2020 1:34 pm
by bzt
pranavappu007 wrote:The problem with me is I can't have a separate VBR as my VBR actually contains some "driver" code(actually more than that).
What has this to do with storing some LBA address in the boot sector? You can always have a separate VBR, see below.
pranavappu007 wrote:I might write a C program to modify the CHS/LBA location embedded in VBR to install to a partition, but not now.
Do that, that's what I and the others are saying :-)
pranavappu007 wrote:Even though I say "Boot loader" or "kernel", it is all linked(not concatenated but actually linked by linker) and is one giant Binary file which contains everything to boot up and give prompt.
That doesn't matter. As long as the remaining parts are loaded after the boot sector (0x7C00) into memory, you can store the rest anywhere on disk. For example:
VBR - LBA 10, loaded at 0x7C00 (by MBR or by BIOS)
kernel - LBA 128, 129, 130, loaded at 0x7E00 (by VBR)

But to install that, you'll definitely need a small C program to properly save everything onto a disk:
1. it should read your binary blob into memory
2. it should find a place to store it on disk (by interpreting the partitioning table and the file system or creating a new one, or could be an argument to your tool, LBA 128 in the above example)
3. it should save the binary blob there without the first 512 bytes (writing LBA 128, 129, 130 in the above example)
4. it should record that LBA (or CHS) address where it saved the binary in the first 512 bytes into the boot code's data area (LBA 128 in the above example)
5. finally it should write the first 512 bytes of the binary blob at the VBR (writing to LBA 10 in the above example)

When you install that on a partitionless disk, then you would simply write the binary blob (without the first 512 bytes) starting from the 2nd sector, save 2 into the boot code's data area, then finally write the VBR to the 1st sector. With partitions the process is the same, but you'll have different sector addresses, that's all.
eekee wrote:Or you could have the VBR look for the active partition.
I would recommend against that because the OP wants to load the 2nd stage (kernel) from partitionless images too.

Cheers,
bzt