Dear Kever Yang, In message <fd0bb500-80c4-f317-cc18-f7aaf1344...@rock-chips.com> you wrote: > > I can understand this feature, we always do dram_init_banks() first, > then we relocate to 'known' area, then will be no risk to access memory. > I believe there must be some historical reason for some kind of device, > the relocate feature is a wonderful idea for it.
This is actuallyu not so much a feature needed to support some specific device (in this case much simpler approahces would be possible), but to support a whole set of features. Unfortunately these appear to get forgotten / ignored over time. > many other SoCs should be similar. > - Without relocate we can save many step, some of our customer really > care much about the boot time duration. > * no need to relocate everything > * no need to copy all the code > * no need init the driver more than once Please have a look at the README, section "Memory Management". The reloaction is not done to any _fixed_ address, but the address is actually computed at runtime, depending on a number features enabled (at least this is how it used to be - appearently little of this is tested on a regular base, so I would not be surprised if things are broken today). The basic idea was to reserve areas of memory at the top of RAM, that would not be initialized / modified by U-Boot and Linux, not even across a reset / warm boot. This was used for exaple for: - pRAM (Protected RAM) which could be used to store all kind of data (for example, using a pramfs [Protected and Persistent RAM Filesystem]) that could be kept across reboots of the OS. - shared frame buffer / video memory. U-Boot and Linux would be able to initialize the video memory just once (in U-Boot) and then share it, maybe even across reboots. especially, this would allow for a very early splash screen that gets passed (flicker free) to Linux until some Linux GUI takes over (much more difficult today). - shared log buffer: U-Boot and Linux used to use the same syslog buffer mechanism, so you could share it between U-Boot and Linux. this allows for example to * read the Linux kernel panic messages after reset in U-Boot; this is very useful when you bring up a new system and Linux crashes before it can display the log buffer on the console * pass U-Boot POST results on to Linux, so the application code can read and process these * process the system log of the previous run (especially after a panic) in Lunux after it rebootet. etc. There are a number of such features which require to reserve room at the top of RAM, the size of which is calculatedat runtime, often depending on user settable environment data. All this cannot be done without relocation to a (dynmaically computed) target address. Yes, the code could be simpler and faster without that - but then, you cut off a number of features. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The flow chart is a most thoroughly oversold piece of program docu- mentation. -- Frederick Brooks, "The Mythical Man Month" _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot