* Re: Decompression error with silo and new kernel
1998-05-20 12:03 Decompression error with silo and new kernel Kris Boulez
@ 1998-05-20 12:12 ` David S. Miller
1998-05-20 12:20 ` Kris Boulez
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: David S. Miller @ 1998-05-20 12:12 UTC (permalink / raw)
To: ultralinux
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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Decompression error with silo and new kernel
1998-05-20 12:03 Decompression error with silo and new kernel Kris Boulez
1998-05-20 12:12 ` David S. Miller
@ 1998-05-20 12:20 ` Kris Boulez
1998-05-20 12:42 ` Jakub Jelinek
1998-05-20 19:54 ` John Gilmore
3 siblings, 0 replies; 5+ messages in thread
From: Kris Boulez @ 1998-05-20 12:20 UTC (permalink / raw)
To: ultralinux
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Decompression error with silo and new kernel
1998-05-20 12:03 Decompression error with silo and new kernel Kris Boulez
1998-05-20 12:12 ` David S. Miller
1998-05-20 12:20 ` Kris Boulez
@ 1998-05-20 12:42 ` Jakub Jelinek
1998-05-20 19:54 ` John Gilmore
3 siblings, 0 replies; 5+ messages in thread
From: Jakub Jelinek @ 1998-05-20 12:42 UTC (permalink / raw)
To: ultralinux
> 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).
___________________________________________________________________
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Decompression error with silo and new kernel
1998-05-20 12:03 Decompression error with silo and new kernel Kris Boulez
` (2 preceding siblings ...)
1998-05-20 12:42 ` Jakub Jelinek
@ 1998-05-20 19:54 ` John Gilmore
3 siblings, 0 replies; 5+ messages in thread
From: John Gilmore @ 1998-05-20 19:54 UTC (permalink / raw)
To: ultralinux
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread