coreboot November 2013

coreboot@coreboot.org

53 participants
117 discussions

Re: [coreboot] thinkpad r400 - porting coreboot
by Marek Doležel 22 Nov '13

22 Nov '13

Hello there, i am interested in porting coreboot to thinkpad r400. I have also included datasheet for t400 (according to what i know they should have same mobo) Please see more below. Have a nice day On Tue, Nov 19, 2013 at 10:42 AM, Nico Huber <nico.huber(a)secunet.com> wrote: > Hello Marek, > > nice to hear that you're interested in coreboot development. You should ask > your questions on the coreboot mailinglist (coreboot(a)coreboot.org). Just > forward your original message there, or reply to this mail, adding the > coreboot mailinglist (don't forget to attach your logs). > > Am 15.11.2013 17:49, schrieb Marek Doležel: > > Hello there, > > > > I have noticed that you commited some patches for roda rk9. I would like > to > > port coreboot to thinkpad r400. I have no previous bios development > > experience. Could you please tell me how hard for beginner should this > be? > This really depends on your experience / programming skills and what > needs to be done (see below). > > > I have attached some interesting dumps. I don't mind working 3 moths to > get > > just error message from coreboot during early init. > Your dmidecode.log shows that you have DDR2 memory. Sadly, our current > GM45 chipset code does only support DDR3 (which is used in the Roda > RK9). If this isn't a fault in your DMI tables and you really have DDR2 > memory, porting coreboot will be especially hard (some more month of extra > work). OTOH, all other chips (southbridge, super i/o, embedded controller) > might already be supported. > > Good luck, > Nico > > -- > M. Sc. Nico Huber > Berater, SINA-Softwareentwicklung > Public Sector > secunet Security Networks AG > > Tel.: +49-201-5454-3635, Fax: +49-201-5454-1325 > E-Mail: nico.huber(a)secunet.com > Mergenthalerallee 77, 65760 Eschborn, Deutschland > www.secunet.com > ______________________________________________________________________ > > Sitz: Kronprinzenstraße 30, 45128 Essen, Deutschland > Amtsgericht Essen HRB 13615 > Vorstand: Dr. Rainer Baumgart (Vors.), Willem Bulthuis, Thomas Pleines > Aufsichtsratsvorsitzender: Dr. Peter Zattler > ______________________________________________________________________ >

1 0

Re: [coreboot] software hardening research project - request for advices to start
by Laurent Lesage 22 Nov '13

22 Nov '13

