Re: [coreboot] GSoC 2014
This is a great start :-) On Thu, Mar 20, 2014 at 1:56 PM, Allen Yan lex...@gmail.com wrote: Hi, coreboot+seabios running in QEMU output: coreboot-4.0-5656-gb34739b Thu Mar 13 10:37:43 CST 2014 starting... CBMEM region 3fee-3fff (cbmem_check_toc) CBMEM region 3fee-3fff (cbmem_initialize_empty) Adding CBMEM entry as no. 1 Adding CBMEM entry as no. 2 Trying CBFS ramstage loader. CBFS: loading stage fallback/coreboot_ram @ 0x10 (180280 bytes), entry @ 0x10 QEMU debugcon not found [port 0x402] coreboot-4.0-5656-gb34739b Thu Mar 13 10:37:43 CST 2014 booting... Enumerating buses... Show all devs...Before device enumeration. Root Device: enabled 1 CPU_CLUSTER: 0: enabled 1 APIC: 00: enabled 1 DOMAIN: : enabled 1 PCI: 00:00.0: enabled 1 PCI: 00:01.0: enabled 1 PCI: 00:01.1: enabled 1 PCI: 00:01.3: enabled 1 Compare with tree... Root Device: enabled 1 CPU_CLUSTER: 0: enabled 1 APIC: 00: enabled 1 DOMAIN: : enabled 1 PCI: 00:00.0: enabled 1 PCI: 00:01.0: enabled 1 PCI: 00:01.1: enabled 1 PCI: 00:01.3: enabled 1 scan_static_bus for Root Device CPU_CLUSTER: 0 enabled DOMAIN: enabled CPU_CLUSTER: 0 scanning... QEMU: firmware config interface detected QEMU: max_cpus is 1 CPU: APIC: 00 enabled DOMAIN: scanning... PCI: pci_scan_bus for bus 00 PCI: 00:00.0 [8086/1237] ops PCI: 00:00.0 [8086/1237] enabled PCI: 00:01.0 [8086/7000] bus ops PCI: 00:01.0 [8086/7000] enabled PCI: 00:01.1 [8086/7010] ops PCI: 00:01.1 [8086/7010] enabled PCI: 00:01.3 [8086/7113] bus ops Wakeup from ACPI sleep type S5 (PMCNTRL=) PCI: 00:01.3 [8086/7113] enabled PCI: 00:02.0 [1013/00b8] ops PCI: 00:02.0 [1013/00b8] enabled PCI: 00:03.0 [8086/100e] enabled scan_static_bus for PCI: 00:01.0 scan_static_bus for PCI: 00:01.0 done scan_static_bus for PCI: 00:01.3 scan_static_bus for PCI: 00:01.3 done PCI: pci_scan_bus returning with max=001 scan_static_bus for Root Device done done found VGA at PCI: 00:02.0 Setting up VGA for PCI: 00:02.0 Setting PCI_BRIDGE_CTL_VGA for bridge DOMAIN: Setting PCI_BRIDGE_CTL_VGA for bridge Root Device Allocating resources... Reading resources... Root Device read_resources bus 0 link: 0 CPU_CLUSTER: 0 read_resources bus 0 link: 0 APIC: 00 missing read_resources CPU_CLUSTER: 0 read_resources bus 0 link: 0 done QEMU: 5 files in fw_cfg QEMU: etc/boot-fail-wait [size=4] QEMU: genroms/kvmvapic.bin [size=9216] QEMU: etc/system-states [size=6] QEMU: etc/pvpanic-port [size=2] QEMU: bootorder [size=0] QEMU: cmos: 1024 MiB RAM below 4G. QEMU: cmos: 0 MiB RAM above 4G. QEMU: reserve ioports 0x0510-0x0511 [firmware-config] QEMU: reserve ioports 0x5658-0x5658 [vmware-port] QEMU: reserve ioports 0xae00-0xae0f [pci-hotplug] QEMU: reserve ioports 0xaf00-0xaf1f [cpu-hotplug] QEMU: reserve ioports 0xafe0-0xafe3 [piix4-gpe0] CBMEM region 3fee-3fff (cbmem_late_set_table) DOMAIN: read_resources bus 0 link: 0 DOMAIN: read_resources bus 0 link: 0 done Root Device read_resources bus 0 link: 0 done Done reading resources. Show resources in subtree (Root Device)...After reading. Root Device child on link 0 CPU_CLUSTER: 0 CPU_CLUSTER: 0 child on link 0 APIC: 00 APIC: 00 DOMAIN: child on link 0 PCI: 00:00.0 DOMAIN: resource base 0 size 0 align 0 gran 0 limit flags 40040100 index 1000 DOMAIN: resource base 0 size 0 align 0 gran 0 limit flags 40040200 index 1100 DOMAIN: resource base 0 size a align 0 gran 0 limit 0 flags e0004200 index a DOMAIN: resource base c size 3ff4 align 0 gran 0 limit 0 flags e0004200 index b DOMAIN: resource base 510 size 2 align 0 gran 0 limit flags e100 index c DOMAIN: resource base 5658 size 1 align 0 gran 0 limit flags e100 index d DOMAIN: resource base ae00 size 10 align 0 gran 0 limit flags e100 index e DOMAIN: resource base af00 size 20 align 0 gran 0 limit flags e100 index f DOMAIN: resource base afe0 size 4 align 0 gran 0 limit flags e100 index 10 DOMAIN: resource base fec0 size 10 align 0 gran 0 limit flags e200 index 2 DOMAIN: resource base fee0 size 1 align 0 gran 0 limit flags e200 index 3 PCI: 00:00.0 PCI: 00:01.0 PCI: 00:01.0 resource base 0 size 1000 align 0 gran 0 limit flags c100 index 1 PCI: 00:01.0 resource base ff80 size 80 align 0 gran 0 limit 0 flags d200 index 2 PCI: 00:01.1 PCI: 00:01.1 resource base 0 size 10 align 4 gran 4 limit flags 100 index 20 PCI: 00:01.3 PCI: 00:01.3 resource base e400 size 40 align 0 gran 0 limit flags d100 index 1 PCI: 00:01.3 resource base f00 size 10 align 0 gran 0 limit flags d100 index 2 PCI: 00:02.0 PCI: 00:02.0 resource base 0 size 200 align 25 gran 25
Re: [coreboot] Changes to the coreboot Project Structure
On Thu, Mar 20, 2014 at 9:31 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: On 21.03.2014 01:39, Carl-Daniel Hailfinger wrote: Hi Stefan, streamlining development and maintenance is definitely absoutely worthwhile. Getting rid of unmaintained code is also a good thing. The guidelines presented in your mail look mostly good IMHO, but I'd like to comment on a few things. Am 20.03.2014 22:55 schrieb Stefan Reinauer: * Significantly reduce number of submitters To ensure consistency, scalability and conformity with the general coreboot strategy, we need to define a clear committer structure that defines the original project structure of having a benevolent dictator aka project leader (Stefan Reinauer) and gatekeepers in place. The suggested structure will need to value both community interests and corporate interests equally and hence a good setup would be to have a final amount of six developers with submit rights, three community representatives and three corporate representatives (on from each major stakeholder): I see a huge bottleneck in restricting the number of committers to six. - Corporate committers will be primarily obliged to get the stuff of their own employer committed, but if they are ill or on vacation, someone else would have to take over. This would either be another corporate committer (in which case their own employer would have to authorize spending time for a different company) or a community committer. - Community committers are not paid, and commit in their spare time. Spare time is not necessarily abundant all year round. Speaking from experience, the flashrom project has no shortage in developers or submitted patches, but a real and painful shortage in reviewers/committers. The flashrom project patch backlog is huge due to this. Doing a commit is easy, but making sure that a commit follows certain guidelines is a huge time sink with none of the fun of writing code. - New contributors (corporate or community) would have to find a sponsor to actually commit their code. With a large committer base, this can happen rather quickly. With only six committers facing their own deadlines or other shortages of time, this could take quite a while. The proposition of gatekeepers would essentially kill community effort. Even in current infrastructure reviewing is a major slowdown. With small number of gatekeepers there wouldn't be any significant contributions as the gatekeepers wouldn't be able to review them in reasonable time, which will, in turn discourage contributions. You may as well just stop accepting community contributions right now: it turns out to be the same thing, just a little bit quicker. You cannot treat community as some kind of corporate entity. Peter Stuge, Kyösti Mälkki, N.N. (non-commercial part of the coreboot community) Sounds like a joke. While Peter is competent, he's also very busy. I'd expect his review thoughtput of perhaps a patch a week. You can't realistically put such burden on few people. If you want a corporate version of coreboot, I think you have to use a workflow similar to Fedora vs Red Hat Enterprise Linux. The changes you proposed would effectively make coreboot into corporate project. I'd expect a community fork to emerge quickly, outside of this new limiting infrastructure and I'll be surely moving to community fork. I will be joining you on the community fork. We can call it FedoraBoot (just kidding). This Google-sponsored takeover of the coreboot leadership cannot be allowed to succeed. I appreciate all that Google has done to promote coreboot. I want them to continue. But Google and the community need to talk more about Google's code dumps, unexplained demands, and closed development. If instead Google finds it more convenient to just co-opt coreboot by Significantly reduce number of submitters then coreboot.org is no more open to committers than chromium.org. We will fork. David -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On 03/20/2014 11:55 PM, Stefan Reinauer wrote: Changes to the coreboot Project Structure .. * Significantly reduce number of submitters To ensure consistency, scalability and conformity with the general coreboot strategy, we need to define a clear committer structure that defines the original project structure of having a benevolent dictator aka project leader (Stefan Reinauer) and gatekeepers in place. The suggested structure will need to value both community interests and corporate interests equally and hence a good setup would be to have a final amount of six developers with submit rights, three community representatives and three corporate representatives (on from each major stakeholder): Current suggestions: Patrick Georgi (Secunet) Marc Jones (Sage) Stefan Reinauer (Google) Peter Stuge, Kyösti Mälkki, N.N. (non-commercial part of the coreboot community) Status: TO BE IMPLEMENTED Hi Just for quick reference, I have read this proposal previously with following comments: For now I am not declining, at least (from becoming a gatekeeper). It finally depends a lot of the final structure of this hierarchy and what goals it sets. One thing you need to add to this document is how project leaders plan to proceed with on-going and further violations of GPL copyright holders rights, as IBV/ODM/OEM chain refuses to make the distributed firmware binaries traceable to the sources they were built from. Regards, Kyösti -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
On 03/21/2014 12:39 AM, Stefan Reinauer wrote: * ron minnich rminn...@gmail.com [140320 22:37]: I like this, I just wish we could remove more boards :-) I was surprised that the number of boards still using ROMCC for romstage was so low. We could also remove the revF and Fam10 boards because the use non-standardized cache as ram implementation. Are any boards in particular making progress hard? Stefan I never heard of standardized cache-as-ram implementation. I assume you mean K8 too (pre-F). I think none of these boards never got really _properly_ ported from ROMCC days as they are built by including all source files in romstage.c. Kyösti -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
On 03/21/2014 02:58 AM, Stefan Reinauer wrote: * Stefan Tauner stefan.tau...@student.tuwien.ac.at [140321 01:42]: On Thu, 20 Mar 2014 22:33:21 +0100 Stefan Reinauer stefan.reina...@coreboot.org wrote: dmp/vortex86ex What's exactly wrong with that one? DMP ported their SoC themselves less than half a year ago, and I seriously doubt that dropping that already would be a good marketing move for coreboot at all. :) I noticed that too... No boards are being dropped, they continue to be present in the 4.0 branch. Maybe the board can be converted to use cache as ram? (That was the only criteria for any board on the list, as going forward it will be harder and harder to support romcc-romstage boards, at no real benefit) Stefan There is no MTRR support in vortex86ex. Kyösti -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
On 20.03.2014 22:33, Stefan Reinauer wrote: During this time we collected over 250 different mainboards. A great achievement, I suppose that most of boards were contributed by non-commercial community. Yet now you propose to basically kill this chicken nesting golden eggs and make coreboot commercial-only. Sorry but your proposition with handling non-commercial community doesn't make any sense at all. You propose to represent the community by small number of people who most likely won't be available enough and who don't represent the community as whole. No single person or small team can represent an entire community, no matter how these persons are knowledgeable and competent. Commercial entity could be represented by one person but a community of independent volunteers can't. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] GSoC-2014 Coreboot project
Hi, everyone, I've sent a preliminary proposal about Tianocore as coreboot payload. https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/jinyiyan/5629499534213120 I'd like to get more feedback about the goal and the test environment. Thanks! Regards! Jinyi Yan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
On Fri, Mar 21, 2014 at 7:55 AM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: I suppose that most of boards were contributed by non-commercial community. It's much more complicated than that. The initial support for coreboot came from DOE. SiS gve a lot of support with early boards and chipsets, as did via and to some extent Acer. LNXI was tremendous, providing romcc and the alpha port. DOE funded a PowerPC port. AMD gave us AGESA, and their commitment to releasing source began in 2007 and continues to this day. More recently, SAGE gave us several boards, and Google of course gave us the Ivybridge, Sandybridge, Haswell, Baytrail, and ARM ports, including V8. The German Gov't gave us the i945 bits. We got some very nice early contributions for Geode from a community developer, but starting in 2006 AMD committed two full time guys for several years to make it an industrial quality port; their work spanned 3 years. Core Systems carried the ball for many years in Germany, and it was a very lonely time for them. If you look carefully, or if you have been here since the beginning as I have, you'll realize that your claim here is quite wrong. This is not like Linux. You can no longer just jump in with some docs and get a chipset done in a few months on your own, as I did for the 440gx in 1999. You need a substantial financial commitment to do a chipset, as well as access to documents that are very hard to get in some cases, before you can even start. I estimate based on what I know of the people involved at various companies, and taking a very low burdened headcount cost, that the companies involved have contributed well over $50M to this effort. And that's only taking the people I know. There are lots of others I don't know. In general, the wonderful work by our non-commercial people has been to take an existing chipset port to a new mainboard -- a lot of work, but anywhere from 10x to 100x less work than the chipset work as I can tell you from experience -- or to improve common code that applies to all motherboards, such as cbfs; and, of course, in addition to coding we see the outstanding job people like Peter do on outreach. Vladimir, you are one of our extreme cases, given your levels of contribution of chipset code for the intel chipset MRC and graphics on the thinkpads :-) How you figured that memory training stuff out I don't know. It's just not fair to discount the gov't and commercial involvement in coreboot. Without those sustaining commitments over the last 15 years coreboot would not exist. And, like it or not, they represent by far the greatest amount of code that has been contributed to coreboot. You don't have to believe me; check the numbers. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
On Fri, 21 Mar 2014 23:23:51 +0800 Allen Yan lex...@gmail.com wrote: Hi, everyone, I've sent a preliminary proposal about Tianocore as coreboot payload. https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/jinyiyan/5629499534213120 I'd like to get more feedback about the goal and the test environment. Does not seem to be public. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] libpayload for ARM with sprinklings of GPL and coreboot code sharing
Am Donnerstag, den 20.03.2014, 17:57 -0500 schrieb mrnuke: * Share these drivers between coreboot and libpayload. Make them BSD-l, like cbfs-core. * libpayload core remains BSD. with strings attached - I'd like to avoid that. If you need SoC drivers, the *BSDs have their share of drivers, too. Typically of a better quality than the Linux ones (but less battle tested). Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
Am Donnerstag, den 20.03.2014, 22:33 +0100 schrieb Stefan Reinauer: Appendix A: romcc boards to be removed bifferos/bifferboard dmp/vortex86ex These are unfortunate, since they're relatively new ports (and one of them by the vendor, no less!). I hope their RAM init is relatively simple - in that case, it might be possible to restrict romcc use to their northbridge code, without affecting common coreboot code. Patrick signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On Thu, Mar 20, 2014 at 2:55 PM, Stefan Reinauer stefan.reina...@coreboot.org wrote: * Build a MAINTAINERS file for common code, and encourage people to keep subsystem maintainers in the loop for changes Aiming for top notch code quality, the coreboot project is generally trying to provide a solid and scalable framework for development as well as a number of generic cross-chipset components. Changes to these parts of the coreboot code affect a large number of supported systems. Hence it is important to have gatekeepers in place to guarantee they stay operational. For non-common code, I am curious if it's possible to make MAINTAINERS hierarchical, perhaps by using multiple files or adding an optional path next to the person's name in the top-level file. For example, if somebody has a particular interest in the x201, they can echo $NAME src/mainboard/lenovo/x201/MAINTAINERS or echo $NAME src/mainboard/lenovo/x201 MAINTAINERS and then have gerrit add $NAME as a reviewer to any patches that touch the subdirectory. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On Thu, Mar 20, 2014 at 5:39 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: Hi Stefan, streamlining development and maintenance is definitely absoutely worthwhile. Getting rid of unmaintained code is also a good thing. The guidelines presented in your mail look mostly good IMHO, but I'd like to comment on a few things. Am 20.03.2014 22:55 schrieb Stefan Reinauer: * Significantly reduce number of submitters To ensure consistency, scalability and conformity with the general coreboot strategy, we need to define a clear committer structure that defines the original project structure of having a benevolent dictator aka project leader (Stefan Reinauer) and gatekeepers in place. The suggested structure will need to value both community interests and corporate interests equally and hence a good setup would be to have a final amount of six developers with submit rights, three community representatives and three corporate representatives (on from each major stakeholder): I see a huge bottleneck in restricting the number of committers to six. - Corporate committers will be primarily obliged to get the stuff of their own employer committed, but if they are ill or on vacation, someone else would have to take over. This would either be another corporate committer (in which case their own employer would have to authorize spending time for a different company) or a community committer. Companies that get open-source development don't operate that way, thankfully. - Community committers are not paid, and commit in their spare time. Spare time is not necessarily abundant all year round. Speaking from experience, the flashrom project has no shortage in developers or submitted patches, but a real and painful shortage in reviewers/committers. The flashrom project patch backlog is huge due to this. Flashrom's problems run a lot deeper than that. Rather than regurgitate old discussion, I'll point to this thread: http://www.flashrom.org/pipermail/flashrom/2013-July/011271.html Doing a commit is easy, but making sure that a commit follows certain guidelines is a huge time sink with none of the fun of writing code. - New contributors (corporate or community) would have to find a sponsor to actually commit their code. With a large committer base, this can happen rather quickly. With only six committers facing their own deadlines or other shortages of time, this could take quite a while. AFAICS the reason to reduce the number of coreboot committers is to have gatekeepers who actually enforce guidelines by looking at patches before they commit them. That essentially introduces an additional review step. Anybody can review a patch and give it a score. AFAICT gatekeepers are necessarily tasked with scrutinizing code, and in fact that will be impossible in many cases where documentation for a new chip isn't public. The way I read it, a committer ensures that patches meet quality/consistency guidelines, adds additional reviewers/stakeholders when appropriate, and can optionally do a more thorough review, with the intention of helping authors to navigate the review process effectively. How many times have community members sent their patches for review only to have them bitrot for days, weeks, or even months? There have been many occasions where Stefan and Ron spend a weekends hanging out in a coffee shop and just going thru stale patches on gerrit to try to reduce the backlog. I doubt the intention is to make the review process more bureaucratic or increase the backlog. While such a step may be desirable, it would have to be made clear whose obligation it is to carry out commit+review step for new contributors, and how any fallback/failover mechanisms are implemented. MAINTAINERS file? Having gerrit automatically add reviewers would be tremendously helpful too. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On Fri, Mar 21, 2014 at 11:52 AM, David Hendricks dhend...@google.comwrote: On Thu, Mar 20, 2014 at 5:39 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: Hi Stefan, streamlining development and maintenance is definitely absoutely worthwhile. Getting rid of unmaintained code is also a good thing. The guidelines presented in your mail look mostly good IMHO, but I'd like to comment on a few things. Am 20.03.2014 22:55 schrieb Stefan Reinauer: * Significantly reduce number of submitters To ensure consistency, scalability and conformity with the general coreboot strategy, we need to define a clear committer structure that defines the original project structure of having a benevolent dictator aka project leader (Stefan Reinauer) and gatekeepers in place. The suggested structure will need to value both community interests and corporate interests equally and hence a good setup would be to have a final amount of six developers with submit rights, three community representatives and three corporate representatives (on from each major stakeholder): I see a huge bottleneck in restricting the number of committers to six. - Corporate committers will be primarily obliged to get the stuff of their own employer committed, but if they are ill or on vacation, someone else would have to take over. This would either be another corporate committer (in which case their own employer would have to authorize spending time for a different company) or a community committer. Companies that get open-source development don't operate that way, thankfully. - Community committers are not paid, and commit in their spare time. Spare time is not necessarily abundant all year round. Speaking from experience, the flashrom project has no shortage in developers or submitted patches, but a real and painful shortage in reviewers/committers. The flashrom project patch backlog is huge due to this. Flashrom's problems run a lot deeper than that. Rather than regurgitate old discussion, I'll point to this thread: http://www.flashrom.org/pipermail/flashrom/2013-July/011271.html Doing a commit is easy, but making sure that a commit follows certain guidelines is a huge time sink with none of the fun of writing code. - New contributors (corporate or community) would have to find a sponsor to actually commit their code. With a large committer base, this can happen rather quickly. With only six committers facing their own deadlines or other shortages of time, this could take quite a while. AFAICS the reason to reduce the number of coreboot committers is to have gatekeepers who actually enforce guidelines by looking at patches before they commit them. That essentially introduces an additional review step. Anybody can review a patch and give it a score. AFAICT gatekeepers are necessarily tasked with scrutinizing code, s/are/are NOT and in fact that will be impossible in many cases where documentation for a new chip isn't public. The way I read it, a committer ensures that patches meet quality/consistency guidelines, adds additional reviewers/stakeholders when appropriate, and can optionally do a more thorough review, with the intention of helping authors to navigate the review process effectively. How many times have community members sent their patches for review only to have them bitrot for days, weeks, or even months? There have been many occasions where Stefan and Ron spend a weekends hanging out in a coffee shop and just going thru stale patches on gerrit to try to reduce the backlog. I doubt the intention is to make the review process more bureaucratic or increase the backlog. While such a step may be desirable, it would have to be made clear whose obligation it is to carry out commit+review step for new contributors, and how any fallback/failover mechanisms are implemented. MAINTAINERS file? Having gerrit automatically add reviewers would be tremendously helpful too. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
2014-03-21 19:45 GMT+08:00 Kyösti Mälkki kyosti.mal...@gmail.com: On 03/21/2014 02:58 AM, Stefan Reinauer wrote: * Stefan Tauner stefan.tau...@student.tuwien.ac.at [140321 01:42]: Maybe the board can be converted to use cache as ram? (That was the only criteria for any board on the list, as going forward it will be harder and harder to support romcc-romstage boards, at no real benefit) There is no MTRR support in vortex86ex. Yes, that is right. DMP/Vortex86EX has no MTRR. So it maybe a problem if without romcc. :( -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
On Saturday, March 22, 2014 03:56:46 AM Andrew Wu wrote: Yes, that is right. DMP/Vortex86EX has no MTRR. So it maybe a problem if without romcc. :( Is there any way whatsoever to temporarily use the cache as SRAM? Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
On Fri, Mar 21, 2014 at 1:33 PM, mrnuke mr.nuke...@gmail.com wrote: On Saturday, March 22, 2014 03:56:46 AM Andrew Wu wrote: Yes, that is right. DMP/Vortex86EX has no MTRR. So it maybe a problem if without romcc. :( Is there any way whatsoever to temporarily use the cache as SRAM? when we did the first real CAR work MTRRs were not needed. I'm not sure if they would be on the vortex. We might want to test the very early CAR code and see how it goes. It's actually quite simple. Also, let's just take it a little easy here. These are proposals, nothing is ever perfect on first release, the world is not ending, Google is not showing up at coreboot.org in skimasks and unmarked uniforms ... I think a fork would harm everyone, and would be destructive of our common goals. Please remember that we are all trying to do the right thing, and our different situations give us different perspectives. Nobody is coming in here with bad motives. We're just trying to muddle our way through the many demands of different stakeholders now that coreboot, thanks to the efforts of some pretty dedicated people, has become a runaway success. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] ioapic dump tool
anybody know of a tool to dump all apics/ioapics from user mode? I'm having a Very Stupid Problem with a research OS in that we can't get the apic's and or iopiac's working. I suck at these things. We can't tell what we've got wrong.I'm hoping a register dump would help us. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
On Fri, Mar 21, 2014 at 4:28 PM, ron minnich rminn...@gmail.com wrote: On Fri, Mar 21, 2014 at 1:33 PM, mrnuke mr.nuke...@gmail.com wrote: On Saturday, March 22, 2014 03:56:46 AM Andrew Wu wrote: Yes, that is right. DMP/Vortex86EX has no MTRR. So it maybe a problem if without romcc. :( Is there any way whatsoever to temporarily use the cache as SRAM? when we did the first real CAR work MTRRs were not needed. I'm not sure if they would be on the vortex. We might want to test the very early CAR code and see how it goes. It's actually quite simple. Also, let's just take it a little easy here. These are proposals, nothing is ever perfect on first release, the world is not ending, Google is not showing up at coreboot.org in skimasks and unmarked uniforms ... I think a fork would harm everyone, and would be destructive of our common goals. Please remember that we are all trying to do the right thing, and our different situations give us different perspectives. Nobody is coming in here with bad motives. We're just trying to muddle our way through the many demands of different stakeholders now that coreboot, thanks to the efforts of some pretty dedicated people, has become a runaway success. I've been thinking about it all day and it seems Vladimir is pretty much spot on, The proposition of gatekeepers would essentially kill community effort. Was Stefan's governance change discussed at any level before announcement? Will he discuss it now? Here's to hoping we can work together. I might be able to contribute to that IOAPIC thorn you've got. David -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
On 03/21/2014 05:28 PM, ron minnich wrote: On Fri, Mar 21, 2014 at 1:33 PM, mrnuke mr.nuke...@gmail.com wrote: On Saturday, March 22, 2014 03:56:46 AM Andrew Wu wrote: Yes, that is right. DMP/Vortex86EX has no MTRR. So it maybe a problem if without romcc. :( Is there any way whatsoever to temporarily use the cache as SRAM? when we did the first real CAR work MTRRs were not needed. I'm not sure if they would be on the vortex. We might want to test the very early CAR code and see how it goes. It's actually quite simple. It would be nice to make sure modern hardware uses modern infrastructure. Also, let's just take it a little easy here. These are proposals, nothing is ever perfect on first release, the world is not ending, Google is not showing up at coreboot.org in skimasks and unmarked uniforms ... Damn! I was hoping to steal some ski gear from them. I think a fork would harm everyone Sure, if you stab the person hard enough. and would be destructive of our common goals. Please remember that we are all trying to do the right thing, and our different situations give us different perspectives. When Stefan sounds so serious, it's hard to tell whether he is just proposing, or announcing changes. Remember, he's the guy that can port a new board with his eyes closed [1]. People take him too seriously sometimes. Nobody is coming in here with bad motives. We're just trying to muddle our way through the many demands of different stakeholders now that coreboot, thanks to the efforts of some pretty dedicated people, has become a runaway success. The bad-ness or good-ness of motives is relative. Note that I'm not using bad in the sense of evil. Let's look at the six gatekeeper idea: * Easier for commercial entities to upstream code, therefore faster progress for coreboot (good motive). (a) * Easier for commercial entities to upstream code, therefore we can get lazy even if code quality drops (bad motive). (b) So, in your 15 years of doing this, which option should prevail? Alex [1] http://www.coreboot.org/Coreboot_Developer_Facts -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
On Fri, Mar 21, 2014 at 6:52 PM, Alex G. mr.nuke...@gmail.com wrote: The bad-ness or good-ness of motives is relative. Note that I'm not using bad in the sense of evil. Let's look at the six gatekeeper idea: * Easier for commercial entities to upstream code, therefore faster progress for coreboot (good motive). (a) * Easier for commercial entities to upstream code, therefore we can get lazy even if code quality drops (bad motive). (b) That's not the intent. The way you are stating this has a lot of built-in assumptions, and you're mixing some things up. That's our fault; the old rule is, that if someone did not understand what you said, it's your fault, not theirs. So, speaking as one of the guys who reviewed the email, I'm sorry it was not clearer. So, first, the intent of the six gatekeeper idea is, in part, to be sure we're being very careful about what goes in. We've had some cases over the past 2-3 years where some inexperienced guys pushed 'commit' on code that broke a bunch of boards -- in ways that were not obvious. We would like to avoid that. As we've learned the hard way a few times, there are not that many people who have the perspective of long experience and a view of all the boards, and know how trivial changes can have far-reaching consequences. Now, can this be serious? Yes, very serious. There was a laptop (no names mentioned here, ok?) I know of in which the vendor made a trivial several line change which caused memory corruption on resume. It shipped. The BIOS was baked in; the recovery had to be implemented in the OS. That kind of thing is not fun. But now that coreboot has succeeded in such a big way, trivial changes can have very serious consequences, and we need to be more careful than 15 years ago when it was just us hackers. This is in part why I'm not generally happy with unifying code -- because trivial changes can have unforeseen consequences, and in the past one of the pain points has been well-intentioned code unification ideas that resulted in propagating bugs from one chipset to another. As for easier upstreaming for commerical guys, again, your summary is wide of the mark -- again, not your fault. The review process has gotten a bit tricky, for the simple reason that the same guys that can +2 reviews to the chromeos coreboot repo end up having to do it twice for the upstream. It's a consequence of the fact that the commercial guys have to build coreboot for a product and end up having to develop code they can't upstream immediately. Can we skip the whole discussion of why this is necessary, btw? It is. Coreboot has succeeded. Many people that are authoring coreboot code also work at companies now -- kind of like what's happened with Linux. It's not something we had to deal with 3 years ago. But it makes no sense for, e.g., Duncan Laurie to have to +2 Aaron Durbin's very fine code twice. First off, these two guys have full time jobs (well, 2, really, packed into one, they work hard), they write some of the best code that goes into the repo, and at least from my point of view, a +2 from either of them is usually good enough for me (that also applies to lots of people outside, btw; when I see +1 or +2 from a lot of you folks, I know the review is going to be easier than if I start from nothing. Some of you would be surprised how much I depend on what you write, even when I complain about some of your commit messages :-). Plus, the internal review process on the chromeos coreboot repo is extremely rigorous (and annoying at times). So it's not about Easier for commercial entities to upstream code -- it's about not having to do the full review process *twice*, given that the code has been picked to pieces by experienced long-time coreboot coders, most of whom (no offense intended) are better qualified to review the code than almost anyone else. That's why I claim what you are saying as not quite right. Finally, a simple question here: how many gatekeepers are there for the final full released version of each version of the Linux kernel? My $.02 anyway. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
