Allen Yan [mailto:lexkde@gmail.com] wrote:
]Oh, sorry, incorrect address! ]http://www.google-%5Dmelange.com/gsoc/proposal/public/google/gsoc2014/jinyiy... ] ]TianoCore as Coreboot payload ]JinyiYan ] ]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: https://www.mail-archive.com/edk2-devel@lists.sourceforge.net/msg06354.html
]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 graphics experts.
]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@gmail.com ]IM/IRC/Skype/other contact:irc.freenode.net: ] #coreboot, #flashrom nick: Jinyi-Yan ]Web Page / Blog / Microblog / Portfolio: ]Country/Timezone:China/UTC+08 ]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? ] ] No. ] ] 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: DuetPkg/BiosVideoThunkDxe/BiosVideo.inf (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 ]working style? ] 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 ]bonding period. ] ] 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 ]success? ] 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: http://notabs.org/coreboot/duet-payload/index.htm 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.
Hi Scott,
I agree that several things are missing for a full experience. I'm just collecting a bunch of pointers where code could come from to be adapted.
Am Montag, den 24.03.2014, 22:37 -0500 schrieb Scott Duplichan:
- 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.
Could be done by importing flashrom, putting that behind the FVB protocol. That makes things GPL but who cares?
- USB OHCI support. Without this the USB keyboard on AMD systems
will not work until after the OS boots.
libpayload has full OHCI support.
[...] or for setting the SMM base address register.
SMM is ideally locked down by coreboot already - payloads shouldn't be able to modify it. Rationale why this also applies to UEFI: it's too large to reasonably trust it.
For necessary UEFI services (eg. safe write access to non-volatile variables to promote UEFI Secure Boot from complete joke to half joke), it might be necessary to provide capabilities within coreboot/SMM.
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 graphics experts.
There's a simple solution, but I guess it's part of the experience of a GSoC applicant to find about their field. :-)
A much simpler INT10h video solution is: DuetPkg/BiosVideoThunkDxe/BiosVideo.inf (with some available bug fixes and enhancements applied) There is no need for full CSM.
Unless VGABIOS isn't initialized in the real system, eg through YABEL. CSM is the bullet proof solution and it exists.
But it's certainly weird to discuss GOP workarounds in a proposal that (right now) consists to 50% of "implement GOP" :-)
What problem will writing the piggyback GOP driver solve?
That one is strategy, not implementation, so I'll answer it: native VGA init. Available on some Intel chipsets near you.
Regards, Patrick