coreboot August 2016

coreboot@coreboot.org

53 participants
132 discussions

Re: [coreboot] Where is the first instrucion?
by Marc Jones 03 Aug '16

03 Aug '16

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

1 0

Re: [coreboot] Sequence of the Excution of the drivers in Coreboot
by Zoran Stojsavljevic 02 Aug '16

02 Aug '16

Hello Alok, >From another @ thread, you might also be interested in (few @ threads below): [coreboot] Where is the first instruction? *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 Tue, Aug 2, 2016 at 6:58 PM, Alok Kumar <alok.uefi.coreboot(a)gmail.com> wrote: > Hi All, > Previosly I have worked in the UEFI- BIOS and just now I have started > with Core boot. Like In the BIOS we have startup.asm the very first file > which will get execute in the UEFI BIOS. IN the same way I want to know > which is the first driver/file will get executed in the coreboot in the > case if we are using Intel Platform. > > Please guide me how can I identify the sequence of the drivers getting > executed in the coreboot. > > Regards > Alok > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Sequence of the Excution of the drivers in Coreboot
by Alok Kumar 02 Aug '16

02 Aug '16

Hi All, Previosly I have worked in the UEFI- BIOS and just now I have started with Core boot. Like In the BIOS we have startup.asm the very first file which will get execute in the UEFI BIOS. IN the same way I want to know which is the first driver/file will get executed in the coreboot in the case if we are using Intel Platform. Please guide me how can I identify the sequence of the drivers getting executed in the coreboot. Regards Alok

1 0

Re: [coreboot] Where is the first instrucion?
by Rafael Machado 02 Aug '16

02 Aug '16

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

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 02 Aug '16

