On Mon, 15 Jun 2009, David Miller wrote:
From: Robert Reif <reif@xxxxxxxxxxxxx>
Date: Sun, 14 Jun 2009 08:59:50 -0400
Would it be possible to use silo to load the kernel at its
final destination like the sun bootloader aparently does?
This seems so simple that I can't believe it hasn't been
done before so there must be issues with this approach.
The relocating does not actually physically move the kernel code. It just
re-arranges the virtual memory map.
On a sun4c SparcStation 1 or 2 the boot prom may not allow the kernel to
be directly loaded to its final destination address. The mappings on my
SS1/SS2 are lower 16M only mapped at boot time however this may just be
that the boot loader did not request an alternate mapping.
Can anyone please give me some feedback?
We just never implemented this way because there was never
a need for such complexity. Originally the kernel was A.OUT
and we need to support relocation for the sake of network
booting anyways.
You will need to make the relocation case work for the sake
of net booting no matter what. Otherwise large kernels will
work for SILO boots but not for networking boots, which
eliminates an installation scheme for a whole class of users.
Why not simply make the relocating code move more than 3MB
of mappings to the final location? What prevents that from
working?
Making the relocate size bigger worked for sun4c with the some what
limited capabilities of the SunOS 4.1 A.OUT loader last time I tried a new
kernel. It is the only way I found of using a sun4c Linux kernels from
about 2.6.16 to 2.6.23 (work got in the way so I have not done any testing
of more recent kernels). I can't think of anything that will prevent it
from working with more recent kernels.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
