coreboot August 2017

coreboot@coreboot.org

59 participants
132 discussions

Coreboot + TPM (Anti-Evil-Maid)
by Jo 24 Aug '17

24 Aug '17

Hello Guys, im trying to set up an Anti-Evil-maid stick.Ive done this before with no problems with Vendor Firmware, however,with coreboot im not even able to verify kernelsupport for TPM (the file pcrs isnt in /sys/devices/*/*/) ,i cant take ownership etc. I selected Support TPM in the .rom configuration, is there anything else to do? cheers

1 0

How is depreciating 95% of coreboot boards worth it for such minor improvements?
by Taiidan＠gmx.com 23 Aug '17

23 Aug '17

Just because a board lacks active developers doesn't mean that no one is using it. As a layman I simply can't understand as to how all these seemingly insignificant improvements such as CBMEM in ramstage make it worth removing almost every compatible board from the source, including nearly all the models that still have an open source init. To me it seems at the rate this is going soon all that will be left is a few blobbed and NDA'ed development boards unavailable to the general public. Am I mistaken?

6 7

Re: [coreboot] How is depreciating 95% of coreboot boards worth it for such minor improvements?
by Aaron Durbin 23 Aug '17

23 Aug '17

On Wed, Aug 23, 2017 at 8:31 PM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: > On Thu, Aug 24, 2017 at 12:29 AM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: >> Ah I see thanks for explaining. >> >> I had read all the AGESA boards were going to be removed, besides the asus >> D8/D16 those are the last and best owner controlled x86 boards. >> Is there a current list of boards to be removed? >> > > Hi > > The work for LATE -> EARLY CBMEM transition for AGESA has been > available for review since February 2017. It's probably announced or > mentioned only briefly on the mailing list, but certainly very visible > on gerrit. > > Unfortunately people currently working on AMD platforms did not show > much interest to review that work. Luckily, devs from chromeos team > (who had no commercial interest, but maybe strings attached) stepped > in the reviews so that the groundwork of AGESA interface changes got > done and reviewed. What's left is merging the individual board > changes, which I am about to do very soon now. Some regressions > expected, most of the old defects remain unfixed. > > I should thank the couple individuals and companies that contributed > by covering some costs of this development. Still, that does not > magically turn all these boards into status of "maintained". > > Now, this applies to everyone: please push status updates for the > boards you have access to, otherwise majority of AGESA boards just hit > that deprecation in the next cycle of board removals. Also, when you > create a board port and you go through all the trouble of getting it > past (my strict or someone else's less strict) review policy, is it > REALLY that hard to run board_status script? You know who you are. Is > there something we need to do better here? Provide OS boot images just > for this purpose? > > As for binaryPI boards, those are at EARLY_CBMEM_INIT starting from August 2. > > As for K8/K10, your help is needed in testing. This is particularly > for boards with multiple CPU packages (nodes). I do want to thank Kyösti for putting in the development effort in this area for these platforms. He's been actively maintaining and developing for a lot of platforms that have lost some love over the years. I know there are others who contribute as well, but I did want to call attention Kyösti's contribution as I've been following it fairly closely. It's very much appreciated. > > HTH, > Kyösti > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] How is depreciating 95% of coreboot boards worth it for such minor improvements?
by ron minnich 23 Aug '17

23 Aug '17

I am always sad to see boards go away, especially since it means that the amount of coreboot I still have code in is smaller by the month, but ... there's a real opportunity cost to keeping old boards in. We've had cases where a new, useful feature has to be implemented as a config variable since not all boards can support it. Frequently these are old boards and there's nobody around to add it. Further, experience has shown us that over time, even if nothing else changes, older boards just stop working due to toolchain changes or even bug fixes. I've had this happen to me several times, where I can't build a new image for a board that is "known good." I'm not the only one. It's a lot of work to keep a board current. We don't want coreboot to become a repo of broken boards. If nobody can stand up and state they are supporting a board, then it's time to end that board. And, as pointed out, this is git, there are branches, so no board is ever really gone. I think that for every board in the tip of tree, we should always have an active maintainer. It's just too easy for them to break otherwise. On Wed, Aug 23, 2017 at 1:13 PM Aaron Durbin via coreboot < coreboot(a)coreboot.org> wrote: > On Wed, Aug 23, 2017 at 2:06 PM, Felipe Sanches <juca(a)members.fsf.org> > wrote: > > Is there an index of which was the latest git commit for each removed > board > > ? > > That would help anyone interested in working on them in the future. It is > > not strictly necessary, but would certainly make life easier. And it > can't > > be that hard to update a wiki page (or something equivalent) any time > > there's a new board deprecation. > > Keep in mind that branches exist for each release which inherently has > the full history at time of release: > > $ git ls-remote upstream refs/heads/* > 6cb3a59fd5e754c3627b79db21c5bcc284bfd721 refs/heads/4.1 > ad342a4589df6c51c96c1e9110979964b244fec3 refs/heads/4.2 > 1bf5e6409678d04fd15f9625460078853118521c refs/heads/4.3 > 588ccaa9a7d94da4f5a5b3579eb9e3d06c9f4a51 refs/heads/4.4 > c21e07385f9b4048d6ddb67989b23999f566951d refs/heads/classic-2014.10 > e9418b454f6d2734360ca4e3c017f59904490d9f refs/heads/coreboot-v1 > 25d77ad675f8bac8fd7e038801c72797ea8dc7d6 refs/heads/coreboot-v3 > 4fcce9da0a1b62b46ed78c522f6fcbf51ff5974e refs/heads/foo2 > f5fe3590af9a67f9fd3adaee85168d3cac0d84d0 refs/heads/master > > > > > > 2017-08-23 16:53 GMT-03:00 Nico Huber <nico.h(a)gmx.de>: > >> > >> Hi, > >> > >> On 23.08.2017 06:00, Taiidan(a)gmx.com wrote: > >> > Just because a board lacks active developers doesn't mean that no one > is > >> > using it. > >> > >> right, and we won't stop anybody from using them in the future. Please > >> keep in mind, when a board is removed from the tree that only means that > >> the people working on newer boards don't maintain the old ones any more. > >> You can still check out the parent of the removal commit and build these > >> boards. I don't know which boards exactly are in question, but older > >> board ports are often broken anyway. So you can't argue that keeping > >> them in the tree would magically make them work. > >> > >> > As a layman I simply can't understand as to how all these seemingly > >> > insignificant improvements such as CBMEM in ramstage make it worth > >> > removing almost every compatible board from the source, > >> > >> I agree that these improvements would be insignificant to the boards in > >> question. Though, making improvements at all for newer platforms is much > >> harder if you have to take care of the old platforms (with incompatible > >> code) too. > >> > >> > including nearly > >> > all the models that still have an open source init. > >> > >> Can I see numbers please? I count about 50 Intel based boards (not > >> counting variants) with free init code which is actively developed. > >> There are more on the ARM front and probably some AMD based too. They'll > >> all stay. How many are we going to remove? > >> > >> > To me it seems at the rate this is going soon all that will be left > is a > >> > few blobbed and NDA'ed development boards unavailable to the general > >> > public. > >> > >> What rate? how many have we removed already? 2? If you estimate from > >> that and the prospect that we'll remove 50+ one year later, well, then > >> we'd remove 1,000+ boards next year. That would indeed be a problem... > >> > >> > > >> > Am I mistaken? > >> > >> Yes, I guess. > >> > >> Nico > >> > >> -- > >> coreboot mailing list: coreboot(a)coreboot.org > >> https://mail.coreboot.org/mailman/listinfo/coreboot > > > > > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] How is depreciating 95% of coreboot boards worth it for such minor improvements?
by Aaron Durbin 23 Aug '17

23 Aug '17

On Wed, Aug 23, 2017 at 2:06 PM, Felipe Sanches <juca(a)members.fsf.org> wrote: > Is there an index of which was the latest git commit for each removed board > ? > That would help anyone interested in working on them in the future. It is > not strictly necessary, but would certainly make life easier. And it can't > be that hard to update a wiki page (or something equivalent) any time > there's a new board deprecation. Keep in mind that branches exist for each release which inherently has the full history at time of release: $ git ls-remote upstream refs/heads/* 6cb3a59fd5e754c3627b79db21c5bcc284bfd721 refs/heads/4.1 ad342a4589df6c51c96c1e9110979964b244fec3 refs/heads/4.2 1bf5e6409678d04fd15f9625460078853118521c refs/heads/4.3 588ccaa9a7d94da4f5a5b3579eb9e3d06c9f4a51 refs/heads/4.4 c21e07385f9b4048d6ddb67989b23999f566951d refs/heads/classic-2014.10 e9418b454f6d2734360ca4e3c017f59904490d9f refs/heads/coreboot-v1 25d77ad675f8bac8fd7e038801c72797ea8dc7d6 refs/heads/coreboot-v3 4fcce9da0a1b62b46ed78c522f6fcbf51ff5974e refs/heads/foo2 f5fe3590af9a67f9fd3adaee85168d3cac0d84d0 refs/heads/master > > 2017-08-23 16:53 GMT-03:00 Nico Huber <nico.h(a)gmx.de>: >> >> Hi, >> >> On 23.08.2017 06:00, Taiidan(a)gmx.com wrote: >> > Just because a board lacks active developers doesn't mean that no one is >> > using it. >> >> right, and we won't stop anybody from using them in the future. Please >> keep in mind, when a board is removed from the tree that only means that >> the people working on newer boards don't maintain the old ones any more. >> You can still check out the parent of the removal commit and build these >> boards. I don't know which boards exactly are in question, but older >> board ports are often broken anyway. So you can't argue that keeping >> them in the tree would magically make them work. >> >> > As a layman I simply can't understand as to how all these seemingly >> > insignificant improvements such as CBMEM in ramstage make it worth >> > removing almost every compatible board from the source, >> >> I agree that these improvements would be insignificant to the boards in >> question. Though, making improvements at all for newer platforms is much >> harder if you have to take care of the old platforms (with incompatible >> code) too. >> >> > including nearly >> > all the models that still have an open source init. >> >> Can I see numbers please? I count about 50 Intel based boards (not >> counting variants) with free init code which is actively developed. >> There are more on the ARM front and probably some AMD based too. They'll >> all stay. How many are we going to remove? >> >> > To me it seems at the rate this is going soon all that will be left is a >> > few blobbed and NDA'ed development boards unavailable to the general >> > public. >> >> What rate? how many have we removed already? 2? If you estimate from >> that and the prospect that we'll remove 50+ one year later, well, then >> we'd remove 1,000+ boards next year. That would indeed be a problem... >> >> > >> > Am I mistaken? >> >> Yes, I guess. >> >> Nico >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] How is depreciating 95% of coreboot boards worth it for such minor improvements?
by szbnwer＠gmail.com 23 Aug '17

23 Aug '17

2017-08-23 6:00 GMT+02:00 Taiidan(a)gmx.com <Taiidan(a)gmx.com>: > Just because a board lacks active developers doesn't mean that no one is > using it. > As a layman I simply can't understand as to how all these seemingly > insignificant improvements such as CBMEM in ramstage make it worth removing > almost every compatible board from the source, including nearly all the > models that still have an open source init. > > To me it seems at the rate this is going soon all that will be left is a few > blobbed and NDA'ed development boards unavailable to the general public. > > Am I mistaken? > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot +1! :)

1 0

Re: [coreboot] coreboot community meeting: August 17, 2017
by Arthur Heymans 22 Aug '17

22 Aug '17

> Development > > * Tianocore patches merged, and working for at least a subset of > boards. Some boards still need some work. Need to test on 32-bit > machine. > I tested a 32bit build on my 32bit-only Thinkpad X60 and while I did not test if it was able to boot something (no EFI bootloader on it), it seemed to work fine and greeted me with the tianocore loading screen. -- Arthur Heymans

1 0

coreboot community meeting: August 17, 2017
by Martin Roth 22 Aug '17

22 Aug '17

Last week's meeting was another quick meeting, so the suggestion was made to switch from bi-weekly to monthly (every 4 weeks). The next meeting will bee Thursday, September 14. Check the calendar to find the meeting in your timezone:. https://coreboot.org/calendar We'd also like to see if we can have a volunteer from the community to work on the agenda and/or run the meetings. Due to changing obligations, it has become difficult for Martin to continue running the community meeting. ####################################################################### Date: Thursday, August 17, 2017 General coreboot news & Discussion * Abandoned patches older than 18 months. (Stefan still reviewing his) * Martin can't continue running these meetings. Do we have a volunteer to take it over? * Move this meeting to Monthly instead of bi-weekly? Would more people attend? Development * Tianocore patches merged, and working for at least a subset of boards. Some boards still need some work. Need to test on 32-bit machine. Infrastructure News * Continuing work to evaluate concourse CI. * PhilMD discussed having the CI system test QEMU. Some work on that was already planned, but extending it would be great. https://review.coreboot.org/#/c/20877 Conferences * North American conference: Still trying to nail down the location and date.

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 22 Aug '17

22 Aug '17

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 3 new defect(s) introduced to coreboot found with Coverity Scan. 3 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 1379849: Null pointer dereferences (FORWARD_NULL) /src/soc/intel/cannonlake/pmutil.c: 211 in soc_get_gpe_configs() ________________________________________________________________________________________________________ *** CID 1379849: Null pointer dereferences (FORWARD_NULL) /src/soc/intel/cannonlake/pmutil.c: 211 in soc_get_gpe_configs() 205 206 /* Look up the device in devicetree */ 207 DEVTREE_CONST struct device *dev = dev_find_slot(0, PCH_DEVFN_PMC); 208 if (!dev || !dev->chip_info) { 209 printk(BIOS_ERR, "BUG! Could not find SOC devicetree config\n"); 210 } >>> CID 1379849: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "dev". 211 config = dev->chip_info; 212 213 /* Assign to out variable */ 214 *dw0 = config->gpe0_dw0; 215 *dw1 = config->gpe0_dw1; 216 *dw2 = config->gpe0_dw2; ** CID 1379848: Null pointer dereferences (FORWARD_NULL) /src/soc/intel/cannonlake/pmutil.c: 214 in soc_get_gpe_configs() ________________________________________________________________________________________________________ *** CID 1379848: Null pointer dereferences (FORWARD_NULL) /src/soc/intel/cannonlake/pmutil.c: 214 in soc_get_gpe_configs() 208 if (!dev || !dev->chip_info) { 209 printk(BIOS_ERR, "BUG! Could not find SOC devicetree config\n"); 210 } 211 config = dev->chip_info; 212 213 /* Assign to out variable */ >>> CID 1379848: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "config". 214 *dw0 = config->gpe0_dw0; 215 *dw1 = config->gpe0_dw1; 216 *dw2 = config->gpe0_dw2; ** CID 1379847: Control flow issues (DEADCODE) /src/cpu/x86/lapic/lapic_cpu_init.c: 529 in wait_other_cpus_stop() ________________________________________________________________________________________________________ *** CID 1379847: Control flow issues (DEADCODE) /src/cpu/x86/lapic/lapic_cpu_init.c: 529 in wait_other_cpus_stop() 523 if (!cpu->initialized) 524 printk(BIOS_ERR, "CPU 0x%02x did not initialize!\n", 525 cpu->path.apic.apic_id); 526 } 527 printk(BIOS_DEBUG, "All AP CPUs stopped (%ld loops)\n", loopcount); 528 checkstack(_estack, 0); >>> CID 1379847: Control flow issues (DEADCODE) >>> Execution cannot reach the expression "i <= last_cpu_index" inside this statement: "for (i = 1; i < 1 && i <= l...". 529 for (i = 1; i < CONFIG_MAX_CPUS && i <= last_cpu_index; i++) 530 checkstack((void *)stacks[i] + CONFIG_STACK_SIZE, i); 531 } 532 533 void initialize_cpus(struct bus *cpu_bus) 534 { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Re: [coreboot] Need help implementing romstage CBMEM
by Keith Hui 21 Aug '17

21 Aug '17

Hi All, I got some assistance from Aaron via gerrit [1] and he had me try some changes. He also asked for my .config which is attached here. However, the key parts are: CONFIG_DCACHE_RAM_BASE=0xcf000 CONFIG_DCACHE_RAM_SIZE=0x01000 This is not consistent with the hard coded assumption cpu/intel/car/romstage.c: #define DCACHE_RAM_ROMSTAGE_STACK_SIZE 0x2000 There is not enough CAR for the entire romstage stack. Reverting to romstage_legacy and just initializing cbmem directly there isn't taking me far either, at least I see the ramstage copy of get_top_of_ram() get run. Next I am going to try "modern" romstage again with an increased CONFIG_DCACHE_RAM_SIZE, but I want to get as much info out as soon as I can for tips. [1] https://review.coreboot.org/20977 On Sat, Aug 12, 2017 at 10:44 PM, Keith Hui <buurin(a)gmail.com> wrote: > Hi all, > > After reading the code for more recent Intel northbridges I think I > have an idea on what needs to be added, so here is my attempt to bring > 440BX to coreboot 4.7 standards: > > https://review.coreboot.org/20977 > > The problem is it could not boot. The console log is attached. > > In short, I think I have the top of RAM value correct, but it could > not find a place for the payload to load and the boot process is > stuck. > > What am I missing? > > By the way, I think an unintended update for my two earlier patches > were also pushed along with this change. How to I get them sorted out? > [1] [2] > > Thanks > Keith > > [1] https://review.coreboot.org/c/20868/ > [2] https://review.coreboot.org/c/20952/

1 0

← Newer
1
2
3
4
5
6
7
...
14
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 August 2017