Hello Rafael, I am looking into disassembly pointed by you:
> 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 Looks very similar like sequence in Coreboot ROMSTAGE ( src/cpu/intel/car/cache_as_ram.inc): /* We don't need CAR from now on. */ /* Disable cache. */ movl %cr0, %eax orl $CR0_CacheDisable, %eax movl %eax, %cr0 /* Clear sth. */ movl $MTRR_FIX_4K_C8000, %ecx xorl %edx, %edx xorl %eax, %eax wrmsr #if CONFIG_DCACHE_RAM_SIZE > 0x8000 movl $MTRR_FIX_4K_C0000, %ecx wrmsr #endif /* * Set the default memory type and disable fixed * and enable variable MTRRs. */ movl $MTRR_DEF_TYPE_MSR, %ecx xorl %edx, %edx movl $MTRR_DEF_TYPE_EN, %eax /* Enable variable and disable fixed MTRRs. */ wrmsr /* Enable cache. */ movl %cr0, %eax andl $(~(CR0_CacheDisable | CR0_NoWriteThrough)), %eax movl %eax, %cr0 __main: Please, check upon it. Please, pass to us your comments... If any? Best Regards, Zoran On Tue, Jul 26, 2016 at 4:23 AM, Rafael Machado < [email protected]> wrote: > Thanks a lot Zoran. > I will! > > Rafael > > Em seg, 25 de jul de 2016 14:13, Zoran Stojsavljevic < > [email protected]> escreveu: > >> Hello Rafael, >> >> Let me try hard... ;-) >> >> Let us look into what actually we have here, in Coreboot: in bootblock >> phase, at the very beginning. >> Let me tell you what I am looking into (what cb tree): [zoran@localhost >> coreboot-09.06.2016]$ git describe<CR> >> 4.4-455-g538b324 >> >> Let us backtrace, to understand what is actual thread of execution: >> src/arch/x86/prologue.inc >> src/cpu/x86/16bit/entry16.inc >> src/cpu/x86/16bit/reset16.inc >> src/cpu/x86/32bit/entry32.inc >> src/cpu/x86/sse_enable.inc >> src/arch/x86/bootblock_simple.c >> >> Please, carefully examine what I pointed/presented here... And let us >> know your thoughts. >> >> Best Regards, >> Zoran >> >> On Mon, Jul 25, 2016 at 6:03 PM, Rafael Machado < >> [email protected]> 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. <[email protected]> >>> 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 >>>> > <[email protected] >>>> > <mailto:[email protected]>> 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 < >>>> [email protected] >>>> > <mailto:[email protected]>> 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: [email protected] >>>> > <mailto:[email protected]> >>>> > http://www.coreboot.org/mailman/listinfo/coreboot >>>> > >>>> > >>>> > >>>> >>>> -- >>>> coreboot mailing list: [email protected] >>>> http://www.coreboot.org/mailman/listinfo/coreboot >>>> >>> >>> -- >>> coreboot mailing list: [email protected] >>> >> https://www.coreboot.org/mailman/listinfo/coreboot >>> >> >>
-- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
