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.mach...@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...@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.mach...@gmail.com >> > <mailto:rafaelrodrigues.mach...@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.ma...@assembler.cz >> > <mailto:r.ma...@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 >
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
