coreboot October 2015

coreboot@coreboot.org

44 participants
137 discussions

Re: [coreboot] Asus M2N-E no boot, post codes A5 80 73
by Kyösti Mälkki 29 Oct '15

29 Oct '15

On Thu, Oct 22, 2015 at 5:59 PM, Balázs Vinarz <vinibali1(a)gmail.com> wrote: > Hi. > I compiled from the source about 6 months and now. The mobo is still > unable to boot. > Serial debugs are attached, i tried with many memory-modules in all > sockets. > There are two options, when the postcard jumps between codes A5 and 80: > > <clip> > > PCI: 00:18.0 assign_resources, bus 0 link: 0 > PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] size 0x04000000 g#� > > #END > > Not sure if this is related, but it stops when writing AGP aperture resource. Can you add some more POST codes or debugging in northbridge/amd/amdk8/misc_control.c: set_agp_aperture() ? You could try "iommu=0" on line 52 to disable this resource, to see if you get any further. As for the board, it may have not been tested for several years now. Try to go further back in history, like build from 2012. Wiki notes tell multi-processor was never tested. Regards, Kyösti

1 0

Document for review: coreboot Gerrit Etiquette and Guidelines
by Martin Roth 29 Oct '15

29 Oct '15

As the community has grown, so has the need to formalize some of the guidelines that the community lives by. When the community was small, it was easy to communicate these things just from one person to another. Now, with more people joining the community every day, it seems that it's time to write some of these things down, allowing people to understand our policies immediately instead of making them learn our practices as they make mistakes. As it says in the document: The following rules are the requirements for behavior in the coreboot codebase in gerrit. These have mainly been unwritten rules up to this point, and should be familiar to most users who have been active in coreboot for a period of time. Following these rules will help reduce friction in the community. This has been posted to gerrit for review: http://review.coreboot.org/#/c/12256/ Please post your thoughts and comments either as a reply to this email or in gerrit. Thanks. Martin coreboot Gerrit Etiquette and Guidelines ======================================== The following rules are the requirements for behavior in the coreboot codebase in gerrit. These have mainly been unwritten rules up to this point, and should be familiar to most users who have been active in coreboot for a period of time. Following these rules will help reduce friction in the community. Summary: -------- These are the expectations for committing, reviewing, and submitting code into coreboot git and gerrit. While breaking individual rules may not have immediate consequences, the coreboot leadership may act on repeated or flagrant violations with or without notice. * Don't violate the licenses. * Let non-trivial patches sit in a review state for at least 24 hours before submission. * Try to coordinate with platform maintainers when making changes to platforms. * If you give a patch a -2, you are responsible for giving concrete recommendations for what could be changed to resolve the issue the patch addresses. * Don't modify other people's patches without their consent. * Be respectful to others when commenting. * Each patch should be kept to one logical change. * Don’t submit patches that you know will break other platforms. More detail: ------------ * Don't violate the licenses. If you're submitting code that you didn't write yourself, make sure the license is compatible with the license of the project you're submitting the changes to. If you’re submitting code that you wrote that might be owned by your employer, make sure that your employer is aware and you are authorized to submit the code. See the Developer's Certificate of Origin in the Signed-off-by policy. * Let non-trivial patches sit in a review state for at least 24 hours before submission. Remember that coreboot developers are in timezones all over the world, and everyone should have a chance to contribute. Trivial patches would be things like whitespace changes or spelling fixes. In general, small changes that don’t impact the final binary output. * Do not +2 patches that you authored or own, even for something as trivial as whitespace fixes. When working on your own patches, it’s easy to overlook something like accidentally updating file permissions or git submodule commit IDs. Let someone else review the patch. * Try to coordinate with platform maintainers when making changes to platforms. The platform maintainers are the users who initially pushed the code for that platform, as well as users who have made significant changes to a platform. To find out who maintains a piece of code, please use util/scripts/maintainers.go or refer to the original author of the code in git log. * If you give a patch a -2, you are responsible for giving concrete recommendations for what could be changed to resolve the issue the patch addresses. If you feel strongly that a patch should NEVER be merged, you are responsible for defending your position and listening to other points of view. Giving a -2 and walking away is not acceptable, and may cause your -2 to be removed by the coreboot leadership after a period of time. * Don't modify other people's patches unless you are specifically requested to do so by the owner of that patch. Not only is this considered rude, but your changes could be lost unintentionally when the owner pushes an update without realizing that you’ve changed something. * Be respectful to others when commenting on their patch. Comments should be kept to the code, and should be kept in a polite tone. If you feel attacked, resist the urge to attack back - this only escalates the issue. * Each patch should be kept to one logical change, which should be described in the title of the patch. Unrelated changes should be split out into separate patches. Fixing whitespace on a line you’re editing is reasonable. Fixing whitespace around the code you’re working on should be a separate ‘cleanup’ patch. Larger patches that touch several areas are fine, so long as they are one logical change. Adding new chips and doing code cleanup over wide areas are two examples of this. * Don’t submit code that you know will break other platforms. If your patch affects code that is used by other platforms, it should be compatible with those platforms. While it would be nice to update any other platforms, you must at least provide a path that will allow other platforms to continue working. Recommendations for gerrit activity: ------------------------------------ These guidelines are less strict than the ones listed above. These are more of the “good idea” variety. You are requested to follow the below guidelines, but there will probably be no actual consequences if they’re not followed. That said, following the recommendations below will speed up review of your patches, and make the members of the community do less work. * Test your patches before submitting them to gerrit. It's also appreciated if you add a line to the commit message describing how the patch was tested. This prevents people from having to ask whether and how the patch was tested. An example of this sort of comment would be ‘TEST=Built platform’ or ‘TEST=Built and booted platform’ * Take advantage of the lint tools to make sure your patches don’t contain trivial mistakes. By running ‘make gitconfig’, the lint-stable tools are automatically put in place and will test your patches before they are committed. As a violation of these tools will cause the jenkins build test to fail, it’s to your advantage to test this before pushing to gerrit. * Don't submit patch trains longer than around 20 patches. Long patch trains become unmanageable and tie up the build servers for long periods of time. Rebasing a patch train over and over as you fix earlier patches in the train can hide comments, and make people review the code multiple times to see if anything has changed between revisions. * Run 'make what-jenkins-does' locally on patch trains before submitting. This helps verify that the patch train won’t tie up the jenkins builders for no reason if there are failing patches in the train. * Use a topic when pushing a train of patches. This groups the commits together so people can easily see the connection at the top level of gerrit. Topics can be set for individual patches in gerrit by going into the patch and clicking on the icon next to the topic line. Topics can also be set when you push the patches into gerrit. For example, to push a set of commits with the the i915-kernel-x60 set, use the command: git push origin HEAD:refs/for/master/i915-kernel-x60 * If one of your patches isn't ready to be merged, make sure it's obvious that you don't feel it's ready for merge yet. This can be something like giving it a -1 or -2, or marking in the commit message that it’s not ready until X. The commit message can be updated easily when it’s ready to be pushed. Examples of this are "WIP: title" or "[NEEDS_TEST]: title". These can also be pushed as drafts as shown in the next guideline. * When pushing patches that are not for submission, these should be marked as such. This can be done in the title ‘[DONOTSUBMIT]’, or can be pushed as draft commits, so that only explicitly added reviewers will see them. These sorts of patches are frequently posted as ideas or RFCs for the community to look at. To push a draft, use the command: git push origin HEAD:refs/drafts/master * Respond to anyone who has taken the time to review your patches, even if it's just to say that you disagree. While it may seem annoying to address a request to fix spelling or 'trivial' issues, it’s generally easy to handle in gerrit’s built in editor. It's also acceptable to add fixes for these sorts of comments to another patch, but it's recommended that that patch be pushed to gerrit before the initial patch gets submitted. * Consider breaking up large individual patches into smaller patches grouped by areas. This makes the patches easier to review, but increases the number of patches. The way you want to handle this is a personal decision, as long as each patch is still one logical change. * If you have an interest in a particular area or mainboard, set yourself up as a ‘maintainer’ of that area by adding yourself to the MAINTAINERS file in the coreboot root directory. Eventually, this should automatically add you as a reviewer when an area that you’re listed as a maintainer is changed. * Submit mainboards that you’re working on to the board-status repo. This helps others and shows that these mainboards are currently being maintained. At some point, boards that are not up to date in the board-status repo will probably end up getting deleted from the coreboot tree. * Abandon patches that are no longer useful, or that you don’t intend to keep working on. * Bring attention to patches that you would like reviewed. Add reviewers, or even just rebase it against the current codebase to bring it to the top of the gerrit list. If you’re not sure who would be a good reviewer, look in the MAINTAINERS file or git history of the files that you’ve changed, and add those people. * Familiarize yourself with the commit message guidelines, and try to follow them. This will help to keep annoying requests to fix your commit message to a minimum. * If there have been comments or discussion on a patch, verify that the comments have been addressed before giving a +2. If you feel that a comment is invalid, please respond to that comment instead of just ignoring it. * Be conscientious when reviewing patches. If you give a patch a +2 and it breaks things, you should feel as responsible as the owner of the patch for fixing things, and could be called on by the community to help fix any fallout of the patch. This means you shouldn’t +2 a patch just because you trust the author of a patch - Make sure you understand what the implications of a patch might be, or leave the review to others. Partial reviews, reviewing code style, for example, can be given a +1 instead of a +2. This also applies if you think the patch looks good, but may not have the experience to know if there may be unintended consequences. * If there is still ongoing discussion to a patch, try to wait for a conclusion to the discussion before submitting it to the tree. If you feel that someone is beating a dead horse, maybe just state that and give a time that the patch will be submitted. If no new objections have come up instead of submitting the patch immediately and ending the discussion by force. * When working with patch trains, for minor requests it’s acceptable to create a fix addressing a comment in another patch at the end of the patch train. This minimizes rebases of the patch train while still addressing the request. For major problems where the change doesn’t work as intended or breaks other platforms, the change really needs to go into the original patch. Expectations contributors should have: -------------------------------------- * Don't expect that people will review your patch unless you ask them to. Adding other people as reviewers is the easiest way. Asking for reviews for individual patches in the IRC channel, or by sending a direct request to an individual through your favorite messenger is usually the best way to get a patch reviewed quickly. * Don't expect that your patch will be submitted immediately after getting a +2. As stated previously, non-trivial patches should wait at least 24 hours before being submitted. That said, if you feel that your patch or series of patches has been sitting longer than needed, you can ask for it to be submitted on IRC, or comment that it's ready for submission in the patch. This will move it to the top of the list where it's more likely to be noticed and acted upon. * Reviews are about the code. It's easy to take it personally when someone is criticising your code, but the whole idea is to get better code into our codebase. Again, this also applies in the other direction: review code, criticize code, but don’t make it personal. Requests for clarification and suggestions for updates to these guidelines should be sent to the coreboot mailing list at <coreboot(a)coreboot.org>.

