[U-Boot] [RFC PATCH 0/5] move boot0 hook in the beginning for armv7

Tue Jun 13 18:29:34 UTC 2017

> On 13 Jun 2017, at 20:14, Jagan Teki <jagannadh.teki at gmail.com> wrote:
> 
> 
> 
> On Jun 13, 2017 11:37 PM, "Dr. Philipp Tomsich" <philipp.tomsich at theobroma-systems.com <mailto:philipp.tomsich at theobroma-systems.com>> wrote:
> Jagan,
> 
> > On 13 Jun 2017, at 19:48, Jagan Teki <jagannadh.teki at gmail.com <mailto:jagannadh.teki at gmail.com>> wrote:
> >
> >>>>>>>
> >>>>>>> On 31 May 2017 at 04:50, Kever Yang <kever.yang at rock-chips.com <mailto:kever.yang at 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 at 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