Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a Bootloader

3zanders.co.uk

Post reply on HN
Print view View original

51–55 of 55 posts

Re: Writing a Bootloader

#51

Post by exikyut »

colejohnson66 wrote: post #5
d33 wrote: post #3

Earlier quoted context omitted.

I'd say yes. Especially if you mess with ACPI and, say, turn off the fans...

Modern processors just thermal throttle to the extreme if the heat can’t be dissipated, no?

Experience with an incorrectly heatsunk laptop GPU has demonstrated to me that the BIOS will yank power to the system if it hits 100°C.

Yeah.

Well, in all honesty I'm not sure if it was Linux, the BIOS, or some low-level thermal monitoring circuitry, but yeah, I one minute I was messing around with WebGL and the next minute I got confused about whether I'd forgotten the power cable. (Then I realized I hadn't heard any beeping (this was a ThinkPad and I didn't have the beeper muted) and realized it had overheated.)

Re: Writing a Bootloader

#52

Post by exikyut »

pmoriarty wrote: post #44

Any good articles about doing this in Forth?

I guess Open Firmware is the canonical answer. This of course compiles for x86. But it's massive and sprawling and not really designed for "can be easily grasped while leaving mental room to actually learn something" but rather for wide-spectrum support.

--

You of course already know about ColorForth (confident guess), which of course fits the bill here. Not quite "build an OS" and more "finished thing", but certainly hits the mark of "rapidly bring up new hardware functionality".

--

I just found 4os (article: https://news.ycombinator.com/item?id=12709802)

--

I found http://forthos.org/drive.html a little while ago but completely failed to get it going in QEMU (the CD image boots GRUB, but promptly hangs on loading). I haven't yet tested it with any other emulator, and haven't fed it to any actual hardware yet either.

HN article: https://news.ycombinator.com/item?id=2973134

--

There's also gfxboot, SuSE's approach to bootloader management.

This is a scary pile of assembly language (https://github.com/openSUSE/gfxboot/blob/master/bincode.asm - warning: 16k lines, large webpage) that parses an equally scary script grammar (see .bc files in https://github.com/openSUSE/gfxboot/blob/master/themes/openS...) that is heavily inspired by Forth (the stack/RPN grammar is right there) but also reminds me of Tcl as well (it uses a { } block syntax).

AFAIK this ships on the install media, and I also vaguely recall building it from scratch being very easy (I used SYSLINUX to bootstrap it).

--

This isn't quite an OS-dev thing, but I think it's fun: http://phrack.org/issues/53/9.html

Re: Writing a Bootloader

#53

Post by zanders3 »

current_call wrote: post #40

It’s probably easiest to download boot3.asm directly. This is kind of funny, since this is the only link that's broken. http://3zanders.co.uk/2017/10/13/writing-a-bootloader/boot3.... I tried to email the author, but I couldn't find his email anywhere.

Hello - author here :) A silly mistake I've fixed it now! http://3zanders.co.uk/2017/10/13/writing-a-bootloader/boot3....

Re: Writing a Bootloader

#55

Post by korethr »

duskwuff wrote: post #32
korethr wrote: post #31

Last line in this article mentions a Part 2, which will cover getting into Protected Mode. Which implies that x86 boxen are still to this day are POSTing in 16-bit real mode What I'm wondering, is whether this is because of the design of the firmware, hardware or both. Back when protected mode was the new hotness, it made sense for the CPU to power on in real mode, for backwards compatibilty. But back-compat w/ DOS i…

UEFI boot handles the real->protected (and ->long) transitions, so it's no longer necessary for the OS to handle it. EFI executables run in protected mode, with a memory mapping set up by the runtime. > Another thing I wonder about, is if it's possible to have the CPU come online directly in protected mode or long mode after POWER_OK has settled and the motherboard releases the reset line. No. The BIOS needs to perfo…

>> Another thing I wonder about, is if it's possible to have the CPU come online directly in protected mode or long mode after POWER_OK has settled and the motherboard releases the reset line.

> No. The BIOS needs to perform some touchy, hardware-specific initialization -- like detecting and calibrating RAM -- before releasing control to user code. It's not something you'd want the OS to be responsible for.

I think you misunderstood me. I didn't mention, and wasn't even thinking about the OS yet. As you said, UEFI handles the real->protected->long transitions. While the OS isn't loaded yet, and hardware initialization is being done, the CPU is still executing. What I'm talking about is setting the CPU's default power-on state, how it is before it begins executing even the boot firmware to initalize hardware and prepare to hand over execution to the OS.

By my understanding, when the power comes on, the motherboard waits for the PSU to assert POWER_OK. Once the PSU has done so, and POWER_OK has settled, then the mobo releases the CPU's RESET line, allowing the CPU to begin executing. At this point, the CPU is in real mode. What I am wondering is if the hardware can be configured so that once the motherboard releases RESET, the CPU is already in long mode, and begins executing the boot firmware. Is there something about the nature of pre-OS hardware initializtion that requires the CPU to be in real-mode to do this?

If CPUs could be coming online directly in long-mode, then perhaps the UEFI firmware could be simplified, since it doesn't need to handle the real->protected->long transitions anymore.

Post reply on HN