GSoC

Google Summer of Code

GSoC: Spice Payload report

3
182 days
by in GSoC

Yeah! it`s came the time to write another report on GSoC status. In fact I`ve – intentionally – postponed it for quite some time and it doesn`t exactly mean there was a lack of informative emails between me and Marc(my mentor).

The need to finish some stuffs justifies – in some ways – the aforementioned delay. I understand you don`t need to report you aren`t done with something, a mail stating “I`m not done yet” would be enough - well, maybe not anyway…

OpenEmbedded Journey

With the second half of my project I jumped in the OpenEmbedded ecosystem and believe it, I`ve loved to get in touch with.

Putting my hands on OE is something I`ve planned for some time, I just hadn`t had the time to do so.

OpenEmbedded is something amazing, and it does what I realized years ago when I worked with gentoo. I always saw gentoo as a great meta-distribution, something you can bend and forge as you need – customizing it according to your needs.

Despite all the conceptual things touching OE wasn`t as easy as I initially tought it would. Bitbake(the great maestro behind OE) was designed with portage in mind and theoretically it was I good advantaged to me – look, theoretically.

Nothing is exactly smooth as you plan, you`ll always get troubles in the way – with OE wasn`t an exception.

OE transitions and yocto project

One of the biggest problems I faced was mainly due the transition the OE project is getting through. The docs(Getting started wiki page for example) are out dated and you get conducted by the old code base, and trust me, it`s not a good way to get started.

My first two weeks was full of crazy hacks, searching for old tarballs, setting up local source repositories, doing everything I could to make that thing to work – it was a bad race doing my best to proof the howtos.

The true is OpenEnbedded has moved to what we name bblayer, it`s a bitbake feature to ease to extend a base system. The intention(as I see) is to keep a minimal, clean and stable set of core packages and yet make it possible to “third party” vendors to append it to fit their needs.

The yocto project has extensively used OpenEmbedded as their base system, both the projects have exchanged a lot and sometimes you loose yourself if you`re touching one or the other. One of the tools provided by yocto project is Poky – which`s actually an OE layer.

There isn`t plenty of docs describing how the bblayer and bbappend work – the bitbake docs aren`t much precise and the OpenEmbedded barely mention it, yocto just describes how it`s fit within poky(or something close to that).

I would really like to recommend newcomers to first play with poky then later consider starting a new third-party layer.

The project as a bblayer

A third party layer is what best fits my project, not exactly a full yocto/poky layer, maybe and extension of it or not even that but an own layer itself, to accomplish that I had to experiment a lot, setting the environment up and watching how everything get together.

Packaging

After many years not touching a single ebuild and having never touched a bb package I jumped in the task to pack some components. The spice client has a bunch of dependencies – of course, I hadn`t to pack everything myself, a great number of things were already done.

Among the things that got me longer then I expected was cyrus-sasl, the old OE tree had it packaged but it was an old version – should I mention it was broken as well?

So, bringing the recipes wouldn`t be enough but I would have to fix things up, once fixing stuffs was the only alternative I decided to upgrade it to the latest version 2.1.31.

Anyway, it brought me a lot of work to pick patches to fix its building and fixing what hadn`t got fixed already. My final PR was 177 what means I came through 177 builds, debugging, testing and working everything around.

The cyrus-sasl code has a bug introduced after 2.1.21, it wasn`t possible to build it –with-static. I did an ugly and ridiculous fix. Everything I found out there – searching the internet – was even uglier. Suggestions to run make twice was one of them. The build system was kind of messed up.

The other packages weren`t so painful and I could quickly move forward.

Slimming the image

I still have to slim few things, I need to cut some X11 packages I included in the image, append the yocto kernel with my own .config and write a small shell script(or something smarter than that) to launch the spice client.

BuildRom

The first thing I worked on in the beginning of my project was buildRom, I wanted to bring all the tasks involved on building the OS image and bios/firmware into to it. But, with my move to OE for building the OS image I realized I could go the reversed way and bring the tasks for building the bios/firmware to OE.

Now I`ve manually packaged the things but have already started to write bbclass to controll bios/firmware + image building and packaging them. I see it as a second generation to BuildRom project, a OE layer with coreboot bb packages and recipes plus the needed bb classes.

Conclusion

After the great effort I had, getting in touch by the first time with OE, I feel comfortable to say it was a good experience to me, I realized many possibilities. I`m really happy with everything I learned on the path and I`m sure I still have a lot to contribute to Coreboot and OE as well.

GSoC 2011: flashrom part 5 – Dear Intel

1
189 days
by in Business, flashrom, GSoC

As mentioned in my GSoC recap, Carl-Daniel and i have sent a letter to Intel to get more information regarding the descriptor section and unlocking the ME flash protection (my official GSoC main project). It was sent about 3 weeks ago (2011-07-29). No reply was received so far. This is the whole message we have sent them: (more…)

GSoC 2011: flashrom part 4 – recap

2
194 days
by in flashrom, GSoC

Final evaluation deadline for this year’s GSoC is in 2 weeks. Most of what i have written in my midterm evaluation is still valid.

We have formulated and sent an email to various Intel representatives in the hope to get at least a few hints regarding ME unlocking (and descriptor semantics). I had the idea to send them a mail earlier, but thought it is an ludicrous attempt from all i have gathered regarding Intel’s cooperation with coreboot. Carl-Daniel suggested giving it a go anyway and it provided me a good excuse to not work on REing until we get an answer. Of course we have not received any reply to date :(

So i think it is quite clear that my main GSoC project will fail to be delivered on time. But i won’t vanish after GSoC and i still plan to implement ME unlocking eventually.

What’s up besides the GSoC project?

The integration of my patches still lacks reviewing power. Everyone but Carl-Daniel seems to be not much interested in my work and he has not the time to look at everything i produce. Right now flashrom has about 150 patches requiring some action to merge them. Thereof are 41 from me (TBH there is a number of patches that are just rebased and improved a little bit) and 37 from Carl-Daniel. meh.

With the help of Florian ‘florz’ Zumbiehl i was also able to find, fix and report a bug in dmidecode which has direct influence on flashrom. Due to an error in decoding the chassis type in dmidecode, flashrom falsely declares some boards to be mobile devices, which makes it shout a big warning at the user unnecessarily.

I’ve been also working on rebasing, improving and reviewing (very) old patches of others whose discussions just stopped (for example when contributors did not send improvements). My hope is that this will help us shorting the long patch queue, but i doubt that it will suffice ;)

To conclude (or begin) my recap of my GSoC involvement this year, i’d like to first thank google for doing this. This sounds quite pathetic, especially if one knows me better. But it really got me involved in FOSS development with the intensity i wished for (by providing a monetary motivation to get really started). There was some involvement in the past (bug reports and fixes etc.), but flashrom was apparently a nice target to get more involved and learn a lot, not so much about REing and technical details (as i expected and hoped in the beginning), but regarding project management in FOSS (my own proposal, but also flashrom and its patch queue/processing and “upper management’s” free time constraints), interacting with contributers and users, and mastering git (the latter is quite ironical because flashrom does not use it (yet)). It’s a bit sad, that flashrom does not have more contributers (especially reviewers). This is obviously a problem and it might be the time to discuss the development process as a whole. The question is with whom should i discuss this if no one is there :)

Although my formal project will not be finished on time, i think i have served the flashrom project well and from the feedback i received so far, Carl-Daniel is also happy with my work. So i think i can declare it as successful after all and i would like to thank everyone involved (so far).

GSoC2011(Week 9): boot ARM using coreboot to romstage

0
217 days
by in ARM, coreboot, GSoC

Hi all. Here I come again. With one week’s work, coreboot now can add romstage to the romfile, pass control to the romstage and find ramstage. I add a new way using a binary file to add stage to a rom file. Since I have not got an idea of how to store the hardware information, no hardware initialization is done now except the console. Following I will show you some snapshots:
This is a romfile without ramstage so it hangs at finding it:

This is a romfile with a simple ramstage. The ramstage code only sends a string “Hello ARM!” to the console then hangs there. It is compressed using LZMA in the romfile and should be decompressed and copied to the RAM at address 0×5000. This romfile is for testing the decompress function and move-jump function.

Next week, I will work on the ramstage. It is one of the hardest parts since we will deal with the hardware information. I need to design it and implement it. I want my code to be tested and reviewed early for that it is not only about implementation but also design. One could change an implementation with a low cost but couldn’t change a design with a low cost.
Thanks to God and Thanks to all the coreboot developers. Working with you all is so happy and fantastic!

GSoC 2011: flashrom part 3 – Midterm Evaluation

1
222 days
by in flashrom, GSoC

in schools essays that stray away from topic are often graded strictly. if one applies similar principles to my gsoc work it would probably degrade to “satisfactory” or worse. when i submitted my application for gsoc, most of my time line consisted of reverse engineering tasks. the plan was to quickly implement hardware sequencing and start reversing some vendor tools to find out how they unlock the ME.

what really happened is something i think is at least as useful as working ME unlocking code: flashrom got an almost full-time maintainer. ;)
i am handling a big chunk of the daily work (support requests on the mailing list and on IRC, keeping our database of tested devices up to date etc.) and i try to fix all problems in flashrom that i become aware of. this has led to countless already accepted patches and many which are still not reviewed yet. (more…)

GSoC 2011: midterm report under panic

0
223 days
by in coreboot, debugging, embedded, FILO, firmware, flashrom, GSoC, SeaBIOS, USB

Well my progress is not so shiny as other students. Looks like I overestimated my capabilities in my project proposal. I ended up with long exam session, lurking by reading coreboot mailing list (like an old cow), reading stuff about computer architecture, making hardware tools and trying to understand how git works :)

Done some patches, unfortunately, nobody likes it :)

Temporary libpayload fixes for flashrom as a payload

Flashrom as a payload with usb flash drive support

SerialICE for coreboot

Triggering another payload

For the second half of GSoC:

I’m working on “carFlashrom” (Yep, sounds a bit french) project:

http://www.coreboot.org/pipermail/coreboot/2011-July/065902.html

If this project is possible, then flashing would be possible without working RAM.

I would like to receive some response to my mails in the list as I am confused with my project goals, what others do think? I need some alternative goal if this is not feasible.

Give me some thoughts.

 

Bonus for readers: this one might be used with flashrom as rayer_spi. Modify flashrom source according to pinout and bits of par port registers:

http://logix4u.net/Legacy_Ports/Parallel_Port/A_tutorial_on_Parallel_port_Interfacing.html

I used m74hc244 from ST, even though parport signals are 5V, the chip is working right with VCC 3.3V.

http://dev.frozeneskimo.com/resources/jtag_wiggler_clone

GSoC2011: midterm report

0
223 days
by in ARM, coreboot, GSoC

Hi all. Welcome to my midterm report for project “porting coreboot to ARM”.

Summary

The goal of this project is porting coreboot to ARM and taking advantage of coreboot’s strength in properly configuring PCI, SAS, SATA and SCSI devices; fast boot times; and payload support.

For ARM SOCs, the device configuring is much easier than that for X86. Most device controllers are connected through the on-chip bus. So the mainly work is focus on porting the basic layout and helping tools to ARM architecture, including CBFS, cbfstool and the codes helping loading next stage and payload into ram.

Changes to this project

At first, I want to work on Marvell ARM SOCs with PCIE support, but after checking into it, I found that mostly all the information and SDK of Marvell SOCs are covered under an NDA license. So I moved to VersatilePB from Armltd.

What works now

  • CBFS record the architecture information in the master header
  • cbfstool can detect the architecture of a rom file
  • cbfstool can create an ARM rom file with bootblock
  • bootblock for VersatilePB is ready for use
  • romstage code for VersatilePB has been written

What doesn’t work (yet)

  • cbfstool can not add-stage to the romfile due to a problem in prase_elf_to_stage
  • romstage for VersatilePB has not been tested
  • ramstage code for VersatilePB has not been written

What needs work

  • design the information struct of hardware for payload on ARM

In this week, I will try to fix the problem of add-stage on ARM and test the romstage code.
Got any feature suggestions/ideas ?

Screenshot-QEMU-flashrom

GSoC 2011: flashrom + filo = ?

0
236 days
by in coreboot, FILO, flashrom, GSoC, USB

 

The answer is flashrom payload, which is capable flashing roms out of usb stick. If you use seabios, you will be able to choose to run this payload instead of booting os. It might be worth for payload developers if we would have a small payload for selecting other payloads out of CBFS :)

Patches are here. Sorry for weird stuff there :)

 

My GSOC project is not going well, I end up with problems almost everywhere :( (Only the good thing is that my exams went well). I spend my time trying to understand what is going on. Yesterday I was running an overflowing code allmost all day, until I found out what is wrong… My E350M1 is still not working (coreboot doesn’t run with 512 kB chip). So I have ordered some chips from ebay. While I’m waiting I have made some PCB adapters to make a dual flash device. Also made additional PCB for RS232<->UART<->USB interface.

I would better go coding… Bye!

GSoC2011(Week 5): the layout of coreboot rom and cbfstool for ARM

1
243 days
by in ARM, coreboot, GSoC

Hi all. How time flies. It has been 4 weeks since my last post. During this month, I have finished the design and implement of bootblock, Rom structure and cbfstool for ARM. Following I will show my changes to you all.
(more…)

GSoC 2011: flashrom part 2 – SFDP

0
243 days
by in flashrom, GSoC

SFDP (Serial Flash Discoverable Parameters) is a JEDEC standard for querying the capabilities of serial flash chips. This allows software like flashrom to support chips without having all properties hard-coded beforehand. SFDP is structured in tables which are laid out in their own linear address space (independent from the “normal” range used to access the stored data). Starting at address 0×0 a mandatory header begins with a signature 0×50444653 (or ‘S’, ‘F’, ‘D’, ‘P’ in ASCII) followed by versioning data and the number of parameter headers. These headers are 64b long and have fields for versioning data, identification, length and offset where the real stuff i.e. the parameter table resides. There is one mandatory table and up to 255 can be added optionally. In the current version of the standard (2011-04) only the mandatory table is defined, but vendors are free (and quite encouraged by the standard) to add their customized tables and from the few data sheets i have seen mentioning SFDP the vendors do that (see below).

I spare you from the nasty details, but keep in mind that the mandatory table allows to retrieve the following properties:

  • the total size of the device
  • 4 (unified) block erasers (size of erase blocks and associated opcode)
  • address mode (24b, 32b or both)
  • status register write enable (none, WREN or EWSR)
  • lots of fast read-related stuff (like modes supported and number of wait states/dummy cycles needed in each)

The good news is: this would be enough to allow flashrom to work with unknown (yet unreleased) chips without recompilation!

The even better news is: i have a patch for that ;)

The bad news: i am not sure if there exists any hardware that supports it yet. (more…)

Next »
Go to Top