On 14.02.2015 03:25, Alexandru Gagniuc wrote:
On Saturday, February 14, 2015 02:50:15 AM Alexander
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
- 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.