[Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Blue Swirl]

CVSROOT:	/cvsroot/qemu
Module name:	qemu
Changes by:	Blue Swirl <blueswir1>	07/11/14 19:41:26

Modified files:
	pc-bios        : README openbios-sparc32 openbios-sparc64 

Log message:
	Update OpenBIOS image to SVN revision 176. Changes:
	r172: Enable boot mode in the exception handler for both SuperSparc and TurboSparc
	r173: More CPU definitions
	r174: Add Sparc64 CPU identification
	r175: Add SPARCserver 600MP emulation
	r176: Update OHW interface to version 3.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/README?cvsroot=qemu&r1=1.17&r2=1.18
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc32?cvsroot=qemu&rev=1.12
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc64?cvsroot=qemu&rev=1.5

[Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Blue Swirl]

CVSROOT:	/cvsroot/qemu
Module name:	qemu
Changes by:	Blue Swirl <blueswir1>	07/12/11 19:33:21

Modified files:
	pc-bios        : README openbios-sparc32 openbios-sparc64 

Log message:
	Update OpenBIOS images to SVN revision 181. Changes:
	r177:
	Reset fixes:
	 * recalculate CRC to avoid error message and halt after reset
	 * fix bug that crashed SS10/SMP when reset
	r178: Remove unused variable
	r179: Improved Module ID generation
	r180: Add support for eccmemctl
	r181: Add support for SPARCstation 20 machine type

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/README?cvsroot=qemu&r1=1.18&r2=1.19
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc32?cvsroot=qemu&rev=1.13
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc64?cvsroot=qemu&rev=1.6

[Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Blue Swirl]

CVSROOT:	/cvsroot/qemu
Module name:	qemu
Changes by:	Blue Swirl <blueswir1>	07/08/11 08:16:01

Modified files:
	pc-bios        : README openbios-sparc32 openbios-sparc64 

Log message:
	r158: Fix wrong number of clean/saveable windows
	r159: Revert previous patch
	r160: Fix nvram size, arch_init hack
	r161: Fix Sparc64 insw and outsw
	r162: Fix read only location write attempt
	r163:
	Change virtual address below 4G
	Map first 16M of RAM
	Execute a kernel if loaded by Qemu
	r164: Make client interface 64 bits wide on Sparc64
	r165: NVRAM support (temporary location)
	r166: Fix mapping of a single byte area, fix reset and poweroff
	r167: Maximally align allocations
	r168: Enable all interrupt sources for NetBSD
	r169: Fix NetBSD property problems

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/README?cvsroot=qemu&r1=1.15&r2=1.16
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc32?cvsroot=qemu&rev=1.10
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc64?cvsroot=qemu&rev=1.4

[Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Blue Swirl]

CVSROOT:	/cvsroot/qemu
Module name:	qemu
Changes by:	Blue Swirl <blueswir1>	07/06/28 07:28:22

Modified files:
	pc-bios        : README openbios-sparc32 openbios-sparc64 

Log message:
	Update Sparc32 and Sparc64 OpenBIOS image to SVN revision 157. Changes:
	r150: Try to fix system reset for SMP and SS-10 cases
	r151: Fix obp_dumb_memalloc
	r152: Fix mapping more than 2G memory
	r153: Get a real memory allocator for Sparc, based on PPC ofmem
	r154: Update totavail when memory is allocated by dumb memory allocator
	r155: Fix pop_fstr_copy memory leaks
	- console one prevented Debian 3.1r1 from installing in console=prom mode
	- fixing this also needed the real malloc/free
	r156: Hack for building on CIFS directory
	r157: Allow boot start PC to be different from virtual location (boot mode)

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/README?cvsroot=qemu&r1=1.14&r2=1.15
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc32?cvsroot=qemu&rev=1.9
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc64?cvsroot=qemu&rev=1.3

Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Johannes Schindelin]

Hi,

On Thu, 28 Jun 2007, Blue Swirl wrote:

> 	Update Sparc32 and Sparc64 OpenBIOS image to SVN revision 157.

Since when is QEmu tracked with Subversion?

Thanks,
Dscho

Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Blue Swirl]

On 6/28/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 28 Jun 2007, Blue Swirl wrote:
>
> >       Update Sparc32 and Sparc64 OpenBIOS image to SVN revision 157.
>
> Since when is QEmu tracked with Subversion?

OpenBIOS SVN, not QEMU.

Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Johannes Schindelin]

