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
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.
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.
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
Just got this:
FILO version 0.6.0 () Fri Jun 11 13:38:04 GMT 2010
00:03.2 0223:1166.2 EHCI controller
00:03.1 0223:1166.1 OHCI controller
00:03.0 0223:1166.0 OHCI controller
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
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. 🙂
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.
Last week’s GSoC work was centered around getting the USB root hub to work. USB root hub is a pseudo USB device, which is exposed as a standard USB device to the stack, but handled by controller registers. When you plug a device into a port on your computer, chances are that a root hub is involved. Continue reading GSoC USB: weekly report #2
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.
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.
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.