allo Ben, been a while, nice to hear from you.<br><br>On Monday, May 10, 2021, Benjamin Herrenschmidt &lt;<a href="mailto:benh@kernel.crashing.org">benh@kernel.crashing.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
We are familiar with u-boot and bare metal initializations. The problem<br>
here is that sdram_init is partially auto-generated and based on<br>
whatever changes are happening in LiteX upstream which is still quite a<br>
moving target.</blockquote><div><br></div><div>ahh got it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
It would probably be nicer if LiteDRAM inits could be refactored in a<br>
more data-driven way such that some kind of very compact table gets<br>
stored in a block &quot;ROM&quot; in the FPGA and a slightly more generic init<br>
code follows it.</blockquote><div><br></div><div> yes, agreed.  of course, the difference between FPGA and ASIC, the assumption of FPGA is, &quot;well you can always re-run the build target command&quot;.</div><div><br></div><div>and in litex you specify which DRAM IC is connected as a compile-time option.</div><div><br></div><div>with the autogeneration logic already being in place, what you suggest should be a straightforward (albeit quite extensive) code-morph exercise.  i.e. the selection of DRAM ICs is entirely dynamic (in python) so morphing to a different type of dynamic selection where that python is translated to c to read the ROM, i get the idea and think it&#39;s quite sensible.</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>