Hi,

On Thu, 28 Jun 2007, Blue Swirl wrote:

> On 6/28/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Thu, 28 Jun 2007, Blue Swirl wrote:
> > 
> > >       Update Sparc32 and Sparc64 OpenBIOS image to SVN revision 157.
> > 
> > Since when is QEmu tracked with Subversion?
> 
> OpenBIOS SVN, not QEMU.

Ah, thanks.

Ciao,
Dscho

[Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Blue Swirl]

CVSROOT:	/cvsroot/qemu
Module name:	qemu
Changes by:	Blue Swirl <blueswir1>	07/04/16 17:41:15

Modified files:
	pc-bios        : README openbios-sparc32 openbios-sparc64 

Log message:
	Update OpenBIOS Sparc images to SVN 125

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/README?cvsroot=qemu&r1=1.10&r2=1.11
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc32?cvsroot=qemu&rev=1.5
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc64?cvsroot=qemu&rev=1.2

[Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Blue Swirl]

CVSROOT:	/cvsroot/qemu
Module name:	qemu
Changes by:	Blue Swirl <blueswir1>	07/04/15 06:38:29

Modified files:
	pc-bios        : README openbios-sparc32 
Added files:
	pc-bios        : openbios-sparc64 

Log message:
	Update OpenBIOS for Sparc32 and add a Sparc64 image

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/README?cvsroot=qemu&r1=1.9&r2=1.10
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc32?cvsroot=qemu&rev=1.4
http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc64?cvsroot=qemu&rev=1.1

Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Stefan Weil]

The Sparc64 image is much larger than the Sparc32 image,
but the size command displays a much smaller text and data size
(about the same size as for the Sparc32 image).

Maybe it contains some unneeded parts?

Stefan

Blue Swirl schrieb:
> CVSROOT:	/cvsroot/qemu
> Module name:	qemu
> Changes by:	Blue Swirl <blueswir1>	07/04/15 06:38:29
>
> Modified files:
> 	pc-bios        : README openbios-sparc32 
> Added files:
> 	pc-bios        : openbios-sparc64 
>
> Log message:
> 	Update OpenBIOS for Sparc32 and add a Sparc64 image

Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

On 4/15/07, Stefan Weil <weil@mail.berlios.de> wrote:
> The Sparc64 image is much larger than the Sparc32 image,
> but the size command displays a much smaller text and data size
> (about the same size as for the Sparc32 image).
>
> Maybe it contains some unneeded parts?

Thanks for the report. There is indeed a whole lot of unused space
between ELF header and start of .text segment.

But I don't see what in the ldscript (attached) causes the gap to
appear. Suggestions?

[-- Attachment #2: ldscript --]
[-- Type: application/octet-stream, Size: 1610 bytes --]

OUTPUT_FORMAT(elf64-sparc)
OUTPUT_ARCH(sparc:v9)

/* Qemu ELF loader can't handle very complex files, so we put ELFBoot
info to rodata and put initctx to data.*/

ENTRY(trap_table)

/* Initial load address
 */
BASE_ADDR = 0x000001fff0000000;

/* 16KB heap and stack */
HEAP_SIZE = 16384;
STACK_SIZE = 16384;
VMEM_SIZE = 128 * 1024;
IOMEM_SIZE = 256 * 1024 + 768 * 1024;

SECTIONS
{
    . = BASE_ADDR;

    /* Start of the program. 
     * Now the version string is in the note, we must include it
     * in the program. Otherwise we lose the string after relocation. */
    _start = .;

    /* Normal sections */
    .text ALIGN(65536): {
        *(.text.vectors)
        *(.text)
        *(.text.*)
    }
    .rodata ALIGN(65536): {
        _rodata = .;
	sound_drivers_start = .;
	*(.rodata.sound_drivers)
	sound_drivers_end = .;
	*(.rodata)
	*(.rodata.*)
        *(.note.ELFBoot)
    }
    .data ALIGN(65536): {
        _data = .;
        *(.data)
        *(.data.*)
    }

    .bss ALIGN(4096): {
        _bss = .;
	*(.bss)
	*(.bss.*)
	*(COMMON)

	/* Put heap and stack here, so they are included in PT_LOAD segment
	 * and the bootloader is aware of it. */

	. = ALIGN(16);
	_heap = .;
	. += HEAP_SIZE;
	. = ALIGN(16);
	_eheap = .;

	. = ALIGN(4096);
	_vmem = .;
	. += VMEM_SIZE;
        _evmem = .;

	_stack = .;
	. += STACK_SIZE;
	. = ALIGN(16);
	_estack = .;
    }

    . = ALIGN(4096);
    _end = .;
    _iomem = _end + IOMEM_SIZE;

    /* We discard .note sections other than .note.ELFBoot,
     * because some versions of GCC generates useless ones. */

    /DISCARD/ : { *(.comment*) *(.note.*) }
}

Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Paul Brook]

