coreboot July 2013

coreboot@coreboot.org

45 participants
108 discussions

Re: [coreboot] Trouble with coreboot for Roda RK9
by Nico Huber 04 Jul '13

04 Jul '13

Hello Dmitry, > I use gcc-4.4.7 version. I also tryed to use gcc-4.6.3 and it didn't make > any results also. Did you use coreboot's reference toolchain or was it a gcc-4.6.3 from your distribution? If you didn't try the reference toolchain yet, it's worth it. To build the reference toolchain, simply run make crossgcc from your coreboot top-level directory, and wait... abuild should use it automatically. For your manual make runs, you should remove `.xcompile` once the toolchain is build. > I don't understand the reasin why it may happen. Me neither. Maybe you should also try to reset your coreboot checkout or even a fresh checkout if you did any changes. 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. Karsten Ottenberg ______________________________________________________________________

2 1

What is the purpose of hard_reset function?
by Andrew Wu 04 Jul '13

04 Jul '13

Hello, I am porting coreboot to our own product(Vortex86EX). I see there is a function called "hard_reset". Some boards implements this function, and some don't. Looks like each different mainboard has different implementation of hard_reset. Now I just wrote a blank hard_reset function, but maybe it is not right. So what is the purpose of this function? What should I put inside this function? To reset the system, why not just use system port(92h port)?

1 0

A few notes on CLs
by ron minnich 03 Jul '13

03 Jul '13

I've noticed some trends in CLs from our newer guys that I want to warn against. People are putting in text that, viewed from a short time frame and a perspective of being unfamiliar with the code base and hardware, make sense. But from the longer time frame, they're not such a good idea. A little background: the coreboot codebase started on sf.net, in 1999. SInce that time, we have - used 4 SCM systems (CVS, ARCH, subversion, GIT) - run on at least two different servers (sf.net, coreboot.org) - supported around 10 kernels (Linux, Plan 9, *BSD, windows variants, QNX, ...) - - and over 100 different linux versions - worked with at least 10 vendors who no longer exist Writing CLs that stand the test of time in this context is a bit of challenge. But there are some things you can avoid: 1. Avoid URLs as much as possible. There are 600 URLs in the 21000 u-boot commit log. There are 224 in the 4000 or so coreboot commit log. Of those in coreboot, 40 or so are invalid. This problem only gets worse with time. Some of them are for dead companies, others because things have moved. 2. avoid kernel boot logs. Sure, it means something to you, right now. But it's useless after about a year, as kernels change. It can be quite misleading over time. And, besides, there are people out there who do not care about Linux and don't want to trawl through Linux boot logs to understand a CL. Avoid being linux-centric 3. avoid coreboot logs. Same reason. It's amazing how much coreboot logs change over time. 4. Avoid copy/paste of documents. Not the least because we don't want to deal with copyright issues 5. A CL is not a tutorial. It's not a chance to thank people for their work. It's an explanation of a change. Keep it short. In many cases, it should be possible to understand it from the summary. For most of them, I should not have to click through a URL to have some idea of what you've done! See gerrit.chromium.org for an example of a real, large project and what their CLs look like. 6. And, I hope for obvious reasons, never link to a patent, cite a patent, or mention patents as the basis of anything you do :-) 7. Avoid telling people to run this or that tool. Not everyone has your environment. 8. Finally, we almost never need to see gcc/iasl error messages. The words 'won't compile' are just fine in almost every case. DO: 1. create a clean, concise summary 2. explain what you did 3. explain why you did it. (2 and 3 can be in the other order) I hope Nico doesn't mind, but I've just been reviewing and his CLs are fresh in my mind. They're a great model of how CLs should be written. So check his CLs out. Hope you do not mind me mentioning you, Nico! thanks ron

1 0

Who sells the Roda RK9 ?
by Marcello Stanisci 02 Jul '13

02 Jul '13

Hi folks, I did a (web) search to discover who sells the RK9. I didn't found shops that sell that laptop. Does someobdy who sells it (either online or physical shop)? ps: I did the same about the Getac P470 with the same results: nobody seems to sell it. Thank in advance, ms

3 3

Re: [coreboot] [coreboot-gerrit] New patch to review for coreboot: 7d39656 lenovo/x60/romstage.c: Collect timestamps in romstage
by ron minnich 02 Jul '13

02 Jul '13

Again, can we cut this down a bit? Most of what you're saying is obvious or gratuitous. It's very kind of you to thank people but we really don't need thanks in the message. On Tue, Jul 2, 2013 at 1:40 AM, Paul Menzel <gerrit(a)coreboot.org> wrote: > Paul Menzel (paulepanter(a)users.sourceforge.net) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/3587 > > -gerrit > > commit 7d396566be210dfd5f86c8d9038ae0fdacefa02f > Author: Paul Menzel <paulepanter(a)users.sourceforge.net> > Date: Tue Jul 2 09:54:17 2013 +0200 > > lenovo/x60/romstage.c: Collect timestamps in romstage > > Collect early timestamps in Lenovo X60’s romstage. This is fine. > like the Lenovo T60 > does. Selecting the option `COLLECT_TIMESTAMPS` in Kconfig and then > doing `cbmem --timestamps` should output the timestamps. Are we going to list *all* the systems that do it? Why? Are we going to tell people how to use each Kconfig? Documentation of this type does not belong in a commit message. > > Thanks to Nico Huber’s work setting this up for the ICH7 and implementing > it for the T60, all what was needed to do, was to do the equivalent > changes for the X60 as for the T60 in commit 44c392f8 [1]. > > lenovo/t60: Collect timestamps in romstage > > [1] http://review.coreboot.org/3499 remove all this text. It's not needed. We all depend on the work of others. We don't need to cite it in each and every CL.

1 0

Enabling Dediprog by default in flashrom
by Stefan Tauner 02 Jul '13

02 Jul '13

Hi, the release of flashrom 0.9.7 is imminent and I would really like to enable the Dediprog programmer by default. Carl-Daniel informed me that the only problem is that we do not know which opcode is actually used for reading on the SPI bus. It could be that we initiate a fast read (0x0b) instead of a normal read (0x03). This would work with the majority of flash chips but would not with others where flashrom should normally work. Since we are not sure we don't want to enable it without further consideration/testing/warning messages. Furthermore not all chips supporting fast read have this fact noted in their datashets. So testing any apparently non-fast read chip does not suffice. We would rather be able to check the opcode on the SPI bus with a logic analyzer directly. Are there any Dediprog users who can help us with that please? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [coreboot] No VGA output on e350m1 after flashing. what to do?
by Alvaro G. [Andor] 01 Jul '13

01 Jul '13

El 01/07/13 22:14, Reiner Luett escribió: > On 01.07.2013 00:35, Álvaro [andor] wrote: >> I have a batch of 10x 8mbyte chips. If you have the USB3 model of the >> board, I can burn the original bios in one of them and send it to you. > Do you know, if the chips are working with the E350M1 without USB3? > Please send a discription of the chip. What kind is it? > > Winbond W25Q64BVDAIG 64Mbit in DIP8? I substituted the included "W25Q32BVAIG 4MB PDIP 8Pin PDIP SPI" by the equivalent in 64Mbit: W25Q64BVAIG (note there's no 'D' as the one you said, I don't know if it was a typo on your side..), and yes, it's DIP8. I think it should work, as there is minimal difference between the USB3 and the regular model, and I think all the controllers are the same, except for the USB3 of course. The coreboot target I'm using is the same for both. But, the bios doesn't look *exactly* like the same. If anybody has a backup for the regular E350M1 (Paul Menzel. Martin Roth...?) vendor bios, I can burn it... Thanks

1 0

Re: [coreboot] Trouble with coreboot for Roda RK9
by Nico Huber 01 Jul '13

01 Jul '13

Am 25.06.2013 23:08, schrieb Dmitry Bagryanskiy: Hello Dmitry, > My processor type is Intel Core 2 Duo P8400, socket mFCPGA479M IIRC, I've seen at least one RK9 with this CPU running coreboot. Looking through your log files, I didn't find anything suspicious. I'll try to check if current upstream coreboot really works on our RK9, tomorrow. Meanwhile, could you post your coreboot .config? And when responding, please always cc the coreboot mailing list. Nico

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2013