Hi everyone,
I will attempt to participate as a student again - and of course my project should be something very closely related to flashrom to exploit my knowledge in that area.
I have already submitted a first alpha-stage proposal that basically includes the standard repertoire of things I do while working on flashrom in general, and also which I ended up doing in the past GSoC projects. Namely a mixture of maintenance, improvement and integration of existing patches, development of new features for flashrom. For me that worked out well and I believe it was very good for flashrom and worthwhile for the coreboot community as a whole too. I have not received too much feedback so I am not sure if everybody agrees with that and thinks that another such summer would be a good thing as well (if there are other candidates and/or proposals to choose from).
If you think the GSoC slots of coreboot deserve something better, or more project-like then I could also try to work on something more confined/focused. There are a number of project ideas that might fit my profile quite well.
The "End user flash tool" proposal would allow me to eventually finish libflashrom and the layout patches, maybe clean up the bios_extract repository and help those users that are fighting with vgabios extractions etc. :)
Then there is the panic room idea which AFAIK is not finished and has some room for improvements, but I am not sure about its current state and if Kyösti wants to work on that this year...?
Somehow related to both points above is an idea for a project I had for some time. A coreboot payload (probably)... for user flash updates that verifies a cryptographically signed image before flashing it. While currently this is relatively useless it might become interesting for distributing libreboot binary images for example. (even though I have to admit it is a bit ironic to ship binary images of a firmware that is blobfree :) IIRC the Chromebooks have a write-protected primary loader that verifies the remaining firmware etc... basically what secure boot demands. That solves a similar problem, but recovery for an end user is way more unpleasant than getting warned early before any modifications are done. Another advantage would be to have an OS-independent update mechanism... OTOH flashrom runs on every OS I deem worthy to run coreboot. :)
The last project idea to be mentioned here that suits me well is what David proposed last year, see his post for details: http://www.flashrom.org/pipermail/flashrom/2013-March/010704.html
So... I would be glad to get your feedback. What do you think would help us most? Do you have other ideas/wishes related to flashrom?
I don't care too much on which project I work... they are all worthwhile IMHO. My preference would be to work freely on flashrom itself because it really needs it (there is no one else doing it) and I have the most knowledge in that field. But OTOH I can learn much more in every other project mentioned above and that's also very motivating. Naturally, I don't want to write multiple proposals if we can agree on one topic already... and time is rather short too :)
PS: I have an asrock imb-180-h, an SPI programmer and lots of flash chips available to tinker with. There is also some ancient intel BX-based PC somewhere that I could port... I'd need to build a parallel flasher for that first though (cortex m3 board and stuff already collecting dust...) but that would probably be based on serprog and peter would veto for sure ;)
Hello again,
since I only got feedback (on IRC) regarding the "end user tool" idea and my preliminary "generic flashrom improvements" proposal, I will try to formulate full proposals for these two projects and we (you) can decide later which one is preferable.
Marc Jones has replied to my GSoC proposals but I really dislike having conversations on the GSoC website and because we will probably need to discuss more than just a few corrections, I'll reply here.
The first proposal is about the end user tool: http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/s...
Marc commented:
What type of flash or coreboot images would you look at working with? I think that the chromebook , Intel FSP and AMD systems have a number of different blob requirements now. Would it be Intel descriptor aware? What about EFI aware?
Thank you for your questions. To be honest, I don't know the answers yet. I hope Patrick finds time to discuss this here with me in the next days/weeks so that I can write a decent specification. In general I want to investigate all possibilities to get a good overview about essential differences in the work flows and formats. That way I can make sure that even if I don't implement them all the code can be extended appropriately later.
I know the Intel layout best so far due to my work on the ich_descriptors_tool (which Stepan did not know about when he started ifdtool), and flashrom's Intel support. Unifying ifdtool and ich_descriptors_tool and making it reusable/"libify" it could be one goal of this project. Basically ifdtool supports basic r/w of Intel images while ich_descriptors_tool is r/o but dumps lots of extra information (softstraps stored in the descriptor region mostly). This is not related to the VGABIOS that is (probably?) still stored somewhere in the BIOS region? The ME and GbE regions are separate and can be copied over easily AFAIK (if they are readable that is :)
As you know I have an Asrock IMB-A180-H. This would be my main test target (for AMD hardware), but I don't know how the AMD flow(s) are regarding blobs. I guess the IMC and USB blobs, and the VGABIOS are relevant, anything else?
For UEFI I would probably rely on https://github.com/NikolajSchlej/UEFITool The author was in #flashrom some while ago but I did not really follow his work.
Regarding chromebooks I am not sure how this tool could help much. For normal builds the blobs are fetched directly from the 3rd party blob repository AFAIK? Of course editing a coreboot image afterwards would also be possible just like for all other boards.
What about chipset-independent ECs?
The second proposal is about general flashrom improvements: http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/s...
Marc had mentioned that he does not like the title before the final proposal was made, and I have only changed it a little since then...
Thanks for this second proposal. I think that a number of these changes would be very useful, but the project title leaves something to be desired. If accepted, I wouldn't want that to be the title Google used when they published the project list.
I do understand that although it sums up the content very well ;) In its current state it is just a bunch of project ideas without anything standing out, which makes finding a good title a bit hard. Would something boring like "Flashrom enhancements" be ok or do you have a better idea?
But apart from the title... I can of course only work on one of the proposals, so I would like to know before further discussions if this one even has a chance of getting selected/what the basic view of the mentors is regarding my projects. Maybe we can save everyone a bit of time by focussing on only one of the two.
On Tue, Mar 25, 2014 at 6:53 PM, Stefan Tauner stefan.tauner@student.tuwien.ac.at wrote:
Marc Jones has replied to my GSoC proposals but I really dislike having conversations on the GSoC website and because we will probably need to discuss more than just a few corrections, I'll reply here.
The first proposal is about the end user tool: http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/s...
Marc commented:
What type of flash or coreboot images would you look at working with? I think that the chromebook , Intel FSP and AMD systems have a number of different blob requirements now. Would it be Intel descriptor aware? What about EFI aware?
Thank you for your questions. To be honest, I don't know the answers yet. I hope Patrick finds time to discuss this here with me in the next days/weeks so that I can write a decent specification. In general I want to investigate all possibilities to get a good overview about essential differences in the work flows and formats. That way I can make sure that even if I don't implement them all the code can be extended appropriately later.
I know the Intel layout best so far due to my work on the ich_descriptors_tool (which Stepan did not know about when he started ifdtool), and flashrom's Intel support. Unifying ifdtool and ich_descriptors_tool and making it reusable/"libify" it could be one goal of this project. Basically ifdtool supports basic r/w of Intel images while ich_descriptors_tool is r/o but dumps lots of extra information (softstraps stored in the descriptor region mostly). This is not related to the VGABIOS that is (probably?) still stored somewhere in the BIOS region? The ME and GbE regions are separate and can be copied over easily AFAIK (if they are readable that is :)
ifdtool/descriptor lib would be great to add as a goal in the application. Thanks for the clarifications. I think that this is an interesting project.
Marc
-
Marc Jones -
Stefan Tauner