[coreboot] Where is the first instrucion?
Zoran Stojsavljevic
zoran.stojsavljevic at gmail.com
Tue Aug 2 06:31:36 CEST 2016
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: 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/20728ef9/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/20160802/20728ef9/attachment-0003.png>
-------------- 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/20728ef9/attachment-0004.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/20728ef9/attachment-0005.png>
More information about the coreboot
mailing list