[coreboot] locking...

[Carl-Daniel Hailfinger]

On 24.06.2009 18:29, Myles Watson wrote:
>>> at the default 8KB). This might solve booting, but I'll still have APs
>>>       
>> and
>>     
>>> BSP talking all at once, which I'm also seeing on K10.
>>>       
>> I tried with a 32KB stack and a 64KB stack, no change, the machine still
>> resets itself:
>>
>>   http://ward.vandewege.net/coreboot/h8dme/minicom-20090624e.cap
>>     
>
> Maybe this is a silly suggestion, but how hard would it be to write a script
> that unscrambled the output?
>   

I did it by hand. Not pleasant, but see below.
[...]
Copying data from cache to RAM -- switching to use RAM as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now
Clearing initial memory region: Done
Jumping to image.
Jumping to image.
Check CBFS header at fffe0fd0
Check CBFS header at fffe0fd0
magic is 4f524243
Found CBFS header at fffe0fd0
magic is 4f524243
Found CBFS header at fffe0fd0
Check normal/payload
CBFS: follow chain:
Check normal/payload
ffCfB0F0S0:0 0f o+l l2o8w  +c h1a0i0n7:6  f+f fa0l0i0g0n0  -+>  2f8f f+1
0100a0076
 +Ch eaclki gnno r-m>a lf/fcfo1r0e0bao0ot
_Crhaemck

It's obvious that the CBFS code is called on each core. Note that even
if CBFS can handle this, concurrent lzma decompression to the same area
is guaranteed to kill the machine: lzma uses the destination memory
range as scratch space during decompression.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/