[libre-riscv-dev] System-Wide Complexity Rant (was store computation unit)

[Luke Kenneth Casson Leighton]

On Wednesday, June 5, 2019, Samuel Falvo II <sam.falvo at gmail.com> wrote:

>
> Getting to the point of configuring SDRAM chips will pose an
> interesting design challenge, but I'll cross that bridge when I get
> there.  For now, I'm quite happy using nothing but static RAM.


 http://linux-sunxi.org/EGON

Follow the trail. Next page is BROM.

BROM looks for SPI, QSPI, SDMMC, ONFI NAND and finally gives up and drops
to USB FEL (front end loader) mode.

It is actually GPL violating source code ripped directly out of uboot SPL
Mode.

Sigh.

BROM loads ONLY one single 16k block from whatever (above) and copies it
into SRAM and executes it.


allwinner created a boot0 that is identical to uboot SPL.

This performs the DRAM init you want.

It also contains yet ANOTHER loader, which this time loads ANOTHER loader,
boot1, however this one can be 1MB in size or beyond.

boot1 contains screen images, a FAT filesystem decoder (you see where this
is going) and it also contains logic for listening to external keys which
can be pressed to select alternative boot options.

If no keys are pressed it loads u-boot (actually at this point, because of
the FAT FS it has loaded a CONFIG file which tells it to load uboot)

Uboot then starts yet ANOTHER loader process, this time its default option
is to load a linux (android) kernel and initramfs, and FINALLY off we go.

Contrary to appearances this approach is quite sane.

In the sunxi community the reverse engineering of the FEL format allowed me
to directly upload uboot SPL into the SRAM, execute it and init the DRAM,
then upload uboot full plus initramfs and even a linux kernel directly into
DRAM, for experimentation.

It was dog slow.

There are good reasons why the allwinner boot process was so many phases.

Still, they could have made uboot SPL 16k the first phase boot, but chose
instead to provide their customers with a much smaller more custom written
process that was managed by a nice pretty Windows only GUI.

Rockchip does something very similar.

Basically all this is down to the fact that the DRAM is utterly dead until
its controller interface is initialised, you are in single core seriously
memory strapped mode, you simply cannot mess about with GUIs or
initialising anything but the absolute most essential of peripherals, PLLs
and GPIO as that absolute top priority is getting DRAM up and loading
another stage in the boot process.

Even once the DRAM is first initialised you STILL have to go through some
checks to get it to run faster, all the things you could not do because
there is just not enough space in only 16k to do that much DRAM
initialisation.

Intel is absolutely no different here, they too are restricted to around 16
to 32k SRAM until the DRAM is brought up in the absolute minimal way, again
you just simply do not witness the process unless you are a coreboot
developer.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68