- 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 🙂