Does this statement fair for all x86 systems? If yes? what is the reason?
For example, i have an image (.ifs file). Its size is about 2.3 MB with [compress=3] and 5 MB uncompressed.
If I boot from compressed image - system boots and works fine.
If I boot from UNcompressed image - system boots and there are error messages about devb-* drivers. There are no any other errors.
If there is a real size limitation of 3 MB uncompressed for OS image, why does my image works fine? Or maybe I just don’t see problems?
If you look at usr/include/sys/startup.h, you will see a block diagram for “Linear ROM XIP”. This has some application to the X86 disk boot process as well.
The “ROM” block in the diagram represents the binary “ifs” file you build, although 0x440 bytes for bios.boot will precede the startup header. Your ifs file is loaded by the boot process “as is” at address 0x110000 - THIS ORIGIN IS FIXED IN THE BOOTSTRAP!
The “RAM” block in the diagram is “built” by the startup code - it copies startup (and the microkernel) from the ifs image to a HIGHER address in RAM where it will begin executing. Note it “may” have to UNCOMPRESS the original image to RAM location where it must be ready-to-run.
startup_header.ram_paddr is the destination of the memory copy. (startup_header.image_paddr is the “relocated” address of the image - normally it matches ram_paddr.) The default RAM address is 0x400000. THIS SETS THE MAXIMUM SIZE for a BIOS-booted, x86 ifs file at 0x400000 - 0x110000 or 3.9375M. (Other boot methods and processors have other limits but approx 3M is maintained.)
To boot a larger .ifs file you must get mkifs to locate “ram_paddr” (and “image_paddr”) to a higher address. In the IDE System Builder, you can change the global property named “Image Address” to the desired location. You don’t want to set it unnecessarily high since the region reserved for the original image is likely excluded from use by the running system.