Łukasz Dobrowolski | 26 Nov 00:33 2015

ThinkPad X120e/X140e

Hi all!
I would like to port coreboot to one of my laptops (ThinkPad X140e and X120e).
Both of them have AMD APU-s.

I would be grateful if somebody could take a look at attachments and
tell me how challenging the task appears to be. I read and searched
for information about those for few days now.

What I found (apart from attachments):
        Logical mainboard schematics
        I'm 90% sure I can get my hands on physical mainboard
schematics if needed.
        I have detailed pictures of the mainboard.
        I can make detailed mainboard pictures.
        I haven't searched for schematics of this one yet.

Regards from Lisbon
Attachment (X140e.cpuinfo): application/octet-stream, 6208 bytes
Attachment (X140e.dmidecode): application/octet-stream, 19 KiB
Attachment (X140e.lshw): application/octet-stream, 23 KiB
Attachment (X140e.lspci): application/octet-stream, 68 KiB
Attachment (X140e.superiotool): application/octet-stream, 8 KiB
Attachment (X120e.cpuinfo): application/octet-stream, 2455 bytes
Attachment (X120e.dmidecode): application/octet-stream, 19 KiB
Attachment (X120e.lshw): application/octet-stream, 19 KiB
Attachment (X120e.lspci): application/octet-stream, 24 KiB
(Continue reading)

WordPress | 23 Nov 16:57 2015

New on blogs.coreboot.org: coreboot changelog

A new post titled "coreboot changelog" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/11/23/coreboot-changelog-6/

The week leading up to November 15th has seen 132 commits (8bd1c36..3ca4116).
The leading themes were the removal of support for old mainboards, and the integration of more non-AGESA AMD support code for Family 10h to 15h that spans everything from fixes to memory configuration to workarounds to problems in the SATA controller, to new feature development, enabling CC6 power-state support and everything in-between.

Other chipset level contributions provided bug fixes to the drivers supporting Intel’s Skylake and AMD’s newer chipsets and mainboards (Kabini, Merlin Falcon, Mullins). Rockchip RK3288 now properly configures displays whether they’re connected through HDMI or DVI.

ARM/ARM64 saw some cleanup in its transition between stages to accommodate more processor configurations on ARM64 SoCs (that sometimes come with smaller 32bit cores for supporting purposes).

Also new is the Intel i8900 southbridge support that can be used with Sandy Bridge and Ivy Bridge, with an Intel reference board, the stargo2, and the SUNW Ultra40m2 board support.

The USB device mode driver for DesignWare’s USB2 controller (DWC2) in libpayload became more robust. The other notable field of work in libpayload is work with PDcurses’ upstream to synchronize their development and our copy.

In terms of the ongoing efforts to clean up old cruft across the entire tree, references to the getpir utility were dropped, after the tool was removed nearly two years ago. We also removed empty mainboard driver files that used to be required by the build system, even if the mainboard needed no special handling in its ramstage.
To help keep the quality bar high, automated testing now also covers intelvbttool. Another forward-looking addition is a clang-format specification of our coding style. It isn’t complete yet, but the hope is that we can eventually use it to simplify adhering to a consistent style and then enforce it.
The script to help organizing the commit log for release notes was pushed into util/release.


coreboot mailing list: coreboot <at> coreboot.org
Ben Gardner | 20 Nov 01:07 2015

CBMEM Console corruption with fsp_baytrail in coreboot 4.2


I've narrowed down where the CBMEM console is getting corrupted and
found a work around that gets it working again.
It is getting corrupted in the FSP Early Init function. So in the
Intel blob, not coreboot.

I added logs to cbmemc_init() and cbmrmc_reinit() that show the
console pointer, size, cursor and the first 64 bytes of the console
(including size and console).