On Sunday 15 April 2007 16:03, Blue Swirl wrote:
> On 4/15/07, Stefan Weil <weil@mail.berlios.de> wrote:
> > The Sparc64 image is much larger than the Sparc32 image,
> > but the size command displays a much smaller text and data size
> > (about the same size as for the Sparc32 image).
> >
> > Maybe it contains some unneeded parts?
>
> Thanks for the report. There is indeed a whole lot of unused space
> between ELF header and start of .text segment.
>
> But I don't see what in the ldscript (attached) causes the gap to
> appear. Suggestions?

Probably the linker is making sure the file offset and VMA are the same modulo 
the page size.

For our purposes we don't care about this. On an OS with virtual memory this 
means the image can be mmapped drectly into memory.

Paul

Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Blue Swirl]

> Probably the linker is making sure the file offset and VMA are the same modulo
> the page size.

But that would be one huge file, as the VMA is near 2TB:

pc-bios/openbios-sparc64:     file format elf64-sparc
pc-bios/openbios-sparc64
architecture: sparc:v9, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x000001fff0000000

Program Header:
    LOAD off    0x0000000000100000 vaddr 0x000001fff0000000 paddr
0x000001fff0000000 align 2**20
         filesz 0x00000000000600c0 memsz 0x00000000000f5000 flags rwx
   STACK off    0x0000000000000000 vaddr 0x0000000000000000 paddr
0x0000000000000000 align 2**3
         filesz 0x0000000000000000 memsz 0x0000000000000000 flags rwx

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         00028bd0  000001fff0000000  000001fff0000000  00100000  2**14
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       0002cdbc  000001fff0030000  000001fff0030000  00130000  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         000000c0  000001fff0060000  000001fff0060000  00160000  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          00094000  000001fff0061000  000001fff0061000  001600c0  2**3
                  ALLOC
SYMBOL TABLE:
no symbols

Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Paul Brook]

On Sunday 15 April 2007 20:11, Blue Swirl wrote:
> > Probably the linker is making sure the file offset and VMA are the same
> > modulo the page size.
>
> But that would be one huge file, as the VMA is near 2TB:

I said *modulo the pace size* :-)
Lets say ld thinks the page size for your system is 1Mb (nor an unreasonable 
assumption).  The vma of .text is aligned on a 1Mb boundary. In order to 
allow loading via mmap, the location of .text within the file must also be 
aligned on a 1Mb boundary. It can't put it at address zero because the ELF 
headers get in the way, so the first viable location is 1Mb into the file.

Paul

Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Blue Swirl]

On 4/15/07, Paul Brook <paul@codesourcery.com> wrote:
> On Sunday 15 April 2007 20:11, Blue Swirl wrote:
> > > Probably the linker is making sure the file offset and VMA are the same
> > > modulo the page size.
> >
> > But that would be one huge file, as the VMA is near 2TB:
>
> I said *modulo the pace size* :-)
> Lets say ld thinks the page size for your system is 1Mb (nor an unreasonable
> assumption).  The vma of .text is aligned on a 1Mb boundary. In order to
> allow loading via mmap, the location of .text within the file must also be
> aligned on a 1Mb boundary. It can't put it at address zero because the ELF
> headers get in the way, so the first viable location is 1Mb into the file.

Nice theory (and I missed the modulo arithmetic, sorry), but on
Ultrasparc the page sizes available are 8k, 64k, 4M and 256M.

Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Daniel Jacobowitz]

