coreboot August 2016

coreboot@coreboot.org

53 participants
132 discussions

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

09 Aug '16

Hi everyone Thanks a lot for the comments Zoran! You are totally right. The way I wrote was not clear. At my comments I added the bit number and the name of the bit based on intel's specification: [image: pasted1] Thanks for confirming this. Just to give you a feedback and for future generation interested on this topic. After checking all comments from everyone and studing a little bit I found the reason of the magic jump: f000:0fed ffe7 jmp di ; di value is 0x113 at this point as checked using QEMU Several instruction before this, we have the following: f000:0109 b0d0 mov al, 0xd0 f000:010b e680 out 0x80, al f000:010d bf1301 mov di, 0x113 f000:0110 e9ed0d jmp 0xf0f00 f000:0113 8cc8 mov ax, cs f000:0115 8ed8 mov ds, ax f000:0117 8ec0 mov es, ax So as it was pointed by you some e-mails ago, the jmps here were used to access other "functions" (in blue), since there is no stack yet. And that "jmp di" was the point the call returns to the starting point (in red). I'll continue my studies and post in case of questions. Soon I'll try to port cb to a system I'm not using. Thanks for the help everyone! Em ter, 9 de ago de 2016 às 07:23, Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> escreveu: > Hello Rafael, > > Once again... About your initial email. > > Code you have posted (in *RED*): > > 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 > > I think you have here errors commenting CD and NW. Resetting these bits > will be the opposite what you wrote here. Namely, CD = 0 will be Cache > Enabled and NW = 0 will be Write-Through. > > This code very closely matches the code in Coreboot's > src/soc/intel/skylake/bootblock/cache_as_ram.S: > > Line 128: > /* Enable variable MTRRs */ > mov $MTRR_DEF_TYPE_MSR, %ecx > rdmsr > or $MTRR_DEF_TYPE_EN, %eax > wrmsr > > /* Enable caching */ > mov %cr0, %eax > and $~(CR0_CD | CR0_NW), %eax > invd > mov %eax, %cr0 > > Please, also look into the file mtrr.h (src/include/cpu/x86/mtrr.h) . *It > starts making (lot of) sense... ;-)* > > 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

hackathon in Berlin next weekend 12-14.
by Alexander Couzens 09 Aug '16

09 Aug '16

hi, some people are visiting Berlin for a hackathon next weekend (12-14) The hackathon will taken place at the Finowstr. 2a. It's between the subway station U Samariter, U Frankfurter Str. Best, lynxis -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu mobile: +4915123277221 gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

2 2

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

09 Aug '16

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. 421 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 1 of 1 defect(s) ** CID 1361475: Memory - illegal accesses (UNINIT) /util/cbfstool/cbfs_image.c: 1055 in cbfs_payload_make_elf() ________________________________________________________________________________________________________ *** CID 1361475: Memory - illegal accesses (UNINIT) /util/cbfstool/cbfs_image.c: 1055 in cbfs_payload_make_elf() 1049 1050 static int cbfs_payload_make_elf(struct buffer *buff, uint32_t arch) 1051 { 1052 Elf64_Ehdr ehdr; 1053 Elf64_Shdr shdr; 1054 struct cbfs_payload_segment *segs = NULL; >>> CID 1361475: Memory - illegal accesses (UNINIT) >>> Declaring variable "ew" without initializer. 1055 struct elf_writer *ew; 1056 struct buffer elf_out; 1057 int segments = 0; 1058 int retval = -1; 1059 1060 if (arch == CBFS_ARCHITECTURE_UNKNOWN) { ________________________________________________________________________________________________________ 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…

2 1

Re: [coreboot] How do I build Coreboot with both normal and fallback?
by Patrick Georgi 09 Aug '16

09 Aug '16

2016-08-05 11:56 GMT+02:00 Yaroslav K. <yar444(a)gmail.com>: > Coreboot's bootblock_normal.c supports booting a fallback romstage if > a normal romstage > boot fails. But you can only specify either "fallback" or "normal" in > CONFIG_CBFS_PREFIX. > So how do I build an image with both normal and fallback stages set? By building twice: once with CBFS_PREFIX=fallback, then with UPDATE_IMAGE=y and CBFS_PREFIX=normal to extend the image. That allows you to use different versions or configurations for fallback and normal. Regards, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

1 0

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

09 Aug '16

Hello Rafael, Once again... About your initial email. Code you have posted (in *RED*): 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 I think you have here errors commenting CD and NW. Resetting these bits will be the opposite what you wrote here. Namely, CD = 0 will be Cache Enabled and NW = 0 will be Write-Through. This code very closely matches the code in Coreboot's src/soc/intel/skylake/ bootblock/cache_as_ram.S: Line 128: /* Enable variable MTRRs */ mov $MTRR_DEF_TYPE_MSR, %ecx rdmsr or $MTRR_DEF_TYPE_EN, %eax wrmsr /* Enable caching */ mov %cr0, %eax and $~(CR0_CD | CR0_NW), %eax invd mov %eax, %cr0 Please, also look into the file mtrr.h (src/include/cpu/x86/mtrr.h) . *It starts making (lot of) sense... ;-)* 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] Mistery of the function: static void enable_rom_caching(void)
by Zoran Stojsavljevic 09 Aug '16

09 Aug '16

Hello Rizwan, Thank you for the tip. I am looking into the whole x86 asm file pointed by you, and cranking it reading x86 architectural manual (lot of info to digest). ;-) If I'll have questions, I might come back later to ask for clarity, if you allow me. :-) Thank you again, Zoran On Mon, Aug 8, 2016 at 12:35 PM, Qureshi, Rizwan <rizwan.qureshi(a)intel.com> wrote: > Hi Zoran, > > For skylake refer src/soc/intel/skylake/bootblock/cache_as_ram.S > around line 256. We are marking the ROMregion as WP and cacheable and > programming an MTRR appropriately. > > So, it’s not removed buts its being done while setting up Cache As Ram. > > > > Regards, > > Rizwan Qureshi > > > > *From:* Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com > <zoran.stojsavljevic(a)gmail.com>] > *Sent:* Monday, August 8, 2016 12:33 PM > *To:* coreboot <coreboot(a)coreboot.org>; Paul Menzel <paulepanter@users. > sourceforge.net> > *Cc:* Qureshi, Rizwan <rizwan.qureshi(a)intel.com>; Ch, Naveenkrishna < > naveenkrishna.ch(a)intel.com>; Yang, York <york.yang(a)intel.com> > *Subject:* Mistery of the function: static void enable_rom_caching(void) > > > > Hello community, > > > > I was/got again today in Coreboot directory src/soc/intel/braswell/bootblock/bootblock.c > looking at static void enable_rom_caching(void). > > > > Then, since Paul Menzel have announcement ([ANNOUNCEMENT] Support for > Intel Kaby Lake), I went to look into src/soc/intel/skylake/bootblock/bootblock.c, > but I did not find this function. Kaby Lake patches do not support this > function as well. > > > > Then I did the following on my WIN 10 (using VMware workstation 12) VM > Fedora 24: > > > > [zoran@localhost intel]$ pwd > > /home/zoran/projects/coreboot/coreboot/src/soc/intel > > [zoran@localhost intel]$ git describe > > 4.4-1038-gdd65ef8 > > [zoran@localhost intel]$ ls -al > > total 48 > > drwxrwxr-x. 12 4096 Aug 1 10:02 . > > drwxrwxr-x. 14 4096 Aug 1 10:02 .. > > drwxrwxr-x. 5 4096 Aug 1 10:02 apollolake > > drwxrwxr-x. 6 4096 Aug 1 10:02 baytrail > > drwxrwxr-x. 6 4096 Aug 1 10:02 braswell > > drwxrwxr-x. 6 4096 Aug 1 10:02 broadwell > > drwxrwxr-x. 3 4096 Aug 1 10:02 common > > drwxrwxr-x. 7 4096 Aug 1 10:02 fsp_baytrail > > drwxrwxr-x. 7 4096 Aug 1 10:02 fsp_broadwell_de > > drwxrwxr-x. 5 4096 Aug 1 10:02 quark > > drwxrwxr-x. 3 4096 Aug 1 10:02 sch > > drwxrwxr-x. 7 4096 Aug 1 10:02 skylake > > [zoran@localhost intel]$ grep -r enable_rom * > > baytrail/bootblock/bootblock.c:static void enable_rom_caching(void) > > baytrail/bootblock/bootblock.c: enable_rom_caching(); > > braswell/bootblock/bootblock.c:static void enable_rom_caching(void) > > braswell/bootblock/bootblock.c: enable_rom_caching(); > > broadwell/bootblock/cpu.c:static void enable_rom_caching(void) > > broadwell/bootblock/cpu.c: enable_rom_caching(); > > fsp_baytrail/bootblock/bootblock.c:static void enable_rom_caching(void) > > fsp_baytrail/bootblock/bootblock.c: enable_rom_caching(); > > [zoran@localhost intel]$ > > > > We see here that from skylake (also does not exists in apollolake) this > function is dropped. > > > > Any logical explanation for this mismatch? > > > > Thank you, > > Zoran > > >

1 0

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

08 Aug '16

The ASUS KFSN4-DRE (K8) fails verification for branch master as of commit f41a9a64598fe91108489619cfc98e790b98819d The following tests failed: BOOT_FAILURE Commits since last successful test: f41a9a6 drivers/elog: treat offsets relative to start of mirror 281c994 drivers/elog: use region_device for mirroring into ram 422c440 drivers/elog: use offsets for checking cleared buffers bec0753 sconfig: Reformat C code c9c27bb sconfig: Remove mainboard chip.h support <56 commits skipped> d1a0051 google/gale: Add more board ID variants 40d62f3 google/gru: Add code to support I2C TPM for Kevin 5e6771b google/gru: Add support for Gru rev1 47ca65a payloads/coreinfo: Set KCONFIG_CONFIG value 5fafc6a soc/intel/quark: Support access to CPU CR registers 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

New on blogs.coreboot.org: flashrom's transition to git
by WordPress 08 Aug '16

08 Aug '16

1 0

Re: [coreboot] Mistery of the function: static void enable_rom_caching(void)
by Qureshi, Rizwan 08 Aug '16

08 Aug '16

Hi Zoran, For skylake refer src/soc/intel/skylake/bootblock/cache_as_ram.S around line 256. We are marking the ROMregion as WP and cacheable and programming an MTRR appropriately. So, it’s not removed buts its being done while setting up Cache As Ram. Regards, Rizwan Qureshi From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com] Sent: Monday, August 8, 2016 12:33 PM To: coreboot <coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>>; Paul Menzel <paulepanter(a)users.sourceforge.net<mailto:paulepanter@users.sourceforge.net>> Cc: Qureshi, Rizwan <rizwan.qureshi(a)intel.com<mailto:rizwan.qureshi@intel.com>>; Ch, Naveenkrishna <naveenkrishna.ch(a)intel.com<mailto:naveenkrishna.ch@intel.com>>; Yang, York <york.yang(a)intel.com<mailto:york.yang@intel.com>> Subject: Mistery of the function: static void enable_rom_caching(void) Hello community, I was/got again today in Coreboot directory src/soc/intel/braswell/bootblock/bootblock.c looking at static void enable_rom_caching(void). Then, since Paul Menzel have announcement ([ANNOUNCEMENT] Support for Intel Kaby Lake), I went to look into src/soc/intel/skylake/bootblock/bootblock.c, but I did not find this function. Kaby Lake patches do not support this function as well. Then I did the following on my WIN 10 (using VMware workstation 12) VM Fedora 24: [zoran@localhost intel]$ pwd /home/zoran/projects/coreboot/coreboot/src/soc/intel [zoran@localhost intel]$ git describe 4.4-1038-gdd65ef8 [zoran@localhost intel]$ ls -al total 48 drwxrwxr-x. 12 4096 Aug 1 10:02 . drwxrwxr-x. 14 4096 Aug 1 10:02 .. drwxrwxr-x. 5 4096 Aug 1 10:02 apollolake drwxrwxr-x. 6 4096 Aug 1 10:02 baytrail drwxrwxr-x. 6 4096 Aug 1 10:02 braswell drwxrwxr-x. 6 4096 Aug 1 10:02 broadwell drwxrwxr-x. 3 4096 Aug 1 10:02 common drwxrwxr-x. 7 4096 Aug 1 10:02 fsp_baytrail drwxrwxr-x. 7 4096 Aug 1 10:02 fsp_broadwell_de drwxrwxr-x. 5 4096 Aug 1 10:02 quark drwxrwxr-x. 3 4096 Aug 1 10:02 sch drwxrwxr-x. 7 4096 Aug 1 10:02 skylake [zoran@localhost intel]$ grep -r enable_rom * baytrail/bootblock/bootblock.c:static void enable_rom_caching(void) baytrail/bootblock/bootblock.c: enable_rom_caching(); braswell/bootblock/bootblock.c:static void enable_rom_caching(void) braswell/bootblock/bootblock.c: enable_rom_caching(); broadwell/bootblock/cpu.c:static void enable_rom_caching(void) broadwell/bootblock/cpu.c: enable_rom_caching(); fsp_baytrail/bootblock/bootblock.c:static void enable_rom_caching(void) fsp_baytrail/bootblock/bootblock.c: enable_rom_caching(); [zoran@localhost intel]$ We see here that from skylake (also does not exists in apollolake) this function is dropped. Any logical explanation for this mismatch? Thank you, Zoran

1 0

Re: [coreboot] Mistery of the function: static void enable_rom_caching(void)
by Qureshi, Rizwan 08 Aug '16

08 Aug '16

Hi Zoran, For skylake refer src/soc/intel/skylake/bootblock/cache_as_ram.S around line 256. We are marking the ROMregion as WP and cacheable and programming an MTRR appropriately. So, it’s not removed buts its being done while setting up Cache As Ram. Regards, Rizwan Qureshi From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com] Sent: Monday, August 8, 2016 12:33 PM To: coreboot <coreboot(a)coreboot.org>; Paul Menzel <paulepanter(a)users.sourceforge.net> Cc: Qureshi, Rizwan <rizwan.qureshi(a)intel.com>; Ch, Naveenkrishna <naveenkrishna.ch(a)intel.com>; Yang, York <york.yang(a)intel.com> Subject: Mistery of the function: static void enable_rom_caching(void) Hello community, I was/got again today in Coreboot directory src/soc/intel/braswell/bootblock/bootblock.c looking at static void enable_rom_caching(void). Then, since Paul Menzel have announcement ([ANNOUNCEMENT] Support for Intel Kaby Lake), I went to look into src/soc/intel/skylake/bootblock/bootblock.c, but I did not find this function. Kaby Lake patches do not support this function as well. Then I did the following on my WIN 10 (using VMware workstation 12) VM Fedora 24: [zoran@localhost intel]$ pwd /home/zoran/projects/coreboot/coreboot/src/soc/intel [zoran@localhost intel]$ git describe 4.4-1038-gdd65ef8 [zoran@localhost intel]$ ls -al total 48 drwxrwxr-x. 12 4096 Aug 1 10:02 . drwxrwxr-x. 14 4096 Aug 1 10:02 .. drwxrwxr-x. 5 4096 Aug 1 10:02 apollolake drwxrwxr-x. 6 4096 Aug 1 10:02 baytrail drwxrwxr-x. 6 4096 Aug 1 10:02 braswell drwxrwxr-x. 6 4096 Aug 1 10:02 broadwell drwxrwxr-x. 3 4096 Aug 1 10:02 common drwxrwxr-x. 7 4096 Aug 1 10:02 fsp_baytrail drwxrwxr-x. 7 4096 Aug 1 10:02 fsp_broadwell_de drwxrwxr-x. 5 4096 Aug 1 10:02 quark drwxrwxr-x. 3 4096 Aug 1 10:02 sch drwxrwxr-x. 7 4096 Aug 1 10:02 skylake [zoran@localhost intel]$ grep -r enable_rom * baytrail/bootblock/bootblock.c:static void enable_rom_caching(void) baytrail/bootblock/bootblock.c: enable_rom_caching(); braswell/bootblock/bootblock.c:static void enable_rom_caching(void) braswell/bootblock/bootblock.c: enable_rom_caching(); broadwell/bootblock/cpu.c:static void enable_rom_caching(void) broadwell/bootblock/cpu.c: enable_rom_caching(); fsp_baytrail/bootblock/bootblock.c:static void enable_rom_caching(void) fsp_baytrail/bootblock/bootblock.c: enable_rom_caching(); [zoran@localhost intel]$ We see here that from skylake (also does not exists in apollolake) this function is dropped. Any logical explanation for this mismatch? Thank you, Zoran

1 0

← Newer
1
...
6
7
8
9
10
11
12
13
14
Older →

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