02 Aug '16

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 56 new defect(s) introduced to coreboot found with Coverity Scan. 52 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 20 of 56 defect(s) ** CID 1361056: Memory - illegal accesses (OVERRUN) /dev/cb-build/coreboot-coverity.0/AMD_LAMAR/agesa/amdlib.c: 1411 in IdsErrorStop() ________________________________________________________________________________________________________ *** CID 1361056: Memory - illegal accesses (OVERRUN) /dev/cb-build/coreboot-coverity.0/AMD_LAMAR/agesa/amdlib.c: 1411 in IdsErrorStop() 1405 } post = {0xDEAD, FileCode, 0xDEAD, FileCode}; 1406 UINT16 offset = 0; 1407 UINT16 j; 1408 1409 while(1) { 1410 offset %= sizeof(struct POST) / 2; >>> CID 1361056: Memory - illegal accesses (OVERRUN) >>> Overrunning array of 3 4-byte elements at element index 15 (byte offset 60) by dereferencing pointer "(UINT32 *)(&post + offset)". 1411 WriteIo32(80, *((UINT32*)(&post+offset))); 1412 ++offset; 1413 for (j=0; j<250; ++j) { 1414 ReadIo8(80); 1415 } 1416 } ** CID 1361055: (OVERRUN) /dev/cb-build/coreboot-coverity.0/AMD_OLIVEHILLPLUS/agesa/amdlib.c: 1411 in IdsErrorStop() /dev/cb-build/coreboot-coverity.0/ODE_E21XX/agesa/amdlib.c: 1411 in IdsErrorStop() /dev/cb-build/coreboot-coverity.0/AMD_DB_FT3B_LC/agesa/amdlib.c: 1411 in IdsErrorStop() ________________________________________________________________________________________________________ *** CID 1361055: (OVERRUN) /dev/cb-build/coreboot-coverity.0/AMD_OLIVEHILLPLUS/agesa/amdlib.c: 1411 in IdsErrorStop() 1405 } post = {0xDEAD, FileCode, 0xDEAD, FileCode}; 1406 UINT16 offset = 0; 1407 UINT16 j; 1408 1409 while(1) { 1410 offset %= sizeof(struct POST) / 2; >>> CID 1361055: (OVERRUN) >>> Overrunning array of 3 4-byte elements at element index 15 (byte offset 60) by dereferencing pointer "(UINT32 *)(&post + offset)". 1411 WriteIo32(80, *((UINT32*)(&post+offset))); 1412 ++offset; 1413 for (j=0; j<250; ++j) { 1414 ReadIo8(80); 1415 } 1416 } /dev/cb-build/coreboot-coverity.0/ODE_E21XX/agesa/amdlib.c: 1411 in IdsErrorStop() 1405 } post = {0xDEAD, FileCode, 0xDEAD, FileCode}; 1406 UINT16 offset = 0; 1407 UINT16 j; 1408 1409 while(1) { 1410 offset %= sizeof(struct POST) / 2; >>> CID 1361055: (OVERRUN) >>> Overrunning array of 3 4-byte elements at element index 15 (byte offset 60) by dereferencing pointer "(UINT32 *)(&post + offset)". 1411 WriteIo32(80, *((UINT32*)(&post+offset))); 1412 ++offset; 1413 for (j=0; j<250; ++j) { 1414 ReadIo8(80); 1415 } 1416 } /dev/cb-build/coreboot-coverity.0/AMD_DB_FT3B_LC/agesa/amdlib.c: 1411 in IdsErrorStop() 1405 } post = {0xDEAD, FileCode, 0xDEAD, FileCode}; 1406 UINT16 offset = 0; 1407 UINT16 j; 1408 1409 while(1) { 1410 offset %= sizeof(struct POST) / 2; >>> CID 1361055: (OVERRUN) >>> Overrunning array of 3 4-byte elements at element index 15 (byte offset 60) by dereferencing pointer "(UINT32 *)(&post + offset)". 1411 WriteIo32(80, *((UINT32*)(&post+offset))); 1412 ++offset; 1413 for (j=0; j<250; ++j) { 1414 ReadIo8(80); 1415 } 1416 } ** CID 1361054: Memory - illegal accesses (OVERRUN) /dev/cb-build/coreboot-coverity.0/AMD_BETTONG/agesa/amdlib.c: 1411 in IdsErrorStop() ________________________________________________________________________________________________________ *** CID 1361054: Memory - illegal accesses (OVERRUN) /dev/cb-build/coreboot-coverity.0/AMD_BETTONG/agesa/amdlib.c: 1411 in IdsErrorStop() 1405 } post = {0xDEAD, FileCode, 0xDEAD, FileCode}; 1406 UINT16 offset = 0; 1407 UINT16 j; 1408 1409 while(1) { 1410 offset %= sizeof(struct POST) / 2; >>> CID 1361054: Memory - illegal accesses (OVERRUN) >>> Overrunning array of 3 4-byte elements at element index 15 (byte offset 60) by dereferencing pointer "(UINT32 *)(&post + offset)". 1411 WriteIo32(80, *((UINT32*)(&post+offset))); 1412 ++offset; 1413 for (j=0; j<250; ++j) { 1414 ReadIo8(80); 1415 } 1416 } ** CID 1353785: (OVERRUN) /3rdparty/chromeec/common/fan.c: 380 in hc_pwm_set_fan_duty() /3rdparty/chromeec/common/fan.c: 373 in hc_pwm_set_fan_duty() ________________________________________________________________________________________________________ *** CID 1353785: (OVERRUN) /3rdparty/chromeec/common/fan.c: 380 in hc_pwm_set_fan_duty() 374 set_duty_cycle(fan, p_v0->percent); 375 376 return EC_RES_SUCCESS; 377 } 378 379 fan = p_v1->fan_idx; >>> CID 1353785: (OVERRUN) >>> Checking "fan >= 2" implies that "fan" and "p_v1->fan_idx" may be up to 1 on the false branch. 380 if (fan >= CONFIG_FANS) 381 return EC_RES_ERROR; 382 383 set_duty_cycle(fan, p_v1->percent); 384 385 return EC_RES_SUCCESS; /3rdparty/chromeec/common/fan.c: 373 in hc_pwm_set_fan_duty() 367 { 368 const struct ec_params_pwm_set_fan_duty_v1 *p_v1 = args->params; 369 const struct ec_params_pwm_set_fan_duty_v0 *p_v0 = args->params; 370 int fan; 371 372 if (args->version == 0) { >>> CID 1353785: (OVERRUN) >>> Checking "fan < 2" implies that "fan" may be up to 1 on the true branch. 373 for (fan = 0; fan < CONFIG_FANS; fan++) 374 set_duty_cycle(fan, p_v0->percent); 375 376 return EC_RES_SUCCESS; 377 } 378 ** CID 1353782: Memory - corruptions (OVERRUN) /3rdparty/chromeec/common/fan.c: 307 in dptf_set_fan_duty_target() ________________________________________________________________________________________________________ *** CID 1353782: Memory - corruptions (OVERRUN) /3rdparty/chromeec/common/fan.c: 307 in dptf_set_fan_duty_target() 301 if (pct < 0 || pct > 100) { 302 /* TODO(crosbug.com/p/23803) */ 303 for (fan = 0; fan < CONFIG_FANS; fan++) 304 set_thermal_control_enabled(fan, 1); 305 } else { 306 /* TODO(crosbug.com/p/23803) */ >>> CID 1353782: Memory - corruptions (OVERRUN) >>> Checking "fan < 2" implies that "fan" may be up to 1 on the true branch. 307 for (fan = 0; fan < CONFIG_FANS; fan++) 308 set_duty_cycle(fan, pct); 309 } 310 } 311 312 /*****************************************************************************/ ** CID 1353361: Code maintainability issues (UNUSED_VALUE) /3rdparty/chromeec/driver/accelgyro_bmi160.c: 382 in set_data_rate() ________________________________________________________________________________________________________ *** CID 1353361: Code maintainability issues (UNUSED_VALUE) /3rdparty/chromeec/driver/accelgyro_bmi160.c: 382 in set_data_rate() 376 if (s->type == MOTIONSENSE_TYPE_MAG) 377 moc->batch_size = 0; 378 #endif 379 return ret; 380 } else if (data->odr == 0) { 381 /* back from suspend mode. */ >>> CID 1353361: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "raw_write8(s->addr, 126, 0x10U | (s->type << 2) | 1U)" to "ret" here, but that stored value is overwritten before it can be used. 382 ret = raw_write8(s->addr, BMI160_CMD_REG, 383 BMI160_CMD_MODE_NORMAL(s->type)); 384 msleep(wakeup_time[s->type]); 385 } 386 ctrl_reg = BMI160_CONF_REG(s->type); 387 reg_val = BMI160_ODR_TO_REG(rate); ** CID 1353360: Code maintainability issues (UNUSED_VALUE) /3rdparty/chromeec/driver/pmu_tps65090.c: 680 in command_pmu() ________________________________________________________________________________________________________ *** CID 1353360: Code maintainability issues (UNUSED_VALUE) /3rdparty/chromeec/driver/pmu_tps65090.c: 680 in command_pmu() 674 ccputs("Invalid repeat count\n"); 675 return EC_ERROR_INVAL; 676 } 677 } 678 679 for (loop = 0; loop < repeat; loop++) { >>> CID 1353360: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "print_pmu_info()" to "rv" here, but that stored value is overwritten before it can be used. 680 rv = print_pmu_info(); 681 usleep(1000); 682 } 683 684 rv = pmu_read(IRQ1_REG, &value); 685 if (rv) ** CID 1353357: Control flow issues (UNREACHABLE) /3rdparty/chromeec/common/charge_manager.c: 625 in charge_manager_make_change() ________________________________________________________________________________________________________ *** CID 1353357: Control flow issues (UNREACHABLE) /3rdparty/chromeec/common/charge_manager.c: 625 in charge_manager_make_change() 619 */ 620 #ifndef CONFIG_CHARGE_MANAGER_DRP_CHARGING 621 if (dualrole_capability[port] != CAP_DEDICATED) 622 #endif 623 return; 624 /* Clear override only if a charge is present on the port */ >>> CID 1353357: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "i = 0;". 625 for (i = 0; i < CHARGE_SUPPLIER_COUNT; ++i) 626 if (available_charge[i][port].current > 0) { 627 clear_override = 1; 628 break; 629 } 630 /* ** CID 1353355: (UNINIT) /3rdparty/chromeec/board/oak/board.c: 470 in vbus_task() /3rdparty/chromeec/board/oak/board.c: 464 in vbus_task() /3rdparty/chromeec/board/oak/board.c: 458 in vbus_task() /3rdparty/chromeec/board/oak/board.c: 446 in vbus_task() ________________________________________________________________________________________________________ *** CID 1353355: (UNINIT) /3rdparty/chromeec/board/oak/board.c: 470 in vbus_task() 464 if (reg != bc12[port].device_type) { 465 bc12[port].device_type = reg; 466 wake++; 467 } 468 469 reg = pi3usb9281_get_charger_status(port); >>> CID 1353355: (UNINIT) >>> Using uninitialized value "bc12[port].charger_status". 470 if (reg != bc12[port].charger_status) { 471 bc12[port].charger_status = reg; 472 wake++; 473 } 474 475 if (wake) /3rdparty/chromeec/board/oak/board.c: 464 in vbus_task() 458 if (reg != bc12[port].interrupt) { 459 bc12[port].interrupt = reg; 460 wake++; 461 } 462 463 reg = pi3usb9281_get_device_type(port); >>> CID 1353355: (UNINIT) >>> Using uninitialized value "bc12[port].device_type". 464 if (reg != bc12[port].device_type) { 465 bc12[port].device_type = reg; 466 wake++; 467 } 468 469 reg = pi3usb9281_get_charger_status(port); /3rdparty/chromeec/board/oak/board.c: 458 in vbus_task() 452 bc12[port].vbus |= 1 << port; 453 else 454 bc12[port].vbus &= ~(1 << port); 455 456 wake = 0; 457 reg = pi3usb9281_get_interrupts(port); >>> CID 1353355: (UNINIT) >>> Using uninitialized value "bc12[port].interrupt". 458 if (reg != bc12[port].interrupt) { 459 bc12[port].interrupt = reg; 460 wake++; 461 } 462 463 reg = pi3usb9281_get_device_type(port); /3rdparty/chromeec/board/oak/board.c: 446 in vbus_task() 440 vbus = !gpio_get_level(port ? GPIO_USB_C1_VBUS_WAKE_L : 441 GPIO_USB_C0_VBUS_WAKE_L); 442 #else 443 vbus = tcpm_get_vbus_level(port); 444 #endif 445 /* check if VBUS changed */ >>> CID 1353355: (UNINIT) >>> Using uninitialized value "bc12[port].vbus". 446 if (((bc12[port].vbus >> port) & 1) == vbus) 447 continue; 448 /* wait 1.2 seconds and check BC 1.2 status */ 449 msleep(1200); 450 451 if (vbus) ** CID 1353346: Memory - illegal accesses (OVERRUN) /3rdparty/chromeec/chip/lm4/pwm.c: 63 in pwm_init() ________________________________________________________________________________________________________ *** CID 1353346: Memory - illegal accesses (OVERRUN) /3rdparty/chromeec/chip/lm4/pwm.c: 63 in pwm_init() 57 58 static void pwm_init(void) 59 { 60 int i; 61 62 for (i = 0; i < PWM_CH_COUNT; ++i) >>> CID 1353346: Memory - illegal accesses (OVERRUN) >>> Overrunning array "pwm_channels" of 1 8-byte elements at element index 1 (byte offset 8) using index "i" (which evaluates to 1). 63 fan_channel_setup(pwm_channels[i].channel, 64 (pwm_channels[i].flags & 65 PWM_CONFIG_HAS_RPM_MODE) 66 ? FAN_USE_RPM_MODE : 0); 67 } 68 69 /* The chip-specific fan module initializes before this. */ ** CID 1353342: (OVERRUN) /3rdparty/chromeec/common/pwm.c: 41 in cc_pwm_duty() /3rdparty/chromeec/common/pwm.c: 41 in cc_pwm_duty() /3rdparty/chromeec/common/pwm.c: 35 in cc_pwm_duty() ________________________________________________________________________________________________________ *** CID 1353342: (OVERRUN) /3rdparty/chromeec/common/pwm.c: 41 in cc_pwm_duty() 35 for (ch = 0; ch < PWM_CH_COUNT; ch++) 36 print_channel(ch); 37 return EC_SUCCESS; 38 } 39 40 ch = strtoi(argv[1], &e, 0); >>> CID 1353342: (OVERRUN) >>> Checking "ch >= PWM_CH_COUNT" implies that "ch" is between 0 and 2 (inclusive) on the false branch. 41 if (*e || ch < 0 || ch >= PWM_CH_COUNT) 42 return EC_ERROR_PARAM1; 43 44 if (argc > 2) { 45 percent = strtoi(argv[2], &e, 0); 46 if (*e || percent > 100) { /3rdparty/chromeec/common/pwm.c: 41 in cc_pwm_duty() 35 for (ch = 0; ch < PWM_CH_COUNT; ch++) 36 print_channel(ch); 37 return EC_SUCCESS; 38 } 39 40 ch = strtoi(argv[1], &e, 0); >>> CID 1353342: (OVERRUN) >>> Checking "ch >= PWM_CH_COUNT" implies that "ch" is between 0 and 2 (inclusive) on the false branch. 41 if (*e || ch < 0 || ch >= PWM_CH_COUNT) 42 return EC_ERROR_PARAM1; 43 44 if (argc > 2) { 45 percent = strtoi(argv[2], &e, 0); 46 if (*e || percent > 100) { /3rdparty/chromeec/common/pwm.c: 35 in cc_pwm_duty() 29 int percent = 0; 30 int ch; 31 char *e; 32 33 if (argc < 2) { 34 ccprintf("PWM channels:\n"); >>> CID 1353342: (OVERRUN) >>> Checking "ch < PWM_CH_COUNT" implies that "ch" may be up to 2 on the true branch. 35 for (ch = 0; ch < PWM_CH_COUNT; ch++) 36 print_channel(ch); 37 return EC_SUCCESS; 38 } 39 40 ch = strtoi(argv[1], &e, 0); ** CID 1353340: (OVERRUN) ________________________________________________________________________________________________________ *** CID 1353340: (OVERRUN) /3rdparty/chromeec/common/adc.c: 49 in command_adc() 43 if (v == ADC_READ_ERROR) 44 return EC_ERROR_UNKNOWN; 45 ccprintf(" %s = %d\n", adc_channels[i].name, v); 46 return EC_SUCCESS; 47 } else { 48 /* Otherwise print them all */ >>> CID 1353340: (OVERRUN) >>> Overrunning array "data" of 8 bytes by passing it to a function which accesses it at byte offset 12. 49 if (adc_read_all_channels(data)) 50 return EC_ERROR_UNKNOWN; 51 for (i = 0; i < ADC_CH_COUNT; ++i) 52 ccprintf(" %s = %d\n", adc_channels[i].name, data[i]); 53 return EC_SUCCESS; 54 } /3rdparty/chromeec/common/adc.c: 49 in command_adc() 43 if (v == ADC_READ_ERROR) 44 return EC_ERROR_UNKNOWN; 45 ccprintf(" %s = %d\n", adc_channels[i].name, v); 46 return EC_SUCCESS; 47 } else { 48 /* Otherwise print them all */ >>> CID 1353340: (OVERRUN) >>> Overrunning array "data" of 12 bytes by passing it to a function which accesses it at byte offset 12. 49 if (adc_read_all_channels(data)) 50 return EC_ERROR_UNKNOWN; 51 for (i = 0; i < ADC_CH_COUNT; ++i) 52 ccprintf(" %s = %d\n", adc_channels[i].name, data[i]); 53 return EC_SUCCESS; 54 } /3rdparty/chromeec/common/adc.c: 49 in command_adc() 43 if (v == ADC_READ_ERROR) 44 return EC_ERROR_UNKNOWN; 45 ccprintf(" %s = %d\n", adc_channels[i].name, v); 46 return EC_SUCCESS; 47 } else { 48 /* Otherwise print them all */ >>> CID 1353340: (OVERRUN) >>> Overrunning array "data" of 4 bytes by passing it to a function which accesses it at byte offset 12. 49 if (adc_read_all_channels(data)) 50 return EC_ERROR_UNKNOWN; 51 for (i = 0; i < ADC_CH_COUNT; ++i) 52 ccprintf(" %s = %d\n", adc_channels[i].name, data[i]); 53 return EC_SUCCESS; 54 } ** CID 1353339: Memory - illegal accesses (OVERRUN) /3rdparty/chromeec/common/adc.c: 52 in command_adc() ________________________________________________________________________________________________________ *** CID 1353339: Memory - illegal accesses (OVERRUN) /3rdparty/chromeec/common/adc.c: 52 in command_adc() 46 return EC_SUCCESS; 47 } else { 48 /* Otherwise print them all */ 49 if (adc_read_all_channels(data)) 50 return EC_ERROR_UNKNOWN; 51 for (i = 0; i < ADC_CH_COUNT; ++i) >>> CID 1353339: Memory - illegal accesses (OVERRUN) >>> Overrunning array "adc_channels" of 4 20-byte elements at element index 4 (byte offset 80) using index "i" (which evaluates to 4). 52 ccprintf(" %s = %d\n", adc_channels[i].name, data[i]); 53 return EC_SUCCESS; 54 } 55 } 56 DECLARE_CONSOLE_COMMAND(adc, command_adc, 57 "[name]", 58 "Print ADC channel(s)", 59 NULL); ** CID 1353338: Memory - illegal accesses (OVERRUN) /3rdparty/chromeec/common/adc.c: 25 in find_adc_channel_by_name() ________________________________________________________________________________________________________ *** CID 1353338: Memory - illegal accesses (OVERRUN) /3rdparty/chromeec/common/adc.c: 25 in find_adc_channel_by_name() 19 int i; 20 21 if (!name || !*name) 22 return ADC_CH_COUNT; 23 24 for (i = 0; i < ADC_CH_COUNT; i++, ch++) { >>> CID 1353338: Memory - illegal accesses (OVERRUN) >>> Overrunning array of 4 20-byte elements at element index 4 (byte offset 80) by dereferencing pointer "ch". 25 if (!strcasecmp(name, ch->name)) 26 return i; 27 } 28 29 return ADC_CH_COUNT; 30 } ** CID 1353324: Memory - corruptions (OVERRUN) /3rdparty/chromeec/driver/temp_sensor/bd99992gw.c: 74 in bd99992gw_init() ________________________________________________________________________________________________________ *** CID 1353324: Memory - corruptions (OVERRUN) /3rdparty/chromeec/driver/temp_sensor/bd99992gw.c: 74 in bd99992gw_init() 68 69 /* Make sure we don't have too many active channels. */ 70 ASSERT(active_channel_count <= ARRAY_SIZE(active_channels)); 71 72 /* Mark the first unused channel so we know where to stop searching */ 73 if (active_channel_count != ARRAY_SIZE(active_channels)) >>> CID 1353324: Memory - corruptions (OVERRUN) >>> Overrunning array "active_channels" of 8 4-byte elements at element index 9 (byte offset 36) using index "active_channel_count" (which evaluates to 9). 74 active_channels[active_channel_count] = 75 BD99992GW_ADC_CHANNEL_NONE; 76 77 /* Now write pointer regs with channel to monitor */ 78 for (i = 0; i < active_channel_count; ++i) 79 /* Write stop bit on last channel */ ** CID 1353321: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1353321: Memory - corruptions (OVERRUN) /3rdparty/chromeec/driver/charger/isl9237.c: 58 in raw_write16() 52 { 53 return i2c_read16(I2C_PORT_CHARGER, I2C_ADDR_CHARGER, offset, value); 54 } 55 56 static inline int raw_write16(int offset, int value) 57 { >>> CID 1353321: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 2 by passing argument "MEC1322_I2C3" in call to "i2c_write16". 58 return i2c_write16(I2C_PORT_CHARGER, I2C_ADDR_CHARGER, offset, value); 59 } 60 61 static int isl9237_set_current(uint16_t current) 62 { 63 return raw_write16(ISL9237_REG_CHG_CURRENT, CURRENT_TO_REG(current)); ** CID 1353320: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1353320: Memory - corruptions (OVERRUN) /3rdparty/chromeec/driver/charger/isl9237.c: 53 in raw_read16() 47 { 48 return i2c_read8(I2C_PORT_CHARGER, I2C_ADDR_CHARGER, offset, value); 49 } 50 51 static inline int raw_read16(int offset, int *value) 52 { >>> CID 1353320: Memory - corruptions (OVERRUN) >>> Overrunning callee's array of size 2 by passing argument "MEC1322_I2C3" in call to "i2c_read16". 53 return i2c_read16(I2C_PORT_CHARGER, I2C_ADDR_CHARGER, offset, value); 54 } 55 56 static inline int raw_write16(int offset, int value) 57 { 58 return i2c_write16(I2C_PORT_CHARGER, I2C_ADDR_CHARGER, offset, value); ** CID 1353317: Memory - illegal accesses (OVERRUN) /3rdparty/chromeec/common/temp_sensor.c: 153 in temp_sensor_command_get_info() ________________________________________________________________________________________________________ *** CID 1353317: Memory - illegal accesses (OVERRUN) /3rdparty/chromeec/common/temp_sensor.c: 153 in temp_sensor_command_get_info() 147 struct ec_response_temp_sensor_get_info *r = args->response; 148 int id = p->id; 149 150 if (id >= TEMP_SENSOR_COUNT) 151 return EC_RES_ERROR; 152 >>> CID 1353317: Memory - illegal accesses (OVERRUN) >>> Overrunning array "temp_sensors" of 5 20-byte elements at element index 14 (byte offset 280) using index "id" (which evaluates to 14). 153 strzcpy(r->sensor_name, temp_sensors[id].name, sizeof(r->sensor_name)); 154 r->sensor_type = temp_sensors[id].type; 155 156 args->response_size = sizeof(*r); 157 158 return EC_RES_SUCCESS; 159 } 160 DECLARE_HOST_COMMAND(EC_CMD_TEMP_SENSOR_GET_INFO, 161 temp_sensor_command_get_info, ** CID 1353316: Memory - illegal accesses (OVERRUN) /3rdparty/chromeec/common/temp_sensor.c: 114 in command_temps() ________________________________________________________________________________________________________ *** CID 1353316: Memory - illegal accesses (OVERRUN) /3rdparty/chromeec/common/temp_sensor.c: 114 in command_temps() 108 if (rv) 109 rv1 = rv; 110 111 switch (rv) { 112 case EC_SUCCESS: 113 ccprintf("%d K = %d C", t, K_TO_C(t)); >>> CID 1353316: Memory - illegal accesses (OVERRUN) >>> Overrunning array "thermal_params" of 5 20-byte elements at element index 14 (byte offset 280) using index "i" (which evaluates to 14). 114 if (thermal_params[i].temp_fan_off && 115 thermal_params[i].temp_fan_max) 116 ccprintf(" %d%%", 117 thermal_fan_percent( 118 thermal_params[i].temp_fan_off, 119 thermal_params[i].temp_fan_max, ** CID 1353315: Memory - illegal accesses (OVERRUN) /3rdparty/chromeec/common/temp_sensor.c: 106 in command_temps() ________________________________________________________________________________________________________ *** CID 1353315: Memory - illegal accesses (OVERRUN) /3rdparty/chromeec/common/temp_sensor.c: 106 in command_temps() 100 static int command_temps(int argc, char **argv) 101 { 102 int t, i; 103 int rv, rv1 = EC_SUCCESS; 104 105 for (i = 0; i < TEMP_SENSOR_COUNT; ++i) { >>> CID 1353315: Memory - illegal accesses (OVERRUN) >>> Overrunning array "temp_sensors" of 5 20-byte elements at element index 14 (byte offset 280) using index "i" (which evaluates to 14). 106 ccprintf(" %-20s: ", temp_sensors[i].name); 107 rv = temp_sensor_read(i, &t); 108 if (rv) 109 rv1 = rv; 110 111 switch (rv) { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

