[coreboot] Where is the first instrucion?
Rafael Machado
rafaelrodrigues.machado at gmail.com
Tue Aug 2 13:46:51 CEST 2016
Hi everyone / Zoran
Thanks Zoran for the comments and don't worry about the name replacement :)
Just to clarify my question.
I already got to the same conclusion as you mentioned about the jmp
instructions. (So your comments are well received because I see that I got
how things are working)
What I would like to understand now, is why I don't see the same
instructions at GDB and Radare2
[image: pasted3]
At this point. if I step gdb one more instruction I get to the following:
[image: pasted5]
So at GDB I can see that the code that is being executed follow the flow
that I can see at radare2.
The final question is:
Why can't I see the same disassembled code at GDB and radare2 ?
Do I need to execute some magic command at gdb besides these?
set disassembly-flavor intel
set architecture i8086
target remote localhost:1234
Thanks everyone for the help
Rafael R. Machado
Em ter, 2 de ago de 2016 às 01:31, Zoran Stojsavljevic <
zoran.stojsavljevic at gmail.com> escreveu:
> Sorry, Rafael (do not know why I wrote Daniel)???
>
> Zoran
>
> On Tue, Aug 2, 2016 at 6:30 AM, Zoran Stojsavljevic <
> zoran.stojsavljevic at gmail.com> wrote:
>
>> 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: image.png]
>>
>> 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/889e4d10/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pasted1
Type: application/octet-stream
Size: 247823 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160802/889e4d10/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/x-png
Size: 9145 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160802/889e4d10/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pasted2
Type: application/octet-stream
Size: 9145 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160802/889e4d10/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pasted3
Type: image/png
Size: 109232 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160802/889e4d10/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pasted5
Type: image/png
Size: 16294 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160802/889e4d10/attachment-0003.png>
More information about the coreboot
mailing list