A new post titled "[GSOC] Panic Room, week #4/5/6" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/07/21/gsoc-panic-room-week-456/

<h3>What have you been up to these past few weeks?</h3>
<p>My facetious alter ego, I must admit I sinned, I strayed oh so much from my original timeline. (Quite obvious if you read the previous posts)</p>
<p>Since my last post I mainly kept focusing on the region_device API, I attempted to go through with my week #3 plan to continue the phasing out of rdev_mmap_full() from the selfload code (described in previous post).</p>
<p>I think I overestimated what I could accomplish regarding that project, I tried to modify the current lzma API used inside to coreboot to make it possible to easily load each chunk of data from memory/chip and decompress it gradually.<br />
Theoretically it shouldn’t be too difficult, in practice the decompression code is particularly nasty and it seems it is a customised version of the LZMA SDK code.<br />
I, not so quickly, realised that I didn’t have the time to delve into that, so I momentarily dropped the idea. (It could be a nice project to do after the GSOC ends.)</p>
<p>I also spent a chunk of my time in porting the time stamps reading functionality from the cbmem utility into the coreinfo payload (<a href="https://review.coreboot.org/#/c/15600">commit</a>).<br />
It is now possible to read how much time the coreboot boot sequence takes without having a working OS environment.<br />
I needed to measure if there had been any boot time improvements after the rdev_mmap_full commit. (Still haven’t got around to doing that though…)</p>
<h3>What are you working on now then?</h3>
<p>I’m currently working on porting the region_device API from coreboot to libpayload, meanwhile replacing all the functionality that was provided by its predecessor: cbfs_media.</p>
<p>Today I finished (in before my code has to be reworked completely ) replacing the old api inside libpayload and started converting the only payload that used cbfs_media: depthcharge, the payload used to boot ChromeOS.<br />
Hopefully it will be a painless process.</p>
<h3>What’s next?</h3>
<p>So, after I finish these current patch (possibly for the weekend), I need to re-focus my attention on my actual timeline.<br />
I plan to test the current FILO master branch to check for possible problems and show-stoppers before an eventual new release in the (near?) future.<br />
It would be quite helpful in that the current stable is not stable at all, it doesn’t even compile and neither does the master tag (unless you apply this <a href="https://review.coreboot.org/#/c/14952/">patch</a> which is still pending approval).<br />
It would also be the first release that includes the new flashupdate command and would allow for some interesting things to be done (i.e. path to the recovery from a bad coreboot flash/configuration).</p>
<p>Furthermore I would like to get the SerialICE firmware-side code to be merged into the main coreboot codebase (<a href="https://review.coreboot.org/#/c/14504/">commit</a>), so I plan to work out the current problems with the time that I still have at my disposal. (Uh, sounds a bit cliche’ by now)</p>
<p>See you next <del>week</del> time! (Just to be on the safe side <img src="https://s.w.org/images/core/emoji/72x72/1f642.png" alt="🙂" class="wp-smiley" style="height: 1em; max-height: 1em;" /> )</p>
<h3></h3>