[coreboot] Potential development funding.

[Patrick Georgi]

Am 04.06.2012 14:42, schrieb mailinglists:
> 1.      What do you all think the requirements will be for replacing UEFI on 
> future mobos.  Will it likely be a case of switching out the bios chip or just 
> flashing it?
We generally reuse the chips. If you're doing business, you should be
able to afford an external flasher, so getting rid of the original BIOS
is no problem, even if vendor BIOS locks down the chip on boot.

Some chip types are easier to flash externally than others, but that's
from a hobbyist perspective. As a business, investing some money in the
right adapter for a large number of boards isn't too bad, it's just hard
to justify spending $50 (to pick some upper bound) on a single-use item
when it's just a hobby.

> 2.      What % of flashes resulted in bricked mobos? Do most new boards come 
> with a backup chip which can restore life after a failure? 
With external flashing you can recover by just writing again. "bricked"
means wrong content and thus unable to boot, not destroyed chip (usually
- I've seen the latter case, but it's very rare).

> 3.      Can anyone reccomend a possible target ivy bridge or Trinity itx mobo 
> for coreboot development?  Perhaps one that's already being worked on?
As yet, Trinity is only released for notebooks, at least that's what I
gathered from the tech media. Desktop and server Trinity are scheduled
for summer and fall releases (AFAIK).

As for Ivybridge, please note that it requires a couple of binary-only
components (beyond those we usually need, see below): RAM init is done
with the Intel reference code, and to turn on the system in the first
place, the Management Engine (some embedded controller in the chipset)
requires a binary-only component as well.

It's remotely feasible to replace the RAM init with source (multimonth
effort, after obtaining access to the documentation), but the ME code
will remain a requirement (if only because it's said to be signed by
Intel, so replacing it requires cracking their signature scheme - good
luck).

> 4.      If we can identify a good itx mobo for the desktop line-up,  would 
> someone here be able to asses how much time a fairly full featured and 
> reliable implementation of coreboot would take to develop?
> 
>         note: to me "fairly full featured would be to have all the 
> fundamentals  up and avaliable for the OS to pick up, such as pci-e usb 3.0, 
> hdmi, sata 3, wifi, and working reliably.
This depends (among other things) on the kind of OS support you desire.
OSS systems are generally more forgiving for incomplete configuration
than Windows - but with "FOSS-only computers" Windows might not be a
priority.

> 5.      Is there any special requirement for getting amd/nvidia gfx cards 
> working with coreboot?
Minor hacks might be necessary to get the IGD/GFX switch to work right.
On systems with integrated graphics we generally expect IGD to manage
the primary display.
Details on that vary by chipset and/or vendor.

> 6.      Which hardware have you found to be the simplist to fully implement 
> coreboot on, and which hardware (if any) should be considered a no go? 
nVidia chipsets are no-go (there was a lucky strike once that gave us
the nVidia support we have - I don't expect that to happen again). Intel
chipsets are complicated. AMD is the best choice for coreboot support
these days.

We don't have to care about many other things (eg. the Wifi card - we
don't handle Wifi, we just have to make sure the card is found on the bus)

> 8.	What do you think about the viability of a kickstarter campaign to raise 
> development funds.  Has anyone tried this yet?
Last I heard Kickstarter has a backlog of several thousand projects.

Kickstarter seems to be first and foremost a social media popularity
contest at the moment, for which coreboot is probably not a fancy enough
topic. I'd assume the same for "FOSS Hardware", but feel free to try, if
you feel like it.

Make clear that you're not collecting funds for the coreboot project -
our situation is that we can't accept donations of any kind (nor take
money with any other designation).

> I would truely love to distribute computers which run entirely on free 
> software. Unfortunately, I'm no developer so If funding some development is 
> the only way I can achieve this, I will find a way to do it.
"run entirely on free software":
We usually reuse the VGABIOS image delivered by the hardware vendor,
which comes in binary-only form. There are a couple of ways around it,
but they're only appropriate for systems where you control the OS that's
used (eg. not doing VGA init at all and defer things to Linux KMS), or
they're still experimental (see i915tool - it's an attempt to create a
coreboot-level driver from KMS sources).

This means that for a "generic" box you're still bound to the VGABIOS to
some degree (you can't rely on KMS being available in the OS when using
a bootloader menu).


The other aspect is that you generally have an embedded controller on
notebooks (in addition to the management engine on newer Intel
chipsets). It usually runs its own firmware, which is also not availabe
in source form. If you're lucky, it's part of the EC chip as read-only
memory - in this case, you can safely consider it part of the hardware
(even under FSF's strict definition, as far as I understand it).


Regards,
Patrick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20120604/5a50224c/attachment.sig>