coreboot December 2014

coreboot@coreboot.org

33 participants
53 discussions

Re: [coreboot] SeaBIOS wit USB3.0 hub and USB3.0 devide behind the hub
by Kevin O'Connor 10 Dec '14

10 Dec '14

On Wed, Dec 10, 2014 at 09:44:06PM -0800, Julius Werner wrote: > This is a complicated case most firmware USB stacks don't support (I > don't have experience with SeaBIOS, but I know that both U-Boot and > libpayload won't work with that either). A USB 3.0 hub is essentially > two completely separate logical hubs connecting to two completely > separate logical ports on the host. The USB 3.0 part of the hub uses a > slightly different protocol (e.g. some bits in the port status have > different meanings) and from a quick glance the SeaBIOS code doesn't > seem to take that into account. I'm not sure where exactly it would > break, but one possibility is the speed detection (in USB 2.0 the port > status bits 9 and 10 indicate the speed, but in USB 3.0 it's implied > to always be SuperSpeed and those two bits indicate the link state and > the port power status instead). The speed is written in the XHCI Slot > Context for the device and using the wrong value there might cause > problems. Right, SeaBIOS does not currently have USB3 hub specific code. The USB3 spec has close to 100 pages on hubs, but much of it resembles the USB2 hub details and it's not immiediately clear which parts differ. BTW, please CC the seabios mailing list on emails. -Kevin

1 0

Re: [coreboot] Memory corruption on Resume from S3 Baytrail
by Gailu Singh 10 Dec '14

10 Dec '14

Problem resolved by reserving initial 64K memory. Thanks to Stefan for his help. On Wed, Dec 10, 2014 at 11:12 AM, Gailu Singh <gailu96(a)gmail.com> wrote: > Hi, > > In coreboot developer manual memory map section ( > http://www.coreboot.org/Developer_Manual/Memory_map) there is specific > mention of low memory. > > *0x00000 - 0x9FFFF*: Low 640kB. Should not be clobbered on S3 > suspend/resume (exceptions?) > > How do I tell Linux not to use this memory? I tried linux kernel argument > memap=640K@0x0 to reserve the space but my kernel does not boot with that. > > What changes are expected in Linux kernel configuration for S3 > suspend/resume to work smoothly with coreboot? > > > > > > On Sun, Nov 23, 2014 at 12:54 PM, Stefan Reinauer < > stefan.reinauer(a)coreboot.org> wrote: > >> On 11/19/14 11:36 AM, Gailu Singh wrote: >> >>> Hi Experts, >>> >>> I am using Baytrail SoC board (Bayleybay CRB) and testing suspend/resume >>> from Linux (kernel 3.10). I can suspend with pm-suspend and resume with >>> power button; however after resuming I get following logs in Linux >>> Corrupted low memory at c0001004 (1004 phys) = 0008eaea >>> Corrupted low memory at c0001008 (1008 phys) = b0606600 >>> ... >>> Corrupted low memory at c00018fc (18fc phys) = 000008ea >>> >>> This seems to be caused by coreboot as I do not see these logs if I use >>> BIOS instead of coreboot. >>> Is it true that during resume coreboot uses RAM portion already mapped >>> by Linux and thus corrupting it. How to I avoid the RAM conflict? >>> >> >> Looks like coreboot (or FSP) is overwriting this memory with some >> trampoline code. >> >> One (ugly) way to fix this would be to just reserve the space in the >> memory table. The better way would be to track down where this is actually >> happening and fix it there. >> >> Stefan >> > >

1 0

SeaBIOS wit USB3.0 hub and USB3.0 devide behind the hub
by Werner Zeh 09 Dec '14

09 Dec '14

Hi all. I have made some tests with SeaBIOS and XHCI and found, that on my board (which is baytrail-based) a USB3.0 hub won't work. For those who are familar with SeaBIOS I have attached two logfiles from SeaBIOS. One of them is with the USB3.0 flash drive directly connected to one of the root ports of SoC (in which case the boot process starts from the flash drive) and the other is with the same flash drive but a USB3.0 hub in between (I have used a hub from Delock #62534, http://www.delock.de/produkte/F_247_extern_62534/merkmale.html). In the hub-case, I see the "No bootable device" screen and no boot will happen. Maybe someone more experienced can see the cause from the logs. Werner

1 0

Re: [coreboot] Memory corruption on Resume from S3 Baytrail
by Stefan Reinauer 09 Dec '14

09 Dec '14

On 11/19/14 11:36 AM, Gailu Singh wrote: > Hi Experts, > > I am using Baytrail SoC board (Bayleybay CRB) and testing > suspend/resume from Linux (kernel 3.10). I can suspend with pm-suspend > and resume with power button; however after resuming I get following > logs in Linux > Corrupted low memory at c0001004 (1004 phys) = 0008eaea > Corrupted low memory at c0001008 (1008 phys) = b0606600 > ... > Corrupted low memory at c00018fc (18fc phys) = 000008ea > > This seems to be caused by coreboot as I do not see these logs if I > use BIOS instead of coreboot. > Is it true that during resume coreboot uses RAM portion already mapped > by Linux and thus corrupting it. How to I avoid the RAM conflict? Looks like coreboot (or FSP) is overwriting this memory with some trampoline code. One (ugly) way to fix this would be to just reserve the space in the memory table. The better way would be to track down where this is actually happening and fix it there. Stefan

2 1

#95: Run coreboot in VirtualBox
by coreboot 09 Dec '14

09 Dec '14

#95: Run coreboot in VirtualBox ---------------------------------+------------------------------------------ Reporter: uwe | Owner: somebody Type: defect | Status: new Priority: minor | Milestone: Component: misc | Version: Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ It would be nice if we could test coreboot images in VirtualBox, see http://virtualbox.org/. VirtualBox does not (yet) provide a simple mechanism to use a different BIOS in their emulated machines (something like "-L" in qemu). Instead the BIOS image (a custom bochs BIOS + LGPL'g VGABIOS) is converted to C code (an array of bytes, or the like) and merged into the VirtualBox executable. The relevant files are {{{ src/VBox/Devices/PC/DevPcBios.cpp bldprogs/bin2c.c }}} if someone want to hack VirtualBox to easily support using coreboot images instead of their usual BIOS. -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/95> coreboot <http://www.coreboot.org/>

2 8

Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
by Garreau, Alexandre 09 Dec '14

09 Dec '14

Le 09/12/2014 à 23h08, Charles Devereaux a écrit : > So basically it's only reading the TMOD field from the EC, but in > src/ec/lenovo/h8/acpi/ec.asl, I see MKHP, but no MKHG > > A simple fix will be to add MKHG > > Meanwhile, commenting out send_acpi_ev=false from hotkey_notify_usrevent > seems in thinkpad-acpi.c enough. Then acpi_listen will then see the > following events: > ibm/hotkey IBM0068:00 00000080 00005009 > ibm/hotkey IBM0068:00 00000080 0000500a > > (which can be mapped to screen rotation scripts) Oh wait, sorry if I only get the thread here and I lost the beginning, but, does that mean you found how to make screen position (tablet or laptop mode) finally detectable through ACPI? ’cos I still didn’t understand why it didn’t. If it’s the case, how much time it could take to have needed changes arriving to Debian testing? is there any way not implying to recompile the whole kernel to have them before? Correct me if I misinterpreted.

2 1

Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
by Charles Devereaux 09 Dec '14

09 Dec '14

Hello My mistake, after carefully checking, it's just the pen that's not giving anything at all ; however I am getting the exact same 5E and 5F for the screen rotation - but no ACPI event. For the pen, I'm not getting any event at all - even with the modified kernel with the original DSDT that previously gave me such events. Unless something weird happened, my best guess is that the pen detection switch is not correctly plugged. I'll have to check that later. Now about these tablet rotation, thinkpad-acpi expects a MHKG field in the dsdt to report them to the input layer (cf tpacpi_input_send_tabletsw) In the original DSDT, MHKG is: Method (MHKG, 0, NotSerialized) { Store (Zero, Local0) ShiftLeft (\_SB.PCI0.LPC.EC.HTAB, 0x03, Local0) Return (Local0) } So basically it's only reading the TMOD field from the EC, but in src/ec/lenovo/h8/acpi/ec.asl, I see MKHP, but no MKHG A simple fix will be to add MKHG Meanwhile, commenting out send_acpi_ev=false from hotkey_notify_usrevent seems in thinkpad-acpi.c enough. Then acpi_listen will then see the following events: ibm/hotkey IBM0068:00 00000080 00005009 ibm/hotkey IBM0068:00 00000080 0000500a (which can be mapped to screen rotation scripts) For the raw EC events: Dec 9 15:36:44 thinkpad kernel: [115080.081227] ACPI : EC: ===== TASK ===== Dec 9 15:36:44 thinkpad kernel: [115080.081232] ACPI : EC: ---> status = 0x28 Dec 9 15:36:44 thinkpad kernel: [115080.081235] ACPI : EC: <--- command = 0x84 Dec 9 15:36:44 thinkpad kernel: [115080.081276] ACPI : EC: ===== IRQ ===== Dec 9 15:36:44 thinkpad kernel: [115080.081280] ACPI : EC: ---> status = 0x09 Dec 9 15:36:44 thinkpad kernel: [115080.081284] ACPI : EC: ---> data = 0x5e Dec 9 15:36:44 thinkpad kernel: [115080.081290] ACPI : EC: ---> status = 0x08 Dec 9 15:36:44 thinkpad kernel: [115080.082262] ACPI : EC: push query execution (0x5e) on queue Dec 9 15:36:47 thinkpad kernel: [115082.603688] ACPI : EC: ===== TASK ===== Dec 9 15:36:47 thinkpad kernel: [115082.603692] ACPI : EC: ---> status = 0x28 Dec 9 15:36:47 thinkpad kernel: [115082.603695] ACPI : EC: <--- command = 0x84 Dec 9 15:36:47 thinkpad kernel: [115082.603734] ACPI : EC: ===== IRQ ===== Dec 9 15:36:47 thinkpad kernel: [115082.603739] ACPI : EC: ---> status = 0x09 Dec 9 15:36:47 thinkpad kernel: [115082.603743] ACPI : EC: ---> data = 0x5f Dec 9 15:36:47 thinkpad kernel: [115082.603749] ACPI : EC: ---> status = 0x08 Dec 9 15:36:47 thinkpad kernel: [115082.604711] ACPI : EC: push query execution (0x5f) on queue On Fri, Dec 5, 2014 at 7:37 AM, Charles Devereaux <coreboot(a)guylhem.net> wrote: > Hello > > For your information, this patch does not gives me any of these ACPI > events on the x60 tablet, so the patch may be specific to the X220t > > To correct the events value, I tried to replicate your events output with : > enable CONFIG_DYNAMIC_DEBUG > echo -n 'file ec.c +p' | sudo tee /sys/kernel/debug/dynamic_debug/control > > I still can't get logs similar to yours. > > I would love to make that work. Please let me know how I can report the > correct values. > > Thanks > Charles > > On Mon, Aug 25, 2014 at 5:02 PM, Vladimir 'φ-coder/phcoder' Serbinenko < > phcoder(a)gmail.com> wrote: > >> On 25.08.2014 22:53, Vladimir 'φ-coder/phcoder' Serbinenko wrote: >> >>> Ideally, the DSDT should be fixed within coreboot, but this goes >> beyond >> >>> my present abilities. >> >> Not true. Just do the same changes to the corresponding *.asl files in >> >> coreboot repo and send the patch to gerrit. Other than a layer of >> >> preprocessing, it's exactly the same code as you got from disassembly. >> >> >> > Sorry, I misread you. I thought that you extracted coreboot DSDT from >> > running system then patched it and used as custom DSDT. I'm going to >> > make few experiments on my x220t. >> > >> > >> This may interest you: >> On X220t >> stylus removal: >> [17424.931729] ACPI : EC: ===== TASK ===== >> [17424.931747] ACPI : EC: ---> status = 0x28 >> [17424.931755] ACPI : EC: <--- command = 0x84 >> [17424.931852] ACPI : EC: ===== IRQ ===== >> [17424.931865] ACPI : EC: ---> status = 0x09 >> [17424.931874] ACPI : EC: ---> data = 0x5d >> [17424.931885] ACPI : EC: ---> status = 0x08 >> >> So it's _Q5D >> >> Stylus reinsert: >> [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 >> >> So it's _Q5C >> >> Turning LID around: >> [17582.701907] ACPI : EC: push gpe query to the queue >> [17582.701979] ACPI : EC: ===== TASK ===== >> [17582.701987] ACPI : EC: ---> status = 0x28 >> [17582.701994] ACPI : EC: <--- command = 0x84 >> [17582.702075] ACPI : EC: ===== IRQ ===== >> [17582.702092] ACPI : EC: ---> status = 0x09 >> [17582.702096] ACPI : EC: ---> data = 0x5e >> [17582.702104] ACPI : EC: ---> status = 0x08 >> So it's _Q5E >> >> Back to laptop layout: >> [17590.610440] ACPI : EC: push gpe query to the queue >> [17590.610513] ACPI : EC: ===== TASK ===== >> [17590.610521] ACPI : EC: ---> status = 0x28 >> [17590.610527] ACPI : EC: <--- command = 0x84 >> [17590.610610] ACPI : EC: ===== IRQ ===== >> [17590.610620] ACPI : EC: ---> status = 0x09 >> [17590.610628] ACPI : EC: ---> data = 0x5f >> [17590.610641] ACPI : EC: ---> status = 0x08 >> so it's _Q5F >> >> Do you get the same events on X60t? >> >> From thinkpad-acpi.c: >> TP_HKEY_EV_TABLET_TABLET = 0x5009, /* tablet swivel up */ >> TP_HKEY_EV_TABLET_NOTEBOOK = 0x500a, /* tablet swivel down */ >> TP_HKEY_EV_PEN_INSERTED = 0x500b, /* tablet pen inserted >> */ >> TP_HKEY_EV_PEN_REMOVED = 0x500c, /* tablet pen removed */ >> >> So those are the values MHKP has to return. >> >> http://review.coreboot.org/6765 implements it. Please test. >> > >

1 0

PCIe PME vs ACPI Interrupt
by Gailu Singh 08 Dec '14

08 Dec '14

Hi Experts, I am working on S3 wakeup from PCIE WAKE Signal on Baytrail SOC (Bayleybay board) with Intel FSP. When I send WOL packet ACPI interrupt count does not increase though PCIe PME interrupt count increases. Can you please provide some pointers why I am not getting ACPI interrupt for the wake event? in /proc/interrupts, PCIe PME counter increments and acpi counter remains 0. 9: 0 0 IO-APIC-fasteoi acpi 103: 2 0 PCI-MSI-edge PCIe PME My Root Port ASL is below. Device (RP01) { Name (_ADR, 0x001c0000) Name (_PRW, Package (0x02) { 0x09, 0x03 }) Device (PXSX) { Name (_ADR, Zero) Name (_PRW, Package (0x02) { 0x09, 0x03 }) } Method (_PRT) { If (PICM) { Return (Package() { #undef PIC_MODE #include "irq_helper.h" PCI_DEV_PIRQ_ROUTE(0x0, A, B, C, D) }) } Else { Return (Package() { #define PIC_MODE #include "irq_helper.h" PCI_DEV_PIRQ_ROUTE(0x0, A, B, C, D) }) } } }

1 0

Re: [coreboot] rfkill equivalent on the X60 - first partial success
by Vladimir 'φ-coder/phcoder' Serbinenko 08 Dec '14

08 Dec '14

On 08.12.2014 01:00, Charles Devereaux wrote: > Sorry, but if it is like the X60 it can not be made the work. > > Just like in the WWAN slot, but in reverse, the USB lines are not wired > on the WLAN slot. > > IIRC this is not the case on the X201 (a very nice machine, but coreboot > support may not be as good for the moment. However the ACPI tables look > more complete.) > Please provide problem descriptions when doubting the quality of my work. Otherwise you're empty-talking.

2 1

questions about Rangerley
by Jack Zhao 07 Dec '14

07 Dec '14

Hi Mr. Coreboot J I am a software engineer. And I am studying the coreboot with a new project which will use the CPU Intel Rangerley. But from the supported list, I cannot find it. Could you please tell me how I can see that? Or you can share with me some link about it. Thanks very much for support in advance. Best Regards, Jack Zhao +86-21-58966996-81122

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2014