[coreboot] Where is the first instrucion?
Marc Jones
marcj303 at gmail.com
Wed Aug 3 02:08:51 CEST 2016
Hi Rafael,
This is a common problem for gdb (as your google search told you). Someone
would need to add real mode (seg:offset etc) to the gdb-stub. As you point
out, other tools are better at doing the real mode disassembly.
Don't get too hung up on the real mode part, it switches modes pretty quick
and you can get on with your day. This shouldn't hinder your understanding
of the boot flow too much, now.
This person seems has a good description of the issue and a script that
might help. http://ternet.fr/?p=gdb_real_mode
Marc
On Tue, Aug 2, 2016 at 5:48 AM Rafael Machado <
rafaelrodrigues.machado at gmail.com> wrote:
> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>> --
> coreboot mailing list: coreboot at coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
--
http://marcjonesconsulting.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160803/2acc0661/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/20160803/2acc0661/attachment-0002.obj>
-------------- 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/20160803/2acc0661/attachment-0003.png>
-------------- 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/20160803/2acc0661/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/20160803/2acc0661/attachment-0004.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/20160803/2acc0661/attachment-0005.png>
More information about the coreboot
mailing list