[OpenBIOS] [PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch
blauwirbel at gmail.com
Tue Apr 10 21:06:43 CEST 2012
On Tue, Apr 10, 2012 at 18:43, Tarl Neustaedter <tarl-b2 at tarl.net> wrote:
> On 2012-Apr-10 13:41 , Blue Swirl wrote:
>> Yes, but again, image size savings are not very interesting. Savings
>> in image loading time is easily lost during decompression.
> Why do you think image size saving aren't interesting? Certainly in the past
> couple of decades of Openboot development, we've several times been severely
> squeezed by prom sizes - in some cases, we had to rip out functionality to
> be able to fit in our PROM.
Yes, but in the virtual world, the images are just files. Not even
very big files these days, a million PROM images could fit in a hard
disk. The sizes of boot flash memories (executable) are also several
orders of magnitude larger than PROMs of old times.
The CPU cycles used for decompression waste time, energy and thus
money each time the (virtual or real) machine is booted. Maybe using
this logic, it would be worthwhile to invest in larger PROMs in real
machines, for some customers at least.
> For what it's worth, Openboot currently compresses the "dropin" images
> (FCode standalone images for devices) before assembling them into the PROM
> image, and decompresses those when they are brought in with find-dropin.
IIRC PC BIOS was often banked, with only a part of the flash visible
at end of memory. That way for example POST (not needed after boot)
could be hidden. The reason was not PROM size, but the size of the
address space window available in real mode, 128k.
> OpenBIOS http://openbios.org/
> Mailinglist: http://lists.openbios.org/mailman/listinfo
> Free your System - May the Forth be with you
More information about the OpenBIOS