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.
[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 <reset_vector>: fff0: e9 51 53 ff ff jmp ffff5346 <_start+0x2>
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
Then disassemble:
stuge@n410c ~/co/v2/targets/gigabyte/m57sli/m57sli $ objdump -b binary -m i386 -D out
out: file format binary
Disassembly of section .data:
0000000000000000 <.data>: 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.
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.
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