[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 because it's used in
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 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!
:) oh is that the one where you can hack into any x86 system just
by plugging in a USB cable?
More information about the lowrisc-dev