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> 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:rafaelrodrigues.machado@gmail.com>> 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:r.marek@assembler.cz>> 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:coreboot@coreboot.org>
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: coreboot(a)coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot