TianoCore payload status

I’ve been holding off on writiing a post until I had some significant chunk of code I could point to to show that I’m making progress.  Well, I am making progress, but there’s no “significant amount” of code yet.  I’m not worried about the slow start, because what I’m doing makes sense and I am writing code, but there are still so many things I run into every day where I have to stop and look something up to try to figure out why it was done a particular way.  Almost all of the confusion comes from the TianoCore codebase, which is 1) huge, and 2) written in a consistent but unfamiliar style.  Like this line,

 IN OUT   EFI_PEI_PPI_DESCRIPTOR      **PpiDescriptor OPTIONAL,

What’s with the IN, OUT and OPTIONAL?  I haven’t been able to find them defined anywhere, I’m assuming they’re special comments that Visual Studio knows about, but I haven’t found any reference to them. In comparison, reading the coreboot code is fun and easy.  It’s just straightforward c.

libpayload xcompile

after a long time learning and code checking, several things has been done:

1)kconfig language have already been learned,  i learned all of these things from “http://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt”

2)much clear with libpayload xcompile code and menuconfig things. i reviewed all of the code under libpayload/util.

question is i do not know what interface should be added into the libpayload menuconfig. and i also have an doubt about the coreboot xcompile. why not just put the files into the trunk but instead of making the downloaded with and script?

First successful Nvidia MCP6x/MCP7x SPI access

Since a few hours, my Nvidia MCP61/MCP65/MCP67/MCP73/MCP78S/MCP79 SPI driver is tested and it works well. Only probing for a flash chip was tested, but still… this means my SPI bitbanging code is correct, and Michael Karcher’s reverse engineered docs are correct, and my implementation of the Nvidia GPIO interface used for bitbanging SPI is correct as well.

This is big news because with this patch flashrom finally has 100% support for all x86 chipsets we saw in the last ten years.

Huge thanks go to Michael Karcher for reverse engineering the interface and writing up cleanroom documentation which I could use for implementing the interface.
Huge thanks to Johannes Sjolund for testing my patch on his hardware although it was completely untested before.

Get the patch here: http://patchwork.coreboot.org/patch/1520/ (click on the “patch” link on that page to get a download).
Continue reading First successful Nvidia MCP6x/MCP7x SPI access

GSoC USB: first successful transfer

Just got this:
FILO version 0.6.0 () Fri Jun 11 13:38:04 GMT 2010
00:03.2 0223:1166.2 EHCI controller
Not supported.
00:03.1 0223:1166.1 OHCI controller
00:03.0 0223:1166.0 OHCI controller
fullspeed device
device 0x3606:0x0151 is USB 2.0 (MSC)
it uses SCSI transparent command set
it uses Bulk-Only Transport protocol
using endpoint 82 as in, 1 as out
has 1 luns
Waiting for device to become ready... ok.
spin up. OK.
Reading capacity of mass storage device.
has 256000 blocks sized 512b
boot:

For this to work, the OHCI root hub must work (to find the USB device), control transfers must work (setup the address, get some general information about it, like “SCSI”, “Bulk-Only”, endpoints, and LUNs), and bulk transfers must work (“256000 blocks of 512b” is got through SCSI/MMC2 commands via bulk)

There’s still quite some work left, as this only works on selected USB devices (more timing resilient than the others?) and errors are neither detected nor handled so far.

Once this is stable and survives all my USB gear, I have to implement interrupt transfers (mostly for keyboards) and my first part of GSoC, OHCI, is done. 🙂

Progress with TianoCore as a payload

I’m finally past the point where I’m scratching my head over what I’m reading and know what I have to do.  This changes my initial schedule, somewhat.  I hadn’t really understood how much work needed to be done to make TianoCore an effective payload, so my original estimate of “two weeks” was totally wrong, but now that I’ve started I’m feeling good about it.  Right now I’m working on getting TianoCore to build with the coreboot reference toolchain, and adapting the Makefile and kconfig stuff from FILO.  The current way of building TianoCore’s edk2 package involves building their toolchain, and I’d like to cut that part out, or automate it if I can’t cut it out entirely.  The goal is to reduce the number of hoops that potential users and developer’s have to jump through in order to try EFI with coreboot.

flashrom 0.9.2 released — Open-Source, crossplatform BIOS / EEPROM / flash chip programmer

The long-pending 0.9.2 version of the open-source, cross-platform, commandline flashrom utility has been released.

From the announce:

New major user-visible features:
* Dozens of newly supported mainboards, chipsets and flash chips.
* Support for Dr. Kaiser PC-Waechter PCI devices (FPGA variant).
* Support for flashing SPI chips with the Bus Pirate.
* Support for the Dediprog SF100 external programmer.
* Selective blockwise erase for all flash chips.
* Automatic chip unlocking.
* Support for each programmer can be selected at compile time.
* Generic detection for unknown flash chips.
* Common mainboard features are now detected automatically.
* Mainboard matching via DMI strings.
* Laptop detection which triggers safety measures.
* Test flags for all part of flashrom operation.
* Windows support for USB-based and serial-based programmers.
* NetBSD support.
* DOS support.
* Slightly changed command line invocation. Please see the man page for details.

Experimental new features:
* Support for some NVIDIA graphics cards.
* Chip test pattern generation.
* Bit-banging SPI infrastructure.
* Nvidia MCP6*/MCP7* chipset detection.
* Support for Highpoint ATA/RAID controllers.

Infrastructural improvements and fixes:
* Lots of cleanups.
* Various bugfixes and workarounds for broken third-party software.
* Better error messages.
* Reliability fixes.
* Adjustable severity level for messages.
* Programmer-specific chip size limitation warnings.
* Multiple builtin frontends for flashrom are now possible.
* Increased strictness in board matching.
* Extensive selfchecks on startup to protect against miscompilation.
* Better timing precision for touchy flash chips.
* Do not rely on Linux kernel bugs for mapping memory.
* Improved documentation.
* Split frontend and backend functionality.
* Print runtime and build environment information.

The list of supported OSes and architectures is slowly getting longer, e.g. these have been tested: Linux, FreeBSD, NetBSD, DragonFly BSD, Nexenta, Solaris and Mac OS X. There's partial support for DOS (no USB/serial flashers) and Windows (no PCI flashers). Initial (partial) PowerPC and MIPS support has been merged, ARM support and other upcoming.

Also, the list of external (non-mainboard) programmers increases, e.g. there is support for NICs (3COM, Realtek, SMC, others upcoming), SATA/IDE cards from Silicon Image and Highpoint, some NVIDIA cards, and various USB- or parallelport- or serialport- programmers such as the Busirate, Dediprog SF100, FT2232-based SPI programmers and more.

More details at flashrom.org and in the list of supported chips, chipsets, baords, and programmers.

I uploaded an svn version slightly more recent than 0.9.2 to Debian unstable, which should reach Debian testing (and Ubuntu I guess) soonish.

weekly report #1

As the first week has already gone so soon, i spend the whole week to clear my thought, checking the xcompile configuration of libpayload. I also read some code of buildroot which wish could bring some ideas for me.

I know it may be a little wasting. But i began to write code in the weekend. Hope everything goes fine this week.

Jetway PA78VM5-H porting progress

firstly, thanks to Scott Olsen for supporting the mainboard. PA78VM5 is 780/700/ddr2.

The superio which it used is fintek f71863fg. I have already make all of the code done. but at last i found that i do not have the serial port convert which make me can connect to it.

The following week may be used to 1)extract the vbios. 2)make the linux booting…

i am pretty looking forward that.

One week plus…

I would like to report that I’m making some progress, but that wouldn’t quite be accurate.  I am making progress: I’m putting in adequate hours, reading code, reading specifications, but… let’s just say I’m starting to appreciate some of the less than complimentary things I’ve read about [U]EFI.  It is extremely complicated.  My inner engineer is constantly frowning as I read page after page of documentation, thinking, really?  they couldn’t think of a simpler way to design this?  Not trying to complain.  There are a few things I really like about EFI, but this sort of software development –the kind that starts with 3000+ pages of specifcations– is unlike anything I’ve ever dealt with.