[coreboot] x86: best approach to debug consumer hardware?

[Andrey Korolyov]

On Thu, Jul 6, 2017 at 8:47 PM, Zoran Stojsavljevic
<zoran.stojsavljevic at gmail.com> wrote:
>> The simplest and most obvious explanation turned out to be true, the
>> register is encoded as multiples of 16MiB.
>
> You say (in other words) the following: Coreboot prepares the whole
> populated 32 bit (physical layout) DRAM2 space for some OS, don't you?
>
> TOLUD = d0000000h, and the next 256MiB are reserved for MM PCI + MM PCIe
> (Yonah is Y2006, so PCIe came in Y2004), so somewhere above there will be
> PCI configuration space (minimum 64K x 256 = 16MiB, maybe more, since some
> ports are PCIe), Then HSEG, after boot FLASH.
> _______
>
> Well, Andrey, if Nico is right, you have reduced options... Dracut stays as
> one of very seldom options to try, don't you agree?
>
> Zoran
>
> On Thu, Jul 6, 2017 at 5:44 PM, Nico Huber <nico.h at gmx.de> wrote:
>>
>> On 06.07.2017 07:20, Zoran Stojsavljevic wrote:
>> > Top of Low Usable RAM 00d0h??? Any explanation for that?
>>
>> The simplest and most obvious explanation turned out to be true, the
>> register is encoded as multiples of 16MiB.
>>
>> Nico
>
>


Thanks everyone, the explanation was pretty simple - the _CST package
generated for model 6ex does not fit this exact CPU (6e8), as soon as
stuff under CONFIG_ACPI_PROCESSOR has been loaded, system dies,
sometimes with visible screen mess. Workaround for now is to use
processor.nocst=1 and for Windows to use UP boot.

For now, I may simply disable the _CST entirely leaving only frequency
scaling options, though this is far from being appropriate for the
public port.