Issue #571 has been reported by Wreg Yek.
----------------------------------------
Support #571: Keyboard scan codes of HP Elitebook 2170p under coreboot are different with those under oem firmware.
https://ticket.coreboot.org/issues/571
* Author: Wreg Yek
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2024-11-23
* Affected hardware: HP Elitebook 2170p
* Affected OS: GNU/Linux with systemd v257-rc1 or later
----------------------------------------
HP Elitebook 2170p is weird compared with many other Elitebooks supported by coreboot, for its keyboard scan codes under coreboot is different with those under oem firmware, regardless of the same set of EC firmware blobs are used.
The scan codes under oem firmware conform to the upstream [60-keyboard.hwdb](https://github.com/systemd/systemd/blob/main/hwdb.d/60-ke…, while after systemd v257-rc1, the `KEYBOARD_KEY_66=pickup_phone` within [upstream](https://github.com/systemd/systemd/commit/93b078c3dd40b10eed34a77… 60-keyboard.hwdb starts to conflict with the scan codes of backspace key under coreboot, where it is 0x66.
Besides backspace, I have collected the scan codes of all Fn-keys under coreboot into the attached 61-2170p-kb.hwdb, which is adjusted to the default SMBIOS tables of coreboot for Elitebook 2170p, and could be used to walk around the scan code conflict.
---Files--------------------------------
61-2170p-kb.hwdb (508 Bytes)
--
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
Issue #567 has been reported by nymous ano.
----------------------------------------
Support #567: How init git repository for avoiding date error?
https://ticket.coreboot.org/issues/567
* Author: nymous ano
* Status: New
* Priority: Normal
* Category: build system
* Target version: none
* Start date: 2024-11-05
* Affected versions: master
* Affected hardware: config.emulation_qemu_aarch64_fit_support_timestamps
* Affected OS: Ubuntu Noble Numbat, 24.04, LTS
----------------------------------------
With compiling for 'config.emulation_qemu_aarch64_fit_support_timestamps' following this tutorial 'https://doc.coreboot.org/tutorial/part1.html'
for origin/main branch on Linux Ubuntu Noble Numbat, 24.04, LTS, for a aarch64 emulation target, there's this error:
> fatal: bad object HEAD
> fatal: bad object HEAD
> fatal: HEAD is neither a commit nor blob
> date: invalid date '@'
> date: invalid date '@'
> date: invalid date '@'
> date: invalid date '@'
> date: invalid date '@'
> date: invalid date '@'
> date: invalid date '@'
> date: invalid date '@'
> fatal: bad object HEAD
> fatal: HEAD is neither a commit nor blob
> Updating git submodules.
> CC romstage/lib/version.o
> CC romstage/southbridge/intel/common/rtc.o
> CC romstage/southbridge/intel/common/smbus.o
> CC romstage/southbridge/intel/i82371eb/early_pm.o
> src/lib/version.c:24:75: error: expected expression before ';' token
> 24 | const unsigned int coreboot_version_timestamp = COREBOOT_VERSION_TIMESTAMP;
> | ^
> In file included from src/lib/version.c:4:
> build/build.h:13:33: error: invalid suffix "x" on integer constant
> 13 | #define COREBOOT_BUILD_YEAR_BCD 0x
> | ^~
> src/lib/version.c:33:17: note: in expansion of macro 'COREBOOT_BUILD_YEAR_BCD'
> 33 | .year = COREBOOT_BUILD_YEAR_BCD,
> | ^~~~~~~~~~~~~~~~~~~~~~~
> build/build.h:14:34: error: invalid suffix "x" on integer constant
> 14 | #define COREBOOT_BUILD_MONTH_BCD 0x
> | ^~
> src/lib/version.c:34:18: note: in expansion of macro 'COREBOOT_BUILD_MONTH_BCD'
> 34 | .month = COREBOOT_BUILD_MONTH_BCD,
> | ^~~~~~~~~~~~~~~~~~~~~~~~
> build/build.h:15:32: error: invalid suffix "x" on integer constant
> 15 | #define COREBOOT_BUILD_DAY_BCD 0x
> | ^~
> src/lib/version.c:35:16: note: in expansion of macro 'COREBOOT_BUILD_DAY_BCD'
> 35 | .day = COREBOOT_BUILD_DAY_BCD,
> | ^~~~~~~~~~~~~~~~~~~~~~
> build/build.h:16:36: error: invalid suffix "x" on integer constant
> 16 | #define COREBOOT_BUILD_WEEKDAY_BCD 0x
> | ^~
> src/lib/version.c:36:20: note: in expansion of macro 'COREBOOT_BUILD_WEEKDAY_BCD'
> 36 | .weekday = COREBOOT_BUILD_WEEKDAY_BCD,
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~
> make: *** [Makefile:430: build/romstage/lib/version.o] Error 1
> make: *** Waiting for unfinished jobs....
There seems to be no hint within tutorial documentation for to avoid this missing date and version from/for the repository?
( Thanks for Your time and engagement. )
--
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
# 2024-11-27 - coreboot Leadership Meeting
## Attendees
Julius Werner, Matt DeVillier, Jay Talbott, David Hendricks, Felix Held, Alicja Michalska, Mina
Asante, Werner Zeh, Andre.
## Open Action Items
* 2024-11-27
* Send out poll with regards to LLM usage (requested by SFC)
* 2024-10-30
* Add clarification to docs, “do not use gerrit change-id or CB: format in reference to
already-merged patches”.
* 2024-10-16
* Matt: Set up a meeting to discuss board status alternatives and send out invites.
* Decouple data collection with uploading
* Require gerrit credentials or other auth to push
* Json format?
* https://github.com/chrultrabook/linux-tools/blob/main/debugging.sh
* 2024-09-18
* Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan.
* Werner: Send out an invite for the meeting.
Sent out a poll to find a time slot: https://rallly.co/invite/1c8J3azXAcje
* 2024-05-01
* Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?)
* 2024-01-10
* Nico: (https://review.coreboot.org/q/topic:enforce_region_api)
* Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project.
## Minutes
### [Julius] Add [Yidi Lin](mailto:yidilin@google.com)
(https://review.coreboot.org/q/owner:yidilin@google.com) to Submitters (“Core Developers”) group
(100+ merged patches, 400+ reviews, been contributing for 4 years, has been bring-up lead for
several SoCs, also contributed to vboot, Arm architecture, etc.)
* Done
### [Alicja] Revisiting extending CBFS to storage media
* (see: 2024-06-26 notes) to deal with large payloads.
# Next Leadership Meeting
December 11, 2024.
[coreboot Calendar](https://coreboot.org/calendar.html).
# Notice
Decisions shown here are not necessarily final, and are based
on the current information available. If there are questions or comments
about decisions made, or additional information to present, please put
it on the leadership meeting agenda and show up if possible to discuss
it.
Of course items may also be discussed on the mailing list, but as it's
difficult to interpret tone over email, controversial topics frequently
do not have good progress in those discussions. For particularly
difficult issues, it may be best to try to schedule another meeting.
# coreboot leadership meeting minutes
https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…
Dear coreboot community,
Please be reminded that we have an upcoming leadership meeting scheduled for Wednesday, November 27, 2024. [1]
Kindly take a moment to review the current agenda and share your thoughts, or suggest any
additional items you would like to discuss during the meeting. [2]
## Current Agenda Items
### [Julius] Add Yidi Lin (https://review.coreboot.org/q/owner:yidilin@google.com) to Submitters
(“Core Developers”) group (100+ merged patches, 400+ reviews, been contributing for 4 years, has
been bring-up lead for several SoCs, also contributed to vboot, Arm architecture, etc.)
[1](https://coreboot.org/calendar.html)
[2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…
Hi All,
Recently had a need to debug the coreboot at source level.
Is it that we can only debug coreboot from romstage and not in bootblock or
verstage via gdb or any other source level debugger?
any pointers will be helpful here.
I see a few pointers below to use gdb for coreboot source level debugging,
any other guidelines or help available for the same?
https://www.coreboot.org/Debugging
*Thanks & RegardsRitul Guru+91-9916513186*
Hello coreboot!
Please note that we have an upcoming review session scheduled for Wednesday, November 20, 2024:
https://meet.google.com/kpu-yozw-gtt
Check the coreboot calendar for the time in your timezone:
https://coreboot.org/calendar.html
As usual, we'll begin by reviewing a few patches together, then switch to individual reviews.
However, everyone will still be available if you have questions about the patch you're reviewing.
Here’s the link to the list of patches to be reviewed this week:
(https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY…
80#gid=594572880)
Kindly add any specific patches you'd like the group to review to the top of the sheet.
Given the limited time for our session, any reviews completed beforehand would be greatly
appreciated.
Thank you.
Best regards,
Mina.
Issue #121 has been updated by Nemanja Z.
I also finally updated my T520 i7-3740QM to 24.08-631-gf8d4283e78d2. (from 4.14-2082-gee760b4be8)
No kernel options, C7 working now, no crashes in Debian 12, Windows 10 also seems fine.
----------------------------------------
Bug #121: T520: Hangs in OS
https://ticket.coreboot.org/issues/121#change-1974
* Author: Firstname Lastname
* Status: In Progress
* Priority: Normal
* Category: chipset configuration
* Start date: 2017-06-09
* Affected hardware: SNB, IVY
* Affected OS: -
----------------------------------------
I have been running coreboot since 2017.04.15 and have experienced hangs ever since then. It was suggested by folk on the IRC that I run memtest to check for incorrect raminit causing errors, however I have run memtest for 12 hours straight with no errors.
Due to the ambiguous nature of the hangs (immediate freeze with no warning signs, audio gets stuck repeating the last 50ms or so of noise, not sure what this effect is called) I don't have much useful information other than the .config and dmesg. However one thing I can say with high confidence is that the hangs occur significantly more frequently in Linux (*buntu distros) than Windows 10. Within an hour of launching Linux a hang is likely, whereas Windows typically runs for many hours before a hang occurs. I considered this an insignificant anecdotal anomaly at first but over the course of the nearly 2 months I have been running coreboot it seems to be a solid trend. The hangs occur anywhere, typically during mere desktop usage or basic web browsing.
Additionally there is another form of hang I experience where the screen goes black except for some sort of graphical corruption down the left side (http://i.imgur.com/4zWrlpX.jpg), whether this is related to the more common total freeze hangs I don't know but I figured I should include it nonetheless. These hangs only occur about 1:20 compared to the regular hangs.
---Files--------------------------------
config (20.7 KB)
dmesg.txt (57.3 KB)
cbmem-raminit.txt (62 KB)
lspci.txt (29.6 KB)
cpuinfo.txt (3.94 KB)
defconfig (1023 Bytes)
defconfig (699 Bytes)
--
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
Hi,
I am trying to understand how cache as ram works and how coreboot
implements it. I am looking into this piece of code:
https://github.com/coreboot/coreboot/blob/main/src/soc/intel/common/block/c…
and if I try to summarize the whole process of setting up cache as ram
is that after setting up MTRR for the region as write-back, we need to
enable cache, invalidate the cache, call "clear_car" so that the
cachelines are marked for these memory addresses. I understand that
this is necessary so that later when CR0.CD = 1, CR0.NW = 1 is done,
the memory accesses to these locations will cause cache hits and if
written to these memory locations, the write-back policy will cause
only the cache to be updated.
My question is when "clear_car" is executed, wouldn't it cause the
cache lines to be filled first (as it's a cache miss), by the cpu
doing memory accesses by trying to "read" those locations? But DRAM
isn't initialized still, so does that mean that the cache lines will
be filled with garbage and this is okay, right? And then the cache is
updated with some value with the stosl instruction. I am just not sure
about if the cache lines will be filled with garbage when the cpu will
first fill up the cache lines by trying to read those memory locations
as there is no DRAM initialized.
It would be great if someone could help me to understand this process. Thanks!
Regards,
Dorjoy
# 2024-11-13 - coreboot Leadership Meeting
## Attendees
Andre, Felix Held, Jay Talbott, Felix Singer, Julius Werner, Werner Zeh, Alicja Michalska, Mina
Asante, Jon Murphy, Matt DeVillier, Maximilian Brune, Ron Minnich, Karthik R.
## Open Action Items
* 2024-10-30
* Add clarification to docs, “do not use gerrit change-id or CB: format in reference to
already-merged patches”.
* 2024-10-16
* Matt: Set up a meeting to discuss board status alternatives and send out invites.
* 2024-09-18
* Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan.
* Werner: Send out an invite for the meeting.
Sent out a poll to find a time slot:https://rallly.co/invite/1c8J3azXAcje
* 2024-05-01
* Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?)
* 2024-01-10
* Nico: (https://review.coreboot.org/q/topic:enforce_region_api)
* Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project.
## Minutes
### [Elyes] Any update on OpenSBI case …. ? (See 2024-07-24 - coreboot Leadership Meeting and
(https://review.coreboot.org/c/coreboot/+/84979) ).
* [Mat]: It was planned to replace the submodule by a binary blob (see patch from Max:
https://review.coreboot.org/c/coreboot/+/83284). This patch is ready to be merged, we do not need
the 3rdparty git repo anymore for OpenSBI.
* Matt will rebase Max’ patch and merge it in.
* [Julius]: Shall we keep the old 3rdparty openSBI submodule in the tree or shall we get rid of it
after Max’s patch was merged?
* [Max]: A lot of users have their own OpenSBI port, so having this submodule in the tree does not
bring us that much benefits. It is hard to update OpenSBI submodule currently (can’t build it with
our toolchain, there might be a missing linker (PIE: *Makefile:193: *** Your linker does not
support creating PIEs, opensbi requires this.. Stop.*) feature). Not clear currently why our
linker is missing.
* [Julius]: Looks like it's not actually querying the linker for that, you just need to set an
option?(https://github.com/riscv-software-src/opensbi/blob/master/Makefile#…
* FelixS will give it a try!
* If we are going to remove it from 3rdparty, we need to document the dependency to the users to
make them aware of the change.
* Conclusion: Keep it as long in the tree as somebody is going to fix the issue.
### [Karthik] Is it ok to enable FW_CONFIG in SMM stage
(https://review.coreboot.org/c/coreboot/+/85107/11/src/lib/Makefile.mk)
* Are there any security concerns?
* FW_CONFIG can use either EC or CBFS
* [Julius]: Is the EC communication driver linked to SMM? –> Yes
* [Karthik]: Since EC code is linked to SMM there is no issue to add fw_config to SMM from Google’s
point of view.
* [Matt]:Isn’t fw_config cached on the first read? → Yes, but per stage only.
* [Mat, FelixH]: Why not toggle the GPIOs even if the WWAN module is not equipped on the board? The
pins should be configured as GPIOs anyway, switching them unconditionally should not harm and will
enable us to not link fw_config into SMM. → Karthik will propose that to the ODMs, looks doable.
# Next Leadership Meeting
November 27, 2024.
[coreboot Calendar](https://coreboot.org/calendar.html).
# Notice
Decisions shown here are not necessarily final, and are based
on the current information available. If there are questions or comments
about decisions made, or additional information to present, please put
it on the leadership meeting agenda and show up if possible to discuss
it.
Of course items may also be discussed on the mailing list, but as it's
difficult to interpret tone over email, controversial topics frequently
do not have good progress in those discussions. For particularly
difficult issues, it may be best to try to schedule another meeting.
# coreboot leadership meeting minutes
https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…