coreboot March 2014

coreboot@coreboot.org

57 participants
180 discussions

Re: [coreboot] GSoC-2014 Coreboot project
by Peter Stuge 19 Mar '14

19 Mar '14

ron minnich wrote: > well, vladimir, I would not be so discouraging. In fact if it is an > existing mainboard, and you have not done coreboot before, I suggest > doing a port, and then doing something new with the port. I think this is a good idea in general. > I'd like somebody to look at doing LinuxBIOS again, i.e. getting us back to > the point where we can embed linux in the flash as the payload. Patrick got > us a long way back toward getting that working, and it'd be nice to see it > finished. I've tested it - it works well at least in QEMU. A solution is still needed for ARM though. //Peter

3 2

Re: [coreboot] GSoC-2014 Coreboot project
by Vladimir 'φ-coder/phcoder' Serbinenko 19 Mar '14

19 Mar '14

On 19.03.2014 21:06, Allen Yan wrote: > As Stefan Tauner's suggestion, maybe porting coreboot to new mainboard Just a quick note: for porting to new chipset to be accepted, you need to: 1) Justify why this chipset is relevant. E.g. old chipsets most probably aren't. 2) Prove that you're able to do it. New raminit isn't an easy task. Also from quick google it seems that this board uses i945 chipset which is already supported. Port with already supported chipset is a task for 3-5 days for experienced dev, most likeyl too small for GSoC.

2 1

GSoC-2014 Coreboot project
by Allen Yan 19 Mar '14

19 Mar '14

Hi, I am Jinyi Yan , a second year PhD candidate from Shanghai Institute of Micro-system and Information Technology, Chinese Academy of Sciences. I used to be a mainboard BIOS engineer in ASUS Technology Suzhou Co., Ltd for about two years (2007.7~2009.2). My major now is optoelectronics. But I have a lot of fun while programming, in my heart the working experience of being a BIOS engineer is still very exciting. I think GsoC is a nice platform for me to participate the open source community. When I search the GsoC projects and organizations, the coreboot and flashrom projects are definitely the right choices for me. I have a spare ASUS P5KPL PC at my hand, but the chipset is not in the support list of coreboot project. As Stefan Tauner's suggestion, maybe porting coreboot to new mainboard or implementing advanced coreboot features on exsiting mainboards are nice too. Now I'm not very familiar with the program structure of coreboot, so I expect your guidence and hope to contribute for coreboot and flashrom even if my application is not accpeted. Thanks! Look forward to your kind advice! Regards, Jinyi Yan

1 0

Building a Thinkpad X230 coreboot image
by Bernie Innocenti 18 Mar '14

18 Mar '14

Hello Vlad! First of all, thank you very much for porting Coreboot to the X230. I'm following your instructions [1] to build a coreboot image from head, but I'm not sure how to configure things in menuconfig. Would you mind sharing your .config file and a prebuilt, known-good rom file? Also, while I'm waiting for the SOIC test clip to ship: do you know if anyone is working on getting flashrom to work with the X230? [1] http://www.coreboot.org/Board:lenovo/x230 -- _ // Bernie Innocenti \X/ http://codewiz.org

4 5

Python versioning
by nap 18 Mar '14

18 Mar '14

Restarting today from a fresh cloning of coreboot followed by make crossgcc and a configuration of an emulated x86 Q35 (see .config), I run into the two following errors : >1 ~/dev/corebootwks/coreboot $ make ... LD cpu_microcode_blob.o /home/user/dev/corebootwks/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld: no input files make: *** [build/cpu_microcode_blob.o] Erreur 1 # which was solved possibly incorrectly by switching in Chipset Include CPU microcode in CBFS (Generate from tree) to Include CPU microcode in CBFS (Do not include microcode updates) >2 ~/dev/corebootwks/coreboot $ make ... Compiling (16bit) /home/user/dev/corebootwks/coreboot/build/seabios/out/romlayout.o Building ld scripts Version: rel-1.7.2.1-0-g88cb66e-20140314_000452-machine File "./tools/layoutrom.py", line 76 print "Error: Fixed section %s has non-zero alignment (%d)" % ( ^ SyntaxError: invalid syntax make[2]: *** [/home/user/dev/corebootwks/coreboot/build/seabios/out/romlayout16.lds] Erreur 1 make[1]: *** [build] Erreur 2 make: *** [seabios] Erreur 2 # it seems to me that the error is due to Seabios assuming in its Makefile line 65 that PYTHON=python but it should be python2 as the print verb in File "./tools/layoutrom.py", line 76 is a typical python2 statement and not a valid python3 function, and many boxes have today python3 as their default python. < Suggestions welcome !

