coreboot December 2014

coreboot@coreboot.org

33 participants
53 discussions

Re: [coreboot] rfkill equivalent on the X60 - first partial success
by Carl-Daniel Hailfinger 08 Dec '14

08 Dec '14

On 07.12.2014 04:31, Charles Devereaux wrote: > It can be powered, since in the X60 the WWAN port only has the USB lines > wired, so it's not much of a security problem for the PCI bus as long as it > is not connected to the USB bus where it could wake up from suspend and > pretend to be many different things. > > The hardware swich properly disconnects the bluetooth module from USB. It > would be nice to do the same for wwan, but I guess ec_access and echo -n > "suspend" are better than nothing. I plan to try and create a rfkill-wwan > kernel module doing just that. I tried to find some code example for the RCBA > but couldn't. Has anyone ever managed to get the USB lines on the T60 WLAN slot to work? I plugged in an Intel 7260 802.11ac + Bluetooth card, and it is reportedly using USB for bluetooth and PCIe for WLAN. My problem is that the Bluetooth part of the card doesn't even show up in lsusb. This thread made me wonder whether this is just an issue with broken rfkill. Regards, Carl-Daniel

2 1

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

07 Dec '14

> > To emulate rfkill functionality, just write directly to the ec, for ex > > to turn on wwan and wifi: > > ./ec_access -w 0x3a -v 0x60 > > > Usecase? > > > Example: I have a wwan card, but I mostly use it for GPS. I can save > some power by turning it off without rebooting, while keeping wifi on with: I'd like to see some real figures on power saved between idle wwan and disabled wwan, I really doubt it's anything noticeable > The hardware button is not safe enough : register 0x3A hasthe H/W > Override bitto "enable to control wireless devices even if the global > WAN disable switch is ON". Disabling the USB ports through the RCBA > registers (nice idea!) would prevent such an override. > > Also, it would save more power on the wwan that the hardware button : > the wwan module is not fully desactivated since it replies to AT commands > > Several persons do not fully trust a wwan module. Physically removing it > is the solution suggested. Disabling the usb port would be a simpler > solution for those than do not want to physically open their laptop yet > do not trust the hardware button due to the override bit. > wwan module is powered unconditionally. So if you don't trust it - remove it. Also none of disables discussed here is irreversible if you're concerned about rogue software. > It seems to have several usecase. None of them looks valid

2 1

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

07 Dec '14

On 03.12.2014 23:32, Charles Devereaux wrote: > Hello > > As explained before, thinkpad-acpi can't control the non-wifi radio like > bluetooth or wwan, because it expects some ACPI entries that aren't > there - so there is no rfkill control for these, even if some > non-working entries are shown with 'rfkill list' > You have a hardware button to do an rfkill. I don't see why software should mess more with this. > To emulate rfkill functionality, just write directly to the ec, for ex > to turn on wwan and wifi: > ./ec_access -w 0x3a -v 0x60 > Usecase? > It works great for bluetooth, basically "physically unplugging" the > device so that if you have uhci_hcd as a module, an rmmod/modprobe will > no longer show the device on lsusb. > RCBA registers can disable any USB ports. But again: usecase?

1 0

Re: [coreboot] kernel boot time down to ~1.5 second on the x60 with i915.fastboot success
by Charles Devereaux 05 Dec '14

05 Dec '14

Hello Here is the dmesg, and the kernel .config. Kernel boot comes down to 1.54s indeed during a simple test with just the bzimage (I have to setup again an optimized distribution for these tests) The command-line I now suggest is : i915.fastboot=1 i915.lvds_downclock=1 i915.i915_enable_rc6=7 nohz=on nmi_watchdog=0 pcie_aspm=force thinkpad_acpi.force_load=1 thinkpad_acpi.brightness_enable=0 thinkpad_acpi.fan_control=1 snd-hda-intel.index=0 snd_hda_intel.power_save=10 snd_hda_intel.model=thinkpad snd-hda-intel.probe_mask=0x103 snd-pcsp.index=1 btusb.reset=1 i915.i915_enable_fbc=1 is not safe : it causes screen corruption on resume PS: I was told that these 2 patches allowed fastboot with a "close enough" mode, even if timings didn't match: http://lists.freedesktop.org/archives/intel-gfx/2014-October/053501.html http://lists.freedesktop.org/archives/intel-gfx/2014-October/053502.html I haven't used them though, so I can't comment on that, but they are a more elegant solution for sure :-) On Fri, Dec 5, 2014 at 2:44 AM, Charles Devereaux <coreboot(a)guylhem.net> wrote: > Hello > > i915.fastboot can be made to work on the x60, shaving about 0.8s from boot > (and removing the annoying blinking screen) > > Since coreboot doesn't select the same video mode the kernel does, the > easiest way to make that work is to comment out request for a mode change > when the modes are different: in > linux-3.14.25/drivers/gpu/drm/i915/intel_display.c comment out on line > 9879: config->mode_changed = true; so that it looks like: > if (set->mode && !drm_mode_equal(set->mode, &set->crtc->mode)) { > DRM_DEBUG_KMS("modes are different, full mode set\n"); > drm_mode_debug_printmodeline(&set->crtc->mode); > drm_mode_debug_printmodeline(set->mode); > // config->mode_changed = true; > } > > It's hackish, but the results are worth it! > > It was tested with a vanilla kernel 3.14.25 with the following kernel > options: > i915.lvds_downclock=1 i915.semaphores=1 i915.i915_enable_rc6=7 > i915.i915_enable_fbc=1 nohz=on nmi_watchdog=0 pcie_aspm=force > thinkpad_acpi.force_load=1 thinkpad_acpi.brightness_enable=0 > thinkpad_acpi.fan_control=1 snd-hda-intel.index=0 > snd_hda_intel.power_save=10 snd_hda_intel.model=thinkpad > snd-hda-intel.probe_mask=0x103 snd-pcsp.index=1 btusb.reset=1 > i915.fastboot=1 > > I'm also using the latest libreboot without ACPI brightness (coreboot head > 8ffc085e1affaabbe3dca8ac6a89346b71dfc02e with patches 6725 7048 5345 7050 > 7051) with CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT and > CONFIG_FRAMEBUFFER_KEEP_VESA_MODE. > > Grub.cfg has: > set gfxpayload=keep > terminal_output --append gfxterm > > The first results I posted on the list were a kernel boot in about 2.2s. I > should now be around 1.5s. I will prepare a static kernel and post the > .config and dmesg for precise measurements in case anyone is interested in > replicating the results. > > I believe further improvements could be made to go below the psychological > 1 second mark: now that I have received my 128 MB SPI chips (25Q128FVSG : > cf > http://www.ebay.com/itm/New-WINBOND-IC-Chip-FLASH-128M-BIT-25Q128FVSG-W25Q1…) > , I'll see if fitting a bzImage is helpful. > > Charles >

1 0

Re: [coreboot] IBM x60t test - DSDT is in fact incomplete
by Vladimir 'φ-coder/phcoder' Serbinenko 05 Dec '14

05 Dec '14

On 25.08.2014 04:39, Charles Devereaux wrote: > Hello > > Previously > (http://www.coreboot.org/pipermail/coreboot/2014-July/078320.html) I > mentioned that 3 bugs seemed to be related to the DSDT: > - missing ACPI events when the stylus is inserted/removed How is the OS supposed to react to them? > - errors when trying to make the leds blink with tpacpi details? usecase? > - errors during TPM initialization Some people here would call it a feature. > 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.

2 4

systemd script for resume with the fallback mechanism
by Charles Devereaux 05 Dec '14

05 Dec '14

Hello The wiki says such a script is missing. Here's a simple one that works so that you resume to the same version of coreboot. It basically sets the boot to normal before sleep, unless we are in fallback (since doing so would then prevent resume). To play it safe, it does the same on resume. Charles $ cat /etc/systemd/system/coreboot-sleep.service [Unit] Description=Make sure coreboot resumes with the correct version Before=sleep.target StopWhenUnneeded=yes [Service] Type=oneshot RemainAfterExit=yes # on resume is not really necessary, we just play safe ExecStart=/ibm/coreboot.sh # before sleep is totally necessary ExecStop=/ibm/coreboot.sh [Install] WantedBy=sleep.target $ cat /ibm/coreboot.sh #!/bin/bash if cbmem -c |grep fallback; then /bin/echo "WARNING: not setting nvram options to preserve sleep mode" else # cbmem and the cmos.layout are lost on resume /usr/local/bin/nvramtool -y /ibm/cmos.layout -w boot_option=Normal /usr/local/bin/nvramtool -y /ibm/cmos.layout -w last_boot=Normal /usr/local/bin/nvramtool -y /ibm/cmos.layout -w reboot_bits=0 fi Suggestion : replace CBET4000 by different strings for normal/fallback to access it with dmidecode, as my cbmem is emptied after a resume (hence the -y with cmos.layout). An alternative is to save cbmem -c output to a file after each boot Charles

1 0

kernel boot time down to ~1.5 second on the x60 with i915.fastboot success
by Charles Devereaux 05 Dec '14

05 Dec '14

Hello i915.fastboot can be made to work on the x60, shaving about 0.8s from boot (and removing the annoying blinking screen) Since coreboot doesn't select the same video mode the kernel does, the easiest way to make that work is to comment out request for a mode change when the modes are different: in linux-3.14.25/drivers/gpu/drm/i915/intel_display.c comment out on line 9879: config->mode_changed = true; so that it looks like: if (set->mode && !drm_mode_equal(set->mode, &set->crtc->mode)) { DRM_DEBUG_KMS("modes are different, full mode set\n"); drm_mode_debug_printmodeline(&set->crtc->mode); drm_mode_debug_printmodeline(set->mode); // config->mode_changed = true; } It's hackish, but the results are worth it! It was tested with a vanilla kernel 3.14.25 with the following kernel options: i915.lvds_downclock=1 i915.semaphores=1 i915.i915_enable_rc6=7 i915.i915_enable_fbc=1 nohz=on nmi_watchdog=0 pcie_aspm=force thinkpad_acpi.force_load=1 thinkpad_acpi.brightness_enable=0 thinkpad_acpi.fan_control=1 snd-hda-intel.index=0 snd_hda_intel.power_save=10 snd_hda_intel.model=thinkpad snd-hda-intel.probe_mask=0x103 snd-pcsp.index=1 btusb.reset=1 i915.fastboot=1 I'm also using the latest libreboot without ACPI brightness (coreboot head 8ffc085e1affaabbe3dca8ac6a89346b71dfc02e with patches 6725 7048 5345 7050 7051) with CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT and CONFIG_FRAMEBUFFER_KEEP_VESA_MODE. Grub.cfg has: set gfxpayload=keep terminal_output --append gfxterm The first results I posted on the list were a kernel boot in about 2.2s. I should now be around 1.5s. I will prepare a static kernel and post the .config and dmesg for precise measurements in case anyone is interested in replicating the results. I believe further improvements could be made to go below the psychological 1 second mark: now that I have received my 128 MB SPI chips (25Q128FVSG : cf http://www.ebay.com/itm/New-WINBOND-IC-Chip-FLASH-128M-BIT-25Q128FVSG-W25Q1…) , I'll see if fitting a bzImage is helpful. Charles

1 0

coreboot - coreinfo - make menuconfig - fails
by Bucsi Andor 04 Dec '14

04 Dec '14

Hi All, I have the same problem, any idea? Thanks/BR,Andor Picon Re: coreboot - coreinfo - make menuconfig - fails Hi All, I wam trying to build coreboot with coreinfo as payload for qemu platform. I am getting the followingerror whe i try to launch make menuconfig from coreinfo directory. I have synced the latest code from git repository /home/harish/opensource/coreboot/payloads/coreinfo/util/kconfig/lxdialog/dialog.h:22:19: fatal error: fcntl.h: No such file or directory-bash: /home/harish/opensource/coreboot/payloads/coreinfo/util/kconfig/lxdialog/dialog.h:22:19:: No such file or directoryharish <at> ubuntubc-OptiPlex-9010:~/opensource/coreboot/payloads/coreinfo$ #include <fcntl.h>harish <at> ubuntubc-OptiPlex-9010:~/opensource/coreboot/payloads/coreinfo$ ^ Any pointers on how to resolve this issue will be of great help RegardsHarish-- http://www.coreboot.org/mailman/listinfo/coreboot

2 2

Adding cycle count to battery.asl on the x60
by Charles Devereaux 04 Dec '14

04 Dec '14

Hello Cycle count are not reported in /proc/acpi/battery/BAT0/info Apparently, this is due to omitting SBCC in the DSDT. If the h8 is close enough to the it8518 (which seems to be the case), then the following should apply: // // Battery Information ID : 01/11 // Field (ERAM, ByteAcc, NoLock, Preserve) { Offset(0xA0), // Battery Mode(w) , 15, SBCM, 1, // bit 15 - CAPACITY_MODE // 0: Report in mA/mAh ; 1: Enabled SBMD, 16, // Manufacture Data SBCC, 16, // Cycle Count } In Lenovo original DSDT, I see a similar SBCC field at this same position, so this is very plausible. In battery.asl I only see: /* PAGE == 0x01 */ Field (ERAM, ByteAcc, NoLock, Preserve) { Offset(0xa0), , 15, BAMA, 1, } I believe adding : BMAN, 16 BCYC, 16 woud read the value, but then I do not know where to display them. In drivers/acpi/battery.c, I see : static enum power_supply_property energy_battery_props[] = { POWER_SUPPLY_PROP_STATUS, POWER_SUPPLY_PROP_PRESENT, POWER_SUPPLY_PROP_TECHNOLOGY, POWER_SUPPLY_PROP_CYCLE_COUNT, POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN, POWER_SUPPLY_PROP_VOLTAGE_NOW, POWER_SUPPLY_PROP_POWER_NOW, POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN, POWER_SUPPLY_PROP_ENERGY_FULL, POWER_SUPPLY_PROP_ENERGY_NOW, POWER_SUPPLY_PROP_CAPACITY, POWER_SUPPLY_PROP_MODEL_NAME, POWER_SUPPLY_PROP_MANUFACTURER, POWER_SUPPLY_PROP_SERIAL_NUMBER, }; Basically, it seems the order of the fields is important, and that BCYC should be added just befofore design voltage. It battery.asl, it seems to be handled by Method(BINF, 2, NotSerialized), and design voltage is BADV: BADV, 16, /* Design voltage */ So I first thought I would add BCYC just after: Store(BADV, Index(Arg0, 4)) // Design Voltage Store(BCYC, Index(Arg0, 3)) // Cycle count But Method(BINF, 2, NotSerialized) seems to be for static information, so I guess I should add that instead to Method(BSTA, 4, NotSerialized) BAVO is voltage now, so I guess I should add BCYC at 2 item before BAVO, yet I see : (...) } else { Store(BARC, Index(Arg1, 2)) Store(Local2, Index(Arg1, 1)) } Store(BAVO, Index(Arg1, 3)) So Arg1,1 is already used by Local2, which contains BAPR (present rate), so I'm stuck. It seems very illogical - there should be an empty field instead of the missing BCYC. Where exactly am I making a mistake here? Thanks Charles

1 0

rfkill equivalent on the X60 - first partial success
by Charles Devereaux 03 Dec '14

03 Dec '14

Hello As explained before, thinkpad-acpi can't control the non-wifi radio like bluetooth or wwan, because it expects some ACPI entries that aren't there - so there is no rfkill control for these, even if some non-working entries are shown with 'rfkill list' My initial plan was to add these missing ACPI entries so that thinkpad-acpi could be used, but I wanted to understand first what was happening. Some documents mention things like /proc/acpi/ibm/ecdump, but it was removed from the kernel several years ago. I found a very simple and practical workaround involving : - ec_access.c from https://github.com/linux-wpan/linux-wpan-next/blob/master/tools/power/acpi/… - ec-sys kernel module (compile with option CONFIG_ACPI_EC_DEBUGFS) so that you have /sys/kernel/debug/ec/ec0/io To emulate rfkill functionality, just write directly to the ec, for ex to turn on wwan and wifi: ./ec_access -w 0x3a -v 0x60 For the last code, if you want to do something else, please use the following table: 00 : nothing 10 : bluetooth 20 : wifi 30 : wifi + bluetooth 40 : wwan 50 : wwan + bluetooth 60 : wifi + wwan 70 : wifi + bluetooth + wwan This is essentially similar to what coreboot did in src/ec/lenovo/h8/h8.c at boot-time: static void h8_bluetooth_enable(int on) { if (on) ec_set_bit(0x3a, 4); else ec_clr_bit(0x3a, 4); } void h8_wlan_enable(int on) { if (on) ec_set_bit(0x3a, 5); else ec_clr_bit(0x3a, 5); } static void h8_wwan_enable(int on) { if (on) ec_set_bit(0x3a, 6); else ec_clr_bit(0x3a, 6); } However, it works without requiring a reboot or some specific support from within coreboot (ie cmos.layout etc). It will also toggle the LEDs. It works great for bluetooth, basically "physically unplugging" the device so that if you have uhci_hcd as a module, an rmmod/modprobe will no longer show the device on lsusb. However, for wwan, it's not that good: it's just like a soft rfkill: with a huawei modem, you will still see the device plugged, only AT^RFSWITCH? will tell that it's offline (ie that at+cfun=0) Based on my understanding, this only toggles pin 20 ("wireless disable") of the MINI PCIe, while ideally the card should no longer be powered at all or software accessible. Based on what I've read on forums where window users talked about wwan problems, in ibm bios there's an option to disable wwan, so that windows doesn't even detect it - which lets me think a wouldn't show in lsusb. In the DSDT I see other commands, so maybe it's necessary to issue further requests to the EC. I really don't know much about the EC (cf next message) Meanwhile, if someone has a x60 having a factory-installed wwan (because of whitelist issues), it'd be nice to see if (and how) the default bios can fully disable it: if the wwan is not showing in lsusb, it might mean something better is possible. a dump from ec_access with vs without wwan would then be quite interesting. Anyway, I know my solution is hackish (so I don't think it should be posted on the wiki), but it's a good start to provide limited functionality to a coreboot user: a proper hardware rfkill for bluetooth and a software rfkill for wwan, which is better than nothing at all. I'll try to create a kernel module that would expose a rfkill interface to control that, so that the rfkill state is restored after a resume. PS: about the wwan port, it can be used to do very interesting things :-) Improving ntpd accuracy using a wwan module with GPS works for the NMEA part! For further accuracy improvements, I just can't get the PPS yet, but it's already quite interesting :-). Also, early tests with my cheap huawei card suggest it can produce an audio stream for freeswitch using gsmopen module) Charles

1 0

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