I think internally this is a huge [1] experiment for Intel. They're saying "is doing the work to support the low-volume 'little guy' going to do anything for our high-volume sales?"

I have a feeling were it up to the people leading the project, the init code would be made available. However Intel as a company is only going to take so much risk in support of this experiment. I have a feeling that init code and firmware for softloaded peripherals will be "business as usual" for quite a while.

That said, the squeaky wheel gets the grease. If this is successful and if customers are very vocal about not wanting "half-assed" open systems, it might eventually get there.

1: Actually, in terms of resources I'm sure it's tiny. In terms of culture on the other hand...

I'm involved in the open source firmware struggle with Intel for a number of years now. There are Intel customers with solid business cases, but it actually got worse in the last few years.

Can you say more? What's made it worse recently? I was witness to some struggle between GumStix and Intel/Marvell back around when Marvell bought the XScale processor line, but I've been out of touch with Intel on this issue since then. However I've seen countless peripheral silicon manufacturers maintain strangleholds on their softloaded firmware... Though with things like wireless chipsets and DSP algorithms, it's arguable there's real IP there worth protecting.

Yea, I wish they could release their entire BIOS Writer Guide including MSRs used for cache as RAM for example.

I don't think that particular part changed much over the years, and it's also relatively easy to figure out with SerialICE (www.serialice.com), since CAR is one of the first things to happen these days.

Since Intel wants everyone to use their code (preferably in binary form), I'm not sure how useful the BIOS Writer's Guide still is. Probably just a guide on how to integrate their code into whatever you're doing yourself.