coreboot February 2017

coreboot@coreboot.org

66 participants
212 discussions

x220 tablet flash chip
by Leah Rowe 25 Feb '17

25 Feb '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 hi, can someone with an X220 Tablet tell me whether it's wson or soic8? - -- Leah Rowe Libreboot developer Use free software. Free as in freedom. https://en.wikipedia.org/wiki/Free_software Use a free operating system, GNU+Linux. https://libreboot.org/docs/distros/ Or BSD: https://libreboot.org/docs/bsd/ Use a free BIOS. https://libreboot.org/ Support computer user freedom. https://peers.community/ Minifree Ltd, trading as Ministry of Freedom | Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK | Web: https://minifree.org/ -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE+JRrnG26iGmvPhSA/0W3TPnRz5QFAlixSTwACgkQ/0W3TPnR z5Q23Qf9HVtILM/6shbAQGNdhIFQV7eTSPp25JVBAx2yY8PTlaedmipT0zaESalE v7UM7eV3egYsFYZHSPylx/v+WlWEDPb4bHkAYeAwiv3RCFx7phwk3MX2kr8Zq6UJ LifULv9LLyA1SZPZqB8v5+BfuCfJS22u1k4VVqSc/PyZENxtEU5KBObo6v4YRvW9 GhrQhslfUtkFrl6XyBjnrxqaKlSYoMy80LUWm5WThNgDOuOZSVwM36cuNdlsc2VI xj/t9ccHX0qftUVVx4rvAKPYGvtPCT/J9Dalo4qxsOxOt8AJ6eb7T+70rS5X39wY 812nI8G3cqWiwCaZqm22g2zZxQmEgQ== =j43+ -----END PGP SIGNATURE-----

1 0

Re: [coreboot] Coreboot at Apollo Lake Oxbohill CRB
by Andrey Petrov 25 Feb '17

25 Feb '17

Hi, On 02/24/2017 09:19 PM, Gailu Singh wrote: > Hi Experts, > > I have built coreboot image for Apollo Lake and trying to boot Oxbohill > CRB but no console or display at HDMI port. you need a bunch of blobs (of course), most importantly fitimage.bin and fsp. Please use https://review.coreboot.org/#/c/18479/3 as starting point. That is for Leafhill. But once you apply that patch, select mainboard intel/leafhill in 'make nconfig', put the sacred blobs in the designated location and 'make' should give you flashable coreboot.rom. Best Andrey

1 0

Coreboot at Apollo Lake Oxbohill CRB
by Gailu Singh 25 Feb '17

25 Feb '17

Hi Experts, I have built coreboot image for Apollo Lake and trying to boot Oxbohill CRB but no console or display at HDMI port. My coreboot.rom details Name Offset Type Size cbfs master header 0x0 cbfs header 32 fallback/romstage 0x80 stage 28268 cpu_microcode_blob.bin 0x6f40 microcode 0 fallback/ramstage 0x6fc0 stage 65343 config 0x16f40 raw 291 revision 0x170c0 raw 569 fallback/postcar 0x17340 stage 16916 fallback/dsdt.aml 0x1b5c0 raw 99 fallback/payload 0x1b680 payload 361265 (empty) 0x73a00 null 443544 mrc.cache 0xdfec0 mrc_cache 65536 (empty) 0xeff00 null 32664 bootblock 0xf7ec0 bootblock 32768 This is an 8 MB image, I flashed it to SPI flash at address 0. When I boot the board no output is observed either on USB serial console or on HDMI display. Do I need to add something more to see at least coreboot log. I am tryng to use GRUB2 as payload to coreboot. Thanks

1 0

Mailing List vs Forum poll
by Martin Roth 25 Feb '17

25 Feb '17

As brought up in the last coreboot community meeting, the coreboot project is discussing the idea of switching from the mailing list to a forum. This idea did not originate with the coreboot leadership, but from a request by members of the community. I know many people have some strong feelings about this one way or the other. Right now we're just collecting data on how people feel about it, and looking for suggestions on ways to either improve the mailing list or set up a well-run forum. Here's the poll about the switch. I plan to close the poll next Friday, March 3, 2017. https://goo.gl/9Hd569 Thanks for participating. Martin

1 0

Re: [coreboot] [RFC] Always include coreboot banner in console independent of log level
by Martin Roth 25 Feb '17

25 Feb '17

