RE: status information

[YhLu]

If the ROMCC can handle function not as inline. You may don't need to
enlarge the 64K limit.
Current Auto.c compiled is some big. Esp the print_debug causes the problem

Regards

YH

-----Original Message-----
From: Ronald G. Minnich [mailto:[e-mail]] 
Sent: Friday, October 29, 2004 12:22 PM
To: Richard Smith
Cc: [e-mail]; Eric W. Biederman; Stefan Reinauer; LinuxBIOS
Subject: Re: status information

On Fri, 29 Oct 2004, Richard Smith wrote:
> Ronald G. Minnich wrote:
> > The issue is this: right now, linubios compressed payload AND romcc

object
> > fit in the top 64k. There is no need to do this. They're not fitting

anyway
> > at this point. romcc object startup can turn on full flash access, so

the
> > linuxbios
> > compressed payload can be placed, not in the top 64k, but in the

next-to-top
> > 64k. The linuxbios image will then have 128k available to it, not just

64k.
> > Then we can put all the debug prints we want into romcc code, which

would be
> > nice.

old-fashioned linuxbios

----------- (e.g.) 0xfff80000
| payload |
|         |
|         |
----------- 0xffff0000
| linux   |
| bios    |
----------|

V2:

--------------0xfff80000
| smith      |
| payload    |
--------------0xffff0000
| c_payload  |
| uncompress |
| to ram     |
|   ----     |
| auto.C     |
| compiled   |
|  code      |
--------------

So there are really two "payloads"

There is startup code -- now compiled by romcc -- that turns on ram and 
uncompresses the c_payload to ram. The RAM code then does final setup and 
uncompresses the "smith payload" or whatever (Etherboot, filo, linux, 
ADLO) to ram.

So I'm just saying do this.

--------------0xfff80000
| smith      |
| payload    |
--------------0xfffe0000
| c_payload  |
| uncompress |
| to ram     |
|------------|0xffff0000
| auto.C     |
| compiled   |
|  code      |
--------------

That's all you have to do to fix the issues with romcc getting too big.

ron
_______________________________________________
Linuxbios mailing list
[e-mail]
http://www.clustermatic.org/mailman/listinfo/linuxbios

status information

[Ronald G. Minnich]

On Fri, 29 Oct 2004, YhLu wrote:
> If the ROMCC can handle function not as inline. You may don't need to
> enlarge the 64K limit.
> Current Auto.c compiled is some big. Esp the print_debug causes the problem

yes.

The long term solution is to have all vendors set up working cache-as-ram, 
short term is harder and involves romcc. It would be good if more people 
could learn romcc innards and help with this difficult problem.

ron

size status information

"Ronald G. Minnich"  writes:
> On Fri, 29 Oct 2004, YhLu wrote:
> > If the ROMCC can handle function not as inline. You may don't need to
> > enlarge the 64K limit.
> > Current Auto.c compiled is some big. Esp the print_debug causes the problem
>
> yes.
>
> The long term solution is to have all vendors set up working cache-as-ram, 
> short term is harder and involves romcc. It would be good if more people 
> could learn romcc innards and help with this difficult problem.

At the moment I would be happy for some bug reports.  That included
a small code sample the reduced problems.  Not that I have heard
of many bugs.

First remember that by turning the down the level of debugging size
can almost always be decreased in LinuxBIOS to a size we can test things
with.

So the things we can to do to keep size down.
1)  Use gcc-3.4 instead of gcc-3.3

From my experience the Opteron platform has the largest and
    most complex code before memory initialization.  So using
    the arima hdama dual opteron board is a reasonable gauge on how
    large we are.  Building with gcc-3.4 and looking at current cvs
    the status is:

$ ls -l linuxbios_payload.nrv2b
    rw-r--r--  1 eric eric 28930 Oct 29 16:30 linuxbios_payload.nrv2b

$ size crt0.o
       text	   data	    bss	    dec	    hex	filename
      36121	      0	      0	  36121	   8d19	crt0.o

