There is motherboard based on the Intel Rangeley Atom C2000 (C2758) series processor. How to enable the SMBus0 in coreboot? If I use OEM BIOS or BIOS from Intel (EDVLCRB1.86B.0048.R00.1508181657_MPK) for mohon peak crb, then I see on the SMBus0 (i2c-1 in Fedora 28) memory DIMM spd (0x50 & 0x52), clock generator (0x69) and other devices. If I use a coreboot based bios for the Mohon peak platform - I do not see any devices on i2c-1. I see an data exchange on the SMBus0 with oscilloscope at boot time only. When I send "i2cdetect -y 1" command in Linux no activity on SMBus0 and no device found.
It seems that after the switch to a new UI some bits were missed in transition.
Sulaco ~/work/coreboot (git::lenovo_z61t_no_ctrl_swap): git review
remote: error: branch refs/publish/master/lenovo_z61t_no_ctrl_swap:
remote: You need 'Create' rights to create new references.
remote: User: lemenkov
remote: Contact an administrator to fix the permissions
remote: Processing changes: refs: 1
remote: Processing changes: refs: 1, done
! [remote rejected] HEAD ->
refs/publish/master/lenovo_z61t_no_ctrl_swap (prohibited by Gerrit:
not permitted: create)
error: failed to push some refs to
Sulaco ~/work/coreboot (git::lenovo_z61t_no_ctrl_swap):
I didn't change anything - so I guess the issue is on the Gerrit's side.
With best regards, Peter Lemenkov.
On 07.06.19 08:56, Alex Feinman wrote:
> I've checked the upper 16 MB - simply dumped the block at 0xff9f0000
> (0xff000000 is the last 16 MB + MRC cache region offset 0x9f0000 from
> the layout file ) where in my image the MRC cache region resides (I can
> confirm it's there by dumping the image from flash). The data I read
> from the supposed memory mapping is all 0xff.
IIRC, you already confirmed with an external programmer that the data
is written at this location, right? If the data is there but not memory
mapped, maybe that offset isn't covered by the BIOS region in IFD?
> fmd and .config files are attached
I didn't spot anything problematic there. But as you don't have
CONFIG_VBOOT selected, you could also try a much simpler FMD file or
just the automatically generated default, by unsetting CONFIG_FMDFILE.
In my Coreboot build (derived from kblrvp configuration) based on 4.9 label I am seeing that MRC test is run on every boot. From what I can tell, what happens is:
1) On first boot the MRC cache is not found (correct). MRC test is done and the MRC cache is saved successfully. If I pull the BIOS image down, I can see valid contents of the MRC cache where they are supposed to be
2) On the second boot MRC verification fails because rdev_mmap does not have .mmap method in the rdev ops. Since this rdev is based on boot_device_rw_nommap, this seems to be both intended and clearly wrong.
3) At this point MRC test is rerun and is written to the flash *without erasing it first* resulting in corrupted data.
4) Next and all subsequent boots result in reading back corrupt header from MRC cache and a failure followed by retrain.
I was able to hack it by replacing 3 calls to mmap with readat and adding erase before the MRC update, but clearly it is supposed to work, so what am I missing?
The board is fairly close to KBL RVP3 and the changes to coreboot are minimal. FMD file has MRC cache section
I'm open to suggestions
Patrick, Matt, Stefan, Arthur, David, Felix, Ron, Philipp, Martin,
### New feature enablement with gerrit 3.0?
jenkins integration in gerrit
* Not urgent - Patrick [will
look](https://ticket.coreboot.org/issues/212) at adding these features
when he has some time.
### Blog access (syndication of a subset of their own blog posts) for
* Maybe with some rules on content, like “must be useful
information for non-customers” and “explicit advertisement for
services and products only in the last paragraph, at most X words” to
avoid becoming a vendor bulletin board (also known as spam trap)?
* Stefan approves, David approves, with clear guidelines for the vendors.
* 3mdeb is interested, 9esec is interested, Martin to ask Kerry
(Silverback), David to ping Eltan
* Example that led to this idea:
* “At most 100 words” would be plenty of space for their (in
Patrick’s humble opinion) reasonable ad paragraph while avoiding a 500
words article with 25000 words of ads in a single paragraph
* Next steps?
* Ask the vendors if there’s interest
* Who will drive the logistics?
* What do we (and the vendors) prefer, direct blog access or
syndication from their own blogs?
## Discuss deprecating additional platforms after coreboot 4.11 release.
Aside from the FSP platforms, these should mainly platforms that are
no longer actively being worked.
FSP 1.0 chips
* Broadwell DE
* David to follow-up with Intel this week.
FSP 1.1 chips
* Why remove fsp 1.1? It’s maintained, “not too bad”, active developers?
* Braswell - Keep this
* Arthur says we have C bootblock support
* 4 new platforms in flight.
* Actively being maintained
* Skylake 1.1 (Also has a 2.0 implementation)
* Drop Skylake 1.1 in favor of 2.0
* Need to update skylake 1.1 platforms to 2.0
Other Possible chips to remove if not being maintained or used
* Via Vx900
* AMD F10
* AMD F12h
* ti am335x
Other items relating to platform removal
* Announce removal for 4.11 “unless a maintainer shows up”?
* What are the requirements on the maintainer?
* At least submitting a working board-status quarterly
* For now, 'boots to kernel' is a minimum requirement.
* Ramp up the requirements for maintainers (because we had
folks registering themselves as maintainer only to disappear)
* The boots-to-kernel + board-status requirement is only for
the boards that are supposed to be removed for 4.11
* Increase the requirements once board-status (or
whatever succeeds it) [can track
it](https://ticket.coreboot.org/issues/210). No use requiring stuff
that we have no systematic way for maintainers to report.
* Request specific things for 4.11 release?
C_ENVIRONMENT_BOOTBLOCK, NO_CAR_GLOBAL_MIGRATION? (for applicable
* Agreed on announcing this in 4.10 release
### Should we change the version numbering for coreboot releases
* After making the 4.11 branch and removing the unused platforms
from ToT, should the next release be 5.0?
* Do we want to go with a Year-based version numbering scheme
* “Coreboot 95” (although that would be Caesar Domitian’s release)
* Stefan likes version numbers (over year based numbers)
* David does too, major.minor versions have useful info
* Fall 2019 release plan:
* 4.11 release is done (~Oct 2019)
* Remove unmaintained platforms
* 5.0 release is tagged (~Oct 2019)
* Old platforms can continue to be maintained on 4.11 branch
* Needs jenkins integration ([build on branch with
* 5.1 release will be in spring 2020
### 4.10 release is behind schedule
* Patrick hopes for release this week
## Should we add Rust support in coreboot?
* Idea is based on Ron’s oreboot project
* Ron prefers talking about compiler guards (again) (kidding!)
* Needs coreboot toolchain support
* What would we use it for? (no answers) (write romrustc)
* Maybe too soon to look into this
* Stefan would like to see the oreboot project re-implement a
base coreboot feature set before pulling it into coreboot.
* Rust can give a lot of features for free, but the binaries are
### Authors file
* Martin to write a script to remove copyright lines and add them
to the AUTHORS file
* This will happen after the 4.10 release
* Call for papers -
* Still looking for more submissions
* Change submission requirement to paragraph summary
* Add draft slides / outline requirement for 1 month after submission
* New deadline for submissions is July 1
* Travel subsidies available for speakers if needed
* Philipp to post call for papers to coreboot mailing list
Public link to coreboot leadership minutes document:
Anyone interested in joining the leadership meetings in the future can
check the calendar on the coreboot website for call-in information.
The next meeting is Wednesday June 19, 17:00 UTC
Just tested a build using this config:
with a recent coreboot (my master branch HEAD is at 0da3a8a91b
soc/intel/baytrail: set default VBIOS filename and PCI ID)
When selecting "3" or "4" for the secondary payloads like coreinfo in
Seabios, I always hit this:
payloads/libpayload/drivers/i8042/keyboard.c: printf("ERROR: Keyboard
reset failed ACK: 0x%x\n", ret);
I get "ERROR: Keyboard reset failed ACK: 0x1".
and I basically have to shutdown.
what's wrong? I think commit 7ae606f57f0b3d450ae748141b0e2367041b27d3
This is perhaps naive, but it's a question that I've been thinking about
for a while.
Pretty much all AMD GPUs (both integrated and otherwise, including PCIe
cards) rely on vgabios blobs for init and to support the driver(s).
From what I've heard, the people writing open source drivers for these GPUs
really don't want to deal with the init and modesetting, ect. Does this
mean it's more practical to try to make open source versions than to try to
eliminate their use outright?
If that's the case, it seems like there's insufficient tooling?
There's been some stuff about reading and writing of vgabios blobs with
flashrom  but I haven't heard anything about a compiler or toolchain
that can produce them. The closest is the available disassembler , which
can provide some insight but probably wouldn't be useful for building
vgabios blobs from source as part of a coreboot build. (I think there were
also some modified radeon drivers for tracing vgabios calls, but I can't
find them now)
Besides a compiler, what other infrastructure would be needed? Maybe tools
for testing and debugging?
A side tangent:
One thing realized recently is some versions of the G505s contain slightly
different versions of the same rom. It seems my G505s' for example has
different LVDS timings that perfectly match the slightly different panel
that mine shipped with. 
I haven't been able to try a "normal" rom with the panel yet, but one
theory to be tested is that the proprietary bios is patching the rom with
the values from the panel's EDID information. (I tried installing a
different panel, but was only met with a temporarily nonfunctional laptop)
Assuming it's not the rom modifying itself (do vgabios' have access to EDID
information?), would it be correct to supply values from the EDID
information to the vgabios build? Or would it be better to have the
coreboot's loader patch the tables by parsing the current panel's EDID
info? (I've seen comments that coreboot's lack of EDID parsing support also
makes native graphics init harder )
Does anyone else know of other tooling that's out there?
I also came across some other misc stuff: