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