Re: [coreboot] GSoC-2014 Coreboot project

2014-03-26 Thread Patrick Georgi
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

Re: [coreboot] GSoC-2014 Coreboot project

2014-03-24 Thread Scott Duplichan
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 

[coreboot] GSoC-2014 Coreboot project

2014-03-21 Thread Allen Yan
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.
  Thanks!
  Regards!
Jinyi Yan

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


Re: [coreboot] GSoC-2014 Coreboot project

2014-03-21 Thread Stefan Tauner
On Fri, 21 Mar 2014 23:23:51 +0800
Allen Yan lex...@gmail.com 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

2014-03-20 Thread Allen Yan
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 dhend...@google.com 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 lex...@gmail.com 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

2014-03-20 Thread Vladimir 'φ-coder/phcoder' Serbinenko
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 dhend...@google.com 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 lex...@gmail.com 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

2014-03-20 Thread Peter Stuge
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

2014-03-20 Thread Vladimir 'φ-coder/phcoder' Serbinenko
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

2014-03-20 Thread mrnuke
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...
hint I cannot stress the importance of being in constant contact with the 
community /hint.

Alex

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot


Re: [coreboot] GSoC-2014 Coreboot project

2014-03-20 Thread ron minnich
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

2014-03-20 Thread mrnuke
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

2014-03-20 Thread ron minnich
On Thu, Mar 20, 2014 at 8:36 AM, mrnuke mr.nuke...@gmail.com 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

2014-03-20 Thread mrnuke
On Thursday, March 20, 2014 09:08:18 AM ron minnich wrote:
 On Thu, Mar 20, 2014 at 8:36 AM, mrnuke mr.nuke...@gmail.com 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

2014-03-20 Thread ron minnich
On Thu, Mar 20, 2014 at 9:33 AM, mrnuke mr.nuke...@gmail.com wrote:
 On Thursday, March 20, 2014 09:08:18 AM ron minnich wrote:
 On Thu, Mar 20, 2014 at 8:36 AM, mrnuke mr.nuke...@gmail.com 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

2014-03-20 Thread mrnuke
On Thursday, March 20, 2014 09:08:18 AM ron minnich wrote:
 On Thu, Mar 20, 2014 at 8:36 AM, mrnuke mr.nuke...@gmail.com 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

2014-03-20 Thread mrnuke
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

2014-03-20 Thread ron minnich
On Thu, Mar 20, 2014 at 9:41 AM, mrnuke mr.nuke...@gmail.com 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


[coreboot] GSoC-2014 Coreboot project

2014-03-19 Thread Allen Yan
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


Re: [coreboot] GSoC-2014 Coreboot project

2014-03-19 Thread Vladimir 'φ-coder/phcoder' Serbinenko
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

2014-03-19 Thread ron minnich
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

2014-03-19 Thread Peter Stuge
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

2014-03-19 Thread David Hendricks
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 lex...@gmail.com 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