Right before the call to FspInitApi() in fsp_early_init():
fsp_early_init: cbm_cons_p: fef00000 size=3064 cur=2606
fef00000: f8 0b 00 00 7b 0a 00 00 63 62 6d 65 6d 63 5f 69  ........cbmemc_i
fef00010: 6e 69 74 3a 20 63 62 6d 5f 63 6f 6e 73 5f 70 3a  nit: cbm_cons_p:
fef00020: 20 66 65 66 30 30 30 30 30 20 73 69 7a 65 3d 33   fef00000 size=3
fef00030: 30 36 34 20 63 75 72 3d 30 0a 66 65 66 30 30 30  064 cur=0.fef000

And this is at the top of romstage_main_continue():
romstage_main_continue: cbm_cons_p: 00000b96 size=2052398204 cur=1024945500
00000b96: 7c 1c 55 7a bd 6d 17 3d 17 a9 76 69 ee 07 d1 b8  |.Uz.m.=..vi....
00000ba6: fa 6b 75 85 ee 7a dd 8f e9 48 59 93 b4 f8 0a ce  .ku..z...HY.....
00000bb6: 1c dc fe a4 09 d6 ba 1d 88 8f 23 e4 40 cc 88 cd  ..........#. <at> ...
00000bc6: 90 91 53 e4 71 6d 90 1d bd e9 fa 13 a8 16 fd b5  ..S.qm..........

So, the FSP is trashing the CAR variables.

I looked at the changes to src/arch/x86/car.ld and see that the
CONSOLE line was moved before _car_data_start.
That move appears to have been in commit dd6fa93d by Aaron Durbin.

When I moved that CONSOLE line back to after _car_data_end, the
console works again.
That also fixes the timestamp table infinite loop issue.

So, I have a work-around.
However, I suspect that the root issue of the FSP trashing CAR
variables persists.

My initial email about the timestamp issue is here:

I'm not sure what to do about this.
The above change seems reasonable and needed for verstage support, so
sending my 'fix' upstream probably isn't viable.




coreboot mailing list: coreboot <at> coreboot.org

Alex G. | 19 Nov 04:49 2015

Payload that can do mmio32/pciserial UART on x86

Is there such a payload? Seabios is stuck with IO UARTs. Not sure if
grub can handle it (and if so, how). Depthcharge is out of the question
because it is unbelievably difficult to build outside chromium os's
uber-cumbersome build system.

So, is there something?



coreboot mailing list: coreboot <at> coreboot.org

ASUS KFSN4-DRE (K8) Automated Test Failure

The ASUS KFSN4-DRE (K8) fails verification as of commit 1455437c9e010bcc617c5927e18cf1cb3b02c82f

The following tests failed:

Commits since last successful test:

See attached log for details

This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE (K8) test stand
Want to test on your own equipment?  Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html

Raptor Engineering also offers coreboot consulting services!  Please visit
https://www.raptorengineeringinc.com for more information

Please contact Timothy Pearson at Raptor Engineering <tpearson <at> raptorengineeringinc.com> regarding
any issues stemming from this notification
Attachment (1447893542-2-automaster.log.bz2): application/octet-stream, 44 KiB

coreboot mailing list: coreboot <at> coreboot.org
Ben Gardner | 18 Nov 21:12 2015

Infinite loop with fsp_baytrail and COLLECT_TIMESTAMPS in coreboot 4.2

Hi all,

Has anyone else tried coreboot 4.2 on fsp_baytrail with

I'm seeing the console flooded with an infinite loop of "ERROR:
Timestamp table full".

The last few post codes are: 4a 4b 4c 4d.
That puts it in fsp_baytrail / romstage.c in romstage_main_continue():

/* if S3 resume skip ram check */
if (prev_sleep_state != 3) {

cbmem_was_initted = !cbmem_recovery(prev_sleep_state == 3);

/* Save the HOB pointer in CBMEM to be used in ramstage*/
cbmem_hob_ptr = cbmem_add (CBMEM_ID_HOB_POINTER, sizeof(*hob_list_ptr));
*(u32*)cbmem_hob_ptr = (u32)hob_list_ptr;

I had console logging set at NOTICE, so I missed some possibly important logs.
Based on a look through the code, I'm guessing the call tree is:

Side note: it takes 15 minutes to load the BIOS using an external
programmer, so I didn't experiment too much.  (Vs. ~30-60 seconds if
programmed using flashrom on the target.)
I just turned off timestamps and reloaded and it boots fine.