Hello Zoran, Thanks for your answer. I googled a bit coreboot and read the short SAGE guide. My understanding is a bit better, but I've not yet begun to put my hands on it. Before that, I ask again some advices. So I understood that, indeed, a very quick boot is possible. That's fine. So, the POST may be done when "cold start" is done. It's only when I want to make a reboot that I need it to be as fast as possible. When you say " shallow warm restart it speaks well to me, though I've still no idea of how to do it. ... if I google those words "shallow warm restart + coreboot" .... I just find this email thread in first position!!! Can you give more tips on haow to go in this direction? I also saw that it was possible to flash coreboot + payload on the chip : this is a very interesting option, because we also have to protect the software against a mad CPU (it will be, as we will cause bitflips in it with ions irradiations). If the soft is in the ROM, we may consider it is safe. In case of error (that is, if the CPU is in an infinite loop, or triggered any exception), the only thing that would have to happen is a reset, that is (as far as I can express it) : -restart the payload only (an so reload it from ROM) = we consider that the RAM content is corrupted. -of course, the cache will have to be reset (also considered as corrupted) -the system should be in the same state as when it started, except there should be no need to make a POST again. -may be do things I do not yet know about... All that stuff is the "shallow warm restart" as far as I understand. AM I right? And yes, the software is as simple as possible, that is, no threads, only C code on bare metal. No interrupts : the only interrupt authorized is to reset the CPU, but this should be triggered with a watchdog and/or the PCIex board which will hold and FPGA and some kind of protected memory (i. e. protected against the "mad" processor). Is UEFI and EDK necessary? I read that UEFI support was not yet complete. EDK is the tool provided by SAGE, I think : is it GPL too? At this time we do not have budget to hire anyone... MAybe in the future if we can set this experiment which has never been done. About the test board : At this point, my idea is to use coreboot + Qemu to put my hands on coreboot and try to do what I described. I suppose (am I right?) that if it works that way, it would be possible to use what I learned to put it quite easily on a "real" board? Is Intel or AMD more suited to those needs? What do you think? Laurent On 22/10/13 09:48, Stojsavljevic, Zoran wrote: > Hello Laurent, > > I can give you my own tips for doing what you have asked. Few of them... > > I don't understand why you need to modify BIOS? Instead, you can keep your SW on the USB mass storage. And go from there. The another approach is to boot to DOS 6.2 on USB and perform tests from there. DOS is a linear OS, does not have MMU engaged, does not have HW multithreading (my best understanding). > > If you will use INTEL CPUs, you can go with FSP approach as well, and put Coreboot on the top of it, using your SW as Coreboot payload. One of the viable solutions, but you need also to have Management Engine (ME) SW added there (in single, or dual spi design, ME placed in spi0, BIOS in spi1). > > If you would like to boot with less than 1 ms, you need to do shallow warm restart, so you need just to be able to free HW resources (since I think you'll use ONLY one HW thread, one core sans hyperthreading, all others while in BIOS are disabled), flush cashes, do memory garbage collection (if any?) and jump to the beginning of your test SW. Not sure while performing shallow warm restart if you need to do something with System Management Mode (SMM) and it structures. Topic to be investigated. > > Please, do notice that BIOS and FSP, both do for you PCIe enumeration. For the boards, I'll advise you for INTEL to use IVB and later (HSW) based. This are the primary CPUs for INTEL to keep supporting 'em for long time (at least for 7 years from date of public release, 2012 for IVB, 2013 for HSW). > > Now, specifically to your questions: > [1] YES, it is possible to modify BIOS to disable POST, and do certain configuration, you need to use Open Source (with incorporated binaries doing SEC and PEI) EDK2 package (UEFI BIOS) which has options for various configurations; > [2] YES; > [3 - 4] I don't know. I am using INTEL's CRBs, these are unlocked always. Not sure about commercial boards, and which are the best for such experiments. > > Zoran > _______ > Most of The Time you should be "intel inside" to be capable to think "out of the box". > > -----Original Message----- > From: coreboot-bounces(a)coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Laurent Lesage > Sent: Monday, October 21, 2013 6:15 PM > To: coreboot(a)coreboot.org > Subject: [coreboot] software hardening research project - request for advices to start > > Hello all, > > After having searched around me for some answers about BIOS and PC board "hacking", I want to ask directly to the "core" developers. > > In short, I would like to run a test software without OS (say, like > "memtest") on a standard mainboard. This software will have to access a PCIe board, and may be some components of the mainboard. So we expect the software will not exceed a few hundred kilobytes. During this experiment, we want that a reset of the CPU does not lead to a reboot, but just restart our software immediately (only a cold start would redo all the usual "POST"), skipping all the usual hardware setups. > "immediately" means in one ms or so (the less, the best). More details about what I'm working on at the end of this post. To achieve this on standard mainboards, being able to modify the BIOS seems the only way. > > My questions /request for comments and advices : > 1.Is it feasible to modifiy the BIOS for such a reset (without POST and very quickly). > 2.Is it possible to put our software on the BIOS chip, so that we do not need to access hard disk, and so that the code is protected (Read only) during the runs. > 3. is it possible to flash the BIOS without locking the board, i.e., is it always possible to recover a working bios if flashing process failed, or experimental BIOS is not working as expected. In that sense, are there boards to avoid? > 4.knowing we will have to access a PCIex8/16 extension board, and knowing the points 1, 2 and 3, which board would you advice to use? For example, I saw this one ( http://www.coreboot.org/ASUS_F2A85-M#Hardware_info ) for which PCIe support seems OK. Of course, the board must be easy to buy, so older ones are not a good choice if they are sold out. > > I also saw that some boards offers bigger space to flash BIOS. Again, this would be a good criterion for our needs, if it is possible to flash our software in it using the remaining space. > What I wish is to start with a mainboard that has more than 90% of probability to meet our needs. > > Some more details about the project. > I'm research engineer in UCLouvain (Belgium). Our topic is "software hardening for mission critical embedded software". Quickly said, we want to test our approach with COTS hardware (usually, testing is done on FPGA systems, or specific hardened hardware systems). So, we want to use a PC board to run a very specific software on it (that could be the "payload" coreboot can start). We intend to make this in two stages : > -first tests on a "naked" machine i.e. without OS. Our software is the payload. That is the subject of this post. > -later, run a software hardened version of Minix (I saw minix is not yet usable as such but if we come to this end, we will have some knowledge to go this way). > The CPU of our "naked machine" will at the end be irradiated to inject error in it, and see if it detects errors and stays working despite transient faults. > > Regards > > Laurent > > board with special memory and FPGA on it > > > -- > coreboot mailing list: coreboot(a)coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 >

3 2

Re: [coreboot] BadBIOS Thoughts
by Alex 21 Nov '13

21 Nov '13

On 11/17/2013 12:00 PM, ron minnich wrote: > > That's you. And in fact it's most of the Linux community. It's why > it's so hard to make progress in this area, because the Linux > community does *not* consider openness down to the hardware level as a > priority, when measured against their other wants. > Exactly. It seems to me the linux community is tired of having linux be idealized for running efficiently on second-grade hardware. Of course I think the community is tired of linux being viewed mostly as a retirement home for desktops. The way I imagine the community sees it, as long as chromebooks are not shiny toys with V12 engines, good or bad as they may be, will be viewed as second-grade. > Which, I have to say, sets all my "Irony-detection" devices to 11 out of 10. :-) > I hope your hypocrisy gauge is still within range. > In many other cases, coreboot *is* a key usability feature (hence the > many chromebooks being sold) and in those cases, it is a very high > priority, if not the highest priority. > > And, yes, you and I are both broken records where vendors are > concerned. But vendors don't set priorities by anything but how many > million units get sold. They don't care what we think :-) > [Broken record warning] What if, somehow, the community gathered a few brains, talked to a vendor, and convinced them to put coreboot on a yet-to-be-released product? It would almost seem like the community would do most of the work for free. What sort of responses have we received in the past with this approach? System 76, ThinkPenguin, Pudget, etc... have we tried any of them? They have sleek systems, and at least the first two value openness more than the average.

8 16

Compilation problem
by Tcendrovskii Vladislav 21 Nov '13

21 Nov '13

Hello everyone! I have compilation problem If build with gcc $ make GEN build.h CC romstage.inc src/mainboard/gigabyte/ma785gmt/romstage.c: In function 'cache_as_ram_main': src/mainboard/gigabyte/ma785gmt/romstage.c:220:1: error: bp cannot be used in asm here } ^ make: *** [build/mainboard/gigabyte/ma785gmt/romstage.pre.inc] Error 1 I've tried gcc-4.4, gcc-4.8 If build with clang $ make GEN build.h CC romstage.inc In file included from src/mainboard/gigabyte/ma785gmt/romstage.c:68: In file included from src/cpu/amd/model_10xxx/init_cpus.c:29: In file included from src/northbridge/amd/amdfam10/raminit_amdmct.c:45: src/northbridge/amd/amdfam10/../amdmct/wrappers/mcti_d.c:442:45: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand] int nbPstate1supported = ! (msr.hi && (1 << (NB_GfxNbPstateDis -32))) ; ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ src/northbridge/amd/amdfam10/../amdmct/wrappers/mcti_d.c:442:45: note: use '&' for a bitwise operation int nbPstate1supported = ! (msr.hi && (1 << (NB_GfxNbPstateDis -32))) ; ^~ & src/northbridge/amd/amdfam10/../amdmct/wrappers/mcti_d.c:442:45: note: remove constant to silence this warning int nbPstate1supported = ! (msr.hi && (1 << (NB_GfxNbPstateDis -32))) ; ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ src/northbridge/amd/amdfam10/../amdmct/wrappers/mcti_d.c:459:39: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand] int powerDown = dRAMConfigHi && (1 << PowerDownEn ) ; ^ ~~~~~~~~~~~~~~~~~~~ src/northbridge/amd/amdfam10/../amdmct/wrappers/mcti_d.c:459:39: note: use '&' for a bitwise operation int powerDown = dRAMConfigHi && (1 << PowerDownEn ) ; ^~ & src/northbridge/amd/amdfam10/../amdmct/wrappers/mcti_d.c:459:39: note: remove constant to silence this warning int powerDown = dRAMConfigHi && (1 << PowerDownEn ) ; ~^~~~~~~~~~~~~~~~~~~~~~ src/northbridge/amd/amdfam10/../amdmct/wrappers/mcti_d.c:460:33: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand] int ddr3 = dRAMConfigHi && (1 << Ddr3Mode ) ; ^ ~~~~~~~~~~~~~~~~ src/northbridge/amd/amdfam10/../amdmct/wrappers/mcti_d.c:460:33: note: use '&' for a bitwise operation int ddr3 = dRAMConfigHi && (1 << Ddr3Mode ) ; ^~ & src/northbridge/amd/amdfam10/../amdmct/wrappers/mcti_d.c:460:33: note: remove constant to silence this warning int ddr3 = dRAMConfigHi && (1 << Ddr3Mode ) ; ~^~~~~~~~~~~~~~~~~~~ src/northbridge/amd/amdfam10/../amdmct/wrappers/mcti_d.c:462:37: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand] int pchgPDModeSel = dRAMMRS && (1 << PchgPDModeSel ) ; ^ ~~~~~~~~~~~~~~~~~~~~~ src/northbridge/amd/amdfam10/../amdmct/wrappers/mcti_d.c:462:37: note: use '&' for a bitwise operation int pchgPDModeSel = dRAMMRS && (1 << PchgPDModeSel ) ; ^~ & src/northbridge/amd/amdfam10/../amdmct/wrappers/mcti_d.c:462:37: note: remove constant to silence this warning int pchgPDModeSel = dRAMMRS && (1 << PchgPDModeSel ) ; ~^~~~~~~~~~~~~~~~~~~~~~~~ In file included from src/mainboard/gigabyte/ma785gmt/romstage.c:68: In file included from src/cpu/amd/model_10xxx/init_cpus.c:29: In file included from src/northbridge/amd/amdfam10/raminit_amdmct.c:46: src/northbridge/amd/amdfam10/../amdmct/mct_ddr3/mct_d.c:3383:24: error: equality comparison with extraneous parentheses [-Werror,-Wparentheses-equality] if ((pDCTstat->Speed == 3)) ~~~~~~~~~~~~~~~~^~~~ src/northbridge/amd/amdfam10/../amdmct/mct_ddr3/mct_d.c:3383:24: note: remove extraneous parentheses around the comparison to silence this warning if ((pDCTstat->Speed == 3)) ~ ^ ~ src/northbridge/amd/amdfam10/../amdmct/mct_ddr3/mct_d.c:3383:24: note: use '=' to turn this equality comparison into an assignment if ((pDCTstat->Speed == 3)) ^~ = In file included from src/mainboard/gigabyte/ma785gmt/romstage.c:68: In file included from src/cpu/amd/model_10xxx/init_cpus.c:29: In file included from src/northbridge/amd/amdfam10/raminit_amdmct.c:61: src/northbridge/amd/amdfam10/../amdmct/mct_ddr3/mhwlc_d.c:505:41: error: equality comparison with extraneous parentheses [-Werror,-Wparentheses-equality] if ((pDCTData->MaxDimmsInstalled == 4)) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ src/northbridge/amd/amdfam10/../amdmct/mct_ddr3/mhwlc_d.c:505:41: note: remove extraneous parentheses around the comparison to silence this warning if ((pDCTData->MaxDimmsInstalled == 4)) ~ ^ ~ src/northbridge/amd/amdfam10/../amdmct/mct_ddr3/mhwlc_d.c:505:41: note: use '=' to turn this equality comparison into an assignment if ((pDCTData->MaxDimmsInstalled == 4)) ^~ = 6 errors generated. make: *** [build/mainboard/gigabyte/ma785gmt/romstage.pre.inc] Error 1 .config in attachement

2 5

Intel SandyBridge Xeon support C600 chip-sets
by FireIcer 21 Nov '13