1 0

coreboot binary policy
by Marc Jones 29 Oct '15

29 Oct '15

Hello coreboot, As presented and discussed in Bonn, the binary policy is up for review. http://review.coreboot.org/#/c/12198/ Please limit comments to specific items in this version. If you have additions for the next version (if needed), the draft document is open for comment. https://docs.google.com/document/d/1wMdDUAZR2Z9V7hcs3IhIOqw6sYQxb3vPEmbITTC… Regards, Marc -- http://marcjonesconsulting.com

1 0

Calling all AMD K8 Opteron users!
by Timothy Pearson 29 Oct '15

29 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, I am currently attempting to add a dual-package, dual core Socket F K8 Opteron system to the REACTS automated test system, however it appears that sometime around June / July this year the second CPU package on such systems stopped working. What I see is a hang in ramstage (not romstage) when initializing CPU #3; the hang occurs on the first call to disable_cache() in model_fxx_init(). I have already spent quite a bit of time fixing up portions of the K8 code and am quickly losing motivation to debug this particular issue on these thoroughly obsolete CPUs. The current fallback plan is to enable single-package testing, however this will effectively allow the dual-package bitrot to fester and/or grow much worse as the codebase continues to churn. Would anyone who has access to an appropriate K8-based Socket F Opteron machine be willing to run a bisect to see exactly where this hang was introduced? My last attempt (which failed) was based on GIT hash df5446196cd81c4a714f45f92fb379c795c1edb5, so I assume the fault was introduced in an earlier commit. Thank you! - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) http://www.raptorengineeringinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJWMivtAAoJEK+E3vEXDOFbHwsH/1aWI2/aX0V1q9RcJumc5KXn vRh/Hx6PPemXvWVY2GB8+tq7XJVWDPbNTqNvu2i7Qqxc449rGzJBpsCH2tyxVEqj pa/m0Mxt221Qn6vc3FjzbTeKGG5K/zWY53JidaN77mAzNicdj8UIO5qYwwLB/+HM 2GiKcqB1rVbso5u4NdgZd6eKRNb7TWnMWkplv6Hn1ZJvMGup4FjCXk/jt2+MOGos iWClwOvivSIyI6Lbb9zBjZDPz7u0a5DEMctqkTIIle9efPVVuSClJVlj5mOOMx8k uh/OqSOYkTdXswocBigHoNPvsX4pVG5cs1YnlEoXCz3I57poHCvjTgdTrseSgCs= =KdWK -----END PGP SIGNATURE-----

1 0

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by Peter Stuge 29 Oct '15

29 Oct '15

Patrick Georgi wrote: > branches are where commits are pushed to die. Yes, this is a very important point, and is why I don't support Alex' proposal of moving some things to live only on a branch, and not on master. Branches *can* work really well, but only when there is a person and/or team actively maintaining that branch, and for that to work well, the branch needs to have a fairly clear policy. The best example of this is the Linux kernel. We don't have the manpower of the Linux kernel however. And I don't that you're volunteering to maintain the branch, Alex? I'd like to propose that without a designated maintainer stepping up we don't create branches other than per the release process that we're starting to get into. The AGESA code and older FSP and the other things you list are yes older and less shiny than the new native code, but also more proven. It's not a good idea to sweep older code under a branchy carpet until newer code is generally felt to be equal or better. I don't think that's the case yet, it's just too early. //Peter

3 3

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by Stefan Reinauer 28 Oct '15

28 Oct '15

* Aaron Durbin <adurbin(a)google.com> [151028 14:52]: > > Various improvements and important bug fixes, that will be introduced to a > > master branch and affect all the coreboot boards, will not be automatically > > applied to that separate AMD branch. Those coreboot developers which have > > AMD boards and want to constantly use and test latest and greatest coreboot > > builds, they will have to constantly check the coreboot commit log and > > backport all these improvements and fixes to their separate (and soon to be > > abandoned) AMD branch. That will be adding lots of unnecessary manual work > > and draining lots of workhours, which otherwise could have been spent on > > writing the bug reports or improving a coreboot code which is common for all > > the coreboot-supported boards. > > Those developers should then take a more active role in improving the > code that is applicable to them. As it stands now, I don't see any > work going in improving those code bases. And there I am, waiting for people to review my AMD64 cleanup patches since July ;-) hint hint. Stefan

