[coreboot] Code flow from reset vector

a a todthgie at hotmail.com
Wed Mar 26 15:41:39 CET 2008


Peter Stuge wrote:
> On Wed, Mar 26, 2008 at 04:27:11AM -0700, Viswesh S wrote:
>> I modified the makefile and copied the coreboot before the
>> stripping to vis_1strip and then did an objdump.
> 
> coreboot.rom is not an ELF file so elfutils can't really do much good
> with it, as you have noticed.
a v2 coreboot.rom actualy IS a elf file (the payload) with some stuff 
(even another elf and a load of binary code) appended...
> 
> 
>> [viswesh at arka image]$ objdump -D --start-address=0xfffffff0 --stop-address=0xffffffff vis_1strip
>> vis_1strip:     file format elf32-i386
>> Disassembly of section .ram:
>> Disassembly of section .rom:
>> Disassembly of section .reset:
>> fffffff0 :
>> fff0:   e9 51 53 ff ff          jmp    ffff5346 

you should do -mi8086 see below

> 
> Remember I wrote that it is common to have a far jump very early?
> 
> 
>> So here I can actually see the flash location and the opcodes in
>> that location.
>>
>> But when I do the same, as you mentioned,  when I try to dump the
>> last 0x20 bytes in coreboot.rom file, I should actually see similar
>> instructions and basically there should be a jump in the last 16 bytes.
> 
> If you use an x86 disassembler on the last 16 bytes of coreboot.rom
> you will get the above instruction. You can use objdump but it needs
> some help. First make a new file starting from the address you are
> interested in:
> 
> stuge at n410c ~/co/v2/targets/gigabyte/m57sli/m57sli $ dd if=coreboot.rom of=out bs=$[524288-16] skip=1
> 0+1 records in
> 0+1 records out
> 16 bytes (16 B) copied, 0.000135259 s, 118 kB/s

i agree (524288 is you chip size......
> 
> Then disassemble:
> 
> stuge at n410c ~/co/v2/targets/gigabyte/m57sli/m57sli $ objdump -b binary -m i386 -D out
wrong should be

  objdump -b binary -m i8086 -D out
remember that ALL cpus of teh x86 famaly EVEN the most new ones start 
basicaly as an 8086 aka in realmode (it has some tricks in place with CS 
but thats another story and quete hard to follow)....
bottom line is that objdump does proetct mode disassemble when dont give 
a -m of give -mi386 ...
-mi8086 makes it do realmode disasmbly and that what you will need for 
the first ??(100 ?? orso) bytes that get executed .. basicaly that jump
then some segment discriptor setup and the switch to protected mode

> 
> out:     file format binary
> 
> Disassembly of section .data:
> 
> 0000000000000000 :
>    0:   e9 11 f0 ff ff          jmp    0xfffff016
>    5:   00 00                   add    %al,(%eax)
>    7:   00 e9                   add    %ch,%cl
>    9:   5f                      pop    %edi
>    a:   f0 ff                   lock (bad) 
>    c:   ff 00                   incl   (%eax)
>         ...
> stuge at n410c ~/co/v2/targets/gigabyte/m57sli/m57sli $ 
> 
> The addresses say 0 but if you prefer just use the --start-address
> option.
> 
> 
>> [viswesh at arka image]$ objdump -D coreboot.rom | grep -ni reset_vector
>> [viswesh at arka image]$ objdump -D coreboot.rom | grep -ni _start
> 
> Will not work since coreboot.rom is not in a file format that objdump
> can parse correctly.
> 
> 
>> [viswesh at arka image]$ objdump -D coreboot.rom | tail
>>   13cf96:       00 00                   add    %al,(%eax)
>>   13cf98:       00 00                   add    %al,(%eax)
>>   13cf9a:       00 00                   add    %al,(%eax)
>>   13cf9c:       d1 e5                   shl    %ebp
>>   13cf9e:       10 00                   adc    %al,(%eax)
>>   13cfa0:       08 00                   or     %al,(%eax)
>>   13cfa2:       00 00                   add    %al,(%eax)
>>   13cfa4:       27                      daa
>>   13cfa5:       e7 10                   out    %eax,$0x10
>>         ...
>> [viswesh at arka image]$
>>
>> So here also we dont see any jump to a specific location.
> 
> Again, objdump treats coreboot.rom as an ELF file, which it is not,
> and so you get garbage output.
it is .. and you are looking at the payload ....
> 
>> So basically where should be the code which should be flashed into
>> the location 0xfffffff0.
> 
> It is 16 bytes from the end of coreboot.rom.
> 
>>From your previous work you may be used to working with hex files or
> S-records which contain both address and data. Because x86 always
> starts at top of 4GB there is no need for address information.
> 
> The flash chip must always be at the top of 4GB. The binary flash
> file is always written to the top of the flash.
> 
> 
>> (or) how can I locate the code inside the coreboot.rom,if it is
>> there inside the rom file.
> 
> The dd and objdump trick I show above will work but is very clumsy
> and does not scale well.
you can also force objdump to start at the end of the file wit 
--start-address= but you still need to specify -bbinary (and -mi8086 for 
the  parts before the pmode switch)
> 
> I recommend the DOS utility HIEW (Hackers View) if you're going to be
> taking apart binary files. It has some useful disassembly options.
> 
> The thing with dd and objdump is that because there are bytes in the
> coreboot.rom stream that are not instructions but instead data, it is
> not neccessarily possible to disassemble the entire coreboot.rom file
> in one go and then take it apart. When data at one byte position is
> parsed as an instruction it may parse the following byte as part of
> the same instruction which causes an error in alignment in the
> disassembler because the data byte in the first position was actually
> the last data byte and the following byte was the first byte of an
> instruction. This is why you usually have to explicitly chop up the
> binary file at whatever boundary you are interested in.
> 
> 
> But why are you doing this anyway? Wouldn't it be easier to just look
> at the source code?
> 
> 
> //Peter
> 
Reinder


_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20080326/c7cf755e/attachment.html>


More information about the coreboot mailing list