On Sun, Jul 9, 2017 at 2:56 AM, Andrey Korolyov wrote:
>>
>> I'd expect the clockgen to be the culprit too. But this C-state number
>> could be a typo and also be the reason for your trouble (though, I'd
>> wonder why it works on the T60). This number is used to map ACPI C-state
>> semantics to th
>
> I'd expect the clockgen to be the culprit too. But this C-state number
> could be a typo and also be the reason for your trouble (though, I'd
> wonder why it works on the T60). This number is used to map ACPI C-state
> semantics to the states presented in _CST. ACPI knows three C states and
> t
On 08.07.2017 15:43, Andrey Korolyov wrote:
>> From git logs it looks like configuring the clockgen was needed for the
>> x60/t60 port for deeper c-states to work. I'd try to dump the clockgen
>> configuration on smbus with block operations ('i2cdump #smbus 0x69 s')
>> and configure it using block
> From git logs it looks like configuring the clockgen was needed for the
> x60/t60 port for deeper c-states to work. I'd try to dump the clockgen
> configuration on smbus with block operations ('i2cdump #smbus 0x69 s')
> and configure it using block write operations either in romstage (look
> at t
>
> 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
On Thu, Jul 6, 2017 at 8:47 PM, Zoran Stojsavljevic
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
> 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 = d000h, and the next 256MiB are r
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
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.o
Andrey (Korolev),
You got all my points. Both of them. It is on you... What you'll do.
But whatever you do, please, post results here. :-)
Zoran
On Thu, Jul 6, 2017 at 2:06 PM, Andrey Korolyov wrote:
> On Thu, Jul 6, 2017 at 8:20 AM, Zoran Stojsavljevic
> wrote:
> > OK, both Andrjusas,
> >
>
On Thu, Jul 6, 2017 at 8:20 AM, Zoran Stojsavljevic
wrote:
> OK, both Andrjusas,
>
> I am a bit ignorant, and I read beginning of the Coreboot log:
>
> DIMM 0 side 0 = 1024 MB
> DIMM 0 side 1 = 1024 MB
> DIMM 2 side 0 = 1024 MB
> DIMM 2 side 1 = 1024 MB
> tRFC = 43 cycles
> Setting Graphics Freque
OK, both Andrjusas,
I am a bit ignorant, and I read beginning of the Coreboot log:
DIMM 0 side 0 = 1024 MB
DIMM 0 side 1 = 1024 MB
DIMM 2 side 0 = 1024 MB
DIMM 2 side 1 = 1024 MB
tRFC = 43 cycles
Setting Graphics Frequency...
FSB: 667 MHz Voltage: 1.05V Render: 250MHz Display: 200MHz
Setting Memo
On 07/05/2017 10:01 AM, Andrey Korolyov wrote:
The fourth/fifth points has very high likeness for the fact that the
regular kernel debugging would not help at all and I hardly imagine
myself spending few more days to manage firewire memory 'sniffer' to
work, though this method has highest succ
On Thu, Jul 6, 2017 at 12:27 AM, Nico Huber wrote:
> I'd start with examining the coreboot console log. Are there resource
> conflicts? Are all APs initialized? Was the microcode updated for all
> of them? etc... If you don't have it already, you can grab the log from
> your running non-smp OS wit
I'd start with examining the coreboot console log. Are there resource
conflicts? Are all APs initialized? Was the microcode updated for all
of them? etc... If you don't have it already, you can grab the log from
your running non-smp OS with `cbmem -c` (see util/cbmem/ in the coreboot
tree). Feel fr
> [1] Platform T2400/i945 ->
> http://ark.intel.com/products/27235/Intel-Core-Duo-Processor-T2400-2M-Cache-1_83-GHz-667-MHz-FSB
> ... Am I correct?
Yup.
> [2] What is GEODE in this context? 500 Mhz i486AMD Geode processor (Single
> HW threaded, one core, no HT)?
Just a remark about how I got warn
> - kernel also is unable to produce any kind of backtrace over all (easily)
available channels,
[1] Platform T2400/i945 ->
http://ark.intel.com/products/27235/Intel-Core-Duo-Processor-T2400-2M-Cache-1_83-GHz-667-MHz-FSB
... Am I correct?
[2] What is GEODE in this context? 500 Mhz *i486*AMD Geode
Hi,
since I`ve got em100 few days ago, I decided to test it against one of
my x86 devices and try to put coreboot on it at once. The selection
was Z61m (T2400 CD/i945/82801). After fixing few things in i945 code
borrowed from t60, I noticed severe problem when I tried to use SMP
kernel, because mo
17 matches
Mail list logo
