coreboot May 2017

coreboot@coreboot.org

70 participants
202 discussions

Re: [coreboot] 2017 North American coreboot Conference
by Juliana Rodrigues 25 May '17

25 May '17

Hey, It is a shame that I've learned about the conference just now. Plane tickets to Denver are too expensive atm. Juliana 2017-05-25 23:43 GMT-03:00 Martin Roth <gaumless(a)gmail.com>: > Hi Naveed, > Yes, the conference is definitely happening. For anyone who doesn't > know where to find the information about the Denver conference, here's > the link: https://coreboot.org/Denver2017 > > We've got 30 people signed up to attend currently, and expect that a > few more will sign up in the next week. > > We're working with the SFC on billing. We'll be sending out emails to > all registered attendees next week with billing information. This is > obviously much closer that we wanted it to be, but the paperwork for > the SFC didn't get finished until last week. An announcement about > coreboot joining the SFC will be going out shortly. > > We'll also be sending another email next week with additional > information about the conference along with arrival information and > our contact information in case there are any issues for anyone > arriving in town. > > Martin > > > On Thu, May 25, 2017 at 7:31 PM, Naveed Ghori <naveed.ghori(a)dti.com.au> > wrote: > > Hi, > > > > Any update on registration payment and number of people attending. > > > > I guess I just want verification that it is still on there has been no > > communications recently. > > > > > > > > Cheer, > > > > Naveed > > > > > > > > From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of > Martin > > Roth > > Sent: Friday, 3 February 2017 1:32 AM > > To: coreboot > > Subject: [coreboot] 2017 North American coreboot Conference > > > > > > > > We are happy to announce that the 2017 North American coreboot Conference > > will be held in Denver, Colorado on June 5th & 6th, with an optional > hacking > > day on June 7th. > > > > > > Register here: https://goo.gl/o2j4gX > > > > > > > > The cost will be $250 for corporate attendees, $100 for individuals, and > $25 > > for students. > > > > All fees go up by $50 for registrations received after May 5. > > > > Payment is NOT required at the time of registration. We will contact you > > later with payment information. > > > > > > > > > > Hotel, travel, and other additional information is available on the > coreboot > > wiki: https://www.coreboot.org/Denver2017 > > > > > > > > > > > > If you have any questions, please email us at convention(a)coreboot.org > > > > > > > > > > > > Martin > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] 2017 North American coreboot Conference
by Naveed Ghori 25 May '17

25 May '17

Hi, Any update on registration payment and number of people attending. I guess I just want verification that it is still on there has been no communications recently. Cheer, Naveed From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Martin Roth Sent: Friday, 3 February 2017 1:32 AM To: coreboot Subject: [coreboot] 2017 North American coreboot Conference We are happy to announce that the 2017 North American coreboot Conference will be held in Denver, Colorado on June 5th & 6th, with an optional hacking day on June 7th. Register here: https://goo.gl/o2j4gX The cost will be $250 for corporate attendees, $100 for individuals, and $25 for students. All fees go up by $50 for registrations received after May 5. Payment is NOT required at the time of registration. We will contact you later with payment information. Hotel, travel, and other additional information is available on the coreboot wiki: https://www.coreboot.org/Denver2017<https://linkprotect.cudasvc.com/url?a=https://www.coreboot.org/Denver2017&c…> If you have any questions, please email us at convention(a)coreboot.org<mailto:convention@coreboot.org> Martin

2 1

ATOM processor E3845
by bnakache＠nolam.com 25 May '17

25 May '17

Hello All , We are wondering if coreboot supports the ATOM processor E3845 If it does please send us the information required for us to work on it for one of our motherboard. Best Regards, Benjamin Nakache Vice President Sales <http://www.nolam.com/> www.nolam.com Note: This message and any attachment hereto is intended solely for the use of the designated recipient(s) and their appointed delegates and may contain confidential information. Any unauthorized use, disclosure,copying, or distribution of its contents is strictly prohibited. If you have received this message in error, please destroy it and advise Nolam Embedded Systems immediately by phone, email, or fax.Thank you for your cooperation.

4 3

Re: [coreboot] Intel me problems
by John Lewis 25 May '17

25 May '17

Egg on face again, Lewis. ;) IDK, if you downloaded the version which the script refers to, it was compiled around 2015 IIRC, so I would expect it to be okay, but I guess I should update it too. If you downloaded one which may (or may not) be hanging around the web root, then that would probably be less so. On 25/05/17 18:18, Alejandro Flores wrote: > Ironic you should ask. :) The binary came from your website. I used it > to flash the boot stub only to start and assumed it would work for the > full rom also. Ooops. > > On May 25, 2017 2:04 AM, "John Lewis" <jlewis(a)johnlewis.ie > <mailto:jlewis@johnlewis.ie>> wrote: > > Where did the binary come from? In distro version? It's really > recommended to use a ChromeOS version of Flashrom to flash > Chromebooks - makes things easier. > > Yes, it is well known that the ME can interfere with its being > overwritten amongst other things. :) > > >

2 1

Re: [coreboot] Coreboot Stickers
by Peter Stuge 25 May '17

25 May '17

Hi Rene, Rene Shuster wrote: > Where can I get Coreboot stickers? You can use the artwork at https://www.coreboot.org/Logo to order stickers in your favorite quality from a local supplier. > What are your thoughts working together w/ UnixStickers.com, so that > Coreboot would receive part of the sales as monthly donations ( > https://www.unixstickers.com/donations ). I don't know unixstickers.com at all, but I think that sticker sales are unlikely to make a big difference for the coreboot project, and would cause more of an administrative burden than a benefit. Hardware and firmware engineering has never been as divided as today, and there is obvious interest to widen that gap. I think it would be great if you made stickers and let more people know about the coreboot project, but more importantly about firmware engineering in general, to counter the current trend with high-end hardware to increase secrecy, to make technology less accessible and to separate producers from consumers. Thanks! //Peter

2 1

Re: [coreboot] GPIO PADRSTCFG conflict in datasheet
by Youness Alaoui 25 May '17

25 May '17

Hi, I just found this file here : https://github.com/IntelFsp/FSP/blob/Skylake/SkylakeFspBinPkg/Include/GpioC… It defines the reset values for GPIO in this enum : typedef enum { GpioResetDefault = 0x0, ///< Leave value of pad reset unmodified GpioResetPwrGood = 0x1, ///< GPP: RSMRST; GPD: DSW_PWROK; (PadRstCfg = 00b = "Powergood") GpioResetDeep = 0x3, ///< Deep GPIO Reset (PadRstCfg = 01b = "Deep GPIO Reset") GpioResetNormal = 0x5, ///< GPIO Reset (PadRstCfg = 10b = "GPIO Reset" ) GpioResetResume = 0x7 ///< GPP: Reserved; GPD: RSMRST; (PadRstCfg = 11b = "Resume Reset" ) } GPIO_RESET_CONFIG; We can see it specifically says that 00b is "GPP: RSMRST; GPD: DSW_PWROK" and 11b is "GPP: Reserved; GPD: RSMRST". So I'm leaning towards the datasheet not having a typo, but rather they just have different values for RSMRST depending on whether it's GPP or GPD, so I vote for changing the define in coreboot so it stops being confusing for those who want to use RSMRST. I'll send a patch shortly to do it as I suggested in my previous email, unless someone else has a better idea. Thanks, Youness. On Thu, May 18, 2017 at 2:56 PM, Youness Alaoui <kakaroto(a)kakaroto.homelinux.net> wrote: > Hi, > > I'm working on a skylake port and I've noticed something with the PADRSTCFG > field of the GPIO Pad configuration. If you look at the 100-series datasheet > volume 2 > (https://www-ssl.intel.com/content/www/us/en/chipsets/100-series-chipset-dat…). > The Pad configuration DW0 for GPP_A, GPP_B, GPP_C, etc.. (page 1179, 1249) > up to GPP_I (page 1319) has bits 31:30 (PADRSTCFG) defined like this : > 00 = RSMRST# > 01 = Host deep reset. > 10 = PLTRST# > 11 = Reserved > > But the Pad configuration DW0 for GPD pads (page 1296) has it defined like > this : > 00 = DSW_PWROK > 01 = Host deep reset. > 10 = PLTRST# > 11 = RSMRST# > > The problem here is that while the DEEP and PLTRST values are the same, the > RSMRST value is 0 for GPP gpio pads, and 3 for GPD gpio pads. In the skylake > and apollolake gpio_defs.h file, it is defined like this (with different > naming for apollolake but same values) : > #define PADRSTCFG_DSW_PWROK 0 > #define PADRSTCFG_DEEP 1 > #define PADRSTCFG_PLTRST 2 > #define PADRSTCFG_RSMRST 3 > > These defines are only valid for GPD pads, if someone was to use a RSMRST > reset config on a GPP pad, they would be setting the pad to a 'reserved' > configuration, which could have unexpected behavior. > There are two possibilities here, either the datasheet is wrong (and PWROK > should be 3 so the RSMRST value is consistent for both GPP and GPD), or the > datasheet is correct, and in both cases, the value in coreboot is wrong. > > If someone from Intel is reading this list, or if someone here knows someone > inside Intel who could confirm whether or not the datasheet has an error, > that would be great. > In the meantime, I would maybe suggest to change the defines to : > #define PADRSTCFG_GPD_RSMRST 3 > #define PADRSTCFG_GPP_RSMRST 0 > > This would affect both skylake and apollolake, and note that the only > skylake+ boards that use RSMRST seem to be the kblrvp in the rvp7 variant > which sets it for GPP_A12 and GPP_E3 (which means those two gpios have the > wrong setting due to the wrong define). > > What do you think ? > > Thanks, > Youness.

