0

Das U-Boot is both first and second stage bootloader, as FSBL in a IBM-PC it must fit into the first 446 bytes (or less) before MBR in the first sector.

There is also a 1.5 stage boot loader that uses the FSBL code to read 31,744 bytes from disk and jump to it (sector 1 to 62, as DOS complience first partition can start in sector 63). I believe it is not the case of U-Boot.

I'm not looking for UEFI neither kexec alike, and I would rather if it doesn't require coreboot or other bootloader code, I have read it is possible but noone made it clear how.

Which config should I use? Chromebook Link or Edison? Will it generate a 446 bytes chunk to put in MBR? should I put something in sector 1 to 62? I believe it will not fit in 1.5 stage, how is it suppose to find the rest in disk?

Improve this question
1
  • Intel Edison has natively been using U-Boot. The issue with it that the binary (starting addresses, supported stuff, etc) is not so compatible with legacy firmware.
    – 0andriy
    Commented Oct 20, 2021 at 9:23

1 Answer 1

Reset to default
1

Although U-Boot supports x86 hardware, it does not include support for x86 BIOS firmware.

Therefore, the first step in using U-Boot on a legacy x86 PC would be to replace the BIOS with your own custom firmware that includes the first stage of U-Boot.

After you’ve done that, the old BIOS boot conventions like loading a 446-byte boot code from block #0 of the first hard disk won’t apply any more, and U-Boot’s conventions will be used instead.

Of course, replacing the BIOS requires that your custom firmware must first be able to handle the initialization of your system’s chipset, and testing and enabling the RAM after a cold start. On PC hardware, this can be a bigger challenge than you expected, as chipset programming documentation may not be easily available for all PC chipsets.

U-Boot is not a BIOS-compatible bootloader nor an easy drop-in replacement for BIOS; when its documentation says it supports x86, it only means that U-Boot can readily be integrated with hardware projects that use an x86 processor on custom hardware.

It looks like you’re perhaps confusing the terminology that was specific to GRUB Legacy (first stage, second stage, stage 1.5) with more generic systems design terminology for boot loaders.

In the systems design sense, on a legacy x86 PC with a goal of running Linux, the BIOS is the first-stage bootloader: it is arranged in ROM (or flash EEPROM) to be the first thing the processor will execute after a cold reset, and its job is to initialize the necessary hardware and load a relatively compact program from a fixed or otherwise well-defined location.

In the systems design sense, the entirety of GRUB would be a second-stage bootloader. GRUB Legacy is also divided in components that are called “stages”, but these are just internal divisions of GRUB that were created to work around legacy BIOS restrictions; GRUB stages are not the same as the systems design first/second stage bootloader terminology.

Improve this answer
3
  • Is that why it is said it would be possible as coreboot payload? But if it requires coreboot I could use the one without u-boot... What is the most lightweight bootloader that is BIOS compliance?
    – Tiago Pimenta
    Commented May 31, 2021 at 19:14
  • It seems barebox is a u-boot fork that is BIOS-compliance, someone with the same problem as I should take a look at it.
    – Tiago Pimenta
    Commented May 31, 2021 at 19:50
  • If you need a lightweight BIOS-based bootloader, the old LILO might also be worth a look.
    – telcoM
    Commented Jun 1, 2021 at 7:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .