coreboot April 2016

coreboot@coreboot.org

49 participants
97 discussions

Re: [coreboot] coreboot specific ACPI table
by Stefan Reinauer 22 Apr '16

22 Apr '16

On 04/18/2016 08:17 PM, Julius Werner wrote: > For comparison, the coreboot device tree interface on ARM > (https://lkml.org/lkml/2014/6/16/622, unfortunately never picked up by > the maintainers but still used on Chromebooks today) only exports > start address and size of the coreboot table and the whole CBMEM area, > so maybe ACPI should just match that. (I guess if CBMEM is referenced > by the coreboot table like Aaron said, we could also drop that part.) > Did you get other feedback than the one mail by Rob Herring? We should keep pushing this.

1 0

Building with SeaBIOS and serial debugging
by Dylan Staley 22 Apr '16

22 Apr '16

I've been attempting to get coreboot running on my Lenovo ThinkPad x230 (a supported mainboard). From the serial output I'm currently getting, it looks like coreboot is getting to the part where it loads the payload (in my case SeaBIOS), but I guess SeaBIOS isn't configured to output debug information to the serial output. This is my console output: https://gist.github.com/dstaley/73ad18b9a73eb60e5fb100972a690ef1 and my .config file https://gist.github.com/dstaley/cf2d9b2955bcfb9052b33f1b981efeb4 >From reading the Makefile in payloads/external/SeaBIOS, both CONFIG_CONSOLE_SERIAL and CONFIG_DRIVERS_UART_8250IO need to be set. However, I can't seem to find which config file I need to modify to properly set these variables. Additionally, CONFIG_TTYS0_BASE needs to be set as well. I've also attempted to manually build SeaBIOS with serial output enabled, but that didn't seem to have any impact on the result. So, in short, how do I configure coreboot in such a way so that SeaBIOS is properly set to output debug information to the serial console (in this case via a FTDI FT232H USB cable)?

1 0

Re: [coreboot] coreboot specific ACPI table
by arian 22 Apr '16

22 Apr '16

> OK. Time for bikeshedding: > > 1. CORE > 2. CBOOT > 3. ... ? 4. 0xC05EB001 :)

1 0

Re: [coreboot] coreboot specific ACPI table
by Aaron Durbin 22 Apr '16

22 Apr '16

