installing embedded os

If you run Linux, chances are good you use Grub as a bootloader. Grub understands the 'multiboot format' - basically a header you stick before your binary image which holds info about the type and size of your image, its entry point, etc. Grub reads the header, loads your image and jumps to your entry point.

Take a look at the multiboot specification for more info :

If your OS is written in C, you will at least need to provide some startup code to prepare the C-environment for your program: initializing the data section, cleaning the BSS, setting up a stack, etc. From this startup code you jump to your C-entry point (main?).

Also I can recommend using a PC-emulator like Qemu or vmware for doing this kind of work, this will speed up your development process considerably.

If you really want to do things the hard way, you can do without the standard C libary (don't forget your compiler and linker to omit those from the build, -fno-builtin, --nostdlib, etc).

If you really need C-library, there are several small alternatives especially ment for embedded systems. newlib or uClibc would be good candidates.

Have fun !

--
:wq
^X^Cy^K^X^C^C^C^C

What applications do you need on it? Do you have any linux kernel specifications? Do you have any specific device requirements?

A simple bootable flash disk can be as small as 32M.

Most libraries are dynamically linked, no need to waste memory space.

See:

What does BSS stand for? I know what it's for but I've never seen it written in its full form.

However, adding support for dynamic libraries to the 'small embedded os' the OP is writing is a non-trivial exercise. Even he wanted to go that route, it would only work for the user applications, not the kernel itself.

I second Ico's recommendation to use an emulator for experimenting. It makes it much easier to debug the initial steps of bringing the system up. Check out bochs

The kernel takes approx. 1MB, so it's no big deal for flash drives. It's a problem for floppy and CD (floppy boot image). But with 32M CF going for couple of dollars, I don't know why people still deal with floppy. The basic Dynamic C run-time libraries needs less than 16M. So, there are plenty of application space left. However, we do need

128M for the development environment. For about $15, 128M flash drives are not too expensive as well.

So, for approx. $20, you can compile on a 128M and run on a 32M.

So, I have solved my library issue. Now I really want to load my os on a flash drive and boot to it there. I know I could use an emulator, but this is more of a learning project I am wanting to do than a testing process.

What I have is the executable of my operating system that I have compiled using gcc with all libraries statically linked in. For now, I don't need to run any programs, everything is built in to the operating system and run as tasks from my scheduler. I just want to be able to put my executable on a flash drive and make the drive bootable so that it will run my os. Is that possible? Any docs I can read on how to do that?

In that case, you can just put the flash drive in the secondary cable. Format the D: drive with system image. Put in autoexec.bat loadlin your-operating-system-image

Using the flash drive in DOS FAT mode would make it easy to update changes.

I guess I forgot to mention something and wasn't too clear on something else. This is a USB flash drive I am trying to put it on. Second, I am in linux. If I can create the bootable flash without using windows, that'd be nice, but I am sure I can find a windows box if necessary. I'll start searching on how to make a bootable flash drive in windows, since it isn't as simple as a floppy.

Try SYSLINUX, it's easy to use. I've used this in x86 embedded systems before.

That's step 1.

Step 2 is to hack the kernel in the USB sub-system. It's not a trivial task, depending on the version. The Linux USB sub-system is a moving target.

Version 2.2 or earlier is impossible. Version 2.4 is possible. Version 2.6 is difficult (I am still working on this).

Unfortunately, I need the FTDI, SAA7134 and ATHEROS drivers on 2.6

What are you on about? He's not booting Linux! Step 2 is to make sure your BIOS (not Linux) supports booting from flash!

Failing that, I'm sure there are some fancy bootloaders out there that can do that for you (exists for ARM platforms so there must be some implementation for PCs).

___________________________________

But it will be easier to just start over , with a replacement for Linux and Windows . Then it would not be so much work to do anything .

Ill be working on a new O.S. that has no file system , no "Boot" , no text command line , no problems .. It boots its debugger in 10k of the loader , thus there is no boot ! It will load any o.s. , and if you like what it loaded , you can save that to flash .

it will be far less work to create this o.s. , because i will be eliminating excess bags , not adding new code . Thus it will be tiny .

Now , C programmers can say its impossible ,

because C programmers cant do a tiny powerful o.s. without a U-Bloat loader , thus NO ONE CAN . Duh !!

Its easy to write an o.s. 10 times better than Linux , in 1/10 th the time and in 1/4th the space ..

Yes he is, if you read his post carefully. He is building a custom Linux kernel task scheduler.

OK, step 3 is to make sure his custom kernel handles the USB drive properly.

Yes, but we all know/had some form of DOS/Open DOS somewhere.

I think you are reading more into his posts than is there. He mentions booting a small embedded OS but not linux. He mentions using linux but from context that just appears to mean that's his development platform.

Robert

OK, you guys might be right. In that case, he would have to rewrite the USB stack to handle the USB flash drive. Basically, re-inventing the Uheel (USB Wheel).

You may remove the word "might" from that statement. The OP

*specifically* mentions "writing his own" "small", "embedded" OS. Meaning "not linux" since linux wouldn't be "his own" nor would it be considered "small" by embedded programmers.

Not necessarily. If the BIOS or bootloader can boot from USB it for you then you don't need to even care about USB. His root filesystem need not be on the USB drive, just his OS executable image (I would have said kernel image but most small embedded OSes are just simple executives). Heck, most embedded OSes don't even have a concept of a filesystem much less requiring a root filesystem.

So again his best bet is to use a BIOS and/or bootloader capable of booting from USB. I know my BIOS can boot from a USB drive but I don't know much about bootloaders apart from embedded bootloaders like Redboot and APEX.

That would be tough to do. To run the BIOS code, you must be in 16 bit mode. The OP is using gcc. I am not aware of any recent 16 bit gcc. You can boot 32 bit OS in BIOS. But once you are booted, you are on your own.

Normally, you'd write an assembly startup file. The gas assembler supports a '.code16' directive to generate 16 bit instructions. This startup file can then switch to 32 bit protected mode.

Look at arch/i386/boot/setup.S in a modern linux kernel source tree for an example.