21 Nov '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Any further updates on Intel contributions to the source tree regarding the sandybridge arch. particularly the C600 chip-set for the current Dual Xeon boards. Seen as Supermicro mainly has the monopoly on these type of high end boards now coreboot would reach a massive market with support for this chip-set. I have tried to get coreboot working on the X9DAi board but without luck, well i say that but i did get it to boot. cant seem to get all elements of the board working though. TPM dont seem to work if the module has not already had its ownership claimed. Trying to get data sheets on how to put that into the coreboot source seems impossible. I think Intel need put in a bit more regarding this hence my question. Also i am having difficulty getting the memory interleave working, i think it might be a kernel issue or graphics driver rather than coreboot, seems like they try to read the conventional memory model and addressing gets messed up somewhere, somehow. just thought i would mention it. - -- Regards F1R31C3R M6EFCZ Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSjYiLAAoJEBzkvPKQNuh2OeQIAJ3XXuc+LmCUZq2LJRAj0Z2p YbKoG7l4eOGe36lzlbjNUpxrLz+9Yfs9cfkceLP00BEEzVAnGjupzgNKnP+6+ATr 9j7DOINAvlvN3Kui3yRhtbvkjTGmL0lqiEUq8oCcQ9hpm1PNRkdN//6RT5EnNB2a FOFJlwQPcoK+g6oruB7kr3kCkYbVXxcQkNrv3+w5QqJRf2uohpzTJMdcsweDm4f3 MeDx+zVl7FdRaao+CAX2TQyrtOEMAB6L6l1jViTMjGAQUJzowt/YLIJJf+ZK9pj3 V1dJ4iSoEQC6D4hbgd5g6Nfxf/LNYa+Q71xxsCP4B4fpq/1QfFNWQWMGKC4pTAs= =4+k0 -----END PGP SIGNATURE-----

2 1

Re: [coreboot] Petition to Google: Please produce a midrange Chromebook
by Alex G. 21 Nov '13

21 Nov '13

On 11/20/2013 10:13 PM, ron minnich wrote: > Alex, you are of course free to submit such a petition. And, anyone > who wishes can sign it. > > I've received an off-list request from one of our other enthusiasts > (i.e. not a company or from a company) to remind you that you are not > in a position to speak for "the coreboot community". Possibly you > should call yourselves an independent group of coreboot enthusiasts. > I apologize for the mis-wording. I did not mean to impose. Alex

1 0

Re: [coreboot] Re : Re: BadBIOS Thoughts
by mrnuke 21 Nov '13

21 Nov '13

On 11/20/2013 11:17 AM, ron minnich wrote: > We should give Intel come credit. They're trying to do the *profitable* thing > *for* their business. There, I fixed it for you.

2 1

An Open Source Phone That’s Completely Unlocked, Hardware Too
by Iurie 21 Nov '13

21 Nov '13

http://www.fastcolabs.com/3021652/an-open-source-phone-thats-completely-unl…

1 0

Re: [coreboot] iasl compiler/disassembler getting confused by Scope operator
by Michael S. Tsirkin 20 Nov '13

20 Nov '13

On Wed, Nov 20, 2013 at 05:38:53PM +0000, Moore, Robert wrote: > OK, can you just send the files? > thanks Here goes (3 files attached). Just run the commands in README to see the problem: iasl dsdt.dsl iasl ssdt.dsl iasl -e DSDT.aml SSDT.aml iasl SSDT.dsl #above fails to compile

2 3

Re: [coreboot] Re : Re: BadBIOS Thoughts
by Carl-Daniel Hailfinger 20 Nov '13

20 Nov '13

Am 20.11.2013 18:17 schrieb ron minnich: > We should give Intel come credit. They're trying to do the right thing > in a way they feel is compatible with their business. You've seen the > FSP commits from Sage in the last few days. That work was only > possible because Intel helped. Agreed. However, some time ago it apparently made business sense for Intel to publish their chipset/memory/cpu init docs. What has changed from an Intel POV? Regards, Carl-Daniel -- http://www.hailfinger.org/

1 0

← Newer
1
2
3
4
5
6
7
8
...
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2013