2 1

Re: [coreboot] [RFT] Please test patch set intel/i945: Only write CID, PN and TCID once
by Mono 18 Mar '14

18 Mar '14

Thank you ron for your comments! actually I was not aware the code I look at is more than 5 years old. You are absolutely right in that the patch was written after reading public ICH7 documentation and I do not know of any problem the current implementation causes. Moreover, I was not aware that the code might do something else than what one can know by reading the code and the public documentation. To be honest, if that was true, I would be disappointed, because I expected coreboot to be a possibility of getting away from private software and "you don't know what your machine does". However, I did debug the code by reading the write-once registers in question before and after the several write operations. The registers do not change their contents but due to the first write operation. By that I concluded the public documentation describes the chip's behavior correctly. After reading your comments about private documentation of course this conclusion might be wrong though. At the moment I believe that applying the patch does no harm. At least this is my current knowledge by running it at the MacBook2,1 for a couple of hours. Switching forth and back between coreboot versions (back to safe ones) works. I do not know if this was true for other boards. Who knows, it might(!) fix some 5 year old bug? In case you were interessted, I uploaded the output of inteltool when running the macbook without the patch, that is by compiling [1] and by compiling the patch on top of [1]. Please see 5324 without patch 5387: http://paste.flashrom.org/view.php?id=2051 5324 plus patch 5387: http://paste.flashrom.org/view.php?id=2052 diff -y without vs with patch 5387: http://paste.flashrom.org/view.php?id=2053 any light shedding is much appreciated! best regards, Mono [1] http://review.coreboot.org/#/c/5324/ On Sun, Mar 16, 2014 at 09:26:09AM -0700, ron minnich wrote: > So do I understand it correctly, that this patch is for hardware that has > been working, in some cases for 5 years; that it has > been written after reading a public doc; and that it was not developed in > response to a known bug or issue? > > Code that does not conform to a public doc is NOT a bug. > > A word to the wise: in all too many cases, the public docs and the private > docs disagree. In some cases, the private docs directly > contradict the public docs. And, in still other cases, the hardware > contradicts the private docs. That's what makes this so much fun. > > It's the implementation of the hardware, not the documentation, that > matters. > > Changes made in response to a reading of public docs, that are not known to > resolve an actual observed problem, are > a very risky thing to do, especially with old chipsets. They should be > rejected outright unless they are confirmed to fix a problem. > > We've had people push this kind of change in the past and break boards. > > So tread carefully. > > ron > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

4 4

[GSoC-2014] Project Proposal Review
by Naman Govil 17 Mar '14

17 Mar '14

Hi! After much review and discussions on the list as well as the irc, I have drafted my proposal for the project "Generic Device Interface for ARM SoCs" and upload it on gsoc-melange. It would be great to have reviews on it. Please provide me with comments/suggestions so that I could improve upon it before the final deadline. Regards, Naman

1 0

Re: [coreboot] I've turned on paging as a test
by Peter Stuge 17 Mar '14

17 Mar '14

ron minnich wrote: > [on arm] > > > Why is it helpful or neccessary there? > > It only matters if you like to have a dcache. Do you want a dcache? What are the numbers? > On PPC, you have no choice Not much effort going into that in coreboot these days, so might not be a big concern. > > > We will have to have it on x86_64. > > > > Why is it neccessary there? > > It only matters if you want to enter 64-bit mode. (Why) Does coreboot need to do so? > > - MTRRs sure make for a lot of fuss. > > - I wish we could do something simpler. > > - Let's turn on paging, that would be simpler! > > And, in fact, it is. It's far, far simpler. I am not dismissing the thought that it is simpler. I am trying to say that *despite paging being simpler* there are (several) more things to think of, which are not being mentioned and so how would anyone know if they've been considered? > Just look at our last iteration of MTRR setup. I'm unfortunately being kept too busy trying to keep coreboot from making changes which seem good enough when proposed but which may not actually be worth the change. > For the base identity map on x86-32, it's one page for 4G. > For a map which locks out page 0, it's two pages. I think it would be great if you could write up what you actually want to accomplish. I am very worried that this is an XY problem: Someone wants X and thinks that Y is the best way to accomplish it. They move on to communicate with others about Y, instead of about X, which is the more constructive communication to be had. Is your goal to write-protect coreboot code in RAM while coreboot runs? > And, again, we've had virtual addresses forever. That's what > segmentation hardware does. We just had a 1:1 mapping. A 1:1 mapping is (obviously, I hope) equivalent to not having paging at all for the purpose of this discussion. //Peter

