6 ms·

Two points: a short question and a longer theory about why only 16KB. The question: how viable is an open-source, publicly-auditable secure boot implementation

by i336_ 10y ago

Two points: a short question and a longer theory about why only 16KB. The question: how viable is an open-source, publicly-auditable secure boot implementation? Not TPM theater or whatever, but a hardened hardware configuration that could be used to implement truly verifiable boot. (If anyone from RISC-V is reading this, I think there is a very noteworthy amount of money in building a truly securely bootable reference design. Hopefully lots of people have already told you that.) -- Next, regarding why only 16KB RAM... I'm very interested in the potential of open source ISA, but admittedly completely ignorant about chip design. With this in mind, I have a theory that the manufacturers deliberately provided a ridiculously low amount of RAM in order to make it impossible[1] to run Linux on it and so keep it out of the mass market. Considering the CPU is full 320MHz I don't think this is because they have some other product up their sleeve. Rather, looking at the fact that this is the first marketed product they have available that's an actual real chip (!!), I would expect that either the chip itself and/or the chipset likely has bugs in it. They've gone through many internal revisions, and now they feel comfortable with putting the chipset out there for public testing to get bugreports from the field. My thinking is that applications that will play nice with 16KB of RAM will stress the CPU out significantly less than full Linux would, similarly to how doing basic tasks on a faulty x86 PC may work for years but compiling GCC will find broken bits in RAM sooner or later. There's also the fact that such projects are also generally quieter as a whole than the thundering herd of people wanting to run Linux on things. Don't forget, RISC-V has been nothing more than a bunch of VHDL for years, running on "perfect" FPGAs that don't require you to think about low-level electrical niggles and whatnot. If I'm understanding correctly, this is the first time a real RISC-V chip run has been done (?) and made available to the market. Considering the success of ARM (or, more generically, the market sector of "little PCBs that run Linux"), RISC-V needs to stay competitive and attractive - and full Linux that constantly oopses in mm.c will make RISC-V look real bad real fast. I definitely want the ISA to thrive, and if my assumptions are correct capping the RAM makes an inelegant-yet-elegant sort of sense. I expect RISC-V will be running Linux on real fabbed chips within the next two years. [1]: Well, practically impossible. If you don't mind 300KB/s RAM (yes, KB/s, not MB/s) there's always http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20on%208bit http://dmitry.gr/index.php?r=05.Projects&proj=07.%20Linux%20... :D

kobeya 10y ago
SiFive is working on two chips. This one is basically an atmel competitor. They are also working on a workstation class many core chip.
- i336_ 10y ago
  Oh, I see. That makes sense. I'm definitely looking forward to seeing the many-core design!
pjc50 10y ago
The whole of your second point is ridiculous conspiracy theory. It is perfectly reasonable to do enough formal verification to ensure that your chip works first time. Linux is not going to "stress" your chip more. And nobody deliberately cuts out a viable market sector unless they've got another product to put in it. On-chip SRAM is just expensive in terms of area. It's comparable to what you get on Cortex-M devices. There are no chips with enough onboard SRAM to run Linux. You can't really run Linux without an external DRAM interface, and then you have to find somewhere to put the DRAM. People keep forgetting about this on the Pi because the DRAM is stuck on top of the SoC package. Sure, maybe if this is a success they'll pay the licensing fees for a DDR3 interface + MMU, or write one themselves. I think you'd also want at least 600MHz for Linux, 320 is kind of slow these days.
- i336_ 10y ago
  > The whole of your second point is ridiculous conspiracy theory. Theory, yes. Conspiracy theory, emphatically not, sorry for the misunderstanding. I have no ill will towards the RISC-V ISA and no disagreement with SiFive's operations. Like others here I was just trying to figure out the huge disparity between the CPU clock speed and the onboard memory, in my case with sorely insufficient understanding of the field. > It is perfectly reasonable to do enough formal verification to ensure that your chip works first time. Oh, okay then. That's really amazing, I didn't know that :) > Linux is not going to "stress" your chip more. Like I said, I'm a bit ignorant here. I was just thinking along the lines of how eg an i7 with faulty L2 cache could be re-designated as an i5, but in this case they're not sure what's faulty, etc. There's also the fact that CPUs do have errata... (?) > And nobody deliberately cuts out a viable market sector unless they've got another product to put in it. Absolutely! What I was saying was that I theorize that this is a first-run design and that another chip was going to follow up. I'm increasingly confident I'm wrong about exactly why (eg, now I understand about the RAM problem) > On-chip SRAM is just expensive in terms of area. It's comparable to what you get on Cortex-M devices. There are no chips with enough onboard SRAM to run Linux. You can't really run Linux without an external DRAM interface, and then you have to find somewhere to put the DRAM. I see. Mmm :/ > People keep forgetting about this on the Pi because the DRAM is stuck on top of the SoC package. Has a look at a picture oh wow so it is, that's amazing. > Sure, maybe if this is a success they'll pay the licensing fees for a DDR3 interface + MMU, or write one themselves. Hopefully this run is an incentivisation to get some support for that! > I think you'd also want at least 600MHz for Linux, 320 is kind of slow these days. Hmm, that's quite true, yeah. (It's kind of sad how speed-hungry the kernel is nowadays - I have a 32MHz PDA with an OS (EPOC, precursor of Symbian) that draws draggable windows on a little monochrome touchscreen LCD, I can fling the windows around faster than the crystals can update :D) I would absolutely buy a 320MHz Linux device with an open-source secure boot story though. Text communication doesn't need a snappy CPU.

by i336_ 10y ago

kobeya 10y ago

SiFive is working on two chips. This one is basically an atmel competitor. They are also working on a workstation class many core chip.

i336_ 10y ago
Oh, I see. That makes sense. I'm definitely looking forward to seeing the many-core design!

pjc50 10y ago

The whole of your second point is ridiculous conspiracy theory. It is perfectly reasonable to do enough formal verification to ensure that your chip works first time. Linux is not going to "stress" your chip more. And nobody deliberately cuts out a viable market sector unless they've got another product to put in it. On-chip SRAM is just expensive in terms of area. It's comparable to what you get on Cortex-M devices. There are no chips with enough onboard SRAM to run Linux. You can't really run Linux without an external DRAM interface, and then you have to find somewhere to put the DRAM. People keep forgetting about this on the Pi because the DRAM is stuck on top of the SoC package. Sure, maybe if this is a success they'll pay the licensing fees for a DDR3 interface + MMU, or write one themselves. I think you'd also want at least 600MHz for Linux, 320 is kind of slow these days.

i336_ 10y ago
> The whole of your second point is ridiculous conspiracy theory. Theory, yes. Conspiracy theory, emphatically not, sorry for the misunderstanding. I have no ill will towards the RISC-V ISA and no disagreement with SiFive's operations. Like others here I was just trying to figure out the huge disparity between the CPU clock speed and the onboard memory, in my case with sorely insufficient understanding of the field. > It is perfectly reasonable to do enough formal verification to ensure that your chip works first time. Oh, okay then. That's really amazing, I didn't know that :) > Linux is not going to "stress" your chip more. Like I said, I'm a bit ignorant here. I was just thinking along the lines of how eg an i7 with faulty L2 cache could be re-designated as an i5, but in this case they're not sure what's faulty, etc. There's also the fact that CPUs do have errata... (?) > And nobody deliberately cuts out a viable market sector unless they've got another product to put in it. Absolutely! What I was saying was that I theorize that this is a first-run design and that another chip was going to follow up. I'm increasingly confident I'm wrong about exactly why (eg, now I understand about the RAM problem) > On-chip SRAM is just expensive in terms of area. It's comparable to what you get on Cortex-M devices. There are no chips with enough onboard SRAM to run Linux. You can't really run Linux without an external DRAM interface, and then you have to find somewhere to put the DRAM. I see. Mmm :/ > People keep forgetting about this on the Pi because the DRAM is stuck on top of the SoC package. Has a look at a picture oh wow so it is, that's amazing. > Sure, maybe if this is a success they'll pay the licensing fees for a DDR3 interface + MMU, or write one themselves. Hopefully this run is an incentivisation to get some support for that! > I think you'd also want at least 600MHz for Linux, 320 is kind of slow these days. Hmm, that's quite true, yeah. (It's kind of sad how speed-hungry the kernel is nowadays - I have a 32MHz PDA with an OS (EPOC, precursor of Symbian) that draws draggable windows on a little monochrome touchscreen LCD, I can fling the windows around faster than the crystals can update :D) I would absolutely buy a 320MHz Linux device with an open-source secure boot story though. Text communication doesn't need a snappy CPU.