coreboot.rom

[ali hagigat]

How the file coreboot.rom is written on BIOS chip logically? Suppose
our BIOS chip is 1 mega bytes. We should read first byte from the
beginning of the file and write it to the address zero of BIOS chip
and continue this way?

I checked the content of build/coreboot.rom and the last byte was
0x0a!! Which is written probably on the top of our EEPROM. Right?
but src/arch/i386/init/ldscript.ld specifies the last byte as 0x00!!
SECTIONS {
    _ROMTOP = 0xfffffff0;
    . = _ROMTOP;
    .resetvector . : {
    	*(.reset)
                . = 15 ;
                BYTE(0x00);
    }
}

Please help me with this puzzle. Thank you.

how Coreboot keeps the right offsets of the sections

[Peter Stuge]

ali hagigat wrote:
> the top content of ROM, like 0xffffff00 is probably written from
> the beginning of coreboot.rom

No.

ali hagigat wrote:
> How the file coreboot.rom is written on BIOS chip logically?

Exactly the same way all other firmware images are written to flash
chips on PCs, and all other machines.

I'd expect you to already know this, with your experience from
firmware development on the PC.
> Suppose our BIOS chip is 1 mega bytes. We should read first byte
> from the beginning of the file and write it to the address zero of
> BIOS chip and continue this way?

Yes, coreboot.rom is a 1:1 representation of the flash chip contents.

This is fairly clear from the size of the file, and the fact that you
must select a flash chip size during configuration.
> I checked the content of build/coreboot.rom and the last byte was
> 0x0a!! Which is written probably on the top of our EEPROM. Right?

If it is written properly or not depends on what tool you use to
write to the flash chip.
> but src/arch/i386/init/ldscript.ld specifies the last byte as 0x00!!
> SECTIONS {
>    _ROMTOP = 0xfffffff0;
>    . = _ROMTOP;
>    .resetvector . : {
>    	*(.reset)
>                 . = 15 ;
>                 BYTE(0x00);
>    }
> }
>
> Please help me with this puzzle. Thank you.

What is the concrete problem? You should not rule out that there are
binutils bugs. Just be happy that the reset vector has the right
opcodes.

//Peter

how Coreboot keeps the right offsets of the sections

[Stefan Reinauer]

* Peter Stuge  [110209 20:44]:
> > I checked the content of build/coreboot.rom and the last byte was
> > 0x0a!! Which is written probably on the top of our EEPROM. Right?
> > but src/arch/i386/init/ldscript.ld specifies the last byte as 0x00!!
> > SECTIONS {
> >    _ROMTOP = 0xfffffff0;
> >    . = _ROMTOP;
> >    .resetvector . : {
> >    	*(.reset)
> >                 . = 15 ;
> >                 BYTE(0x00);
> >    }
> > }
> >
> > Please help me with this puzzle. Thank you.
>
> What is the concrete problem? You should not rule out that there are
> binutils bugs. Just be happy that the reset vector has the right
> opcodes.

cbfstool updates those memory regions.

[Marc Jones]

On Wed, Feb 9, 2011 at 6:35 AM, ali hagigat  wrote:
> How the file coreboot.rom is written on BIOS chip logically? Suppose
> our BIOS chip is 1 mega bytes. We should read first byte from the
> beginning of the file and write it to the address zero of BIOS chip
> and continue this way?
>
> I checked the content of build/coreboot.rom and the last byte was
> 0x0a!! Which is written probably on the top of our EEPROM. Right?
> but src/arch/i386/init/ldscript.ld specifies the last byte as 0x00!!
> SECTIONS {
>        _ROMTOP = 0xfffffff0;
>        . = _ROMTOP;
>        .resetvector . : {
>                *(.reset)
>                . = 15 ;
>                BYTE(0x00);
>        }
> }

x86 systems start executing 0xFFFFFFF0, the reset vector.

http://en.wikipedia.org/wiki/Reset_vector

The first instruction is a far jump down to the stackless init code.

This wiki is for V3, but all the details are there:
http://www.coreboot.org/Coreboot_v3#How_coreboot_starts_after_Reset

Marc