Tiny Core Base > TCB Talk
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
--- Quote ---I'm curious if the kernel could be modified a bit to hunt for init on external devices...
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
Go to full version