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
]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
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
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
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
> 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
>
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
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
> 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
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
