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:
TL;DR you can simply compile a VGA BIOS with GCC/Clang. You don't have
to make the same mistakes as AMD and compile/interpret some byte code.
Which, IMHO, would only make it harder to implement an open-source
On 05.06.19 02:38, Matt B wrote:
> I'm not talking about replacing a blob that nobody understands with a
> technically different but equally incomprehensible one. It sounds like your
> interpretation is to simply copy all the individual routines to a new blob.
> (Some sort of strange Theseus' ship exercise?) But you don't develop an
> open-source replacement for any a piece of software by a copying several
> sequences of instructions from the original ELF file to another.
well, I'm afraid that is what many people do. Most of the AtomBIOS code
will be like: write magic number A into magic register B. If you do that
too in your code, it works. If you don't do it, it doesn't work. I fear,
without an unreasonably huge effort, the open-source version won't get
much more comprehensible. I don't think the AMD hardware is worth it
when you can get documentation from many other vendors. Or maybe the
time is better spend on convincing AMD to release documentation.
> Presumably (one would hope) somewhere AMD has un-obfuscated
> (understandable) source code of some form that was compiled into the
> vgabios roms that are frequently used. I recognize that it would be a
> colossal pain to figure out how the chips work without documentation, but
> in order to go through that process, tooling would presumably be
> Afaik, the only development tooling anyone has right now is a disassembler.
> Nothing which can turn the source code one might try to write into a
> vgabios blob that could be loaded into a build of coreboot and tried out.
> This is important as the painful process typically works when replacing any
> proprietary code is :
> a) try to write something that's a little bit correct
> b) build and flash
> c) test the result and make a few changes
> d) go back to step B until a little bit more functionality is understood,
> then go back to step A for more
> For that to work it's a big help to have a compiler that can turn
> annotated, documented source code into the binary format that's stored in
> flash. That same compiler also sees use in builds once things are complete
> enough to start sharing source code. That's why I'm interested in the
> question of whether such a tooling is available.
Let's add some more background. AMD's VGA BIOS contains two code parts:
1. The AtomBIOS that is card/mainboard specific, compiled to some byte
2. An interpreter for the AtomBIOS byte code.
There are already open-source implementations of 2. So I guess what you
are asking for is a compiler for the AtomBIOS. But I wonder why? A new,
clean implementation wouldn't have to keep this weird structure. You can
simply skip AtomBIOS byte code and write your VGA BIOS in C, Rust or
whatever you prefer; use GCC or Clang to compile it.
>  One example is the panfrost team's development of the panfrost GPU
> driver. They started by recording and replaying command streams to
> understand how things work, but to move beyond that they obviously had to
> start writing the skeleton of a driver in C.