<div dir="ltr">Hi guys. Long time since my last e-mail.<div><br><div>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 :)</div><div><br></div><div>Since the last talk I was doing what everyone kindly proposed. (by the way thank you all for the guidance.)</div><div><br></div><div>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)</div><div><br></div><div>The code is:</div><div><br></div><div><div>f000:0fcb     66b9ff020000    mov ecx, 0x2ff</div><div>f000:0fd1     0f32                 rdmsr             ; read register 0x2ff (IA32_MTRR_DEF_TYPE)</div><div>f000:0fd3     0fbae80b          bts ax, 0xb     ; Enable bit 11 (MTRR Enable).</div><div>f000:0fd7     0fbae80a          bts ax, 0xa     ; Enable bit 10 (Fixed MTRR Enable).</div><div>f000:0fdb     0f30                 wrmsr            ; Write changes to MTRR</div><div>f000:0fdd     0f20c0             mov eax, cr0</div><div>f000:0fe0     660fbaf01e       btr eax, 0x1e   ; Bit 30 means CD - Cache disabled.</div><div>f000:0fe5     660fbaf01d       btr eax, 0x1d   ; Disable bit 29. NW - No Write-through</div><div>f000:0fea     0f22c0             mov cr0, eax   ; Write changes to CR0</div><div>f000:0fed     ffe7                  jmp di</div><div>f000:0fef     0f20c0              mov eax, cr0</div><div>f000:0ff2     660fbae81e       bts eax, 0x1e</div><div>f000:0ff7     660fbae81d       bts eax, 0x1d</div><div>f000:0ffc     0f22c0              mov cr0, eax</div><div><br></div></div><div><br></div><div>Here is the code with my notes. I understand that some MTRR were set, and now the processor will be "configured".</div><div>We see at address <span style="line-height:1.5">f000:0fe0 and </span><span style="line-height:1.5">f000:0fe5 that the CR0 register is being changed and after that the changes are saved.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Now I have two questions.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">1 - After CR0 changes get completed there is a "jmp di" instruction. This does not make any </span>sense<span style="line-height:1.5"> to me. Does anyone know why this is needed ? As far as I could check di value is 0x0 at this point. I think</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">2 - After the "jmp di" a "CR0 Déjà vu" code is executed. Any idea why this is needed ?</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Thanks everyone</span></div><div><span style="line-height:1.5">Rafael R. Machado</span></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">Em seg, 11 de jan de 2016 às 03:57, Alex G. <<a href="mailto:mr.nuke.me@gmail.com">mr.nuke.me@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 01/10/2016 10:23 AM, ron minnich wrote:<br>
> One thing I think you'd enjoy doing is building the qemu target, setting<br>
> up qemu with gdb, and just watching what happens, instruction by<br>
> instruction, as the system boots.<br>
<br>
One exercise I liked doing was to rewrite the entire boot flow, from<br>
reset vector to protected mode entry. Tested on qemu, put it on<br>
hardware, nothing burned.<br>
<br>
Alex<br>
<br>
> ron<br>
><br>
> On Sun, Jan 10, 2016 at 3:28 AM Rafael Machado<br>
> <<a href="mailto:rafaelrodrigues.machado@gmail.com" target="_blank">rafaelrodrigues.machado@gmail.com</a><br>
> <mailto:<a href="mailto:rafaelrodrigues.machado@gmail.com" target="_blank">rafaelrodrigues.machado@gmail.com</a>>> wrote:<br>
><br>
>     Hi Peter and Rudolf.<br>
>     Thanks for the answers and tips. They are realy helpfull !<br>
>     I'll take a look.<br>
><br>
>     Rafael R. Machado<br>
><br>
><br>
>     Em Sáb, 9 de jan de 2016 17:19, Rudolf Marek <<a href="mailto:r.marek@assembler.cz" target="_blank">r.marek@assembler.cz</a><br>
>     <mailto:<a href="mailto:r.marek@assembler.cz" target="_blank">r.marek@assembler.cz</a>>> escreveu:<br>
><br>
>         Hi,<br>
><br>
>         I guess your question is more general than the coreboot related<br>
>         right?<br>
><br>
>         If you have a firmware image dump of the flash (not the file you<br>
>         download from<br>
>         board vendor) then yes, first location to be executed is the<br>
>         instruction located<br>
>         16 bytes before end of the image.<br>
><br>
>         In coreboot see in build/ bootblock_inc.S which also has<br>
>         reset16.inc and<br>
>         entry16.inc which is a real start. Consult the Intel or AMD<br>
>         manual to see the<br>
>         CPU state after reset. The CPU starts in real mode, but CS base<br>
>         is shifted to<br>
>         last 64KB before end of 4GB address space. In general your CPU<br>
>         starts in<br>
>         compatible mode with 8086 manufactured in 1978.<br>
><br>
>         Thanks<br>
>         Rudolf<br>
><br>
>     --<br>
>     coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
>     <mailto:<a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a>><br>
>     <a href="http://www.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">http://www.coreboot.org/mailman/listinfo/coreboot</a><br>
><br>
><br>
><br>
<br>
--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
<a href="http://www.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">http://www.coreboot.org/mailman/listinfo/coreboot</a><br>
</blockquote></div>