[coreboot] Where is the first instrucion?

Zoran Stojsavljevic zoran.stojsavljevic at gmail.com
Wed Jul 27 13:17:00 CEST 2016


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 <
rafaelrodrigues.machado at gmail.com> wrote:

> 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/20160727/ce8ea6c7/attachment.html>


More information about the coreboot mailing list