Re: [coreboot] Where is the first instrucion?

[Rafael Machado]

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 <
[e-mail]> 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 <
> [e-mail]> 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 <
> > [e-mail]> wrote:
> > > Thanks a lot Zoran.
> > > I will!
> > >
> > > Rafael
> > >
> > > Em seg, 25 de jul de 2016 14:13, Zoran Stojsavljevic <
> > > [e-mail]> 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@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 <
> > > > [e-mail]> 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. 
> > > > > 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
> > > > > > > <[e-mail]
> > > > > > > > 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 <
> > > > > > [e-mail]
> > > > > > >     > 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: [e-mail]
> > > > > > >     
> > > > > > >     http://www.coreboot.org/mailman/listinfo/coreboot
> > > > > > >
> > > > > > >
> > > > > > >
> > > >
> > > > https://www.coreboot.org/mailman/listinfo/coreboot
> > > > >