> Arthur proposed making a number of features mandatory so that the bootflow > becomes more > predictable across chipsets and boards. Mandatory features imply that > chipsets or boards that > can't comply to these new requirements for whatever reason will be dropped. > There was no > decision yet whether to make anything mandatory, and on what schedule and > with what effect. Sure, this is exactly the way I got it. I just wanted to depict my point of view without being afraid that this will happen in the very near future.
> So maybe people like you and Jay want to register yourselves as reviewers to > fsp_baytrail and > fsp_broadwell_de, so you'll notice changes early and can test and comment on > them? Yes, this is a really nice feature. Thank you for implementing it into gerrit Patrick! I will add myself as reviewer for both platforms. > So if we were to review changes to make these fsp 1.0 boards "somehow" > postcar-capable, > you'd notice shortly after we checked them in if that broke anything? Yes that is exactly what would happen. I got a few catches in the past already with that setup. In the first glance I wanted to test even unmerged patches from gerrit but realized very soon that my system will not be able to handle this amount. So for now I trigger the test setup every 4 hours for a complete test which includes mc_tcu3, mc_bdx1 and since September even mc_apl1. >Is publicly reporting which commits on master work on your boards something >you could do, > or is that off-limits for some operational reason? Yes, I have that in mind for some time already. I simply hadn't the time yet to think about a way on how to feed back this test results in detail. Though it should be possible. If you have an idea of how we can reasonable feed back this test results let me know. I can think about implementing it in the spare time (once I will get some). Werner -- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
