Re: [ECOS] n00b PC booting questions

[Chuck McManis <cmcmanis at mcmanis dot com>]

At 10:32 AM 2/9/2006, Nick Garnett wrote:
> Sure you could do what you want with the rest of the disk. But if you
> want to run an existing filesystem then it will need a partition table
> and boot sector. Having a filesystem also makes installing new
> versions of RedBoot easy since you can just copy it on from a
> floppy. Otherwise you will need some sort of installation utility.

I understand this limitation, the flash is small (32MB) and I do not expect 
to have need of another file system. I am also concerned about efficiency 
where if I need to use every byte of flash for code formatting it as a FAT 
filesystem throws away about 10% of the flash to meta-data. (there is a 
"track" that is wasted, and the directory area). It may be that I have to 
go this route but as I've said, its a second choice.

> I'm not sure why you are set against using GRUB. It gives you
> everything you need straight out of the box. It will boot the CPU, put
> it into 32 bit protected mode, read the ELF executable from disk and
> run it. From a standing start you can probably have it all running in
> a couple of hours.

I'm not "set against it" I'm just trying to see if there is something that 
is inherently simpler to do. So I'm not arguing against GRUB, really I'm 
not, I'm looking for what is the simplest way to go from a standing start 
to code execution on my little Epia motherboard. I'll assume for now (I've 
not used grub before) that there is a way to configure grub to not generate 
any dialog and simply start up the application.

> Actually all it knows is how to read sector zero and execute it. The
> rest is left up to you.

Got that part, and I've ascertained that the processor is still in real 
mode and that no partition table is actually necessary if you have the 
correct 0xaa55 magic signature in the last two bytes of the sector. Writing 
a real mode program that then reads in a section of the disk (where the 
application is installed) and then jumps to it (the second stage boot 
loader) is also rather straightforward. Certainly the first 640K of RAM is 
"fair game" in terms of loading code into it and executing and it looks 
like much of the code expects to load/run in the above the 1MB "hole" in 
the address space.

> For someone who is "documentation challenged" you are taking a very
> documentation intensive route. Doing all the stuff necessary to get an
> executable off disk and into RAM using just the BIOS requires quite a
> lot of detailed knowledge of how the x86 CPU, the PC and BIOS work.

I'm thick that way ;-) One of the reasons I'm doing this is that I'm really 
tired of having someone else's bugs screw up my system. And I really don't 
like not understanding everything that is going on in the system so that 
when strange things do occur (and they always do) I can get to their root 
cause and fix them. I've been programming for over 30 years so I think I'm 
up to the challenge.

The interesting thing is that stuff like the x86 has lots of documentation, 
as do many of the specifications for the PC and BIOS. It just isn't 
centralized or perhaps everyone assumes you're just going to boot Windows 
or Linux and you don't need to know about that bit.

> It's a flash device that goes to a lot of trouble to make itself look
> like a disk device. Don't fight it.

This is a good point as well. Really I hear you on the simplicity of giving 
up on trying to understand how it gets booted and let someone else handle 
those details.

> So why spend a lot of time and effort on making a stand-alone
> bootstrap when GRUB will do it all for you? You can then get on with
> the real job.

Well I think getting it booted is part of the 'real' job ;-) At its heart 
booting is very simple (look at DOS for heaven's sake, and that FreeDOS 
reference Steva gave was excellent). By diving into this problem I am 
motivated to really internalize how Redboot works and what its limitations 
are and that helps me more clearly plan my next steps.

> For FLOPPY startup RedBoot, the entry point is implicit in the
> code. All others use a file format like ELF or S-Records, which
> contains the start address.

Yes, I should have twigged to this earlier, using objdump(1) I figured out 
the code in redboot.elf expects to be loaded into 0x108000. Where upon it 
sets up the address space. So it looks like if I switch into protected 
mode, set up the GDT for a flat address space, and then load the sections 
of redboot into the correct locations I can just vector to _start and the 
rest should just work.

I know, I know, Grub will do that for me. :-)

Getting lots closer, there are some comments that the GDB stubs when you 
set GRUB startup won't work over the network, is that still true? If it is 
I'll see if I can dig out my terminal server and set it up over where my 
test machine is.

Thanks for all the help Nick, I know I'm a pain and I apologize for that.

--Chuck


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss