How tiny can tiny be?

[CentralWare]

Hello everyone, it's your friendly neighborhood pain in the ash conjuring up yet another inquiry which I hope is not seen as a waste of time by most.  As I doubt this is being (or has been) attempted I'm asking this as more of a theory level; unless there are a few out there who have tried.

I have this image in my head regarding Processor "X" - no one chip in particular, just one that isn't in the repo to date.  Chip "X" whether it be MIPS, ARM, RISC, etc. is soldered to a board with "A" megs of memory, "B" megs of flash and ports available elsewhere for additional storage such as SD, USB, etc. which open the door to a virtual wealth of extensions, if only we can get that far.

Concept is to rip the kernel down to the bare-bones with the least amount of necessity just to get the device to boot, so beyond file system (dos/ext) and basic hardware, would it be (theory) possible to rip everything else to a modular state (encryption, etc. - anything NOT required to get that first heartbeat?)  Note: I understand encryption would be needed IF a storage item required TO boot was encrypted...  but let's assume up front there are no network storage, encrypted backups, etc. and also assume that IF such existed, we'd tend to them in a modular fashion once init was mounted.  Once we had this crushed kernel, it would be 'xx' megs in size.

The next step would be to repeat the same for the init (core) -- modular as can be as we might be crushing this entire package into a tiny flash of 4-8MB.  THIS would be the greatest challenge.

Once root was loaded, it's virtually useless to most degrees as it has very little functionality, and thus the modular concept.  From external device(s) we can then find out what the intentions for the project/device would be and load support accordingly.

Basically, I'm thinking of turning TC into an initial boot-strap and turning the "functionality" into tcz's.  If I'm guessing correctly, this would mean a stripped down core.gz, minimal busybox and term, along with the skeletal kernel.  Since most of these types of devices would be headless for the most part, a mini client such as Dropbear would likely be required, but could be done via storage instead of the image.

Can anyone take a grab as to just how low (in physical bytes) we might be able to go and yet achieve the outcome desired?

Thanks in advance for even giving this a moment to read, let alone any responses!

[Rich]

Hi centralware
About 5 or 6 years ago I built a stripped down 2.6 kernel and busybox and fit them on a 3.5" bootable floppy formatted to 1.68 megabytes.
I think there was about 200K of free space on the disk. I accessed the machine using netcat.

[CentralWare]

@Rich: Thanks for the insight!  It would be nice to see 3.x come together in that fashion, too!

I'm curious if the kernel could be modified a bit to hunt for init on external devices...  boot codes may or may not be an option depending on the hardware.  I'm thinking one of the biggest challenges will be the initial flash is going to be very limited in size (4MB~16MB generally speaking, and 16MB is likely too generous) thus if we have the means to embed the kernel into flash and the initrd/rootfs were hosted elsewhere (say, USB) this would solve so many potential issues with existing embedded devices.  Sadly, I'm inexperienced with kernel source (save for config/recompile) so I really don't know the inner-makings of how it's intended to operate at start-up, nor its capabilities during the start-up.

[Rich]

Hi centralware

I'm curious if the kernel could be modified a bit to hunt for init on external devices...

The boot loader tells the kernel where initrd is, look at extlinux.conf.

[gerald_clark]

Core is designed to NOT have the root filesystem on a drive.  If that is what you are seeking, you should probably look elsewhere.

[CentralWare]

@gerald: When referring to RootFS I'm referring to the core.gz which for TC is merely a compressed cpio OF the root file system; please forgive any misconception in that regard.  I'm not implying (nor would I want) an extracted/scatter mode type of installation as it defeats not only TC concepts, but would put the idea behind what I'm trying to accomplish to risk.  When updating the root file system, this should be a one-shot ordeal...  replace the image and viola'...  upgrade complete.  NOTE: There might be a couple scenarios where an extracted image is used instead of a compressed cpio...  such as MIPS boards which have a read-only (at run-time) flash where a compressed cpio would simply be additional work for the same outcome; in the end the result is the same - a clean root at every boot.  The binary images being sent to the devices are many times cpio in the first place, so zipping a zip doesn't really have much benefit.

@Rich: I'm guessing ext/syslinux isn't going to apply to all types of hardware (ie: RasPi being a configuration text file, though I haven't dug to determine what it uses for a boot loader) but yes, in a perfect world where everyone believes in standards it would be wonderful to just rely on boot codes...  something tells me it's not going to be that simple; though I hope I'm wrong!   LOL...  though with standards, what people agree on today will be argued tomorrow...

[bmarkus]

Majority of embedded systems (SBC) are using U-BOOT. RPi has its own bootloader, probably an U-BOOT derivate.