1 0

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by ron minnich 28 Oct '15

28 Oct '15

IIRC I did the IBM e325/6 back in the day and I'm happy to see it die. ron On Wed, Oct 28, 2015 at 8:49 AM Martin Roth <gaumless(a)gmail.com> wrote: > It seems that we've got more issues than we can address before the > proposed 4.2 release date within the next few days - we're trying to > get this out in October. > > Maybe it's time for another 'Major' release where we can remove more > than just the few mainboards and truly obsolete code that I was > thinking of when I started this conversation. > > Is there anyone against removal of any of these boards/chipsets after > the 4.2 release, or should we wait for a decision about handling all > of the current issues before we delete anything? > > mainboard/via/epia-m700 - http://review.coreboot.org/#/c/7470 > northbridge/via/vx800 - http://review.coreboot.org/#/c/7471 > * arima/hdama - CPU: _AMD_SOCKET_940 NB: AMDK8, SB: AMD8111, SB: AMD8131 > * digitallogic/adl855pc - CPU: INTEL_SOCKET_MPGA479M, NB: INTEL_I855, > SB: INTEL_I82801DX > * ibm/e325 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131 > * ibm/e326 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131 > * iwill/dk8s2 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131 > * iwill/dk8x - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131 > * newisys/khepri - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: > AMD8131 > * tyan/s2735 - CPU: INTEL_SOCKET_MPGA604, NB: INTEL_E7501, SB: > INTEL_I82870, SB: INTEL_I82801EX > * tyan/s2850 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111 > * tyan/s2875 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8151 > * tyan/s2880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131 > * tyan/s2881 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131 > * tyan/s2882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131 > * tyan/s2885 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: > AMD8131, SB: AMD8151 > * tyan/s2891 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: > AMD8131 > * tyan/s2892 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: > AMD8131 > * tyan/s2895 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: > AMD8131 > * tyan/s4880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131 > * tyan/s4882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131 > > > I'd vote against the removal of any of the AGESA codebases for this > release with the possible exception of the Family 12 codebase. It's > only used in the torpedo mainboard, and even that's not well > supported. > I'd vote against the removal of any of the Intel FSP codebases for > this release. They are recent, and they are definitely still being > used. Even Rangeley. Yes, they have their issues. > > I could support moving platforms off to the 4.X branch if we decide to > create a 5.0 branch to move forward and get things cleaned up. Still, > having dealt with several different forks of the coreboot code, my > opinion is that branching is basically going to end the support for > these platforms. Of course the people that don't use those platforms > don't care whether coreboot is killed off for those platforms, so I'd > ask that these platforms that we're choosing to die be picked > carefully. > > > > On Wed, Oct 28, 2015 at 8:30 AM, Aaron Durbin <adurbin(a)google.com> wrote: > > On Wed, Oct 28, 2015 at 9:15 AM, Patrick Georgi <pgeorgi(a)google.com> > wrote: > >> 2015-10-28 14:50 GMT+01:00 Aaron Durbin <adurbin(a)google.com>: > >>> That presupposes there is work going on in those branches that is > >>> desired to be pushed back into another branch. Anyone can very much > >>> port forward something if they so choose. That's the point of the > >>> branching mechanism. > >>> > >>> What is your proposal for dealing w/ inconvenience? I haven't seen a > >>> modicum of change in that area. In fact, what we have seen is more > >>> boards being added that use the constructs that are inconvenient. > >> For one: when things are considered too inconvenient (and used and > >> maintained) to be practical to keep around, remove them. For real. > >> Claiming that we can stuff them "in branches" is a cop-out, because > >> they're still dead. > >> > >> That's also why I proposed to go with tags for releases: When people > >> are motivated enough to dig out the old stuff and make it work again, > >> there should be some incentive to bring them up to current standards. > >> Then they can get back into master. > >> If somebody is spearheading such an effort and provides test > >> resources, I think there's even some willingness to help with some of > >> the more mechanical tasks - like cleaning out #include "file.c" stuff, > >> but the motivation is rather hard to get by when it's unclear if the > >> code is ever used again. > > > > Where is that motivation now? There is no one providing the resources > > so the answer is status quo which in turn means an insanely daunting > > task in trying to clean up things that just so happen to touch 90% of > > the mainboards because of the existing code flow/design. Without the > > resources nothing can be done which means accumulation of cruft and no > > idea if anyone uses anything. What's the end game there? > > > > Maybe it doesn't matter because all the work required has been > > completed going forward so one can just keep cranking out boards, but > > I suspect that is not the case. And when another requirement surfaces > > that no one was anticipating do we add yet another API/subset on how > > to do things? Where's the common base to work against? > > > >> > >> People can still take any old commit (tagged, branched, or not) and do > >> their own thing on github - however I think we're setting standards by > >> what we do. Opening branches encourages to keep basing work on them, > >> instead of considering snapshots to be just that. > > > > What are the standards we're setting? > > > >> > >> My main objection to dropping things was that the motivation by the > >> proponents always looked very similar to "this is inconvenient to me > >> right now, let's get rid of this". > >> If we were consequential in following up every such sentiment by > >> everyone, we'd probably ship a single file, COPYING. > > > > I think you're taking such a notion to the extreme. Probably the > > superset of opinion may be that, but I don't think that's practical > > nor helpful in this discussion. I've cited very specific things that I > > have run into within my development, and I don't see a solution aside > > from "tred lightly, hold your nose, and hope for the best". I'd be > > happy to help support said improvement work, but there's no path for > > such things, and the carrot of getting back into the sacred master > > branch is apparently unpalatable for people. > > > > From my vantage point it seems people want the playground they grew up > > with and knew and loved. Therefore, don't ever change my playground. > > > >> > >> > >> Patrick > >> -- > >> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > >> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > >> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > http://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by Martin Roth 28 Oct '15

