SPARC: 3.13-rc1 and newer: kernel size issue with tftpboot.img

SPARC: 3.13-rc1 and newer: kernel size issue with tftpboot.img

[Aaro Koskinen]

Hi,

Sun Ultra 5/10 (OpenBoot 3.25) seems to have 10 MB limitation for the
tftpboot.img. With larger images "boot net" will fail with "Fast Data
Access MMU Miss":

	Rebooting with command: boot net
	Boot device: /pci@1f,0/pci@1,1/network@1,1  File and args:
	a00000 Fast Data Access MMU Miss
	ok

tftpboot.img size seem to be roughly uncompressed kernel text/data +
bss + compressed initramfs. Until 3.13-rc1 the 10 MB size limitation
has not been an issue. With 3.12, normal kernel + GLIBC + busybox +
other tools will result in a 7 MB image. However, 3.13-rc1 introduced
a huge increase in bss size:

	   text    data     bss     dec     hex filename
	4214999  341664  320496 4877159  4a6b67 vmlinux-3.12
	4242584  350216 4588328 9181128  8c17c8 vmlinux-3.13-rc1

As a result in will be practically impossible to create an useful/working
tftpboot.img fitting into 10 MB.

The bloat seems to be coming from arch/sparc/mm/init_64.c:

	   text    data     bss     dec     hex filename
	  10147   13536 4335264 4358947  428323 arch/sparc/mm/init_64.o

The cause is MAX_PHYS_ADDRESS_BITS changing from 41 to 47. Would it be
possible to make this configurable for legacy SPARCs? Manually patching
this value back to 41 seems to at least produce a bootable image (no
further testing done).

A.

Re: SPARC: 3.13-rc1 and newer: kernel size issue with tftpboot.img

[David Miller]

From: Aaro Koskinen <aaro.koskinen@iki.fi>
Date: Sun, 1 Dec 2013 21:02:20 +0200

> The bloat seems to be coming from arch/sparc/mm/init_64.c:
> 
> 	   text    data     bss     dec     hex filename
> 	  10147   13536 4335264 4358947  428323 arch/sparc/mm/init_64.o
> 
> The cause is MAX_PHYS_ADDRESS_BITS changing from 41 to 47. Would it be
> possible to make this configurable for legacy SPARCs? Manually patching
> this value back to 41 seems to at least produce a bootable image (no
> further testing done).

That would defeat the whole point of having one kernel image that
works on all sparc64 systems.

This data structure must be locked into the TLB and therefore must
be in the main kernel image.  I'll try to look into doing things
differently but it won't be done any time soon as I'm very backlogged
with just networking patch review after coming home from travelling.

Re: SPARC: 3.13-rc1 and newer: kernel size issue with tftpboot.img

[Xose Vazquez Perez]

Aaro Koskinen wrote:

> Sun Ultra 5/10 (OpenBoot 3.25) seems to have 10 MB limitation for the
> tftpboot.img. With larger images "boot net" will fail with "Fast Data
> Access MMU Miss":

Latest patchdiag.xref [0] shows that the last OBP for U5/10 was:
OBP_3.31.0,POST_3.1.0,OBDIAG_P2.9 (106121-18) [1]

But I didn't see any bug fix related to that limit.


[0] https://getupdates.oracle.com/reports/patchdiag.xref
[1] https://updates.oracle.com/readme/106121-18

Re: SPARC: 3.13-rc1 and newer: kernel size issue with tftpboot.img

[David Miller]

From: Xose Vazquez Perez <xose.vazquez@gmail.com>
Date: Sun, 01 Dec 2013 22:37:57 +0100

> Aaro Koskinen wrote:
> 
>> Sun Ultra 5/10 (OpenBoot 3.25) seems to have 10 MB limitation for the
>> tftpboot.img. With larger images "boot net" will fail with "Fast Data
>> Access MMU Miss":
> 
> Latest patchdiag.xref [0] shows that the last OBP for U5/10 was:
> OBP_3.31.0,POST_3.1.0,OBDIAG_P2.9 (106121-18) [1]
> 
> But I didn't see any bug fix related to that limit.

It's not a bug, and even if they increase the limit we always and
indefinitely need to support 10MB properly.

Therefore, I don't think that talking about the possibility of it
increasing is worthwhile.

Thanks.

Re: SPARC: 3.13-rc1 and newer: kernel size issue with tftpboot.img

[David Miller]

From: Aaro Koskinen <aaro.koskinen@iki.fi>
Date: Sun, 1 Dec 2013 21:02:20 +0200

> The bloat seems to be coming from arch/sparc/mm/init_64.c:
> 
> 	   text    data     bss     dec     hex filename
> 	  10147   13536 4335264 4358947  428323 arch/sparc/mm/init_64.o
> 
> The cause is MAX_PHYS_ADDRESS_BITS changing from 41 to 47. Would it be
> possible to make this configurable for legacy SPARCs? Manually patching
> this value back to 41 seems to at least produce a bootable image (no
> further testing done).

This issue should now be fully addressed.

The kernel image BSS should now be just over 6MB smaller. 

I'm going to try and backport the changes that are going into v3.18
that allowed this to happen as far back in -stable as possible.

Just FYI...