[coreboot] GSoC-2014 Coreboot project
scott at notabs.org
Tue Mar 25 04:37:43 CET 2014
Allen Yan [mailto:lexkde at gmail.com] wrote:
]Oh, sorry, incorrect address!
]TianoCore as Coreboot payload
]Short description: The combination of coreboot + TianoCore
]is the most straightforward option to provide a complete,
]opensource UEFI environment.
This proposal should mention that only x86 systems will
be supported if that is the case.
To provide a complete, opensource x86 UEFI some items not
listed in this project proposal are needed:
1) UEFI support for writing to flash memory. The UEFI name is
Firmware Volume Block protocol. One module for Intel systems and
another module for AMD systems would probably cover most x86
motherboards. All current open source UEFI solutions use a
substitute that either fails to capture OS writes to UEFI NVRAM
variables, or does not preserve these writes through a power down.
The most visible effect of the substitute firmware volume block
driver is loss of the NVRAM variable that points to the boot
device. When this variable is lost, Linux will no longer boot.
Windows can still boot due to an automatic repair mechanism.
In all cases, the boot order in a multiboot system will be lost.
The use of the substitute firmware volume block driver causes
other limitations such as such as loss of configuration settings.
2) USB OHCI support. Without this the USB keyboard on AMD systems
will not work until after the OS boots.
3) Another missing item is UEFI MP Services. This one might not
be essential. It is needed if UEFI code needs to launch the AP for
such things as gathering SMBIOS data or for setting the SMM base
address register. There is a discussion on the EDK2 Devel mailing
list about the possibility of an open source solution:
]Based on coreboot-pkg, the project intends to implement
]some new features like UEFI CBFS driver and a GOP driver
]based on pre-initialized framebuffer.
How will the CBFS Driver be used?
Will the GOP driver support multiple video solutions?
If so, how? If I use a brand XYZ video card how will the
GOP driver find the details of the frame buffer? I know
it is possible because operating systems do it. But the
proposal should explain it for those of us who are not
]Please complete the standard Google SoC application and project
]proposal. Prospective coreboot GSoC student should provide the
]following information as part of their application. If you are
]applying for a flashrom or SerialICE project use common sense
]when using the template below, this is part of the test. ;)
]Name: Jinyi Yan
]Email: lexkde at gmail.com
] #coreboot, #flashrom nick: Jinyi-Yan
]Web Page / Blog / Microblog / Portfolio:
]Normal working hours(UTC): 10:00~16:00
]School:University of Chinese Academy of Sciences
]Expected graduation date: 2015
]coreboot welcomes students from all backgrounds and levels
]of experience. To be seriously considered for coreboot GSoC,
]we recommend joining the mailing list and IRC channel.
]Introduce yourself and mention that you are a prospective
]GSoC student. Ask questions and discuss the project that
]you are considering. Community involvement is a key
]component of coreboot development. By the time you have
]submitted your application, you should have downloaded,
]built a and booted coreboot in QEMU, SimNow, or on real
]hardware. Please, email your serial output results to
]the mailing list.
]The following information will help coreboot match students
]with mentors and projects.
] Please comment on your software and firmware experience.
] I used to be a mainboard BIOS engineer in ASUS Technology
]Suzhou Co., Ltd for about two years (2007.7~2009.2). When at
]AsusTek Suzhou, my work is mainly responsible for bios porting
]and fixing bug. There were four mainboards P5KPL-S, P5QL-E,
]P5QL-SE, P5QL. All based on Intel platform and AMI Legacy BIOS Core.
] In the second half year of 2008, I worked on pre-development
]of EFI-BIOS for ASUS mainboard. I wrote a Dual bootblock module
]and added NTFS support(read only) for AutoRecovery module using
]AMI Apito platform (based on EFI).
] The most important is that I still have plenty training
]materials(EFI training and hardware initialization,
]kinds of intel chipset datasheet before 2009) from the company.
If the intel chipset documents are not publically available
you should not list them in your proposal. The reason is that
companies sometimes ask engineers to destroy non-public documents
once they leave the company or finish the project.
]They can let me grasp the concepts that I‘ve forgot quickly and
]do proper choice.
] Have you participated in the coreboot community before?
] Have you contributed to an open source project? Which one?
] What was your experience?
] Not happened before.
] Have you built and run coreboot? Did you have problems?
] Yes. With SeaBIOS as payload, It's a easy job.
] Did you find and fix a coreboot bug? Did you send a patch to
] Gerrit? Please provide a link to the Gerrit page.
] Not now!
] Please provide an overview of your project (in your own words).
] Coreboot-pkg provides a nice start. In the project idea
]webpage, there lists two possible tasks, one is a minimal
]GOP driver, the other is a CBFS EFI driver. I consider the
]“minimal GOP driver” is more hardware related but “CBFS EFI
]driver” is less hardware related or simpler.
]Considering the GOP driver can be workaround by integrating
]SeaBIOS as CSM in Tianocore payload,
A much simpler INT10h video solution is:
(with some available bug fixes and enhancements applied)
There is no need for full CSM.
]then maybe I should work out the simpler tasks “CBFS” driver first.
] As mentioned in webpage “www.coreboot.org/TianoCore”,
]the GOP driver piggybacks on the coreboot framebuffer.
]So, it's based on the VGA BIOS, but provide a new interface
]other than int 10h.
So it sounds like coreboot will install the legacy video
option rom and then make INT10h calls to get the frame
buffer info. If the day ever comes where legacy video
option roms are no longer shipped, this GOP driver will
no longer work. Yet that will be the time when a GOP
driver is most needed. Why not extract and use the OEM
GOP driver? What problem will writing the piggyback
GOP driver solve?
] In my view, this project may suffer less issues caused
]by SB chips, CPU and MRC code because coreboot would run
]well in supported mainboard.
] That is very nice. In my mind, the Tianocore payload
]should be start execution from DXE phase. For now, I don't
]know exactly the details that how coreboot pass control to
]Tianocore DXE phase. In my mind, in Tiano, the original
]PPI phase will send proper information to DXE through hand
]off block (HOB) in the system memory.
] Provide break down of your project in small specific
]weekly goals. Think about the potential timeline.
] 1. How will you accomplish this goal? What is your
] a) building a test enviroment.
Consider stating if the build will work from Linux,
Windows, or both.
] Both emulator and real mainboard are needed.
It is good you specifically mention real mainboard.
It is usually more work than an emulation only boot.
But then the question becomes which mainboard(s)?
For example, AMD mainboards use OHCI for the low speed
USB used with keyboards. Intel uses UHCI. Open source
EDK2 UEFI supports UHCI but not OHCI. As a result,
open source UEFI does not support the USB keyboard on
AMD systems unless you pass it through a USB2.0 hub
as a work around. There are also some relatively easy
to fix problems when EDK2 is used on AMD boards.
]As Vladimir's suggestion, I'd better
]use GRUB's ability to chainload payloads for testing. So,
]the coreboot and the tianocore payload are separated.
]Maybe I should use EFI shell AP to test the drivers.
] b) bonding with the cooreboot communities. Patrick
]Georgi, Stefan Reinauer, David Woodhouse and Vladimir
]Serbinenko seems main contributor to coreboot-pkg.
] c) Grasp the code base of Coreboot interface to
]payload, CBFS and the knowledge of UEFI in the community
] d) coding, testing, coding... get CBFS driver worked
]on the emulator before mid-term evaluations.
] e) get the code worked on a real coreboot mainboard.
]If everything goes well, the GOP driver would be checked.
] I think continuous working time is important for me,
]because I want to grasp the whole image of the project
]at first, then begin to read corresponding datasheets
]and code base carefully and write some test at the same
]time. I'd like to work from 6 p. m.(UTC 10) to 12 p. m.
](UTC 16) for GSoC 2014 from Monday to Saturday and go on
]programming in the day on Sunday.
] 2. Explain what risks or potential problems your
]project might experience.
] I concern about the proper debug method and test
]environment. Debug information output from serial port
]is nice. Maybe the debug card is also needed. About
]test environment, I need to purchase a coreboot
]mainboard and a few flash chips. As suggestion from
]IRC(phcoder-1creen), I should run in simulator first.
] The potential problem is lack of document if I
]failed to test the project on the real hardware. I
]also notice that there's little training materials
]for coreboot, but not a serious problem.
] 3. What would you expect as a minimum level of
] 1) get a worked CBFS driver on emulator. 2) Make
]windows load with tianocore.
There is already a coreboot UEFI payload that boots
Windows and Linux:
So goal 2 doesn't break any new ground.
] 4. Do you have a stretch goal?
] Implementing a GOP driver that piggybacks on the
]coreboot framebuffer or writing some training
]materials for coreboot.
] What are your other time commitments? Do you have
]a job, classes, vacations? When and how long?
] I have a three weeks vacations. During that I
]could contribute more then 8 hours a day.
More information about the coreboot