Hi all,
I'm currently running Libreboot 20150518 on ThinkPad X200, but I'd like
to switch to Coreboot (the newest stable version, 4.4). The reason is
that Libreboot seems to provide only one configuration and its build
system seems difficult to understand in comparison to Coreboot.
I'd like to use SeaBIOS (as opposed to Libreboot's GRUB) as payload - I
also would like to have coreinfo, memtest and nvramcui so that it all
provides kind of BIOS-like menu.
Is that possible using native graphics initialization without vgabios?
There are some recent references that it's possible.
I'm asking because, although I have flashing equipment (I've flashed my
X200 myself), the flashing took a lot of time, because of too long
wires, interferences from PSU etc. I don't want to be forced to flash it
again, so I want to be absolutely sure before I switch.
Dear Martin.
Thank you, your prompt reply. It is very useful to me.
I'll study the document of FSP. and tools.
Thank you.
2016-06-02 오전 5:23에 Martin Roth 이(가) 쓴 글:
> 1) The MRC cache is a location for saving the state of the memory
> registers. These values are typically used to restore the memory
> controller state on resume from S3 suspend, or to help the system boot
> faster. On systems using the Rangeley FSP it is not optional as it is
> on some other platforms.
>
> 2) The file you see in cbfs is actually just a placeholder. If you
> look in that area of the rom, you'll see that it's empty. It's just
> there to reserve the space for coreboot to write the memory register
> information into, and to prevent anything else from being put into
> that location.
>
> 3) The memory code for Rangeley is part of the FSP. This is currently
> only available for the Rangeley chip as a binary blob. You can
> download it, along with the FSP documentation and the Binary
> Configuration Tool, from Intel's website: http://intel.com/fsp
>
> Martin
>
> On Tue, May 31, 2016 at 10:38 PM, 김유석 책임연구원 <kay.kim(a)hansol.com> wrote:
>> Dear Sir.
>>
>>
>> My ENV.
>>
>> Platform : intel atom rangeley mohon peak CRB(C2358)
>>
>>
>> This time, I'm try to study for MRC(Memory Reference Code).
>>
>>
>> But, I'm can not found a some example code on coreboot source tree.(rangely)
>>
>>
>> Anyway, I'm get a some hint on last image.
>>
>>
>> Performing operation on 'COREBOOT' region...
>> Name Offset Type Size
>> cbfs master header 0x0 cbfs header 32
>> fallback/romstage 0x80 stage 24356
>> config 0x6040 raw 440
>> revision 0x6240 raw 567
>> cmos_layout.bin 0x64c0 cmos_layout 1316
>> fallback/dsdt.aml 0x6a40 raw 8074
>> payload_config 0x8a40 raw 1574
>> payload_revision 0x90c0 raw 244
>> (empty) 0x9200 null 27800
>> mrc.cache 0xfec0 mrc_cache 65536
>> cpu_microcode_blob.bin 0x1ff00 microcode 167936
>> fallback/ramstage 0x48f80 stage 48170
>> fallback/payload 0x54c00 payload 61309
>> (empty) 0x63bc0 null 1163992
>> fsp.bin 0x17fec0 fsp 389120
>> (empty) 0x1def00 null 133528
>> bootblock 0x1ff8c0 bootblock 1528
>>
>>
>> Question.
>>
>> 1. What purpose the "mrc.cache"?
>>
>> 2. Where to location the source code for "mrc.cache" ?
>>
>> 3. How modify the MRC ? for the sdram.
>>
>>
>> Thank you.
>>
>>
>>
>>
>>
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>
>
Hi phcoder,
I'm trying to resolve a question that came up with inteltool &
autoport regarding how the probing of graphics should behave.
Stefanct kept having his board reboot when he was running autoport, so
he added this change to separate out the graphics call as "unsafe"
when probing all.
https://review.coreboot.org/#/c/14627/4
Because this changes the behavior of autoport, I suggested we ask the
user what they want to do when running autoport.
https://review.coreboot.org/#/c/14901/
What's your opinion?
Martin
Dear Sir.
My ENV.
Platform : intel atom rangeley mohon peak CRB(C2358)
This time, I'm try to study for MRC(Memory Reference Code).
But, I'm can not found a some example code on coreboot source tree.(rangely)
Anyway, I'm get a some hint on last image.
Performing operation on 'COREBOOT' region...
Name Offset Type Size
cbfs master header 0x0 cbfs header 32
fallback/romstage 0x80 stage 24356
config 0x6040 raw 440
revision 0x6240 raw 567
cmos_layout.bin 0x64c0 cmos_layout 1316
fallback/dsdt.aml 0x6a40 raw 8074
payload_config 0x8a40 raw 1574
payload_revision 0x90c0 raw 244
(empty) 0x9200 null 27800
*mrc.cache 0xfec0 mrc_cache 65536*
cpu_microcode_blob.bin 0x1ff00 microcode 167936
fallback/ramstage 0x48f80 stage 48170
fallback/payload 0x54c00 payload 61309
(empty) 0x63bc0 null 1163992
fsp.bin 0x17fec0 fsp 389120
(empty) 0x1def00 null 133528
bootblock 0x1ff8c0 bootblock 1528
*Question.*
1. What purpose the "mrc.cache"?
2. Where to location the source code for "mrc.cache" ?
3. How modify the MRC ? for the sdram.
Thank you.
Hi Iru,
>From T420 manual [1]:
"Memory: Up to 8GB DDR3 - 1333MHz (2 DIMM Slots)"
While it seems possible to use 16GB (2x 8GB), it isn't possible to use
16GB DIMMs.
I haven't tested by myself, but it seems like a hardware limitation.
Please provide raminit logs, just to make sure.
Regards,
Patrick
[1]
http://www.lenovo.com/shop/americas/content/pdf/notebooks/ThinkPad/t-series…
On 2016-05-31 05:04 AM, Iru Cai wrote:
> Hi,
>
> I'm tesing to see if the coreboot Sandy/Ivy MRC supports 16GB DIMMs.
> Here's my result.
>
> I'm using a MT16KTF2G64HZ-1G6A1[1]. My machine is Lenovo T420 with
> i7-3630QM. With this module inserted (I've tested 16G+0 and 16G+8G),
> the system can light up, but it'll then get crashed.
> - with GRUB2 payload, it'll crash after the payload loads
> - with SeaBIOS payload with proprietary VGABIOS, I can see the prompt,
> and can boot to a GRUB or syslinux loader on my USB stick, but when I
> try to boot a system, it get crashed. If I boot to Memtest86+ on my
> USB stick, the system will crash when memtest starts to test the
> memory.
>
> And another thing I can see is, the first boot can boot to payload,
> but the second boot will fail. I think it's caused by the MRC cache.
>
> I'm still wondering if Sandy/Ivy northbridge can support 16GB DIMMs.
> I'll give a more detailed EHCI debug output later. According to [2], I
> think the incompatibility is an MRC issue instead of hardware
> incompatibility.
>
> [1]
> https://www.micron.com/parts/modules/ddr3-sdram/mt16ktf2g64hz-1g6?pc={E1D8F…
> [2]
> http://www.intelligentmemory.com/fileadmin/download/compatibilitylist.pdf
>
> Iru.
