Decompression error with silo and new kernel

Decompression error with silo and new kernel

[Kris Boulez]

After having installed the latest ultrapenguin release I wanted to
compile a new kernel. I couldn't find any (ultra)sparclinux specific
docs about this, so I used my Intel/PMac knowledge about Linux. I did 
the following

- make kernel as usual
- copy and gzip the resulting vmlinux file (tiens, it is not located somewhere 
  deep down in the arch hierarchy this time) to /boot
- edit /etc/silo.conf to add a new target
- reboot

I get the error "Decompression error: uncompressed image too large - 
		 wouldn't fit into destination"

/etc/silo.conf
timeoutP
partition=3
root=/dev/sda1
image=/boot/vmlinux-2.1.102
        label=linux102
        root=/dev/sda1
        read-only
image=/boot/vmlinux-2.1.99.gz
        label=linux
        root=/dev/sda1
        read-only

# ls -l /boot/vml*
-rwxr-xr-x   1 root     root       987827 May 20 08:31 /boot/vmlinux-2.1.102.gz
-rw-r--r--   1 root     root       938796 May  2 20:56 /boot/vmlinux-2.1.99.gz
-rw-r--r--   1 root     root       966315 May  2 21:20 /boot/vmlinux-smp-2.1.99.gz
lrwxrwxrwx   1 root     root           17 Feb 19 19:53 /boot/vmlinux.gz -> vmlinux-2.1.99.gz


Uncompressing the kernel by hand doesn't solve the problem : "Image too large
to fit in destination"

Kris,
-- 
Kris Boulez				kris@belbone.be

Re: Decompression error with silo and new kernel

[David S. Miller]

   Date: 	Wed, 20 May 1998 14:03:59 +0200
   From: Kris Boulez <kris@belbone.be>

   image=/boot/vmlinux-2.1.102

s/102/102.gz/

Later,
David S. Miller
davem@dm.cobaltmicro.com

Re: Decompression error with silo and new kernel

[Kris Boulez]

Quoting David S. Miller (davem@dm.cobaltmicro.com):
>    Date: 	Wed, 20 May 1998 14:03:59 +0200
>    From: Kris Boulez <kris@belbone.be>
> 
>    image=/boot/vmlinux-2.1.102
> 
> s/102/102.gz/
> 
I already did that, this is just a remainder of one of my attempts to
cure the problem (silo finds the kernel without any problem and
starts decompressing).

Kris,
-- 
Kris Boulez				kris@belbone.be

Re: Decompression error with silo and new kernel

[Jakub Jelinek]

> After having installed the latest ultrapenguin release I wanted to
> compile a new kernel. I couldn't find any (ultra)sparclinux specific
> docs about this, so I used my Intel/PMac knowledge about Linux. I did 
> the following
> 
> - make kernel as usual
> - copy and gzip the resulting vmlinux file (tiens, it is not located somewhere 
>   deep down in the arch hierarchy this time) to /boot
> - edit /etc/silo.conf to add a new target
> - reboot
> 
> I get the error "Decompression error: uncompressed image too large - 
> 		 wouldn't fit into destination"

You have compiled everything in, haven't you?
Current SILO is not able to load images larger than 2.5M-16384.
So, for now, modularize your kernel a bit. I will in the mean time try to
think how to make SILO able to handle larger sizes (but there will probably
be a limitation 3M-100K even then). The problem is SILO is statically linked
to 0x280000 address, which is caused by old Suns where they guarantee only
3M of contiguous mapped memory.

Cheers,
    Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
Ultralinux - first 64bit OS to take full power of the UltraSparc
Linux version 2.1.102 on a sparc64 machine (498.80 BogoMips).
___________________________________________________________________

Re: Decompression error with silo and new kernel

[John Gilmore]

> So, for now, modularize your kernel a bit. I will in the mean time try to
> think how to make SILO able to handle larger sizes (but there will probably
> be a limitation 3M-100K even then). The problem is SILO is statically linked
> to 0x280000 address, which is caused by old Suns where they guarantee only
> 3M of contiguous mapped memory.

It was very easy to make SPARC machine code location-independent, at
least in the v7-v8 days, particularly if you only need to relocate it
on large boundaries (e.g. move it in 64K or 16MB increments).  GCC can
generate such code (for shared libraries).  SILO is probably a small
enough program that making it able to relocate itself to avoid the
memory of the incoming kernel is possible without much work.

Another alternative is to have it decompress the kernel image into
available (high) memory, then use a small location-independent loop to
copy it into its final resting place.

A third alternative would be to remap the virtual address space to do
the same thing, avoiding the final memory-to-memory copy.  The kernel
should be able to handle starting itself up from *any* set of physcial
memory pages (i.e. it can't assume that it's in low physical memory --
low phys memory might be broken, so the ROMs are designed to allocate
other memory to low virtual addresses in that case).

If you want the kernel to end up in low *physical* memory as well as
low *virtual* memory, one thing you could do is relocate SILO in physical
memory as it starts.  Copy SILO into non-conflicting physical memory,
change the VM to map the new copy of SILO instead of the old one,
change the VM to map the kernel's low physical memory location into
contiguous (high) virtual addresses, decompress it into there, then
reset the VM to a nice flat map and jump to the kernel.  You'd still 
have to only use the physical page frames that the ROMs had handed you,
rather than assume that all memory from location 0 exists and works.

	John