GSoC 2013 [flashrom] week #1: while(1);

This week I was busy preparing flashrom for the 0.9.7 release and queue up some overdue patches to be merged shortly after. This includes the infamous layout patches which I need to polish a bit since quite some time has passed since they were created and the surrounding conditions have changed a bit. Not only did flashrom evolve quite a bit (the original version of the layout patches were part of my GSoC 2011 contributions(!)), but I have learned a few tricks in the meantime too, I hope. Progress is rather slow because I am waiting for Carl-Daniel’s input to various issues but there is no response. That’s also the reason why I chose the subject for this blog post ;).

When I stumbled over a discussion in #coreboot about the new AMD SoCs (Kabini et al, preliminary BKDG), I discovered that they apparently contain a new flash interface supporting all kind of neat stuff (e.g. Multi I/O). This would match parts of my GSoC project perfectly and so I made a joke by asking who will send me a board. To my pleasant and big surprise I received a private message a few minutes later and a brand new ASRock IMB-A180-H is currently on the way to me. I want to express my gratitude to Martin Roth from Sage who was so kind to arrange this and Sage and AMD for paying for it. :)

Lately I’ve been looking at libpayload a bit since it will probably play some role in Ky√∂sti’s project in conjunction with libflashrom. So it is also important that I grasp it before I am working on libflashrom. I got (lib)flashrom to compile locally with a slightly patched version of libpayload (patches pushed upstream of course). I hope to get the changes needed in flashrom out before release (NB: I am talking about the current state of libflashrom not about Nico’s patchset). After that I’ll continue to queue up/refine overdue patches – the main focus will be on Nico’s libflashrom.

5 thoughts on “GSoC 2013 [flashrom] week #1: while(1);”

  1. I just wanted to show what changes were needed by Kabini. I don’t think it can be accepted as is. I think a cleaner solution is to create new programmer module since the interface has changed much from sb600. But then we will have some amount of code duplication between the two. Anyway just thinking out loud here. I’m sure you can develop a clean patch independent of mine. Do you still want me to go ahead and submit the patch anyways?

    BTW, are you aware of anyone working on coreboot support for this ASRock board?

  2. oh i certainly dont plan to use it verbatim, but even if i only take a line or two or a comment i would like to give proper credit. also, this is always a good way to lure poor people into my testing trap, so that i can get hold of their email addresses to ask them for help with testing ;) and maybe someone on the mailing list would be interested to use the hack until something better emerges; i am certain that not every subscriber is reading the blog posts.

    from what i have seen (which is very little) i agree that we will probably create a complete new module for it. but you never know… the situation with intel’s hardware sequencing (see my blog post(s) about that) wasn’t so much different and it works great in the merged way… the different sb generations should be more separated too. the differences are way less severe and mostly cosmetic, but still…
    we will see.

    regarding a port of the asrock… i am pretty sure sage will be working on it and i will certainly try too at some point. i always wanted to do coreboot stuff, but i fell for flashrom so that i could only contribute very little to the main project yet. :)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>