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

Let’s write a Kernel with keyboard and screen support (2014)

arjunsreedharan.org

Post reply on HN
Print view View original

21–30 of 40 posts

Re: Let’s write a Kernel with keyboard and screen support (2014)

#21

Post by peatfreak »

hazz99 wrote: post #11

For further reading, I can't recommend enough this free book: http://pages.cs.wisc.edu/~remzi/OSTEP/ It's fantastically well-written, yet detailed without being overwhelming.

I just read one chapter, which I thought was OK. It felt more like a book on how the C programming language translates to operating system concepts, rather than a book about the operating system concepts themselves. For example, the chapter I read discusses malloc() and indicates that it allocates memory from the heap, but it doesn't mention sbrk().

Re: Let’s write a Kernel with keyboard and screen support (2014)

#22

Post by meuk »

zaarn wrote: post #2

If anyone wants to breach into kernel development, I recommend osdev[0], which is a very good resources for beginners and others. 0: https://wiki.osdev.org/Main_Page

The forums are also excellent. They are a little bit like the Arch Linux forums: People can be a bit snarky, but pretty much everyone is extremely smart and pretty helpful. Noobs are tolerated if they are willing to put in some effort.

Re: Let’s write a Kernel with keyboard and screen support (2014)

#23

Post by pjc50 »

dschuetz wrote: post #16
adamnemecek wrote: post #3

I hate to sound dismissive but I feel like a lot of these projects put too much emphasis on booting and too little on something like say process semantics. I've written bootloaders before and it was some of the most uninspired code I've ever written.

You know, once a machine is running, you can do everything else that's limited by your own imagination. I've been trying to figure out how a powerpc machine is being booted so that I can insert my own 'hello world' OS. Sure there is a BIOS equivalent somewhere in there, but how to figure out how and when to talk to it? Booting x86 might seem like nothing, but booting some old SPARC for instance seems like black magic…

I guess it all depends on the documentation. Sun's is excellent e.g.: http://www.bitsavers.org/pdf/sun/sun3/Sun-3_Customer_Mainten... - on the Sun 3/60 you have a rather nice boot ROM which does similar things to UEFI but without the drama. It will let you netboot it over tftp, for example.

Which sort of PPC machine is it? Have you already managed to get e.g. NetBSD running on it?

Re: Let’s write a Kernel with keyboard and screen support (2014)

#24

Post by zaarn »

teddyh wrote: post #18

I may be wrong, but if you assume a non-ancient x86 platform with EFI BIOS, don’t you get all this for free from drivers included in EFI?

Not quite.

EFI will kill your program if it runs too long unless it disables a lot of the drives by exiting the boot environment.

Additionally, a lot of the EFI structures aren't intuitive or straightforward since they cover a lot of functionality, you'd still write a lot of code, probably more than the non-EFI variant.

Re: Let’s write a Kernel with keyboard and screen support (2014)

#25

Post by dschuetz »

pjc50 wrote: post #23
dschuetz wrote: post #16

Earlier quoted context omitted.

You know, once a machine is running, you can do everything else that's limited by your own imagination. I've been trying to figure out how a powerpc machine is being booted so that I can insert my own 'hello world' OS. Sure there is a BIOS equivalent somewhere in there, but how to figure out how and when to talk to it? Booting x86 might seem like nothing, but booting some old SPARC for instance seems like black magic…

I guess it all depends on the documentation. Sun's is excellent e.g.: http://www.bitsavers.org/pdf/sun/sun3/Sun-3_Customer_Mainten... - on the Sun 3/60 you have a rather nice boot ROM which does similar things to UEFI but without the drama. It will let you netboot it over tftp, for example. Which sort of PPC machine is it? Have you already managed to get e.g. NetBSD running on it?

Powermac g5 and/or power6. I got a CLFS kernel version 3.16 to boot and run (insanely fast) on the g5, but power6 is completely mysterious to me. There is some sort of RHEL linux based firmware running on it, but it seems there is no way to make it boot anything other than what's officially supported.

Re: Let’s write a Kernel with keyboard and screen support (2014)

#27

Post by nsajko »

zaarn wrote: post #19
pjc50 wrote: post #13

x86 16-bit real mode! It's certainly easy, but only because all the real work (initialising the PCI bus to speak to the video card, USB host drivers for the keyboard) is being done by the BIOS somewhere. Does anyone know these days if the 16-bit boot environment is still "bare metal", or is it inside an UEFI or ACPI hypervisor of some sort?

If you're on UEFI, the 16bit environment is very likely running inside a UEFI "hypervisor" (ie, it puts the CPU into 16bit mode after setting up the appropriate interrupt handlers and hardware drivers). If you boot Windows or Linux via UEFI and not BIOS methods, then you never leave 64bit mode during boot. Real BIOS that boots from 16bit is quite a rarity these days.

What if you have a UEFI motherboard with a BIOS bootloader like Syslinux?

Re: Let’s write a Kernel with keyboard and screen support (2014)

#29

Post by jjoonathan »

zaarn wrote: post #19
pjc50 wrote: post #13

x86 16-bit real mode! It's certainly easy, but only because all the real work (initialising the PCI bus to speak to the video card, USB host drivers for the keyboard) is being done by the BIOS somewhere. Does anyone know these days if the 16-bit boot environment is still "bare metal", or is it inside an UEFI or ACPI hypervisor of some sort?

If you're on UEFI, the 16bit environment is very likely running inside a UEFI "hypervisor" (ie, it puts the CPU into 16bit mode after setting up the appropriate interrupt handlers and hardware drivers). If you boot Windows or Linux via UEFI and not BIOS methods, then you never leave 64bit mode during boot. Real BIOS that boots from 16bit is quite a rarity these days.

Does UEFI start the same way as BIOS (firmware on LPC bus, PC starts at 0xFFFFFFF0)? Or is there a different top level mechanism?

My understanding was that the CPU still starts in 16 bit real mode (with an evil hack to sign-extend IP) but that by the time UEFI hands off to code on a hard drive it is in long mode.

Re: Let’s write a Kernel with keyboard and screen support (2014)

#30

Post by tenebrisalietum »

zaarn wrote: post #19
pjc50 wrote: post #13

x86 16-bit real mode! It's certainly easy, but only because all the real work (initialising the PCI bus to speak to the video card, USB host drivers for the keyboard) is being done by the BIOS somewhere. Does anyone know these days if the 16-bit boot environment is still "bare metal", or is it inside an UEFI or ACPI hypervisor of some sort?

If you're on UEFI, the 16bit environment is very likely running inside a UEFI "hypervisor" (ie, it puts the CPU into 16bit mode after setting up the appropriate interrupt handlers and hardware drivers). If you boot Windows or Linux via UEFI and not BIOS methods, then you never leave 64bit mode during boot. Real BIOS that boots from 16bit is quite a rarity these days.

"Running inside a hypervisor" is not equivalent to the UEFI setting interrupt vectors to point to its own code.

Not sure how UEFI's "Compatibility Service Module" works exactly but if it acts like the original BIOS did, it's just a chunk of code that can be called, either by a program or be set as the destination for interrupts.

But there is no "VM exit" mechanism like there is in hypervisors. One thing a hypervisor does is intercept IO address accesses and does them on behalf of the client code (without the code knowing), don't think the CSM is doing this.

Post reply on HN