Re: [coreboot] lower memory performance with coreboot on KGPE-D16
Hi Daniel, Thanks for your reply, but it's not the case with me. I'm not using DDR3L-RDIMMs. My dmidecode output of one DIMM is: Handle 0x0007, DMI type 17, 40 bytes Memory Device Array Handle: 0x0006 Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 16384 MB Form Factor: DIMM Set: None Locator: NODE 0 DIMM_A2 Bank Locator: Not Specified Type: DDR3 Type Detail: Synchronous Registered (Buffered) Speed: 800 MT/s Manufacturer: Samsung Serial Number: 7FCC9C13 Asset Tag: Not Specified Part Number: M393B2G70BH0-CK0 Rank: 2 Configured Memory Speed: 800 MT/s Minimum Voltage: 1.5 V Maximum Voltage: 1.5 V Configured Voltage: 1.5 V Iru On Sat, Oct 6, 2018 at 3:58 AM Daniel Kulesz wrote: > 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: x > 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 > -- My website: https://vimacs.lcpu.club Please do not send me Microsoft Office/Apple iWork documents. Send OpenDocument instead! http://fsf.org/campaigns/opendocument/ -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Bootblock CMOS default and the checksum algo
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 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@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Bootblock CMOS default and the checksum algo
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 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 > 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@coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot -- William McCall -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Source code for "Intel Firmware"
Am Samstag, den 06.10.2018, 07:50 +0300 schrieb Zvi Vered: > Currently, in order to replace vendor's BIOS we must take binary > parts > of the original bin file and then stitch it to coreboot.rom built > with > the coreboot project. Well, exactly. Why do you think that is? Intel won't give you or anyone that code. Their policy seems to be to hide as much source code as possible. I don't know why they contribute so much to the Linux Kernel, though… > I want to depend only on Intel. ? You do depend on Intel. You depend on them not doing awkward stuff on their machines (what they clearly do, running Minix within the whole "BIOS"). -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Source code for "Intel Firmware"
On 10/7/18 10:10 PM, Philipp Stanner wrote: > Am Samstag, den 06.10.2018, 07:50 +0300 schrieb Zvi Vered: >> Currently, in order to replace vendor's BIOS we must take binary >> parts >> of the original bin file and then stitch it to coreboot.rom built >> with >> the coreboot project. > > Well, exactly. Why do you think that is? Intel won't give you or anyone > that code. Their policy seems to be to hide as much source code as > possible. At least since I'm working on the project it was always like this. And, IMHO, it is a good thing. The only decent x86 coreboot code I know was written when Intel didn't have their fingers in the pie. Without source code available, people had to write clean code. If you compare this to coreboot code that is closer to vendor code or was contributed by sili- con vendors... there are some levels of quality and maintainability in between. So what we need is documentation not code, IMHO. > I don't know why they contribute so much to the Linux Kernel, though… > >> I want to depend only on Intel. > > ? > You do depend on Intel. You depend on them not doing awkward stuff on > their machines (what they clearly do, running Minix within the whole > "BIOS"). Minix runs on the Management Engine (ME). It's completely separate from the "BIOS". Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Change superio in "Bayley Bay FSP-based CRB"
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 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Source code for "Intel Firmware"
On Sat, 6 Oct 2018 16:24:15 -0700 ron minnich wrote: > There are people on this list who know better than I what the most > "open" one is. > > Anyone out there have some advice? These are interesting: Samsung Chromebook Plus (based on RK3399, not available in EU) and Asus Chromebook R13 "ECC'17: Run upstream coreboot on an ARM Chromebook" https://www.youtube.com/watch?v=N7_9okzPeHo Cheers, Merlin > > On Sat, Oct 6, 2018 at 3:17 PM Andrew Luke Nesbit < > ullbek...@andrewnesbit.org> wrote: > > > > > On 6 Oct 2018, at 22:17, ron minnich 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 < > > ullbek...@andrewnesbit.org> wrote: > > > >> > >> > On 6 Oct 2018, at 17:42, ron minnich 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 > >> > > -- Merlin Büge -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