My argument is that if nothing at all is shown, its difficult to know if that's because nothing needs to be shown, or because the console is busted. Maybe we break break up the banner, and don't print both romstage and ramstage banners, but just the romstage banner. I'd say that just printing the coreboot version should be sufficient, especially since the build date is based on the commit id: So at loglevel 0, we get: coreboot-4.5-1079-g613350897d At loglevel 5 (or whatever) we get the additional text: coreboot-4.5-1079-g613350897d Fri Feb 24 14:59:42 UTC 2017 romstage starting... On Fri, Feb 24, 2017 at 4:33 PM, Julius Werner <jwerner(a)chromium.org> wrote: > I think "only print problems / exceptional conditions" is a reasonable use > case. All UART output wastes time. > > Is there a reason you want to see the banner but don't want to run at > NOTICE? Maybe the better answer would be to add a new log level (e.g. > LOG_IMPORTANT) between NOTICE and WARNING (or maybe between WARNING and > ERROR)? Do you think there's a case where you would not want to see actual > errors, but still want to see the banner? (Of course it's possible that on > some platforms even LOG_ERROR spews uninteresting spam right now, but we > should probably consider that a bug with the code that does so instead.) > > On Fri, Feb 24, 2017 at 2:05 PM, Martin Roth <gaumless(a)gmail.com> wrote: > >> Hi Paul, >> I agree that it seems reasonable to always print the banner to the >> console. My recommendation is that we don't even add it as an option. If >> there's a console set up, write the banner to it. >> >> As I recall from Sage's version of coreboot, they made this same change, >> and printed it at level 0. >> >> Martin >> >> >> >> On Fri, Feb 24, 2017 at 2:52 PM, Paul Menzel via coreboot < >> coreboot(a)coreboot.org> wrote: >> >>> Dear coreboot folks, >>> >>> >>> Playing a little with the log levels and QEMU, it turns out that there >>> are no coreboot messages below the log level *NOTICE*. >>> >>> This is expected, but like with SeaBIOS, it’d be a good idea in my >>> opinion to at least output the “banner” of romstage and ramstage. >>> >>> ``` >>> coreboot-4.5-1079-g613350897d Fri Feb 24 14:59:42 UTC 2017 romstage >>> starting... >>> >>> coreboot-4.5-1079-g613350897d Fri Feb 24 14:59:42 UTC 2017 ramstage >>> starting... >>> ``` >>> >>> This doesn’t map with the current log level description. Here are the >>> log levels with their help text from `src/console/Kconfig`. >>> >>> > config DEFAULT_CONSOLE_LOGLEVEL_8 >>> > bool "8: SPEW" >>> > help >>> > Way too many details. >>> > config DEFAULT_CONSOLE_LOGLEVEL_7 >>> > bool "7: DEBUG" >>> > help >>> > Debug-level messages. >>> > config DEFAULT_CONSOLE_LOGLEVEL_6 >>> > bool "6: INFO" >>> > help >>> > Informational messages. >>> > config DEFAULT_CONSOLE_LOGLEVEL_5 >>> > bool "5: NOTICE" >>> > help >>> > Normal but significant conditions. >>> > config DEFAULT_CONSOLE_LOGLEVEL_4 >>> > bool "4: WARNING" >>> > help >>> > Warning conditions. >>> > config DEFAULT_CONSOLE_LOGLEVEL_3 >>> > bool "3: ERR" >>> > help >>> > Error conditions. >>> > config DEFAULT_CONSOLE_LOGLEVEL_2 >>> > bool "2: CRIT" >>> > help >>> > Critical conditions. >>> > config DEFAULT_CONSOLE_LOGLEVEL_1 >>> > bool "1: ALERT" >>> > help >>> > Action must be taken immediately. >>> > config DEFAULT_CONSOLE_LOGLEVEL_0 >>> > bool "0: EMERG" >>> > help >>> > System is unusable. >>> >>> In my opinion, it’d be a good idea to make an exception for the banner. >>> >>> What do you think? Another solution would be, to make that a separate >>> Kconfig option like `CONSOLE_ALWAYS_PRINT_BANNER`, but I’d like to not >>> add other configuration options, if it’s not needed. >>> >>> >>> Thanks, >>> >>> Paul >>> -- >>> 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

Re: [coreboot] [RFC] Always include coreboot banner in console independent of log level
by Julius Werner 25 Feb '17

25 Feb '17

I think "only print problems / exceptional conditions" is a reasonable use case. All UART output wastes time. Is there a reason you want to see the banner but don't want to run at NOTICE? Maybe the better answer would be to add a new log level (e.g. LOG_IMPORTANT) between NOTICE and WARNING (or maybe between WARNING and ERROR)? Do you think there's a case where you would not want to see actual errors, but still want to see the banner? (Of course it's possible that on some platforms even LOG_ERROR spews uninteresting spam right now, but we should probably consider that a bug with the code that does so instead.) On Fri, Feb 24, 2017 at 2:05 PM, Martin Roth <gaumless(a)gmail.com> wrote: > Hi Paul, > I agree that it seems reasonable to always print the banner to the > console. My recommendation is that we don't even add it as an option. If > there's a console set up, write the banner to it. > > As I recall from Sage's version of coreboot, they made this same change, > and printed it at level 0. > > Martin > > > > On Fri, Feb 24, 2017 at 2:52 PM, Paul Menzel via coreboot < > coreboot(a)coreboot.org> wrote: > >> Dear coreboot folks, >> >> >> Playing a little with the log levels and QEMU, it turns out that there >> are no coreboot messages below the log level *NOTICE*. >> >> This is expected, but like with SeaBIOS, it’d be a good idea in my >> opinion to at least output the “banner” of romstage and ramstage. >> >> ``` >> coreboot-4.5-1079-g613350897d Fri Feb 24 14:59:42 UTC 2017 romstage >> starting... >> >> coreboot-4.5-1079-g613350897d Fri Feb 24 14:59:42 UTC 2017 ramstage >> starting... >> ``` >> >> This doesn’t map with the current log level description. Here are the >> log levels with their help text from `src/console/Kconfig`. >> >> > config DEFAULT_CONSOLE_LOGLEVEL_8 >> > bool "8: SPEW" >> > help >> > Way too many details. >> > config DEFAULT_CONSOLE_LOGLEVEL_7 >> > bool "7: DEBUG" >> > help >> > Debug-level messages. >> > config DEFAULT_CONSOLE_LOGLEVEL_6 >> > bool "6: INFO" >> > help >> > Informational messages. >> > config DEFAULT_CONSOLE_LOGLEVEL_5 >> > bool "5: NOTICE" >> > help >> > Normal but significant conditions. >> > config DEFAULT_CONSOLE_LOGLEVEL_4 >> > bool "4: WARNING" >> > help >> > Warning conditions. >> > config DEFAULT_CONSOLE_LOGLEVEL_3 >> > bool "3: ERR" >> > help >> > Error conditions. >> > config DEFAULT_CONSOLE_LOGLEVEL_2 >> > bool "2: CRIT" >> > help >> > Critical conditions. >> > config DEFAULT_CONSOLE_LOGLEVEL_1 >> > bool "1: ALERT" >> > help >> > Action must be taken immediately. >> > config DEFAULT_CONSOLE_LOGLEVEL_0 >> > bool "0: EMERG" >> > help >> > System is unusable. >> >> In my opinion, it’d be a good idea to make an exception for the banner. >> >> What do you think? Another solution would be, to make that a separate >> Kconfig option like `CONSOLE_ALWAYS_PRINT_BANNER`, but I’d like to not >> add other configuration options, if it’s not needed. >> >> >> Thanks, >> >> Paul >> -- >> 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

Re: [coreboot] Coreboot on Thinkpad "X62" (i7-5600u)?
by Taiidan＠gmx.com 24 Feb '17

24 Feb '17

On 02/23/2017 04:22 PM, Rafael Send wrote: > "MEI device not found". I take it that's good news? > > Rafael > > On Thu, Feb 23, 2017 at 4:51 AM, Iru Cai <mytbk920423(a)gmail.com> wrote: > >> Hello, >> >> On Thu, Feb 23, 2017 at 3:46 PM, Rafael Send <rsend(a)berkeley.edu> wrote: >> >>> Hello there- >>> I'm assuming this is the right way to ask a general question, but please >>> let me know if it isn't. >>> >>> I have an "X62" laptop, which is actually an old Thinkpad X61 with a >>> custom motherboard in it. >>> This board has an i7-5600u CPU on it, and I was wondering if it was >>> possible to build a version of coreboot for this machine. >>> I see an existing mailing list entry in the archive discussing a >>> Chromebook Pixel with the same CPU, so I'm thinking it may be possible >>> unless I'm missing something major. >>> Since this is a custom motherboard, how would I find out about the Intel >>> Boot Guard and related issues so that I can provide the details for the >>> good folks here? >>> >> You can try https://review.coreboot.org/#/c/16328/, or modify some >> instructions in the firmware to see if it still boots. >> >> If boot guard is not enabled, I think booting with coreboot is not so >> hard, but it may be hard to make the EC interface work fine. >> >> Iru >> >> I'm pretty comfortable around Linux but probably would have trouble >>> building this from scratch. >>> Thanks in advance! >>> >>> Rafael >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://www.coreboot.org/mailman/listinfo/coreboot >>> >> >> >> -- >> Please do not send me Microsoft Office/Apple iWork documents. Send >> OpenDocument instead! http://fsf.org/campaigns/opendocument/ >> What appears in lspci has no bearing on what is actually DMA capable. You have the same effect by using the ME option ROM to set it to "disabled" but how do you know it is really disabled? you don't.

1 0

[RFC] Always include coreboot banner in console independent of log level
by Paul Menzel 24 Feb '17

24 Feb '17

Dear coreboot folks, Playing a little with the log levels and QEMU, it turns out that there are no coreboot messages below the log level *NOTICE*. This is expected, but like with SeaBIOS, it’d be a good idea in my opinion to at least output the “banner” of romstage and ramstage. ``` coreboot-4.5-1079-g613350897d Fri Feb 24 14:59:42 UTC 2017 romstage starting... coreboot-4.5-1079-g613350897d Fri Feb 24 14:59:42 UTC 2017 ramstage starting... ``` This doesn’t map with the current log level description. Here are the log levels with their help text from `src/console/Kconfig`. > config DEFAULT_CONSOLE_LOGLEVEL_8 > bool "8: SPEW" > help > Way too many details. > config DEFAULT_CONSOLE_LOGLEVEL_7 > bool "7: DEBUG" > help > Debug-level messages. > config DEFAULT_CONSOLE_LOGLEVEL_6 > bool "6: INFO" > help > Informational messages. > config DEFAULT_CONSOLE_LOGLEVEL_5 > bool "5: NOTICE" > help > Normal but significant conditions. > config DEFAULT_CONSOLE_LOGLEVEL_4 > bool "4: WARNING" > help > Warning conditions. > config DEFAULT_CONSOLE_LOGLEVEL_3 > bool "3: ERR" > help > Error conditions. > config DEFAULT_CONSOLE_LOGLEVEL_2 > bool "2: CRIT" > help > Critical conditions. > config DEFAULT_CONSOLE_LOGLEVEL_1 > bool "1: ALERT" > help > Action must be taken immediately. > config DEFAULT_CONSOLE_LOGLEVEL_0 > bool "0: EMERG" > help > System is unusable. In my opinion, it’d be a good idea to make an exception for the banner. What do you think? Another solution would be, to make that a separate Kconfig option like `CONSOLE_ALWAYS_PRINT_BANNER`, but I’d like to not add other configuration options, if it’s not needed. Thanks, Paul

3 2

Re: [coreboot] [RFC] Always include coreboot banner in console independent of log level
by Paul Menzel 24 Feb '17

24 Feb '17

Dear Ron, Am Freitag, den 24.02.2017, 21:56 +0000 schrieb ron minnich: > I agree with you. Always avoid new options. Good. ;-) > Just print the banner at spew. That's what spew is there for. Hmm, as written, in my opinion the log level for that should actually be lower, and not higher. Could you please elaborate, why you think always having a banner is useless? Thanks, Paul

