Re: [OpenBIOS] [PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch

[Tarl Neustaedter]

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.

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.

[PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch

[Artyom Tarasenko]

On Tue, Apr 10, 2012 at 8:43 PM, Tarl Neustaedter  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.

The problem is currently OpenBIOS won't work on a bare metal, since
it's tightly coupled with qemu. So, PROM size at this point is a
purely academical question.
> 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.

So, basically, if OpenBIOS has to support FCode "dropin" images, it
must support the compression type (s?) used in OBP?

[PATCH 0/8] RFC: OFMEM cleanup/memory reduction patch

[Blue Swirl]

On Tue, Apr 10, 2012 at 18:43, Tarl Neustaedter  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.
>