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.
Getting the flashrom 0.9.2 release out of the door was a really labor-intensive process because we wanted to make 0.9.2 the 1000th commit in the repository. That worked and 0.9.2 is a really nice release with no known regressions, but a lot more features and improved reliability. Speaking from experience of the last 3 releases, acting as release manager is really a full-time job and will not leave any spare time for developing cool features.
flashrom GSoC development is right on track. So far, I have posted patches for:
Continue reading flashrom progress report #1
The flashrom developers are happy to announce the release of flashrom 0.9.2.
flashrom is a utility for reading, writing, erasing and verifying flash ROM chips.
flashrom is designed to update BIOS/EFI/coreboot/firmware/optionROM images on mainboards, network/graphics/storage controller cards, and various programmer devices. It can do so without any special boot procedures and from your normal working environment.
After over nine years of development and constant improvement, we have added support for every BIOS flash ROM technology present on x86 mainboards and every flash ROM chip we ever saw in the wild.
Highlights of flashrom:
Continue reading flashrom 0.9.2 released
The first week passed already, and given the experiences of the last years, the coreboot project decided to request weekly reports from us students, so here is the first report for my USB project. Continue reading GSoC USB: Not-quite-weekly report #1
Although this article is about Coreboot I start from beginning. Once upon a time (November 2009) there was nice idea to make SerialICE work through the Ethernet link. Reason is simple, it is slow and Ethernet is way faster. I started to investigate if there is some network adapter which can be used without the need of RAM.
If you check the documentation of most Ethernet chips, the packet descriptors are always located in main memory and they just use DMA to transfer data to/from the FIFO inside the card. I tried some sophisticated google queries to find out if there is some adapter with internal SRAM, and after a while I found one. Continue reading Coreboot console over Ethernet
hi i am Cai Bai Yin. And my GSOC 2010 project is Payload infrastrcuture. The main job may including adding payload build support to the coreboot kconfig and crossgcc build which would make the project as an whole. if time permit, some filo improment will aslo be included.
I am a freshman to coreboot. But i am trying my best to do things better. There may be lots of tough probems stay in front of me. Hope i can deal everything well. I will aslo try to learn as much as i can from the others.
Hi! My name’s Robert Austin, and my GSoC 2010 project is to get TianoCore working well as a coreboot payload. TianoCore is the open source component of Intel’s implementation of UEFI. TianoCore on it’s own is not a BIOS replacement, but it can do some interesting things, and since a quite a few large companies are already committed to EFI, it makes sense to have an EFI payload as an option in coreboot.
I am very excited about working on this project, and working with the coreboot community. I will make regular announcements about my progress here on this blog, and I will keep my working code available in a git repository here. There isn’t anything there yet, but there will be soon. To anyone who happens to checkout my code during the summer, I welcome any comments or suggestions relating to the style or quality of my code. I want to write high-quality code, so feedback is appreciated.
It is my second year to join GSOC. In this year, i will take in charge of AMD RS780+SB700 mass porting. I would like to write down each progress here between this summer.
Today, the dediprog ISP-Testclip-SO8 has arrived. although it’s pretty expensive, but it seems pretty cute. I have already tested in in BTDC lab, hope it can helps me much more.
After starting the USB stack in libpayload in the Google Summer of Code of 2007, I’m back this year to implement some more drivers. So far, we support UHCI Controllers – that is, USB1.x on Via and Intel chipsets.
There are also patches to support OHCI which are under GPL licensing As libpayload ist BSD-licensed, this make it unsuitable for inclusion. So this year I’ll do a clean implementation of OHCI to get this matter settled.
With this, all USB1.x controllers except for some very rare pre-standard controllers will be supported. This also includes USB2 boards, which means all current mainboards out there, as USB2 simply requires “companion controllers” (which are usually OHCI or UHCI) for USB1 modes.
After this is done, I’ll start on USB3 support. USB3 is still relatively new, but there are two reasons to start working on it:
- USB3 will be more popular in the next years, so doing it now ensures that we have one issue less to care about.
- Unlike with USB2, xHCI (the host controller standard for USB3) doesn’t use the companion concept, but requires the controller to support USB1 to USB3 itself. This means that old drivers (for UHCI, OHCI or EHCI) won’t find any controller to work with on such boards.
Implementing OHCI and xHCI ensures that all current boards as well as those of the near future will be supportable by libpayload and its users.