coreboot June 2015

coreboot@coreboot.org

41 participants
76 discussions

push error (not Signed-off-by author/committer/uploader in commit message footer)
by WANG Siyuan 05 Jun '15

05 Jun '15

Hi, I push code as normal, but I got this error: $ git push Counting objects: 27, done. Delta compression using up to 4 threads. Compressing objects: 100% (15/15), done. Writing objects: 100% (15/15), 3.56 KiB, done. Total 15 (delta 13), reused 0 (delta 0) remote: Resolving deltas: 100% (13/13) remote: Processing changes: refs: 1, done To ssh://Siyuan@review.coreboot.org:29418/coreboot ! [remote rejected] HEAD -> refs/for/master (not Signed-off-by author/committer/uploader in commit message footer) error: failed to push some refs to 'ssh://Siyuan@review.coreboot.org:29418/coreboot' My commit message is: commit 9df9e354dee0f07569adfd69976d27e30fd99710 Author: WANG Siyuan <wangsiyuanbuaa(a)gmail.com> Date: Fri Jun 5 13:22:44 2015 +0800 update submodule when 'make' rather than 'make menuconfig' 'git submodule update --init' runs before 'make menuconfig'. This is very inconvenience when developing. CONFIG_USE_BLOBS is used to control updating submodule, but the original command is wrong. With this patch, people can choose 'Allow use of binary-only repository' if they want to update submodule. Change-Id: I4b49f9b0d258ba22a006b6e669bf7fa016ecd76c Signed-off-by: WANG Siyuan <SiYuan.Wang(a)amd.com> Signed-off-by: WANG Siyuan <wangsiyuanbuaa(a)gmail.com> What is the problem? Thanks a lot.

1 0

Re: [coreboot] Fwd: Coreboot T-shirts
by Vladimir 'φ-coder/phcoder' Serbinenko 04 Jun '15

04 Jun '15

Good news: now it's possible to have them in black as well. I received up to now only one request to which I replied by personal mail. If you didn't receive any reply, please resend your request. Please specify in request the size, color (white, black, few other colors if someone is interested), quantity and if you want it single or double-sided printing. Please tell me until Friday. @Carl-Daniel: Still waiting for that PDF. On 21.05.2015 15:41, Vladimir 'phcoder' Serbinenko wrote: > Apparently original mail didn't make it to the list. Resent > > > ---------- Forwarded message ---------- > From: Vladimir 'phcoder' Serbinenko <phcoder(a)gmail.com> > Date: Thu, May 21, 2015 at 2:29 PM > Subject: Re: [coreboot] Coreboot T-shirts > To: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> > Cc: coreboot <coreboot(a)coreboot.org> > > > > Le 21 mai 2015 13:01, "Carl-Daniel Hailfinger" > <c-d.hailfinger.devel.2006(a)gmx.net> a écrit : >> >> On 21.05.2015 12:51, Vladimir 'phcoder' Serbinenko wrote: >>> A contact of mine proposes to print coreboot T-shirts for the community. >>> Black printing on white T-shirt. Expected price is 30€-35€ + shipping from >>> CH or DE, double-sided printing, one-sided is 5-8€ less. It will be printed >>> in Russia. >> >> Please note that the coreboot T-Shirt I am wearing is black, with the >> logo being a white plastic foil melted/glued to the t-shirt. >> Could you ask your contact whether such a variant would be possible as >> well? The foil variant is extremely durable and IMHO a black T-Shirt >> fits a bit better with all the other hacker culture T-Shirts. >> > I already did. Unfortunately it's not possible at this point >>> I need to know who wants one and sizes by June 5th. For payment >>> I accept paypal and bank wiring. >>> It will be available in ~August. Do we have some kind of dev meeting in >>> autumn where I could bring them? >>> @carldani: could you give me the file used for printing? >> >> Sure. >> >> Regards, >> Carl-Daniel > >

3 3

coreboot community chat
by Stefan Reinauer 04 Jun '15

04 Jun '15

Hi coreboot community! In order to have more face time and a more personal connection with each other than it is possible on the coreboot IRC channel, I would like to invite you to participate in a monthly video conference to discuss the up and coming projects, ideas and issues that all of us are involved in. We suggest to have these meetings via Google Hangouts, as we have figured out in the past that other alternatives like Mumble didn’t work as well for us. So I would like to invite interested contributors of the community to join us. The first video conference will be on Thursday, May 21th at 9:15am Pacific Time (16:15 UTC). The meeting can be joined by clicking on this link: http://goo.gl/SD6t3G. If, for some reason you can not access Hangouts, we can try and call you (no promises). Please let me know ahead of time if you need assistance! The agenda for the first meeting is available here: http://goo.gl/7E0zYz Looking forward to seeing y’all! Stefan

2 3

MCP-55 IOAPIC Strangeness
by Nick 04 Jun '15

04 Jun '15

Hi guys, I have an MCP-55 system with two IOAPICs: IOAPIC 4 @ PCI 00:01.0 IOAPIC 5 @ PCI 40:01.0 The first strange thing I see is when IOAPIC 4 is initilized and it says: 1. IOAPIC: Initializing IOAPIC at 0x00000000" Does this seem strange to anyone that it's initializing at 0x00000000? Should I be seeing this at 0xfec00000? (which is the address the registers are mapped to under the vendor bios) The next strange thing is when APIC 5 is initilized and spits out a bunch of register values - I think this is expected, but IOAPIC 4 doesn't spit out many register values? They are both MCP55 APICs. The this irregular thing is when using the* find_resource *function to help add IOAPIC 4 to MPTable. It fails with the error: 1. PCI: 00:01.0 missing resource: 14 This works fine for APIC 5, though. They're the same device. Here's a very truncated coreboot log: http://pastebin.com/JyJph1Ee Any ideas? -Nick

1 0

(no subject)
by pradeep kathirgamaraja 04 Jun '15

04 Jun '15

1 0

ASUS KFSN4-DRE Automated Test Failure
by Raptor Engineering Automated Coreboot Test Stand 04 Jun '15

04 Jun '15

The ASUS KFSN4-DRE fails verification as of commit d42ee150a0330f22986ad7237c9e70cebd9d995c The following tests failed: ACPI_DSDT_ACCESS_FAILURE ACPI_SSDT_ACCESS_FAILURE CBMEM_TIMESTAMP_ACCESS_FAILURE Commits since last successful test: d42ee15 libpayload: usb: Support MTK xHCI host controller 08e3013 libpayload: usb: Max packet size of SuperSpeed control EPs should be 512. a4cf83d cbfs: Fix mismerge. 1aeea7f tpm: Add dummy _DSM to make Bitlocker happy. 36f8d27 Make DSDT a file in CBFS rather than embedding it into ramstage. 1cac2c9 Hide PLATFORM_USES_FSP1_1. 633352c Kconfig: Remove RELOCATABLE_MODULES. See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Raptor Engineering offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] [Bug?] 3 different bytes in VGAbios after upgrade to coreboot
by Patrick Georgi 03 Jun '15

03 Jun '15

2015-06-03 1:33 GMT+02:00 ron minnich <rminnich(a)gmail.com>: > interesting. Not sure what is up here but I have seen that many VGA bioses > copy themselves to RAM and then modify their own code. I've seen some VGABIOSes map some small register block into the memory region where the VGABIOS resides. I guess the idea is that this region is guaranteed to be unused. When dumping a segment set up like this, it can differ over time... Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores

1 0

New post published at blog.coreboot.org on June 3, 2015 at 4:18 am
by WordPress 03 Jun '15

03 Jun '15

1 0

ASUS KFSN4-DRE Automated Test Failure
by Raptor Engineering Automated Coreboot Test Stand 03 Jun '15

03 Jun '15

The ASUS KFSN4-DRE fails verification as of commit a4cf83df7a3ef3401e12ca3732cbe07294684d02 The following tests failed: ACPI_DSDT_ACCESS_FAILURE ACPI_SSDT_ACCESS_FAILURE CBMEM_TIMESTAMP_ACCESS_FAILURE Commits since last successful test: a4cf83d cbfs: Fix mismerge. 1aeea7f tpm: Add dummy _DSM to make Bitlocker happy. 36f8d27 Make DSDT a file in CBFS rather than embedding it into ramstage. 1cac2c9 Hide PLATFORM_USES_FSP1_1. 633352c Kconfig: Remove RELOCATABLE_MODULES. See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Raptor Engineering offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

2 1

Re: [coreboot] [Bug?] 3 different bytes in VGAbios after upgrade to coreboot
by ron minnich 03 Jun '15

03 Jun '15

interesting. Not sure what is up here but I have seen that many VGA bioses copy themselves to RAM and then modify their own code. Actually, I have seen many BIOSes that do this self modifying code hack; they use it to change behavior for a warm restart; copy themselves to shadow RAM and then change a byte or two so the jump target is different.. I've no idea if that's what is going on here but thought I'd mention it. ron On Tue, Jun 2, 2015 at 4:17 PM Vladimir <quickcracktime(a)gmail.com> wrote: > I retrieved my vgabios via Linux kernel 3.19 (ubuntu 15.04) using this > method - http://www.coreboot.org/VGA_support#Retrieval_via_Linux_kernel > ; then I downloaded latest sources of SeaBIOS & Coreboot and built Coreboot > using compiled SeaBIOS payload as well as vgabios file ( 1002,990b ) > > After coreboot installation I have decided to retrieve vgabios again, > using exactly the same kernel and OS, and then diff'ed two vgabios files > out of curiosity. To my surprise, they are slightly different! > vgabios_before.bin - SHA1 checksum: > e4d320eb278b0118c46e2e470e7154b12c41966d > vgabios__after.bin - SHA1 checksum: > a9e2ed569bbaaea283b5380a5f6c44fc4efc3da4 > Here is a report about 3 bytes difference between them - > http://www.diffnow.com/?report=2kwq3 > (wait a few seconds while it loads) > > Then I teardown a laptop, and check if vgabios inside coreboot's image > (flashed in chip) is 3 bytes different as well, but there was no difference > against the original vgabios. > > So, it appears that, while loading vgabios from a flash chip, coreboot > modifies it slightly. Although this tiny difference is not causing any > graphical glitches or problems for me, this could be a result of a bug - > which is not necessarily limited to my hardware ( Lenovo G505s ) , and > maybe could lead to some other problems > > Please tell your opinion, is it a bug or I am wrong at something? > > Best regards, > Vladimir Shipovalov > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

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 June 2015