coreboot

coreboot@coreboot.org

6 participants
39687 discussions

Coreboot : Change/modify Boot maintenance manager for auto boot support.
by Putsala Amar 21 Apr '22

21 Apr '22

Hi, We are working on intel c508 intel denverton board. We have programmed coreboot image in 16MB NOR flash. After the coreboot hw initialization , it moves to payload stage by default it is entering to "boot maintenance manager" . We expect the node to boot without getting into boot manager(without waiting for any key) . Made below experiment which i found in BIOS : Change/Modify Auto Boot Time-out option as "0" in "Boot Maintenance manager". but this timeout parameter is not allow to commit/save the new changes. As per the Auto Boot Time-out description : Range: 0 means no wait , 65535 means waiting for Key. By default timeout hold 65535. Thanks in advance.., Thanks & Regards, Amar Putsala ( ID : 2353 ) 4th Floor , Cubical : 4058 J.P. Software Park, Electronic City Phase-1, Hosur Road, 560100 Ext. No: 8110

3 3

RFC: Clarifying use of GCC extensions in the coding style
by Julius Werner 18 Apr '22

18 Apr '22

Hi, We occasionally get into discussions in code reviews when code uses a GCC extension, and a reviewer asks that it be rewritten to be C standard compliant instead. A recent example was on the use of `void *` arithmetic in this patch https://review.coreboot.org/c/coreboot/+/56791/9/src/soc/mediatek/common/pc… , and there have been others in the past. I would like to come to a consensus on this topic here and add some blurb to the coding style document so we don't have to rehash the same discussion over and over again. In my opinion, GCC extensions are absolutely necessary for coreboot development and there should be no reason to reject them. Inline assembly is the most obvious example -- without it we would have to convert a ton of static inline functions that wrap special instructions into full linker-level functions in a separate assembly file instead, and eat all the unnecessary function call overhead that comes with that. Others enable such important features that it would become much more dangerous and cumbersome to develop without them -- most importantly statement expressions (https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Statement-Exprs.html) which are necessary to write things like double-evaluation safe macros, expression-assertions like dead_code_t() and simple convenience shortcuts like wait_us(). And some extensions just offer a small bit of convenience to reduce boilerplate -- for example, `void *` arithmetic just tends to be useful to prevent cluttering the code with a bunch of unnecessary casts to other types that don't add any additional meaning to the data (e.g. for an unspecified buffer of opaque data I think `void *` is a much more appropriate type than `uint8_t *`, even if I want to add a byte offset to it), and I've never seen a case where I think it would have actually been unclear to anyone what step width the pointer arithmetic was done at (there's no reason to assume anything other than bytewise for a `void *`). If we need some extensions anyway, and coreboot will never be "fully C standards compliant" (not that that would actually be very useful for anything in practice), I don't see a reason why we should still avoid some extensions when we're using others. I think if an (official, long-term supported) extension exists and it allows us to write better code than standard C, there should be no reason not to use it. (Note that for those people who are trying to get coreboot working with clang, it generally supports all the same extensions as GCC.) I've written a draft CL to add a section for this to the coding style, please let me know what you think: https://review.coreboot.org/c/coreboot/+/63660

2 1

lb_serial: drop 'uart_pci_addr' entry
by Arthur Heymans 17 Apr '22

17 Apr '22

