Hey there,
Wolfgang Denk wrote:
Multiple implementations of the same feature / multiple solutions for the same problem have never been a bad thing per se.
Not per se, but they have indeed been a bad thing with coreboot in the past.
The coreboot project has always sought cooperation with hardware vendors.
Intel was however not interested, to the point where multiple different efforts to implement coreboot were all independently refused support on the (obviously false) grounds that "nobody else wants what you are asking for."
One could argue that Intel is now more interested, since they make the FSP available and work with coreboot upstream, but I for one think that is far too simplistic.
I understand where you are coming from, because it would be logical also for x86 vendors to enable as many customers as possible to program their silicon, but the trend with x86 is actually strictly the opposite.
For good insight I highly recommend that you read ISBN 9781430265719 "Platform Embedded Security Technology Revealed" by Intel.
You can hopefully see that it's more important to work together on x86 than on platforms where vendors have a different attitude.
So without deeper understanding I disagree with both statemen't - with Peter's, as different projects for the same thing are not necessarily bad
You're absolutely right about the "not neccessarily" part - but coreboot experience is clear - we achieve more quicker when working together.
I can imagine a bunch of other scenarios which use vanilla U-Boot without coreboot at all.
Please share? I guess you know that coreboot explicitly wants to do the bare minimum. U-Boot as payload makes perfect sense to me, because in the end a standalone U-Boot on x86 needs to do most everything that coreboot already does.
I can see no technical reason why x86 must be different from all other architectures where U-Boot boots directly.
Right - but good reasons aren't always technical. ;)
Thanks
//Peter