On Fri, Apr 22, 2016 at 2:49 PM, ron minnich <rminnich(a)gmail.com> wrote: > I tend to vote for CORE, I think it is really going to be clear to people > what it's for .... > > I like CRBT but fear it gets lost in the plethora of ACPI alphabet soup. > It's been decided. Stefan, time to work your magic. > ron > > On Fri, Apr 22, 2016 at 2:40 PM Aaron Durbin <adurbin(a)google.com> wrote: >> >> On Fri, Apr 22, 2016 at 2:38 PM, ron minnich <rminnich(a)gmail.com> wrote: >> > Wait, I thought it had to be 4 characters. >> >> Yes. I cannot count. :/ CRBT >> > >> > ron >> > >> > On Fri, Apr 22, 2016 at 2:36 PM Aaron Durbin via coreboot >> > <coreboot(a)coreboot.org> wrote: >> >> >> >> On Fri, Apr 22, 2016 at 2:00 PM, Duncan Laurie <dlaurie(a)chromium.org> >> >> wrote: >> >> > On Tue, Apr 19, 2016 at 6:49 AM, Aaron Durbin <adurbin(a)google.com> >> >> > wrote: >> >> >> >> >> >> On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner >> >> >> <jwerner(a)chromium.org> >> >> >> wrote: >> >> >> > I think we should only export the coreboot table location and size >> >> >> > through ACPI and then read everything else from there. That way we >> >> >> > can >> >> >> > share almost all of the kernel driver code with ARM and just need >> >> >> > a >> >> >> > tiny platform-specific stub to look up the table location first. >> >> >> > If >> >> >> > we >> >> >> > add all the information into an actual ACPI table, we're building >> >> >> > an >> >> >> > x86-only solution again. (A generic, platform-independent coreboot >> >> >> > driver could just as easily export the stuff we want into sysfs.) >> >> >> > >> >> >> >> >> >> That's fine. The only thing I was concerned about was implementing >> >> >> an >> >> >> ACPI table proper or try to do some ACPI device shenanigans like the >> >> >> ramoops device. coreboot doesn't currently have a ACPI ID assigned >> >> >> to >> >> >> it. If we go with a ACPI device coreboot should apply for an ACPI >> >> >> ID. >> >> >> I personally think the coreboot ACPI table seems more straight >> >> >> forward, but I was wondering if people knew of any downsides to >> >> >> going >> >> >> that route. >> >> >> >> >> > >> >> > >> >> > The official tables are all defined in the ACPI spec while the >> >> > related >> >> > tables are also linked to from the spec, so we'd need to convince the >> >> > UEFI >> >> > forum to at least reserve the signature for us (and then link to our >> >> > table >> >> > definition) since they intend to act as gatekeepers to avoid >> >> > collisions >> >> > in >> >> > table signatures: >> >> > >> >> > "Requests to reserve a 4-byte alphanumeric table signature should be >> >> > sent to >> >> > the email address info(a)acpi.info and should include the purpose of >> >> > the >> >> > table >> >> > and reference URL to a document that describes the table format." >> >> > >> >> > An easier path would be to define a specific device in the DSDT and >> >> > populate >> >> > it with the various data we want to be there on every system. That >> >> > would >> >> > allow us to control the format and be able to alter it in the future >> >> > if >> >> > we >> >> > want to expose new information. >> >> > >> >> > As you note a Device would need a valid unique HID, and that needs an >> >> > ID >> >> > prefix if it wants to be official. In theory we could request >> >> > something >> >> > like "CORE" as an official APCI ID from >> >> > http://www.uefi.org/PNP_ACPI_Registry >> >> >> >> OK. Time for bikeshedding: >> >> >> >> 1. CORE >> >> 2. CBOOT >> >> 3. ... ? >> >> >> >> Stefan, we'll likely need you to request the HID w/ your coreboot.org >> >> email. >> >> >> >> > >> >> > I suppose the real difference between the two is whether we need this >> >> > data >> >> > early in boot before there is an AML interpreter available in the OS. >> >> >> >> I don't think we need it that early. Right now the current usage (at >> >> least on x86) is all very late since we're doing AML evaluation. We >> >> could go w/ the ACPI device first. Just need to request that HID. >> >> >> >> > >> >> > -duncan >> >> > >> >> > >> >> > -- >> >> > 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 specific ACPI table
by ron minnich 22 Apr '16

22 Apr '16

