GSoC 2011: Coreboot Spice Payload

This year I was accepted on gsoc – and I`m excited – to work in a project to make corebook a spice client. The idea is to use buildrom to pack everything.

Once buildrom has been unmaintained for quite some time now I`ll need to work around it before working on the spice bits.

 

Spice

Yeah! when I say spice I mean the remote and virtualized desktop protocol, originally developed by Qumranet now acquired by Red Hat.
The basic idea is to make a client run from a minimal environment. We`ll be working on a LAB(Linux as bootloader) solution.

 

Initial steps

As I said above, we need some work around buildrom system, the coreboot buildsystem has migrated to kbuild on the stable code and lots of things have changed with it.
Both buildrom and coreboot work with kbuild with that I`m writing a small python piece of code to parse coreboot`s Kconfig files and then arrange it into buildrom source code. I also need to 1) monitor the coreboot Kconfig files changes so I run the parser again and 2) change the coreboot build calls.
With all the kconfig arranged the buildrom user needs just to set the rom properties including the coreboot options(since those options are passed to coreboot build).

The kernel configs also need some attention it`s statically set for each board, I haven`t come with a better solution for this till now.

 

Hardware and new toys

I have ordered an ALIX.3D3, a flexyICE and a new desktop computer. The first 2 are comming from EU and will be dispatched later on May. The new desktop computer I get till the end of the week(before the gsoc bonding period end).

 

Now, let`s rock.

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.

GSoC project: Coreboot panic room. Diagnostics (also remote flashing)

I’m very excited to announce my GSoC project which is intended to bring some light for coreboot users. To begin with, I would like to introduce myself. I’m 20 years old student living in Lithuania. I’m studying Informatics Engineering at Kaunas University of Technology. This year we have two interesting modules here: one about operating systems and the other is introduction to computer architecture, which is crucial for learning coreboot. Some time ago I have played with avr microcontrollers, so I have good soldering skills. One day during my free time I thought:

What the hell my old computer’s bios is so badly written that it can’t boot from usb flash and it can’t suspend correctly on Linux? I have a laptop that is running bios stuff more time than the old computer. I thought I can’t live with that and then I found coreboot 🙂 I was very excited that it was so configurable, so open alternative 🙂

Not to waste time on cheap talks, here is my project:

To help developing coreboot code, we have to set-up remote diagnostics (also flashing) interface in coreboot. We will be a able to renew bricked board through serial port or even do some research through registers in case of panic(). This will enable easier development of CAR, chipset, payloads code.

Abbreviations used later:
TARGET – machine running coreboot;
HOST – machine running serial port application, connected to TARGET through serial port
The platform that I will use for development is traditional x86. In case coreboot is supported on ARM, I will be hapy to buy one board to make my code working on both platforms.

 

There will be a diagnostics shell, similar to Serial ICE (or LLshell). Invocation of the shell may occur at any time (when we have (cache or ram) memory or not). It would be invoked by (we should discuss this):
1) serial port data received interrupt (HOST triggers diagnostics mode)
2) if user specified it in code (we may add something like checkpoints in coreboot’s code where TARGET will send command through serial port to HOST and if receives the answer – it enters diagnostics mode)
3) in case of panic() invocation (or something like die())

 

In that shell’s loop we will be able:
1) to run the code instructed through serial port (like Serial ICE): manage register contents, do some research or even like Carl-Daniel suggested to initialise CAR
2) to flash memory through serial port, when we have some memory (CAR or RAM) initialised. Some generic flashing code will be pumped through serial port to memory and then executed.

 

Some small specific goals:
1) analyse different code handling schemes in cases of memory we have (no memory, CAR, RAM)
2) define how Serial ICE will be integrated to coreboot
3) integrate defined Serial ICE stuff to coreboot as our new shell
4) add memory handling funcions to our new shell (for checking how much memory we have, and if we have – for uploading code to memory)
—
5) analyse flashing protocols
6) develop uniform flashing scheme (for SPI, parralel flash…) define what commands are required, where these commands should reside.
7) make serial port application for HOST (maybe we will use flashrom’s serprog code, it might require enhancing)

 

These are just milestones, some points may change after deeper investigation, when we will have something done.
We may experience the risk of problems in different operating modes when having different memory (no memory, CAR, RAM).

 

Yesterday I was looking at flashrom sources. People have done very good job in preparation for porting it to libpayload. Maybe I should concern making a complete flashrom port on libpayload?
Anyway, thanks for reading about my project. You are welcome to post some comments (maybe on the mailinglist). Your experience would be helpful.
Thanks to our mentors for their patience 🙂

AMD commits to coreboot

Kevin Tanguay at AMD writes about AMD’s focus on coreboot.

 

Finally, AMD is now committed to support coreboot for all future products on the roadmap starting next with support for the upcoming “Llano” APU.  AMD has come to realize that coreboot is useful in a myriad of applications and markets, even beyond what was originally considered.  Consequently, AMD plans to continue building its support of coreboot in both features and roadmap for the foreseeable future.

 

This is great news for coreboot and I hope to see some announcements from other vendors on their coreboot offerings later this year.

FOSDEM 2011 photos

I just found out that nobody wrote a few lines about this year’s FOSDEM 2011. This year we had a booth (aka a “table”) in one of the buildings. We had total 4 speeches. I did one lightning talk about the coreboot and x86 init (video) and a lecture about coreboot and its speed. Carl-Daniel Hailfinger had lightning talk (video) and a talk about RAM Cold Boot Attacks The talks had a great success and a lot people attended. Continue reading FOSDEM 2011 photos

u-boot as coreboot payload

U-boot is bootloader on ARMs, PowerPCs and other platforms, it has a nice set of commands and in general it feels like a small operating system. I’m not certainly sure if it is good direction, please feel free to compare with UEFI 😉 but I simply miss it on x86. I work at SYSGO with u-boot in daily basis and even port it to different boards/platforms. The x86 is no easy to init and I think this is the reason why there is only one x86 board in whole u-boot tree. This board is called eNET and it has a AMD ELAN SC520 SOC. But luckily, with coreboot we can init much more x86 boards and this leads to natural conclusion to have the u-boot as the coreboot payload. I would like to share with you part of this “fantastic” hacking journey to make it happen. Continue reading u-boot as coreboot payload

flashrom: Which hardware do you want supported?

flashrom is growing rapidly and we are constantly adding support for new SATA/PATA controllers, network cards, graphics cards, USB devices, JTAG cables, DIY hardware hacks, desktop/server mainboards and even some laptops.

If you own a piece of hardware which has a flash chip and lives in a PC (embedded devices with NAND flash are already covered by other software), and if you want to reflash that piece of hardware, please comment here (with some info on how to reach you) or mail us at flashrom@flashrom.org. We will use this to prioritize support for hardware people are interested in.

Continue reading flashrom: Which hardware do you want supported?

Intel selling crippled CPUs

Via boingboing.net: Intel is now selling crippled CPUs that can be ‘upgraded’ through the purchase of scratch cards (!) with a code. That code can be entered in the BIOS of the computer, thus unlocking additional horsepower.

I’m running out of CPU – quick, head over to the corner store for an Intel scratch card!

Is this an alternate universe? And, how long before they sell cards that will unlock extra features, but only for a limited time?

I guess now we know at least one concrete reason why Intel does not like coreboot. You can’t restrict people like this when their computer does not have a proprietary BIOS.

git svn info: Unable to determine upstream SVN information from working tree history

If you ever had to work with a clone of a git repo which was created with git-svn, you might have tried to run

git svn info .

to find out about the latest svn revision in the git tree. Instead, you will see the error message

Unable to determine upstream SVN information from working tree history

and you might scratch your head. Turns out that git svn info only works for local trees created with git-svn. Once you clone such a tree, all svn related metadata will be lost. This data loss is by design. Apparently git considers svn info to be “metadata” which will not be cloned, whereas git history is not “metadata” and will thus be cloned. Is is also apparently fairly well known among git developers and advanced users that git svn only works from the repository it is initialized from, but the documentation doesn’t mention this limitation anywhere AFAICS. Similar issues exist for git svn log.

Continue reading git svn info: Unable to determine upstream SVN information from working tree history