[coreboot] romcc segfaults; serious help needed
Hi guys,
I posted a new 440BX RAM init code a few days ago that was segfaulting
romcc, and I didn't get any response.
In the meantime I have narrowed the cause to this code fragment, with enough
wrapper added so it can be fed to romcc on its own:
void romcc_fail(void) {
int dimm03 = 0;
int dimm47 = 0;
char mbsc[5];
char mbfs[3];
/* begin actual fragment */
if (dimm03 > 2) {
mbsc[4] |= 0x80;
mbsc[1] |= 0x28;
mbfs[2] |= 0x40;
mbfs[0] |= 0x60;
} else {
mbsc[4] |= 0xc0;
mbsc[1] |= 0x3c;
}
if ((dimm03 + dimm47) > 4) {
mbsc[4] = 0xba;
mbsc[0] = 0x30;
mbfs[0] |= 0x02;
} else {
mbsc[0] = 0x2c;
}
if (dimm47 > 2) {
mbsc[4] |= 0x20;
mbsc[1] |= 0x02;
mbsc[0] |= 0x80;
mbfs[2] |= 0x20;
mbfs[0] |= 0x18;
} else {
mbsc[4] |= 0x30;
mbsc[1] |= 0x03;
mbsc[0] |= 0xc0;
}
/* end actual fragment */
}
There are three similar constructs, any one of them is enough to cause a
segfault.
mbfs and mbsc are meant to be an array of bytes that make up the MBFS and
MBSC registers in the 440BX, to be written out to it once they're all set.
Thanks for all help
Keith
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] "How come it's so slow?"
> On 3/9/10, Ed Swierk wrote: >> On Fri, Mar 5, 2010 at 8:58 AM, ron minnich wrote: >>> Just got a new nehalem box in for test yesterday. Experiences so far: >>> >>> 1. POST from power-on takes 45 seconds. *45 SECONDS*. Now, I had it >>> said to me at SCALE7x last year from someone from Intel that all new >>> BIOSes on Intel chips are really EFI underneath -- is this indicative >>> of what we are to expect? If so, it's awful. It's 15 times slower than >>> what we had ten years ago, and 50 times slower than what we can do >>> today on coreboot. >> >> As far as I can tell the sole purpose of EFI is to make it easier for >> hardware vendors to shovel more junk into the BIOS by removing the >> hurdle of hand-coding 16-bit assembly. >> >> But while EFI might accelerate the trend, it's not the only villain. >> Someone noticed a 9x growth in boot time on qemu recently >> (http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg00546.html ). >> Even on a virtual platform with no actual hardware to initialize, boot >> time will grow unless someone is actively pushing the other way. >> >> Ultimately the system board vendors are responsible for the BIOS in >> the boards we buy. They are the ones cutting deals with Intel and AMI >> and Phoenix, and can exert the necessary leverage. But they won't, >> until they see 1-second cold boot as a feature that will sell more >> boards. >> >> --Ed >> Sorry about the double post. Something went wrong with my mail client. Anyway, perhaps these articles by vid is a nice addition: http://x86asm.net/articles/introduction-to-uefi/index.html http://x86asm.net/articles/uefi-programming-first-steps/index.html -Darmawan -- -= Human knowledge belongs to the world =- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] "How come it's so slow?"
I think every UEFI/EFI implementation will boot to "old school" boot mode when it can't find any EFI/UEFI-compliant boot-device/boot-partition. It would take too long though but at least the fallback is there. -Darmawan On 3/9/10, Ed Swierk wrote: > On Fri, Mar 5, 2010 at 8:58 AM, ron minnich wrote: >> Just got a new nehalem box in for test yesterday. Experiences so far: >> >> 1. POST from power-on takes 45 seconds. *45 SECONDS*. Now, I had it >> said to me at SCALE7x last year from someone from Intel that all new >> BIOSes on Intel chips are really EFI underneath -- is this indicative >> of what we are to expect? If so, it's awful. It's 15 times slower than >> what we had ten years ago, and 50 times slower than what we can do >> today on coreboot. > > As far as I can tell the sole purpose of EFI is to make it easier for > hardware vendors to shovel more junk into the BIOS by removing the > hurdle of hand-coding 16-bit assembly. > > But while EFI might accelerate the trend, it's not the only villain. > Someone noticed a 9x growth in boot time on qemu recently > (http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg00546.html ). > Even on a virtual platform with no actual hardware to initialize, boot > time will grow unless someone is actively pushing the other way. > > Ultimately the system board vendors are responsible for the BIOS in > the boards we buy. They are the ones cutting deals with Intel and AMI > and Phoenix, and can exert the necessary leverage. But they won't, > until they see 1-second cold boot as a feature that will sell more > boards. > > --Ed > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -- -= Human knowledge belongs to the world =- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Supermicro H8QME-2+: Dumping smbus registers (was: Supermicro H8QME-2+ mct_d fatal exit.)
Dear Knut, Am Mittwoch, den 10.03.2010, 17:26 +0100 schrieb Knut Kujat: […] > I know that because I found a nice piece of code dumping smbus registers > on the h8dme board :D thx to the autor!! is it possible to share that piece of code? […] Anyway, nice to hear you ar making some progress and good luck with the next steps! Thanks, Paul signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
Hi, I finally know that my issue must be related with the smbus registers because on a vendor bios running machine and using i2cdetect and i2cdump I get several values for different i2c devices detected, I get the same values when I successfully start with coreboot. But when I start with coreboot and fail with mcr_d fatal exit those registers are blank, I know that because I found a nice piece of code dumping smbus registers on the h8dme board :D thx to the autor!! I also know that reading these registers out may cause them to get lost! I'm not sure why?! Now my question is how do I initialize these registers with the values known from the vendor BIOS? smb_write_byte doesn't seems to work or maybe I'm using it wrong. THX, Knut Kujat. Knut Kujat escribió: > Hello, > > thx all of you for your comments. Here a little update :) > > I now know why the boards worked just fine up here in my lab. To know if > the board would work after being unplugged I always "only" unplugged the > electrical cable but never the monitor attached to the board I figured > out that the monitor is providing enough juice to maintain whatever > alive in the board so after plugging the electrical cable on again > coreboot started fine. Another thing I figured out is that it seems that > the front leds of the board a managed by GPIO as well, is this right? If > so it seems that something is wrong with GPIO because the power on led > never works with coreboot. > > thx, > Knut Kujat. > > > > ron minnich escribió: > >> Just FYI: >> >> on our first system with Arima boards in 2002, everything worked well >> until we started booting 64-bit kernels. I'm not kidding. We did not >> find the SMBUS MUX on the boards until we had unreliable coreboot >> boots of 64-bit kernels. For quite some time the boards worked fine. >> Ollie found the SMBUS MUX by examining schematics. >> >> So the SMBUS mux can appear in strange ways, at strange times. This >> sounds like one of those times. SMBUS muxes are more common than you >> might think and the default power-on state is not always very well >> determined. >> >> ron >> >> >> > > > -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] revive llshell
Am 07.03.2010 15:40, schrieb Stefan Reinauer: > Ron and Peter should like this "Panic Room" there you go. > > It's of course completely useless if the machine hangs. It could be made > part of "die()" though. Maybe guard the Kconfig option with "depends on CONFIG_EXPERT"? With or without, it's Acked-by: Patrick Georgi -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
