Hi Nico,
you seem to be misinformed about the G505s. There is no open-source gfx init for AMD (not in firmware, not in the OS), so within your requirements it's not usable as a laptop
I've had a small discussion with bridgman from AMD (at Phoronix forums) and he told me that VBIOS needed by G505S - aka "gfx init for AMD" - - is "effectively open source" - a byte code which is possible to parse with [AtomDis] open source interpreter
Only problem is that the last update of AtomDis was at 2011 - so, while it should be able to parse 100% of G505S integrated / discrete GPUs AtomBIOSes (because these GPUs were developed before 2011 if I am correct) maybe AtomDis couldn't parse everything for the modern AMD GPUs
Me:
" @bridgman why you don't just open source the complete source code of VBIOS, to let the open source community improve it and fix some bugs? With the help of flashrom open source project, anyone is able to reflash their VBIOS through In-System-Programming. We just don't have the original source code of VBIOS, and the creation of open source VBIOS from scratch is like reinventing the wheel - a huge wheel, which is way too much for unpaid work
Just share the complete source code of VBIOS and let the open source community fix the bugs for you for free! A win-win solution. Why not do it? For the bystanders like me, it gives an impression that either 1) VBIOS source code is a horrible quality, too ashamed to release it to public 2) VBIOS contains some hidden backdoors, hence the need for secrecy 3) AMD is not that friendly to open source community, if instead of sharing what you already got, you want the people to start reinventing the wheel and waste countless of unpaid work hours on it "
brigman:
" It is effectively open source. The data tables are all documented in atombios.h. They are just data structures. The command table parameters are all documented in atombios.h (also just data structures). The command tables are all written in byte code to begin with. The source to the interpreter is open source so you can dump command tables and see exactly what they are doing. You can even write your own command tables in byte code or edit exiting ones if you wanted to. Those are the only things the driver uses from the vbios. The whole point of the data and command tables is to encapsulate board specific configuration details on the actual board itself so that the driver doesn't need explicit knowledge about every board configuration out there.
To summarize:
1. We use an interpreter in VBIOS in order to (a) fit a lot of functionality into a small ROM, (b) give us a degree of CPU independence. My understanding is that this is pretty common practice; either way it's not likely to change unless OEMs buying AMD chips are willing to spend more $$ on the ROM for our hardware than for competitors hardware AND we are willing to go back to having different BIOS code for each of the different CPUs our chips are used with.
2. As agd5f said, the VBIOS source code is bytecode similar to what you get out of the disassembler, although the disassembler output is formatted more neatly. It's not like there is a single master copy of VBIOS source written in C that could be "opened once" - every HW vendor tweaks their BIOS images before production and AFAIK those changes are not ours to publish.
Relatively more of the changes are in data tables than in command tables but both get changed and so we need to use both in the driver if we want driver functionality to correctly match the HW config. There are literally thousands of different HW subsystems, each with their own VBIOS image and hence each with their own slightly different source code... and the associated HW differences DO generally need to be considered when the driver runs.
3. A couple of people have started projects to replace VBIOS with a fully open solution, but my impression is that they all run into the same issues:
- initial implementation is straightforward but ongoing maintenance is a big and boring effort nobody wants to own - you lose CPU independence unless you are willing to maintain AND TEST a lot more different VBIOS builds - without an interpreter the resulting implementation won't fit in the on-card ROM unless you cut back functionality
We make enough information for an open source BIOS replacement available as part of the open source driver effort (data table & command table headers, bytecode interpreter, open source drivers using the tables) although I don't think we support VBIOS re-flashing in general. It is easy to get the same result by over-riding tables in the driver code, however, and I believe there is an existing quirk mechanism.
4. Over time I think you will see a trend away from using AtomBIOS calls simply because ROM size limits the amount of complexity that can be supported in ROM-resident tables while HW complexity is continuing to grow as quickly as ever.
My understanding is that DAL/DC makes somewhat less use of AtomBIOS calls but it also replaces a relatively painless sharing model (drivers for all OSes/platforms make the same AtomBIOS calls for the fiddly HW-specific bits) with a much-harder-to-sell sharing model (drivers for all OSes/platforms share native driver code for the fiddly HW-specific bits).
I understand that this seems unnecessary (and maybe even counter-productive) if you believe that modesetting is trivial, but I don't know how to reconcile your views on modesetting with the views of developers working on the code at different vendors. Once we figure out how to close that gap the rest of the discussion should become easier. "
Best regards, Mike Banon
On Thu, Jan 11, 2018 at 1:05 PM, Nico Huber nico.h@gmx.de wrote:
Hi Taiidan,
On 11.01.2018 03:55, Taiidan@gmx.com wrote:
I am curious of any intel insiders know if there will be microcode updates released for older intel CPU's (ex: sandy/ivybridge) and failing that, what can be done in regards to securing them from meltdown/spectre.
I believe this is a relevant coreboot topic considering how many coreboot boards have these and older CPU's....without a fix there will be only one coreboot compatible laptop with open source hardware initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD CPU) and theoretically owner controllable
you seem to be misinformed about the G505s. There is no open-source gfx init for AMD (not in firmware, not in the OS), so within your require- ments it's not usable as a laptop.
(as the previous C2D/C2Q's such as the X200 are now permanently insecure without intervention from intel apparently)
It depends on the software you run. Please read more about Meltdown and Spectre. When you understood it, you can still start to worry.
At this point even a massive performance loss is better than having to throw out so much now-useless hardware.
Yes? and that can be accomplished without microcode updates, AFAIK.
Nico
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot