New subject: Code flow from reset vector

26 Mar 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@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@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@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@n410c ~/co/v2/targets/gigabyte/m57sli/m57sli $
The addresses say 0 but if you prefer just use the --start-address
option.
...
[viswesh@arka image]$ objdump -D coreboot.rom | grep -ni reset_vector
[viswesh@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@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@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/

Re: [coreboot] Code flow from reset vector