coreboot May 2013

coreboot@coreboot.org

38 participants
91 discussions

Re: [coreboot] Intel: How to share `tsc_freq.c` to select `UDELAY_TSC`
by ron minnich 08 May '13

08 May '13

It's nice to merge code where possible, but it's been shown to be a mistake in the past to be overzealous in merging code. Sometimes, the merged code turns into an ugly mess of if's and special cases; see some parts of Linux drm to see just how complex this can get. And, in the worst case, as people extend the merged code for newer cases, they break older cases. You've really got to be careful. Sometimes, code is duplicated because either it has to be tweaked or people want to make sure it remains unchanged for a given part, or the part is sensitive to order of operations. There are timing or other issues that make code delicate. In the worst case (this has happened) code is changed for a common case and it works in the initial tests, and fails later, or fails later on one platform for one special case in which it used to work. That's always fun. We've already seen with Paul's first plan how easy it would be to break a bunch of platforms with a well-intentioned code merge. This kind of mistake has happened before. Just merging code is not necessarily virtuous. Given that the platforms work, and most of them are obsolete, it's hard to see the virtue in this change. It adds the risk of failure for what seems an academic gain in cleanliness. ron

1 0

Re: [coreboot] Building AMD Persimmon in MinGW
by Scott Duplichan 08 May '13

08 May '13

]2013/5/6 Wim Vervoorn <wvervoorn(a)eltan.com>: ]> Hello, ]> ]> ]> ]> I am trying to build CoreBoot from Windows using MingGW. ]> ]> ]> ]> After downloading the latest version of the complete package to enable ]> this it is possible to build this without problem. ]> ]> ]> ]> As this package contains an old version of the tree I updated this to ]> the latest one. After doing this it's not possible to build the ]> Persimmon tree any longer. ]> ]> ]> ]> In the latest CoreBoot version the Persimmon tree uses the ]> nvramtool.exe to generate "option_table.h". When this is started I get ]> a "nvramtool.exe has stopped working message" is anyone familiar with ]> that? Is there a solution for this so I can get the tree building with the latest version as well? ] ]My guess is that nvramtool won't work on any Windows build since Windows most likely blocks CMOS ](nvram) access. ]Most developers are using Linux; if you are in dire need of a persimmon coreboot.rom: please say so (I or ]someone else can send you one off-list). I looked at this problem a while back and found the same thing as you. Because Windows blocks direct hardware access attempts by applications, nvramtool fails. Routing I/O access through a driver was easy until Microsoft came up with their signed driver requirement. The question in my mind is why should the coreboot build process need to access the cmos of the build machine? I assume the answer is that it does not, and accessing the cmos of the build machine is an unintentional side effect of the way nvramtool works. Thanks, Scott ]> Best regards, ]> ]> Wim Vervoorn

5 8

Re: [coreboot] Intel: How to share `tsc_freq.c` to select `UDELAY_TSC`
by Paul Menzel 08 May '13

08 May '13

Dear Aaron, Am Mittwoch, den 08.05.2013, 08:18 -0500 schrieb Aaron Durbin: > I think what you'll find is that determining this is cpu specific. understood. > I'm fairly sure it's not worth trying to generalize it. The > implementations are already associated with the chipset/cpu code. Why > move them? Because there would be a lot of copies. 19 if I am not mistaken. $ ls src/cpu/intel/ car model_65x model_f2x socket_mFCPGA478 ep80579 model_67x model_f3x socket_mPGA478 fit model_68x model_f4x socket_mPGA479M haswell model_69x slot_1 socket_mPGA603 hyperthreading model_6bx slot_2 socket_mPGA604 Kconfig model_6dx socket_441 socket_PGA370 Makefile.inc model_6ex socket_BGA956 socket_rPGA989 microcode model_6fx socket_FC_PGA370 speedstep model_1067x model_6xx socket_LGA771 thermal_monitoring model_106cx model_f0x socket_LGA775 turbo model_206ax model_f1x socket_mFCBGA479A989 I guess that is also the reason, why `udelay.c` was put into the northbridge code beforehand? For example the `udelay.c` in Sandy Bridge could use the `tsc_freq.c` from Haswell. Thanks, Paul

2 1

Intel: How to share `tsc_freq.c` to select `UDELAY_TSC`
by Paul Menzel 08 May '13

08 May '13

Dear coreboot folks, after having looked at how to port Aaron’s commit commit 7cb1ba9a61b244800eb65c08729f75d85a504de3 Author: Aaron Durbin <adurbin(a)chromium.org> Date: Wed May 1 15:39:28 2013 -0500 haswell: use tsc for udelay() Instead of using the local apic timer for udelay() use the tsc. That way SMM, romstage, and ramstage all use the same delay functionality. Reviewed-on: http://review.coreboot.org/3169 to the i945-based T60, it looks like the following code +#include <stdint.h> +#include <cpu/x86/msr.h> +#include <cpu/x86/tsc.h> +#include "cpu/intel/haswell/haswell.h" + +unsigned long tsc_freq_mhz(void) +{ + msr_t platform_info; + + platform_info = rdmsr(MSR_PLATFORM_INFO); + return HASWELL_BCLK * ((platform_info.lo >> 8) & 0xff); +} is generic enough and can be used by the northbridges i945, i5000 and Sandy Bridge as #define MSR_PLATFORM_INFO 0xce is true for the three of them. So where should `tsc_freq.c` be put and how should the header be included? Thanks, Paul

2 2

Re: [coreboot] X201 porting
by Peter Stuge 07 May '13

07 May '13

George Chriss wrote: > Which BIOS<->Bus Pirate pin assignments + serial mode are you using? Unclear which bus pirate pins, but you need 5 connections to the chip; GND SCK SI SO CS# > Is the 'additional power supply' provided by the '3V3' pin on the > Bus Pirate or an external power supply? Are there any special > instructions on keeping the laptop powered or should the laptop be > fully 'off'? Don't connect a common power supply to the programmer and the mainboard, only ground. For most reliable operation, disconnect power cable and remove battery. Keep laptop powered off. Connect programmer. Connect laptop power cable but not battery. Run flashrom on second computer. //Peter

1 0

X201 porting
by George Chriss 07 May '13

07 May '13

> From phcoder(a)gmail.com Wed Jan 16 21:16:43 2013 > Date: Wed, 16 Jan 2013 21:16:43 +0100 > Subject: [coreboot] X201 porting > Message-ID: <50F70AAB.7030007(a)gmail.com> > > Hello, all. I've began porting coreboot to X201 laptop. I've analysed > the original firmware (Phoenix). Video in original firmware is inited by > VGA ROM. The firmware chip is an MX25L6445E SOIC8 package, 8 Mibibytes. > Flashable externally with buspirate but you need an additional power > supply and make sure that cable from chip to buspirate don't exceed ~10cm. > One part of original consists of EFI executables. I've replaced the > executables there with my own and when it ran, the RAM was already > inited but not PCI. Lenovo x201i also uses a Macronix MX25L6445E chip and I'd like to give it a try using a Bus Pirate (ver. 3.6). Which BIOS<->Bus Pirate pin assignments + serial mode are you using? Is the 'additional power supply' provided by the '3V3' pin on the Bus Pirate or an external power supply? Are there any special instructions on keeping the laptop powered or should the laptop be fully 'off'? I'm currently running a modified BIOS to bypass MiniPCI whitelist checks.[1] Is there a way to have the Pirate save a known-good backup should flashing fail? I've found flashrom-generated BIOS backups to be problematic vs. external flashing. Any other step-by-step guidance on the flashing process would also be helpful. Sincerely, George [1] http://www.thinkwiki.org/wiki/Problem_with_unauthorized_MiniPCI_network_card > I attach the pcidump and memory maps from normal boot (normalboot.txt) > and when I insert GRUB in BIOS (grubinbios.txt). As you can see the > devices visible in both modes differ. Especially communication > controllers and PCI-PCI bridge. I attach 2 programs: x201_analyze and > x201_reconstruct. With them you can split the original (and create > descriptive XML) and then recreate firmware with changed files. I could > with it also remove files from pack 1 in order to free up some space and > so modified BIOSes continued to boot. lzint code is borrowed from phdeco. > Right now the only working output console is through the use of system > speaker ("spkmodem") and analysing it on another machine. The keyboard > works for input. I've added "spkmodem" to GRUB for this but this code > depends on having calibrated TSC. I'll adjust it to use only PIT instead > and will contribute to coreboot then. > My next step is to remove all parts of original BIOS which are not used > to executed before the point I was able to take over and put in a > coreboot in freed space and launch it from small .efi to take over the > boot at this point. How much more init is needed from this point to > booted kernel? Especially how much new code fro coreboot is needed. > In the next stage I'l be working on eliminating original memory initer > and replace it with coreboot one. > -- > Regards > Vladimir '?-coder/phcoder' Serbinenko >

1 0

Re: [coreboot] cooperative multitasking
by Aaron Durbin 06 May '13

06 May '13

Updated patches: remote: http://review.coreboot.org/3204 remote: http://review.coreboot.org/3205 remote: http://review.coreboot.org/3206 remote: http://review.coreboot.org/3207 On Mon, May 6, 2013 at 9:26 AM, Aaron Durbin <adurbin(a)chromium.org> wrote: > On Fri, May 3, 2013 at 4:27 PM, Aaron Durbin <adurbin(a)chromium.org> wrote: >> Hi, >> >> I just uploaded some patches that implement the ability to >> cooperatively multitask on the boot cpu. The patches still need some >> cleaning up, but I wanted to start the conversation. Fwiw, Ron claims >> he needs this. So blame him. This notion does allow for people to >> write state machines using the callbacks and can still rely on >> synchronous programming. >> >> Patches are here: >> remote: http://review.coreboot.org/3191 >> remote: http://review.coreboot.org/3192 >> remote: http://review.coreboot.org/3193 > > I'm going to work on a revised set of patches that makes things less > ugly. I'll also attempt to split out the arch-specific code bits so > that adding arm support, for instance, should be easier. The current > behavior of the patches does not please me because it changes the > behavior of the boot sequence without the user knowing. A more > explicit opt-in for creating threads will be employed. > > -Aaron

1 0

Building AMD Persimmon in MinGW
by Wim Vervoorn 06 May '13

06 May '13

Hello, I am trying to build CoreBoot from Windows using MingGW. After downloading the latest version of the complete package to enable this it is possible to build this without problem. As this package contains an old version of the tree I updated this to the latest one. After doing this it's not possible to build the Persimmon tree any longer. In the latest CoreBoot version the Persimmon tree uses the nvramtool.exe to generate "option_table.h". When this is started I get a "nvramtool.exe has stopped working message" is anyone familiar with that? Is there a solution for this so I can get the tree building with the latest version as well? Best regards, Wim Vervoorn

2 1

Re: [coreboot] Terminology
by Peter Stuge 06 May '13

06 May '13

> a simple CL I guess that CL may be another term for "commit", but coreboot uses Git, where the correct term for "commit" is "commit" and nothing else. Please remember to use the correct term in the community, to avoid any unneccessary confusion. Thanks //Peter

1 0

Re: [coreboot] cooperative multitasking
by Aaron Durbin 06 May '13

06 May '13

On Fri, May 3, 2013 at 4:27 PM, Aaron Durbin <adurbin(a)chromium.org> wrote: > Hi, > > I just uploaded some patches that implement the ability to > cooperatively multitask on the boot cpu. The patches still need some > cleaning up, but I wanted to start the conversation. Fwiw, Ron claims > he needs this. So blame him. This notion does allow for people to > write state machines using the callbacks and can still rely on > synchronous programming. > > Patches are here: > remote: http://review.coreboot.org/3191 > remote: http://review.coreboot.org/3192 > remote: http://review.coreboot.org/3193 I'm going to work on a revised set of patches that makes things less ugly. I'll also attempt to split out the arch-specific code bits so that adding arm support, for instance, should be easier. The current behavior of the patches does not please me because it changes the behavior of the boot sequence without the user knowing. A more explicit opt-in for creating threads will be employed. -Aaron

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
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 May 2013