[coreboot] Where is the first instrucion?
Rafael Machado
rafaelrodrigues.machado at gmail.com
Mon Aug 1 19:40:40 CEST 2016
Hi everyone
I'm studying one firmware and to do that, as we talked on previous e-mail,
I was using the Radare2.
At a given point I faced a "jmp di" instruction and I would like to know
the value at a given register to understand
where the jmp is going to.
To do that I'm using Qemu, so I can check everything happening on the fly.
The problem I'm having now, is that the disas instruction at GDB is not
working as I expected.
[image: pasted1]
gdb output
The strange thing, is that when I compare the code flow, it really seems to
do what I see at the Radare2 (except the fact that Qemu does not use the
segment registers, but this is not a problem), but the gdb disas command
doesn't present the code as I see at Radare2.
[image: pasted2]
radare2 output
I did the following commands at gdb:
set disassembly-flavor intel
set architecture i8086
target remote localhost:1234
I searched on the internet ways to debug real-mode code, but didn't find
any similar problem yet.
Does anyone have a guess of how could I solve this situation?
Thanks and Regards
Rafael R. Machado
Em qua, 27 de jul de 2016 às 09:56, Rafael Machado <
rafaelrodrigues.machado at gmail.com> escreveu:
> 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/20160801/17cc5d81/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pasted1
Type: image/png
Size: 247823 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160801/17cc5d81/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pasted2
Type: image/png
Size: 9145 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160801/17cc5d81/attachment-0003.png>
More information about the coreboot
mailing list