Re: [coreboot] Where is the first instrucion?

[Alex G.]

On 01/10/2016 10:23 AM, ron minnich wrote:
 One thing I think you'd enjoy doing is building the qemu target,
setting
 up qemu with gdb, and just watching what happens, instruction by
 instruction, as the system boots.
One exercise I liked doing was to rewrite the entire boot flow, from
reset vector to protected mode entry. Tested on qemu, put it on
hardware, nothing burned.

Alex

 ron
 
 On Sun, Jan 10, 2016 at 3:28 AM Rafael Machado
 <rafaelrodrigues.machado(a)gmail.com
 <mailto:[e-mail]>> wrote:
 
     Hi Peter and Rudolf.
     Thanks for the answers and tips. They are realy helpfull !
     I'll take a look.
 
     Rafael R. Machado
 
 
     Em Sáb, 9 de jan de 2016 17:19, Rudolf Marek <r.marek(a)assembler.cz
     <mailto:[e-mail]>> escreveu:
 
         Hi,
 
         I guess your question is more general than the coreboot related
         right?
 
         If you have a firmware image dump of the flash (not the file you
         download from
         board vendor) then yes, first location to be executed is the
         instruction located
         16 bytes before end of the image.
 
         In coreboot see in build/ bootblock_inc.S which also has
         reset16.inc and
         entry16.inc which is a real start. Consult the Intel or AMD
         manual to see the
         CPU state after reset. The CPU starts in real mode, but CS base
         is shifted to
         last 64KB before end of 4GB address space. In general your CPU
         starts in
         compatible mode with 8086 manufactured in 1978.
 
         Thanks
         Rudolf
 
     --
     coreboot mailing list: coreboot(a)coreboot.org
     <mailto:[e-mail]>
     http://www.coreboot.org/mailman/listinfo/coreboot

Where is the first instrucion?

[Rafael Machado]

Hi guys. Long time since my last e-mail.

It's hard to synchronize my day work with my firmware studies. Since my
projects are more UEFI related I usually do not have to much time to study
the legacy way, but It's really cool and Ill not give up :)

Since the last talk I was doing what everyone kindly proposed. (by the way
thank you all for the guidance.)

Now I'm disassembly an old systems bios I have, but I cannot understand
what is happening in a specific section of the code. (I'm using radare2 for
my studies)

The code is:

f000:0fcb     66b9ff020000    mov ecx, 0x2ff
f000:0fd1     0f32                 rdmsr             ; read register 0x2ff
(IA32_MTRR_DEF_TYPE)
f000:0fd3     0fbae80b          bts ax, 0xb     ; Enable bit 11 (MTRR
Enable).
f000:0fd7     0fbae80a          bts ax, 0xa     ; Enable bit 10 (Fixed MTRR
Enable).
f000:0fdb     0f30                 wrmsr            ; Write changes to MTRR
f000:0fdd     0f20c0             mov eax, cr0
f000:0fe0     660fbaf01e       btr eax, 0x1e   ; Bit 30 means CD - Cache
disabled.
f000:0fe5     660fbaf01d       btr eax, 0x1d   ; Disable bit 29. NW - No
Write-through
f000:0fea     0f22c0             mov cr0, eax   ; Write changes to CR0
f000:0fed     ffe7                  jmp di
f000:0fef     0f20c0              mov eax, cr0
f000:0ff2     660fbae81e       bts eax, 0x1e
f000:0ff7     660fbae81d       bts eax, 0x1d
f000:0ffc     0f22c0              mov cr0, eax


Here is the code with my notes. I understand that some MTRR were set, and
now the processor will be "configured".
We see at address f000:0fe0 and f000:0fe5 that the CR0 register is being
changed and after that the changes are saved.

Now I have two questions.

1 - After CR0 changes get completed there is a "jmp di" instruction. This
does not make any sense to me. Does anyone know why this is needed ? As far
as I could check di value is 0x0 at this point. I think

2 - After the "jmp di" a "CR0 Déjà vu" code is executed. Any idea why
this
is needed ?

Thanks everyone
Rafael R. Machado


Em seg, 11 de jan de 2016 às 03:57, Alex G. <mr.nuke.me(a)gmail.com&gt; escreveu:

 On 01/10/2016 10:23 AM, ron minnich wrote:
 > One thing I think you'd enjoy doing is building the qemu target, setting
 > up qemu with gdb, and just watching what happens, instruction by
 > instruction, as the system boots.

 One exercise I liked doing was to rewrite the entire boot flow, from
 reset vector to protected mode entry. Tested on qemu, put it on
 hardware, nothing burned.

 Alex

 > ron
 >
 > On Sun, Jan 10, 2016 at 3:28 AM Rafael Machado
 > <rafaelrodrigues.machado(a)gmail.com
 > <mailto:[e-mail]>> wrote:
 >
 >     Hi Peter and Rudolf.
 >     Thanks for the answers and tips. They are realy helpfull !
 >     I'll take a look.
 >
 >     Rafael R. Machado
 >
 >
 >     Em Sáb, 9 de jan de 2016 17:19, Rudolf Marek <r.marek(a)assembler.cz
 >     <mailto:[e-mail]>> escreveu:
 >
 >         Hi,
 >
 >         I guess your question is more general than the coreboot related
 >         right?
 >
 >         If you have a firmware image dump of the flash (not the file you
 >         download from
 >         board vendor) then yes, first location to be executed is the
 >         instruction located
 >         16 bytes before end of the image.
 >
 >         In coreboot see in build/ bootblock_inc.S which also has
 >         reset16.inc and
 >         entry16.inc which is a real start. Consult the Intel or AMD
 >         manual to see the
 >         CPU state after reset. The CPU starts in real mode, but CS base
 >         is shifted to
 >         last 64KB before end of 4GB address space. In general your CPU
 >         starts in
 >         compatible mode with 8086 manufactured in 1978.
 >
 >         Thanks
 >         Rudolf
 >
 >     --
 >     coreboot mailing list: coreboot(a)coreboot.org
 >     <mailto:[e-mail]>
 >     http://www.coreboot.org/mailman/listinfo/coreboot
 >
 >
 >

 --
 coreboot mailing list: coreboot(a)coreboot.org
 http://www.coreboot.org/mailman/listinfo/coreboot