[Libre-soc-dev] u-boot for openpower

[Luke Kenneth Casson Leighton]

hi paul,

nice to hear you had some success getting u-boot running on microwatt.
that's a Big Deal.

as mentioned on the conf call, u-boot-spl.bin is the "normal" place for
ultra low level cold-start initialisation of peripherals in absolute bare
minimum mode sufficient to load a next payload into memory.

the RK3288 u-boot-spl.bin for example does not even initialise the DDR3 to
full "training", it sets speed at 200 mhz (low enough to not need impedance
matching), does the absolute bare minimum detection of timing, width and
port, checks a few reads and writes, then goes "ok.that's good enough" and
proceeds to load the main (1 mbyte +) u-boot into DRAM.

that *main* u-boot then will *re-run* proper training and crank up the DRAM
speed.

this all to make sure that time is saved on startup.  if there is only 16k
SRAM available (including for stack and heap!) you simply have no room for
a complex SDMMC USB2 QSPI suite of drivers, anyway.

most people in the embedded world are dead happy to have single SPI and
UART, and treat QSPI and SDMMC also as single SPI, within the u-boot-spl
loader.  actual like... screens n stuff (HDMI) come waaay down the chain of
initialisation.

regarding submitting litedram sdram_init upstream to u-boot, your concern
was that this is so device specific that you felt it inappropriate

i thought about this, and realised, "news flash: *all* u-boot bare metal
cold start initialisation is device-specific"!

:)

this is... ahh... one of the areas that confuses the stuffing out of x86 PC
linux kernel developers, *including linus torvalds*. they think, "oink,
everything in the x86 world is dead uniform, it's all self-describing buses
like USB and PCIe, what on earth with the total incompatibility and massive
fragmentation in ARM???"

this is just how SoCs are.  there *is* no uniformity, and the uniformity
that x86 sees is *hidden behind proprietary BIOSes anyway*.

whereas in the ARM world there are a couple of thousand licensees, none of
whom collaborate or cooperate and even if they wanted to their products are
targetted at such radically different markets it is a waste of time trying.

u-boot source code reflects this by the bucketload.

some fabless companies such as Rockchip have however gone to some lengths
to use at least similar peripherals.  they use the same DRAM controller for
example across the whole product family.

bottom line is, ultra-device-specific initialisation in u-boot is "normal",
i would not expect there to be any objections.

l.



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