coreboot October 2018

coreboot@coreboot.org

53 participants
145 discussions

Change superio in "Bayley Bay FSP-based CRB"
by Zvi Vered 07 Oct '18

07 Oct '18

Hello, I have to port coreboot to a "Bay Trail" board (KONTRON). I selected "Bayley Bay FSP-based CRB" as a reference. In my board, the output of superiotool is: Found Winbond W83627HF/F/HG/G (id=0x52, rev=0x41) at 0x2e But the configuration of the reference board is: *** Super I/O *** How can I change it ? I wish there was a basic configuration that could be easily modified. Thank you, Zvika

1 0

Re: [coreboot] Bootblock CMOS default and the checksum algo
by William McCall 07 Oct '18

07 Oct '18

my bad. option_table.h sets the checksum boundaries at LB_CKS_RANGE_START and LB_CKS_RANGE_END for the option table area. so perhaps this discussion is a bit easier.. I think your comment indicates that we may assume the option table is zero'ed and we can have a case specific for the option table csum? On Sun, Oct 7, 2018 at 4:30 PM Lance Zhao <lance.zhao(a)gmail.com> wrote: > > 1) Will CMOS reset typically result in zeroed out CMOS? Should we > assume that it probably does? Is this a common case? > > I don't think so, RTC will kepp on counting. We may assume so if only use extended CMOS like 0x72/0x73. > > On Sat, Oct 6, 2018 at 7:28 PM William McCall <william.mccall(a)gmail.com> wrote: >> >> Hey all-- >> >> Recently, I started the process of enabling CMOS-based runtime config >> on a board. As this board is native coreboot and it had never used the >> CMOS in any meaningful sense, the CMOS was wholly zeroed out. >> >> Based on this, the bootblock never programs the defaults. Why? Because >> the checksum algorithm sums with a constant of 0 and simply sums the >> bytes. This wasn't always the case, but was changed here: >> http://review.coreboot.org/279 >> >> Downstream effects of this can be seen in nvramcui. As the CMOS is >> zeroed, some enums (like debug_level) do not define a value at zero. >> As a result, nvramcui ends up with a null pointer deref when trying to >> set these enums. >> >> Questions for the list: >> 1) Will CMOS reset typically result in zeroed out CMOS? Should we >> assume that it probably does? Is this a common case? >> >> 2) To fix this, bootblock could look at options table checksum and use >> a different constant or NOT the result. Is this reasonable to do in >> bootblock? (My opinion is probably not) >> >> 3) As a workaround, an image could be used with >> CONFIG_STATIC_OPTION_TABLE to force initial programming. Is a special >> image acceptable if we assume question 1 is answered "yes"? >> >> 4) Should nvramcui be fixed to handle bogus enums? >> >> 5) What documentation of this behavior makes sense? >> >> Also open to other solutions, thoughts, etc. Depending on the results >> of this convo, I'll send patches/doc updates over that make sense. >> >> TIA, >> -- >> William McCall >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot -- William McCall

1 0

Re: [coreboot] Bootblock CMOS default and the checksum algo
by Lance Zhao 07 Oct '18

07 Oct '18

1) Will CMOS reset typically result in zeroed out CMOS? Should we assume that it probably does? Is this a common case? I don't think so, RTC will kepp on counting. We may assume so if only use extended CMOS like 0x72/0x73. On Sat, Oct 6, 2018 at 7:28 PM William McCall <william.mccall(a)gmail.com> wrote: > Hey all-- > > Recently, I started the process of enabling CMOS-based runtime config > on a board. As this board is native coreboot and it had never used the > CMOS in any meaningful sense, the CMOS was wholly zeroed out. > > Based on this, the bootblock never programs the defaults. Why? Because > the checksum algorithm sums with a constant of 0 and simply sums the > bytes. This wasn't always the case, but was changed here: > http://review.coreboot.org/279 > > Downstream effects of this can be seen in nvramcui. As the CMOS is > zeroed, some enums (like debug_level) do not define a value at zero. > As a result, nvramcui ends up with a null pointer deref when trying to > set these enums. > > Questions for the list: > 1) Will CMOS reset typically result in zeroed out CMOS? Should we > assume that it probably does? Is this a common case? > > 2) To fix this, bootblock could look at options table checksum and use > a different constant or NOT the result. Is this reasonable to do in > bootblock? (My opinion is probably not) > > 3) As a workaround, an image could be used with > CONFIG_STATIC_OPTION_TABLE to force initial programming. Is a special > image acceptable if we assume question 1 is answered "yes"? > > 4) Should nvramcui be fixed to handle bogus enums? > > 5) What documentation of this behavior makes sense? > > Also open to other solutions, thoughts, etc. Depending on the results > of this convo, I'll send patches/doc updates over that make sense. > > TIA, > -- > William McCall > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] lower memory performance with coreboot on KGPE-D16
by Daniel Kulesz 07 Oct '18

