Detect the loaction of bootloader

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
User avatar
eekee
Member
Member
Posts: 891
Joined: Mon May 22, 2017 5:56 am
Location: Kerbin
Discord: eekee
Contact:

Re: Detect the loaction of bootloader

Post 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.)
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie
User avatar
bzt
Member
Member
Posts: 1584
Joined: Thu Oct 13, 2016 4:55 pm
Contact:

Re: Detect the loaction of bootloader

Post 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
Post Reply