coreboot April 2013

coreboot@coreboot.org

42 participants
125 discussions

Jenkins: Use a config file with more stuff enabled
by Paul Menzel 05 Apr '13

05 Apr '13

Dear coreboot folks, for example the patch adding the spkmodem console [1] is currently not build tested as it is disabled by default. Could we put a `.config.jenkins` file into the repository where more stuff is enabled so it gets tested too. Patrick said something about Linux’ `allyesconfig` option. But this would require getting latest Kconfig into coreboot I think. So using the approach with just adding a separate config file for Jenkins might be easier? Thanks, Paul [1] http://review.coreboot.org/#/c/2987/

2 1

A patch for SuperIOtool: add CR definitions for the W83627UHG (for dump capability)
by Frantisek Rysanek 05 Apr '13

05 Apr '13

Dear gentlemen, attached is a patch that adds "register dump capability" to SuperIOtool for a specific chip by Winbond/Nuvoton: the W83627UHG AKA NCT6627UD (same chip, different package). Have a nice day :o) Frank Rysanek The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: W83627UHG_rev-E.patch Date: 4 Apr 2013, 14:20 Size: 2944 bytes. Type: Unknown

2 2

Request to become wiki admin
by Stefan Tauner 04 Apr '13

04 Apr '13

Hi, please make Patrick and me (or at least him :) a (coreboot) wiki admin so that we can delete obsolete pages, thanks. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

4 4

Jenkins: Build test all programs under `utils` too
by Paul Menzel 03 Apr '13

03 Apr '13

