[coreboot] Where is the first instrucion?

Zoran Stojsavljevic zoran.stojsavljevic at gmail.com
Tue Aug 2 06:30:38 CEST 2016


Hello Daniel,

I do not know if my answer will help you, but this what you see (I assume)
in radare2 (which I am not aware of this package, I used in 1990/1991 to do
lot of 8051 disassembling, namely INTEL 8052AH/80C52 8KB embedded BASIC -
even wrote two part article in Elector Electronics about bugs and fixes in
BASIC floating point):

[image: Inline image 1]

What I see here is the following: your CPU is in real 16-bit mode, using
20-bit memory (old x8086 1MB legacy), namely you are peaking into some jmp
table, sort of (seems, function calls one after another, but no memory
available, thus no stack)... You have here 3 byte short relative jumps one
after another, with 16-bit Code Segment and 16-bit Instruction Pointer
(example: CS -> 0xF000, IP -> 0x0040, which gives you the real 20-bit
0xF0000 + 0x00040 = 0xF0040 address), with short jump opcode (0xE9)  and
offset (in little endian format) to be added to current IP (pointing
already to the next instruction).

This is at the very beginning of your BIOS (presumably), since as my best
knowledge is, you need to jump from the initial location 0xF000:FFF0
somewhere back and switch from 16-bit Real to 32-bit Protected mode for CPU
to continue to execute (this code seems still to set/prepare some required
FW context in 16-bit mode).

Hope this helps,
Zoran

On Mon, Aug 1, 2016 at 7:40 PM, Rafael Machado <
rafaelrodrigues.machado at gmail.com> wrote:

> 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/20160802/4f270d18/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 9145 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160802/4f270d18/attachment-0003.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/20160802/4f270d18/attachment-0004.png>
-------------- 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/20160802/4f270d18/attachment-0005.png>


More information about the coreboot mailing list