Re: [coreboot] Where is the first instrucion?

[Rafael Machado]

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 <
[e-mail]> escreveu:
> Sorry, Rafael (do not know why I wrote Daniel)???
>
> Zoran
>
> On Tue, Aug 2, 2016 at 6:30 AM, Zoran Stojsavljevic <
> [e-mail]> 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 <
> > [e-mail]> 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 <
> > > [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
> > > > > > >>> >
> > > > > > >>> >
> > > > > > >>> >
> > > > > > >>>
> > > > > > >>> --
> > > > > > >>> coreboot mailing list: [e-mail]
> > > > > > >>> http://www.coreboot.org/mailman/listinfo/coreboot
> > > > > > >>>
> > > > > > >>
> > > > > > >> --
> > > > > > >> coreboot mailing list: [e-mail]
> > > > > > >>
> > > > > > > https://www.coreboot.org/mailman/listinfo/coreboot
> > > > > > >>
> > > > > > >
> > > > > > >