GSoC USB: Conclusion

Now that GSoC is coming to an end, I prepared the patches and pushed the code upstream.

r5691 contains the work done until today, which is what I’ll post as my final result to GSoC, too. Work won’t end on it however, so expect more patches in the future.

OHCI

OHCI works – except for interrupt transfers, which are mostly used (in boot environments at least) for keyboards.

xHCI

That one is more complicated than the other controllers combined, and while I made a couple of stupid mistakes that held me up for longer than I wanted, there are aspects in xHCI that make the bootstrap of the driver harder than I’d like it to be.

Once you got the command and event channels set up, it seems that xHCI provides a neat interface for getting all kinds of status information out of it. The only problem is that setting up these channels seems to be more complicated than the entire bring up of UHCI – at least, that’s where I’m stuck right now.

I’ll get back to it, but I hope that a couple of days of doing something else will help me to finally see the problem.

Conclusion

Doing both drivers was ambitious. While I didn’t have the burden of creating the stack design, and learning USB in the first place, like I had in 2007 (when I worked on UHCI for GSoC), it’s still two specifications to understand, two way of communication between the controller and the host system, and finally two drivers to write.

It was fun, but I’ll be more conservative in choosing my project, and estimating the required effort, next time. It’s much easier (and also more satisfying) to add some tasks when the job is done early than to remove them – especially when you get to strip milestones because the hardware is acting up.

GSoC USB: xHCI part 1

I started implementing the xHCI driver. The first obstacle was to overcome a weird lack of configuration of the card (it’s a PCIe device) by coreboot. First I suspected that something went wrong because it uses a 64bit memory BAR, but then it was just a disabled PCIe bus in the devicetree.cb.

Thanks to Stefan for working out that issue.

However, the last days weren’t wasted, as I read the xHCI spec again and again, to build a mental image of how things interact in that standard.

Now I’m chugging along with implementing the data structures in C that xHCI requires (many more than in the older USB HCI specs)

GSoC USB: mid-term report

I stopped doing weekly reports at some point, for a very simple reason: I had few to report, except maybe my frustration that I couldn’t find the bugs in my OHCI driver that prevented some (but not all) devices from working.

So I spent the last weeks tracking down these issues and reading specs and more specs. Both OHCI and xHCI – the latter because it’s part two of my project, and because I was close to giving up OHCI for now and working on xHCI first. It’s an independent task, so that could have been done easily.

Today, I managed to hunt down the bug. It was a simple fix once I found out what’s up. While this uncovered more problems, I can move forward again.

To prevent me from hanging 4 weeks on the next bug, I’ll start on xHCI nonetheless, while doing OHCI on the sideline. Most of OHCI is done, and I guess I can start pushing code upstream soon – just one feature (interrupt transfers, so keyboards work) and a couple of cleanups are missing.

TianoCore payload, mid-summer status update

Well, it’s hard to believe that the GSoC midterm evaluations are here already. I guess it’s true what they say, time flies when you’re sitting in a basement in front of a computer all day. If I were to evaluate myself, I’d give myself a barely passing grade based on results –I’m nowhere near where I expected to be this summer. I think I mentioned before, partly this is due to TianoCore being massively more complicated than I expected when I wrote my project proposal –seriously, I ran cscope on the edk2 branch of TianoCore, and it reported over 160,000 files… the resulting index itself took up half a gig– and partly it’s due to there being so much about sophisticated C usage (and makefiles, and preprocessor directives, and macros, and calling conventions…) that I didn’t understand going into this. (But, having said that, part of the reason I applied to coreboot was I knew there were a lot of important details that had been glossed over in my classes, things that I needed to know and would be forced to learn if I worked on a close-to-the-hardware project.)

Moving on to the status of my project. In my proposal I assumed a couple weeks to improve the state of TianoCore as a payload, a month or so to write a CBFS driver for TianoCore, and a month or so to write the VGA driver. It turns out that the state of TianoCore as a payload was not very good, and so that is what I am working on.

Let me try to briefly explain my current approach. UEFI itself does not initialize the hardware. Before the UEFI firmware can be run, the system (from a cold boot) has to go through the Platform Initialization stage. The PI stage is itself made up of the Security stage (the initial booting, and some optional checksums to make sure the image hasn’t been tampered with), the Pre-EFI Initiialization (PEI , where the memory and chipsets are woken up and initialized) and the Driver Execution Environment (DXE, which loads additional drivers, then starts the UEFI). Coreboot already does most of this work in its own way, so it seems the best strategy would be for a coreboot payload to impersonate one of these stages (each stage is it’s own binary in the firmware volume), provide all the functions and data stuctures that the following stage expects, then jumps to it. Inserting the payload immediately after the Security stage seems redundant and dangerous (the PEI stage would end up trying to reinitialize hardware that’s already in use), and after the DXE stage seems too late, because then the payload would have to know how to load DXE-stage binary drivers. So I’m working on implementing a pseudo-PEI stage, that translates the coreboot provided data structures into the form that the DXE stage expects, and writing a couple dozen functions that the DXE stage expects to be available. This way we can have a minimal-sized payload that can leverage a separate DXE and UEFI stage compiled directly from the TianoCore codebase (or borrowed from a manufacturer supplied image, like a traditional option ROM). I think I can have this working by the end of summer. Thoughts?

coreboot porting to jetway PA78VM5 have been 95% successful.

i am glad to say that the Jetway PA78VM5 mainboard can run coreboot sucessfully. The configuration of Jetway PA78VM5 can be found at PA78VM5.the coreboot+filo can work fine. The kernel began booting, but the only problem is after kernel shows”jumping to **” the serial port stoped showing anything. And i have already set the kernel parameter with “console=ttyS0,115200”

First of all thank olsen provide me this mainboard.

The mainboard have an SPI flash W25X80A, my SF100+testchip SO08 can detect the flash type, but can not erase the flash correctly. After contacted with dediprog engineer. i remove the flash from the board, it seems fine, the programming is fine, but i can not use it with the mainboard unless i can bear removing the flash chip every time i need to rebuild the coreboot. After that, i replace that flash chip with an sst 080b. it worked pretty fine. 🙂

another problem is while the coreboot booting, it stoped while corebooting trying to extract the cbfs files. i debugged this for a long time, finally thanks to patrick, i take his advice remove the $(CBFS_COMPRESS_FLAG).it worked.

the latest problem is that amd famlily10 may have much problem with the current build version.

i should find out what difference between btdc and coreboot public version caused problems.

my next step may focus on this things merge the code, and find out why the kernel did not show the booting message.

i am so glad that coreboot can finally booting the Jetway PA78VM5

progress of libpayload infrastructure and filo

it’s so happy that, filo finally can load libpayload kconfig. i deleted the first line of libpayload Config.in which is “mainmenu”, it still work even if libpayload build itself alone. After this, filo can easy load libpayload kconfig by adding “source ../libpayload/Config.in”. The variable is also blocked me a while for each variable is defined by quotation mark. the makefile should remove these quotation mark before using them, i learned that from coreboot makefile.

the xcompile things of libpayload has already resolved, i found that filo have the same problem which seem the scripts are almostly the same with libpayload, they are need to use the correct directory of coreboot, not themselves.

the problem now is the kconfig command “source” is used to read specified configuration file, this file is always parsed which means that it is parsed at the first beginning, i can not make it get the variable from the forward defined lines. it can only read from ../libpayload. i am thinking if we put filo under coreboot/payloads/, then the path is permanent. We did not need to change this path.

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.

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.