ASUS KFSN4-DRE (K8) Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 02 Aug '16

02 Aug '16

The ASUS KFSN4-DRE (K8) fails verification for branch master as of commit 8c8403ff5f7bab0f6e5c4ccc20e5be0afbca569b The following tests failed: BOOT_FAILURE Commits since last successful test: 8c8403f console: Drop leftover struct console_driver b168db7 intel/skylake: Fix UART build options 0f2025d intel/lynxpoint,broadwell: Fix eDP display in Windows, SeaBios & Tiano 6e8233a soc/intel/quark: Enable use of hard reset aac31ca soc/intel/common: Fix build error in reset.c 0cd338e Remove non-ascii & unprintable characters bb9722b Add newlines at the end of all coreboot files 049b462 arch/x86: Enable postcar console See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE (K8) test stand Want to test on your own equipment? Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] Where is the first instrucion?
by Zoran Stojsavljevic 02 Aug '16

02 Aug '16

Sorry, Rafael (do not know why I wrote Daniel)??? Zoran On Tue, Aug 2, 2016 at 6:30 AM, Zoran Stojsavljevic < zoran.stojsavljevic(a)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(a)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(a)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(a)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(a)gmail.com> wrote: >>>> >>>>> Thanks a lot Zoran. >>>>> I will! >>>>> >>>>> Rafael >>>>> >>>>> Em seg, 25 de jul de 2016 14:13, Zoran Stojsavljevic < >>>>> zoran.stojsavljevic(a)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(a)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(a)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(a)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(a)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(a)coreboot.org >>>>>>>> > <mailto:coreboot@coreboot.org> >>>>>>>> > http://www.coreboot.org/mailman/listinfo/coreboot >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>>> -- >>>>>>>> coreboot mailing list: coreboot(a)coreboot.org >>>>>>>> http://www.coreboot.org/mailman/listinfo/coreboot >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> coreboot mailing list: coreboot(a)coreboot.org >>>>>>> >>>>>> https://www.coreboot.org/mailman/listinfo/coreboot >>>>>>> >>>>>> >>>>>> >>>> >

1 0

Re: [coreboot] Where is the first instrucion?
by Zoran Stojsavljevic 02 Aug '16

02 Aug '16

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

1 0

New on blogs.coreboot.org: [GSoC] Better RISC-V Support, week #10
by WordPress 02 Aug '16

02 Aug '16

1 0

Re: [coreboot] Where is the first instrucion?
by Rafael Machado 01 Aug '16

01 Aug '16

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

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot August 2016