coreboot

coreboot@coreboot.org

17 participants
39654 discussions

make menuconfig - is broken after commit 7eab8ef (Linux 6.2's kconfig) and follow-ups
by Mike Banon 26 Nov '23

26 Nov '23

Dear friends, I just encountered a menuconfig problem on a fresh coreboot. Steps to reproduce: 1) Testing environment - fully updated Artix Linux (arch w/o systemd): 6.5.11 linux kernel etc. 2) At the freshly cloned coreboot directory (+ submodules checkout'ed), git reset --hard 7eab8ef and then make menuconfig - will cause these errors: /usr/bin/ld: build/util/kconfig/lxdialog/yesno.o: warning: relocation against `acs_map' in read-only section `.text' /usr/bin/ld: build/util/kconfig/mconf.o: in function `show_help': mconf.c:(.text+0x1770): undefined reference to `stdscr' /usr/bin/ld: mconf.c:(.text+0x177c): undefined reference to `stdscr' /usr/bin/ld: build/util/kconfig/lxdialog/checklist.o: in function `print_item': checklist.c:(.text+0x82): undefined reference to `wattrset' /usr/bin/ld: checklist.c:(.text+0x98): undefined reference to `wmove' /usr/bin/ld: checklist.c:(.text+0xb2): undefined reference to `waddch' /usr/bin/ld: checklist.c:(.text+0xd8): undefined reference to `wmove' /usr/bin/ld: checklist.c:(.text+0xfe): undefined reference to `wattrset' 3) One commit before - 7f93aa4 - the things worked OK Curious, if anyone else has the same error? Please take a look at this -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

3 3

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 24 Nov '23

24 Nov '23

Dear Community, We are happy to announce that the upcoming coreboot leadership meeting is scheduled for November 29, 2023. [1] Kindly update the current agenda items with things you wish to see addressed during the meeting.[2] [1] https://coreboot.org/calendar.html (https://coreboot.org/calendar.html) [2] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK… (https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…) j6ljr2742djc

1 0

Fwd: Re: Makefile indentation for conditionals
by Maximilian Brune 23 Nov '23

23 Nov '23

---------- Forwarded message --------- Von: Maximilian Brune <maximilian.brune(a)9elements.com> Date: Do., 23. Nov. 2023 um 23:13 Uhr Subject: Re: [coreboot] Re: Makefile indentation for conditionals To: Felix Held <felix-coreboot(a)felixheld.de> Could you please show the world a simple example of what you mean? It > would certainly help everyone understand your proposal. > https://review.coreboot.org/c/coreboot/+/79230 Am Do., 23. Nov. 2023 um 21:29 Uhr schrieb Felix Held < felix-coreboot(a)felixheld.de>: > On 23/11/2023 20:50, Martin Roth via coreboot wrote: > > If we do go this route for indentation, could we standardize on either > > 2-space 4-space indentation per level? The Makefile lines are long > > enough without indentation. > > I was initially thinking of 4 or 8 spaces vs tabs which isn't > necessarily easy to visually differentiate, so I didn't like the idea > too much. A 2 spaces indentation might be much better and something to > look into; at least that's sufficiently visually different from the tabs > for any usual tab size to not mix those up. > > Regards, > Felix > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

1 0

Makefile indentation for conditionals
by Maximilian Brune 23 Nov '23

23 Nov '23

Hi Reading Makefiles especially in big projects like coreboot is a constant. pain. One of the big issues is that conditionals are very hard to read since we cannot use tabs for indentation. Has anyone ever thought about using whitespaces as indentation for conditionals in our Makefiles or is that connected to known problems? greetings Max

6 6

bay area firmware meetup dec. 4
by ron minnich 23 Nov '23

23 Nov '23

https://www.eventbrite.com/e/bay-area-firmware-meetup-tickets-759502210557?… Thanks to Binal for setting all this up ...

1 0

Programming BIOS with Flash Programming Tool from UEFI shell
by Moorthi M.s 23 Nov '23

23 Nov '23

Hi, I am developing coreboot along with Uefipayload for a custom board derived from CFL H RVP11 CRB. Modifications are done as per the custom board and the board was booted and working fine. I tried to reprogram the BIOS flash with FPT (Flash Programming Tool) from UEFI shell throws the below error and the operation failed. "Error 167: Protected Range Registers are currently set by BIOS, preventing flash access". What are the configurations need to be done in coreboot to allow program BIOS image with the FPT tool from UEFI shell? Thanks & Regards, Moorthi S

2 4

Re: RFC on coreboot forms representation
by Martin Roth 21 Nov '23

21 Nov '23

Since this is for a setup engine, I'd think we'd want multi-language support as well. That's going to be difficult to handle if we try to generate all the strings at runtime. I think that support needs to be fundamental to the design. Martin Nov 1, 2023 at 13:54 by coreboot(a)coreboot.org: > Hi Patrick, I put a bunch of comments into the reviews, but I thought I'd reply directly on the mailing list as well for anyone who isn't looking at the patches. > > > We discussed this at today's leadership meeting where I actually brought up the patches and discussed some of the things I'd seen. > > I may not completely understand the intentions here, and I'd like to understand the requirements that led to this solution. > > > Really, I have 3 main objections: > > 1) The name - “Forms Representation” may be the single most UEFI phrase I've ever read. Use "Config Option Data", "Option Data Structures", "Menu Option Data", anything other than "Forms Representation". Is that maybe a mechanical translation from a different language, or does someone actually talk that way? > > 2) As I said, I don't understand your requirements, but this seems hugely more complex than it needs to be. I also think this entire structure should be generated at build time and not runtime. My personal opinion is that the default for any item shouldn't be something read from EC, SPI, wherever at runtime. Instead it should be a flag that says to update the (non-default) setting from someplace at runtime. > > 3) It should be to populate and modify the menus from any different level in the coreboot hierarchy - Arch, SoC, (Vendor), Mainboard. Right now, the menus seem to be very hardcoded, without a good way to insert items from any other place in the tree other than where the menu is created. > > > I guess I'd prefer to have something more like how Kconfig or devicetree work, taking text files from all of the different levels in coreboot, combining them into a tree, then generating the structures from that. > > Unfortunately, Items 2 and 3 are completely different from your proposal, and would require a complete rewrite. Sorry about that. > > Maybe we can set up a meeting time to discuss things between 9E and interested parties in the coreboot community? > > Take care. > Martin > > > Oct 31, 2023, 10:45 by patrick.rudolph(a)9elements.com: > >> Hello coreboot folks, >> At the time of writing coreboot is lacking good firmware menus or >> user-space applications to change options consumed by coreboot. While >> there's support for changing CMOS options in SeaBIOS or from within >> Linux on some x86 mainboards it's quite limited in user friendliness. >> While CMOS was a great thing some decades ago, it cannot compete with >> today's flash based non-volatile option store, like UEFI variables, >> SMMSTORE or VPD. >> >> Our best engineers at 9elements came up with a possible solution: >> coreboot forms representation, see [1], [2], [3] >> CFR allows to have nice firmware menus in coreboot payloads as done in >> example for tianocore/EDK2 [5]. While it was designed with EDK2 in >> mind it's possible to use it on any payload with any variable store >> back-end (UEFI, SMMSTORE, VPD, CMOS, ...), as it's really about >> providing meta data about the options, not how to actually store it's >> value in a non-volatile fashion. The coreboot forms representation is >> provided to a payload in a new coreboot table and is generated at >> runtime by using C-style lookup tables, but in order to reduce code >> duplicates can be defined in common code as done in [4]. >> >> Please review and give feedback. >> Regards, >> Patrick >> >> 1: https://review.coreboot.org/c/coreboot/+/77882/ >> 2: https://review.coreboot.org/c/coreboot/+/74121/ >> 3: https://review.coreboot.org/c/coreboot/+/78506/ >> 4: https://review.coreboot.org/c/coreboot/+/78296/ >> 5: https://github.com/9elements/edk2/commit/f34f17996444ef811cc0223b4f875c45da… >> _______________________________________________ >> coreboot mailing list -- coreboot(a)coreboot.org >> To unsubscribe send an email to coreboot-leave(a)coreboot.org >> > > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

4 3

Re: RFC on coreboot forms representation
by Martin Roth 21 Nov '23

21 Nov '23

Hi Angel, Thanks for the response, and for all the work that's been done. I do appreciate what went into your patches. I wish that it had been discussed more widely before you'd completed it though. This is always going to be an issue of doing something in private with the hope that coreboot will just accept what's been done. Of course, maybe the other way doesn't work well either. When I wrote up a proposal for postcodes, I was told to just implement it and then I could get feedback. I guess I don't know what the best way is. The rest of my responses are inline. I'd still like to have a public meeting as I mentioned in my last email to see what we can work out regarding this issue. Take care, Martin Nov 16, 2023, 09:29 by th3fanbus(a)gmail.com: > Hi all, > > I am writing things down as I think them, so I am sure this email will > most likely turn out to be a hailstorm of scatterbrained ideas. Brace > yourselves, here comes a wall o'text... > > CFR is part of a very ambitious idea I came up several months ago to > solve a specific problem with a general-purpose solution: > > - Specific problem: one of 9elements' customers wants a "UEFI setup > menu" equivalent on a COMe module with coreboot+edk2, options' > visibility and default value depend on runtime-only data > - General-purpose solution: payload-independent data structures in > cbtables (or somewhere else, if needed) that describe which options > coreboot supports > Sure, having way to support a setup engine seems totally reasonable. I like the idea. > About the CFR (coreboot forms representation / cursed forms > representation) name: I needed to name the folder in which I put the > code I was writing. And because I was looking at UEFI stuff for > inspiration when writing the code, the names of IFR (Internal Forms > Representation) and VFR (Visual Forms Representation) were fresh in my > brain-cache and influenced my decision... Even though CFR is separate > from UEFI (although it borrows some names), if the CFR name is > unnaceptably UEFI-sounding, I don't mind renaming the thing to > something else as long as it's short and not easily confused with a > different thing (something like "option table" wouldn't be great > because it can be confused with the existing CMOS option table > subsystem)... > > Hmmm, maybe keep the CFR acronym but redefine it as "Configure > Firmware at Runtime"? [This should address Martin's 1st objection.] > Why would we want to keep the CFR acronym and try to fit names to it? Is there something special about CFR? What you're proposing here is data to be consumed by a setup engine. This actually doesn't have very much to do with the firmware configuration, as that would be the back-end that this proposal doesn't actually address (though I think that could be a problem). > With additional support for CMOS indexing, CFR could replace original > CMOS option records in cbtables. However, boards like asus/p2b already > struggle with flash chip space and would not benefit from using CFR > anyway. What seems doable, however, is to generate both the > cmos.{default,layout} files as well as the pre-CFR input data (the > structures with the `sm_` prefix) from a single source of data > (replacing the cmos.{default,layout} files, which would have been the > source of data until then). > Sure, having a single format that supports any and all option back-ends sounds good to me too. How would you propose to actually support that if there's no back-end information in any of this data? It seems like there's going to need to be some sort of method associated with this to tell where the data for each setting is going to be stored, at least for *some* back-ends, even if it's not needed for your current issue. > As Nico pointed out, most of the proposed code is about serialization, > and is the result of "build to think" design thinking: it's much > easier to notice shortcomings and other issues of a design when one > has a working example to play with. Furthermore, the serialization > needs to happen *somewhere*, no matter where the data to serialize > comes from. However, I am fully aware that having to write option > descriptors directly as C code is outright painful; a proper solution > pretty much requires using a domain-specific language to generate the > data to be serialized (not unlike SCONFIG and devicetrees, for > instance). > > Regarding the domain-specific language for the runtime-configurable > options, my first thought was to use the devicetree. With chipset > devicetrees, this would solve a major pain point that CMOS layouts > have: redundancy. Every board needs to repeat option declarations and > enumerations for chipset options, the only difference being the offset > of the option in CMOS space (size should be the same no matter what). > With runtime options in the devicetree, chipsets would describe the > options and mainboards would "use" them as needed. There are options > like `gfx_uma_size` (on Intel platforms, the amount of RAM reserved > for the iGPU) that only matter in certain situations (e.g. > `gfx_uma_size` does nothing when the iGPU is disabled); one could use > devicetree information to show/hide these options as needed. One could > even add a new device operation so that each device fills in CFR with > its options. [This should address Martin's 3rd objection.] > One issue is that I'm not interested in just showing/hiding data as needed. For example, I don't want intel specific stuff to be present on AMD or ARM platforms, but hidden - that's a waste of space. We need to be able to customize what actually goes into the menu data and exclude pieces that aren't needed. I'd look more to Kconfig than to devicetree for setting up a menu since that is, after all, what Kconfig does. I think we could probably use a DSL very similar to Kconfig to support everything that's needed here. > Even when only considering the specific problem (see above), > generating CFR structures at build-time is out of the question: > knowing which options are visible and what their default value should > be is only possible after reading a "profile code" value from an > EC-attached EEPROM. We already generate more complex structures at > runtime (ACPI SSDTs, SMBIOS...) anyway. That being said, it is true > that simpler use-cases (e.g. a regular desktop board, without custom > shenanigans) could be made to work with build-time generated CFR > structures, although conditional options would require patching the > CFR structures manually or something else... [This should address > Martin's 2nd objection.] > I have to disagree that generating the *structures* at build-time are out of the question. Maybe some of the data needs to be updated, but you can pull the data from the EC-attached EEPROM in your mainboard code, and update whatever fields need to be updated after copying things to CBMEM. You can even update the menu data directly in CBFS. That isn't something that every coreboot platform (or even most) will need to do. Please don't force a solution required for your single customized platform onto the entirety of coreboot. A mainboard-specific solution to the issue of reading the data and populating it where it needs to go seems totally reasonable to me. Am I missing something? > About default values in CFR: they actually have a dual purpose. For > regular options, they allow the user to reset options to their default > value from the setup menu. For "volatile" options (i.e. options which > are read-only and are not stored in the backend), the default value is > the value of the option. These "volatile" options are used to pass > data to the payload, e.g. serial numbers or the aforementioned profile > code. This is convenient when using edk2 as payload, as the CFR > deserializer outputs variables which can be accessed from anywhere. > Note: edk2 deserializes the CFR structures into variables on every > boot, but these variables are only displayed visually when entering > the setup menu (Boot Manager). > So if you set a value of "Default" in the setup engine, and read the value in from the EEPROM on the next boot, does that not meet your requirement? I mean, that's what you're already proposing, though in the reverse order. You're reading the default value on *every* boot just in case it's needed by the setup engine. That seems wasteful to me. > Regarding enums being defined separately to allow for reuse, I like > the idea. Why didn't I think of it before? It can also be useful for > boolean options, which do not define any names for true/false (if > memory serves right, edk2 code assumes `false ---> Disabled` and `true > ---> Enabled`) and could benefit from having more specific wording in > certain cases. It's true that one would have to resolve the enum > indices on the deserializer side, but it shouldn't be too bad (the > dependency/callback mechanism is likely more complicated, need to > catch up with that part). [This should address Nico's comment about > CMOS enums being more flexible.] > > Regarding multi-language support, I haven't thought too much about > it... Well, until now. To avoid repeating things, we could have a > `translations` folder at the root of the coreboot repo containing one > text file for each language. These files would need to use an encoding > (UTF-8 maybe?) that works well with non-English languages. There would > be some sort of "translation key" for each localized message, maybe a > numeric ID or a descriptive string (e.g. > `enums.power_on_after_fail.keep`). The option descriptors (e.g. stuff > in the devicetree) would reference these "translation keys" > accordingly. Then, the build-time "option processor" (if the options > are part of the devicetree, then SCONFIG; else, a similar kind of > program) would collect a list of all the needed "translation keys" for > this image, and a separate program would take said list and generate a > "string table" for each enabled language (behavior when translation > incomplete TBD). These "string tables" would be in binary form, stored > in CBFS (compressed), and coreboot would place them in cbtables at > runtime. The payload (or whoever displays the options to the user) > would pick the desired "string table" from cbtables and use it to > display the localized options. The post-build "translation keys" can > be numbers instead of variable-length strings for space efficiency > reasons. > > But we should first decide on which functionality we want to cover > regarding i18n (internationalization). The above contemplates > multi-language support with on-the-fly switching with no access to > CBFS, which is the most extreme case. If accessing files from CBFS > directly is possible, then it's not necessary to bloat cbtables with > strings. If on-the-fly switching isn't necessary (changes take effect > next boot), then coreboot only needs to place one "string table" into > cbtables. If run-time language switching isn't necessary (language is > chosen at build time), the "string table" in CBFS can be removed, and > the build-time tools would instead place the localized strings in the > to-be-compiled code. > I absolutely agree that we need to decide what we want first - that's what I think we're trying to do here. I'm not even pushing to include internationalization into the initial configuration, just saying that it's something we're probably going to want at some point, and we need to look at how we would support it when we need it. I think it'd be better to have the setup engine support decompressing the language tables from CBFS, but I'd be fine if the setup engine required a reboot to change languages if needed. It's not like people are typically going to be switching them a lot. > I *think* I've addressed most questions, but I feel I've still missed > something. If so, please remind me.with > > Best regards, > Angel > > On Sat, Nov 11, 2023 at 3:09 AM Martin Roth via coreboot > <coreboot(a)coreboot.org> wrote: > >> >> >> Since this is for a setup engine, I'd think we'd want multi-language support as well. That's going to be difficult to handle if we try to generate all the strings at runtime. I think that support needs to be fundamental to the design. >> >> Martin >> >> Nov 1, 2023 at 13:54 by coreboot(a)coreboot.org: >> >> > Hi Patrick, I put a bunch of comments into the reviews, but I thought I'd reply directly on the mailing list as well for anyone who isn't looking at the patches. >> > >> > >> > We discussed this at today's leadership meeting where I actually brought up the patches and discussed some of the things I'd seen. >> > >> > I may not completely understand the intentions here, and I'd like to understand the requirements that led to this solution. >> > >> > >> > Really, I have 3 main objections: >> > >> > 1) The name - “Forms Representation” may be the single most UEFI phrase I've ever read. Use "Config Option Data", "Option Data Structures", "Menu Option Data", anything other than "Forms Representation". Is that maybe a mechanical translation from a different language, or does someone actually talk that way? >> > >> > 2) As I said, I don't understand your requirements, but this seems hugely more complex than it needs to be. I also think this entire structure should be generated at build time and not runtime. My personal opinion is that the default for any item shouldn't be something read from EC, SPI, wherever at runtime. Instead it should be a flag that says to update the (non-default) setting from someplace at runtime. >> > >> > 3) It should be to populate and modify the menus from any different level in the coreboot hierarchy - Arch, SoC, (Vendor), Mainboard. Right now, the menus seem to be very hardcoded, without a good way to insert items from any other place in the tree other than where the menu is created. >> > >> > >> > I guess I'd prefer to have something more like how Kconfig or devicetree work, taking text files from all of the different levels in coreboot, combining them into a tree, then generating the structures from that. >> > >> > Unfortunately, Items 2 and 3 are completely different from your proposal, and would require a complete rewrite. Sorry about that. >> > >> > Maybe we can set up a meeting time to discuss things between 9E and interested parties in the coreboot community? >> > >> > Take care. >> > Martin >> > >> > >> > Oct 31, 2023, 10:45 by patrick.rudolph(a)9elements.com: >> > >> >> Hello coreboot folks, >> >> At the time of writing coreboot is lacking good firmware menus or >> >> user-space applications to change options consumed by coreboot. While >> >> there's support for changing CMOS options in SeaBIOS or from within >> >> Linux on some x86 mainboards it's quite limited in user friendliness. >> >> While CMOS was a great thing some decades ago, it cannot compete with >> >> today's flash based non-volatile option store, like UEFI variables, >> >> SMMSTORE or VPD. >> >> >> >> Our best engineers at 9elements came up with a possible solution: >> >> coreboot forms representation, see [1], [2], [3] >> >> CFR allows to have nice firmware menus in coreboot payloads as done in >> >> example for tianocore/EDK2 [5]. While it was designed with EDK2 in >> >> mind it's possible to use it on any payload with any variable store >> >> back-end (UEFI, SMMSTORE, VPD, CMOS, ...), as it's really about >> >> providing meta data about the options, not how to actually store it's >> >> value in a non-volatile fashion. The coreboot forms representation is >> >> provided to a payload in a new coreboot table and is generated at >> >> runtime by using C-style lookup tables, but in order to reduce code >> >> duplicates can be defined in common code as done in [4]. >> >> >> >> Please review and give feedback. >> >> Regards, >> >> Patrick >> >> >> >> 1: https://review.coreboot.org/c/coreboot/+/77882/ >> >> 2: https://review.coreboot.org/c/coreboot/+/74121/ >> >> 3: https://review.coreboot.org/c/coreboot/+/78506/ >> >> 4: https://review.coreboot.org/c/coreboot/+/78296/ >> >> 5: https://github.com/9elements/edk2/commit/f34f17996444ef811cc0223b4f875c45da… >> >> _______________________________________________ >> >> coreboot mailing list -- coreboot(a)coreboot.org >> >> To unsubscribe send an email to coreboot-leave(a)coreboot.org >> >> >> > >> > _______________________________________________ >> > coreboot mailing list -- coreboot(a)coreboot.org >> > To unsubscribe send an email to coreboot-leave(a)coreboot.org >> > >> >> _______________________________________________ >> coreboot mailing list -- coreboot(a)coreboot.org >> To unsubscribe send an email to coreboot-leave(a)coreboot.org >> > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

1 0

Add openpgp smartcard authentication
by t＠okpl.ru 21 Nov '23

21 Nov '23

2 1

[coreboot - Support #515] (New) CONFIG_DRIVERS_PS2_KEYBOARD=y doesn't fixate detected keyboard to AT Translated 2 between cold/warm boot
by Thierry Laurion 20 Nov '23

20 Nov '23

Issue #515 has been reported by Thierry Laurion. ---------------------------------------- Support #515: CONFIG_DRIVERS_PS2_KEYBOARD=y doesn't fixate detected keyboard to AT Translated 2 between cold/warm boot https://ticket.coreboot.org/issues/515 * Author: Thierry Laurion * Status: New * Priority: Normal * Target version: none * Start date: 2023-11-20 * Affected versions: 4.21, 4.15, 4.16, 4.17, 4.18, 4.19, master ---------------------------------------- This is a long term issue under QubesOS for x230t/x220t and now x230 users as an be seen https://github.com/QubesOS/qubes-issues/issues/3306 The reason is unclear since it is not a generalized behavior. Is it because of EC firmware version variation, keyboard SKU? User reports don't clarify this enough. What is known (Heads linux payload of coreboot here). If coreboot doesn't do anything for ps2 keyboard, linux does what it can to initialize ps2 and then determine mode of comms, which varies across cold boot/warm boot and sometimes falls back to Raw 2 Translated, which OSes behavior for keyboard cause issues with Backspace, | and \ keys. This is short version of https://github.com/QubesOS/qubes-issues/issues/3306 ---- cbmem -1 filtered output: Coldboot with/without CONFIG_DRIVERS_PS2_KEYBOARD=y ![not normal](https://github.com/linuxboot/heads/assets/827570/c05f82e7-da27-4056… Warm boot: ![normal](https://github.com/linuxboot/heads/assets/827570/5b4009a9-28ea-4c63-98f4-17a472f3b3a2) ---- When applying ugly hack on pc80 coreboot driver: - discussion https://github.com/QubesOS/qubes-issues/issues/3306#issuecomment-1817347378) - ugly patch https://github.com/linuxboot/heads/pull/1525/commits/1a6fbfa26ebf0a0afb58a9… coldboot issue resolved by removing exit 0 from patch above: ![signal-2023-11-18-05-49-02-251-1.jpg](https://github.com/QubesOS/qubes-issues/assets/827570/fe2e509f-8838-41f4-a8b4-bb92ba546c27) So it seems that we could force AT Translated 2 for keyboards that need it. Linux i8042.debug output given by user under https://github.com/linuxboot/heads/pull/1525 (i8042.notimeout, i8042.debug andcoreboot CONFIG_DRIVERS_PS2_KEYBOARD=y on): - [i8042 debug output being going into AT 2 Translated mode](https://github.com/linuxboot/heads/files/13352680/dom0_dmesg_i8042_su… - [i8042 debug output being going into Raw 2 Translated mode](https://github.com/linuxboot/heads/files/13352681/dom0_dmesg_i8042_fa… --- Other solutions attempted: - Forcing coreboot-> linux i8042 options through COMMAND_LINE without success: i8042.translate=1:kbd, i8042.reset + i8042.notimeout and others without success. Coldboot still shows Raw Translated 2 Other possibilities suggested by chat: - adapt pc80 or borrow fixes from libpayload/unifying pc80 code. -- 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 1

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