Dear coreboot folks, if I am not mistaken, all programs under `utils/` are currently not built tested. Could that be changed, please? Maybe the following script could be integrated somehow? $ for s in util/*; do cd "$s"; make; cd -; done Be aware that I have no idea how to use Jenkins. Thanks, Paul

3 2

Super I/Os Winbond W83627HF and Nuvoton NCT5572D detected as NCT6775F (was: Ivy Bridge desktop support)
by Paul Menzel 03 Apr '13

03 Apr '13

Am Dienstag, den 02.04.2013, 12:12 -0500 schrieb Aaron Durbin: > On Tue, Apr 2, 2013 at 11:56 AM, Nico Huber <nico.h(a)gmx.de> wrote: > > Am 02.04.2013 11:12, schrieb Paul Menzel: > >> Am Sonntag, den 31.03.2013, 21:10 +0200 schrieb Paul Menzel: > >> > >>> Am Samstag, den 30.03.2013, 19:57 +0100 schrieb Nico Huber: > >>> > >>>> I'm looking forward to write a port for my Ivy Bridge desktop system based > >>>> on this board: Intel DH77EB (codenamed Eb Lake, [1]). It comes with the H77 > >>>> platform controller hub (PCH) and a Winbond W83677HG super I/O chip (build > >>>> by Nuvoton as NCT6775F, [2]). I'm using it with a Core i3-3225 processor [3]. > >>> > >>> awesome news! Best luck with this! > >>> > >>>> I've got the datasheet for the super I/O, so writing support for it should > >>>> be no problem. > >>> > >>> The ASRock E350M1 [4] also uses the Nuvoton NCT6775F. Currently the code > >>> from the Winbond W83627HF [5]. > >>> > >>> device pci 14.3 on # LPC 0x439d > >>> chip superio/winbond/w83627hf > >>> > >>> Serial works for me. The only problem that might be related from any > >>> incompatibilities is, that a PS/2 keyboard connected to the shared PS/2 > >>> port does not work correctly, meaning, entering a character the > >>> characters is displayed several times more. Entering »n«, I get > >>> »nnnnnnnn« for example. Alvaro, having a ASRock E350M1/USB3, also uses a > >>> PS/2 keyboard *but* has no problems with this at all. So I have no idea > >>> if this is related to the Super I/O or not. > > Sounds weird. But something I can't test / run into: My board doesn't even > > have a PS/2 port. > > > >> Please note that Martin Roth pointed out to me, that when looking at the > >> the ASRock E350M1, one actually finds that the Nuvoton NCT5572D is used. > >> Both superiotool and Linux’ w83627ehf are incorrect. > >> > >> superiotool r4.0-3888-gce9f8be > >> Found Nuvoton NCT6775F (B) (id=0xb473) at 0x2e > >> > >> And if you know what you have to look for, you also find that this was > >> known all time along [8]. > >> > >> The board has a socketed SPI flash BIOS chip and a serial port > >> header. The SIO is Nuvoton NCT5572D. Using coreboot's existing > >> Winbond w83627hf is a good enough match to get the serial port > >> and keyboard working. > > Uh, does this mean that both chips share the same ID? I get the same output > > from superiotool: > > Found Nuvoton NCT6775F (B) (id=0xb473) at 0x2e > > My chip is labeled W83677HG and I vaguely remember that I saw on a web page > > that this is a NCT6775F. But I can't find the page anymore :( > > Also, W83677HG sounds more like NCT6775F than NCT5572D. > > They are probably the same chip. http://en.wikipedia.org/wiki/Nuvoton > Nuvoton was spun off from Winbond a few years ago. It's all just > branding and part number differences, I suspect. According to the LM Sensors developers replied that all three are variants and should be compatible, but cannot be told apart [1]. > > > Should the Linux message be changed to the following? > > > > > > w83627ehf: Found NCT6775F (or NCT5572D) chip at 0x290 > > > > > > Is it planned to add support for that the NCT5572D? > > > > > I don't think so. Many of the superio chips have different labels - we would > > end up spending a lot of time trying to keep the labels up to date. > > Besides, that chip can also be labeled as NCT6772F or NCT6771F. > > So it should read > > > > w83627ehf: Found NCT6775F, or NCT6771F, or NCT6772F, or NCT5572D chip at 0x290 > > > > which would get a bit awkward. And then there is its original name, W83677HG-I, > > which we would presumably have to add as well. > > "NCT6775F or compatible" is one way to name it, that would make > everyone happy I think. > Ok, I'll add something like that to the nct6775 driver. Turns out the other supported chips (NCT6776, NCT6779) have similar variants, so "or compatible" applies to all those chips. One interesting detail is that the variants support fewer sensors/fans according to the data sheets, but there is no way to distinguish the chips from each other. Should we adapt superiotool to also print »NCT6775F or compatible«? Thanks, Paul [1] http://www.spinics.net/lists/lm-sensors/msg38272.html

1 0

ASRock E350M1: Several seconds spend in `SB800 - Late.c - sb800_callout_entry`
by Paul Menzel 03 Apr '13

03 Apr '13

Dear coreboot folks, I post the coreboot log for my ASRock E350M1 built from commit 60a4a73fcd7babd4819853542a5566293a097ed4 Author: Stefan Reinauer <reinauer(a)chromium.org> Date: Thu Mar 28 16:46:07 2013 -0700 cbfstool: fix --machine Reviewed-on: http://review.coreboot.org/3009 and captured with `readserial.py` from the SeaBIOS repository [1]. As you can see in the following excerpt there are huge delays. 01.146: PCI: 00:15.0 subordinate bus PCI Express 01.146: PCI: 00:15.0 [1002/43a0] enabled 01.146: sb800_enable() PCI: 00:16.0 [1002/4397] ops 01.146: PCI: 00:16.0 [1002/4397] disabled 01.146: sb800_enable() SB800 - Late.c - sb800_callout_entry - Start. 01.534: SB800 - Late.c - sb800_callout_entry - End. 01.534: SB800 - Late.c - sb800_callout_entry - Start. 01.534: SB800 - Late.c - sb800_callout_entry - End. 05.227: SB800 - Late.c - sb800_callout_entry - Start. 05.227: SB800 - Late.c - sb800_callout_entry - End. 05.228: SB800 - Late.c - sb800_callout_entry - Start. 05.228: SB800 - Late.c - sb800_callout_entry - End. 16.338: SB800 - Late.c - sb800_callout_entry - Start. 16.338: SB800 - Late.c - sb800_callout_entry - End. 16.339: SB800 - Late.c - sb800_callout_entry - Start. 16.339: SB800 - Late.c - sb800_callout_entry - End. 28.124: SB800 - Late.c - sb800_callout_entry - Start. 28.124: SB800 - Late.c - sb800_callout_entry - End. 28.124: SB800 - Late.c - sb800_callout_entry - Start. 28.124: SB800 - Late.c - sb800_callout_entry - End. 35.189: SB800 - Late.c - sb800_callout_entry - Start. 35.189: SB800 - Late.c - sb800_callout_entry - End. 35.189: SB800 - Late.c - sb800_callout_entry - Start. 35.189: SB800 - Late.c - sb800_callout_entry - End. 40.231: SB800 - Late.c - sb800_callout_entry - Start. 40.231: SB800 - Late.c - sb800_callout_entry - End. 40.231: SB800 - Late.c - sb800_callout_entry - Start. 40.231: SB800 - Late.c - sb800_callout_entry - End. 50.668: SB800 - Late.c - sb800_callout_entry - Start. 50.668: SB800 - Late.c - sb800_callout_entry - End. 50.668: SB800 - Late.c - sb800_callout_entry - Start. 50.668: SB800 - Late.c - sb800_callout_entry - End. 55.035: SB800 - Late.c - sb800_callout_entry - Start. 55.035: SB800 - Late.c - sb800_callout_entry - End. 55.035: SB800 - Late.c - sb800_callout_entry - Start. 55.036: SB800 - Late.c - sb800_callout_entry - End. 55.036: PCI: 00:18.0 [1022/1700] enabled They are not present in commit bdca15337bc9337f399b43290dc74cb598c5ec4d Author: Nico Huber <nico.huber(a)secunet.com> Date: Mon May 21 14:01:52 2012 +0200 libpayload: Remove orphaned delay from USB mass storage Reviewed-on: http://review.coreboot.org/1071 though that also sometimes has problems enabling the Ethernet device. Thanks, Paul [1] http://review.coreboot.org/gitweb?p=seabios.git;a=tree;f=tools;h=2d6cbb520e…

1 0

Ivy Bridge desktop support
by Nico Huber 02 Apr '13

02 Apr '13

Dear coreboot folks, I'm looking forward to write a port for my Ivy Bridge desktop system based on this board: Intel DH77EB (codenamed Eb Lake, [1]). It comes with the H77 platform controller hub (PCH) and a Winbond W83677HG super I/O chip (build by Nuvoton as NCT6775F, [2]). I'm using it with a Core i3-3225 processor [3]. I've got the datasheet for the super I/O, so writing support for it should be no problem. Is there any doubt that the current code for Ivy Bridge and the Panther Point PCH works out of the box on a desktop system? I see that at least I have to add some device IDs. Regarding the PCH code, is SOUTHBRIDGE_INTEL_C216 the general option for Panther Point? or is it really C216 specific? Then there are the binary blobs. I'm not quite sure, which are necessary: `ifdtool -x` gives me four regions out of the original vendor firmware: flashregion_0_flashdescriptor.bin, flashregion_1_bios.bin, flashregion_2_intel_me.bin, and flashregion_3_gbe.bin. Obviously, the second one will be replaced with coreboot. I guess, I'll need to use or replace the flashdescriptor.bin and intel_me.bin? What about the last one `flashregion_3_gbe.bin`? do I need it as well? I haven't seen an equivalent in the 3rdparty directories for supported boards. Surprisingly, I didn't find a VGA BIOS in there. Well, I might not need it, anyhow. The box should be booted before any display device is up :) Regards, Nico [1] http://ark.intel.com/products/59505/Intel-Desktop-Board-DH77EB [2] http://www.nuvoton.com/NuvotonMOSS/Community/ProductInfo.aspx?tp_GUID=746a4… [3] http://ark.intel.com/products/65692/Intel-Core-i3-3225-Processor-3M-Cache-3…

5 6

Re: [coreboot] x86 automatic ROM caching enabled
by ron minnich 02 Apr '13

02 Apr '13

I think your intuition on this one is solid, especially putting a warning in the .h file. On Mon, Apr 1, 2013 at 8:06 PM, Aaron Durbin <adurbin(a)chromium.org> wrote: > Hi folks, > > I uploaded http://review.coreboot.org/#/c/3004/ to do an auto > enablement of caching the ROM. I put some comments on the patch. > Basically, if the cpu is a hyperthreaded CPU and all the APs run > through the MTRR code the auto caching of the ROM will be dropped > because the MTRR MSRs are core scoped -- not thread scope. I am of the > opinion I should drop that change and just fix up the users (only > ChromeOS devices on a single chipset at the moment) that really desire > this behavior by calling x86_mtrr_enable_rom_caching() at the > appropriate point in the code. In addition I plan on putting a comment > in mtrr.h to warn people of the side effects. > > I just wanted to hear what others' opinions were. > > Thanks for the feedback. > > -Aaron > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

x86 automatic ROM caching enabled
by Aaron Durbin 02 Apr '13

02 Apr '13

Hi folks, I uploaded http://review.coreboot.org/#/c/3004/ to do an auto enablement of caching the ROM. I put some comments on the patch. Basically, if the cpu is a hyperthreaded CPU and all the APs run through the MTRR code the auto caching of the ROM will be dropped because the MTRR MSRs are core scoped -- not thread scope. I am of the opinion I should drop that change and just fix up the users (only ChromeOS devices on a single chipset at the moment) that really desire this behavior by calling x86_mtrr_enable_rom_caching() at the appropriate point in the code. In addition I plan on putting a comment in mtrr.h to warn people of the side effects. I just wanted to hear what others' opinions were. Thanks for the feedback. -Aaron

1 0

Fwd: Re: Can the LiPPERT Cool RoadRunner-LX image be used for Gene 5315 Rev.B?
by sergey 02 Apr '13

02 Apr '13

Hello everybody, The image of coreboot for LiPPERT Cool RoadRunner-LX can use on Gene 5315 Rev.B . My problem was in driver for graphics GEODE. The system is started, but display did not worked. Thanks. Sergey ----------------------------------------------------------------------

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2013