ons 2014-07-23 klockan 17:15 +0200 skrev Maxime Ripard: > IIRC, the u-boot guys are *very* reluctant to chain-loading > u-boot. Plus, that would have quite a huge impact on the boot time.
Yes. The point is that we can do the following: 1. Boot installer using generic u-boot using any of the available boot methods. 2. installer uses NAND driver to extract DRAM parameters from boot0 or existing SPL and also script.bin from the board. 3. installer copies script.bin and DRAM parameters to the installed system. script.bin into /boot, and DRAM parameters into SPL. 4. reboot to installed system with "correct" DRAM parameters. 5. user can tune DRAM parameters with a tool which rewrites the SPL with changed DRAM parameters. Maybe even integrated into u-boot mkimage to keep everyone happy. This limits the needed targets in u-boot to the generic ones + some boards which are well known and supported where we care for exact DRAM parameters from start and LED status indication etc.. Requirements to get there: We need generic u-boot that boots on most boards, autodetecting the most critical DRAM parameters allowing us to boot the board and run code. u-boot SPL needs a configuration area for DRAM parameters. Today embedded into the binary but should be moved to the header area allowing it to be easily configured without recompile. we need a tool that configures SPL with needed DRAM parameters. Might be integrated in u-boot mkimage. linux NAND driver with boot block support needs to be integrated into kernel, allowing the boot blocks to be both read and written. AW NAND drover do not expose the boot blocks out of the box. Here is quite different choices depending on if one wants to use the MTD NAND driver or AW virtual block device NAND drivers (multiple block device driver versions exists, mutually incompatible). An installer needs to be written which can extract the DRAM parameters from boot0 or SPL and script.bin from boot1 and/or the boot partition and transform these into a configured SPL and script.bin. For mainline kernel migration a tool to transform from script.bin to devicetree dts is needed, and integrated in installer. And then a repository of improved DRAM parameters and script.bin/devicetree.dts files is also needed, as most AW vendors do not really know their own hardware (or care about it) so the data we find on the board is often less than optimal. Might also need a safe fallback mechanism telling the SPL to disregard the DRAM configuration parameters and use "autodetected defaults", allowing easier recovery when setting incorrect DRAM parameters. There is some user data bits in both the AW RTC and AW PMU which could be abused for such purpose (needs to persist a soft power cycle). Or some magics with buttons, but hard to get that right without delaying normal boot process. Same software switch can also be used for bypassing Falcon boot mode. Regards Henrik -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
