Hi Zoran, thanks a lot for expending your time to help! I'll take a look. (It may take some time, but I will! )
Rafael R. Machado Em qua, 27 de jul de 2016 às 08:17, Zoran Stojsavljevic < [email protected]> escreveu: > 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
