Am 04.06.2012 14:42, schrieb mailinglists:
What do you all think the requirements will be for replacing UEFI onfuture 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.
What % of flashes resulted in bricked mobos? Do most new boards comewith 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).
Can anyone reccomend a possible target ivy bridge or Trinity itx mobofor 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).
If we can identify a good itx mobo for the desktop line-up, wouldsomeone 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 thefundamentals 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.
Is there any special requirement for getting amd/nvidia gfx cardsworking 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.
Which hardware have you found to be the simplist to fully implementcoreboot 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)
- 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