October 2016 - coreboot - mail.coreboot.org

Re: [coreboot] Official builds for EoL Chromebooks
by Matt DeVillier Oct. 13, 2016

Oct. 13, 2016

well, in order for that to happen, someone would have to take ownership of that - are you volunteering? =) There's also the issue of blobs that can't be redistributed, which is AIUI one of the reasons why coreboot doesn't offer compiled firmware. Additionally, some models (ie, Chomeboxes) require persistence of parts of the stock firmware in order to maintain their unique ethernet MAC address, so having users simply download and manually flash a compiled firmware manually is highly suboptimal. This is why I implemented the flashing script (well that, and to provide some basic sanity checks that users weren't flashing the wrong firmware, had write-protect disabled, etc) On Thu, Oct 13, 2016 at 10:14 AM, Emilian Bold <emilian.bold(a)gmail.com> wrote: > I think EoL Chromebooks are a good opportunity for Coreboot to present > itself to end users. > > Right now Chromebooks use Coreboot but nobody knows that. > > But once a Chromebook reaches EoL people will either throw it away or use > it with the insecure and outdated browser version they have until it breaks. > > People would appreciate that it's possible to keep the device and use a > modern Linux with up-to-date browser by only installing a dedicated > Coreboot ROM. > > A per-device wiki page would be great! Something to show how to install > it, etc. > > A ROM sha-256 (and a link) is also essential to know what to grab (or if > your build was good). > > I'm actually the one that started the reproducible builds thread last time > precisely because I could not get the same ROM image as the ones posted > online and I was wondering what I did wrong and if I would brick my laptop > or not. > > > > --emi > > On Thu, Oct 13, 2016 at 5:53 PM, Matt DeVillier <matt.devillier(a)gmail.com> > wrote: > >> Emi, >> >> I think this is what you're looking for: https://www.coreboot.org/ >> Supported_Motherboards >> It contains the commit hash, build config, and a few other logs for each >> device/commit. It is user submitted though, since there doesn't exist a >> test setup for every supported device. >> >> Right now, I'm the main builder/distributor of upstream coreboot firmware >> for ChromeOS devices; I support all Haswell, Broadwell, and some Baytrail >> devices, the former with both UEFI and Legacy Boot variants. When time >> permits, I'll expand that to cover the rest of the Baytrail devices, then >> move on to adding support for Skylake. No plans for Braswell support >> unless I acquire a device on which to test. >> >> John Lewis has some upstream firmware for the older SandyBridge/IvyBridge >> models, but his Haswell firmware is build from Google's tree/branches not >> upstream. He also has no plans for any future upstream firmware. >> >> cheers, >> Matt >> >> On Thu, Oct 13, 2016 at 6:49 AM, Emilian Bold <emilian.bold(a)gmail.com> >> wrote: >> >>> Hello, >>> >>> Now that Coreboot has reproducible builds, could you provide a list of >>> build hashes for Chromebooks that are or will soon reach End of Life? >>> >>> I see on https://support.google.com/chrome/a/answer/6220366?hl=en that >>> 2 Chromebooks will reach End of Life in 2016 and 3 more in 2017 then 7 in >>> 2018. I assume the number will increase each year. >>> >>> I know that Coreboot does not distribute builds, but the little Custom >>> roms section on https://www.coreboot.org/users.html seems insufficient. >>> >>> It's easy making a build, you just need to have the certainty you did it >>> well. Or that the one you are downloading is correct. >>> >>> Posting an official SHA-256 hash for a ROM would solve this. >>> >>> --emi >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://www.coreboot.org/mailman/listinfo/coreboot >>> >> >> >

1 0

Re: [coreboot] Official builds for EoL Chromebooks
by Emilian Bold Oct. 13, 2016

Oct. 13, 2016

