Hi Andy, On Tue, 21 May 2019 at 19:56, Andy Yan <andys...@gmail.com> wrote: > > Hi Simon: > > Simon Glass <s...@chromium.org> 于2019年5月22日周三 上午8:28写道： >> >> Hi Andy, >> >> On Tue, 21 May 2019 at 00:51, Andy Yan <andy....@rock-chips.com> wrote: >> > >> > Hi Simon: >> > >> > On 2019/5/20 下午11:35, Simon Glass wrote: >> > > Hi Andy, >> > > >> > > On Mon, 20 May 2019 at 00:34, Andy Yan <andy....@rock-chips.com> wrote: >> > >> Hi Simon: >> > >> >> > >> On 2019/5/19 上午12:26, Simon Glass wrote: >> > >>> Hi Andy, >> > >>> >> > >>> Instead of this could you: >> > >>> >> > >>> - move ATF? >> > >> All rockchip based arm64 ATF run from the start 64KB of dram as this >> > >> will give convenient for kernel manage the memory. >> > >> >> > >> On the other hand, change the ATF load address will break the >> > >> compatibility of the exiting firmware. >> > >> >> > >>> - change the SPL load address so it is not in the way (since TPL can >> > >>> load to any address) >> > >> The SPL is loaded by bootrom after TPL back to bootrom, so the load >> > >> address if fixed by bootrom code. >> > > I think you are creating a nightmare here. If you have to do things >> > > like this for older and smaller SoCs, OK. But it should not be used >> > > for newer ones that can do things properly. >> > >> > >> > Most rockchip based SOC sram is small, even in the future soc roadmap, >> > this situation will still exist, larger sram means more cost. >> >> I believe the RK3399 has 192KB. What is the minimum size in new chips? > > > The sram size of RK3328 is 32KB, and now the u-boot-tpl.bin of rk3328 without > storage drive is 28KB. > The available sram size for TPL on RK3326 is 10KB, our another A35 based IOT > SOC has the same limitation.
OK, I see. > >> >> >> > >> > As for the current spl for rockchip soc in mainline, we use a workaround >> > by reserve large space at the head of spl(see >> > CONFIG_ROCKCHIP_SPL_RESERVE_IRAM ), this generate a very large spl binary. >> >> Yes. >> >> > >> > As for my patch, the spl relocation is disabled default, we only enable >> > it on necessary platform, so it won't hurt others . >> >> Well it adds more code and complexity. Perhaps it makes sense to add >> this, but I want to understand the need. >> >> > >> > > The bootrom has so many limitations that it just creates pain. >> > > >> > >> I know we can build mmc or other storage driver into TPL so we can use >> > >> tpl load spl on some platform that sram is big enough, but there are >> > >> also many rockchip soc has very small sram, so we tend to only do dram >> > >> initialization in tpl, and let bootrom load next stage . >> > > See above >> > > >> > For the consideration of software development, we also want to keep TPL >> > clean, only do dram initialization(as it current status), this make our >> > internal dram team work more simple, they don't need to care about other >> > modules like mmc. >> >> Yes I understand this, but the boot ROM should be provided as a >> library to call into: >> >> int mmc_read(void *addr, int start_block, int end_block) >> int spi_read(void *addr, int start_block, int end_block) >> >> Then SPL or TPL can use it without all the strange limitations we have now. >> >> Since you probably already have these functions somewhere in the boot >> ROM, you could implement this using a function table somewhere in the >> ROM with a magic number before it, so that SPL can find it. > > > The Bootrom do much more work than directly load the spl binary. It will do > somthing like checksum, look for the backup when the current image is > invalid, also including security check when secure boot is enabled. This is > why we did much work to add back_too_bootrom mechanism in mainline in 2017. Yes I understand that, but it is also quite inflexible, and creates enormous problems with bootloaders. I am not suggesting that you remove functionality. I am suggesting that you allow bootloaders to call into some of it, to reduce the problems caused by the inflexible bootrom. Regards, Simon >> >> >> > >> > >> > >>> - (in extremis) create a function which does a memmove() and a jump, >> > >>> copy it somewhere and run it (I think x86 does this) >> > > ? >> > I am not very understand about this, just a memmove may not work, we >> > need to link the code by pie, and fix the rela.dyn sections after copy. >> > see arm/relocate_64.S >> >> Well if you don't access absolute addresses (which you generally don't >> in ARM) your memmove() and jump code should be relocatable. >> >> Also I wonder what you think of Andre's solution? >> > > See my reply . Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
