coreboot

GSoC 2011: little trip

This might be not a good idea, but I had got bored with my project not going well, so I eventually got on trip, through “FOSS and friends” 🙂 I have had some headache with nouveau driver, till I understood that deprecated version was installed. Tried to install a package, which got me in a geometric progression of required dependency packages 🙂 I have filed a bug for LibreOffice, and got one future TODO for “reverse enginering” how exactly CUPS works with one of the label printers we have here as it needs a slight modification. The best thing I have done is started reading a book and building “Linux From Scratch (LFS)”. It’s great while building a package you are accompanied with a short page of info about it, not all manual 🙂 Also I have found out that I don’t have good stuff to read, except that 1k pages book about Linux internals 🙂 While looking at the freenode chatrooms list I have found this resource about c language: http://www.iso-9899.info – all it needs is time for reading everything 🙂

My project progress is really slow. As Marc suggested I have done some work to reduce stack usage: wrapped functions to read and use file by 256B peaces (somewhat default granularity). But that still needs testing and cleaning up. Also I need to cleanup my previous work that I haven’t submitted to the list, which enabled running code in car (even though not completely working, as mtrr settings might be wrong or more problems still there).

GSoC 2011: midterm report under panic

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

GSoC 2011: flashrom + filo = ?

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!

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 🙂