I tend to vote for CORE, I think it is really going to be clear to people what it's for .... I like CRBT but fear it gets lost in the plethora of ACPI alphabet soup. ron On Fri, Apr 22, 2016 at 2:40 PM Aaron Durbin <adurbin(a)google.com> wrote: > On Fri, Apr 22, 2016 at 2:38 PM, ron minnich <rminnich(a)gmail.com> wrote: > > Wait, I thought it had to be 4 characters. > > Yes. I cannot count. :/ CRBT > > > > ron > > > > On Fri, Apr 22, 2016 at 2:36 PM Aaron Durbin via coreboot > > <coreboot(a)coreboot.org> wrote: > >> > >> On Fri, Apr 22, 2016 at 2:00 PM, Duncan Laurie <dlaurie(a)chromium.org> > >> wrote: > >> > On Tue, Apr 19, 2016 at 6:49 AM, Aaron Durbin <adurbin(a)google.com> > >> > wrote: > >> >> > >> >> On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner < > jwerner(a)chromium.org> > >> >> wrote: > >> >> > I think we should only export the coreboot table location and size > >> >> > through ACPI and then read everything else from there. That way we > >> >> > can > >> >> > share almost all of the kernel driver code with ARM and just need a > >> >> > tiny platform-specific stub to look up the table location first. If > >> >> > we > >> >> > add all the information into an actual ACPI table, we're building > an > >> >> > x86-only solution again. (A generic, platform-independent coreboot > >> >> > driver could just as easily export the stuff we want into sysfs.) > >> >> > > >> >> > >> >> That's fine. The only thing I was concerned about was implementing an > >> >> ACPI table proper or try to do some ACPI device shenanigans like the > >> >> ramoops device. coreboot doesn't currently have a ACPI ID assigned to > >> >> it. If we go with a ACPI device coreboot should apply for an ACPI ID. > >> >> I personally think the coreboot ACPI table seems more straight > >> >> forward, but I was wondering if people knew of any downsides to going > >> >> that route. > >> >> > >> > > >> > > >> > The official tables are all defined in the ACPI spec while the related > >> > tables are also linked to from the spec, so we'd need to convince the > >> > UEFI > >> > forum to at least reserve the signature for us (and then link to our > >> > table > >> > definition) since they intend to act as gatekeepers to avoid > collisions > >> > in > >> > table signatures: > >> > > >> > "Requests to reserve a 4-byte alphanumeric table signature should be > >> > sent to > >> > the email address info(a)acpi.info and should include the purpose of > the > >> > table > >> > and reference URL to a document that describes the table format." > >> > > >> > An easier path would be to define a specific device in the DSDT and > >> > populate > >> > it with the various data we want to be there on every system. That > >> > would > >> > allow us to control the format and be able to alter it in the future > if > >> > we > >> > want to expose new information. > >> > > >> > As you note a Device would need a valid unique HID, and that needs an > ID > >> > prefix if it wants to be official. In theory we could request > something > >> > like "CORE" as an official APCI ID from > >> > http://www.uefi.org/PNP_ACPI_Registry > >> > >> OK. Time for bikeshedding: > >> > >> 1. CORE > >> 2. CBOOT > >> 3. ... ? > >> > >> Stefan, we'll likely need you to request the HID w/ your coreboot.org > >> email. > >> > >> > > >> > I suppose the real difference between the two is whether we need this > >> > data > >> > early in boot before there is an AML interpreter available in the OS. > >> > >> I don't think we need it that early. Right now the current usage (at > >> least on x86) is all very late since we're doing AML evaluation. We > >> could go w/ the ACPI device first. Just need to request that HID. > >> > >> > > >> > -duncan > >> > > >> > > >> > -- > >> > 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 specific ACPI table
by Aaron Durbin 22 Apr '16

22 Apr '16

On Fri, Apr 22, 2016 at 2:38 PM, ron minnich <rminnich(a)gmail.com> wrote: > Wait, I thought it had to be 4 characters. Yes. I cannot count. :/ CRBT > > ron > > On Fri, Apr 22, 2016 at 2:36 PM Aaron Durbin via coreboot > <coreboot(a)coreboot.org> wrote: >> >> On Fri, Apr 22, 2016 at 2:00 PM, Duncan Laurie <dlaurie(a)chromium.org> >> wrote: >> > On Tue, Apr 19, 2016 at 6:49 AM, Aaron Durbin <adurbin(a)google.com> >> > wrote: >> >> >> >> On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner <jwerner(a)chromium.org> >> >> wrote: >> >> > I think we should only export the coreboot table location and size >> >> > through ACPI and then read everything else from there. That way we >> >> > can >> >> > share almost all of the kernel driver code with ARM and just need a >> >> > tiny platform-specific stub to look up the table location first. If >> >> > we >> >> > add all the information into an actual ACPI table, we're building an >> >> > x86-only solution again. (A generic, platform-independent coreboot >> >> > driver could just as easily export the stuff we want into sysfs.) >> >> > >> >> >> >> That's fine. The only thing I was concerned about was implementing an >> >> ACPI table proper or try to do some ACPI device shenanigans like the >> >> ramoops device. coreboot doesn't currently have a ACPI ID assigned to >> >> it. If we go with a ACPI device coreboot should apply for an ACPI ID. >> >> I personally think the coreboot ACPI table seems more straight >> >> forward, but I was wondering if people knew of any downsides to going >> >> that route. >> >> >> > >> > >> > The official tables are all defined in the ACPI spec while the related >> > tables are also linked to from the spec, so we'd need to convince the >> > UEFI >> > forum to at least reserve the signature for us (and then link to our >> > table >> > definition) since they intend to act as gatekeepers to avoid collisions >> > in >> > table signatures: >> > >> > "Requests to reserve a 4-byte alphanumeric table signature should be >> > sent to >> > the email address info(a)acpi.info and should include the purpose of the >> > table >> > and reference URL to a document that describes the table format." >> > >> > An easier path would be to define a specific device in the DSDT and >> > populate >> > it with the various data we want to be there on every system. That >> > would >> > allow us to control the format and be able to alter it in the future if >> > we >> > want to expose new information. >> > >> > As you note a Device would need a valid unique HID, and that needs an ID >> > prefix if it wants to be official. In theory we could request something >> > like "CORE" as an official APCI ID from >> > http://www.uefi.org/PNP_ACPI_Registry >> >> OK. Time for bikeshedding: >> >> 1. CORE >> 2. CBOOT >> 3. ... ? >> >> Stefan, we'll likely need you to request the HID w/ your coreboot.org >> email. >> >> > >> > I suppose the real difference between the two is whether we need this >> > data >> > early in boot before there is an AML interpreter available in the OS. >> >> I don't think we need it that early. Right now the current usage (at >> least on x86) is all very late since we're doing AML evaluation. We >> could go w/ the ACPI device first. Just need to request that HID. >> >> > >> > -duncan >> > >> > >> > -- >> > 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 specific ACPI table
by ron minnich 22 Apr '16

