This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: n00b PC booting questions


Chuck McManis <cmcmanis@mcmanis.com> writes:

> At 01:59 AM 2/9/2006, Nick Garnett wrote:
> >The main problem with the floppy boot code is that it renders the
> >floppy totally useless for any other purpose, since it overwrites all
> >the blocks that would contain the MBR and filesystem boot
> >sector. Doing the equivalent on a hard disk or a CompactFlash would
> >also render that device useless for any other purposes.
> 
> I hear what you're saying Nick but I don't exactly agree with it. My
> disagreement comes from your assertion that the device is "useless"
> for any other purpose. There is absolutely no reason at all that my
> code can't continue to use the device as a mass storage device, with a
> primitive file system of my own design.

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.

> 
> >Since in most embedded systems if you go to the effort of adding an
> >IDE device, you want to use it for something other than booting, what
> >we really require is a mechanism for booting eCos/Redboot out of a
> >filesystem.
> >
> >And we have one: GRUB!
> 
> Yes, after poking around I saw that GRUB booting was supported (Grub
> Legacy or Grub 2.0 ?) Rhetorical question since I'm not interested in
> using GRUB if I can avoid it.
>

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.

> So let's back up for a minute. On my embedded system I get IDE devices
> "for free" as I'm simply leveraging an existing design rather than
> rolling my own. Further, I've got some firmware in that system, BIOS,
> which already knows how to start up programming from a device attached
> to the IDE bus.

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

> 
> I'm documentation challenged as I'm not part of the "Secret Society of
> PC Developers" so for whatever reason manufacturers are loathe to tell
> exactly how their hardware works or what it is expecting, but they do
> adhere to generally established conventions and standards. This at
> least allows me to get part of the way there.

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.

> 
> Remember that at its heart, the disk on chip system is Flash, not
> disk, so treating it like a disk after I've booted is probably not the
> best idea (hence the plethora of flash file systems)

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

> further my system
> architecture is such that I have a "regular" disk for user data, and
> it will have a more standard file system, but the boot drive is really
> just for booting and initial software load.

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.

> 
> Since my original email, I've created a boot sector that reads sectors
> 2-n
> (where 'n' is poked into the boot sector at install time) into memory
> using the int 13h call that BIOS provides. I'm currently looking at
> telling Redboot to expect "RAM" startup and making sure that place
> where I load it is where it expects to be. Is there a vector to the
> start address stored in the first address of Redboot?

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.


-- 
Nick Garnett                                          eCos Kernel Architect
http://www.ecoscentric.com                     The eCos and RedBoot experts
Besuchen Sie uns vom 14.-16.02.06 auf der Embedded World 2006, Stand 11-222
Visit us at Embedded World 2006, NÃrnberg, Germany, 14-16 Feb, Stand 11-222


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]