I think EoL Chromebooks are a good opportunity for Coreboot to present itself to end users. Right now Chromebooks use Coreboot but nobody knows that. But once a Chromebook reaches EoL people will either throw it away or use it with the insecure and outdated browser version they have until it breaks. People would appreciate that it's possible to keep the device and use a modern Linux with up-to-date browser by only installing a dedicated Coreboot ROM. A per-device wiki page would be great! Something to show how to install it, etc. A ROM sha-256 (and a link) is also essential to know what to grab (or if your build was good). I'm actually the one that started the reproducible builds thread last time precisely because I could not get the same ROM image as the ones posted online and I was wondering what I did wrong and if I would brick my laptop or not. --emi On Thu, Oct 13, 2016 at 5:53 PM, Matt DeVillier <matt.devillier(a)gmail.com> wrote: > Emi, > > I think this is what you're looking for: https://www.coreboot.org/ > Supported_Motherboards > It contains the commit hash, build config, and a few other logs for each > device/commit. It is user submitted though, since there doesn't exist a > test setup for every supported device. > > Right now, I'm the main builder/distributor of upstream coreboot firmware > for ChromeOS devices; I support all Haswell, Broadwell, and some Baytrail > devices, the former with both UEFI and Legacy Boot variants. When time > permits, I'll expand that to cover the rest of the Baytrail devices, then > move on to adding support for Skylake. No plans for Braswell support > unless I acquire a device on which to test. > > John Lewis has some upstream firmware for the older SandyBridge/IvyBridge > models, but his Haswell firmware is build from Google's tree/branches not > upstream. He also has no plans for any future upstream firmware. > > cheers, > Matt > > On Thu, Oct 13, 2016 at 6:49 AM, Emilian Bold <emilian.bold(a)gmail.com> > wrote: > >> Hello, >> >> Now that Coreboot has reproducible builds, could you provide a list of >> build hashes for Chromebooks that are or will soon reach End of Life? >> >> I see on https://support.google.com/chrome/a/answer/6220366?hl=en that 2 >> Chromebooks will reach End of Life in 2016 and 3 more in 2017 then 7 in >> 2018. I assume the number will increase each year. >> >> I know that Coreboot does not distribute builds, but the little Custom >> roms section on https://www.coreboot.org/users.html seems insufficient. >> >> It's easy making a build, you just need to have the certainty you did it >> well. Or that the one you are downloading is correct. >> >> Posting an official SHA-256 hash for a ROM would solve this. >> >> --emi >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> > >

1 0

Re: [coreboot] Official builds for EoL Chromebooks
by Matt DeVillier Oct. 13, 2016

Oct. 13, 2016

Emi, I think this is what you're looking for: https://www.coreboot.org/Supported_Motherboards It contains the commit hash, build config, and a few other logs for each device/commit. It is user submitted though, since there doesn't exist a test setup for every supported device. Right now, I'm the main builder/distributor of upstream coreboot firmware for ChromeOS devices; I support all Haswell, Broadwell, and some Baytrail devices, the former with both UEFI and Legacy Boot variants. When time permits, I'll expand that to cover the rest of the Baytrail devices, then move on to adding support for Skylake. No plans for Braswell support unless I acquire a device on which to test. John Lewis has some upstream firmware for the older SandyBridge/IvyBridge models, but his Haswell firmware is build from Google's tree/branches not upstream. He also has no plans for any future upstream firmware. cheers, Matt On Thu, Oct 13, 2016 at 6:49 AM, Emilian Bold <emilian.bold(a)gmail.com> wrote: > Hello, > > Now that Coreboot has reproducible builds, could you provide a list of > build hashes for Chromebooks that are or will soon reach End of Life? > > I see on https://support.google.com/chrome/a/answer/6220366?hl=en that 2 > Chromebooks will reach End of Life in 2016 and 3 more in 2017 then 7 in > 2018. I assume the number will increase each year. > > I know that Coreboot does not distribute builds, but the little Custom > roms section on https://www.coreboot.org/users.html seems insufficient. > > It's easy making a build, you just need to have the certainty you did it > well. Or that the one you are downloading is correct. > > Posting an official SHA-256 hash for a ROM would solve this. > > --emi > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Official builds for EoL Chromebooks
by Emilian Bold Oct. 13, 2016

