3 ms·
> - Initialising the DRAM controller and sizing memory Hum I don't really understand that one. Based on the article I understood that the code before SBI was d
by phh 3y ago
> - Initialising the DRAM controller and sizing memory
Hum I don't really understand that one. Based on the article I understood that the code before SBI was directly bootrom, and usually bootrom doesn't init DRAM (at least that's not how rockchip/allwinner/amlogic SoCs behave). So what's the expectation on how SoC vendors implement DDR init code? It's expected that SoC vendor push this code to bootrom (thus costing more in maskrom)?
- dezgeg 3y agoNothing forces it to be in ROM. See for example https://github.com/carlosedp/riscv-bringup/blob/master/unleashed/Readme.md https://github.com/carlosedp/riscv-bringup/blob/master/unlea... where DRAM init seems to be in the FSBL part which is loaded from the SD card.
- Taniwha 3y agoDepends on what sort of boot rom you have - typically the code before SBI is hard baked into the CPU while SBI, uboot, linux etc are copied into DRAM and run there - this may not be true on embedded systems which may have SRAM for loading initial code into. These days though SDRAM controllers are complex, and need careful tuning when the power comes on (and the chip heats up), the code that runs cycles to initialise DRAM is often very complex and proprietary. If you're building a high performance chip you typically have very big wide L1 caches, and relatively wide paths to DRAM - you don't want to hamper them by having to attach them to a much slower 8-bit wide ROM (typically eMMC these days) - better to have boot code do the copy (eMMC looks like a fast SD card) - there are tricks you can do with L1 cache tag management that turns it into an SRAM until DRAM is initialised
- deleted 3y ago[deleted]