28 Oct '15

It seems that we've got more issues than we can address before the proposed 4.2 release date within the next few days - we're trying to get this out in October. Maybe it's time for another 'Major' release where we can remove more than just the few mainboards and truly obsolete code that I was thinking of when I started this conversation. Is there anyone against removal of any of these boards/chipsets after the 4.2 release, or should we wait for a decision about handling all of the current issues before we delete anything? mainboard/via/epia-m700 - http://review.coreboot.org/#/c/7470 northbridge/via/vx800 - http://review.coreboot.org/#/c/7471 * arima/hdama - CPU: _AMD_SOCKET_940 NB: AMDK8, SB: AMD8111, SB: AMD8131 * digitallogic/adl855pc - CPU: INTEL_SOCKET_MPGA479M, NB: INTEL_I855, SB: INTEL_I82801DX * ibm/e325 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131 * ibm/e326 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131 * iwill/dk8s2 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131 * iwill/dk8x - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131 * newisys/khepri - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131 * tyan/s2735 - CPU: INTEL_SOCKET_MPGA604, NB: INTEL_E7501, SB: INTEL_I82870, SB: INTEL_I82801EX * tyan/s2850 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111 * tyan/s2875 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8151 * tyan/s2880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131 * tyan/s2881 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131 * tyan/s2882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131 * tyan/s2885 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131, SB: AMD8151 * tyan/s2891 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131 * tyan/s2892 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131 * tyan/s2895 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131 * tyan/s4880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131 * tyan/s4882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131 I'd vote against the removal of any of the AGESA codebases for this release with the possible exception of the Family 12 codebase. It's only used in the torpedo mainboard, and even that's not well supported. I'd vote against the removal of any of the Intel FSP codebases for this release. They are recent, and they are definitely still being used. Even Rangeley. Yes, they have their issues. I could support moving platforms off to the 4.X branch if we decide to create a 5.0 branch to move forward and get things cleaned up. Still, having dealt with several different forks of the coreboot code, my opinion is that branching is basically going to end the support for these platforms. Of course the people that don't use those platforms don't care whether coreboot is killed off for those platforms, so I'd ask that these platforms that we're choosing to die be picked carefully. On Wed, Oct 28, 2015 at 8:30 AM, Aaron Durbin <adurbin(a)google.com> wrote: > On Wed, Oct 28, 2015 at 9:15 AM, Patrick Georgi <pgeorgi(a)google.com> wrote: >> 2015-10-28 14:50 GMT+01:00 Aaron Durbin <adurbin(a)google.com>: >>> That presupposes there is work going on in those branches that is >>> desired to be pushed back into another branch. Anyone can very much >>> port forward something if they so choose. That's the point of the >>> branching mechanism. >>> >>> What is your proposal for dealing w/ inconvenience? I haven't seen a >>> modicum of change in that area. In fact, what we have seen is more >>> boards being added that use the constructs that are inconvenient. >> For one: when things are considered too inconvenient (and used and >> maintained) to be practical to keep around, remove them. For real. >> Claiming that we can stuff them "in branches" is a cop-out, because >> they're still dead. >> >> That's also why I proposed to go with tags for releases: When people >> are motivated enough to dig out the old stuff and make it work again, >> there should be some incentive to bring them up to current standards. >> Then they can get back into master. >> If somebody is spearheading such an effort and provides test >> resources, I think there's even some willingness to help with some of >> the more mechanical tasks - like cleaning out #include "file.c" stuff, >> but the motivation is rather hard to get by when it's unclear if the >> code is ever used again. > > Where is that motivation now? There is no one providing the resources > so the answer is status quo which in turn means an insanely daunting > task in trying to clean up things that just so happen to touch 90% of > the mainboards because of the existing code flow/design. Without the > resources nothing can be done which means accumulation of cruft and no > idea if anyone uses anything. What's the end game there? > > Maybe it doesn't matter because all the work required has been > completed going forward so one can just keep cranking out boards, but > I suspect that is not the case. And when another requirement surfaces > that no one was anticipating do we add yet another API/subset on how > to do things? Where's the common base to work against? > >> >> People can still take any old commit (tagged, branched, or not) and do >> their own thing on github - however I think we're setting standards by >> what we do. Opening branches encourages to keep basing work on them, >> instead of considering snapshots to be just that. > > What are the standards we're setting? > >> >> My main objection to dropping things was that the motivation by the >> proponents always looked very similar to "this is inconvenient to me >> right now, let's get rid of this". >> If we were consequential in following up every such sentiment by >> everyone, we'd probably ship a single file, COPYING. > > I think you're taking such a notion to the extreme. Probably the > superset of opinion may be that, but I don't think that's practical > nor helpful in this discussion. I've cited very specific things that I > have run into within my development, and I don't see a solution aside > from "tred lightly, hold your nose, and hope for the best". I'd be > happy to help support said improvement work, but there's no path for > such things, and the carrot of getting back into the sacred master > branch is apparently unpalatable for people. > > From my vantage point it seems people want the playground they grew up > with and knew and loved. Therefore, don't ever change my playground. > >> >> >> Patrick >> -- >> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg >> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg >> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by Aaron Durbin 28 Oct '15