1 0

Re: [coreboot] Dont filter supported CPUs on a mainboard by the CPUID
by Julius Werner 24 Feb '17

24 Feb '17

How about just changing the die() into a printk(BIOS_ALERT, ...) and an assert(0)? Then people could use CONFIG_FATAL_ASSERTS to select whether they would rather fail fast or try to keep booting as far as possible. On Fri, Feb 24, 2017 at 7:46 AM, ron minnich <rminnich(a)gmail.com> wrote: > For those of us working on boards that don't ship in a product, the die() > is probably not appropriate. But if you intend to ship a real product then > you definitely want to die() if someone tries to use a CPU that's not > tested on the board. > > Or at least that's the way it seems to me. > > On Fri, Feb 24, 2017 at 7:42 AM Aaron Durbin via coreboot < > coreboot(a)coreboot.org> wrote: > >> On Fri, Feb 24, 2017 at 5:04 AM, <i1w5d7gf38keg(a)tutanota.com> wrote: >> > Yes, this die() is what i mean. Try to get maybe some functionality is i >> > think better then just stopping there and providing zero functionality. >> > >> > I also know, that there is a message when the CPUID is not known. Its >> about >> > the die() afterwards. >> >> Patches always welcome. Did you try removing the die() and seeing if >> things actually booted? >> >> > >> > >> > 23. Feb 2017 14:31 by coreboot(a)coreboot.org: >> > >> > On Thu, Feb 23, 2017 at 2:39 AM, Nico Huber <nico.h(a)gmx.de> wrote: >> > >> > On 23.02.2017 00:07, i1w5d7gf38keg(a)tutanota.com wrote: >> > >> > There is a Filter to stop booting when the CPUID is not in a list of >> > supported CPUs. This filter does not make sense in the real world usage. >> > >> > >> > It's not a filter. It's a measure to know which code to run for which >> > CPU. Please dig a little deeper before making such useless complaints. >> > >> > >> > To add to Nico's point: the cpuid list is a way to bind code code to >> > run for certain devices -- including CPUs. If the cpuid is not listed >> > then the match on device->code to run is not met. Therefore, the code >> > necessary to make that CPU work won't ever be ran. src/arch/x86/cpu.c >> > has the cpu driver binding. And there already is message printed. See >> > the callers of set_cpu_ops() in that file. The issue is that we die() >> > when no match is found. We could attempt to boot further, but there's >> > no guarantee it'd actually succeed. >> > >> > >> > Nico >> > >> > -- >> > 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 >> >> -- >> 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

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