You commented in , that there are problems with native RAM
initialization on Intel Sandy Bridge.
> using native raminit seems to be problematic on several
> samsung/stumpy devices, hence the use of the MRC blob instead
In #coreboot, I was asked which ones there are. Could you please report
those here, or in the bug tracker .
This is my first post to this mailing list :)
I'm trying to get a specific panel working on my Thinkpad T400 which runs
libreboot. It's an WXGA+ MVA panel (CMO G141C1-L01) and I have soldered an
adapter cable for it. From what I have found, nobody succeeded on this mod yet -
there are some attempts on 51nb.com, but only for the T410. I basically took
some already existing adapter cable, and modified a few pins, so that it would
match up exactly with the datasheets. I used the LG LP141WP2-TLB1 for reference.
Some details about my adapter cable can be found here:
In the first post there are also links to the datasheets of the two panels in
Of course I thoroughly checked all my self-made connections and modifications,
but only with some general purpose DMM for continuity. They all seem fine.
So far backlight + PWM control works, but I have no image displayed, both in
libreboot (with GRUB2 as payload) and Linux (up-to-date Arch Linux).
I tried the panel both with the latest stock ROM (3.23/EC 1.06) and with
the latest libreboot release, which is currently 2016090
(t400_8mb_usqwerty_vesafb.rom in my case).
Since I have not much experience with such low-level hardware stuff, could
someone maybe help me with this or direct me to some useful direction, how I
can debug this?
I already tried booting with i915.lvds_channel_mode=2 (since I was not able
to figure out what mode was actually used, because this module parameter is
normally set to "0", which means the channel mode is taken from BIOS).
I attached the EDIDs of both panels, the coreboot log (cbmem -c) of both
panels, and a kernel log of both panels. I also attached a kernel log of the
MVA panel with drm debbuging enabled (drm.debug=0x1e log_buf_len=1M). Note that
all of the logs were taken from the T400 with the latest libreboot release.
It would be great if somebody could have a look at it. (I don't understand much
Here is a picture of the adapter cable, so that you have an idea what it looks
I already put *a lot* of effort in this project, and I would be very happy if it
succeeded at the end of the day. I would design some PCBs then, so that this
would basically become a drop-in replacement. Background is: The T400 is a very
desirable target for libreboot, since it's build on the latest Intel hardware
currently supported in libreboot for laptops. And (not only in the libreboot
community) it is sadly well known for its rather bad TN panels. Also, it would
be something that I could give back to the libreboot community.
Since I have not much experience with mailing lists, please correct my of any
Thank you for reading this,
and for any advice in advance :)
Merlin Büge <toni(a)bluenox07.de>
We are trying to do the eye pattern test on USB2.0 on Bayley Bay board.
But we are not able to see the test pattern support from BIOS side.
Do we have any settings in coreboot to enable this?
This works fine on any Linux laptop/desktop
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
Hello Adolfo (you are somehow known to me, isn't it that you are working
for INTEL Inside support, or maybe not)!? What does it mean _cr in your
email address (Costa Rica, isn't it)?! ;-)
Let us ask this very relevant people in INTEL Inside, who MANDATORY should
know info you are asking, since they are responsible, aren't they (INTEL
insider is asking for FSP POST codes Coreboot outsiders, which will again
ask much more relevant INTEL Insiders)??? IN -> OUT -> IN schema. Shouldn't
it be: IN -> IN schema ONLY??? :-))
Verrückt (Deutsche Sprache)?! :LOL:
You realize how this all strange is (the context)? *BTW, we, Coreboot
members... We should once forever know these POST codes are (you hide
inside FSPs - probably reminiscence of BIOS MRC post codes, or you tell us
all?!)? Could you, please, make this as public info to INTEL Outside?*
Could you, please, arrange what I am (in *RED*) asking for (INTEL Inside
and INTEL Outside)? You do realize why I am asking this, correct???💡
(don't touch/blame Adolfo... You should ask many questions somewhere
else... You know exactly where!)
Zoran Stojsavljevic, independent FREE contributor
On Sun, Sep 25, 2016 at 5:55 PM, Adolfo Sanchez <adolfo_sm_cr(a)hotmail.com>
> I would like to know the best way to get information about a Failure
> related with Memory Initialization when using FPS.
> Specially when the FSPmemoryinit is being called but then the system
> hangs. POST Code 0x50
> What flags can be enable to get more information?
> Best Regards,
> Adolfo Sanchez
> coreboot mailing list: coreboot(a)coreboot.org
I would like to know the best way to get information about a Failure related with Memory Initialization when using FPS.
Specially when the FSPmemoryinit is being called but then the system hangs. POST Code 0x50
What flags can be enable to get more information?
I've been trying to make this board boot and I haven't had much success.
Sometimes I've been able to get it to POST, but it's not something that
happens consistently. Since I can't find much info other than it being
listed, I'm asking here to see if by any chance there's something that I'm
missing, because I feel like I'm just trying random things to see what
Thankfully the board has dual bios, so it's easy to go back if I mess
something up. Please, help.
I'm trying to work with some HP machines. I disassembled these machines and
saw they the EC chip SMSC KBC1126-NU. I read the backup firmware and can
see strings like `8051 RESET`, and I found if I modify certain part of the
firmware, the machine will fail to power with some LEDs blinking, so I know
the EC firmware is in the BIOS chip, and it's an 8051 program.
I searched about this chip, and some people say the EC chip also contains
program. I can't find anything about this chip, and coreboot wiki has
KBC1122 and I only found a 5-page product review on the Internet. I don't
know if there's anyone know about this EC. I want to know about:
- Where is the entry point of the EC firmware in the BIOS chip
- How this EC chip does the power management and keyboard control
A week ago, libreboot left the GNU project because of transgender
discrimination at the Free Software Foundation.
GNU project has told me that they will not allow libreboot to leave GNU.
This is quite possibly the biggest insult imaginable, considering what
This attitude within the GNU project is disgusting.
So the libreboot project hereby announces just how disgusting both the
GNU project and FSF are:
Use free software. Free as in freedom.
Use a free operating system, GNU/Linux.
Use a free BIOS.
Support computer user freedom.
Minifree Ltd, trading as Ministry of Freedom | Registered in England,
No. 9361826 | VAT No. GB202190462
Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK |
I want to experiment with an SMI handler on the Camelback Mountain CRB (Xeon D-1500) but it appears that the fsp_broadwell_de changes removed SMM support. I'm browsing the coreboot-4.4 release. Was there a reason it was removed? It shows up in the soc/intel/Broadwell area so I suppose I could port over the original code. I didn't see that the D_LCK bit was set anywhere so does that mean I can potentially let SeaBIOS install an SMI handler? Or is it set in the FSP? I also noticed the mainline has some new code under coreboot/src/soc/intel/sch but I'm not sure which processors that is for.
Thank you very much for the reply. I think you mean though that the FSP does NOT need to be touched - correct?
From: Yang, York [york.yang(a)intel.com]
Sent: Thursday, September 22, 2016 8:34 PM
To: Watzlavick, Robert L (US); coreboot(a)coreboot.org
Subject: EXTERNAL: Re: SMI handler for fsp_broadwell_de
Fsp_broadwell_de do not implement the SMI support, but you may refer to soc/Broadwell as both are Intel architecture chipset. The SMI support can be done purely in coreboot, but need to touch FSP.
From: coreboot [mailto:email@example.com] On Behalf Of Watzlavick, Robert L
Sent: Thursday, September 22, 2016 4:28 PM
Subject: [coreboot] SMI handler for fsp_broadwell_de
I want to experiment with an SMI handler on the Camelback Mountain CRB (Xeon D-1500) but it appears that the fsp_broadwell_de changes removed SMM support. I’m browsing the coreboot-4.4 release. Was there a reason it was removed? It shows up in the soc/intel/Broadwell area so I suppose I could port over the original code. I didn’t see that the D_LCK bit was set anywhere so does that mean I can potentially let SeaBIOS install an SMI handler? Or is it set in the FSP? I also noticed the mainline has some new code under coreboot/src/soc/intel/sch but I’m not sure which processors that is for.