hi paul,<div><br></div><div>nice to hear you had some success getting u-boot running on microwatt.  that&#39;s a Big Deal.</div><div><br></div><div>as mentioned on the conf call, u-boot-spl.bin is the &quot;normal&quot; place for ultra low level cold-start initialisation of peripherals in absolute bare minimum mode sufficient to load a next payload into memory.</div><div><br></div><div>the RK3288 u-boot-spl.bin for example does not even initialise the DDR3 to full &quot;training&quot;, 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 &quot;ok.that&#39;s good enough&quot; and proceeds to load the main (1 mbyte +) u-boot into DRAM.</div><div><br></div><div>that *main* u-boot then will *re-run* proper training and crank up the DRAM speed.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>regarding submitting litedram sdram_init upstream to u-boot, your concern was that this is so device specific that you felt it inappropriate</div><div><br></div><div>i thought about this, and realised, &quot;news flash: *all* u-boot bare metal cold start initialisation is device-specific&quot;!</div><div><br></div><div>:)</div><div><br></div><div>this is... ahh... one of the areas that confuses the stuffing out of x86 PC linux kernel developers, *including linus torvalds*. they think, &quot;oink, everything in the x86 world is dead uniform, it&#39;s all self-describing buses like USB and PCIe, what on earth with the total incompatibility and massive fragmentation in ARM???&quot;</div><div><br></div><div>this is just how SoCs are.  there *is* no uniformity, and the uniformity that x86 sees is *hidden behind proprietary BIOSes anyway*.</div><div><br></div><div>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.</div><div><br></div><div>u-boot source code reflects this by the bucketload.</div><div><br></div><div>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.</div><div><br></div><div>bottom line is, ultra-device-specific initialisation in u-boot is &quot;normal&quot;, i would not expect there to be any objections.</div><div><br></div><div>l.</div><div><br></div><br><br>-- <br>---<br>crowd-funded eco-conscious hardware: <a href="https://www.crowdsupply.com/eoma68" target="_blank">https://www.crowdsupply.com/eoma68</a><br><br>