07 Oct '18

Hi Iru, > I just found the memory performance on KGPE-D16 is lower when running with > coreboot. I have two Opteron 6276 and 8 16GB DDR3-1600 RDIMM on all orange > slots. I tested it with `hdparm -tT /dev/sda` and see the `Timing cached > reads` result. With coreboot, this value is around 3000 MB/s, but with OEM > firmware it can go to around 3600 MB/s. I think the disk cached read speed > is related to memory performance. Are you using DDR3L-RDIMMs? And did you check whether your memory really runs at 800 MHz? My experience is that coreboot sets the clock down to 667 MHz when running on 1.35V (low voltage), while the vendor bios seems to run modules at 800 MHz in low voltage mode, resulting in higher performance. According to Timothy, this is "over the spec" and thus not set in coreboot by default (you can choose between 1.5V 800 MHz or 1.35V at 667 MHz - but may depend on the used modules). You can check e.g. in dmidecode. Below is an example (serial number x'd out): Handle 0x000E, DMI type 17, 40 bytes Memory Device Array Handle: 0x0006 Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 8192 MB Form Factor: DIMM Set: None Locator: NODE 0 DIMM_D2 Bank Locator: Not Specified Type: DDR3 Type Detail: Synchronous Registered (Buffered) Speed: 800 MHz Manufacturer: Samsung Serial Number: xxxxxxxxx Asset Tag: Not Specified Part Number: M393B1K70DH0-YK0 Rank: 2 Configured Clock Speed: 800 MHz Minimum Voltage: 1.35 V Maximum Voltage: 1.5 V Configured Voltage: 1.5 V Btw.: I am getting around 3700 MB/sec with hdparm -Tt on my /dev/sda (mechanical disk) and around 3840 MB/sec on /dev/nvme0n1 (PCIe M.2 SSD). Cheers, Daniel

2 1

Bootblock CMOS default and the checksum algo
by William McCall 07 Oct '18

07 Oct '18

Hey all-- Recently, I started the process of enabling CMOS-based runtime config on a board. As this board is native coreboot and it had never used the CMOS in any meaningful sense, the CMOS was wholly zeroed out. Based on this, the bootblock never programs the defaults. Why? Because the checksum algorithm sums with a constant of 0 and simply sums the bytes. This wasn't always the case, but was changed here: http://review.coreboot.org/279 Downstream effects of this can be seen in nvramcui. As the CMOS is zeroed, some enums (like debug_level) do not define a value at zero. As a result, nvramcui ends up with a null pointer deref when trying to set these enums. Questions for the list: 1) Will CMOS reset typically result in zeroed out CMOS? Should we assume that it probably does? Is this a common case? 2) To fix this, bootblock could look at options table checksum and use a different constant or NOT the result. Is this reasonable to do in bootblock? (My opinion is probably not) 3) As a workaround, an image could be used with CONFIG_STATIC_OPTION_TABLE to force initial programming. Is a special image acceptable if we assume question 1 is answered "yes"? 4) Should nvramcui be fixed to handle bogus enums? 5) What documentation of this behavior makes sense? Also open to other solutions, thoughts, etc. Depending on the results of this convo, I'll send patches/doc updates over that make sense. TIA, -- William McCall

1 0

Re: [coreboot] Source code for "Intel Firmware"
by Andrew Luke Nesbit 07 Oct '18

07 Oct '18

> On 6 Oct 2018, at 22:17, ron minnich <rminnich(a)gmail.com> wrote: > > It depends on what you mean by fully. If there is a so-called Mask ROM (i.e. initial boot program that's part of the chip itself, not replaceable, you can disassemble it however) and the rest of the chip is fully open, does that count? That's a good start. In my experience, these are what I've mostly seen. Ideally I mean one where the boot loader (and payload?) are not proprietary. Or that an open source boot loader could be used, preferably without added blobs. > For my money the ARM chromebooks are still one of the best bets out there for messing about with ARM firmware. Yes, I've been looking at getting one for this very purpose, especially as it's already a whole, usable system. Have you any particular recommendations? >> On Sat, Oct 6, 2018 at 12:30 PM Andrew Luke Nesbit <ullbeking(a)andrewnesbit.org> wrote: >> >> > On 6 Oct 2018, at 17:42, ron minnich <rminnich(a)gmail.com> wrote: >> > >> [...] >> > >> > if you really want 100% open, the only real options at this point are power 9, RISCV and some ARM CPUs. >> >> Ron, thanks for your reasoned reply and the contextual background. I believe this is important when embarking on any project with a legacy. >> >> I know of libre-friendly POWER9 and RISC-V options. For example, I am currently learning my way around the Talos II (which is excellent). ARM-based systems have been elusive to me. >> >> Could you please give some examples of fully libre-friendly ARM-based boards or systems? Thanks!! >> >> Kind regards, >> >> Andrew

2 1

Re: [coreboot] Source code for "Intel Firmware"
by Andrew Luke Nesbit 06 Oct '18

06 Oct '18

> On 6 Oct 2018, at 17:42, ron minnich <rminnich(a)gmail.com> wrote: > [...] > > if you really want 100% open, the only real options at this point are power 9, RISCV and some ARM CPUs. Ron, thanks for your reasoned reply and the contextual background. I believe this is important when embarking on any project with a legacy. I know of libre-friendly POWER9 and RISC-V options. For example, I am currently learning my way around the Talos II (which is excellent). ARM-based systems have been elusive to me. Could you please give some examples of fully libre-friendly ARM-based boards or systems? Thanks!! Kind regards, Andrew

2 1

current state of board/f2a85m
by kinky_nekoboi 06 Oct '18

06 Oct '18

I was not able to build any usable rom from the current master branch of coreboot for f2a85m. Compliation runs smooth but the resulting system does not pass POST(i dont know how to call it in coreboot terms, the system just powers up and dont loads the SeaBIOS payload) .. no useful debug information getable from der TTYS0 as there is no output. anyway to contact the current maintainer of this board? my setup: ASUS F2A85M with A8-6600K and 8GB DDR3 Ram. and early version of coreboot was fine expect the fact it was not able to initialize my Radeon HD7850. grettings the kinky nekoboi

2 1

Re: [coreboot] Source code for "Intel Firmware"
by Nico Huber 06 Oct '18

06 Oct '18

On 10/6/18 2:46 PM, Zvi Vered wrote: > Hello Nathaniel, Nico, > > Thank you very much for the detailed answers. > > The vendor's bin file starts with the following pattern: > 00000000: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF > 00000010: 5AA5F00F 03000402 0602100B 20002100 > > Can you confirm that this is the start of IFD ? Yes, it is (at least the first 20B are distinctive). There is not much public documentation about it ([1] is all I know) but you might find something less public with Google [2]. There's also a lot of open-source code of programs that can parse it [3][4]. Code is usually more accurate than documentation but it explains less about the configuration bits. You'll have to ask Intel for the SPI Program- ming Guide for your particular platform if you want to fully under- stand it and craft your own. Nico [1] https://review.coreboot.org/cgit/flashrom.git/plain/Documentation/mysteries… [2] "Intel" "SPI" "Programming Guide" *cough [3] https://review.coreboot.org/cgit/flashrom.git/tree/ich_descriptors.c [4] https://review.coreboot.org/cgit/coreboot.git/tree/util/ifdtool/

2 1

Re: [coreboot] Source code for "Intel Firmware"
by ron minnich 06 Oct '18

06 Oct '18

On Fri, Oct 5, 2018 at 9:53 PM Zvi Vered <veredz72(a)gmail.com> wrote: > > coreboot only replaces the BIOS part developed by vendors like "AMI bios". > > Just to make it clear, it was not always this way. In 1999, 100% of what we call coreboot did 100% of the tasks, and by 2002 it worked on x86, x86_64, powerpc, and alpha-- all 100% GPL. See slide 17 in https://docs.google.com/presentation/d/1-_cgb4gRhZxl9anxudIgO_NAB80yq-ks4Ht… from 2012. This table shows the fraction of the ROM that is developed with GPL'ed code. That table was made in 2012; as of 2018, AMD is no more open than intel. Probably around 10% at most of the x86 ROM space consists of GPL code. Starting in 2004, Intel pushed back hard on this open situation and we have ended up where we are today: significant amounts of binary blobs in coreboot images on x86. PLEASE, let's not start another "bad intel!" discussion again. There are lots of people at Intel who are working hard to change back to the more open model. Intel is a business and the higher ups at Intel made what they thought were the right business decisions at the time. We don't agree, and let's leave it at that. I just wanted to point out that in the history of microprocessors, from 1970 to present, this current closed situation is not normal. if you really want 100% open, the only real options at this point are power 9, RISCV and some ARM CPUs. ron

1 0

← Newer
1
...
7
8
9
10
11
12
13
14
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2018