22 Apr '16

Wait, I thought it had to be 4 characters. ron On Fri, Apr 22, 2016 at 2:36 PM Aaron Durbin via coreboot < coreboot(a)coreboot.org> wrote: > On Fri, Apr 22, 2016 at 2:00 PM, Duncan Laurie <dlaurie(a)chromium.org> > wrote: > > On Tue, Apr 19, 2016 at 6:49 AM, Aaron Durbin <adurbin(a)google.com> > wrote: > >> > >> On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner <jwerner(a)chromium.org> > >> wrote: > >> > I think we should only export the coreboot table location and size > >> > through ACPI and then read everything else from there. That way we can > >> > share almost all of the kernel driver code with ARM and just need a > >> > tiny platform-specific stub to look up the table location first. If we > >> > add all the information into an actual ACPI table, we're building an > >> > x86-only solution again. (A generic, platform-independent coreboot > >> > driver could just as easily export the stuff we want into sysfs.) > >> > > >> > >> That's fine. The only thing I was concerned about was implementing an > >> ACPI table proper or try to do some ACPI device shenanigans like the > >> ramoops device. coreboot doesn't currently have a ACPI ID assigned to > >> it. If we go with a ACPI device coreboot should apply for an ACPI ID. > >> I personally think the coreboot ACPI table seems more straight > >> forward, but I was wondering if people knew of any downsides to going > >> that route. > >> > > > > > > The official tables are all defined in the ACPI spec while the related > > tables are also linked to from the spec, so we'd need to convince the > UEFI > > forum to at least reserve the signature for us (and then link to our > table > > definition) since they intend to act as gatekeepers to avoid collisions > in > > table signatures: > > > > "Requests to reserve a 4-byte alphanumeric table signature should be > sent to > > the email address info(a)acpi.info and should include the purpose of the > table > > and reference URL to a document that describes the table format." > > > > An easier path would be to define a specific device in the DSDT and > populate > > it with the various data we want to be there on every system. That would > > allow us to control the format and be able to alter it in the future if > we > > want to expose new information. > > > > As you note a Device would need a valid unique HID, and that needs an ID > > prefix if it wants to be official. In theory we could request something > > like "CORE" as an official APCI ID from > > http://www.uefi.org/PNP_ACPI_Registry > > OK. Time for bikeshedding: > > 1. CORE > 2. CBOOT > 3. ... ? > > Stefan, we'll likely need you to request the HID w/ your coreboot.org > email. > > > > > I suppose the real difference between the two is whether we need this > data > > early in boot before there is an AML interpreter available in the OS. > > I don't think we need it that early. Right now the current usage (at > least on x86) is all very late since we're doing AML evaluation. We > could go w/ the ACPI device first. Just need to request that HID. > > > > > -duncan > > > > > > -- > > 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 specific ACPI table
by Aaron Durbin 22 Apr '16

22 Apr '16