Hi In 2016 'uart_pci_addr' was added to the coreboot table entry for serial devices. (https://review.coreboot.org/c/coreboot/+/14609) It was done for the Intel Quark platform which has its uart on a PCI device like other Intel hardware. Right now only Quark sets this to a non zero value using an awkwardly defined Kconfig parameter: CONFIG_UART_PCI_ADDR. It looks like only tianocore uses this and it's pretty much a NOOP used only to get the VID/DID of the PCI device. Should we update tianocore and just drop this for the lb_table? Most other payloads don't even have this struct entry updated to contain this entry... Now our codebase has awkward code with "serial.uart_pci_addr = CONFIG_UART_PCI_ADDR;" on a lot of platforms that don't even feature PCI and there is no real use case as far as I can tell. Do any of your payloads use this in a meaningful way? If not, can we just drop it? Kind regards Arthur

2 2

review.coreboot.org 's wget is working unreliable today
by Mike Banon 17 Apr '22

17 Apr '22

Downloading the patches by wget from review.coreboot.org - really often results in these errors today. my Internet connection is OK and I'm able to load review.coreboot.org at the same time with a browser. --2022-04-17 **:**:**-- https://review.coreboot.org/changes/58748/revisions/1/patch?zip Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt' Resolving review.coreboot.org (review.coreboot.org)... 78.46.105.101, 2a01:4f8:121:1254::2 Connecting to review.coreboot.org (review.coreboot.org)|78.46.105.101|:443... failed: Connection timed out. Connecting to review.coreboot.org (review.coreboot.org)|2a01:4f8:121:1254::2|:443... failed: Network is unreachable. WARNING: can't download a ./patch?zip file ! Please check your Internet connection and try again. press [ENTER] to continue... -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 0

Re: Deprecation of the Intel Quark SoC
by Martin Roth 14 Apr '22

14 Apr '22

Apr 14, 2022, 14:06 by 0xloem(a)gmail.com: > Hi Martin, > >> I think we all agree that it'd be good to have test racks that have all of the boards in the coreboot repository for verification, however that's currently not practical with the resources we have. The whole thing just isn't a simple problem to solve. >> > > Often the biggest impediment to something like this is simply holding it as a shared goal, and continuing to do so when issues arise. > > If public test labs were desired, a callout for donations of space and hardware could be placed on the main page. If somebody had the capacity to do more than that, then local makerspaces and hackerspaces could be reached out to. > It's a good point. Maybe we can put up a webpage with how an individual can help the coreboot project. Put up a list of boards to be adopted for testing and how to find which commit broke them if they're broken. >> I'm actually also not completely convinced that just testing the boards is the solution to whether or not we keep a board/chip on the mastre branch. If there really aren't any people using coreboot on their quark boards, then personally, I don't see any need to keep it in the master branch. I know others feel differently, but as I said earlier in this thread, I don't think there's actually any harm in moving an aging or little-used platform to be maintained on a branch. >> > > Sounds like there is a difference of opinion in the community. > Always. ;-) > It seems obvious to me that there would be people using coreboot on their quark boards. The world is gigantic. > > But you have a different opinion, which is fine. > > It seems to me the reason to include a board is because people care about doing so. > Agreed. Currently we have no way of knowing whether or not anyone cares about a board. There are two ways people typically make it known - by working on a board or by testing a board. > I care enough about including boards that I'd test this one if it was needed to do so to retain it. But I'm just a visitor. And it seems more productive to discuss public test labs that could grow to support more boards. > Sure, and I'm not trying to advocate that we remove anything. Mostly right now I'm trying to figure out how we should decide when things should or should not be moved to a branch to make it easier going forward. Take care Martin

2 2

libpayload CBFS API deprecation; please port payloads to new API
by Julius Werner 14 Apr '22

14 Apr '22

