Hi ,
Thanks for the answers, but still some questions.
I modified the makefile and copied the coreboot before the stripping to vis_1strip and then did an objdump.
[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> fff5: 00 00 add %al,(%eax) fff7: 00 e9 add %ch,%cl fff9: 9f lahf fffa: 53 push %ebx fffb: ff (bad) fffc: ff 00 incl (%eax) ... Disassembly of section .id: [viswesh@arka image]$
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.
[viswesh@arka image]$ objdump -D coreboot.rom | grep -ni reset_vector [viswesh@arka image]$ objdump -D coreboot.rom | grep -ni _start [viswesh@arka image]
Here I have dumped both the beginning and the end of the coreboot,rom file.
[viswesh@arka image]$ objdump -D coreboot.rom | more coreboot.rom: file format elf32-i386 Disassembly of section .note: 00100000 <.note>: 100000: 08 00 or %al,(%eax) 100002: 00 00 add %al,(%eax) 100004: 05 00 00 00 01 add $0x1000000,%eax 100009: 00 00 add %al,(%eax) 10000b: 00 45 4c add %al,0x4c(%ebp) 10000e: 46 inc %esi 10000f: 42 inc %edx 100010: 6f outsl %ds:(%esi),(%dx) 100011: 6f outsl %ds:(%esi),(%dx) 100012: 74 00 je 0x100014 100014: 46 inc %esi 100015: 49 dec %ecx
[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.
So basically where should be the code which should be flashed into the location 0xfffffff0.
(or) how can I locate the code inside the coreboot.rom,if it is there inside the rom file.
Thanks in advance,
Viswesh
----- Original Message ---- From: a a todthgie@hotmail.com To: coreboot@coreboot.org Cc: viswesh_vichu@yahoo.com Sent: Wednesday, March 26, 2008 1:04:13 PM Subject: Re: [coreboot] Code flow from reset vector
Hello, Viswesh S wrote:
Hi, I understand the procedure in which internally how the CS register ( Segment selector and base address part) make sure that we point to the address 0xFFFFFFF0.
correct
But my doubts are in this part.
- We will be flashing the coreboot.rom into the BIOS flash, right ?
yes and the flash chip is mapped at 0x(1)00000000 - chipsize (0xFFFFFFFF - chipsize +1 in the core iirc) so a 256Kbyte (0x40000 bytes) chip would be at 0xFFFC0000....0xFFFFFFFF....
- If we objdump coreboot.rom, dump all the sections, we dont see the
reset vector part and also the address 0xFFFFFFF0.This could be because these sections are stripped off.Is it because of that ?
no, it will be at chipsize -0x10 (0x3FFF0 for a 256Kbyte chip) coreboot.rom should be EXACLY as long as you flash chip is .... so 0x10 bytes from the end of the file
- If they are stripped off, then when I flash the coreboot.rom, what do
I flash into the address 0xFFFFFFF0, as the coreboot.rom doesnt even contain the data(opcodes ) to write in that location.
no they should not be stripped... whats in the file @ 0x10 bytes from the end ends op @ 0xFFFFFFF0
Am I missing anything. Regards, Viswesh ps:- I am trying to correlate my experience in embedded firmware exp, where the files we were flashing had absolute addresses and we could objdump the flash file to understand the code at each location.
a lot of embedded targets have the flash at 0x00000000 the x86 does not. the adresses are static but have a offset of 4G-chipsize
____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
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
-
Peter Stuge -
Viswesh S