coreboot September 2014

coreboot@coreboot.org

51 participants
90 discussions

Re: [coreboot] How to translate a PCI_DEV macro to struct device (device_t)?
by Patrick Georgi 04 Sep '14

04 Sep '14

Hi Ricardo, Am 04.09.2014 um 21:57 schrieb Ricardo Menzer: > I'm trying to port an old Intel version of coreboot for tunnelcreek to > a newer version of the coreboot code. I think that's the first time I hear about such a thing. What's up with that? :-) > I looked at the source code and in the mailing list, but couldn't find > a way to pass a correct dev parameter to the function. src/include/device/device.h provides a couple of dev_find_* functions. For bdf->device_t, dev_find_slot(bus, devfn) should be helpful. Regards, Patrick

1 0

How to translate a PCI_DEV macro to struct device (device_t)?
by Ricardo Menzer 04 Sep '14

04 Sep '14

Hi guys, I'm trying to port an old Intel version of coreboot for tunnelcreek to a newer version of the coreboot code. I'm stuck at a point in which the boot stops at get_pbus(device_t dev) because dev is NULL (0x0). I think the problem is in a function that calls pci_write_config32, but using PCI_DEV(0,0,0) to access the bus 0, device 0, function 0. PCI_DEV(0,0,0) evaluates to 0x0, which get_pbus interprets as a NULL pointer. This is used in the 'dev' parameter of pci_write_config32. I looked at the source code and in the mailing list, but couldn't find a way to pass a correct dev parameter to the function. I'm also not so sure I am in the right path. I may be confusing thing a little, since I'm no so experienced in x86 hardware and firmware levels. I'm also learning coreboot at my own, it's a lot of information at the same time being pushed at my brain! ;) I appreciate any help and clarifications! Thank you very much! Ricardo Menzer ricardomenzer(a)gmail.com +55 (32) 8865-8805

1 0

[RFC] Gerrit: Please enable sticky scores for trivial rebases and no code changes
by Paul Menzel 04 Sep '14

04 Sep '14

Dear coreboot folks, on IRC I was told, developers won’t update or fix commit messages as long as it means +2 scores are removed. Luckily Gerrit supports that [2]. A useful feature on labels is the possibility to automatically copy scores forward to new patch sets if it was a trivial rebase or if there was no code change (e.g. only the commit message was edited). I propose to enable these two features. If nobody opposes until next Monday, September 8th, it’d be great if the two config parameters below could be set to true. 1. label.Label-Name.copyAllScoresOnTrivialRebase [3] 2. label.Label-Name.copyAllScoresIfNoCodeChange [4] Thanks, Paul [1] http://review.coreboot.org/Documentation/intro-project-owner.html#labels [2] http://review.coreboot.org/Documentation/intro-project-owner.html#labels [3] http://review.coreboot.org/Documentation/config-labels.html#label_copyAllSc… [4] http://review.coreboot.org/Documentation/config-labels.html#label_copyAllSc…

3 2

Re: [coreboot] cbfstool, Linux trampoline and SeaBIOS
by Curt Brune 04 Sep '14

04 Sep '14

Hello Ron, On Wed Sep 03 18:26, ron minnich wrote: > Curt, thanks for those patches. You are welcome. > > I need to do the following: build a more recent kernel with a .config > with minimal drivers at this point, but not modules; x86_64; and then > make it a payload. I did not quite find the ONIE page that describes > this; any hints? The default virtual machine build of ONIE should be just what you need. Minimal drivers, everything compiled in. The default ONIE kernel is 3.14.x, pretty recent. You can read about it here: https://github.com/opencomputeproject/onie/blob/master/machine/kvm_x86_64/I… Summarizing, to build the kernel and initramfs: $ git clone https://github.com/opencomputeproject/onie.git $ cd onie/build-config $ make -j8 all [ takes a while (20+ minutes), first builds toolchain and then the rest ] The output is in onie/build/images: $ ls -l ../build/images: [ ... ] -rw-r--r-- 1 curt Development 5368352 Aug 19 10:24 kvm_x86_64-r0.initrd -rw-r--r-- 1 curt Development 3117088 Aug 19 10:22 kvm_x86_64-r0.vmlinuz Then my coreboot .config has: CONFIG_PAYLOAD_LINUX=y CONFIG_PAYLOAD_FILE="<ABSOLUTE_PATH_TO>/kvm_x86_64-r0.vmlinuz" CONFIG_LINUX_INITRD="<ABSOLUTE_PATH_TO>/kvm_x86_64-r0.initrd" CONFIG_LINUX_COMMAND_LINE="console=tty0 console=ttyS0,115200n8" I use the serial console from qemu, hence the console=ttyS0,115200n8 settings. > > Very cool stuff. It's nice to see someone wrapping it up and making it go :) I should write a proper wiki page or blog entry about the whole thing end-to-end. Cheers, Curt

1 0

Re: [coreboot] cbfstool, Linux trampoline and SeaBIOS
by ron minnich 04 Sep '14

04 Sep '14

Curt, thanks for those patches. I need to do the following: build a more recent kernel with a .config with minimal drivers at this point, but not modules; x86_64; and then make it a payload. I did not quite find the ONIE page that describes this; any hints? Very cool stuff. It's nice to see someone wrapping it up and making it go :) ron

1 0

Re: [coreboot] [RFC] Gerrit: Please enable sticky scores for trivial rebases and no code changes
by David Hendricks 03 Sep '14

03 Sep '14

On Wed, Sep 3, 2014 at 8:46 AM, Vadim Bendebury <vbendeb(a)chromium.org> wrote: > Note that the version of gerrit used for chromeos allows editing the > commit message through the web interface, no need to re-upload the > patch, and the scores are kept. > > Not sure if this is available in the coreboot gerrit though. > Yes, it is. I happen to think that is sufficient to accomplish what Paul is asking w.r.t. fixing commit messages. But I also like the idea of keeping scores for trivial rebases and no code change as well. There's no sense in having to wait for somebody to re-approve a patch for such things. > > --vb > > > On Wed, Sep 3, 2014 at 12:39 AM, Paul Menzel > <paulepanter(a)users.sourceforge.net> wrote: > > Dear coreboot folks, > > > > > > on IRC I was told, developers won’t update or fix commit messages as > > long as it means +2 scores are removed. > > > > Luckily Gerrit supports that [2]. > > > > A useful feature on labels is the possibility to automatically > > copy scores forward to new patch sets if it was a trivial rebase > > or if there was no code change (e.g. only the commit message was > > edited). > > > > I propose to enable these two features. > > > > If nobody opposes until next Monday, September 8th, it’d be great if the > > two config parameters below could be set to true. > > > > 1. label.Label-Name.copyAllScoresOnTrivialRebase [3] > > 2. label.Label-Name.copyAllScoresIfNoCodeChange [4] > > > > > > Thanks, > > > > Paul > > > > > > [1] > http://review.coreboot.org/Documentation/intro-project-owner.html#labels > > [2] > http://review.coreboot.org/Documentation/intro-project-owner.html#labels > > [3] > http://review.coreboot.org/Documentation/config-labels.html#label_copyAllSc… > > [4] > http://review.coreboot.org/Documentation/config-labels.html#label_copyAllSc… > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > http://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

Re: [coreboot] New board with unsupported cpu, chipset, and superIO
by ron minnich 02 Sep '14

02 Sep '14

On Fri, Aug 29, 2014 at 7:39 AM, ron minnich <rminnich(a)gmail.com> wrote: > Just a word to whoever does this next: figure out your firmware > picture first, THEN pick the hardware. It's never been a good idea to > start the other way around. Actually, I said that not quite correctly. If you want to do open source firmware based boards, and you don't want to spend too long on it, or fail in the process: 1. decide which firmware you want 2. pick a chipset 3. buy an off-the-shelf board which has that chipset 4. make sure you can get your open source firmware going on that board; if not, go to 1. 5. THEN design your own board Notice how I did not say anywhere in here "ask the chipset vendor if they will support blob-free coreboot development on your chipset"? There's a reason. Left as an exercise for the reader. Let's just say that we have seen, many times, that chipset salesmen are often ready to promise more than the chipset company will deliver. ron

1 0

Re: [coreboot] x60 : adding WWAN support
by Vladimir 'φ-coder/phcoder' Serbinenko 01 Sep '14

01 Sep '14

On 01.09.2014 22:19, Charles Devereaux wrote: > Hello > > 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). > Most GPS receivers don't have enough precision for any timing. > 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 > Not necessary. > 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) Soft rfkill is always available through wwan driver. > 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. > 5242 is very special because of wacom tablet interaction (serial device naming) See src/ec/lenovo/h8/acpi/ec.asl and included files for the relevant scopes

2 1

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

01 Sep '14

On 01.09.2014 22:08, Charles Devereaux wrote: > Hello > Keep list CC'ed. https://wiki.ubuntu.com/Kernel/Reference/ACPITricksAndTips > 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(a)guylhem.net <mailto:coreboot@guylhem.net>> wrote: > > (offlist reply) > > Hello > > Very interesting, indeed, but I need to use my X60t tomorrow (and I > already bricked it once while trying some simple coreboot patch so > I'd rather not take any risk :-) > > However I will try to test that as soon as possible and let you > know, tomorrow night or wednesday. > > I will also report you the ACPI EC results. > > Did you only had to activate CONFIG_ACPI_DEBUG to get these logs? > > Thanks > Charles > > > > On Mon, Aug 25, 2014 at 5:02 PM, Vladimir 'φ-coder/phcoder' > Serbinenko <phcoder(a)gmail.com <mailto:phcoder@gmail.com>> wrote: > > On 25.08.2014 22 <tel:25.08.2014%2022>: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. > > >

2 1

x60 : adding WWAN support
by Charles Devereaux 01 Sep '14

01 Sep '14

Hello 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. 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 September 2014