coreboot February 2017

coreboot@coreboot.org

66 participants
212 discussions

Re: [coreboot] Add coreboot storage driver
by Aaron Durbin 14 Feb '17

14 Feb '17

On Mon, Feb 13, 2017 at 5:28 PM, Julius Werner <jwerner(a)chromium.org> wrote: > +1 for preferring a single-core concurrency model. This would be much more > likely to be reusable for other platforms, and much simpler to maintain in > the long run (way less platform-specific details to keep track of and figure > out again and again for every new chipset). You CAR problems would become > much more simple... just make sure the scheduler structures get migrated > together with the rest of the globals and it should work fine out of the > box. FWIW, there's no coherency in CAR. It's per building block of the hardware units -- much like multiple nodes in AMD K* systems. Migrating CAR not necessarily a simple solution, but I'm not convinced we need multiple cores executing with CAR as a backing store. > > On Mon, Feb 13, 2017 at 12:31 PM, ron minnich <rminnich(a)gmail.com> wrote: >> >> >> >> On Mon, Feb 13, 2017 at 11:17 AM Nico Huber <nico.h(a)gmx.de> wrote: >>> >>> >>> >>> Another idea just popped up: Performing "background" tasks in udelay() >>> / mdelay() implementations ;) >> >> >> that is adurbin's threading model. I really like it. >> >> A lot of times, concurrency will get you just as far as ||ism without the >> nastiness. >> >> But if we're going to make a full up kernel for rom, my suggestion is we >> could start with a real kernel, perhaps linux. We could then rename coreboot >> to, say, LinuxBIOS. >> >> ron >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Add coreboot storage driver
by Andrey Petrov 14 Feb '17

14 Feb '17

Hi, On 02/13/2017 12:31 PM, ron minnich wrote: > Another idea just popped up: Performing "background" tasks in udelay() > / mdelay() implementations ;) > > > that is adurbin's threading model. I really like it. > > A lot of times, concurrency will get you just as far as ||ism without > the nastiness. But how do you guarantee code will get a slice of execution time when it needs it? For example for eMMC link training you need to issue certain commands with certain time interval. Lets say every 10ms. How do you make sure that happens? You can keep track of time and see when next piece of work needs to be scheduled, but how do you guarantee you enter this udelay code often enough? Andrey

3 2

ASUS KFSN4-DRE Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 14 Feb '17

14 Feb '17

The ASUS KFSN4-DRE fails verification for branch master as of commit e2143cdf5a95032809449722950e503740973a56 The following tests failed: BOOT_FAILURE Commits since last successful test: e2143cd AGESA: Remove nonexistent include path See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] Add coreboot storage driver
by Andrey Petrov 14 Feb '17

14 Feb '17

Hi, On 02/13/2017 12:21 AM, Zoran Stojsavljevic wrote: > IBVs can work on this proposal, and see how BIOS boot-up time will improve (by this parallelism) There is no need to wait for anybody to see real-world benefits. The original patch where you train eMMC link already saves some 50ms. However MP init kicks in very late. That is a limitation of current approach where MPinit depends on DRAM to be available. If you move mpinit earlier, you can already get approx 200ms saving. On Apollolake we have a prototype where MPinit happens in bootblock. That already reduces boot time by some 200ms. > Since, very soon, you'll run to shared HW resource, and then you'll need > to implement semaphores, atomic operations and God knows what!? Fortunately, divine powers have nothing to do with it. Atomic operations are already implemented and spinlocks are in as well. What other major issues you see, Zoran? thanks Andrey

2 1

Re: [coreboot] KGPE-D16 and Samsung DDR3L memory sticks
by Daniel Kulesz 14 Feb '17

14 Feb '17

