[coreboot] K8 and Fam10 CAR

[Carl-Daniel Hailfinger]

Hi Yinghai,

can you please look at the problems below?

On 06.08.2008 18:54, Marc Jones wrote:
> Carl-Daniel Hailfinger wrote:
>> I'm currently working to unify K8 and Fam10 CAR to use the same code at
>> runtime (as opposed to buildtime #ifdefs). While this may not be a goal
>> for v2, I definitely want to try it for v3.
>>
>> A few questions/comments about the CAR code:
>> - Only Fam10 APs are treated specially. APs of older generations seem to
>> be unhandled. Did older generations treat each core as BSP (code seems
>> to suggest that) or were there other special provisions?
>
> I don't know. I haven't used or worked on that code. YH would be the
> better person to ask. For the fam10 code there are some settings that
> can only be set from the AP cores.

Older BKDGs indicate that we should treat all APs specially. That would
be a missing feature in the old code.


>> - CAR goes from 0xC8000 to 0xCFFFF. Assuming GlobalVarSize=0 (untrue,
>> but easier to calculate), BSP stack will be from 0xCC000 to 0xCFFFF and
>> AP stacks will be below 0xCBFFF.
>> * With the current settings (32k CAR total, 1k per AP, 16K for the BSP)
>> the scheme will fall apart if the highest NodeID shifted by the number
>> of CoreID bits is 16 or higher. The BKDG indicates that the number of
>> CoreID bits is 2, so a NodeID of 4 or higher will break.
>
> Yes. This was sufficient for the K8 and was not changed when I added
> fam10. 8 dual core K8 was the most you could have. It could probably
> be expended into the rest of the shadow hole (up to FFFFF) if needed.
> The reason to keep it in the hole is for memory eye finding that will
> happen from 1MB to TOM.

We may need to revisit this for Family 10h. What's the maximum number of
cores in one Family 10h system?


>> * There is no good place to store the printk() buffer in CAR. On Geode
>> and i586, the printk buffer runs from the lowest address of the CAR area
>> to the middle. Keeping that design will result in the AP stacks
>> colliding with the printk buffer. Limiting the size of the printk buffer
>> dynamically would work unless there are more than 15 cores in the
>> system, where even a printk buffer of zero size would clobber one AP
>> stack. The other alternative is to keep the printk buffer size fixed and
>> let the AP stacks eat into BSP stack space.
>
> This was the problem I mentioned when you were doing the printk()
> buffer. You are not guaranteed the use of the cache.

I think I can fix that. If APs are only started after the BSP has
initialized DRAM, there is no problem because the printk() buffer is
relocated directly after DRAM init.


>> - Is there any reason on any K8 or later processor supported by the
>> current CAR code not to use 64k CAR?
>
> To leave room for APs? There may have been some concern about small
> cache versions be introduced?

The various BKDGs state that L1 cache tag indexes of 00h - FFh are
reserved for memory training and recommend to use exactly 48k CAR. I
intend to follow that advice.
By the way, the AP CAR areas in our code are inside the BSP CAR area.


>> - Is 1k enough stack for the APs, given some stack-heavy functions in
>> v3?
>
> I don't know for sure but I would expect it to be ok.
>
>> - Can the K8 processors work reliably with 0x1e1e1e1e settings in the
>> fixed MTRR or can the Fam10 processors work with 0x06060606?
>
> No.

OK, I will work on a generic code sequence for this problem. Does Family
11h need 0x1e or 0x06?


Regards,
Carl-Daniel

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