[coreboot] Where is the first instrucion?
Rafael Machado
rafaelrodrigues.machado at gmail.com
Wed Jul 27 14:56:25 CEST 2016
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 <
zoran.stojsavljevic at gmail.com> 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 <
> 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/0beb294d/attachment.html>
More information about the coreboot
mailing list