28 Oct '15

On Wed, Oct 28, 2015 at 9:15 AM, Patrick Georgi <pgeorgi(a)google.com> wrote: > 2015-10-28 14:50 GMT+01:00 Aaron Durbin <adurbin(a)google.com>: >> That presupposes there is work going on in those branches that is >> desired to be pushed back into another branch. Anyone can very much >> port forward something if they so choose. That's the point of the >> branching mechanism. >> >> What is your proposal for dealing w/ inconvenience? I haven't seen a >> modicum of change in that area. In fact, what we have seen is more >> boards being added that use the constructs that are inconvenient. > For one: when things are considered too inconvenient (and used and > maintained) to be practical to keep around, remove them. For real. > Claiming that we can stuff them "in branches" is a cop-out, because > they're still dead. > > That's also why I proposed to go with tags for releases: When people > are motivated enough to dig out the old stuff and make it work again, > there should be some incentive to bring them up to current standards. > Then they can get back into master. > If somebody is spearheading such an effort and provides test > resources, I think there's even some willingness to help with some of > the more mechanical tasks - like cleaning out #include "file.c" stuff, > but the motivation is rather hard to get by when it's unclear if the > code is ever used again. Where is that motivation now? There is no one providing the resources so the answer is status quo which in turn means an insanely daunting task in trying to clean up things that just so happen to touch 90% of the mainboards because of the existing code flow/design. Without the resources nothing can be done which means accumulation of cruft and no idea if anyone uses anything. What's the end game there? Maybe it doesn't matter because all the work required has been completed going forward so one can just keep cranking out boards, but I suspect that is not the case. And when another requirement surfaces that no one was anticipating do we add yet another API/subset on how to do things? Where's the common base to work against? > > People can still take any old commit (tagged, branched, or not) and do > their own thing on github - however I think we're setting standards by > what we do. Opening branches encourages to keep basing work on them, > instead of considering snapshots to be just that. What are the standards we're setting? > > My main objection to dropping things was that the motivation by the > proponents always looked very similar to "this is inconvenient to me > right now, let's get rid of this". > If we were consequential in following up every such sentiment by > everyone, we'd probably ship a single file, COPYING. I think you're taking such a notion to the extreme. Probably the superset of opinion may be that, but I don't think that's practical nor helpful in this discussion. I've cited very specific things that I have run into within my development, and I don't see a solution aside from "tred lightly, hold your nose, and hope for the best". I'd be happy to help support said improvement work, but there's no path for such things, and the carrot of getting back into the sacred master branch is apparently unpalatable for people. >From my vantage point it seems people want the playground they grew up with and knew and loved. Therefore, don't ever change my playground. > > > Patrick > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg > Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

1 0

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by Patrick Georgi 28 Oct '15

28 Oct '15

2015-10-28 14:50 GMT+01:00 Aaron Durbin <adurbin(a)google.com>: > That presupposes there is work going on in those branches that is > desired to be pushed back into another branch. Anyone can very much > port forward something if they so choose. That's the point of the > branching mechanism. > > What is your proposal for dealing w/ inconvenience? I haven't seen a > modicum of change in that area. In fact, what we have seen is more > boards being added that use the constructs that are inconvenient. For one: when things are considered too inconvenient (and used and maintained) to be practical to keep around, remove them. For real. Claiming that we can stuff them "in branches" is a cop-out, because they're still dead. That's also why I proposed to go with tags for releases: When people are motivated enough to dig out the old stuff and make it work again, there should be some incentive to bring them up to current standards. Then they can get back into master. If somebody is spearheading such an effort and provides test resources, I think there's even some willingness to help with some of the more mechanical tasks - like cleaning out #include "file.c" stuff, but the motivation is rather hard to get by when it's unclear if the code is ever used again. People can still take any old commit (tagged, branched, or not) and do their own thing on github - however I think we're setting standards by what we do. Opening branches encourages to keep basing work on them, instead of considering snapshots to be just that. My main objection to dropping things was that the motivation by the proponents always looked very similar to "this is inconvenient to me right now, let's get rid of this". If we were consequential in following up every such sentiment by everyone, we'd probably ship a single file, COPYING. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

1 0

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2015