> On 13 Jun 2017, at 20:14, Jagan Teki <jagannadh.t...@gmail.com> wrote: > > > > On Jun 13, 2017 11:37 PM, "Dr. Philipp Tomsich" > <philipp.toms...@theobroma-systems.com > <mailto:philipp.toms...@theobroma-systems.com>> wrote: > Jagan, > > > On 13 Jun 2017, at 19:48, Jagan Teki <jagannadh.t...@gmail.com > > <mailto:jagannadh.t...@gmail.com>> wrote: > > > >>>>>>> > >>>>>>> On 31 May 2017 at 04:50, Kever Yang <kever.y...@rock-chips.com > >>>>>>> <mailto: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. > >> > >> To me it looks as if we need to fix the BOOT0 handling across all ARMv7 > >> platforms, as it looks as if the current implementation and its > >> documentation > >> contradict each other. > >> > >> Here’s how BOOT0 was intended: > >> > >> 1. from Kconfig: > >> If the SoC's BOOT0 requires a header area filled with (magic) > >> values, then choose this option, and create a define called > >> ARM_SOC_BOOT0_HOOK which contains the required assembler > >> preprocessor code. > >> > >> 2. from the code in arch/arm/lib/vectors.S: > >> /* > >> * Various SoCs need something special and SoC-specific up front in > >> * order to boot, allow them to set that in their boot0.h file and then > >> * use it here. > >> */ > >> > >> Can we just resolve this by changing arch/arm/lib/vectors.S to replace > >> the entire content starting after the “_start:” label with the BOOT0 hook, > >> if one is defined? > >> This would then make it the responsibiliy of the respective BOOT0 hook > >> to appropriately insert the vectors before or after its other magic and > >> allow all architectures to do whatever their boot ROM requires... > > > > I don't think placing boot0 hook after _start will resolve (I thought > > you mentioned the same here) and look like placing boot0 hook > > insertion before or after _start results the same based on the > > generated image.I've checked this and find the same 4-byte change in > > hexdump. > > I’ll look at what’s going on there. Which defconfig did you try with? > > orangepi_pc
I must be doing something wrong, as this doesn’t set the BOOT0_HOOK (this was against the mailine master @ 8cb3ce64f936f5dedbcfc1935c5caf31bb682474): ptomsich@android:~/rk3399-spl/boot0/u-boot$ make CROSS_COMPILE=arm-unknown-eabi- ARCH=arm -j8 orangepi_pc_defconfig && grep BOOT0 .config # # configuration written to .config # # CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK is not set # CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER is not set _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot