| Message ID | 4A325654.3050201@earthlink.net |
|---|---|
| State | Accepted |
| Delegated to: | David Miller |
| Headers | show |
Robert Reif wrote: > This patch changes the location that second is loaded to make room for > larger kernels. I forgot to mention that this patch has been boot tested on a sparcstation 20 and an ultra 60. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Robert Reif wrote: > This patch changes the location that second is loaded to make room for > larger kernels. > > On sparc32 a kernel is loaded at 0x4000 and second is loaded > at 0x280000. That means that the largest kernel that can be loaded > is 0x27c000 (2605056) bytes. Sparc32 kernels have been larger > than that for years and it has recently been almost impossible > to strip down a kernel small enough to actually load. > > OBP initializes 3 megs of memory and second is loaded at 2.5 > meg. second is only 40k bytes so most of the last 1/2 meg is > wasted. This patch moves second to 0x2e0000 which leaves > room for a 128k byte second. > > This doesn't fix the sparc32 boot problems because you still > need to compile everything as modules and strip the executable > but it is a short term fix. > > The long term fix is to make the sparc32 kernel relocatable > like sparc64. The first step is to make silo load a large sparc32 > kernel. A patch has been submitted 2 years ago > http://marc.info/?l=linux-sparc&m=117952409730426&w=2 > that fixes the silo side. I have tested that patch and it does > fix the problem of decompressing a large kernel. However > sparc32 kernel is not relocatable so silo tries to move the > kernel down to low memory (0x4000) but refuses because there > is no room for a large kernel. I think that patch should go > into silo so the silo will be ready for relocatable sparc32 > kernels. > > Linux head_32.S has some issues with large kernels. It > is capable of relocating itself from 0x4000 up to higher > memory but has a hard coded size limit of 0x300000. I > tried relocating a smaller image by changing the header > version to 0x300 which should support relocation and > silo was OK with that but the kernel boot failed with an > illegal instruction so the kernel is not OK with being > loaded at an arbitrary location yet. > I'm looking into changing linux to be relocatable from > an arbitrary address but that requires that the 2 year > old large kernel patch be applied first. > > Signed-off-by: Robert Reif <reif@earthlink.net> > > I have been looking at head_32.S and things don't look good. The kernel expects to either be loaded at 0x4000 or already be loaded at KERNBASE by the boot loader. If it needs to relocate itself, it just moves the first 3 meg to high memory or modifies the page table so the currently mapped memory shows up at KERNBASE. This won't help the large kernel problem. 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. Can anyone please give me some feedback? -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 14 Jun 2009, Robert Reif wrote: > 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. > > Can anyone please give me some feedback? How does the BSD bootloader work ? -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Chris Newport <crn@netunix.com> Date: Mon, 15 Jun 2009 02:38:51 +0100 (BST) > How does the BSD bootloader work ? BSD uses an fcode bootblock. Because only MIT/BSD licensed forth tokenizers exist, and also we only have one 512 byte boot block available, such an implementation really isn't an option for Linux. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Robert Reif <reif@earthlink.net> 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. > > 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? -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 15 Jun 2009, David Miller wrote: > From: Robert Reif <reif@earthlink.net> > 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@vger.kernel.org > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Robert, I'm working on getting your work integrated into SILO somehow and will look at the ugly relocation issues on sparc32 soon. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Robert Reif <reif@earthlink.net> Date: Fri, 12 Jun 2009 09:21:24 -0400 > This patch changes the location that second is loaded to make room for > larger kernels. ... > Signed-off-by: Robert Reif <reif@earthlink.net> I've taken over the SILO GIT tree and applied this patch. git://git.kernel.org/pub/scm/linux/kernel/git/davem/silo.git Enjoy. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Mark Fortescue <mark@mtfhpc.demon.co.uk> Date: Wed, 17 Jun 2009 02:41:34 +0100 (BST) > 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. Ok, if that works, the thing to do is: 1) Calculate "SUN4C_SEGMAP_ROUND_UP(&_end - KERNBASE)" Make this calculation a macro. 2) Use that instead of the 3MB constant in the sun4/sun4c remapping loops of head_32.S I'd be happy to apply this if it can get at least a minimal smoke test by someone. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Rules.make b/Rules.make index 4e722f9..f36e2d4 100644 --- a/Rules.make +++ b/Rules.make @@ -11,8 +11,8 @@ NM=nm ELFTOAOUT=elftoaout BIN2H=../common/bin2h -SMALL_RELOC=0x280000 -LARGE_RELOC=0x380000 +SMALL_RELOC=0x2E0000 +LARGE_RELOC=0x3E0000 cc-option-yn = $(shell if $(CC) $(CFLAGS) $(1) -S -o /dev/null -xc /dev/null \ > /dev/null 2>&1; then echo "y"; else echo "n"; fi;)
This patch changes the location that second is loaded to make room for larger kernels. On sparc32 a kernel is loaded at 0x4000 and second is loaded at 0x280000. That means that the largest kernel that can be loaded is 0x27c000 (2605056) bytes. Sparc32 kernels have been larger than that for years and it has recently been almost impossible to strip down a kernel small enough to actually load. OBP initializes 3 megs of memory and second is loaded at 2.5 meg. second is only 40k bytes so most of the last 1/2 meg is wasted. This patch moves second to 0x2e0000 which leaves room for a 128k byte second. This doesn't fix the sparc32 boot problems because you still need to compile everything as modules and strip the executable but it is a short term fix. The long term fix is to make the sparc32 kernel relocatable like sparc64. The first step is to make silo load a large sparc32 kernel. A patch has been submitted 2 years ago http://marc.info/?l=linux-sparc&m=117952409730426&w=2 that fixes the silo side. I have tested that patch and it does fix the problem of decompressing a large kernel. However sparc32 kernel is not relocatable so silo tries to move the kernel down to low memory (0x4000) but refuses because there is no room for a large kernel. I think that patch should go into silo so the silo will be ready for relocatable sparc32 kernels. Linux head_32.S has some issues with large kernels. It is capable of relocating itself from 0x4000 up to higher memory but has a hard coded size limit of 0x300000. I tried relocating a smaller image by changing the header version to 0x300 which should support relocation and silo was OK with that but the kernel boot failed with an illegal instruction so the kernel is not OK with being loaded at an arbitrary location yet. I'm looking into changing linux to be relocatable from an arbitrary address but that requires that the 2 year old large kernel patch be applied first. Signed-off-by: Robert Reif <reif@earthlink.net>