On Tue, Jun 13, 2017 at 1:14 PM, Dr. Philipp Tomsich <philipp.toms...@theobroma-systems.com> wrote: > >> On 13 Jun 2017, at 03:40, Kever Yang <kever.y...@rock-chips.com> wrote: >> >> Hi Simon, >> >> >> On 06/09/2017 08:27 PM, Simon Glass wrote: >>> Hi Kever, >>> >>> On 7 June 2017 at 04:55, Kever Yang <kever.y...@rock-chips.com> wrote: >>>> Simon, >>>> >>>> >>>> >>>> On 06/07/2017 11:15 AM, Simon Glass wrote: >>>>> Hi Kever, >>>>> >>>>> On 6 June 2017 at 20:41, Kever Yang <kever.y...@rock-chips.com> wrote: >>>>>> Simon, >>>>>> >>>>>> >>>>>> >>>>>> On 06/07/2017 05:08 AM, Simon Glass wrote: >>>>>>> Hi Kever, >>>>>>> >>>>>>> On 31 May 2017 at 04:50, Kever Yang <kever.y...@rock-chips.com> wrote: >>>>>>>> I think the boot0 hook is suppose to add some data in the very >>>>>>>> beginning >>>>>>>> of the SPL image, am I right? >>>>>>>> >>>>>>>> Rockchip SoCs bootrom design is like this: >>>>>>>> - First 2KB or 4KB internal memory is for bootrom stack and heap; >>>>>>>> - Then the first 4-byte suppose to be a TAG like 'RK33'; >>>>>>>> - The the following memory address end with '0004' is the first >>>>>>>> instruction load and running by bootrom; >>>>>>>> >>>>>>>> Example for RK3288: >>>>>>>> Before this patch set, the SPL_TEXT_BASE is ff704004, and image write >>>>>>>> to >>>>>>>> media device after mkimage like this: >>>>>>>> >>>>>>>> ff704000: 32334b52 00000000 00000000 00000000 RK32............ >>>>>>>> ff704010: 00000000 00000000 00000000 00000000 ................ >>>>>>>> ff704020: ea00000f e59ff014 e59ff014 e59ff014 ................ >>>>>>>> ff704030: e59ff014 e59ff014 e59ff014 e59ff014 ................ >>>>>>>> >>>>>>>> Where the first instruction from bootrom is '00000000', which is a >>>>>>>> undefined instruction. >>>>>>>> The '_start' and 'reset' have to align to 0x20 for the requirement of >>>>>>>> VBAR, the memory offset '004'~'01c' are filled with '00000000'. >>>>>>>> >>>>>>>> We can use the boot0 hook to fix this issue, after this patch set, >>>>>>>> the SPL_TEXT_BASE is ff704000 and image write to media device after >>>>>>>> mkimage like this: >>>>>>>> >>>>>>>> ff704000: 32334b52 ea00001d e320f000 e320f000 RK32...... ... . >>>>>>>> ff704010: e320f000 e320f000 e320f000 e320f000 .. ... ... ... . >>>>>>>> ff704020: ea000016 e59ff014 e59ff014 e59ff014 ................ >>>>>>>> ff704030: e59ff014 e59ff014 e59ff014 e59ff014 ................ >>>>>>>> >>>>>>>> The first instruction from bootrom is a 'b reset', and memory of >>>>>>>> '008'~'01c' are filled with 'nop' instruction. >>>>>>>> >>>>>>>> This patch set does not provide patch for socfpga, bcm and sunxi SoCs >>>>>>>> which also >>>>>>>> enable BOOT0_HOOK, so this is a RFC patch, please advice how to make it >>>>>>>> compatible with those three platforms. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Kever Yang (5): >>>>>>>> armv7: move boot hook before '_start' >>>>>>>> rockchip: boot0: align to 0x20 for armv7 '_start' >>>>>>>> rockchip: enable BOOT0_HOOK for SoCs >>>>>>>> rockchip: configs: use aligned address for SPL_TEXT_BASE >>>>>>>> rockchip: mkimage: use spl_boot0 for all Rockchip SoCs >>>>>>>> >>>>>>>> arch/arm/include/asm/arch-rockchip/boot0.h | 9 ++++++++- >>>>>>>> arch/arm/lib/vectors.S | 19 ++++++++++--------- >>>>>>>> arch/arm/mach-rockchip/Kconfig | 3 +++ >>>>>>>> include/configs/rk3036_common.h | 2 +- >>>>>>>> include/configs/rk3288_common.h | 2 +- >>>>>>>> tools/rkcommon.c | 8 ++++---- >>>>>>>> 6 files changed, 27 insertions(+), 16 deletions(-) >>>>>>>> >>>>>>>> -- >>>>>>>> 1.9.1 >>>>>>>> >>>>>>> Do will still need this series now that (I think) we have a fix for >>>>>>> the return-to-brom feature in u-boot-rockchip/master? >>>>>> >>>>>> Could you point me out exactly which fix do you talking about? >>>>> These ones: >>>>> >>>>> a079e52d35 rockchip: mkimage: set init_boot_size to avoid confusing the >>>>> boot ROM >>>>> ee2c63912b rockchip: mkimage: force 2KB alignment for init_size >>>>> 99c700c794 rockchip: mkimage: add support for verify_header/print_header >>>>> >>>>>> This is not about return-to-brom, it's about the first instruction from >>>>>> Bootrom to SPL. >>>>>> So this is need for all Rockchip armv7 SoCs. >>>>> OK, how did we survive before? What has changed to make this series >>>>> needed? >>>> >>>> After check with JTAG, I find that I'm wrong with cmd code '00000000', >>>> this is 'andeq r0, r0, r0', but not undefined in armv7, so it can work. >>>> >>>> I still want this patch set applied because it's better to make all the >>>> Rockchip's >>>> SPL have the same format(with 4-byte TAG space reserved), and the ddr >>>> binary >>>> from Rockchip always have pre-padding 4-byte TAG, with this patch set, we >>>> can replace each other easily and work with one mkimage tool. >>> I'm not sure how to apply this since on the other thread[1] Marek says >>> it will break socfpga. >> >> I know this must break socfpga platform, and as I have said in cover letter, >> I think this patch also break bcm and sunxi platform, I add 'RFC' for this >> patch >> set because I don't know the detail requirement of hook0 for other 3 >> platform, >> I'm not asking if this patch set break other 3 platforms or not, but I'm >> asking for >> the solution for those 3 platform so that we can apply this patch set. > > The following platforms have a boot0-hook implemented: > > ./arch/arm/include/asm/arch-rockchip/boot0.h > ./arch/arm/include/asm/arch-bcm235xx/boot0.h > ./arch/arm/include/asm/arch-sunxi/boot0.h > ./arch/arm/include/asm/arch-bcm281xx/boot0.h > ./arch/arm/mach-socfpga/include/mach/boot0.h > >> I think my patch is correct in what HOOK0 wants to do, just like Philipp's >> opinion >> in another mail. >> I hope to get help from maintainer for socfpga, bcm, sunxi platform.
for sunxi32 boot0 hook does normal execution (b reset) but the image changed 4 bytes with this change. w/o the change: 0000000 0016 ea00 4765 4e4f 422e 3054 cf32 4cc6 0000010 6000 0000 5053 024c 0000 0000 0000 0000 with the change: 0000000 0016 ea00 4765 4e4f 422e 3054 da15 4b6f 0000010 6000 0000 5053 024c 0000 0000 0000 0000 of-course board not booting. thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