36121 + 28930 = 65051
    65536 - 65051 = 485

$ ls -l linuxbios_payload.nrv2b 
    -rw-r--r--  1 eric eric 28393 Oct 29 16:28 linuxbios_payload.nrv2b

$ size crt0.o
       text	   data	    bss	    dec	    hex	filename
      37033	      0	      0	  37033	   90a9	crt0.o

37033 + 28393 = 65426
    65536 - 65426 = 110

So even with gcc-3.4 I am running quite tight but it does still build.
    It is interesting that it takes nearly 1KiB for fallback.c

2) Kill unused strings.

3) Expand the space available for linuxbios_c.gz

4) Better tune the current 64bit support for size.  I think the size
   increase of the last few days has something to do with gcc's poor
   handling of 64bit integers.  Perhaps linuxbios_c needs to go native
   64bit on x86-64 capable machines.

5) Get non-inlining working usefully with romcc.

6) cache-as-ram support (long term).

Eric

Merge/Cleanup status

I have just committed another big bunch of code and I need to make
one more pass through the tree catch up other boards besides the
hdama to handle what I have introduced.  But things are cleaner more a
little smaller now, but with a little more functionality so I break
even on size.

- To reduce confuse rename the parts of linuxbios bios that run from
  ram linuxbios_ram instead of linuxbios_c and linuxbios_payload...
- Reordered the linker sections so the LinuxBIOS fallback image can take more the 64KiB on x86
- ROM_IMAGE_SIZE now will work when it is specified as larger than 64KiB.
- Tweaked the reset16.inc and reset16.lds to move the sanity check to see if everything will work.
- Start using romcc's built in preprocessor (This will simplify header compiler checks)
- Add helper functions for examining all of the resources
- Remove debug strings from chip.h
- Add llshell to src/arch/i386/llshell (Sometime later I can try it...)
- Add the ability to catch exceptions on x86
- Add gdb_stub support to x86
- Removed old cpu options
- Added an option so we can detect movnti support
- Remove some duplicate definitions from pci_ids.h
- Remove the 64bit resource code in amdk8/northbridge.c in preparation for making it generic
- Minor romcc bug fixes

[e-mail] (Eric W. Biederman) writes:
> So the things we can to do to keep size down.
> Use gcc-3.4 instead of gcc-3.3

An updated size comparison for fallback gcc-3.3 vs gcc-3.4 on the arima
      hdama fallback image.

With gcc-3.3 I have:
----------------------------------------------------------------
$ size linuxbios_ram
   text	   data	    bss	    dec	    hex	filename
  40656	  39728	  58956	 139340	  2204c	linuxbios_ram

$ ls -l linuxbios_ram.nvr2b
-rw-r--r--  1 eric eric 28938 Oct 30 02:08 linuxbios_ram.nrv2b

$ ls -l linuxbios_ram.rom 
-rw-r--r--  1 eric eric 28938 Oct 30 02:08 linuxbios_ram.rom

$ size crt0.o
   text	   data	    bss	    dec	    hex	filename
  37033	      0	      0	  37033	   90a9	crt0.o

28938 + 37033 = 65971 or just over 65KiB

With gcc-3.4 I have:
-----------------------------------------------------------------
$ size linuxbios_ram

text	   data	    bss	    dec	    hex	filename
  40448	  38268	  60652	 139368	  22068	linuxbios_ram

$ ls -l linuxbios_ram.nrv2b
-rw-r--r--  1 eric eric 28317 Oct 30 02:16 linuxbios_ram.nrv2b

$ ls -l linuxbios_ram.rom 
-rw-r--r--  1 eric eric 28317 Oct 30 02:16 linuxbios_ram.rom

$ size crt0.o
   text	   data	    bss	    dec	    hex	filename
  37033	      0	      0	  37033	   90a9	crt0.o

28317 + 37033 = 65350 or just under 65KiB

---------------------------------------------------------------------

So with this comparison I see the following.
28938 - 28317                     = 621 bytes or 2% more for gcc-3.3 in compressed size
(40656 + 39728) - (40448 + 38268) = 1668 bytes or 2% more for gcc-3.3 in uncompressed size

So switching to gcc-3.4 gives a 2% size reduction.  Not huge bug significant.
> Kill unused strings.

The member is removed from device.h and the dead strings just remain to
     be killed.
> Expand the space available for linuxbios_c.gz

Done.  linuxbios_ram can now occupy more space on x86.
> Better tune the current 64bit support for size.  I think the size
> increase of the last few days has something to do with gcc's poor
> handling of 64bit integers.  Perhaps linuxbios_c needs to go native
> 64bit on x86-64 capable machines.

Some initial tuning has be done in particular some helper functions
     were introduced which noticeably bring the code size down.
> Get non-inlining working usefully with romcc.

Not really started but I have added functions:
     print_debug_hex8_(unsigned char value);
     print_debug_hex32_(unsigned int value);
     print_debug_(const char *str);

Into arch/i386/lib/console.c so we can begin to experiment with
     this manually.  Once the manual case works it will be time to
     look at doing this automatically.

In addition I modified the hdama build to let romcc preprocess
     the files itself without help from gcc.  Since that code works.
     (Well except for unsigned long constant expressions...)
> cache-as-ram support (long term).

Perhaps llshell.inc will make this easier to debug.
     I have added that into 
     src/arch/i386/llshell.inc for people to play with.

And the list of files I touched this round.

CVS: ----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS:    src/arch/i386/boot/linuxbios_table.c
CVS:    src/arch/i386/init/ldscript.lb src/arch/i386/lib/Config.lb
CVS:    src/arch/i386/lib/c_start.S src/arch/ppc/init/ldscript.lb
CVS:    src/arch/ppc/lib/cpuid.c src/config/Config.lb
CVS:    src/config/Options.lb src/cpu/amd/model_fxx/Config.lb
CVS:    src/cpu/amd/mtrr/amd_mtrr.c src/cpu/amd/socket_940/Config.lb
CVS:    src/cpu/amd/socket_940/socket_940.c
CVS:    src/cpu/intel/model_f0x/Config.lb
CVS:    src/cpu/intel/model_f1x/Config.lb
CVS:    src/cpu/intel/model_f2x/Config.lb
CVS:    src/cpu/intel/model_f3x/Config.lb
CVS:    src/cpu/x86/16bit/entry16.inc src/cpu/x86/16bit/reset16.inc
CVS:    src/cpu/x86/16bit/reset16.lds src/cpu/x86/lapic/secondary.S
CVS:    src/cpu/x86/mtrr/earlymtrr.c src/cpu/x86/mtrr/mtrr.c
CVS:    src/devices/device.c src/devices/device_util.c
CVS:    src/devices/root_device.c src/include/delay.h
CVS:    src/include/device/device.h src/include/device/pci_ids.h
CVS:    src/include/device/resource.h
CVS:    src/mainboard/arima/hdama/Config.lb
CVS:    src/mainboard/arima/hdama/Options.lb
CVS:    src/mainboard/arima/hdama/mainboard.c
CVS:    src/northbridge/amd/amdk8/coherent_ht.c
CVS:    src/northbridge/amd/amdk8/northbridge.c src/ram/ramtest.c
CVS:    src/southbridge/amd/amd8111/amd8111.c
CVS:    src/superio/NSC/pc87360/superio.c
CVS:    targets/arima/hdama/Config.lb util/romcc/romcc.c
CVS: Added Files:
CVS:    src/arch/i386/llshell/llshell.inc
CVS:    src/arch/i386/llshell/readme.linuxbios
CVS:    src/config/linuxbios_ram.ld
CVS: Removed Files:
CVS:    src/config/linuxbios_c.ld
CVS: ----------------------------------------------------------------------

Merge/Cleanup status