1 0

ASUS KGPE-D16 Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 25 May '17

25 May '17

The ASUS KGPE-D16 fails verification for branch master as of commit 000cc598cbd2ab663e1192d8623171bda293b6d3 The following tests failed: BOOT_FAILURE Commits since last successful test: 000cc59 mb/lenovo/*60: Remove not existing DIMMs from SPD map See attached log for details This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

2 1

Re: [coreboot] VGA rom doesn't work
by Alejandro Flores 25 May '17

25 May '17

Thanks Youness, the vga works now. On May 24, 2017 8:17 PM, "Youness Alaoui" <kakaroto(a)kakaroto.homelinux.net> wrote: > Congratulations on getting the ME working again. > Your VGA device is 8086,1616, so that's what you need to set. The > 8086,0406 is probably just the default one in coreboot, but you still > have to configure it. > In 'make menuconfig', go to Devices menu and set the "VGA Device ID" > to "8086,1616", then recompile, and it will work. > I had the exact same issue . Search for "VGA" in this blog post to > read about it (I didn't say much about it other than what I just said) > : https://puri.sm/posts/librem-13-coreboot-report-february-3rd-2017/ > > Good luck, > Youness. > > On Wed, May 24, 2017 at 7:50 PM, Alejandro Flores <af49880(a)gmail.com> > wrote: > > Now that my ME problem is solved I turn to another problem. > > > > The video bios does not seem to function. During seabios boot screen no > > video is displayed. Only when grub auto loads does the video start. > > > > When I use cbfstool auron_yuna.bin print > > it shows pci8086,0406.rom at offset 0x7004c0 > > > > However when I check lspci -n it shows an address of 8086:1616 for pci > > device 00.02.0 VGA compatible controller. > > > > Which of these should I use for coreboot VGA device PCI ID? > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Intel me problems
by Nico Huber 25 May '17

25 May '17

On 25.05.2017 01:34, Alejandro Flores wrote: > Problem is solved. I was using an old precompiled version of flashrom to > write the bios. Was that a chromiumos flashrom? or flashrom proper? > When I compiled a new binary from latest source it gave an > error when I tried to write the rom. > > It said it would be unable to write to ME since the ME is currently active > and in use. The old binary hadn't given any error and presumably tried to > write to ME and failed silently leaving some mix of new and old that failed > signature verification. Leaving a mix should be impossible if the firmware descriptor is cor- rectly configured. Do you have a backup of the original descriptor? > > I confirmed this by using a hardware writer to verify first that the rom on > chip is not the rom I intended to write and then writng the correct rom. > > ME now works as expected. I wonder though if this is expected behavior to > be unable to flash the ME from a running system or if it is just my model > of laptop? Yes, the ME region is completely locked (not even readable) in the correct configuration. You can however flash other regions (patches for flashrom are pending, currently it gets confused because it can't read). Nico

2 1

Re: [coreboot] Intel me problems
by John Lewis 25 May '17

25 May '17

Where did the binary come from? In distro version? It's really recommended to use a ChromeOS version of Flashrom to flash Chromebooks - makes things easier. Yes, it is well known that the ME can interfere with its being overwritten amongst other things. :) https://www.flashrom.org/ME On 25/05/17 00:34, Alejandro Flores wrote: > Problem is solved. I was using an old precompiled version of flashrom > to write the bios. When I compiled a new binary from latest source it > gave an error when I tried to write the rom. > > It said it would be unable to write to ME since the ME is currently > active and in use. The old binary hadn't given any error and > presumably tried to write to ME and failed silently leaving some mix > of new and old that failed signature verification. > > I confirmed this by using a hardware writer to verify first that the > rom on chip is not the rom I intended to write and then writng the > correct rom. > > ME now works as expected. I wonder though if this is expected behavior > to be unable to flash the ME from a running system or if it is just my > model of laptop? > >

2 1

← Newer
1
2
3
4
5
6
7
...
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