[coreboot] Where is the first instrucion?
Rafael Machado
rafaelrodrigues.machado at gmail.com
Tue Aug 9 17:46:53 CEST 2016
Hi everyone
Thanks a lot for the comments Zoran!
You are totally right. The way I wrote was not clear.
At my comments I added the bit number and the name of the bit based on
intel's specification:
[image: pasted1]
Thanks for confirming this.
Just to give you a feedback and for future generation interested on this
topic.
After checking all comments from everyone and studing a little bit I found
the reason of the magic jump:
f000:0fed ffe7 jmp di ; di value is 0x113 at this point as checked
using QEMU
Several instruction before this, we have the following:
f000:0109 b0d0 mov al, 0xd0
f000:010b e680 out 0x80, al
f000:010d bf1301 mov di, 0x113
f000:0110 e9ed0d jmp 0xf0f00
f000:0113 8cc8 mov ax, cs
f000:0115 8ed8 mov ds, ax
f000:0117 8ec0 mov es, ax
So as it was pointed by you some e-mails ago, the jmps here were used to
access other "functions" (in blue), since there is no stack yet.
And that "jmp di" was the point the call returns to the starting point (in
red).
I'll continue my studies and post in case of questions. Soon I'll try to
port cb to a system I'm not using.
Thanks for the help everyone!
Em ter, 9 de ago de 2016 às 07:23, Zoran Stojsavljevic <
zoran.stojsavljevic at gmail.com> escreveu:
> Hello Rafael,
>
> Once again... About your initial email.
>
> Code you have posted (in *RED*):
>
> 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
>
> I think you have here errors commenting CD and NW. Resetting these bits
> will be the opposite what you wrote here. Namely, CD = 0 will be Cache
> Enabled and NW = 0 will be Write-Through.
>
> This code very closely matches the code in Coreboot's
> src/soc/intel/skylake/bootblock/cache_as_ram.S:
>
> Line 128:
> /* Enable variable MTRRs */
> mov $MTRR_DEF_TYPE_MSR, %ecx
> rdmsr
> or $MTRR_DEF_TYPE_EN, %eax
> wrmsr
>
> /* Enable caching */
> mov %cr0, %eax
> and $~(CR0_CD | CR0_NW), %eax
> invd
> mov %eax, %cr0
>
> Please, also look into the file mtrr.h (src/include/cpu/x86/mtrr.h) . *It
> starts making (lot of) sense... ;-)*
>
> 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/20160809/b8bee7ea/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pasted1
Type: image/png
Size: 124348 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160809/b8bee7ea/attachment-0001.png>
More information about the coreboot
mailing list