[Yinghai Lu]

1. Using ROMCC to do propresser will help the size reduction?
2. what is usage for MOVNTI? It is for GDB....
3. How to use GDB to debug LinuxBIOS? Is it only for linuxbios_ram?
4. You will use llshell for crt0.s or auto.c debug?
5. Current romcc only take constant parameters for non inline function? It
that right?
6. Anyone has tried to compile LinuxBIOS under Suse 9.1?  what's the
recommended platform for LinuxBIOS compliation? It seems Suse 9.1 can not
compile Etherboot properly. I am always using RH9 to do the work. And just
found I can not compile LB for S2885, (size>65536), but I can do it in Suse
9.1 pro.

Regards

YH

-----Original Message-----
From: Eric W. Biederman [mailto:[e-mail]] On Behalf Of Eric W.
Biederman
Sent: Saturday, October 30, 2004 1:39 AM
To: LinuxBIOS
Cc: Ronald G. Minnich; YhLu; Richard Smith; [e-mail]; Stefan Reinauer
Subject: Merge/Cleanup status

I have just committed another big bunch of code and I need to make
one more pass through the tree catch up other boards besides the
hdama to handle what I have introduced.  But things are cleaner more a
little smaller now, but with a little more functionality so I break
even on size.

- To reduce confuse rename the parts of linuxbios bios that run from
  ram linuxbios_ram instead of linuxbios_c and linuxbios_payload...
- Reordered the linker sections so the LinuxBIOS fallback image can take
more the 64KiB on x86
- ROM_IMAGE_SIZE now will work when it is specified as larger than 64KiB.
- Tweaked the reset16.inc and reset16.lds to move the sanity check to see if
everything will work.
- Start using romcc's built in preprocessor (This will simplify header
compiler checks)
- Add helper functions for examining all of the resources
- Remove debug strings from chip.h
- Add llshell to src/arch/i386/llshell (Sometime later I can try it...)
- Add the ability to catch exceptions on x86
- Add gdb_stub support to x86
- Removed old cpu options
- Added an option so we can detect movnti support
- Remove some duplicate definitions from pci_ids.h
- Remove the 64bit resource code in amdk8/northbridge.c in preparation for
making it generic
- Minor romcc bug fixes

[e-mail] (Eric W. Biederman) writes:
> So the things we can to do to keep size down.
> Use gcc-3.4 instead of gcc-3.3

An updated size comparison for fallback gcc-3.3 vs gcc-3.4 on the
arima
      hdama fallback image.

With gcc-3.3 I have:
----------------------------------------------------------------
$ size linuxbios_ram
   text	   data	    bss	    dec	    hex	filename
  40656	  39728	  58956	 139340	  2204c	linuxbios_ram

$ ls -l linuxbios_ram.nvr2b
-rw-r--r--  1 eric eric 28938 Oct 30 02:08 linuxbios_ram.nrv2b

$ ls -l linuxbios_ram.rom 
-rw-r--r--  1 eric eric 28938 Oct 30 02:08 linuxbios_ram.rom

$ size crt0.o
   text	   data	    bss	    dec	    hex	filename
  37033	      0	      0	  37033	   90a9	crt0.o

28938 + 37033 = 65971 or just over 65KiB

With gcc-3.4 I have:
-----------------------------------------------------------------
$ size linuxbios_ram

text	   data	    bss	    dec	    hex	filename
  40448	  38268	  60652	 139368	  22068	linuxbios_ram

$ ls -l linuxbios_ram.nrv2b
-rw-r--r--  1 eric eric 28317 Oct 30 02:16 linuxbios_ram.nrv2b

$ ls -l linuxbios_ram.rom 
-rw-r--r--  1 eric eric 28317 Oct 30 02:16 linuxbios_ram.rom

$ size crt0.o
   text	   data	    bss	    dec	    hex	filename
  37033	      0	      0	  37033	   90a9	crt0.o

28317 + 37033 = 65350 or just under 65KiB