6 8

[RFT] Please test patch set intel/i945: Only write CID, PN and TCID once
by Paul Menzel 16 Mar '14

16 Mar '14

Dear coreboot folks, Mono pushed the patch intel/i945: Only write CID, PN and TCID once for review [1], which needs testing to make sure nothing breaks. Could you please test it on Lenovo T60, Lenovo X60, the Kontron 986LCD-M/mITX and other Intel 945 based devices? Please attach output of `inteltool` (under `util/inteltool`) without and with the patch *and* please also attach the coreboot log with patch set 5393 [2] applied. That would be very helpful. Thanks, Paul [1] http://review.coreboot.org/5387/ [2] http://review.coreboot.org/5393/

2 1

Re: [coreboot] GSoC-2014 Project for Coreboot
by mrnuke 15 Mar '14

15 Mar '14

On Saturday, March 15, 2014 05:15:12 PM Kevin O'Connor wrote: > Did you mean to send this only to me? I'm only sending to you and not > the list, but I'd prefer the discussion to be on list. > OOPS! I blame it on KMail's shitty "Reply" interface. > On Sat, Mar 15, 2014 at 01:54:47PM -0500, mrnuke wrote: >> On Saturday, March 15, 2014 01:02:22 PM you wrote: >>> On Fri, Mar 14, 2014 at 08:58:01AM -0500, Aaron Durbin wrote: >>>> CBFS is definitely not friendly to environments that can't map() the >>>> storage area of the CBFS itself. Beyond that in-storage format with >>>> metadata tightly coupled to the data itself leads to needing to stream >>>> large amounts of data through the working set just to locate the piece >>>> that is desired. >>> >>> CBFS is a neat system for accessing flash that can be linearly mapped >>> into memory. >>> >>> If one has a flash device that can't be mapped into memory, I don't >>> understand why one would want to use CBFS. >> >> Last I checked, CBFS stood for "CoreBoot File System". I think that might >> mean it's the filesystem used by coreboot, but I'll have to double check >> and get back to you on that. > > I don't think that's a great way to look at it. The CBFS system is > clearly designed to delineate a linearly mapped area of memory. I > wouldn't recommend using it for something else solely because it > starts with "CB". > >>> Trying to adapt CBFS to block devices is going to complicate the CBFS >>> code, and it still isn't going to be a good solution for those block >>> devices. There are a number of filesystems already developed for >>> block devices - why not just use one of them? >> >> And how exactly is this going to complicate CBFS code? And how would >> adding >> another filesystem parser into coreboot simplify things? > > The code has a bunch of media->open(), ->close(), ->read(), > etc. operations that are unnecessary for basic linear memory mapped > accesses. As you've already cited, even with these "media" accessors > the system still doesn't work well for not mapped flash chips. > > By moving the abstraction up a layer, I posit that the CBFS code could > be simpler, and the ARM code could be more capable. > >>> The coreboot code's interaction with the "filesystem" after memory >>> init >> >> Aye, there's the rub: the assumption of "after memory init". > > Before memory init everything is different on these non-mapped flash > systems anyway. In past conversations I've been told the hardware (or > builtin firmware) on these systems extracts a preset block from the > flash and places it into sram, and this is how the bootblock/romstage > is done on these systems. Thus the execute in place nature of > bootblock/romstage in CBFS has no added value for these platforms. > >>> (should) largely boil down to load_file(char *name, void >>> *address, int maxsize). Why not just end the abstraction there (ie, >>> on these arm devices, implement a completely different "load_file" >>> function). >> >> Did you have a look at our CBFS backending, by any chance? > > Yes. > >> I'm sorry to be dismissive of your comments, Kevin, but it seems to me you >> do not fully understand the issue and its implications. I suggest you >> fully read this thread and "CBFS bullfart (forked from GSoC-2014 Project >> for Coreboot)" to get an idea of the problem and its subtleties. > > I have read the thread. I concur that I do not understand. > > -Kevin

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2014