On Fri, Apr 22, 2016 at 2:00 PM, Duncan Laurie <dlaurie(a)chromium.org> wrote: > On Tue, Apr 19, 2016 at 6:49 AM, Aaron Durbin <adurbin(a)google.com> wrote: >> >> On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner <jwerner(a)chromium.org> >> wrote: >> > I think we should only export the coreboot table location and size >> > through ACPI and then read everything else from there. That way we can >> > share almost all of the kernel driver code with ARM and just need a >> > tiny platform-specific stub to look up the table location first. If we >> > add all the information into an actual ACPI table, we're building an >> > x86-only solution again. (A generic, platform-independent coreboot >> > driver could just as easily export the stuff we want into sysfs.) >> > >> >> That's fine. The only thing I was concerned about was implementing an >> ACPI table proper or try to do some ACPI device shenanigans like the >> ramoops device. coreboot doesn't currently have a ACPI ID assigned to >> it. If we go with a ACPI device coreboot should apply for an ACPI ID. >> I personally think the coreboot ACPI table seems more straight >> forward, but I was wondering if people knew of any downsides to going >> that route. >> > > > The official tables are all defined in the ACPI spec while the related > tables are also linked to from the spec, so we'd need to convince the UEFI > forum to at least reserve the signature for us (and then link to our table > definition) since they intend to act as gatekeepers to avoid collisions in > table signatures: > > "Requests to reserve a 4-byte alphanumeric table signature should be sent to > the email address info(a)acpi.info and should include the purpose of the table > and reference URL to a document that describes the table format." > > An easier path would be to define a specific device in the DSDT and populate > it with the various data we want to be there on every system. That would > allow us to control the format and be able to alter it in the future if we > want to expose new information. > > As you note a Device would need a valid unique HID, and that needs an ID > prefix if it wants to be official. In theory we could request something > like "CORE" as an official APCI ID from > http://www.uefi.org/PNP_ACPI_Registry OK. Time for bikeshedding: 1. CORE 2. CBOOT 3. ... ? Stefan, we'll likely need you to request the HID w/ your coreboot.org email. > > I suppose the real difference between the two is whether we need this data > early in boot before there is an AML interpreter available in the OS. I don't think we need it that early. Right now the current usage (at least on x86) is all very late since we're doing AML evaluation. We could go w/ the ACPI device first. Just need to request that HID. > > -duncan > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] coreboot specific ACPI table
by Duncan Laurie 22 Apr '16

22 Apr '16

On Tue, Apr 19, 2016 at 6:49 AM, Aaron Durbin <adurbin(a)google.com> wrote: > On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner <jwerner(a)chromium.org> > wrote: > > I think we should only export the coreboot table location and size > > through ACPI and then read everything else from there. That way we can > > share almost all of the kernel driver code with ARM and just need a > > tiny platform-specific stub to look up the table location first. If we > > add all the information into an actual ACPI table, we're building an > > x86-only solution again. (A generic, platform-independent coreboot > > driver could just as easily export the stuff we want into sysfs.) > > > > That's fine. The only thing I was concerned about was implementing an > ACPI table proper or try to do some ACPI device shenanigans like the > ramoops device. coreboot doesn't currently have a ACPI ID assigned to > it. If we go with a ACPI device coreboot should apply for an ACPI ID. > I personally think the coreboot ACPI table seems more straight > forward, but I was wondering if people knew of any downsides to going > that route. > > The official tables are all defined in the ACPI spec while the related tables are also linked to from the spec, so we'd need to convince the UEFI forum to at least reserve the signature for us (and then link to our table definition) since they intend to act as gatekeepers to avoid collisions in table signatures: "Requests to reserve a 4-byte alphanumeric table signature should be sent to the email address info(a)acpi.info and should include the purpose of the table and reference URL to a document that describes the table format." An easier path would be to define a specific device in the DSDT and populate it with the various data we want to be there on every system. That would allow us to control the format and be able to alter it in the future if we want to expose new information. As you note a Device would need a valid unique HID, and that needs an ID prefix if it wants to be official. In theory we could request something like "CORE" as an official APCI ID from http://www.uefi.org/PNP_ACPI_Registry I suppose the real difference between the two is whether we need this data early in boot before there is an AML interpreter available in the OS. -duncan

1 0

Re: [coreboot] coreboot 4.4 release coming soon
by Alexander Couzens 20 Apr '16

20 Apr '16

Lenovo: - t400 - tested by CaptainCoward - boot - x201 - broken - doesn't boot - x220 - works @Martin: Can you create a rc1 tag for this? Everybody would against test the same revision. -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu mobile: +4915123277221 gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2016