[lowrisc-dev] minion core 0.4 boot procedure

Luke Kenneth Casson Leighton lkcl at lkcl.net
Mon Dec 18 13:02:38 GMT 2017


On Mon, Dec 18, 2017 at 12:40 PM, Jonathan Neuschäfer
<j.neuschaefer at gmx.net> wrote:

>> *entire embedded/smart-style processor* such as the Allwinner A20, A64
>> or an Ingenic jz4775 SoC, is considered "pocket change" because of the
>> insane cost of x86 and amd processors.  [i'm looking to do a THREE
>> dollar RISC-V 64-bit SoC].
>
> I don't know the unit price here, but coreboot runs on and is shipped
> with some ARM SoCs from Rockchip/Nvidia/Mediatek[4] because it's used in
> Chromebooks[5].

 jz4775: $3.  A20 (plus PMIC): $4.50.  A64 (plus PMIC): $4.
 16mbyte quad SPI NOR off of digikey: $1.60.... ok... not so bad as i thought.

> Coreboot on RISC-V even gets a conference talk every once in a while :)

 :)

> That's good, because RAM init can be quite board specific.

 i've never dealt with anything other than SoCs, so i'm used to code
(in u-boot) which probes the DDR3 interface, does all the
initialisation(s), cranks the memory up to a 200mhz (or other set bus
speed) and off it goes.  some of the init stuff i've seen even does
speed grading testing.

 ... and intel's been keeping their speed-testing code "secret"
because they think it's unique and gives them some kind of
propriettary advantage... *sigh*...

anyway the vendors do quite extensive testing and reporting with
various different RAM ICs so that you don't have to.


>>  so you could *choose* not to initialise the DDR3 controller, by
>> simply flipping a config option in u-boot, or instead of u-boot SPL
>> (or coreboot once it has SPL mode), just putting a debug / test
>> program onto the SD card.
>
> I'm not sure what SPL mode entails exactly,

 basically a massive batch of #ifdefs that cut out 99.5% of u-boot,
leaving the *absolute* bare minimum: init PLLs, init CLKs, init DDR3,
init SPI or NAND or MMC, load, execute, done. *nothing* else.

> but coreboot can load U-Boot
> as a payload[2] on other architectures (it has not been tested on RISC-V).

 is there a config option to cut the compiled target down to an (appx)
sub 16k raw binary?

>>  i think i start to see what you mean.  you'd want to upload as much
>> of a "debugging / test" program as you could, so as to be able to
>> investigate.  yes that makes sense.
>
> Only somewhat related: To ease early debugging, there should not be too
> many configuration steps (PLL setup, clock gating, power gating,
> DMA-able RAM) in the way of having a UART.

 that's pretty much the definition of a SPI u-boot executable :)

> And whatever is done, don't
> go the x86 way of relying on EHCI debug[3]!

  :)  oh is that the one where you can hack into any x86 system just
by plugging in a USB cable?

l.



More information about the lowrisc-dev mailing list