On 4/29/19 7:23 PM, Matteo Carlini wrote:
> Hi Marek,
> Thanks for raising the topic across the communities. The question is probably how many people from the various projects are going to attend Plumbers this year in Lisbon, so to create some critical mass.
> The TF.org project is planning a significant presence at the Open Source Firmware Conference happening the week before in California (https://osfc.io/), sponsoring the event and submitting few engineering topics. This is another great opportunity to meet and chat on Boot/Firmware topics as well.
The conf being in the US is a barrier for some, for various reasons.
Another upside of LPC miniconf is that you have the kernel people there,
who are taking over once the bootloader starts them, so it would give us
an unique opportunity to synchronize with their needs.
I had some exchange(s) on IRC and Alex Graf mentioned that rather then a
pure bootloader miniconf, we should also pull in OpTee and other such
"resident service provider" projects, since the kernel also communicates
with those and they're installed before the kernel takes over.
> Having a boot miniconf the week after in Europe may be a natural extension, but I'm wondering if people would be willing to travel and attend two similar events in a row...
I cannot answer that, maybe the result of this email can :)
Thanks for raising the topic across the communities. The question is probably how many people from the various projects are going to attend Plumbers this year in Lisbon, so to create some critical mass.
The TF.org project is planning a significant presence at the Open Source Firmware Conference happening the week before in California (https://osfc.io/), sponsoring the event and submitting few engineering topics. This is another great opportunity to meet and chat on Boot/Firmware topics as well.
Having a boot miniconf the week after in Europe may be a natural extension, but I'm wondering if people would be willing to travel and attend two similar events in a row...
[Arm & TrustedFirmware.org]
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Marek
> Vasut via TF-A
> Sent: 29 April 2019 14:39
> To: Marek Vasut <marek.vasut(a)gmail.com>
> Cc: u-boot-custodians(a)lists.denx.de; tf-a(a)lists.trustedfirmware.org;
> Subject: [TF-A] [LPC] Bootloader miniconf
> I was pondering whether it would make sense to organize a bootloader
> miniconf at Linux Plumbers . The Linux kernel is what we often start, the
> bootloader projects generally do similar things, hence I think being able to
> meet face-to-face and discuss how to make things better/nicer would be
> Feel free to expand the CC list to other interested parties.
> Thoughts ?
>  https://www.linuxplumbersconf.org/
> Best regards,
> Marek Vasut
> TF-A mailing list
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-------- Weitergeleitete Nachricht --------
Betreff: Re: [coreboot] Re: Fwd: Re: Fwd: F2A85M IOMMU still not
working for RIchland CPUS
Datum: Thu, 18 Apr 2019 16:24:42 +0200
Von: Kinky Nekoboi <kinky_nekoboi(a)nekoboi.moe>
An: Mike Banon <mikebdp2(a)gmail.com>, coreboot(a)coreboot.org
sudo dmesg | grep microcode
[ 1.177705] microcode: CPU0: patch_level=0x0600111f
[ 1.177708] microcode: CPU1: patch_level=0x0600111f
[ 1.177715] microcode: CPU2: patch_level=0x0600111f
[ 1.177722] microcode: CPU3: patch_level=0x0600111f
[ 1.177761] microcode: Microcode Update Driver: v2.2.
works like a charm.
please inform me if this is still the case: (from libreboot side)
are there any other blobs present in my rom now besides microcode ?
/* my build rom in attachment for inspection. (no vbios included as i
mentioned before radeon gpus are not working, i am running an NV GT210 atm)
AMD SMU firmware
Handles some power management for PCIe devices (without this, your
laptop will not work properly) and several other power management
The firmware is signed, although on older AMD hardware it is a symmetric
key, which means that with access to the key (if leaked) you could sign
your own modified version and run it. Rudolf Marek (coreboot hacker)
found out how to extract this key in this video demonstration
and based on this work, Damien Zammit (another coreboot hacker)
partially replaced it <https://github.com/zamaudio/smutool/> with free
firmware, but on the relevant system (ASUS F2A85-M) there were still
other blobs present (Video BIOS, and others) preventing the hardware
from being supported in libreboot.
Am 18.04.19 um 15:08 schrieb Mike Banon:
> Thank you, Nekoboi. If I understand it correctly: you haven't changed
> anything at coreboot or its' configuration, but your IOMMU suddenly
> started to work? ;-) (unknown what got it working?) Also, please could
> you make almost the same coreboot build, with the only difference is
> these microcodes installed by the unofficial patch:
> , and then try it again with the same Linux to see if it's still
> working. With this patch applied, the microcode level should be
> 0x0600111f (...1f instead of ...0f) to confirm the successful
> On Thu, Apr 18, 2019 at 1:35 PM Kinky Nekoboi
> <kinky_nekoboi(a)nekoboi.moe> wrote:
> IOMMU and system still booting without linux kernel level microcode
> Am 18.04.19 um 11:38 schrieb Kinky Nekoboi:
>> -------- Weitergeleitete Nachricht --------
>> Betreff: Re: [coreboot] Re: Fwd: F2A85M IOMMU still not working
>> for RIchland CPUS
>> Datum: Thu, 18 Apr 2019 11:38:16 +0200
>> Von: Kinky Nekoboi <kinky_nekoboi(a)nekoboi.moe>
>> An: Mike Banon <mikebdp2(a)gmail.com> <mailto:firstname.lastname@example.org>
>> CPU : A8-6600K
>> [ 1.271514] microcode: CPU0: patch_level=0x0600110f
>> [ 1.271521] microcode: CPU1: patch_level=0x0600110f
>> [ 1.271532] microcode: CPU2: patch_level=0x0600110f
>> [ 1.271538] microcode: CPU3: patch_level=0x0600110f
>> [ 1.271583] microcode: Microcode Update Driver: v2.2.
>> i compiled from the master tree, build on 16. April 2019
>> no microcode was included in that build.
>> next step i will try if, the problems occur again if i remove
>> updates via llinux kernel.
>> here is cbmem output as attachment
>> Am 18.04.19 um 06:08 schrieb Mike Banon:
>>>> also it seems that IOMMU is working now...
>>> Congratulations with these amazing news! Please tell, what version of
>>> coreboot you've currently installed? Also, have you used this
>>> microcode updating patch from DangerousPrototypes page before building
>>> your current coreboot build?
>>>> maybe cause i have microcode updates in the kernel included this time ?
>>> By the way, the microcode updates provided by Linux are _older_ than
>>> what this "microcode updating patch" is providing : simply because AMD
>>> has shared their latest update with some proprietary UEFI makers but
>>> didn't share them with the opensource world (and so we had to get them
>>> by manually extracting). But if the kernel sees that a newer microcode
>>> version is loaded, it doesn't replace it. Please, could you check and
>>> tell, what microcode version do you see as installed?
>> coreboot mailing list -- coreboot(a)coreboot.org <mailto:email@example.com>
>> To unsubscribe send an email to coreboot-leave(a)coreboot.org <mailto:firstname.lastname@example.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
I was pondering whether it would make sense to organize a bootloader
miniconf at Linux Plumbers . The Linux kernel is what we often start,
the bootloader projects generally do similar things, hence I think being
able to meet face-to-face and discuss how to make things better/nicer
would be beneficial.
Feel free to expand the CC list to other interested parties.
I got an actual p2b motherboard a few months ago so that I could
actually test it properly and not just claim the p2b build works on
the p2-99. It seems to work fine and flashrom works on the p2b (but
not the p2-99).
I believe there was some discussion and a patch to setup the p2-99 as
a variant of the p2b and if the patch is still around, it would
probably be best to try to figure out if that is what we should do.
I'd like to get around to doing some more work with coreboot yet, but
I'll probably be too busy for a while and really haven't gotten around
to it up until now either. Sorry for just making more work out of an
24 April 2019 meeting minutes
Attendees: StefanR, WernerZ, PatrickG, MartinR, MattD, Dhendricks,
FelixH, PhilippD, Jay Trivedi, Aheymans
Martin’s been very busy with personal issues and hasn’t gotten to the items
from last meeting
* Will publish last meeting’s minutes with today’s. (These are below)
Finding a leadership group replacement for Marc
- Email to the mailing list asking for nominations drafted and reviewed
* (GSoC guidelines prevent posting discussions)
- April 24 - May 1 18:00 UTC: Org Admins select the proposals to become
student projects. At least 1 mentor must be assigned to each project before
it can be selected. (Org Admins enter selections)
- May 1-5: Google Program Admins will do another review of
- May 6: Accepted GSoC 2019 students/projects are announced
Voting in the community
* Martin has not yet written up the questions but will write up
the questions in the next week and we can discuss them in the next meeting
* Topics include
- How to handle copyrights
- Line length
- Automatic code formatting
The 4.10 release is scheduled for the end of April
* Patrick will start the process.
* Martin will start work on the document for release notes.
* Arthur proposed a few requirements for boards to remain on the master
branch on the mailing list for the 4.11 release - will include these
requirements in the 4.10 release notes
- All boards/chipsets need to use Relocatable ramstage
- All boards using Cache-As-Ram would need a postcar stage
- All boards need C env bootblock (Maybe move this to 4.12)
- Deprecate 1.0 FSP in 4.12 - maybe maintain it on a branch
- No new FSP 1.0 boards will be allowed in the tree after the 4.10
- Intel should decide how they want to handle this
~ Note that a new Broadwell-DE chip was just released
- The three chips still using FSP 1.0 are
~ Baytrail E38xx embedded SoC
~ Broadwell DE Xeon SoC
~ Rangeley C2000 SoC
* If we're looking to maintain platforms on branches, we have an issue
that branches aren't tested.
- Patrick will work to set up builders for branches
Martin just pushed initial patches for picasso (AMD Zen based processor)
* Martin will write some documentation and get it released
How does the coreboot project want to spend the money we’ve collected?
* Request: Hire someone to update the website.
- Come up with a list of what we’d like to see improved.
- Martin will send out an email to the mailing list.
* Request: Look at hiring a tech writer to help with documentation?
- There’s a fear that they wouldn’t be able to do anything
useful because of a lack of knowledge
- Maybe hire someone from within the coreboot community to write the
* Request: Test setup on real hardware?
- We need a plan on how to implement this.
- The amount we’d be willing to spend per month depends on what we get.
- We'd be looking at an upfront portion (cost of board + setup fee)
then a fee for ongoing maintenance.
- How frequently are we looking at having the boards tested?
- Every 4 hours / 1 day / every commit?
- There’s worry about long-term sustainability of testing.
- Just test a few key platforms
Can we look at running another round of compile tests before the commit
merge goes through? The build has gotten broken several times recently due
to conflicts between merges that weren’t noticed in testing or by merging
commits out of order.
* Gerrit doesn’t support this very well.
* Can we do something similar to ChromeOS and close the tree when
the coreboot breaks so nothing else gets merged on top?
- This would be a significant amount of work as well
* Is it worth the pain if it’s only once or twice a month?
10 April 2019 meeting minutes
Attendees: FelixH, PhilippD, StefanR, MartinR, PatrickG, ArthurH
* Martin tried to set up livestream, but it’s internal only. We’ll
try again for next time.
* Finding a leadership group replacement for Marc
- Do we want to open nominations? (yes)
- Martin will send out email to list. (sent)
* Should we go for a copyright “The coreboot authors” with an AUTHORS file?
- We're getting copyright lines for trivial changes and code deletions
- Proposed on IRC, so far 2 “+1”s, no objections
- Werner needs to ask in company about what they think about an AUTHORS
file (Still working on following up with this)
- Ron mentions issues they had with copyright notices in Harvey project,
encourages use of AUTHORS
- Should we just create a guideline of what’s copyrightable?
- Martin has been encouraging people to contribute code so they can add
copyright headers heighten their profile in the community
- Philipp proposes other means of raising profile:
maintainership, marketing (eg. talking about your work on twitter, getting
re-tweeted by coreboot_org)
- Martin to research and create guidelines on what’s necessary for
- Start an AUTHORS file
- Ask the community about moving copyright lines from individual files to
AUTHORS for consistency
- Create a script to generate the initial Authors file
* Who is the voting population for coreboot?
Martin researched commits & reviews over the past 2 years and came up
with these statistics
- Looking at just committers for the past 2 years:
- cutoff 20 commits: 70 voters
- cutoff 10 commits: 105 voters
- Including committers & Reviewers in the past 2 years:
- cutoff 20 commits or 20 reviews: 77 voters
- cutoff 10 commits or 10 reviews: 117 voters
- Looking at just commiters from the past 1 year:
- cutoff 20 commits: 43 voters
- cutoff 10 commits: 77 voters
- Including committers & Reviewers in the past 1 year:
- cutoff 20 commits or 20 reviews: 54 voters
- cutoff 10 commits or 10 reviews: 90 voters
- Go with the widest distribution: 10 commits or reviews in the past 2
- Martin has generated the list
* GSoC applications are in
- (GSoC guidelines prevent posting discussion)
* Community events:
- Hackathon in June: 3 tickets still open, so get yours fast
- OSFC 2019: CFP is out, registration open next week
- Philipp will send invites directly to previous presenters and
people on coreboot contractors list.
- OSFC needs people on the program committee to review proposals
* Voting in the community:
- Ranked voting using https://civs.cs.cornell.edu
- Martin will create a list of questions:
- Line length question: 80, 88, 96, 120, 132, unlimited characters
- clang-format or not?
In recent months, Marc Jones, a longtime contributor and leader in
the coreboot community, hasn't been able to participate as much as he
has wanted to, and is opening up his leadership position for someone
who is better able to focus on it. The coreboot leadership is looking
for a person to replace him and would like to open the process for
- Participating in leadership meetings, helping to make decisions
about the future of the coreboot project
- Driving the community forward
- Representing the coreboot project when working with other
open-source firmware projects and hardware manufacturers
Who can apply:
- Employees of Google are not allowed as Stefan Reinauer works at
Google, and according to our agreement with the SFC, we'll only have
one member of the coreboot leadership from each company.
- Employees of Siemens are also not allowed for the same reason:
Werner Zeh is an employee of Siemens.
- Should have been an active committer over the last year.
- Should have a good understanding of the coreboot codebase
- Should be an active member of the community, participating in at
least some of the following ways: Attending conferences / Commenting
and reviewing commits / Being active and helpful on the email list /
Being active and helpful on IRC
If you're interested in the leadership, please reply to this email.
If you think someone else might be interested, please have them reply
I build CB from the master branch a few times a month for an ASUS KCMA-
D8 motherboard. On some CB builds, CB will boot fine and consistently
(press the power button, wait a little bit, SeaBIOS starts).
On other CB builds, sometimes it may boot fine (power button, wait,
SeaBIOS), but other times it won't boot fine (press power button, wait
a bit, nothing happens/no SeaBIOS). When it doesn't boot, I have to
reset the machine a random amount of times in order to get it to
finally boot (sometimes 2-3 times, but as of lately it's been up to 5+
I didn't keep track of successful build dates/commits, but I believe I
compiled from master earlier this month (April 2019) and had consistent
booting. I'm currently using the 4.9 release tag and it boots
I looked at the merged commits from this month and didn't really see
anything obvious that may be causing this. I'm unsure how to debug CB
or get any kind of logs from it, and don't have any serial or USB
I'd like to be able to compile from master and boot consistently, and
would like to figure out what the problem is.
I have the settings I set for CB for this motherboard noted here: