[coreboot] Supermicro H8QME-2+ mct_d fatal exit.

Rudolf Marek r.marek at assembler.cz
Fri Mar 12 12:20:56 CET 2010


> 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?!
>
>   

There is a multiplexer on SMBus, this confirms my theory. Please check
the GPIO.

Imagine the multiplexer acts as some kind of rail switch. The
transactions on smbus never reach thhe memory chips (the SPD eeprom).
You need to find a pin to control the multiplexer.

Rudolf



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






More information about the coreboot mailing list