Hello Rafael,
Once again... About your initial email.
Code you have posted (in *RED*):
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
I think you have here errors commenting CD and NW. Resetting these bits will be the opposite what you wrote here. Namely, CD = 0 will be Cache Enabled and NW = 0 will be Write-Through.
This code very closely matches the code in Coreboot's src/soc/intel/skylake/ bootblock/cache_as_ram.S:
Line 128: /* Enable variable MTRRs */ mov $MTRR_DEF_TYPE_MSR, %ecx rdmsr or $MTRR_DEF_TYPE_EN, %eax wrmsr
/* Enable caching */ mov %cr0, %eax and $~(CR0_CD | CR0_NW), %eax invd mov %eax, %cr0
Please, also look into the file mtrr.h (src/include/cpu/x86/mtrr.h) . *It starts making (lot of) sense... ;-)*
Zoran
On Mon, Jul 25, 2016 at 6:03 PM, Rafael Machado < rafaelrodrigues.machado@gmail.com> wrote:
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@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@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@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@coreboot.org <mailto:coreboot@coreboot.org> http://www.coreboot.org/mailman/listinfo/coreboot-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
-
Zoran Stojsavljevic