[lowrisc-dev] minion core 0.4 boot procedure

Dr Jonathan Kimmitt jrrk2 at cam.ac.uk
Mon Dec 18 08:12:53 GMT 2017


Dear Luke,
  Allow me to defend the design choices if I can, preferably without starting a “my processor is better than your processor” debate. The vast majority of commercial SOCs are ARM based, a company with 30 years+ of propriety instruction set and compiler technology improvement behind them. The majority of this technology was designed when memory was really tight. With this commanding market share it justifies a royalty of up to 5% of average selling price, a significant amount for high volume devices.

Now when we consider LowRISC, the parameters are different, memory is relatively cheap, it’s a 64-bit architecture so offsets are relatively large, compilation technology is preliminary, compressed instructions are not implemented in our version of Rocket, and there is a desire to minimise ROM space to make more room for caches etc. Furthermore SOCs frequently incorporate proprietary peripheral host controllers which make booting easier, these would have to come out of our overall gate count budget, whereas our demonstrator is targeting low end educational FPGA boards. A commercial implementation of our IP might have very different constraints.

Regards,
Jonathan 

Sent from my iPhone

> On 18 Dec 2017, at 07:28, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
> 
> http://www.lowrisc.org/docs/minion-v0.4/overview/
> 
> i notice in that documentation that there is significant difficulty
> experienced in getting the core booted up.  a limit of 60k ROM is
> mentioned, 5mhz card speeds set as a hard-coded limit, older cards not
> supported and so on.
> 
> in commercial SoCs all these problems are solved with a multi-stage
> boot process.  they only require a 16k executable to be loaded off of
> either NAND, eMMC, SPI or MicroSD (the loader itself being executed
> from a boot ROM, which itself can be incredibly small), where the
> first task of that program is: to initialise DDR3 RAM, PLLs and to
> begin executing a *larger* (2nd stage) boot process.
> 
> the sub-16k boot process usually loads u-boot directly into the *DDR3*
> ram then executes that.  usually the sub-16k boot process is actually
> a cut-down version *of* u-boot, called an "SPL loader".
> 
> all of this is extremely well-known, particularly to the developers of
> u-boot who often have to merge proprietary SPL-loaders or write ones
> for various SoCs where the proprietary SoC companies couldn't be
> bothered to respect software licenses... such as the GPL.
> 
> which brings me to the strange conflict going on in my mind: what have
> i missed?  is the minion 0.4 boot process sufficiently different from
> a standard commercial SoC (the A20's eGON bootloader is only 32k in
> size and it *still* does NAND *and* SPI *and* MicroSD *and* eMMC
> booting http://linux-sunxi.org/BROM - that's 60% the size of the ROM
> mentioned at the page above), such that it's not possible to deploy
> the same technique... or was it an oversight on the part of the team
> that they were unaware of this tried-and-tested technique?
> 
> what am i missing?
> 
> tia,
> 
> l.
> 




More information about the lowrisc-dev mailing list