Tag: GSoC

Hello :)

I’m Ayush Sagar from India and I will be working with coreboot this summer on the project “Test set-up for the coreboot distributed firmware test environment featuring greater extensibility, enhanced automation, concurrent high speed firmware flashing and decentralized operation“ under Google Summer of Code 2013.

I’ve almost completed my graduation in Electrical & Electronics Engineering and by training I’m skilled at developing SCADA applications and ladder logic programs which are used for power system and factory automation. However my interests are widely scattered around physics, electrical engineering and computer science. I have been repairing consumer electronics and computer hardware on component level since a very long time as an earning hobby. It’s quite profitable here even today as most people are reluctant about throwing away their belongings. I’m also passionate about programming but I’m new to free and open source software development.

Continue reading Hello 🙂

Hello world

Hello World! I am Alexandru Gagniuc, and I’m a free software addict.

superboosted2

I got involved in coreboot in early 2011. I had an old VIA board and just thought I’d try coreboot on it. What could go wrong with an unsupported board? I ignored the “everything” part, and nothing went wrong. I never finished that port, but that’s of less relevance. I learned “how things are done around here”. Besides starting to make small contributions here and there, I was also lucky enough to catch an NDA with VIA and a free EPIA-M850 board. The only thing supported on that board was the superio. Today, we can initialize DDR3 memory and boot Linux with it.

My journey was perilous. I have met a great number of wonderful people along the way. Actually, that’s where I learned most of what I know. My only useful skill when I arrived was knowing how to read C syntax. I have since contributed to a modest number of other projects, most notably sigrok and libopencm3 (I’m the same guy that added support for LM4F there). I just like making hardware come to life, it seems.

This summer, I will be bringing you a tool to unlock your bricked LPC and FWH flash chips. I need a break from needing to program 30 years of history, and needing to deal with thousands of registers in several different IO and memory spaces. I’ve chosen Cortex-M as my operating table. No port IO, no configuring memory regions, no interrupt handlers, no memory initialization, no “any of the one million things that can silently break”. Everything is memory-mapped and the number of registers is so insanely small, that it makes sense to #define them all. It’s small, it’s readable, it’s not confusing. It’s beautiful. It’s the best coding vacation anyone can take from coreboot.

I will use a Stellaris Launchpad as my patient. For anyone coming late to the game, the new name is Tiva C Launchpad. I’ll use the Stellaris because

  • it sounds a lot cooler than “Tiva C”
  • the name actually fits well next to “Launchpad”
  • I was able to snatch a couple of them last year for $5 a piece.
  • The picture at the top would not look as cool if it were a “Tiva C”

I’ll turn the innocent looking red slab into a mean lean, programming machine. We’ll start with LPC. Emulating a 33MHz 4-bit bus should be fun (not counting the obscene cost of coffee, and red eyes due to sleepless nights). I didn’t say it will be easy, but as Jimmy McMillan once said, “the fun is too damn high!”

Next time, I’ll tell you how to set up the development environment, and how to put some firmware on the board.

 

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.

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

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 0x5000. 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!

GSoC2011: midterm report

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 ?

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

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.
Continue reading GSoC2011(Week 5): the layout of coreboot rom and cbfstool for ARM

GSoC2011(Week 1): Analysis of U-boot ARM boot code

This is such a busy week. At the end of last week, I have just ordered my OpenRD-Ultimate box but sadly it will be delivered at the end of June. So if I just wait for that box, I will not be able to test my code. That’s terrible! After talking with my mentor, I decided first porting coreboot to RealView Versatile/PB926EJ-S board then to OpenRD-Ultimate. Since qemu can emulate PB926EJ-S, I can test my code on it quickly and freely. After this work, the basic layout, libs and headers for ARM are ready to use. So I can start to port coreboot to OpenRD-Ultimate then.
Continue reading GSoC2011(Week 1): Analysis of U-boot ARM boot code

GSoC2011 Project: Porting coreboot to ARM architecture

I am so excited that my idea on porting coreboot to ARM architecture has been accepted by GSoC project this year. First, let me introduce myself to you all. I am now a junior student at Hebei University of Technology, People’s Republic of China. My major is Computer Science and Technology. Although my courses are almost focus on high-level software development like database system and software engineering, I am a fan of low-level development. I taught myself IA32 and ARM architecture last year. And during this summer, we will porting coreboot to ARM and make it a new bootloader for ARM.

Those days, I am studying the building system of coreboot deeply, and I am trying to add cross-compile toolchain support to it. Developers has created such a great system and I want to make it greater. 🙂

Thanks for reading my project and any comment is welcome.