GSoC (coreboot): Test interface board complete

Apologies for the late update. The design that I posted in the last post was more challenging than I had thought. However I’m happy to announce that my test hardware that I call ‘coreboot test interface board’ (TIB) is now complete. Only some of the software interface part is remaining in the project. So let me share with you a very quick update of last month. Continue reading GSoC (coreboot): Test interface board complete

GSoC (coreboot): Week 5-7 – Redesigning the test-interface-board

In the last blog post I talked about the test-interface-board. There were some concerns about the use of FT232H chip and extra features like voltage and temperature measurement were not required. Keeping in view all the suggestions and improving things on my side I have redesigned the board.

w567fig1

The figure above shows only one target board connected to the test supervision for simplicity. The purple L-block is the test-interface-board. This time, instead of using an integrated flasher I wish to support all existing flashers so I have developed an ICP adapter. An In-Circuit Programming (ICP) adapter contains the firmware flash memory removed from the motherboard and it acts as an electronic change-over switch that connects this flash memory to the motherboard or the programmer as required. It also includes logic-level translation to support as many as possible combinations of programmers and motherboards. The support for programmer voltage is in range 1.2V-5.5V and for motherboard SPI voltage it’s in range 1.65V-3.3V.

As a quick test for VGA initialization I’ve added video detection for Analog video (VGA), DVI and HDMI ports. This checks presence of signals that are only there when video is active. In other words, it checks whether a monitor’s status led would turn green if it’s plugged to the motherboard without actually plugging one. I have prepared schematics, some parts of which are yet to be validated through prototyping. This will all be implemented as an Arduino add-on board (aka Shield) for convenience and the Arduino would act as the controller.

The Serial and Ethernet ports can be connected in the usual way using Serial-to-USB cables, Ethernet cables and hubs. Continue reading GSoC (coreboot): Week 5-7 – Redesigning the test-interface-board

GSoC (coreboot): Week 3 and 4

In the past two weeks I was on vacation and I have been working on what I call “test interface board”. Before I go on to elaborate this I feel there’s a need to discuss the big picture of this project because a lot of things have changed for good reasons and the old terminologies don’t make sense.

System Topology

Just to remind, my project is centered on building inexpensive and flexible test-rig for the Automated Distributed Firmware Test System described in Quality Assurance Talk by Stefan Reinauer.

A centralized Test Management Server generates test sequences for remotely located systems under test (SUTs) and this includes controlling and monitoring the SUTs and flashing different firmware builds on them. The test management server coordinates with a repository for accessing test builds and for storing test reports. Test reports are the final and useful output of the whole system and these may be accessed using browser by clients from internet.

A Test Supervision Server is a low power computer that acts as a local housekeeper of SUTs for a given physical location. It connects to the Test Management Server using SSH over internet and executes given test sequences by coordinating closely with the SUTs using a Test Interface Board. Programmable power-strips are provided to control power supply to the SUTs from Test Supervision Server.

My work will be confined to the distributed components for now. I have completed the programmable power-strip block. A future add-on to this block could be integrating active power & energy measurement of an SUT for energy efficiency benchmarking. If this is really desirable it could be done after I finish doing the other parts. Right now I’m working on the Test Interface Board.

Test Interface Board: Behaviour

The Test Interface Board provides necessary hardware interface for connecting Test Supervision Server to an SUT. This is necessary to flash firmware to the ROM, to control power/reset sw, to measure PSU voltages and surface temp. of ICs and to take POST feedback if available. Let’s dive into more details to see how this can be done.

Test Interface Board: Detailed box diagrams

FT232H has a multipurpose serial engine that can be configured as SPI master. FT232H has additional pins that may be used as GPIOs so a GPIO expander may not be needed. The FT232H datasheet states that it offers up to 30mpbs throughput in synchronous serial mode which makes it a fast flashing solution for the given price point (3$). Slave Select (SS) pins can be used to switch between other devices like an ADC that gives voltage and temperature measurements and an optional Feedback microcontroller configured as an SPI slave that gives more information about the SUT. A few GPIO pins can be used to configure Logic Level Translator to ensure compatibility with serial flash of different voltages ranging from 1.8 V to 5V and a GPIO pin will also be used to configure a FET toggle switch (MUX) to electrically detach the serial flash for programming and connecting it back to the motherboard when it’s done.

Notice that I’ve got rid of microcontroller this time. This is because a new microcontroller chip doesn’t necessarily have a bootloader and it needs to be programmed using a dedicated programmer. This adds considerable cost and inconvenience for someone who needs to build only few of these boards. So unless you’re using the optional Feedback module nothing needs to be programmed. Just ordering the board and components and soldering up everything using a 15W iron should be enough to make one of these.

I’m also going to ensure modularity by having small PCBs for each functionality connected to a main-board using headers so that they can be developed independently and used as required. Also, there’s flexibility of choosing temperature probes because it is possible that someone already has good quality probes (that come with professional DMMs).

And a few comments about the ADC I’ve chosen – The ideal choice of ADC for voltage and temperature measurements where the sampling period is large is an integrating ADC. An integrating ADC charges a capacitor from the input signal for a known period of time using an opamp integrator then it discharges that capacitor using a known negative reference voltage. The time it takes to discharge the capacitor is proportional to average value (area under curve) of input signal over sampling period. It’s theoretically simple but it needs use of precision external components and a microcontroller program to work. This is the technique used in professional DMMs (True-RMS) and bench power supplies (for feedback). Delta-Sigma ADCs are common and cheap these days but they don’t average the values over time like integrating ADCs. However, they can provide acceptable accuracy for our application and MCP3208 is a good candidate.

Please see the figure for more details and let me know if there are concerns or suggestions. I’ll post more stuff and schematics in a couple of days.

GSoC (coreboot) Progress till week 2

As you might know my GSoC project is about making a test rig that can make coreboot test systems more accessible to a coreboot test server. This test rig enables coreboot test server to interact with the systems under test (which may be remotely located) in the following ways:

  • Power supply control (discussed in this post)
  • power/reset switch control, voltage and temperature readouts, firmware flashing on serial flash (to be done next)
  • provision for POST feedback (later)

With this project I’m hoping to create an environment where developers will be able to conveniently connect their systems to the coreboot test server for testing at their own place. This is why I like to call it a distributed test environment as it facilitates mass testing without the need to maintain a dedicated testing facility.

So this week I will present a nice and easy solution for power control of the coreboot test systems. I would call this device a ‘programmable power strip’. Before going to the final solution let me first walk you through all the routes that I’ve taken in order to answer some potential questions that may arise. Read on…

GSoC: Spice Payload report

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.