Thanks a lot Zoran. I will! Rafael
Em seg, 25 de jul de 2016 14:13, Zoran Stojsavljevic < zoran.stojsavlje...@gmail.com> 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 < > 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