Re: [coreboot] GSoC-2014 Coreboot project
On 19.03.2014 21:06, Allen Yan wrote: > As Stefan Tauner's suggestion, maybe porting coreboot to new mainboard Just a quick note: for porting to new chipset to be accepted, you need to: 1) Justify why this chipset is relevant. E.g. old chipsets most probably aren't. 2) Prove that you're able to do it. New raminit isn't an easy task. Also from quick google it seems that this board uses i945 chipset which is already supported. Port with already supported chipset is a task for 3-5 days for experienced dev, most likeyl too small for GSoC. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
well, vladimir, I would not be so discouraging. In fact if it is an existing mainboard, and you have not done coreboot before, I suggest doing a port, and then doing something new with the port. I'd like somebody to look at doing LinuxBIOS again, i.e. getting us back to the point where we can embed linux in the flash as the payload. Patrick got us a long way back toward getting that working, and it'd be nice to see it finished. ron On Wed, Mar 19, 2014 at 7:46 AM, Vladimir 'φ-coder/phcoder' Serbinenko < phco...@gmail.com> wrote: > On 19.03.2014 21:06, Allen Yan wrote: > > As Stefan Tauner's suggestion, maybe porting coreboot to new mainboard > Just a quick note: for porting to new chipset to be accepted, you need to: > 1) Justify why this chipset is relevant. E.g. old chipsets most probably > aren't. > 2) Prove that you're able to do it. New raminit isn't an easy task. > Also from quick google it seems that this board uses i945 chipset which > is already supported. Port with already supported chipset is a task for > 3-5 days for experienced dev, most likeyl too small for GSoC. > > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
ron minnich wrote: > well, vladimir, I would not be so discouraging. In fact if it is an > existing mainboard, and you have not done coreboot before, I suggest > doing a port, and then doing something new with the port. I think this is a good idea in general. > I'd like somebody to look at doing LinuxBIOS again, i.e. getting us back to > the point where we can embed linux in the flash as the payload. Patrick got > us a long way back toward getting that working, and it'd be nice to see it > finished. I've tested it - it works well at least in QEMU. A solution is still needed for ARM though. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
Hi Jinyi, Can you provide more details about your work as a BIOS engineer? As Vladimir said, if the chipset is unsupported then writing MRC for it will be a very long and difficult process. If the chipset is supported then adding mainboard support may be a relatively simple task that not sufficient for GSoC. If you have experience with UEFI, perhaps you can implement features that are missing in our Tianocore support: http://www.coreboot.org/TianoCore . On Wed, Mar 19, 2014 at 6:06 AM, Allen Yan wrote: > Hi, > I am Jinyi Yan , a second year PhD candidate from Shanghai Institute > of Micro-system and Information Technology, Chinese Academy of > Sciences. I used to be a mainboard BIOS engineer in ASUS Technology > Suzhou Co., Ltd for about two years (2007.7~2009.2). My major now is > optoelectronics. But I have a lot of fun while programming, in my > heart the working experience of being a BIOS engineer is still very > exciting. > I think GsoC is a nice platform for me to participate the open source > community. When I search the GsoC projects and organizations, the > coreboot and flashrom projects are definitely the right choices for > me. I have a spare ASUS P5KPL PC at my hand, but the chipset is not in > the support list of coreboot project. > As Stefan Tauner's suggestion, maybe porting coreboot to new mainboard > or implementing advanced coreboot features on exsiting mainboards are > nice too. > Now I'm not very familiar with the program structure of coreboot, so I > expect your guidence and hope to contribute for coreboot and flashrom > even if my application is not accpeted. > Thanks! Look forward to your kind advice! > Regards, > Jinyi Yan > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
Hi, David, 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). Interesting experience, but memories will fade! Details can't be remembered clearly. >As Vladimir said, if the chipset is unsupported then writing MRC for it will >be a very long and difficult process. If the chipset is supported then adding >mainboard support may be a relatively simple task that not sufficient for GSoC. Do we need to write MRC by ourselves in coreboot? Isn't MRC code supported by Intel? >If you have experience with UEFI, perhaps you can implement features that are >missing in our Tianocore support: http://www.coreboot.org/TianoCore . Implementing UEFI CBFS driver and GOP driver are very clear goal. questions: I don't know whether coreboot or some payload implement common flash interface for flash programming software. If not, why? >https://trello.com/b/pEdlwYTb/tiano-payload It seems that Tiano payload is a very activity project. I think I can try my best to implement one feature or twp for the project! Like use a seperate Fv in CBFS as Fault Tolerant Variable Storage Look forward to your kind advice! On 3/20/14, David Hendricks wrote: > Hi Jinyi, > Can you provide more details about your work as a BIOS engineer? > > As Vladimir said, if the chipset is unsupported then writing MRC for it > will be a very long and difficult process. If the chipset is supported then > adding mainboard support may be a relatively simple task that not > sufficient for GSoC. > > If you have experience with UEFI, perhaps you can implement features that > are missing in our Tianocore support: http://www.coreboot.org/TianoCore . > > > On Wed, Mar 19, 2014 at 6:06 AM, Allen Yan wrote: > >> Hi, >> I am Jinyi Yan , a second year PhD candidate from Shanghai Institute >> of Micro-system and Information Technology, Chinese Academy of >> Sciences. I used to be a mainboard BIOS engineer in ASUS Technology >> Suzhou Co., Ltd for about two years (2007.7~2009.2). My major now is >> optoelectronics. But I have a lot of fun while programming, in my >> heart the working experience of being a BIOS engineer is still very >> exciting. >> I think GsoC is a nice platform for me to participate the open source >> community. When I search the GsoC projects and organizations, the >> coreboot and flashrom projects are definitely the right choices for >> me. I have a spare ASUS P5KPL PC at my hand, but the chipset is not in >> the support list of coreboot project. >> As Stefan Tauner's suggestion, maybe porting coreboot to new mainboard >> or implementing advanced coreboot features on exsiting mainboards are >> nice too. >> Now I'm not very familiar with the program structure of coreboot, so I >> expect your guidence and hope to contribute for coreboot and flashrom >> even if my application is not accpeted. >> Thanks! Look forward to your kind advice! >> Regards, >> Jinyi Yan >> >> -- >> coreboot mailing list: coreboot@coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot >> > > > > -- > David Hendricks (dhendrix) > Systems Software Engineer, Google Inc. > -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
On 20.03.2014 11:25, Allen Yan wrote: > Hi, David, >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). > Do I understand it correctly, that you've had access to proprietary BIOS code? If so which papers did you sign and under what license did you get them? Depending on the answers it may partially or fully disqualify you from contributing to coreboot. > Interesting experience, but memories will fade! Details can't be > remembered clearly. > >> As Vladimir said, if the chipset is unsupported then writing MRC for it will >> be a very long and difficult process. If the chipset is supported then >> adding mainboard support may be a relatively simple task that not sufficient >> for GSoC. > Do we need to write MRC by ourselves in coreboot? Isn't MRC code > supported by Intel? > >> If you have experience with UEFI, perhaps you can implement features that >> are missing in our Tianocore support: http://www.coreboot.org/TianoCore . > > Implementing UEFI CBFS driver and GOP driver are very clear goal. > questions: I don't know whether coreboot or some payload implement > common flash interface for flash programming software. If not, why? > >> https://trello.com/b/pEdlwYTb/tiano-payload > It seems that Tiano payload is a very activity project. I think I can > try my best to implement one feature or twp for the project! Like use > a seperate Fv in CBFS as Fault Tolerant Variable Storage > > Look forward to your kind advice! > > > > On 3/20/14, David Hendricks wrote: >> Hi Jinyi, >> Can you provide more details about your work as a BIOS engineer? >> >> As Vladimir said, if the chipset is unsupported then writing MRC for it >> will be a very long and difficult process. If the chipset is supported then >> adding mainboard support may be a relatively simple task that not >> sufficient for GSoC. >> >> If you have experience with UEFI, perhaps you can implement features that >> are missing in our Tianocore support: http://www.coreboot.org/TianoCore . >> >> >> On Wed, Mar 19, 2014 at 6:06 AM, Allen Yan wrote: >> >>> Hi, >>> I am Jinyi Yan , a second year PhD candidate from Shanghai Institute >>> of Micro-system and Information Technology, Chinese Academy of >>> Sciences. I used to be a mainboard BIOS engineer in ASUS Technology >>> Suzhou Co., Ltd for about two years (2007.7~2009.2). My major now is >>> optoelectronics. But I have a lot of fun while programming, in my >>> heart the working experience of being a BIOS engineer is still very >>> exciting. >>> I think GsoC is a nice platform for me to participate the open source >>> community. When I search the GsoC projects and organizations, the >>> coreboot and flashrom projects are definitely the right choices for >>> me. I have a spare ASUS P5KPL PC at my hand, but the chipset is not in >>> the support list of coreboot project. >>> As Stefan Tauner's suggestion, maybe porting coreboot to new mainboard >>> or implementing advanced coreboot features on exsiting mainboards are >>> nice too. >>> Now I'm not very familiar with the program structure of coreboot, so I >>> expect your guidence and hope to contribute for coreboot and flashrom >>> even if my application is not accpeted. >>> Thanks! Look forward to your kind advice! >>> Regards, >>> Jinyi Yan >>> >>> -- >>> coreboot mailing list: coreboot@coreboot.org >>> http://www.coreboot.org/mailman/listinfo/coreboot >>> >> >> >> >> -- >> David Hendricks (dhendrix) >> Systems Software Engineer, Google Inc. >> > signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
Vladimir 'φ-coder/phcoder' Serbinenko wrote: > On 20.03.2014 11:25, Allen Yan wrote: > > Hi, David, > >When at AsusTek Suzhou, my work is mainly responsible for bios > > porting and fixing bug. > > Do I understand it correctly, that you've had access to proprietary BIOS > code? If so which papers did you sign and under what license did you get > them? Vladimir, I would assume that Jinyi signed a standard employment agreement. Employment agreements contain a non-disclure clause which covers all non-public information which the employer has received from suppliers and customers. > Depending on the answers it may partially or fully disqualify you > from contributing to coreboot. I disagree, and I think your tone is rude. Please be supportive of GSoC candidates who are showing an interest in coreboot, especially candidates such as Jinyi who can obviously contribute with significant relevant experience from the firmware domain. Employment agreements have clauses about not working on competing products. coreboot in summer of 2014 does not compete with BIOS for commercial mainboards in 2008. I am obviously not a lawyer but I can not see a problem here. //Peter pgpXZW8VXntsp.pgp Description: PGP signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
On 20.03.2014 13:45, Peter Stuge wrote: > Vladimir 'φ-coder/phcoder' Serbinenko wrote: >> On 20.03.2014 11:25, Allen Yan wrote: >>> Hi, David, >>>When at AsusTek Suzhou, my work is mainly responsible for bios >>> porting and fixing bug. >> >> Do I understand it correctly, that you've had access to proprietary BIOS >> code? If so which papers did you sign and under what license did you get >> them? > > Vladimir, I would assume that Jinyi signed a standard employment > agreement. Employment agreements contain a non-disclure clause > which covers all non-public information which the employer has > received from suppliers and customers. > > >> Depending on the answers it may partially or fully disqualify you >> from contributing to coreboot. > > I disagree, and I think your tone is rude. > I didn't mean to be rude. I apologise if it sounded like this. I'm somewhat pessimistic generally and a mathematician and so I look for problems first. > Please be supportive of GSoC candidates who are showing an interest > in coreboot, especially candidates such as Jinyi who can obviously > contribute with significant relevant experience from the firmware > domain. > I didn't mean to be dismissive, when I discuss problems it's to prevent and fix them. > Employment agreements have clauses about not working on competing > products. coreboot in summer of 2014 does not compete with BIOS for > commercial mainboards in 2008. I am obviously not a lawyer but I > can not see a problem here. > They sometimes also have draconian non-disclosure parts. We can't know until such issues are checked by someone qualified. I'm not. Does coreboot has some kind of experts it can use for those cases? On GNU projects I'd refer to copyright clerk who would in turn refer further if needed. > > //Peter > > > signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
Hi Allen, There's less than 24 hours left to submit proposals. If you want to do this, I suggest you get your proposal up before the deadline (March 21st). While I do not know the details of your employment contract with ASUS, I find it irrelevant for the purpose of you working on coreboot. Does it prevent you from submitting a proposal? Most likely not. Come hang out with us on IRC (#coreboot @ freenode). You can brainstorm, discuss ideas with us, get a better idea of what you'll get to work on, etc... I cannot stress the importance of being in constant contact with the community . Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
put in the proposal. We'll deal with other issues later. The guy that gave us the first real CAR implementation was an intel employee who had NDAs out the ... and it was not an issue. Let's not start putting in roadblocks. We're not lawyers. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
On Thursday, March 20, 2014 08:30:58 AM ron minnich wrote: > in the proposal. We'll deal with other issues later. > > The guy that gave us the first real CAR implementation was an intel > employee who had NDAs out the ... > > > and it was not an issue. > > Let's not start putting in roadblocks. We're not lawyers. > BTW, has any manufacturer been hostile in the past in any way relating to coreboot supporting hardware they would rather have kept closed/secret? Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
On Thu, Mar 20, 2014 at 8:36 AM, mrnuke wrote: > BTW, has any manufacturer been hostile in the past in any way relating to > coreboot supporting hardware they would rather have kept closed/secret? ha ha ha ha ha ha ha ha ha ha ha haha ha ha ha ha haha ha ha ha ha haha ha ha ha ha haha ha ha ha ha haha ha ha ha ha ha you're killing me. How about, "all of them" at one time or another. One vendor had an internal memo stating that anyone who talked to me (my name was on it) about LinuxBIOS would be terminated. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
On Thursday, March 20, 2014 09:08:18 AM ron minnich wrote: > On Thu, Mar 20, 2014 at 8:36 AM, mrnuke wrote: > > BTW, has any manufacturer been hostile in the past in any way relating to > > coreboot supporting hardware they would rather have kept closed/secret? > > ha ha ha ha ha ha ha ha ha ha ha haha ha ha ha ha haha ha ha ha ha > haha ha ha ha ha haha ha ha ha ha haha ha ha ha ha ha > > you're killing me. > > How about, "all of them" at one time or another. One vendor had an > internal memo stating that anyone who talked to me (my name was on it) > about LinuxBIOS would be terminated. > You're popular it seems. How about within this decade (last 4 years) ? Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
On Thu, Mar 20, 2014 at 9:33 AM, mrnuke wrote: > On Thursday, March 20, 2014 09:08:18 AM ron minnich wrote: >> On Thu, Mar 20, 2014 at 8:36 AM, mrnuke wrote: >> > BTW, has any manufacturer been hostile in the past in any way relating to >> > coreboot supporting hardware they would rather have kept closed/secret? >> >> ha ha ha ha ha ha ha ha ha ha ha haha ha ha ha ha haha ha ha ha ha >> haha ha ha ha ha haha ha ha ha ha haha ha ha ha ha ha >> >> you're killing me. >> >> How about, "all of them" at one time or another. One vendor had an >> internal memo stating that anyone who talked to me (my name was on it) >> about LinuxBIOS would be terminated. >> > You're popular it seems. How about within this decade (last 4 years) ? > > Alex it's a continuing problem that I doubt will ever be fully resolved, since as you may have noticed there is no QPI support yet. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
On Thursday, March 20, 2014 09:08:18 AM ron minnich wrote: > On Thu, Mar 20, 2014 at 8:36 AM, mrnuke wrote: > > BTW, has any manufacturer been hostile in the past in any way relating to > > coreboot supporting hardware they would rather have kept closed/secret? > > ha ha ha ha ha ha ha ha ha ha ha haha ha ha ha ha haha ha ha ha ha > haha ha ha ha ha haha ha ha ha ha haha ha ha ha ha ha > > you're killing me. > > How about, "all of them" at one time or another. One vendor had an > internal memo stating that anyone who talked to me (my name was on it) > about LinuxBIOS would be terminated. > That seems like a slap on the wrist. Terminating employees rather than taking legal action against coreboot also suggests they might feel they have no legal standing against coreboot supporting more stuff. I wonder if there's any legal action hardware vendors could take against ODM/OEM vendors who distribute and/or contribute to coreboot. And I don't mean BS lawsuits hw vendors know they'll lose. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
On Thursday, March 20, 2014 09:36:06 AM ron minnich wrote: > >> How about, "all of them" at one time or another. One vendor had an > >> internal memo stating that anyone who talked to me (my name was on it) > >> about LinuxBIOS would be terminated. > > > > You're popular it seems. How about within this decade (last 4 years) ? > > > > Alex > > it's a continuing problem that I doubt will ever be fully resolved, > since as you may have noticed there is no QPI support yet. > Not sure I care much about Intel nowadays. They are already part of the "fellatio_admin" group in my books. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
On Thu, Mar 20, 2014 at 9:41 AM, mrnuke wrote: > Not sure I care much about Intel nowadays. They are already part of the > "fellatio_admin" group in my books. No offense intended, but your cares in this case are of no real importance compared to the cares of the companies that are shipping O(1M) systems a year. Anyway, muting this thread. Jinyi Yan, please submit your proposal. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
On Fri, 21 Mar 2014 23:23:51 +0800 Allen Yan wrote: > Hi, everyone, >I've sent a preliminary proposal about "Tianocore as coreboot payload". > https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/jinyiyan/5629499534213120 > I'd like to get more feedback about the goal and the test environment. Does not seem to be public. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
Oh, sorry, incorrect address! http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/jinyiyan/5629499534213120 On 3/22/14, Stefan Tauner wrote: > On Fri, 21 Mar 2014 23:23:51 +0800 > Allen Yan wrote: > >> Hi, everyone, >>I've sent a preliminary proposal about "Tianocore as coreboot payload". >> https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/jinyiyan/5629499534213120 >> I'd like to get more feedback about the goal and the test environment. > > Does not seem to be public. > > -- > Kind regards/Mit freundlichen Grüßen, Stefan Tauner > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GSoC-2014 Coreboot project
Allen Yan [mailto:lex...@gmail.com] wrote: ]Oh, sorry, incorrect address! ]http://www.google-]melange.com/gsoc/proposal/public/google/gsoc2014/jinyiyan/5629499534213120 ] ]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: lex...@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 expe
Re: [coreboot] GSoC-2014 Coreboot project
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: > 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. Could be done by importing flashrom, putting that behind the FVB protocol. That makes things GPL but who cares? > 2) 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 signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot