SiFive To Release Code As Open-Source For Fully Initializing The RISC-V Board

[phoronix]

Phoronix: SiFive To Release Code As Open-Source For Fully Initializing The RISC-V Board

Last week we noted how some of the code to boot the RISC-V SiFive HiFive Unleashed development board was closed-source. That upset some in the Coreboot community with hoping for a more open development board built around the RISC-V open-source processor ISA. The good news is that SiFive will soon be releasing the necessary code for initialization as open-source...

http://www.phoronix.com/scan.php?page=news_item&px=SiFive-Open-Boot-Code-Coming

[willmore]

This is realy good news. Well done SiFive folks! I wonder if this IP is similar to any of that used in other SoCs out there such that they could benefit from it--either by studying how it works in general or more specifically in how different registers get set.

[starshipeleven]

Heh, I guess the discussion with their IP providers went on like "look, you can opensource this or they ARE going to reverse-engineer it, choose your poison".

[starshipeleven]

yes right sounds good... maybe AMD need some teaching to ?

Nah they are safe. Reverse-engineering the board initialization blob and the ram controller on the SiFIve is doable, reverse-engineering AMD/Intel/NVIDIA stuff is way too complex. Also there is much more at stake than just some dumb thing like a RAM controller IP, so anyone that tries gets sued (see Purism vs Intel ME) unless they are russian or in a similar country that does not give a fuck.

[bridgman]

Heh, I guess the discussion with their IP providers went on like "look, you can opensource this or they ARE going to reverse-engineer it, choose your poison".

I doubt that... companies don't respond well to threats.

It's much more likely that SiFive just asked nicely and made a good case for opening up the code.

It's all a function of associated costs / risks / benefits. We used to deliver the comparable code in open source as part of AGESA but stopped because at the time the costs and additional time-to-market were something we could not continue to carry.

[dibal]

some dumb thing like a RAM controller IP

I don't think that this is dump stuff, PHYs from today are highly sophisticated analog stuff.

[starshipeleven]

I doubt that... companies don't respond well to threats.

It's not a threat, it's a warning and a way to get out of the situation with a PR benefit to offset the inevitable (minor) loss of IP.

I did exaggerate it in that post, but I think that's something you could really use to get some kind of agreement where you can buy the rights to opensource that stuff.

It's much more likely that SiFive just asked nicely and made a good case for opening up the code.

It's likely that the firmware in question weren't terribly hot IP to begin with, some more money was provided (as SiFive also cares about their own PR and on Coreboot mailing list they weren't happy at all to learn about blobs), and contracts were signed.

Really, there is like sub-zero reasons for the IP provider to even care about opensourcing their firmware.

It could theoretically lead to more sales to other open-hardware designer companies (which is a great thing imho, this would be probably the only RAM controller with open firmware they can embed in a new design), but that's a market that does not even exist yet so it would take a good seller to convince them of this "investment".

[starshipeleven]

I don't think that this is dump stuff, PHYs from today are highly sophisticated analog stuff.

The point I was making remains valid.
A RAM controller formware IP is MUCH less valuable than Intel FSP or ME firmwares (or AMD equivalents). Intel was ready to sue Purism over reverse-engineering the ME.

[RSpliet]

I don't think that this is dump stuff, PHYs from today are highly sophisticated analog stuff.

They are indeed, and I'm sure that parties like Cadence, TSMC, GloFo, Intel etc. have secrets in their production that they'd rather not share for competition reasons. The question however is whether there are any secrets in the hw/sw interface... We don't have to understand the exact implementation of a PLL (the "analogue" secret sauce) to understand how to perform a register write that sets the clock multiplier and divider. I personally suspect there are hardly any secrets in this interface worth hiding.

[bridgman]

Heh, I guess the discussion with their IP providers went on like "look, you can opensource this or they ARE going to reverse-engineer it, choose your poison".

It's not a threat, it's a warning

Fair point - I interpreted "they" in your post as referring to SiFive themselves (which would be a threat), but I gather you intended "they" to refer to "other people who are not SiFive or acting on SiFive's behalf", in which case I agree that would be a warning.

Either way it would almost definitely be interpreted as a threat by the company's legal department, and that is what would shape the response.