Oct. 13, 2016

Hello, Now that Coreboot has reproducible builds, could you provide a list of build hashes for Chromebooks that are or will soon reach End of Life? I see on https://support.google.com/chrome/a/answer/6220366?hl=en that 2 Chromebooks will reach End of Life in 2016 and 3 more in 2017 then 7 in 2018. I assume the number will increase each year. I know that Coreboot does not distribute builds, but the little Custom roms section on https://www.coreboot.org/users.html seems insufficient. It's easy making a build, you just need to have the certainty you did it well. Or that the one you are downloading is correct. Posting an official SHA-256 hash for a ROM would solve this. --emi

1 0

Intel Baytrail E3845 Coreboot - Not booting after modifying CMOS boot_option
by Mohan Shanmuga Sundaram Oct. 13, 2016

Oct. 13, 2016

Dear Coreboot Community! I have modified the following CMOS option table bit using 'nvramtool' utility from Ubuntu: 384 1 e 4 boot_option Its default value was 'Normal', which I modified to 'Fallback'. After rebooting, the coreboot seems to be not loading the default payload. In what way I can recover it? Where does the CMOS modification resides? I have redone the coreboot.rom flashing completely, yet the coreboot didn't load the default payload. The following is my CBFS: Performing operation on 'COREBOOT' region... Name Offset Type Size cbfs master header 0x0 cbfs header 32 fallback/romstage 0x80 stage 30868 cpu_microcode_blob.bin 0x7980 microcode 208896 fallback/ramstage 0x3aa00 stage 51629 config 0x47400 raw 749 revision 0x47740 raw 575 cmos_layout.bin 0x479c0 cmos_layout 1212 pci8086,0f31.rom 0x47ec0 optionrom 65536 fallback/dsdt.aml 0x57f40 raw 12527 fallback/payload 0x5b080 payload 61165 payload_config 0x69fc0 raw 1563 payload_revision 0x6a640 raw 243 (empty) 0x6a780 null 1333016 fsp.bin 0x1afec0 fsp 294912 (empty) 0x1f7f00 null 30168 bootblock 0x1ff500 bootblock 2480 Regards, Mohan "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

1 0

Re: [coreboot] Skylake ME power down mitigation timer
by Trammell Hudson Oct. 12, 2016

Oct. 12, 2016

