[coreboot] Where is the first instrucion?
Zoran Stojsavljevic
zoran.stojsavljevic at gmail.com
Tue Aug 9 12:23:54 CEST 2016
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/64361c0b/attachment.html>
More information about the coreboot
mailing list