The libpayload CBFS stack ("libcbfs") has recently been rewritten from scratch in order to eliminate a bunch of very old warts and better match the new CBFS API in coreboot (https://review.coreboot.org/59497). For the time being, the old libcbfs code remains side-by-side to the new one so that the old API functions still work for existing payloads. However, we would like to remove this code eventually as it still presents a maintenance burden. All payloads that use the CBFS API in libpayload should please upgrade to the new API. Among the payloads hooked up to the coreboot build system, I think this only affects depthcharge (we already ported that one), BOOTBOOT and FILO. See https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/pa… for available interfaces (they match the coreboot API which is documented in more detail in https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/sr…). If you have a use case that cannot be implemented with this interface please let me know. If there are no objections I'd suggest that we target the official deprecation and removal of the old API for the release after next, i.e. 4.18 around the end of this year.

2 1

Fwd: Refactoring duplicate Embedded Controller code
by Ivan Ivanov 13 Apr '22

13 Apr '22

G505S has KB9012 chip on board, I can guarantee this. However, maybe KB9012 is a bit similar to the older chips, and just the internal 128KB memory and some features got added. If you'd look at KB9012 dataset available online, I think it had a comparison table of KB9012 vs some older chip. Hope this helps! пт, 8 апр. 2022 г., 16:46 Abel Briggs <abelbriggs1(a)hotmail.com>: > Yes, I was looking at the G505S and its EC when considering these patches. > > The situation with the EC in the G505S seems a bit odd. The EC is named > `ene932`, but there are several commits in the codebase which reference the > chip as a KB9012. The KB9012 datasheet, however, reference the ENE930 > series chips as the predecessor chip to the KB9010 series. > > The S230U has a KB9012 and the Compal firmware seems to have a similar > `OperationRegion` layout to the firmware in the `ene932`, but the EC query > values are completely different. The S230U basically defines its own EC in > its mainboard tree and only uses the `ene932` code for its helper I/O space > functions. > > If anyone has a G505S or its vendor documentation to check that the chip > on the board is really an ENE930 series, I think that would help clear this > up. > > This is something I was considering trying to refactor as well, by giving > the S230U its own `ec/` common code. However, I would probably throw that > patch in with my mainboard's patchset (Lenovo Edge E530), since otherwise > the S230U would be the only user of that code. > > ------------------------------ > *From:* Ivan Ivanov <qmastery16(a)gmail.com> > *Sent:* Friday, April 8, 2022, 4:38 AM > *To:* Abel Briggs <abelbriggs1(a)hotmail.com> > *Cc:* coreboot(a)coreboot.org <coreboot(a)coreboot.org> > *Subject:* Re: [coreboot] Refactoring duplicate Embedded Controller code > > If this could help you, coreboot-supported Lenovo G505S also has EC KB9012 > > чт, 7 апр. 2022 г. в 06:44, Abel Briggs <abelbriggs1(a)hotmail.com>: > > > > Hello, > > > > I was looking at the code and ACPI for a number of different embedded > > controllers while adding support for a Lenovo mainboard. > > The mainboard in question has an EC nearly identical to the Twist S230U > > (Compal KB9012), so I planned to factor out the S230U's EC code/ACPI > > into its own chip. > > > > While doing this, I noticed there were several duplicate functions > > across the `ec/` directory, so I'd like to potentially submit some > > patches to clean them up. However, I'm not sure of the best way to > > go about this. > > > > The following is what I currently have in mind: > > > > - Removing most individual `ec_write_cmd()` > > and similar functions andreplacing calls with their respective > `ec/acpi/ec.c` library functions > > - Removing individual `kbc_` polling functions and sharing the ones > defined > > in `drivers/pc80/keyboard.c` > > - Should public library functions for sending and receiving data from > > a PC80 keyboard controller be defined in the PC80 driver and exported > > in `include/pc80/keyboard.h`? > > - We already have `send_keyboard()` there, > > which sends a command and receives data - would it be good to add > > individual functions for those operations as well? > > > > Any suggestions or recommendations would be appreciated. I looked for > > guidelines on suggested code organization in the docs/commit history/ > > mailing list, but came up mostly empty-handed. > > > > Thanks! > > > > _______________________________________________ > > coreboot mailing list -- coreboot(a)coreboot.org > > To unsubscribe send an email to coreboot-leave(a)coreboot.org > >

1 0

regarding support for W25Q256JW (0x6019)
by ritul guru 12 Apr '22

12 Apr '22

Hi, I am looking for info to add WINBOND SPI FLASH part W25Q256JW (0x6019). tried adding below entry in winbond.c, is there any other changes required to enable this part to boot from? { /* W25Q256JW */ .id[0] = 0x6019, .nr_sectors_shift = 13, .fast_read_dual_output_support = 1, .fast_read_dual_io_support = 1, .protection_granularity_shift = 16, .bp_bits = 4, }, *Thanks & RegardsRitul Guru+91-9916513186*

1 0

[Issue Tracker] Security notification
by Issue Tracker 12 Apr '22

12 Apr '22

Email coreboot(a)coreboot.org was removed. https://ticket.coreboot.org/my/account User: flx IP address: 185.104.142.213 Date: 04/12/2022 12:55 AM -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

[coreboot][GSoC] idea for a proposal project porting to a Thinkpad AMD Ryzen 3rd gen machine
by Lahfa Samy 10 Apr '22

10 Apr '22

Hi all Coreboot folks, I'm a first year graduate student in CS, been hanging around on #coreboot IRC (Libera.Chat server) and was thinking if it was possible or not to port Coreboot to a Thinkpad T495 (AMD Ryzen 7 3700U PRO) [1] manufactured in May 2019, I successfully dumped the BIOS using flashrom internally, see `flashrom_info.log` and 'flashrom_info.err.log`. It is unclear if there is any AMD protection that does the same as Intel BootGuard on Ryzen 3rd gen (there is for sure this [2] since the 1st gen of Ryzen which is the equivalent to Intel Management Engine). AMD has a whitepaper stating that from Ryzen 5000s mobile generation [3], AMD PSB (Platform Secure Boot) is activated, and it looks like kind of the same as Intel BootGuard if I'm not mistaken here. I know so far that the BIOS SPI chip is operating at 1.8v, and is a Winbond flash chip "W25Q128.W" (16384 kB, SPI), will be useful in case I need to externally flash the SPI ROM to unbrick the laptop. I still have to : - Test whether there is a protection that checks if the firmware was changed or not by patching the original bios ROM, I was told for this to change a copyright string or changing the logo : - it is a gif file and has a sha2-256 signature in its properties, which isn't the sha256sum of the file. - I've attached the `identify -verbose logo.gif` output) and trying to boot could allow checking for any tamper protection on the ROM flash (bricking intentionally the device if there is). - Understand if the EC RAM is something I can make out of or not (so far there is a lot of FF and 00 in it, the last line shows the version of the embedded firmware), so far I'm not too sure I can make sense of it right now. - Get the model of the EC and try to find datasheets online. I have at my disposal: - A kind of cheap 16 channel logic analyzer [4] with a software available on Linux/Windows with a few decoders for most known serial protocols such as SMBUS, I2C, SPI and more. - Raspberry Pi 3 model B+ (will be used as an external programmer, but I still need to find out how I could pull down the power to 1.8v since the VCC is 3.3v). - SOIC clip 8 pins (will be delivered to me in 2 weeks), I took the best one from this guide [5]. - A cheap multimeter with basic probes, capable of continuity test. And possibly more such as FPGAs by going to hackerspaces in my vicinity. I have built Coreboot for qemu with the Seabios payload as the documentation for GSoC recommended, see coreboot-serial.log output attached as a text file. In the case where there is indeed a protection, maybe a solution could be found by using a flash emulator (spispy ?) [6] but I need more details on this. I am also aware that a complete port will not be feasible under the time period of GSoC hence I need to know what should be the basics that needs to be covered for a Coreboot port to be considered minimally working first ? USB should work ? Charging is made using a USB-C port, this might be partly handled by the EC Embedded Controller. Finally, if nothing could be done on this Thinkpad because it is too recent, I also have an older Intel Thinkpad a T450, that has Intel BootGuard but that I'm looking try to port Coreboot to it too, using a flash emulator and possibly this attack [7]. Thanks for the time taken to read this lengthy mail, I hope the goal of this mail is clear. Kind regards, Lahfa Samy Links: ------ [1] https://psref.lenovo.com/syspool/Sys/PDF/ThinkPad/ThinkPad_T495/ThinkPad_T4… [2] https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor [3] https://www.amd.com/system/files/documents/amd-security-white-paper.pdf [4] https://sigrok.org/wiki/Kingst_LA2016 [5] http://dangerousprototypes.com/docs/Flashing_a_BIOS_chip_with_Bus_Pirate [6] https://github.com/osresearch/spispy [7] https://trmm.net/Sleep_attack/

2 2

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