Hi Paul, > Am Samstag, den 11.02.2017, 16:14 +0100 schrieb Daniel Kulesz: > > To answer my question myself: It works partially. > > > > > 1.) Samsung M393B1K70DH0-YK0 > > > > > > Type: DDR3 DIMM 240-Pin, reg ECC ? Ranks/Banks: dual rank, x4 ? Modules: 1x 8GB ? JEDEC: PC3L-12800R ? Voltage: 1.35V > > > > I got 8 of these working with one CPU package on the KGPE-D16 with > > one of the latest Coreboot master versions: > > (Please note, that coreboot is officially spelled all lowercase.) > > How much did you pay for these modules? > One of them costs around 12-25 Euros (used) or ~65 Euros (new). > Just to be sure. You got 64 GB of RAM working. If you plug in more > modules, it fails, right? > No. Using 64 GB worked more or less fine, but using *less* than 64 GB caused issues - depending in which slots I had put them. > > Version: 4.5-963-gf57a768 > > Please upload your logs to the board status repository. (This commit > has not been uploaded by REACTS, so it wouldn?t overwrite anything.) > I uploaded one of the tested configurations here: https://review.coreboot.org/cgit/board-status.git/commit/asus/kgpe-d16/4.5-… I was not able to upload more configurations since the build_status output folder is named after the build, and I didn't want to rename too much manually. > Without the logs, it?s hard to debug anything. Verbose logs are one of > the biggest advantages of coreboot. So please upload them, or attach > them. I attached the serial logs of one of the failing configurations (all orange slots populated). However, I was unable to reproduce the exact failure because meanwhile I populated the second CPU socket and didn't find a way to deactivate the CPU (after pulling the second power connector the system did not boot up at all). I also noticed the following messages in dmesg: [ 1561.833618] [Hardware Error]: Corrected error, no action required. [ 1561.840026] [Hardware Error]: CPU:16 (15:1:2) MC4_STATUS[Over|CE|MiscV|-|AddrV|-|-|CECC]: 0xdc644000ea080a13 [ 1561.851687] [Hardware Error]: Error Addr: 0x0000000ffe8a4c70 [ 1561.860313] [Hardware Error]: MC4 Error (node 2): DRAM ECC error detected on the NB. [ 1561.870995] [Hardware Error]: cache level: L3/GEN, mem/io: MEM, mem-tx: RD, part-proc: RES (no timeout) [ 1873.121721] mce: [Hardware Error]: Machine check events logged [ 1873.121777] [Hardware Error]: Corrected error, no action required. [ 1873.128184] [Hardware Error]: CPU:16 (15:1:2) MC4_STATUS[-|CE|MiscV|-|AddrV|-|-|CECC]: 0x9c644000ea080a13 [ 1873.142264] [Hardware Error]: Error Addr: 0x0000000ff95c9230 [ 1873.150857] [Hardware Error]: MC4 Error (node 2): DRAM ECC error detected on the NB. [ 1873.161573] [Hardware Error]: cache level: L3/GEN, mem/io: MEM, mem-tx: RD, part-proc: RES (no timeout) I didn't notice any of these before the installation of the second CPU module. Don't know if this is related or not. But I'll run a memtest next to check if maybe one of the modules could be faulty. Cheers, Daniel

1 1

ASUS KGPE-D16 Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 14 Feb '17

14 Feb '17

The ASUS KGPE-D16 fails verification for branch master as of commit b07d266042621e050962bb9ce814f1106d0a8bcf The following tests failed: BOOT_FAILURE Commits since last successful test: b07d266 google/poppy: select NO_FADT_8042 2864f85 intel/skylake: Disable FADT.8042 if NO_FADT_8042 is set See attached log for details This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] Add coreboot storage driver
by ron minnich 13 Feb '17

13 Feb '17

I don't see the big deal here, actually. We've had a nice concurrency in coreboot for years, it works, I've used it, what else do we need to do? On Mon, Feb 13, 2017 at 3:39 PM Vadim Bendebury <vbendeb(a)chromium.org> wrote: > Incidentally, a few years ago Chirantan and Simon (cced) implemented > u-boot concurrency support for an ARM SOC. I don't remember how much gain > it was bringing, and it did not go into production as it was quite late in > the project cycle. > > But they might have some experience to share. > > -v > > > On Tue, Feb 14, 2017 at 7:28 AM, Julius Werner <jwerner(a)chromium.org> > wrote: > > +1 for preferring a single-core concurrency model. This would be much more > likely to be reusable for other platforms, and much simpler to maintain in > the long run (way less platform-specific details to keep track of and > figure out again and again for every new chipset). You CAR problems would > become much more simple... just make sure the scheduler structures get > migrated together with the rest of the globals and it should work fine out > of the box. > > On Mon, Feb 13, 2017 at 12:31 PM, ron minnich <rminnich(a)gmail.com> wrote: > > > > On Mon, Feb 13, 2017 at 11:17 AM Nico Huber <nico.h(a)gmx.de> wrote: > > > > Another idea just popped up: Performing "background" tasks in udelay() > / mdelay() implementations ;) > > > that is adurbin's threading model. I really like it. > > A lot of times, concurrency will get you just as far as ||ism without the > nastiness. > > But if we're going to make a full up kernel for rom, my suggestion is we > could start with a real kernel, perhaps linux. We could then rename > coreboot to, say, LinuxBIOS. > > ron > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Add coreboot storage driver
by Vadim Bendebury 13 Feb '17

13 Feb '17

Incidentally, a few years ago Chirantan and Simon (cced) implemented u-boot concurrency support for an ARM SOC. I don't remember how much gain it was bringing, and it did not go into production as it was quite late in the project cycle. But they might have some experience to share. -v On Tue, Feb 14, 2017 at 7:28 AM, Julius Werner <jwerner(a)chromium.org> wrote: > +1 for preferring a single-core concurrency model. This would be much more > likely to be reusable for other platforms, and much simpler to maintain in > the long run (way less platform-specific details to keep track of and > figure out again and again for every new chipset). You CAR problems would > become much more simple... just make sure the scheduler structures get > migrated together with the rest of the globals and it should work fine out > of the box. > > On Mon, Feb 13, 2017 at 12:31 PM, ron minnich <rminnich(a)gmail.com> wrote: > >> >> >> On Mon, Feb 13, 2017 at 11:17 AM Nico Huber <nico.h(a)gmx.de> wrote: >> >>> >>> >>> Another idea just popped up: Performing "background" tasks in udelay() >>> / mdelay() implementations ;) >>> >> >> that is adurbin's threading model. I really like it. >> >> A lot of times, concurrency will get you just as far as ||ism without the >> nastiness. >> >> But if we're going to make a full up kernel for rom, my suggestion is we >> could start with a real kernel, perhaps linux. We could then rename >> coreboot to, say, LinuxBIOS. >> >> ron >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Add coreboot storage driver
by Julius Werner 13 Feb '17

13 Feb '17

+1 for preferring a single-core concurrency model. This would be much more likely to be reusable for other platforms, and much simpler to maintain in the long run (way less platform-specific details to keep track of and figure out again and again for every new chipset). You CAR problems would become much more simple... just make sure the scheduler structures get migrated together with the rest of the globals and it should work fine out of the box. On Mon, Feb 13, 2017 at 12:31 PM, ron minnich <rminnich(a)gmail.com> wrote: > > > On Mon, Feb 13, 2017 at 11:17 AM Nico Huber <nico.h(a)gmx.de> wrote: > >> >> >> Another idea just popped up: Performing "background" tasks in udelay() >> / mdelay() implementations ;) >> > > that is adurbin's threading model. I really like it. > > A lot of times, concurrency will get you just as far as ||ism without the > nastiness. > > But if we're going to make a full up kernel for rom, my suggestion is we > could start with a real kernel, perhaps linux. We could then rename > coreboot to, say, LinuxBIOS. > > ron > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

What does cmos option Experimental Memory Speed Boost do?
by Taiidan＠gmx.com 13 Feb '17

13 Feb '17

Is it safe to enable? what does it do?

2 1

← Newer
1
...
11
12
13
14
15
16
17
...
22
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 February 2017