[coreboot] Where is the first instrucion?

Tue Jul 26 04:23:41 CEST 2016

Thanks a lot Zoran.
I will!

Rafael

Em seg, 25 de jul de 2016 14:13, Zoran Stojsavljevic <
zoran.stojsavljevic at 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 at 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.machado at 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.me at 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.machado at gmail.com
>>> > <mailto:rafaelrodrigues.machado at 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.marek at assembler.cz
>>> >     <mailto:r.marek at 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 at coreboot.org
>>> >     <mailto:coreboot at coreboot.org>
>>> >     http://www.coreboot.org/mailman/listinfo/coreboot
>>> >
>>> >
>>> >
>>>
>>> --
>>> coreboot mailing list: coreboot at coreboot.org
>>> http://www.coreboot.org/mailman/listinfo/coreboot
>>>
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>>
> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160726/06a1bd6e/attachment.html>