---------------------------------------------------------------------

So with this comparison I see the following.
28938 - 28317                     = 621 bytes or 2% more for gcc-3.3 in
compressed size
(40656 + 39728) - (40448 + 38268) = 1668 bytes or 2% more for gcc-3.3 in
uncompressed size

So switching to gcc-3.4 gives a 2% size reduction.  Not huge bug
significant.
> Kill unused strings.

The member is removed from device.h and the dead strings just remain to
     be killed.
> Expand the space available for linuxbios_c.gz

Done.  linuxbios_ram can now occupy more space on x86.
> Better tune the current 64bit support for size.  I think the size
> increase of the last few days has something to do with gcc's poor
> handling of 64bit integers.  Perhaps linuxbios_c needs to go native
> 64bit on x86-64 capable machines.

Some initial tuning has be done in particular some helper functions
     were introduced which noticeably bring the code size down.
> Get non-inlining working usefully with romcc.

Not really started but I have added functions:
     print_debug_hex8_(unsigned char value);
     print_debug_hex32_(unsigned int value);
     print_debug_(const char *str);

Into arch/i386/lib/console.c so we can begin to experiment with
     this manually.  Once the manual case works it will be time to
     look at doing this automatically.

In addition I modified the hdama build to let romcc preprocess
     the files itself without help from gcc.  Since that code works.
     (Well except for unsigned long constant expressions...)
> cache-as-ram support (long term).

Perhaps llshell.inc will make this easier to debug.
     I have added that into 
     src/arch/i386/llshell.inc for people to play with.

And the list of files I touched this round.

CVS: ----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS:    src/arch/i386/boot/linuxbios_table.c
CVS:    src/arch/i386/init/ldscript.lb src/arch/i386/lib/Config.lb
CVS:    src/arch/i386/lib/c_start.S src/arch/ppc/init/ldscript.lb
CVS:    src/arch/ppc/lib/cpuid.c src/config/Config.lb
CVS:    src/config/Options.lb src/cpu/amd/model_fxx/Config.lb
CVS:    src/cpu/amd/mtrr/amd_mtrr.c src/cpu/amd/socket_940/Config.lb
CVS:    src/cpu/amd/socket_940/socket_940.c
CVS:    src/cpu/intel/model_f0x/Config.lb
CVS:    src/cpu/intel/model_f1x/Config.lb
CVS:    src/cpu/intel/model_f2x/Config.lb
CVS:    src/cpu/intel/model_f3x/Config.lb
CVS:    src/cpu/x86/16bit/entry16.inc src/cpu/x86/16bit/reset16.inc
CVS:    src/cpu/x86/16bit/reset16.lds src/cpu/x86/lapic/secondary.S
CVS:    src/cpu/x86/mtrr/earlymtrr.c src/cpu/x86/mtrr/mtrr.c
CVS:    src/devices/device.c src/devices/device_util.c
CVS:    src/devices/root_device.c src/include/delay.h
CVS:    src/include/device/device.h src/include/device/pci_ids.h
CVS:    src/include/device/resource.h
CVS:    src/mainboard/arima/hdama/Config.lb
CVS:    src/mainboard/arima/hdama/Options.lb
CVS:    src/mainboard/arima/hdama/mainboard.c
CVS:    src/northbridge/amd/amdk8/coherent_ht.c
CVS:    src/northbridge/amd/amdk8/northbridge.c src/ram/ramtest.c
CVS:    src/southbridge/amd/amd8111/amd8111.c
CVS:    src/superio/NSC/pc87360/superio.c
CVS:    targets/arima/hdama/Config.lb util/romcc/romcc.c
CVS: Added Files:
CVS:    src/arch/i386/llshell/llshell.inc
CVS:    src/arch/i386/llshell/readme.linuxbios
CVS:    src/config/linuxbios_ram.ld
CVS: Removed Files:
CVS:    src/config/linuxbios_c.ld
CVS: ----------------------------------------------------------------------