coreboot June 2014

coreboot@coreboot.org

45 participants
77 discussions

Re: [coreboot] setting smbios values from the OS
by Giri 21 Jun '14

21 Jun '14

I believe the request is about filling SMBIOS Table Type 1 – System Information. Fields like Manufacturer, Product Name, Version, Serial Number, UUID, SKU Number, Family…. Some fields are unique per platform / system like Serial Number, UUID. -Giri From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of ron minnich Sent: Friday, June 20, 2014 11:24 PM To: Patrick Georgi Cc: coreboot Subject: Re: [coreboot] setting smbios values from the OS On Fri, Jun 20, 2014 at 11:20 PM, Patrick Georgi <patrick(a)georgi-clan.de <mailto:patrick@georgi-clan.de> > wrote: In the end, I pose the question why a serial number must be exported to the OS in the first place - this looks like a potential privacy issue to me, while doing nothing for servicing the part (if it's sent back, read the bar code). There I also agree. I don't like electronically readable serial numbers in general on computers. ron

1 0

Re: [coreboot] Improvement of coreboot code (was: latest baytrail fsp on CRB)
by ron minnich 21 Jun '14

21 Jun '14

On Sat, Jun 21, 2014 at 5:17 AM, Karl-Heinz Nirschl <kh.nirschl(a)gmail.com> wrote: > But anyway - the real statement of the message meant to be: "thanks for > all the good code". > > > > That's very kind of you. I think you are right about the code, it has improved a lot in the last couple years. ron

1 0

Improvement of coreboot code (was: latest baytrail fsp on CRB)
by Paul Menzel 21 Jun '14

21 Jun '14

Dear Karl-Heinz, Am Freitag, den 20.06.2014, 21:17 +0200 schrieb Karl-Heinz Nirschl: > i did some experiments with the baytrail fsp coreboot and first of all i > like to say thanks for all the good code! everything looks much better than > the last time i tried to do anything with coreboot. could you please elaborate on that statement? When was that last time and what device/board did you look at? I ask because in my experience the majority of coreboot code lives up to a high standard since several years now. […] Thanks, Paul

2 2

Re: [coreboot] setting smbios values from the OS
by Patrick Georgi 21 Jun '14

21 Jun '14

Am 21.06.2014 08:06, schrieb ron minnich: > very interesting. Thing is, this is pretty much the antithesis of > build-time serial number creation ... which is the thing that I don't > see scaling. Right now we compile any serial number right into .text, and modifying that is not a good idea (plus, updaters won't be able to handle that properly either). By storing the ID somewhere (be that at a magic location or in CBFS) at least there's the possibility of keeping it around when updating the same way it's currently done. In the end, I pose the question why a serial number must be exported to the OS in the first place - this looks like a potential privacy issue to me, while doing nothing for servicing the part (if it's sent back, read the bar code). Given the possibility of runtime modifying the values (in a preboot loader), it doesn't even function as some cheap DRM scheme. Which brings us back to the original question ;-) Patrick

2 1

Re: [coreboot] coreboot engineer needed
by Scott Duplichan 21 Jun '14

21 Jun '14

A coreboot(a)coreboot.org subscriber wrote: ]Hi Scott, ] ]It appears they are looking for a full-time position. If they were ]willing to outsource, I would be interested. It might be useful to apply anyway. Others have pointed out that most of the coreboot experts are located in Europe. If a few engineers from remote or non-US locations responded, it might get the hiring manager interested. I point out this job offer because the recent Intel coreboot openings are unique in an important aspect. Today, a BIOS engineer who wants the security, pay and other benefits of working for a major computer OEM must learn to be happy living in the world of UEFI, including its rules, regulations, mandates, laws, restrictions, enforcements, and "coding standard". Want to use features of C99? Sorry, Microsoft doesn't support that. Want to use static functions? Sorry, those are banned. Want to use a comma operator? Sorry, forbidden. Want to start a local variable name with a lower case letter? Sorry, prohibited. Want to write ugly code full of dangerous type casts, spaghetti gotos, and countless global variables? You're in luck. Today, the Intel coreboot openings are the only non-UEFI BIOS jobs that I know of. Thanks, Scott ]On 06/19/2014 08:11 PM, Scott Duplichan wrote: ]> Scott Duplichan [mailto:scott@notabs.org] wrote: ]> ]> ]Sent: Thursday, January 09, 2014 08:37 AM ]> ]To: 'coreboot(a)coreboot.org' ]> ]Subject: coreboot engineer needed ]> ] ]> ] ]> ]https://intel.taleo.net/careersection/10000/jobdetail.ftl?job=725464 ]> ] ]> ]Thanks, ]> ]Scott ]> ]> https://intel.taleo.net/careersection/10000/jobdetail.ftl?]job=737461&src=J… ]> ]> "Coreboot BIOS development for Chrome OS" ]> ]> Thanks, ]> Scott

