Hi everyone,
I would like to update you with my current x220 status:
1) *DDR3 Speed:*
- My goal was to get 1866Mhz DDR3 speed (tCK = 933Mhz);
- I'm using 2 of these modules: CRUCIAL_CT8G3S186DM.M16F
<http://www.crucial.com/usa/en/ct8g3s186dm>;
- With default coreboot-4.4 I was getting just 1333MHz (tCK = 666MHz):
dmidecode <http://pastebin.com/Zvfs9QAD>;
- After editing coreboot source (check below), I'm getting 1600Mhz (tCK
= 800MHz): dmidecode <http://pastebin.com/KR0RVZ0z>*;*
- The patch is very simple (Thanks a lot for your help Iru):
- Edit src/northbridge/intel/sandybridge/raminit.c;
- Add: 'return TCK_933MHZ;' to the very beginning of
get_mem_min_tck(void) function;
- This avoid automatic detection of the capabilities and makes
coreboot(?) think that the min_freq is 1866MHz;
- As I said, doing this gave me just 1600MHz so, as a paranoid
check, I decided to use 'return TCK_1066MHZ;'
- Using tCK = 1066MHz also gave me just 1600MHz (my current
firmware build is using tCK = 1066MHz);
- Apparently, the patch works and that makes me happy :) So the
question is: Why 1866MHz is not being applied?:
- I found a better tool to get DIMM info: command is decode-dimms,
from i2c-tools package (don't forget to load eeprom module);
- With decode-dimms I get much more info than with dmidecode. Current
output of my x220 is here <http://pastebin.com/fMDW9XFw>;
- In this output we can see: Maximum module speed: 1777 MHz
(PC3-14200);
- This makes think these Crucial modules cannot reach 1866MHz and
that's why I'm getting only 1600MHz. Unfortunately I don't
have any other
1866MHz modules to test;
- In resume, I think there's nothing more we can do here. Good
progress anyway. Thanks everyone.
2) *Battery Charging Thresholds:*
- tp_smapi is not supported;
- tpacpi-bat doesn't work either:
- [~]$ tpacpi-bat -v -g ST 1
Error: AE_NOT_FOUND for ASL base: \_SB.PCI0.LPCB.EC.HKEY
Error: AE_NOT_FOUND at /usr/bin/tpacpi-bat line 409.
[~]$
- I think '\_SB.PCI0.LPCB.EC.HKEY' is not found...
- acpidump is here <http://pastebin.com/G3UZQNbX>;
- In TLP I get: tpacpi-bat = inactive (unsupported hardware);
- Any ideas here?
3) *Internal MIC device:*
- I cannot mute internal MIC (it was possible with official firmware);
- Even if I try to mute it using pavucontrol, the MIC mute led never
gets on;
- Any ideas here?
I still have some tests and validations ongoing, but the issues present are
the only open topics at the moment.
Hope it helps and I'm looking forward for your feedback.
Thanks in advance.
--sigkill
On Wed, May 25, 2016 at 12:06 PM, Nuno Moreira <naomoreira(a)gmail.com> wrote:
> Hello Zoran, Hello everybody,
>
> Thanks for your reply Zoran.
> I'll try to give all the details about it. Maybe you are missing some
> important detail.
>
> 1 - Laptop was with official BIOS_1.29 / EC_1.20;
> 2 - From windows, updated to official BIOS_1.40 / EC_1.24;
> 3 - From windows, installed custom 8duj26us_NWL_ADV_AES_PM_Speedo;
> 4 - Custom BIOS unlocked Advanced Menu (with tons of chipset related
> options);
> 5 - 2x8GB DDR3-1866Mhz modules installed. Changed RAM speed to 1866Mhz in
> BIOS;
> 6 - Booted to Archlinux and dmidecode reported 1333Mhz as RAM speed;
> 7 - I went back to BIOS and changed RAM speed to Auto and noticed that
> SR-IOV was not activated for PCI, so I decided to activate it since I plan
> to play a little with kvm and stuff (If I recall correctly, these were the
> only 2 changes that bricked the system).
> 8 - Save and exit: BIOS bricked. Infinite boot/restart loop until I remove
> ac/battery;
> 9 - Tried to remove all the hardware and clear CMOS. Nothing worked.
> Always in boot loop.
>
> I still have the flashrom read dump of this bricked unofficial BIOS.
> Let me know i you want the dump. Maybe you can get some info from it.
>
> *Possible stupid question:* I tried to find a solution to recover this
> bricked BIOS and flash it back but I don't have the know how to do it. Do
> you think it is possible to unbrick the BIOS from the dump and flash it
> back?
>
> *PS:* I've made some progress with coreboot in the meantime (good and bad
> news). Will reply to the mailing-list after complete other tests.
>
> Thanks in advance.
> --sigkill
>
>
> On Tue, May 24, 2016 at 8:27 PM, Zoran Stojsavljevic <
> zoran.stojsavljevic(a)gmail.com> wrote:
>
>> Hello Nuno,
>>
>> Very interesting use case, I should say.
>>
>> *> 1) Init:*
>> > --------
>> > Recently I bought a refurbished x220 and flashed it with a custom BIOS
>> (Lenovo ThinkPad
>> > x220_1.40-(8DET70WW)-8duj26us_NWL_ADV_AES_PM_Speedo) because I wanted
>> to unlock the RAM speed
>> > to be 1866MHz (max RAM speed is locked to 1333Mhz in official BIOS),
>> white-list some Wi-Fi
>> > cards, Advanced Chipset Config menu, etc.
>> >
>> > This custom BIOS worked perfectly until I changed some settings related
>> with Intel VT-x. If
>> > I recall correctly, I activated SR-IOV for PCI-E, saved and exited and
>> after that x220 =
>> > BRICKED.
>> >
>> > I tried every typical troubleshooting/workaround (Removing as much HW
>> as possible, unplug
>> > BIOS battery for hours, etc), nothing worked.
>>
>> This is peculiar... How SR-IOV feature can break the BIOS??? Never saw
>> such or similar brick.
>>
>> Taking to account that introduced custom BIOS (Lenovo ThinkPad
>> x220_1.40-(8DET70WW)-8duj26us_NWL_ADV_AES_PM_Speedo) added (probably)
>> additional few Memory Reference Code algorithms to make DDR3 work @
>> 1866MHz, I have no clue how these two parameters are connected/in
>> relations.
>>
>> But I'll try to investigate this use case. Not (at all) in connection
>> with Coreboot, rather I would like to understand why SNB BIOS behaves like
>> this? Maybe I can learn much more out of this?!
>>
>> I'll move this to other (BIOS based) forum, and try to see if there are
>> more experienced BIOS people to put some light on/demystify this problem?
>>
>> It is, after all, Sandy Bridge CORe:
>> http://thinkwiki.de/X220#Technische_Daten
>>
>> http://ark.intel.com/products/52229/Intel-Core-i5-2520M-Processor-3M-Cach...
>>
>> Let me see what I can dig out of this? ;-)
>>
>> Best Regards,
>> Zoran
>>
>> On Mon, May 23, 2016 at 3:00 PM, Nuno Moreira <naomoreira(a)gmail.com>
>> wrote:
>>
>>> Hello, everyone.
>>>
>>> First of all, I would like to thanks and to congratulate all the
>>> community who helps to develop and to optimize this great project. Keep it
>>> up :)
>>>
>>> I would appreciate if you can give me some opinions or point me to
>>> someone who will, regarding the Open Issues I present below (3.1 and 3.2).
>>> Trying to give you a brief contextualization of my status before and
>>> after Coreboot.
>>>
>>> *1) Init:*
>>> --------
>>> Recently I bought a refurbished x220 and flashed it with a custom BIOS
>>> (Lenovo ThinkPad x220_1.40-(8DET70WW)-8duj26us_NWL_ADV_AES_PM_Speedo)
>>> because I wanted to unlock the RAM speed to be 1866MHz (max RAM speed is
>>> locked to 1333Mhz in official BIOS), white-list some Wi-Fi cards, Advanced
>>> Chipset Config menu, etc.
>>>
>>> This custom BIOS worked perfectly until I changed some settings related
>>> with Intel VT-x. If I recall correctly, I activated SR-IOV for PCI-E, saved
>>> and exited and after that x220 = BRICKED.
>>>
>>> I tried every typical troubleshooting/workaround (Removing as much HW as
>>> possible, unplug BIOS battery for hours, etc), nothing worked.
>>> x220 BIOS never booted again and the machine was in a constant boot
>>> loop. Don't know why/how this happened in the first place, but since it is
>>> a custom BIOS and it is very hard to reach the developer, I knew I could
>>> never get it to work without an intrusive method...
>>>
>>> *2) Coreboot as Salvation:*
>>> -------------------------
>>> I started to look for alternatives, and luckily, Coreboot supports x220
>>> since a couple of months ago :)
>>> After dealing with all the learning curve to understand the minimal
>>> requirements to compile and install Coreboot (tricky part is basically the
>>> need for HW flashing) I managed to get a working BIOS and x220 is now
>>> (almost 100%) operational :)
>>> I've read and used the blobs from the "damaged" custom BIOS. I'm not
>>> sure if this can affect the functionality of Coreboot. Apparently, it does
>>> not.
>>>
>>> *(Let me know if anyone of you need details/help about/with the HW
>>> flashing in this type of chip (MX25L6406E/MX25L6408E)).*
>>> *3) Coreboot rocks but... Current Open issues:*
>>> ---------------------------------------------
>>> I decided to use coreboot-4.4 release instead of git-master.
>>> As payload I'm using SeaBIOS (booting Archlinux with Syslinux as
>>> bootloader).
>>>
>>> *3.1) RAM speed:*
>>> ---------------
>>> I've 2 x 8GB DRR3-1866MHz installed. The 16GB are detected but the speed
>>> reported is just 667MHz.
>>> With the official BIOS, the max speed was 1333Mhz. Don't know how
>>> Coreboot is handling this subject in this particular main-board...
>>> DDR timings are a little bit confusing to me, I guess...
>>>
>>> Before, with dmidecode -t 17 the speed was 1333Mhz and now it is just
>>> 667Mhz...
>>> This 667MHz speed I get with coreboot is 2x667=1333Mhz or in reality is
>>> 2x333MHz?
>>> In "northbridge/intel/sandybridge/raminit.c" we can see the following
>>> statement:
>>>
>>> /* Maximum supported DDR3 frequency is 1066MHz (DDR3 2133) so make
>>> sure
>>> * we cap it if we have faster DIMMs.
>>> * Then, align it to the closest JEDEC standard frequency */
>>>
>>> *=> So, if I'm understanding it correctly, current 667 Mhz is not the
>>> maximum *
>>> *speed supported.Any idea on how I can get higher speeds?*
>>>
>>> *3.2) TP-SMAPI: *
>>> --------------
>>> Looks like tp-smapi is not available using Coreboot. It was OK with the
>>> official and custom BIOS before.
>>> From what I've read, this is not a Coreboot limitation... Not sure if
>>> the blobs/EC are not ok for tp-smapi now...
>>> I use tp-smapi for battery threshold, etc. TLP
>>> <http://linrunner.de/en/tlp/tlp.html>also uses tp-smapi. So it is kinda
>>> of important to me.
>>>
>>> *=> Anyone using tp-smapi with no problems out there?*
>>>
>>> *3.3) Config files:*
>>> ------------------
>>> coreboot - http://pastebin.com/9ymtxLBW
>>> seabios - http://pastebin.com/rUU7ajRH
>>> cmos.default - http://pastebin.com/Pm5vS15R
>>>
>>> Thanks in advance, guys.
>>> All the best \o
>>>
>>> --sigkill
>>>
>>> --
>>> coreboot mailing list: coreboot(a)coreboot.org
>>> https://www.coreboot.org/mailman/listinfo/coreboot
>>>
>>
>>
>
>
> --
> Cumprimentos / Best Regards
>
> Nuno Moreira
>
--
Cumprimentos / Best Regards
Nuno Moreira
Hello Zoran, Hello everybody,
Thanks for your reply Zoran.
I'll try to give all the details about it. Maybe you are missing some
important detail.
1 - Laptop was with official BIOS_1.29 / EC_1.20;
2 - From windows, updated to official BIOS_1.40 / EC_1.24;
3 - From windows, installed custom 8duj26us_NWL_ADV_AES_PM_Speedo;
4 - Custom BIOS unlocked Advanced Menu (with tons of chipset related
options);
5 - 2x8GB DDR3-1866Mhz modules installed. Changed RAM speed to 1866Mhz in
BIOS;
6 - Booted to Archlinux and dmidecode reported 1333Mhz as RAM speed;
7 - I went back to BIOS and changed RAM speed to Auto and noticed that
SR-IOV was not activated for PCI, so I decided to activate it since I plan
to play a little with kvm and stuff (If I recall correctly, these were the
only 2 changes that bricked the system).
8 - Save and exit: BIOS bricked. Infinite boot/restart loop until I remove
ac/battery;
9 - Tried to remove all the hardware and clear CMOS. Nothing worked. Always
in boot loop.
I still have the flashrom read dump of this bricked unofficial BIOS.
Let me know i you want the dump. Maybe you can get some info from it.
*Possible stupid question:* I tried to find a solution to recover this
bricked BIOS and flash it back but I don't have the know how to do it. Do
you think it is possible to unbrick the BIOS from the dump and flash it
back?
*PS:* I've made some progress with coreboot in the meantime (good and bad
news). Will reply to the mailing-list after complete other tests.
Thanks in advance.
--sigkill
On Tue, May 24, 2016 at 8:27 PM, Zoran Stojsavljevic <
zoran.stojsavljevic(a)gmail.com> wrote:
> Hello Nuno,
>
> Very interesting use case, I should say.
>
> *> 1) Init:*
> > --------
> > Recently I bought a refurbished x220 and flashed it with a custom BIOS
> (Lenovo ThinkPad
> > x220_1.40-(8DET70WW)-8duj26us_NWL_ADV_AES_PM_Speedo) because I wanted
> to unlock the RAM speed
> > to be 1866MHz (max RAM speed is locked to 1333Mhz in official BIOS),
> white-list some Wi-Fi
> > cards, Advanced Chipset Config menu, etc.
> >
> > This custom BIOS worked perfectly until I changed some settings related
> with Intel VT-x. If
> > I recall correctly, I activated SR-IOV for PCI-E, saved and exited and
> after that x220 =
> > BRICKED.
> >
> > I tried every typical troubleshooting/workaround (Removing as much HW as
> possible, unplug
> > BIOS battery for hours, etc), nothing worked.
>
> This is peculiar... How SR-IOV feature can break the BIOS??? Never saw
> such or similar brick.
>
> Taking to account that introduced custom BIOS (Lenovo ThinkPad
> x220_1.40-(8DET70WW)-8duj26us_NWL_ADV_AES_PM_Speedo) added (probably)
> additional few Memory Reference Code algorithms to make DDR3 work @
> 1866MHz, I have no clue how these two parameters are connected/in
> relations.
>
> But I'll try to investigate this use case. Not (at all) in connection with
> Coreboot, rather I would like to understand why SNB BIOS behaves like this?
> Maybe I can learn much more out of this?!
>
> I'll move this to other (BIOS based) forum, and try to see if there are
> more experienced BIOS people to put some light on/demystify this problem?
>
> It is, after all, Sandy Bridge CORe:
> http://thinkwiki.de/X220#Technische_Daten
>
> http://ark.intel.com/products/52229/Intel-Core-i5-2520M-Processor-3M-Cach...
>
> Let me see what I can dig out of this? ;-)
>
> Best Regards,
> Zoran
>
> On Mon, May 23, 2016 at 3:00 PM, Nuno Moreira <naomoreira(a)gmail.com>
> wrote:
>
>> Hello, everyone.
>>
>> First of all, I would like to thanks and to congratulate all the
>> community who helps to develop and to optimize this great project. Keep it
>> up :)
>>
>> I would appreciate if you can give me some opinions or point me to
>> someone who will, regarding the Open Issues I present below (3.1 and 3.2).
>> Trying to give you a brief contextualization of my status before and
>> after Coreboot.
>>
>> *1) Init:*
>> --------
>> Recently I bought a refurbished x220 and flashed it with a custom BIOS
>> (Lenovo ThinkPad x220_1.40-(8DET70WW)-8duj26us_NWL_ADV_AES_PM_Speedo)
>> because I wanted to unlock the RAM speed to be 1866MHz (max RAM speed is
>> locked to 1333Mhz in official BIOS), white-list some Wi-Fi cards, Advanced
>> Chipset Config menu, etc.
>>
>> This custom BIOS worked perfectly until I changed some settings related
>> with Intel VT-x. If I recall correctly, I activated SR-IOV for PCI-E, saved
>> and exited and after that x220 = BRICKED.
>>
>> I tried every typical troubleshooting/workaround (Removing as much HW as
>> possible, unplug BIOS battery for hours, etc), nothing worked.
>> x220 BIOS never booted again and the machine was in a constant boot loop.
>> Don't know why/how this happened in the first place, but since it is a
>> custom BIOS and it is very hard to reach the developer, I knew I could
>> never get it to work without an intrusive method...
>>
>> *2) Coreboot as Salvation:*
>> -------------------------
>> I started to look for alternatives, and luckily, Coreboot supports x220
>> since a couple of months ago :)
>> After dealing with all the learning curve to understand the minimal
>> requirements to compile and install Coreboot (tricky part is basically the
>> need for HW flashing) I managed to get a working BIOS and x220 is now
>> (almost 100%) operational :)
>> I've read and used the blobs from the "damaged" custom BIOS. I'm not sure
>> if this can affect the functionality of Coreboot. Apparently, it does not.
>>
>> *(Let me know if anyone of you need details/help about/with the HW
>> flashing in this type of chip (MX25L6406E/MX25L6408E)).*
>> *3) Coreboot rocks but... Current Open issues:*
>> ---------------------------------------------
>> I decided to use coreboot-4.4 release instead of git-master.
>> As payload I'm using SeaBIOS (booting Archlinux with Syslinux as
>> bootloader).
>>
>> *3.1) RAM speed:*
>> ---------------
>> I've 2 x 8GB DRR3-1866MHz installed. The 16GB are detected but the speed
>> reported is just 667MHz.
>> With the official BIOS, the max speed was 1333Mhz. Don't know how
>> Coreboot is handling this subject in this particular main-board...
>> DDR timings are a little bit confusing to me, I guess...
>>
>> Before, with dmidecode -t 17 the speed was 1333Mhz and now it is just
>> 667Mhz...
>> This 667MHz speed I get with coreboot is 2x667=1333Mhz or in reality is
>> 2x333MHz?
>> In "northbridge/intel/sandybridge/raminit.c" we can see the following
>> statement:
>>
>> /* Maximum supported DDR3 frequency is 1066MHz (DDR3 2133) so make
>> sure
>> * we cap it if we have faster DIMMs.
>> * Then, align it to the closest JEDEC standard frequency */
>>
>> *=> So, if I'm understanding it correctly, current 667 Mhz is not the
>> maximum *
>> *speed supported.Any idea on how I can get higher speeds?*
>>
>> *3.2) TP-SMAPI: *
>> --------------
>> Looks like tp-smapi is not available using Coreboot. It was OK with the
>> official and custom BIOS before.
>> From what I've read, this is not a Coreboot limitation... Not sure if the
>> blobs/EC are not ok for tp-smapi now...
>> I use tp-smapi for battery threshold, etc. TLP
>> <http://linrunner.de/en/tlp/tlp.html>also uses tp-smapi. So it is kinda
>> of important to me.
>>
>> *=> Anyone using tp-smapi with no problems out there?*
>>
>> *3.3) Config files:*
>> ------------------
>> coreboot - http://pastebin.com/9ymtxLBW
>> seabios - http://pastebin.com/rUU7ajRH
>> cmos.default - http://pastebin.com/Pm5vS15R
>>
>> Thanks in advance, guys.
>> All the best \o
>>
>> --sigkill
>>
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>
>
--
Cumprimentos / Best Regards
Nuno Moreira
Hello Nuno,
Very interesting use case, I should say.
*> 1) Init:*
> --------
> Recently I bought a refurbished x220 and flashed it with a custom BIOS
(Lenovo ThinkPad
> x220_1.40-(8DET70WW)-8duj26us_NWL_ADV_AES_PM_Speedo) because I wanted to
unlock the RAM speed
> to be 1866MHz (max RAM speed is locked to 1333Mhz in official BIOS),
white-list some Wi-Fi
> cards, Advanced Chipset Config menu, etc.
>
> This custom BIOS worked perfectly until I changed some settings related
with Intel VT-x. If
> I recall correctly, I activated SR-IOV for PCI-E, saved and exited and
after that x220 =
> BRICKED.
>
> I tried every typical troubleshooting/workaround (Removing as much HW as
possible, unplug
> BIOS battery for hours, etc), nothing worked.
This is peculiar... How SR-IOV feature can break the BIOS??? Never saw such
or similar brick.
Taking to account that introduced custom BIOS (Lenovo ThinkPad
x220_1.40-(8DET70WW)-8duj26us_NWL_ADV_AES_PM_Speedo) added (probably)
additional few Memory Reference Code algorithms to make DDR3 work @ 1866MHz,
I have no clue how these two parameters are connected/in relations.
But I'll try to investigate this use case. Not (at all) in connection with
Coreboot, rather I would like to understand why SNB BIOS behaves like this?
Maybe I can learn much more out of this?!
I'll move this to other (BIOS based) forum, and try to see if there are
more experienced BIOS people to put some light on/demystify this problem?
It is, after all, Sandy Bridge CORe:
http://thinkwiki.de/X220#Technische_Datenhttp://ark.intel.com/products/52229/Intel-Core-i5-2520M-Processor-3M-Cach...
Let me see what I can dig out of this? ;-)
Best Regards,
Zoran
On Mon, May 23, 2016 at 3:00 PM, Nuno Moreira <naomoreira(a)gmail.com> wrote:
> Hello, everyone.
>
> First of all, I would like to thanks and to congratulate all the community
> who helps to develop and to optimize this great project. Keep it up :)
>
> I would appreciate if you can give me some opinions or point me to someone
> who will, regarding the Open Issues I present below (3.1 and 3.2).
> Trying to give you a brief contextualization of my status before and after
> Coreboot.
>
> *1) Init:*
> --------
> Recently I bought a refurbished x220 and flashed it with a custom BIOS
> (Lenovo ThinkPad x220_1.40-(8DET70WW)-8duj26us_NWL_ADV_AES_PM_Speedo)
> because I wanted to unlock the RAM speed to be 1866MHz (max RAM speed is
> locked to 1333Mhz in official BIOS), white-list some Wi-Fi cards, Advanced
> Chipset Config menu, etc.
>
> This custom BIOS worked perfectly until I changed some settings related
> with Intel VT-x. If I recall correctly, I activated SR-IOV for PCI-E, saved
> and exited and after that x220 = BRICKED.
>
> I tried every typical troubleshooting/workaround (Removing as much HW as
> possible, unplug BIOS battery for hours, etc), nothing worked.
> x220 BIOS never booted again and the machine was in a constant boot loop.
> Don't know why/how this happened in the first place, but since it is a
> custom BIOS and it is very hard to reach the developer, I knew I could
> never get it to work without an intrusive method...
>
> *2) Coreboot as Salvation:*
> -------------------------
> I started to look for alternatives, and luckily, Coreboot supports x220
> since a couple of months ago :)
> After dealing with all the learning curve to understand the minimal
> requirements to compile and install Coreboot (tricky part is basically the
> need for HW flashing) I managed to get a working BIOS and x220 is now
> (almost 100%) operational :)
> I've read and used the blobs from the "damaged" custom BIOS. I'm not sure
> if this can affect the functionality of Coreboot. Apparently, it does not.
>
> *(Let me know if anyone of you need details/help about/with the HW
> flashing in this type of chip (MX25L6406E/MX25L6408E)).*
> *3) Coreboot rocks but... Current Open issues:*
> ---------------------------------------------
> I decided to use coreboot-4.4 release instead of git-master.
> As payload I'm using SeaBIOS (booting Archlinux with Syslinux as
> bootloader).
>
> *3.1) RAM speed:*
> ---------------
> I've 2 x 8GB DRR3-1866MHz installed. The 16GB are detected but the speed
> reported is just 667MHz.
> With the official BIOS, the max speed was 1333Mhz. Don't know how Coreboot
> is handling this subject in this particular main-board...
> DDR timings are a little bit confusing to me, I guess...
>
> Before, with dmidecode -t 17 the speed was 1333Mhz and now it is just
> 667Mhz...
> This 667MHz speed I get with coreboot is 2x667=1333Mhz or in reality is
> 2x333MHz?
> In "northbridge/intel/sandybridge/raminit.c" we can see the following
> statement:
>
> /* Maximum supported DDR3 frequency is 1066MHz (DDR3 2133) so make sure
> * we cap it if we have faster DIMMs.
> * Then, align it to the closest JEDEC standard frequency */
>
> *=> So, if I'm understanding it correctly, current 667 Mhz is not the
> maximum *
> *speed supported.Any idea on how I can get higher speeds?*
>
> *3.2) TP-SMAPI: *
> --------------
> Looks like tp-smapi is not available using Coreboot. It was OK with the
> official and custom BIOS before.
> From what I've read, this is not a Coreboot limitation... Not sure if the
> blobs/EC are not ok for tp-smapi now...
> I use tp-smapi for battery threshold, etc. TLP
> <http://linrunner.de/en/tlp/tlp.html>also uses tp-smapi. So it is kinda
> of important to me.
>
> *=> Anyone using tp-smapi with no problems out there?*
>
> *3.3) Config files:*
> ------------------
> coreboot - http://pastebin.com/9ymtxLBW
> seabios - http://pastebin.com/rUU7ajRH
> cmos.default - http://pastebin.com/Pm5vS15R
>
> Thanks in advance, guys.
> All the best \o
>
> --sigkill
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
Hi,
since I switched to an F2A-85M I have a spare gigabyte desktop board with the Intel X4500 onboard graphics (quite rare) which has afaik no coreboot so far. In general, it seems like only one other socket 775 board is supported. I was wondering if this could be an interesting target or if any major showstoppers are to be expected. Here's are the specs:
http://www.gigabyte.com/products/product-page.aspx?pid=2877#sp
Although the board just supports DDR2 memory (4 slots), with the Socket 771 pinmod it should be able to run quite decent and cheap Xeon quadcores.
Cheers, Daniel
On Mon, Apr 25, 2016 at 10:13 AM, Aaron Durbin <adurbin(a)google.com> wrote:
> On Fri, Apr 22, 2016 at 9:35 PM, Stefan Reinauer
> <stefan.reinauer(a)coreboot.org> wrote:
>> On 04/22/2016 02:35 PM, Aaron Durbin via coreboot wrote:
>>> 1. coreboot tables base address and size.
>>> 2. console base address and size.
>>> 3. ramoops info.
>> Since ramoops already has its own object in the DSDT, do we want to
>> mention it here?
>> What about other cbmem entries? coverage, timestamps...?
>> Do we want a pointer to cbmem in there, instead?
>
> All of those things are in the coreboot table already. We can use the
> same code/parser for ARM (and other device tree archs) as x86. The
> only difference is where to source the initial information for where
> the table resides.
>
>>
>> Here's the 1 million dollar question: Do we want to get rid of coreboot
>> table and only have a coreboot
>> specific table? For a non-ACPI OS it's not much harder to read a
>> (non-DSDT) ACPI table than the current
>> coreboot table approach. For ACPI OSes it might make things a bit easier
>> (and counter the argument that
>> coreboot requires "support for non-standard tables")
>>
>>> On Fri, Apr 22, 2016 at 2:00 PM, Duncan Laurie <dlaurie(a)chromium.org> wrote:
>>>> On Tue, Apr 19, 2016 at 6:49 AM, Aaron Durbin <adurbin(a)google.com> wrote:
>>>>> On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner <jwerner(a)chromium.org>
>>>>> wrote:
>>>>>> I think we should only export the coreboot table location and size
>>>>>> through ACPI and then read everything else from there. That way we can
>>>>>> share almost all of the kernel driver code with ARM and just need a
>>>>>> tiny platform-specific stub to look up the table location first. If we
>>>>>> add all the information into an actual ACPI table, we're building an
>>>>>> x86-only solution again. (A generic, platform-independent coreboot
>>>>>> driver could just as easily export the stuff we want into sysfs.)
>>>>>>
>>>>> That's fine. The only thing I was concerned about was implementing an
>>>>> ACPI table proper or try to do some ACPI device shenanigans like the
>>>>> ramoops device. coreboot doesn't currently have a ACPI ID assigned to
>>>>> it. If we go with a ACPI device coreboot should apply for an ACPI ID.
>>>>> I personally think the coreboot ACPI table seems more straight
>>>>> forward, but I was wondering if people knew of any downsides to going
>>>>> that route.
>>>>>
>>>>
>>>> The official tables are all defined in the ACPI spec while the related
>>>> tables are also linked to from the spec, so we'd need to convince the UEFI
>>>> forum to at least reserve the signature for us (and then link to our table
>>>> definition) since they intend to act as gatekeepers to avoid collisions in
>>>> table signatures:
>> I like the idea of having a separate table rather than an object.
>
> We can pursue that if it's needed, but it sounds like it should be
> easy to just apply for HID and place a coreboot device object in the
> acpi code.
>
>>
>>
>>>>
>>>> "Requests to reserve a 4-byte alphanumeric table signature should be sent to
>>>> the email address info(a)acpi.info and should include the purpose of the table
>>>> and reference URL to a document that describes the table format."
>>>>
>>>> An easier path would be to define a specific device in the DSDT and populate
>>>> it with the various data we want to be there on every system. That would
>>>> allow us to control the format and be able to alter it in the future if we
>>>> want to expose new information.
>>>>
>>>> As you note a Device would need a valid unique HID, and that needs an ID
>>>> prefix if it wants to be official. In theory we could request something
>>>> like "CORE" as an official APCI ID from
>>>> http://www.uefi.org/PNP_ACPI_Registry
>>> OK. Time for bikeshedding:
>>>
>>> 1. CORE
>> This one is it!
>>
Did CORE get requested from the ACPI forum as a hid we can use? I
think it should be fairly easy to request and get.
-Aaron
Hi all
I find the same problem in my mainboard.The cpu type is N3150.
but I can't find why the microcode is not loaded to SOC.
Could you please share your exprience to me? Thank you
I'm at the boot menu. When I select "nvramcui", I get this:
IO space mapped serial not present. Could not find coreboot options table.
Then the firmware locks up. If I try coreinfo, I get the first sentence,
then the screen blanks and the firmware locks up. Ctrl-Alt-Del does
nothing. Taking the exact same .config and setting it for QEMU, coreinfo
works, but selecting nvramcui causes "Could not find coreboot option
table" to be printed.
--
David Griffith
dave(a)661.org
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
I'm experimenting with a Thinkpad T60p, specifically getting something
working that includes PXE and secondary payloads. Apparently the default
CBFS size of 0x40000 is too small because the build process complains it
can't add ipxe.rom and guesses that there's no room. Just now I tried
specifying a size of 0x200000, thinking that would work because I have a
two megabyte SPI flash chip. I went through the procedures on
https://www.coreboot.org/Board:lenovo/t60 and
https://www.coreboot.org/Board:lenovo/x60/Installation which led to a T60p
that shows a black screen and is non-responsive. So, I guess that was a
wrong value.
So, what's a safe value for the CBFS size that will allow me to add PXE
and some other secondary payloads?
--
David Griffith
dave(a)661.org
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Hi all,
Is there a debug build of coreboot or a way to test memory very early on.
My custom board goes through the romstage just fine but stops booting while trying to enumerate the buses.
I am suspecting RAM might be an issue so would like to eliminate that by doing a memory test on it.
--------------
POST: 0x72
Enumerating buses...
Show all devs... Before device enumeration.
Root Dev
--------------
Thanks in advance,
Naveed
Naveed Ghori | Lead Firmware & Driver Engineer
DTI Group Ltd | Transit Security & Surveillance
31 Affleck Road, Perth Airport, Western Australia 6105, AU
P +61 8 9373 2905,151 | F +61 8 9479 1190 | naveed.ghori(a)dti.com.au
Visit our website www.dti.com.au<http://www.dti.com.au>
The information contained in this email is confidential. If you receive this email in error, please inform DTI Group Ltd via the above contact details. If you are not the intended recipient, you may not use or disclose the information contained in this email or attachments.
