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@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@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@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@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@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@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@gmail.com> wrote:
> Thanks a lot Zoran. > I will! > > Rafael > > Em seg, 25 de jul de 2016 14:13, Zoran Stojsavljevic < > zoran.stojsavljevic@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@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@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@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@gmail.com >>>> > mailto:rafaelrodrigues.machado@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@assembler.cz >>>> > mailto:r.marek@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@coreboot.org >>>> > mailto:coreboot@coreboot.org >>>> > http://www.coreboot.org/mailman/listinfo/coreboot >>>> > >>>> > >>>> > >>>> >>>> -- >>>> coreboot mailing list: coreboot@coreboot.org >>>> http://www.coreboot.org/mailman/listinfo/coreboot >>>> >>> >>> -- >>> coreboot mailing list: coreboot@coreboot.org >>> >> https://www.coreboot.org/mailman/listinfo/coreboot >>> >> >>
--
coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
-
Marc Jones