On Sun, Apr 15, 2007 at 10:37:08PM +0300, Blue Swirl wrote:
> On 4/15/07, Paul Brook <paul@codesourcery.com> wrote:
> > On Sunday 15 April 2007 20:11, Blue Swirl wrote:
> > > > Probably the linker is making sure the file offset and VMA are the same
> > > > modulo the page size.
> > >
> > > But that would be one huge file, as the VMA is near 2TB:
> >
> > I said *modulo the pace size* :-)
> > Lets say ld thinks the page size for your system is 1Mb (nor an unreasonable
> > assumption).  The vma of .text is aligned on a 1Mb boundary. In order to
> > allow loading via mmap, the location of .text within the file must also be
> > aligned on a 1Mb boundary. It can't put it at address zero because the ELF
> > headers get in the way, so the first viable location is 1Mb into the file.
> 
> Nice theory (and I missed the modulo arithmetic, sorry), but on
> Ultrasparc the page sizes available are 8k, 64k, 4M and 256M.

#define ELF_MAXPAGESIZE 0x100000

BFD and GNU ld think it's 1MB.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Blue Swirl]

On 4/16/07, Daniel Jacobowitz <drow@false.org> wrote:
> On Sun, Apr 15, 2007 at 10:37:08PM +0300, Blue Swirl wrote:
> > On 4/15/07, Paul Brook <paul@codesourcery.com> wrote:
> > > On Sunday 15 April 2007 20:11, Blue Swirl wrote:
> > > > > Probably the linker is making sure the file offset and VMA are the same
> > > > > modulo the page size.
> > > >
> > > > But that would be one huge file, as the VMA is near 2TB:
> > >
> > > I said *modulo the pace size* :-)
> > > Lets say ld thinks the page size for your system is 1Mb (nor an unreasonable
> > > assumption).  The vma of .text is aligned on a 1Mb boundary. In order to
> > > allow loading via mmap, the location of .text within the file must also be
> > > aligned on a 1Mb boundary. It can't put it at address zero because the ELF
> > > headers get in the way, so the first viable location is 1Mb into the file.
> >
> > Nice theory (and I missed the modulo arithmetic, sorry), but on
> > Ultrasparc the page sizes available are 8k, 64k, 4M and 256M.
>
> #define ELF_MAXPAGESIZE 0x100000
>
> BFD and GNU ld think it's 1MB.

I stand corrected. Is there anything that can be done to reduce this waste?

Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Daniel Jacobowitz]

On Mon, Apr 16, 2007 at 06:01:04PM +0300, Blue Swirl wrote:
> I stand corrected. Is there anything that can be done to reduce this waste?

For a BIOS image, you might be OK with ld -N - that should suppress
the padding.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Blue Swirl]

On 4/16/07, Daniel Jacobowitz <drow@false.org> wrote:
> On Mon, Apr 16, 2007 at 06:01:04PM +0300, Blue Swirl wrote:
> > I stand corrected. Is there anything that can be done to reduce this waste?
>
> For a BIOS image, you might be OK with ld -N - that should suppress
> the padding.

Thanks, size is smaller and Qemu still accepts the image.

I'll update the image and rules.

Re: [Qemu-devel] qemu/pc-bios README openbios-sparc32 openbios-s...

[Thiemo Seufer]

Blue Swirl wrote:
> On 4/16/07, Daniel Jacobowitz <drow@false.org> wrote:
> >On Sun, Apr 15, 2007 at 10:37:08PM +0300, Blue Swirl wrote:
> >> On 4/15/07, Paul Brook <paul@codesourcery.com> wrote:
> >> > On Sunday 15 April 2007 20:11, Blue Swirl wrote:
> >> > > > Probably the linker is making sure the file offset and VMA are the 
> >same
> >> > > > modulo the page size.
> >> > >
> >> > > But that would be one huge file, as the VMA is near 2TB:
> >> >
> >> > I said *modulo the pace size* :-)
> >> > Lets say ld thinks the page size for your system is 1Mb (nor an 
> >unreasonable
> >> > assumption).  The vma of .text is aligned on a 1Mb boundary. In order 
> >to
> >> > allow loading via mmap, the location of .text within the file must 
> >also be
> >> > aligned on a 1Mb boundary. It can't put it at address zero because the 
> >ELF
> >> > headers get in the way, so the first viable location is 1Mb into the 
> >file.
> >>
> >> Nice theory (and I missed the modulo arithmetic, sorry), but on
> >> Ultrasparc the page sizes available are 8k, 64k, 4M and 256M.
> >
> >#define ELF_MAXPAGESIZE 0x100000
> >
> >BFD and GNU ld think it's 1MB.
> 
> I stand corrected. Is there anything that can be done to reduce this waste?

See ld's -z max-page-size and -z common-page-size.


Thiemo