On Wed, Oct 12, 2016 at 10:08:38AM -0700, Duncan Laurie wrote: > I wouldn't read too much into the data in there, it turns out the ME > release that added this output detail (which we shipped in this device) > also got it wrong so the data is not reliable. Interesting. Do you mean the ME firmware release that was installed in the boot ROM? Has Intel shipped an updated firmware file for the platform? > > The only drawback so far is that FSP takes quite a bit longer > > to complete. I should say "FSPMemoryInit" takes longer; "FSPTempRamInit" is still as fast as before. I've removed all of the code from the ME firmware image, except the rbe, kernel, syslib and bup files. I've also resized the ME region from 0x1000-0x1FFFFF to 0x1000-0xFFFFF. This potentially makes another 1 MB available to the coreboot payload. > > It's been up for almost two hours without shutting down. The system has been functional most of the day, so the 30 minute timer does not seem to be active on this platform. Everything seems to work fine: S3 suspend/resume is slow, but does the right thing now, and powertop says the system is around 5W idle (Qubes with a 4.4 kernel, mjg59 mentioned that kernel can't take advantage of low power states). -- Trammell

2 1

Skylake ME power down mitigation timer
by Trammell Hudson Oct. 12, 2016

Oct. 12, 2016

Does anyone have experience with how long the Management Engine's "Power Down Mitigation" timer is on Skylake? My Chell Chromebook with modified ME firmware reports this on bootup / S3 resume: ME: FW Partition Table : BAD ME: Bringup Loader Failure : YES ME: Firmware Init Complete : YES ME: Manufacturing Mode : YES ME: Boot Options Present : YES ME: Update In Progress : YES ME: D3 Support : YES ME: D0i3 Support : YES ME: Low Power State Enabled : YES ME: Power Gated : YES ME: CPU Replaced : YES ME: CPU Replacement Valid : YES ME: Current Working State : Unknown (15) ME: Current Operation State : M0 without UMA but with error ME: Current Operation Mode : M0 without UMA ME: Error Code : Preboot ME: Progress Phase : <NULL> ME: Power Management Event : CM0PG->CM0 ME: Progress Phase State : Unknown phase: 0x0f state: 0xff ME: Power Down Mitigation : YES ME: PD Mitigation State : Issue Detected but not Recovered ME: Encryption Key Override : Workaround Applied ME: Encryption Key Check : FAIL ME: PCH Configuration Info : Changed ME: Firmware SKU : Unknown (0x7) It's been up for almost two hours without shutting down. The only drawback so far is that FSP takes quite a bit longer to complete. -- Trammell

2 1

Re: [coreboot] Adapting Linux kernel documentation setup with Sphinx and reStructuredText
by mdn Oct. 12, 2016

Oct. 12, 2016

Hello I don't want to be a party pooper but gohugo uses non-free javascript, try librejs and you'll see that the non-free javascript is from cloudflare (fortunately part of the site is ok). Good night Le 03/10/2016 21:43, Martin Roth a écrit : > Zaolin has been working for a while on updating our documentation, and his > plan is to switch coreboot to using Hugo for our documentation manager.[1] > Hugo supports various different markup languages, including markdown, > html, RestructuredText, and AsciiDoc. [2] > > I meant to send the list an email a while back about doing this, but got > sidetracked with other projects. It's just been picked back up, so if > anyone has any thoughts, please feel free to comment, either here or in his > patches. [3] [4] > > We're going to try to switch away from the wiki for our documentation. The > wiki is great for some things, but not so good for other things. The > thought is that if we keep the documentation in the coreboot tree, in an > accessible format, people will be able to contribute to it more easily, and > it will hopefully stay more up-to-date. The plan is to move some of the > documentation out of the wiki into the Documentation folder and adding new > documentation shortly. > > And, as always, any documentation contributions would be greatly > appreciated. [5] > > Martin > > [1] https://gohugo.io/ > [2] https://gohugo.io/content/supported-formats > [3] https://review.coreboot.org/#/c/16853/ > [4] https://review.coreboot.org/#/c/16787/ > [5] Please. > > On Mon, Oct 3, 2016 at 1:56 AM, Paul Menzel via coreboot < > coreboot(a)coreboot.org> wrote: > >> Dear coreboot folks, >> >> >> The Linux kernel switched to Sphinx and reStructuredText [1] for its >> documentation [2][3][4]. >> >> Would it make sense to also use that for coreboot? I would see the >> following benefits. >> >> 1. It’s easier to import code like drivers from the Linux kernel to >> coreboot. >> 2. Developers familiar with the Linux kernel have it easier to work on >> coreboot. >> 3. The coreboot project could import all improvements the Linux kernel >> documenation gets. >> >> >> Thanks, >> >> Paul >> >> >> [1] https://en.wikipedia.org/wiki/ReStructuredText >> [2] https://static.lwn.net/kerneldoc/index.html >> [3] https://lwn.net/Articles/692704/ >> "Kernel documentation with Sphinx, part 1: how we got here" >> [4] https://lwn.net/Articles/692705/ >> "Kernel documentation with Sphinx, part 2: how it works >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> > > > -- Note: veuillez s'il vous plaît utiliser GnuPg pour nos futures conversations https://emailselfdefense.fsf.org/fr/ Plus d'info ici: http://www.bibmath.net/crypto/index.php?action=affiche&quoi=moderne/pgp Message envoyé avec GNU Icedove un fork de Thunderbird https://directory.fsf.org/wiki/Icedove

1 0

Re: [coreboot] Building Intel SoC Apollo Lake with DDR3L+PMIC
by Furquan Shaikh Oct. 11, 2016

Oct. 11, 2016

On Tue, Oct 11, 2016 at 1:20 AM, PG W <wmorris102668(a)gmail.com> wrote: > Hi Andrey, > > thank you for your reply. > > I have done as you instructed, but there will be an error message as > follows: > ============================ > Built intel/apollolake_rvp (Apollolake RVP) > E: Image does not contain BPDT!! > E: build/util/cbfstool/ifwitool: ifwi parsing failed > src/soc/intel/apollolake/Makefile.inc:118: recipe for target > 'files_added' failed > make: *** [files_added] Error 1 > ============================= > This error seems to be coming from src/soc/intel/apollolake/Makefile.inc: files_added:: $(IFWITOOL) » $(IFWITOOL) $(CONFIG_IFWI_FILE_NAME) create -f $(objcbfs)/ifwi.bin.tmp » $(IFWITOOL) $(objcbfs)/ifwi.bin.tmp delete -n OBBP » $(IFWITOOL) $(objcbfs)/ifwi.bin.tmp replace -n IBBP -f $(objcbfs)/bootblock.bin -d -e IBBL » $(CBFSTOOL) $(obj)/coreboot.rom write -r $(CONFIG_IFWI_FMAP_NAME) -f $(objcbfs)/ifwi.bin.tmp --fill-upward Did you ensure that CONFIG_IFWI_FILE_NAME is set correctly to point to your IFWI image and that your IFWI image is actually valid? You can run "ifwitool <IFWI_IMAGE> print" to check if you see it printing the right information. > If I want to build an APL 8MB BIOS need to prepare what the necessary > components? > > Thanks in advance for your help!!! > > > Regards, > Morris > > 2016-09-22 22:09 GMT+08:00 Andrey Petrov <andrey.petrov(a)intel.com>: > >> Hi, >> >> On 09/22/2016 03:45 AM, morris.wang wrote: >> >> Hello, >> >> I am building coreboot image for Apollo Lake. >> My designed mainboard comes with DDR3L SODIMMs + PMIC. >> >> To my knowledge, >> RVP1 board is for DDR3L SODIMMs and discrete VRs. >> RVP2 board is for LPDDR3 and PMIC. >> >> If I selected under coreboot configuration: >> Mainboard --> Mainboard vendor (Intel) >> Mainboard model (Apollolake DDR3 RVP1) >> >> How to modify VR type from Discrete to PMIC??? >> >> You need to re-generate IFWI image and the descriptor with Intel-provided >> FIT tool. >> Then you need to reference them with CONFIG_IFWI_FILE_NAME and >> CONFIG_IFD_BIN_PATH >> >> Best, >> Andrey >> >> -- >> 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 >

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com Oct. 11, 2016

Oct. 11, 2016

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. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1364118: Integer handling issues (NO_EFFECT) /src/northbridge/intel/x4x/gma.c: 190 in intel_gma_init() ________________________________________________________________________________________________________ *** CID 1364118: Integer handling issues (NO_EFFECT) /src/northbridge/intel/x4x/gma.c: 190 in intel_gma_init() 184 for (candp1 = 8; candp1 >= 1; candp1--) { 185 u32 m = 5 * (candm1 + 2) + (candm2 + 2); 186 u32 p = candp1 * 10; /* 10 == p2 */ 187 u32 vco = DIV_ROUND_CLOSEST( 188 BASE_FREQUENCY * m, candn + 2); 189 u32 dot = DIV_ROUND_CLOSEST(vco, p); >>> CID 1364118: Integer handling issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "dot - target_frequency < 0U". 190 u32 this_err = ABS(dot - target_frequency); 191 if (this_err < err_most) { 192 err_most = this_err; 193 pixel_n = candn; 194 pixel_m1 = candm1; 195 pixel_m2 = candm2; ________________________________________________________________________________________________________ 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