Dear coreboot folks,
A lot of change sets to the new Memtest86+ project  hosted on the
coreboot infrastructure have been posted. Martin and Ben, thank you for
The commit message summaries are prepended with *Memtest86+* making the
git history look like below.
$ git log --oneline
11248a0 Memtest86+: coreboot.c - Change var name to not mask other variable
f7b770a Memtest86+: Match function declaration with function definition
04f7f14 Memtest86+: Fix bit field that was getting masked off
6959343 Memtest86+: Fix non-ANSI C function declarations
5bb29b2 memtest86+: rewrite popup popdown popclear
fea5eb7 memtest86+: Add license file
I don’t see, how this is helpful. The project is also listed in the
Gerrit table .
If there is no compelling reason, it’d be really great if this could be
left out in future commit message summaries.
Yes, I don't think this project will take many lines of code and so I won't
be spending most of my time coding. I expect most of my time to go into
learning and research. Hopefully this does not make it an inadequate GSoC
On Sat, Mar 26, 2016 at 9:44 AM, Stefan Tauner <stefan.tauner(a)gmx.at> wrote:
> On Wed, 23 Mar 2016 01:58:59 -0700
> Huimin Zhang <thehobn(a)gmail.com> wrote:
> > I have my first draft for my GSoC proposal ready. I am quite anxious for
> > bit of feedback, as I have yet to receive any so far. The link is below.
> Hello Min,
> I am far from an expert on ACPI but the project you proposed seems to
> me as it should be doable in a few weeks maximum. Could you please
> explain why you think this will keep you busy for the whole programming
> period? What problems do you expect to encounter?
> Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Below is a link to my GSoC project proposal draft. In essence it's
about porting coreboot to a non-emulated board with a RISC-V CPU. If you
have any comments, please go ahead and add them to the document.
The exact RISC-V board is not yet decided, but I'll fix that as soon as
Also, I'm not sure about the timeline. It currently weighs heavily on
the first half. Maybe I'm not giving the individual subtasks enough
time; maybe I have not listed enough subtasks to fill the three months
Dear Ivan, dear Jeann,
There is an unwanted regression due to commit d7f96f97 (firmware:
dmi_scan: add SBMIOS entry and DMI tables).
Since Linux kernel 4.2 the utility `cbmem`, used to access information
stored in memory, from the coreboot project  does not work anymore
on a lot of systems as reported in coreboot’s issue tracker as ticket
Failed to mmap /dev/mem: Resource temporarily unavailable
Aaron Durbin analyzed on the coreboot mailing list :
> > 3) Why is that range set as uncached-minus? Would write-back work?
> Please see this thread:
> The actual issue stems from
> which maintains a persistent mapping of smbios tables. It uses
> dmi_remap() which is '#define dmi_remap ioremap' which is where the
> uncached-minus PAT entry comes from. It should be using the same
> mechanism as the ACPI table mappings which uses ioremap_cache().
It’d be great, if the commit could be reverted, or the code be changed
in a way that `cbmem` still works.
If I should report this issue somewhere else, please tell me too, and
I’ll do my best to follow up there.
On Wed, 23 Mar 2016 01:58:59 -0700
Huimin Zhang <thehobn(a)gmail.com> wrote:
> I have my first draft for my GSoC proposal ready. I am quite anxious for a
> bit of feedback, as I have yet to receive any so far. The link is below.
I am far from an expert on ACPI but the project you proposed seems to
me as it should be doable in a few weeks maximum. Could you please
explain why you think this will keep you busy for the whole programming
period? What problems do you expect to encounter?
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
We started on that a few years ago, but ran out of time and abandoned the
effort. There are still patches from Sept/Oct 2013 on Gerrit if you are
interested. Look for "beaglebone" and "am335x" patches by Gabe Black.
The Cubieboard is another dev board you might want to look into. The
patches are merged, and I believe the author had it booting Linux.
On Fri, Mar 25, 2016 at 4:05 PM, daoud yessine <yessine.daoud.92(a)gmail.com>
> Does coreboot work on beaglebone Black ?
> How tried It ?
> coreboot mailing list: coreboot(a)coreboot.org
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
Hello coreboot people,
we are looking for a hired hand in helping us getting IOMMU (Xen
virtualisation) to work on a APU2c4  - it is a fantastic little AMD
SoC based on AMD GX-412TC and the folks at pcengines did a fantastic job
with it. Philip (zaolin(a)das-labor.org) even got secure boot for it
Anyway, we would like to get XEN with IOMMU to work - it is pretty safe
to assume the CPU actually supports it, we are just stuck at weather it
is all related to coreboot, or if there is a bit of a hickup with xen
I summarised everything we have so far at  - would be great if you
could have a look. In terms of compensation, we are completely open, you
tell us, what works for you, e.g. the usual suspects, or bountysource,
Many thanks!! Jürgen