[lowrisc-dev] minion core 0.4 boot procedure

Luke Kenneth Casson Leighton lkcl at lkcl.net
Mon Dec 18 07:28:13 GMT 2017


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