-----BEGIN PGP SIGNED MESSAGE-----
Hi @ all,
is there a Coroboot for the Lenovo T410 Laptop?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
I have a board here that loads memtest86 but won't actually test memory.
This is the output:
AMD K10 CPU @ 2312 MHz
L1 Cache: 64K 35028 MB/s
L2 Cache: 512K 6963 MB/s
L3 Cache: 2048K 6052 MB/s
Memory : 0K
I'm guessing memtest86 doesn't understand coreboot's memory
tables/structure, but I have no idea why that would be. The e820 map is
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x000000003ffacfff] usable
BIOS-e820: [mem 0x000000003ffad000-0x000000003fffffff] reserved
BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved
Any ideas? Other than this one irritating glitch coreboot is working
perfectly on this board.
+1 (415) 727-8645
we have used two logos in the past for flashrom. The one most are
familiar with is actually a generic icon stemming from coreboot's
"Related Tools" section, i.e.:
This is not only set up as the "Mediawiki" icon on flashrom.org but is
also used on our Twitter account and other sites like openhub
The second logo was specifically designed for this purpose and was used
at various occasions in presentation slides and on marketing materials
(e.g. posters). Namely
(the one described as "Different style of bolt" on
I think that one is way lesser known since even I was not really aware
about the fact that it kind of the "official" logo at the moment.
I am not too happy with either. The hammer logo has grown dear to me...
the hammer perfectly symbolizes the force we have to exert to get some
systems to work and the logo as such is very recognizable. But... I
only have it in very low quality... is there a better source for it?
It also does not represent our generally gentle and cautious approach
when dealing with hardware and our focus on stability.
The DIP logo on the other hand is available in SVG (at least
Carl-Daniel has it AFAIK), but it looks a bit inanimate. The major
problems I have with it are that it is not even nearly rectangular and
it is very complex. There is the text with the lightning bolt replacing
the h character and the DIP32 chip. Both is ok for posters and other
big displays but sucks for other uses where simple, rectangular icons
I have spent the last weekend with playing around with Blender and its
freestyle renderer that is able to output SVG directly. I have managed
to render a 3D model of a SOIC8 chip that way as a base for a possible
new logo. It required some cleanup afterwards but it looks way better
than everything I could draw by hand ;)
I have made two logos that I think are worth sharing. They are quite
similar and the only major difference is the orientation of the chip...
I have created 3 versions of each: one fully colored, one with outlines
only and a two-colored simple version (e.g. for PCB silkscreens). I
have attached the Inkscape SVGs as well as 96 pixel-wide PNG exports. I
have not decided on an appropriate license... probably something
similar to how the coreboot hare is licensed.
What do you think about my suggestions and the whole matter? I would
love to see proposals for alternatives as well!
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
I am currently planning to set up a test system with 5 (later up to 10)
machines boot testing each new coreboot commit. This test system will be
serviced (i.e. recovery from bricking) Mo-Fr during CET/CEST office hours.
Current goals for every commit:
- Check if coreboot + SeaBIOS are able to boot Linux to a point where
network is up and running
Current goals for every work day:
- Check if screen, keyboard and touchpad/mouse work
- Check if USB works and has the expected transfer speed (i.e. if USB
High and Super Speed both work)
Future goals for every work day:
- Run memtest86+ (short run)
- Run GRUB2 and boot Linux
- Check if USB works (see above)
Once any test running once per work day can be automated with reasonable
effort (i.e. not requiring robots or human interaction), it can be moved
to a per-commit goal.
The selection of target systems should include:
1. at least one x86 laptop without an active ME (present but inactive
would be OK)
2. at least one x86 laptop which can boot x86-blob-free (except microcode)
3. at least one x86 board or laptop which needs neither blobs (except
microcode) nor ME
4. at least one x86 board with reasonable (past or present) business
5. if the first two laptops use the same CPU vendor, a board using a
different x86 CPU vendor
1+2 are designed to partially remove the potential for nasty surprises,
3 should remove nasty surprises completely, 4 is the one I need to show
that the test system is actually relevant for our goals, 5 should give
us better coverage outside the most common systems used by coreboot
Please nominate machines (e.g. "Thinkpad T60 with Intel graphics") and
tell me to which category they belong. If a system fits into multiple
categories, please specify that as well.
I will try to consolidate the recommendations and buy those machines.
Once the system is up and running (hopefully in May), I will add more
machines suggested by the community as time permits.
The time window for suggestions will close at the end of February.
let's say goodbye to all Intel notebooks produced by OEM's which are not
Google ( Chromebooks ). Maybe the haswell/broadwell notebooks of Lenovo
without U/Y processor can be used ( Thinkpad tXX xXX ). It depends if
they are supporting Intel Boot Guard on the southbridge...
> On 02/06/2015 06:29 AM, Zaolin wrote:
> > Hi,
> > new thinkpad's can't be used anymore for coreboot. Especially the U and
> > Y Intel CPU Series.
> > They come with Intel Boot Guard and you are won't be able to boot
> > anything which is unsigned and
> > not approved by OEM. This means the OEM are fusing SHA256 public key
> > hashes into the southbridge.
> > For more details take a look at Intel Boot Guard architecture. It could
> > be also confirmed by Secunet AG and Google.
> > Regards Zaolin
> That's scary to say the least. No more Thinkpads for us...
have seen the same problem on all thinkpad product types supported by
Maybe someone should get a Windows Developer Edition
and solve this bug ;) .
> I tried today a windows 7 installation usb stick and a cd disc.
> Both 32bit and 64bit.
> Both Windows' stopping at disk.sys and the hdd led on.
> 32bit: sometimes windows boots, most time not.
> Any ideas, what's wrong?
Okay, the doodle has been up for a while now and it seems that
write32(address, value) is preferred by a clear majority of people. I've
prepared a set of patches starting at
https://chromium-review.googlesource.com/#/c/254862 to enact that change in
the Chromium repo. As mentioned before, I think due to the fact that
there's much more active ARM(64) development going on in Chromium right now
I should only land it there for the time being and wait until it naturally
bubbles up to mainline coreboot as part of the current upstreaming
effort... trying to apply it to both trees at once would just require a lot
of pointless conflict resolution effort to down the road.
Am Donnerstag, den 26.02.2015, 22:15 +0100 schrieb Patrick Georgi:
> 2015-02-26 21:56 GMT+01:00 Aaron Durbin <adurbin(a)chromium.org>:
> > I reproduced the error. I was trying to figure out how to debug it. I
> > entered into the util/crossgcc/build-armv7-a-eabi-gcc directory and
> > typed make. Everything worked... I'm trying again. I'm not really sure
> > why one way would fail and the other not.
> Paul, could you try executing buildgcc manually (not through a make rule)?
Just for the archive, running `./buildgcc -G -p armv7a-eabi` worked.
> If that works, there's some make environment stuff that survives and
> breaks things.
Thank you for providing a patch ! I’ll test that tomorrow.