1 0

Re: [coreboot] setting smbios values from the OS
by Scott Duplichan 21 Jun '14

21 Jun '14

ron minnich [mailto:rminnich@gmail.com] wrote: ]realistically, though, it's hard for me to see how setting the ]serial # at firmware image build time scales. And setting it after ]boot makes no real sense either -- it's not really a serial number ]if you're changing it at that point. ]But some way to customize the binary images with a serial number ]seems most workable, if you're going to put the serial number in ]the firmware image at all (which never made sense to me either ]--serial #s are supposed to be indelible, and firmware images are ]not indelible). ] ]ron Putting the serial number in the same flash chip as the main firmware is a cost reduction measure used with desktop and other low cost boards. I have even seen a board where the MAC address lives there. The only protection for those items is that the flash utility given to the end user knows to skip that area. The way I have seen the serial number programmed is at manufacturing diagnostics time. The board is PXE booted to a diagnostic image. The image runs a script that first erases the entire flash chip. It then programs it with the OEM firmware image. The OEM image contains a blank serial number. The script then prompts for operator input. The operator pulls a barcoded serial number label from a roll and attaches it to the board. The operator then scans the label with a barcode reader. The script uses the barcode data to find the serial number in a database. The script then runs a special flash utility that reprograms only the serial number portion of the flash chip. If the end user flashes the firmware by any method other than the supplied utility, the serial number will be lost. It can still be read from the barcoded label though. Thanks, Scott

2 1

Re: [coreboot] latest baytrail fsp on CRB
by Martin Roth 20 Jun '14

20 Jun '14

Hi, I'm getting ready to push some code that better aligns things between the Kconfig option and the FSP for the MMIO configuration area. It shouldn't be a problem after that. Martin On 06/20/2014 01:17 PM, Karl-Heinz Nirschl wrote: > hi, > > i did some experiments with the baytrail fsp coreboot and first of all > i like to say thanks for all the good code! everything looks much > better than the last time i tried to do anything with coreboot. > > for the problems - maybe there is something wrong with reading the > ids. i found that on my platform it seems like fsp is change mmio base > address. so pci reads will not work there after and read all ff. > > > maybe there should be a check which reads back mmio and does some > debug log. a example for access to the base address is in setup_mmconfig > > > regards, > > > 2014-06-20 12:33 GMT+02:00 Mike Hibbett <mhibbett(a)ircona.com > <mailto:mhibbett@ircona.com>>: > > > PCI ids will be different > > Oh - what do you mean by the Sean? > > I am still trying to understand why for two identical > CPUID/Stepping E3815s, with the same 8BM flash image, I get > different PCI device ids for the Soc Transaction Router ( 0000 > rather than 0f00 ) and Video ( 0031 rather than 0f00 ). Is this > related? > > I’ve asked Intel Premier Support but heard nothing back yet. Still > puzzled :o) > > Mike. > > *From:*coreboot [mailto:coreboot-bounces@coreboot.org > <mailto:coreboot-bounces@coreboot.org>] *On Behalf Of *Sean McNeil > *Sent:* 20 June 2014 11:26 > *To:* Gerald Otter > *Cc:* Wen Wang; coreboot > > > *Subject:* Re: [coreboot] latest baytrail fsp on CRB > > PCI ids will be different. Plus some devices may be disabled. > > On Jun 20, 2014 5:21 PM, "Gerald Otter" <gerald.otter(a)gmail.com > <mailto:gerald.otter@gmail.com>> wrote: > > As Mike mentioned earlier, you need the TXE ( located in top 6MB ) > from BYT-I_SEC_DUAL_BOOT_PV_GOLD. > > The TXE from the BIOS’s you mentioned don’t work with coreboot. I > ran into the same issue as you. > > Alternatively you can erase the top 6MB to start in non-descriptor > mode. I don’t think this matters much for coreboot’s startup > process, but could be wrong. > > Gerald > > On 19 Jun 2014, at 23:08, Wen Wang <wen.wang(a)adiengineering.com > <mailto:wen.wang@adiengineering.com>> wrote: > > > > I went back to the commit (Martin’s commit > d75800c7f2476bee243cc22255acb54d6676d4bc back in late May) that > seems work for a few people on the list. I also thought it was > working better for me too as I was observing coreboot and fsp > booting until it failed at SeaBIOS. It turned out I had a pilot > error flashing the image. I thought I flashed the top 2M of the > flash, but my script accidentally erased the bottom 6M. > Surprisingly it booted quite far. Anyhow, after I corrected my > script today (flashing only the top 2M, leaving rest from BIOS). > Nothing happens, port 80 remains 0, no console output. Here is > cbfstool print, my config file is attached to an earlier post, > > [wenwang@localhost coreboot]$ build/cbfstool build/coreboot.rom print > > coreboot.rom: 2048 kB, bootblocksize 1024, romsize 2097152, offset 0x0 > > alignment: 64 bytes > > Name Offset Type Size > > cmos_layout.bin 0x0 cmos_layout 1132 > > pci8086,0f31.rom 0x4c0 optionrom 65536 > > fallback/romstage 0x10500 stage 27029 > > fallback/ramstage 0x16f00 stage 58966 > > fallback/payload 0x255c0 payload 59949 > > config 0x34040 raw 4239 > > (empty) 0x35100 null 896728 > > cpu_microcode_blob.bin 0x110000 microcode 52224 > > (empty) 0x11cc40 null 209752 > > mrc.cache 0x14ffc0 (unknown) 65536 > > (empty) 0x160000 null 393112 > > fsp.bin 0x1bffc0 (unknown) 229376 > > (empty) 0x1f8000 null 31640 > > Could it be my BIOS issue? I tried both 64 and 32-bit BIOS from > 540469_540469_BYT_l_66_41_ReleasePackage and > 543844_543844_BYTI_080_011_ReleasePackage. None of them works with > my coreboot build. . Can somebody please share the working BIOS > version? > > Thanks, > > Wen > > *From:*Mike Hibbett [mailto:mhibbett@ircona.com] > *Sent:* Wednesday, June 18, 2014 4:58 PM > *To:* Wen Wang; Mike Hibbett; coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > *Subject:* Re: [coreboot] latest baytrail fsp on CRB > > Use the one that came with your board, or get the latest From the > IBL. I forget the document number but the file is called > byt-i_sec_dual_boot_pv_gold > > Mike > > Sent with AquaMail for Android > http://www.aqua-mail.com <http://www.aqua-mail.com/> > > On 18 June 2014 21:15:51 Wen Wang <wen.wang(a)adiengineering.com > <mailto:wen.wang@adiengineering.com>> wrote: > > .config file attached. > > Also what should I do for flash descriptor? > > Thanks, > > Wen > > *From:*Mike Hibbett [mailto:mhibbett@ircona.com] > *Sent:* Wednesday, June 18, 2014 2:29 PM > *To:* Wen Wang; coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > *Subject:* Re: [coreboot] latest baytrail fsp on CRB > > Can you post your coreboot .config file? > > I'm booting bayley bay with a b3 e3815. > > Mike > > Sent with AquaMail for Android > http://www.aqua-mail.com <http://www.aqua-mail.com/> > > On 18 June 2014 19:13:49 Wen Wang <wen.wang(a)adiengineering.com > <mailto:wen.wang@adiengineering.com>> wrote: > > Hi all, > > Has anybody been able to boot Bayley Bay CRB with the > latest coreboot source from the git tree? We have a Bayley > Bay CRB (E3827, B3). With coreboot Baytrail fsp support > pulled from about two weeks ago and some help from Martin, > I was able to see coreboot booting and fsp loaded, but was > having issues with SeaBIOS. I pulled latest source tree > this morning and found out it does not boot any more on my > board. Port 80 stuck at code 0x43, no console output. > > Here are my steps: > > 1.Build coreboot toolchain. > > 2.Build coreboot.rom using fsp and microcode from > BAY_TRAIL_FSP_KIT downloaded from Intel fsp site. > > 3.Flash coreboot.rom to top 2M of the 8M flash. > > I was getting the usage information here and there from > the discussion threads and perhaps I missed something? It > would be great if somebody could post the detailed procedure. > > Thanks! > > Wen > > -- > 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 > <mailto:coreboot@coreboot.org> > http://www.coreboot.org/mailman/listinfo/coreboot > > > -- > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > http://www.coreboot.org/mailman/listinfo/coreboot > > > >

1 0

Re: [coreboot] latest baytrail fsp on CRB
by Mike Hibbett 20 Jun '14

20 Jun '14

> PCI ids will be different Oh - what do you mean by the Sean? I am still trying to understand why for two identical CPUID/Stepping E3815s, with the same 8BM flash image, I get different PCI device ids for the Soc Transaction Router ( 0000 rather than 0f00 ) and Video ( 0031 rather than 0f00 ). Is this related? I’ve asked Intel Premier Support but heard nothing back yet. Still puzzled :o) Mike. From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Sean McNeil Sent: 20 June 2014 11:26 To: Gerald Otter Cc: Wen Wang; coreboot Subject: Re: [coreboot] latest baytrail fsp on CRB PCI ids will be different. Plus some devices may be disabled. On Jun 20, 2014 5:21 PM, "Gerald Otter" <gerald.otter(a)gmail.com<mailto:gerald.otter@gmail.com>> wrote: As Mike mentioned earlier, you need the TXE ( located in top 6MB ) from BYT-I_SEC_DUAL_BOOT_PV_GOLD. The TXE from the BIOS’s you mentioned don’t work with coreboot. I ran into the same issue as you. Alternatively you can erase the top 6MB to start in non-descriptor mode. I don’t think this matters much for coreboot’s startup process, but could be wrong. Gerald On 19 Jun 2014, at 23:08, Wen Wang <wen.wang(a)adiengineering.com<mailto:wen.wang@adiengineering.com>> wrote: I went back to the commit (Martin’s commit d75800c7f2476bee243cc22255acb54d6676d4bc back in late May) that seems work for a few people on the list. I also thought it was working better for me too as I was observing coreboot and fsp booting until it failed at SeaBIOS. It turned out I had a pilot error flashing the image. I thought I flashed the top 2M of the flash, but my script accidentally erased the bottom 6M. Surprisingly it booted quite far. Anyhow, after I corrected my script today (flashing only the top 2M, leaving rest from BIOS). Nothing happens, port 80 remains 0, no console output. Here is cbfstool print, my config file is attached to an earlier post, [wenwang@localhost coreboot]$ build/cbfstool build/coreboot.rom print coreboot.rom: 2048 kB, bootblocksize 1024, romsize 2097152, offset 0x0 alignment: 64 bytes Name Offset Type Size cmos_layout.bin 0x0 cmos_layout 1132 pci8086,0f31.rom 0x4c0 optionrom 65536 fallback/romstage 0x10500 stage 27029 fallback/ramstage 0x16f00 stage 58966 fallback/payload 0x255c0 payload 59949 config 0x34040 raw 4239 (empty) 0x35100 null 896728 cpu_microcode_blob.bin 0x110000 microcode 52224 (empty) 0x11cc40 null 209752 mrc.cache 0x14ffc0 (unknown) 65536 (empty) 0x160000 null 393112 fsp.bin 0x1bffc0 (unknown) 229376 (empty) 0x1f8000 null 31640 Could it be my BIOS issue? I tried both 64 and 32-bit BIOS from 540469_540469_BYT_l_66_41_ReleasePackage and 543844_543844_BYTI_080_011_ReleasePackage. None of them works with my coreboot build. . Can somebody please share the working BIOS version? Thanks, Wen From: Mike Hibbett [mailto:mhibbett@ircona.com] Sent: Wednesday, June 18, 2014 4:58 PM To: Wen Wang; Mike Hibbett; coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> Subject: Re: [coreboot] latest baytrail fsp on CRB Use the one that came with your board, or get the latest From the IBL. I forget the document number but the file is called byt-i_sec_dual_boot_pv_gold Mike Sent with AquaMail for Android http://www.aqua-mail.com<http://www.aqua-mail.com/> On 18 June 2014 21:15:51 Wen Wang <wen.wang(a)adiengineering.com<mailto:wen.wang@adiengineering.com>> wrote: .config file attached. Also what should I do for flash descriptor? Thanks, Wen From: Mike Hibbett [mailto:mhibbett@ircona.com] Sent: Wednesday, June 18, 2014 2:29 PM To: Wen Wang; coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> Subject: Re: [coreboot] latest baytrail fsp on CRB Can you post your coreboot .config file? I'm booting bayley bay with a b3 e3815. Mike Sent with AquaMail for Android http://www.aqua-mail.com<http://www.aqua-mail.com/> On 18 June 2014 19:13:49 Wen Wang <wen.wang(a)adiengineering.com<mailto:wen.wang@adiengineering.com>> wrote: Hi all, Has anybody been able to boot Bayley Bay CRB with the latest coreboot source from the git tree? We have a Bayley Bay CRB (E3827, B3). With coreboot Baytrail fsp support pulled from about two weeks ago and some help from Martin, I was able to see coreboot booting and fsp loaded, but was having issues with SeaBIOS. I pulled latest source tree this morning and found out it does not boot any more on my board. Port 80 stuck at code 0x43, no console output. Here are my steps: 1. Build coreboot toolchain. 2. Build coreboot.rom using fsp and microcode from BAY_TRAIL_FSP_KIT downloaded from Intel fsp site. 3. Flash coreboot.rom to top 2M of the 8M flash. I was getting the usage information here and there from the discussion threads and perhaps I missed something? It would be great if somebody could post the detailed procedure. Thanks! Wen -- 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<mailto:coreboot@coreboot.org> http://www.coreboot.org/mailman/listinfo/coreboot

3 2

Re: [coreboot] IMB-A180 based design question regarding POST codes during boot failure
by Mark C. Mason 20 Jun '14

20 Jun '14

1 0

Migrating to a free BIOS
by Kevin Mizzi 20 Jun '14

20 Jun '14

Dear Sir I would like to migrate my PC to a free BIOS. Do I have to replace the motherboard, please? Thanks Kevin

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot June 2014