Any ideas?

Prior to rebasing on 4.2, I didn't have any issues with timestamps.
I was using 4.1 + a few patches.



coreboot mailing list: coreboot <at> coreboot.org

Anthony Martin | 18 Nov 00:51 2015

questions about veyron boards and the rk3288

1. Is veyron_mickey the ASUS Chromebit CS10?

2. Are any of the veyron_(danger|rialto|emile) products released yet?

3. Also, is the RK3288 TRM available without an NDA?



coreboot mailing list: coreboot <at> coreboot.org

Kevin O'Connor | 17 Nov 21:36 2015

CBFS file format changed but documentation not updated

I noticed that commit 0d618afc modified the CBFS file format.  (It
looks like the "checksum" field was replaced with a new file
"attributes" feature.)  However, the CBFS documentation in the
repository (Documentation/cbfs.txt) was not updated.

It would be great if the documentation could be kept in sync with the
CBFS implementation.  (Or, if that's not feasible, I think it would be
preferable to remove Documentation/cbfs.txt .)  Having up to date
specifications helps other projects (eg, SeaBIOS) keep up with

Also, I didn't see any emails for the above change on the mailing
list.  What is the best way to keep up with notable architectural
changes in coreboot?



coreboot mailing list: coreboot <at> coreboot.org

echelon | 17 Nov 13:39 2015

Some feedback regarding the coreboot hackaton poll

Hello all,

First of all I want to reassure everbody who participated to the poll for the hackaton in Paris, that it is NOT
canceled (in the light of the recent events..) and that I am more deternined than ever to make it happen!..

On the other hand, at the time when I launched this poll (maybe a bit prematurelly), I was missing some
important information regarding other initiatives about potential coreboot meetings in 2016, some of
them related to important events which could have a big impact on the visibility of our project coreboot in
the open source ecosystem. But I will let the persons which are driving these initiatives to make an
anouncement themselves.

Regarding the hackaton in Paris, and taking into account these informations (not yet officially
announced), I cannot yet anounce a firm date for the Paris venue, because we need to accomodate the Paris
meeting with other important coreboot events which will take place in 2016.

Stay tunned..

Best regards,
  Florentin Demetrescu


coreboot mailing list: coreboot <at> coreboot.org

Ben Gardner | 16 Nov 19:26 2015

Long boot delay with a large CBFS

Hi all,

I have a 16 MB BIOS flash on a fsp_baytrail based design.

I tried expanding the CBFS to fill the whole space, but found that to
cause a 10-15 sec boot delay.

The offending code appears to be here:


coreboot mailing list: coreboot <at> coreboot.org

Peter Stuge | 16 Nov 16:23 2015

Re: Understanding BIOS I/O Adresses

Please don't post disassembly of code from outside the project. Thanks.

panic wrote:
> I have some difficulties to understand what is done

Welcome to x86 firmware. Some day you may even grow to appreciate
that feeling.

> Is there a way to find out what these addresses are used for?

You have to look for a lot of different documentation, and piece
together the complete picture on your own.

Get Ralf Brown's interrupt list. It includes an IO port list with
some register explanations.

Also look at operating system programming documentation. This is 386
class hardware, read books about operating system programming on the
386 and on older hardware.

Writing a 386 operating system is also a good exercise to learn about
the hardware.

There are good IA-32 books from Intel. They're a couple thousand

> In particular I'm interested in 0x80, 0x84/0x85, 0x8c/0x8d.

From ports.lst:
PORT 0080-008F - DMA PAGE REGISTERS (74612)

0084  RW  extra page register
0085  RW  extra page register
008C  RW  extra page register
008D  RW  extra page register

So either something is being done with the DMA controller (seems
unlikely in early boot) or these registers have a completely
different meaning at that time in the platform lifecycle.

I would not expect that there is any good documentation about this.

Good luck and have fun!



coreboot mailing list: coreboot <at> coreboot.org