coreboot May 2017

coreboot@coreboot.org

70 participants
202 discussions

Re: [coreboot] Will we maintain Skylake/FSP1.1?
by Youness Alaoui 09 May '17

09 May '17

I thought FSP 1.1 was for skylake and FSP 2.0 for Kabylake, I didn't realize 2.0 would be compatible with skylake too. Does this mean a skylake port could use fsp 1.1 or 2.0 ? In that case, is the 2.0 version better maintained, more stable, easier to integrate, etc.. or are both 1.1 and 2.0 implementations equivalent at this point? I also don't see the 2.0 release in https://github.com/IntelFsp/FSP/ so I assume getting my hands on it would mean grabbing it from somewhere else.... Thanks, Youness. On Tue, May 9, 2017 at 11:19 AM, Aaron Durbin <adurbin(a)google.com> wrote: > On Tue, May 9, 2017 at 10:14 AM, Nico Huber <nico.huber(a)secunet.com> > wrote: > > Hi, > > > > I was walking through the Skylake FSP1.1 support in coreboot and asked > > myself if it is worth to clean it up and maintain the code? given that > > the upcoming release of Kabylake FSP should be able to supersede it (I > > presume it is?). Are there any plans yet to drop it once the next FSP > > is released? (when will that be anyway?) > > I wanted to get rid of it, but Intel claimed they had customers using it > still. > > > > > Btw. does anybody feel like a maintainer for soc/intel/skylake/? > > Personally feel? Or want? > > > > > In it's current state it's very hard to use from a mainboard porter's > > point of view. Many of the selectable Kconfig settings are useless > > (either don't compile or don't run) for FSP1.1, and there's a `struct > > pei_data` [1] that seems to be a remnant of compatibility for a dif- > > ferent blob ;) > > That's just an old remnant of passing data around. It could be removed > as you annotated isolating those pieces to different structs and/or > variables for passing data around. The name is obviously not > applicable w.r.t. its current use. > > > > > Best regards, > > Nico > > > > PS. Microcode updates are also missing in the upstream blobs repo. Is > > that a licensing problem? If I try to download them from Intel, it > > asks me to click to accept that I'll prevent further distribution. > > I could prepare a patch to add them but somebody else would have > > to sign it off. > > > > [1] https://review.coreboot.org/#/c/19638/ > > >

1 0

Will we maintain Skylake/FSP1.1?
by Nico Huber 09 May '17

09 May '17

Hi, I was walking through the Skylake FSP1.1 support in coreboot and asked myself if it is worth to clean it up and maintain the code? given that the upcoming release of Kabylake FSP should be able to supersede it (I presume it is?). Are there any plans yet to drop it once the next FSP is released? (when will that be anyway?) Btw. does anybody feel like a maintainer for soc/intel/skylake/? In it's current state it's very hard to use from a mainboard porter's point of view. Many of the selectable Kconfig settings are useless (either don't compile or don't run) for FSP1.1, and there's a `struct pei_data` [1] that seems to be a remnant of compatibility for a dif- ferent blob ;) Best regards, Nico PS. Microcode updates are also missing in the upstream blobs repo. Is that a licensing problem? If I try to download them from Intel, it asks me to click to accept that I'll prevent further distribution. I could prepare a patch to add them but somebody else would have to sign it off. [1] https://review.coreboot.org/#/c/19638/

2 1

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

09 May '17

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 4 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 4 of 4 defect(s) ** CID 1374934: Memory - illegal accesses (OVERRUN) /src/drivers/storage/storage.c: 104 in display_capacity() ________________________________________________________________________________________________________ *** CID 1374934: Memory - illegal accesses (OVERRUN) /src/drivers/storage/storage.c: 104 in display_capacity() 98 /* Determine the hex divisor for the capacity */ 99 ASSERT(ARRAY_SIZE(hex_capacity_table) == ARRAY_SIZE(hex_unit_name)); 100 for (index = 0; index < ARRAY_SIZE(hex_capacity_table); index++) { 101 if (capacity >= hex_capacity_table[index]) 102 break; 103 } >>> CID 1374934: Memory - illegal accesses (OVERRUN) >>> Overrunning array "hex_capacity_table" of 5 8-byte elements at element index 5 (byte offset 40) using index "index" (which evaluates to 5). 104 hex_divisor = hex_capacity_table[index]; 105 hex_units = hex_unit_name[index]; 106 107 /* Display the capacity */ 108 sdhc_debug("%3lld.%03lld %sytes (%3lld.%03lld %sytes)%s%s\n", 109 capacity / decimal_divisor, ** CID 1374933: Memory - illegal accesses (OVERRUN) /src/drivers/storage/storage.c: 96 in display_capacity() ________________________________________________________________________________________________________ *** CID 1374933: Memory - illegal accesses (OVERRUN) /src/drivers/storage/storage.c: 96 in display_capacity() 90 == ARRAY_SIZE(decimal_unit_name)); 91 for (index = 0; index < ARRAY_SIZE(decimal_capacity_table); index++) { 92 if (capacity >= decimal_capacity_table[index]) 93 break; 94 } 95 decimal_divisor = decimal_capacity_table[index]; >>> CID 1374933: Memory - illegal accesses (OVERRUN) >>> Overrunning array "decimal_unit_name" of 5 4-byte elements at element index 5 (byte offset 20) using index "index" (which evaluates to 5). 96 decimal_units = decimal_unit_name[index]; 97 98 /* Determine the hex divisor for the capacity */ 99 ASSERT(ARRAY_SIZE(hex_capacity_table) == ARRAY_SIZE(hex_unit_name)); 100 for (index = 0; index < ARRAY_SIZE(hex_capacity_table); index++) { 101 if (capacity >= hex_capacity_table[index]) ** CID 1374932: Memory - illegal accesses (OVERRUN) /src/drivers/storage/storage.c: 105 in display_capacity() ________________________________________________________________________________________________________ *** CID 1374932: Memory - illegal accesses (OVERRUN) /src/drivers/storage/storage.c: 105 in display_capacity() 99 ASSERT(ARRAY_SIZE(hex_capacity_table) == ARRAY_SIZE(hex_unit_name)); 100 for (index = 0; index < ARRAY_SIZE(hex_capacity_table); index++) { 101 if (capacity >= hex_capacity_table[index]) 102 break; 103 } 104 hex_divisor = hex_capacity_table[index]; >>> CID 1374932: Memory - illegal accesses (OVERRUN) >>> Overrunning array "hex_unit_name" of 5 4-byte elements at element index 5 (byte offset 20) using index "index" (which evaluates to 5). 105 hex_units = hex_unit_name[index]; 106 107 /* Display the capacity */ 108 sdhc_debug("%3lld.%03lld %sytes (%3lld.%03lld %sytes)%s%s\n", 109 capacity / decimal_divisor, 110 (capacity / (decimal_divisor / 1000)) % 1000, ** CID 1374931: Memory - illegal accesses (OVERRUN) /src/drivers/storage/storage.c: 95 in display_capacity() ________________________________________________________________________________________________________ *** CID 1374931: Memory - illegal accesses (OVERRUN) /src/drivers/storage/storage.c: 95 in display_capacity() 89 ASSERT(ARRAY_SIZE(decimal_capacity_table) 90 == ARRAY_SIZE(decimal_unit_name)); 91 for (index = 0; index < ARRAY_SIZE(decimal_capacity_table); index++) { 92 if (capacity >= decimal_capacity_table[index]) 93 break; 94 } >>> CID 1374931: Memory - illegal accesses (OVERRUN) >>> Overrunning array "decimal_capacity_table" of 5 8-byte elements at element index 5 (byte offset 40) using index "index" (which evaluates to 5). 95 decimal_divisor = decimal_capacity_table[index]; 96 decimal_units = decimal_unit_name[index]; 97 98 /* Determine the hex divisor for the capacity */ 99 ASSERT(ARRAY_SIZE(hex_capacity_table) == ARRAY_SIZE(hex_unit_name)); 100 for (index = 0; index < ARRAY_SIZE(hex_capacity_table); index++) { ________________________________________________________________________________________________________ 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

Re: [coreboot] Recommended memory for coreboot + ASUS KGPE-D16
by Taiidan＠gmx.com 09 May '17

09 May '17

On 04/30/2017 08:05 AM, BogDan Vatra wrote: > Hi, > > I'd like to build desktop/workstation for my personal use (lots of > compilations + of course gaming on linux) > I bought 2 x 6276 CPUs and a KGPE-D16, eprom programmer, etc. now I'm > looking to buy some RAM. > My goal is to have a quad channel 64Gb and because I looking for a > desktop/workstation I think the best choice will be ECC UDIMMs and not > RDIMMs. > Will coreboot support 8 x 8Gb DDR3 UDIMMs 1600Mhz? If yes, there are > any recommended brands/product series? > If not, then what is the best option for achieving my goal? > > Thanks! > > Yours, > BogDan. > RDIMM's are generally cheaper as ECC UDIMM's are rare, and it doesn't matter what brands or w/e you use AFAIK - I have never had problems with mismatched ebay sticks. If you want to play games on higher settings that can't utilize 16 cores you will have to get a better CPU, like a 6328, 6386SE or 6287SE. Something cool you can do with this too is play yours in a VM like me with an attached graphics card. I would do a 6328 and a 6386SE combo with the first used for games. If you want 1600mhz you need 63xx CPU's I believe.

3 4

Re: [coreboot] kernel payload
by ron minnich 09 May '17

09 May '17

no, you have lots of great options with initramfs. So do a file command on your initramfs and see what it is :-) On Mon, May 8, 2017 at 5:28 PM Healer64 <Healer64(a)protonmail.com> wrote: > I don't know. I thought all initramfs is compressed. > > Thank you Ron and Duncan for your help. > > > Sent with ProtonMail <https://protonmail.com> Secure Email. > > -------- Original Message -------- > Subject: Re: [coreboot] kernel payload > Local Time: May 8, 2017 4:54 PM > UTC Time: May 8, 2017 10:54 PM > From: rminnich(a)gmail.com > To: Healer64 <Healer64(a)protonmail.com> > coreboot(a)coreboot.org <coreboot(a)coreboot.org> > > is that a compressed or uncompressed initramfs? linux payload can use > anything you configure it for. > >

1 0

Re: [coreboot] kernel payload
by Healer64 09 May '17

09 May '17

I don't know. I thought all initramfs is compressed. Thank you Ron and Duncan for your help. Sent with [ProtonMail](https://protonmail.com) Secure Email. -------- Original Message -------- Subject: Re: [coreboot] kernel payload Local Time: May 8, 2017 4:54 PM UTC Time: May 8, 2017 10:54 PM From: rminnich(a)gmail.com To: Healer64 <Healer64(a)protonmail.com> coreboot(a)coreboot.org <coreboot(a)coreboot.org> is that a compressed or uncompressed initramfs? linux payload can use anything you configure it for.

1 0

Re: [coreboot] kernel payload
by ron minnich 08 May '17

08 May '17

is that a compressed or uncompressed initramfs? linux payload can use anything you configure it for. On Mon, May 8, 2017 at 3:22 PM Healer64 <Healer64(a)protonmail.com> wrote: > I guess I will need to do more research about what the minimum > requirements will be. > > Looking at /boot on my current system the initramfs is about 11Mb, so that > would be way too large. Can a linux payload use initramfs or only initrd? > > > Sent with ProtonMail <https://protonmail.com> Secure Email. > > -------- Original Message -------- > Subject: Re: [coreboot] kernel payload > Local Time: May 8, 2017 4:15 PM > UTC Time: May 8, 2017 10:15 PM > From: rminnich(a)gmail.com > To: Healer64 <Healer64(a)protonmail.com> > coreboot(a)coreboot.org <coreboot(a)coreboot.org> > > On Mon, May 8, 2017 at 3:11 PM Healer64 <Healer64(a)protonmail.com> wrote: > >> So the question still remains as to how big the initrd image will be >> assuming it has to have the necessities to mount root on lvm encrypted >> drive. Any idea? >> >> >> > > What do you want in there? I'm puzzled that you keep asking this given how > much it can vary. OK, here's, and idea: I've seen it range from 100K to 30M. > > ron > >

1 0

Re: [coreboot] kernel payload
by Healer64 08 May '17

08 May '17

I guess I will need to do more research about what the minimum requirements will be. Looking at /boot on my current system the initramfs is about 11Mb, so that would be way too large. Can a linux payload use initramfs or only initrd? Sent with [ProtonMail](https://protonmail.com) Secure Email. -------- Original Message -------- Subject: Re: [coreboot] kernel payload Local Time: May 8, 2017 4:15 PM UTC Time: May 8, 2017 10:15 PM From: rminnich(a)gmail.com To: Healer64 <Healer64(a)protonmail.com> coreboot(a)coreboot.org <coreboot(a)coreboot.org> On Mon, May 8, 2017 at 3:11 PM Healer64 <Healer64(a)protonmail.com> wrote: So the question still remains as to how big the initrd image will be assuming it has to have the necessities to mount root on lvm encrypted drive. Any idea? What do you want in there? I'm puzzled that you keep asking this given how much it can vary. OK, here's, and idea: I've seen it range from 100K to 30M. ron

1 0

Re: [coreboot] kernel payload
by ron minnich 08 May '17

08 May '17

On Mon, May 8, 2017 at 3:11 PM Healer64 <Healer64(a)protonmail.com> wrote: > So the question still remains as to how big the initrd image will be > assuming it has to have the necessities to mount root on lvm encrypted > drive. Any idea? > > > What do you want in there? I'm puzzled that you keep asking this given how much it can vary. OK, here's, and idea: I've seen it range from 100K to 30M. ron

1 0

Re: [coreboot] kernel payload
by Healer64 08 May '17

08 May '17

So the question still remains as to how big the initrd image will be assuming it has to have the necessities to mount root on lvm encrypted drive. Any idea? Sent with [ProtonMail](https://protonmail.com) Secure Email. -------- Original Message -------- Subject: Re: [coreboot] kernel payload Local Time: May 5, 2017 1:14 PM UTC Time: May 5, 2017 7:14 PM From: coreboot(a)coreboot.org To: ron minnich <rminnich(a)gmail.com> coreboot(a)coreboot.org <coreboot(a)coreboot.org> Thanks for the offer. I'll think about it once I can get a linux kernel working in my own hardware. :) There is no dedicated serial port though I guess I could do serial over usb if I needed to. It makes more sense to me to start by using the kernel I already have if possible and move to a custom kernel once I know that works. I have enough space for a kernel at this point though depending on the combined size of kernel + initrm I may run into a problem. I'm really not sure how big the initrd will end up being or if there is an option to link to the initrd on the hard drive. Sent with [ProtonMail](https://protonmail.com) Secure Email. -------- Original Message -------- Subject: Re: [coreboot] kernel payload Local Time: May 5, 2017 12:14 PM UTC Time: May 5, 2017 6:14 PM From: rminnich(a)gmail.com To: Healer64 <Healer64(a)protonmail.com> coreboot(a)coreboot.org <coreboot(a)coreboot.org> neat! Do you have serial console or just graphics? We've been doing a lot of this linux payload stuff lately. I assume you can recover from a bad image. If so, I'd recommend building a kernel with kerneltiny config (or whatever it's called -- tinykernel?), add back in console support of your choice, set the command line in menuconfig for earlypintk=tty0 or ttyS0,keep and boot it and see how far it gets. the kerneltiny configf can get you to a 400K bzImage so it's worth the effort to start small and grow it up -- that's how we've done it in my project at Google (not a chromeos project, though I'll be talking about it this fall). To give you an idea of just how far the tiny kernel stuff goes, it removes all tests for uid != 0 and also all options to set uid to !0. This makes sense in a firmware payload. There's a lot of space saving options in that config and that's how you get a tiny kernel. Once you get past this point you can then look at what initramfs to add. Or maybe you are past that point, but let's talk. I've been doing this a lot for the past year and I have probably made lots of mistakes I can help you avoid ... BTW, I'm looking for people to work with on a project embedding Linux and a Go userland in flash, so if anyone out there wants to get involved, please, we need your brains. see u-root.tk.

1 0

← Newer
1
...
10
11
12
13
14
15
16
...
21
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 May 2017