Re: IBM x60t test - DSDT is in fact incomplete

On 01.09.2014 22:08, Charles Devereaux wrote:
> Hello
Keep list CC'ed.
> Sorry for the late reply. Yesterday I tried acpi_debug with various
> values, but even with 0xFFFFFFFF I could not get logs similar to yours :
> [17493.249126] ACPI : EC: push gpe query to the queue
> [17493.249198] ACPI : EC: ===== TASK =====
> [17493.249207] ACPI : EC: ---> status = 0x28
> [17493.249213] ACPI : EC: <--- command = 0x84
> [17493.249293] ACPI : EC: ===== IRQ =====
> [17493.249306] ACPI : EC: ---> status = 0x09
> [17493.249316] ACPI : EC: ---> data = 0x5c
> [17493.249329] ACPI : EC: ---> status = 0x08
> Could you please tell me the cmdline you use, or the options you set in
> /sys to activate that kind of output?
> In any case, I will soon try your patch even if I could not check the
> output (I have a test motherboard where I added an ISP wiring)
> Thanks
> Charles
> On Tue, Aug 26, 2014 at 12:28 AM, Charles Devereaux
> <coreboot <at> guylhem.net <mailto:coreboot <at> guylhem.net>> wrote:
(Continue reading)

Charles Devereaux | 1 Sep 22:19 2014

x60 : adding WWAN support


I'm interested in WWAN support, mostly for the GPS features and the cool things you can do with them (like a stratum ntp server).

I was told a EM770W doesn't even need a network registration to output NMEA coordinates (http://forum.thinkpads.com/viewtopic.php?f=30&t=114426#p735612) so I got one.

I looked at patch #4056 which enable WWAN for the EC, but it seems to only part of the job: the ACPI table should also contain a GWAN key for thinkpad-acpi

In drivers/platform/x86/thinkpad_acpi.c, you can see different references to WAN:
        /* ACPI GWAN/SWAN bits */
        TP_ACPI_WANCARD_HWPRESENT       = 0x01, /* Wan hw available */
        TP_ACPI_WANCARD_RADIOSSW        = 0x02, /* Wan radio enabled */
        TP_ACPI_WANCARD_RESUMECTRL      = 0x04, /* Wan state at resume:
                                                   0 = disable, 1 = enable */

In wan_get_status :
        if (!acpi_evalf(hkey_handle, &status, "GWAN", "d"))
                return -EIO;

Apparently, this last part cause the WWAN card not to be handled by thinkpad-acpi, which would otherwise provide rfkill support (usefull to save power, something I'd like to improve)

In acpi-3.dsl Scope (\_SB.PCI0.LPC.EC.HKEY, I see entries for both GWAN and SWAN, and other things (WGPS, but what does it means???)

I believe similar entries should be added to coreboot asl, but I'm not sure of how integrated they should be. If I understand correctly, following the logic of patch #5242, there should be a conditional statement then some acpigen.

If anyone is willing to submit a patch, I would be happy to test it.


coreboot mailing list: coreboot <at> coreboot.org
The Gluglug | 1 Sep 00:01 2014

i945: 6718 PTE (page table error) report

A while ago I was asked by Paul to check if PTE errors still exist on
i945 (X60 tested here) related to i945 native graphics, when including
6718. That patch is now merged and I can confirm that they do still

Posting to list because it may be useful for others.


Snippet from kernel log:

Aug 31 22:50:24 minifree kernel: [    1.180448] vgaarb: device changed
decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
Aug 31 22:50:24 minifree kernel: [    1.180450] i915: render error
detected, EIR: 0x00000010
Aug 31 22:50:24 minifree kernel: [    1.180452] i915: page table error
Aug 31 22:50:24 minifree kernel: [    1.180454] i915:   PGTBL_ER:
Aug 31 22:50:24 minifree kernel: [    1.180457]
[drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
Aug 31 22:50:24 minifree kernel: [    1.180463]
[drm:i915_irq_handler], pipe B underrun
Aug 31 22:50:24 minifree kernel: [    1.180469] i915: render error
detected, EIR: 0x00000010
Aug 31 22:50:24 minifree kernel: [    1.180471] i915: page table error
Aug 31 22:50:24 minifree kernel: [    1.180473] i915:   PGTBL_ER:
Curt Brune | 29 Aug 01:08 2014

cbfstool, Linux trampoline and SeaBIOS

Hello -

First time poster, so take it easy on me :)

This is a great project -- I was able to get a kvm+coreboot+SeaBIOS
environment going pretty easily.  I started with the master branch of
coreboot and went from there.

I am having a problem trying to load a Linux kernel+initramfs cbfs
payload from SeaBIOS.  I can successfully boot the same
kernel+initramfs straight from coreboot (without SeaBIOS) as a

I started this topic on the SeaBIOS list -- there's a lot of good
background in the replies there:


I now think my problem lies in the cbfstool and the Linux trampoline.

Summarizing the analysis from those posts: the Linux trampoline code
does not set up the segment descriptors for __BOOT_CS and __BOOT_DS as
described in the Linux kernel documentation:

  ... a GDT must be loaded with the descriptors for selectors
  __BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G
  flat segment; __BOOT_CS must have execute/read permission, and
  __BOOT_DS must have read/write permission;

Now in the working coreboot case it turns out the segment descriptors
at selectors 0x10 and 0x18, setup in the coreboot ramstage, match what
the Linux kernel expects (see coreboot/src/arch/x86/lib/c_start.S).

In the non-working SeaBIOS case the segment descriptors are configured
differently and the cbfs Linux payload does not work.

If the cbfs Linux payload is to be used in multiple environments
should the trampoline take care of descriptors that Linux requires?

Attached is a patch to util/cbfstool/linux_trampoline.c that does just
that.  Basically I borrowed the descriptor configs from
coreboot/src/arch/x86/lib/c_start.S for selectors 0x10 and 0x18.

Apologies for my poor x86 assembly coding -- first time.

Attachment (linux_trampoline.patch): text/x-diff, 4194 bytes

coreboot mailing list: coreboot <at> coreboot.org
Todd Weaver | 27 Aug 23:16 2014

New board with unsupported cpu, chipset, and superIO

It appears (from following the instructions) that I have a new board
with unsupported cpu, chipset, and superIO.

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor DRAM Controller (rev 06)
00:1f.0 ISA bridge: Intel Corporation HM86 Express LPC Controller (rev

From this page:

It appears "If it is not supported by coreboot then you will have a lot
of work in front of you."

What I need to find out is:

a) If it is even possible to get coreboot to work with this board?
b) How much time would it take to get coreboot to work with this board?
c) If there is any coreboot developers that would be willing to contract
for hire to develop coreboot for this board?

It is a requirement to replace the bios with coreboot, so I am tasked
with making sure it is possible (a), a rough idea of how long (b), and
if we can hire somebody to develop it (c).

I appreciate any replies to any parts of the above, and I am hopeful
somebody would be able to have the time needed to get paid to get
coreboot onto this board.

Thank you!

Todd Weaver


coreboot mailing list: coreboot <at> coreboot.org

ron minnich | 27 Aug 18:43 2014

apologies in advance for a question I may have asked

I need to set up qemu with a 64MiB ROM.

I figure supporting EFI has made QEMU capable of such things, but if
anyone has direct experience with this, please let me know. I tried it
a few years back (2008) and it did not work at all ... I guess worst
case I can make an NE2000 "device" with a giant ROM, but I'd prefer to
just do it with a 64MiB device at top of 4GiB address space.




coreboot mailing list: coreboot <at> coreboot.org

Mike | 27 Aug 13:44 2014

for more working mainboards

treacherous computing, like amd trustzone...

... could spawn all over.  We have to stop this by giving end users more 
purchasing choice.

Someone suggested that fsf actually produce mainboards without it. 
Sounds like a plan.  Is fsf up to it?  Are they willing to sign NDAs?

If not, then we should start a company to do the mainboards.  Producing 
amd/intel/etc boards.

The current coreboot code would be fully applicable, and the mainboards 
would ship with coreboot.  At least, coreboot might disable trusted 
computing functionality.



coreboot mailing list: coreboot <at> coreboot.org

Wen Wang | 26 Aug 22:09 2014

Rangeley reset


Has anybody tested reset signal (PMU_RESETBUTTON_B) on Rangeley/Avoton? The
board seems to shut down after asserting the signal (pushing the reset
button). I turn on an LED in early_mainboard_romstage_entry(). The LED was
not on indicating the function was not executed. Below is what printed out
on console after reset:

coreboot-0f49404 Tue Aug 26 15:28:40 EDT 2014 starting...
POST: 0x41
POST: 0x42
Setting up static southbridge registers... done.
Disabling Watchdog timer... done.
RTC Init
POST: 0x46
POST: 0x47
Starting the Intel FSP (early_init)
Configure Default UPD Data
PcdEnableIQAT 1
PcdEnableLan 1
PcdEnableLan 1
PcdEnableLan 1
PcdEnableLan 1
PcdEnableUsb20 1
PcdEnableSata2 1
PcdEnableSata3 1
find_current_mrc_cache_local: No valid fast boot cache found.
FSP MRC cache not present.

For cold boot, it will continue to spit out boot messages.


-- Wen Wang


coreboot mailing list: coreboot <at> coreboot.org

ron minnich | 25 Aug 23:28 2014

disabling bios usb stack

A friend asks me how to disable the usb stack in his bios. I have no
clue, anyone?



coreboot mailing list: coreboot <at> coreboot.org

ron minnich | 25 Aug 19:44 2014


I'm utterly ignorant of the PSP -- is this thing like the Intel ME,
and how scared should we be of it?

Is it as closed off and mysterious?



coreboot mailing list: coreboot <at> coreboot.org

The Gluglug | 25 Aug 17:50 2014

bug report: i945 text-mode native graphics initialization: graphical corruption with starting Debian/Trisquel net installer.

Using 6725 to enable text-mode gfx init on X60 when using native
graphics initialization.

Affected machines: X60, T60.
It may also affect: macbook21/macbook11, X60 Tablet

This relies on the (merged) patch 6723 that enables text-mode graphics
initialization on i945 platforms. The code is there.

I then disabled "Keep VESA framebuffer" in menuconfig, to enable

error: no video mode activated
This is what I see when I try to use the net install iso for Debian
with the isolinux parser in grub.
I also saw the same thing when trying to start Trisquel 6 isolinux
menu from SeaBIOS (with SeaVGABIOS added at vgaroms/vgabios.bin from
seabios's rom that I built).

See attached image of what happens when I try to boot the net install
from Debian (same thing happens with the Trisquel net install), using
the following:
linux (usb0)/install.386/vmlinuz
initrd (usb0)/install.386/initrd.gz

As you can see, there is quite a lot of flicker and parts of the
screen are missing or corrupt. I think this is related to the issue
above ("error: no video mode activated").

The net install for Debian and Trisquel both work when using
corebootfb initialization method, but they fail (as seen in the image)
for text-mode method.

In case the attachment was scrubbed by the mailing list, I also put it

Trisquel graphical install works (I wasn't able to figure out how to
boot the Debian graphical install).

I also enabled it for T60 (adding the keep/drop vesa fb option for
t60/Kconfig, based on 6725, and cherry picking 5345) and the same
behaviour was observed there.

What does work in text-mode init (tested): memtest86+ and grub invaders.

coreboot mailing list: coreboot <at> coreboot.org