[coreboot] GSOC 2015 Preperations

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Sat Feb 14 17:56:23 CET 2015


On 14.02.2015 03:25, Alexandru Gagniuc wrote:
> On Saturday, February 14, 2015 02:50:15 AM Alexander Couzens wrote:
>> I would like to attend as a student this year.
>> I'm open for most of the ideas at the page.
>> Here are some of my ideas.
>>
>> - porting new mainboards (hp micro n54L and x121e atm)
>> - porting new arm platforms
>> - refactoring amd code
>> - create an opensource firmware for some Thinkpad (H8S based)
>> - building a basic testing system (looking for a x60 or other
>> supported_board)
>> - add usb debug support to SerialICE
> Porting new boards is of limited value.

Indeed. Especially when those "new" boards are already 2-3 years off the
market. In that case it would only make sense if they still have a
really large user base, and AFAICS both your suggestions are in areas
where either the user base regularly changes hardware (X121e) or is
reluctant to touch something that's expected to run 24/7 (HP Micro N54L).


> New ARM platforms is definitely an interesting topic. Although you have to 
> consider whether your platform of choice can work blob-free, and whether or 
> not there is already a uboot port for it.

Especially in the ARM case it also depends on whether someone believes
the student to realistically be able to bring up a platform without
having the mentor figure out all the hard stuff.


> Refactoring code seems to have been a popular GSoC theme since I've been doing 
> coreboot. Personally, and I will not be part of the decision making, I think 
> this is of limited value when that source code works. You see, coreboot is 
> nowadays being bombarded from all directions with binary-only components.

You will face resistance from two camps: First camp doesn't see a
benefit in the nth refactoring, second camp believes most refactoring
will make merging vendor code harder. IMO a refactoring is OK if it only
impacts binary-only vendor code, but others will disagree with me.


> I think that you can do a great deal more good by working on eliminating some of 
> these blobs. Though tread carefully if you choose this path... reverse 
> engineering is not a valid project for GSoC, so RE should not be part of your 
> proposal or project.

IMO RE and reimplementation could be done in one proposal, but please
note that it all depends on your local legal landscape whether you want
to go all the way to a Chinese Wall type of reverse engineering or not.
That said, I believe that reverse engineering is one of the most
valuable activities in a time where binary blobs crop up everywhere.


> And this point is where you've really gotten my attention. It's gold. Pure 
> gold. Having a free software implementation of H8 firmware is a worthy goal in 
> itself. Although there's the argument to be made that there already is such a 
> thing in ChromeEC, your should stress the counterpoint that the EC is not 
> something that can just be replaced, and the mere popularity of the H8 makes 
> it a great platform to target.

Doesn't Google have some open source code for H8-based ECs as well, not
just their own ChromeEC?


> Another amazing subject that I would suggest you consider is creating a free 
> replacement for the SMU firmware in AMD chipsets. Talk to ruik about it. He 
> may be able to tell you more. Regarding AMD chips up to fam16 at least, this 
> is the final frontier.


AFAIK the SMU firmware is not enforcing any restrictions on coreboot or
the platform, and thus I'd consider this a fun project, but without real
benefits for coreboot.

Regards,
Carl-Daniel




More information about the coreboot mailing list