[U-Boot] [RFC PATCH 1/5] armv7: move boot hook before '_start'

[Simon Glass]

Hi,

On 13 June 2017 at 04:31, Dr. Philipp Tomsich
<philipp.tomsich at theobroma-systems.com> wrote:
>
>> On 13 Jun 2017, at 11:47, Marek Vasut <marex at denx.de> wrote:
>>
>> On 06/13/2017 11:44 AM, Dr. Philipp Tomsich wrote:
>>> Marek,
>>>
>>>> On 13 Jun 2017, at 10:42, Marek Vasut <marex at denx.de
>>>> <mailto:marex at denx.de>> wrote:
>>>>
>>>> On 06/13/2017 03:51 AM, Kever Yang wrote:
>>>>> Hi Marek,
>>>>
>>>> Hi,
>>>>
>>>>> On 06/07/2017 02:28 PM, Marek Vasut wrote:
>>>>>> On 06/07/2017 04:28 AM, Kever Yang wrote:
>>>>>>> Hi Andre, Steve, Marek,
>>>>>>>
>>>>>>>    Could you help to check how to make it work with this patch on
>>>>>>> sunxi, bcm and socfpga platform?
>>>>>> The socfpga expects the hook at that exact position (0x40 I think) , so
>>>>>> if you moved it somewhere, you broke socfpga.
>>>>>
>>>>> I know this break socfpga, and that's why I cc you for help, could you
>>>>> help the take a look if we can have a solution on socfpga to "make it
>>>>> work with this patch"?
>>>>
>>>> Can you generate the same u-boot binary with this patch ? If so, then it
>>>> will work on socfpga. SoCFPGA expects that small piece of stuff at
>>>> offset 0x40 , so if you move this boot0 hook, it will break. HTH
>>>
>>> So the SoCFPGA-implementation relies on the boot0 hook to always start
>>> at 0x40?  Then this needs fixing anyway… or it will break once someone
>>> else touches the armv7 startup code.
>>
>> I think it's not just the SoCFPGA.
>
> What I am saying is that the boot0-hook is intended to add a header
> before the actual U-Boot code (as Andre had originally stated in his
> commit message and as various comments around the boot0 hook
> also suggest):
>
>     arm/arm64: implement a boot header capability
>
>     Some SPL loaders (like Allwinner's boot0, and Broadcom's boot0)
>     require a header before the actual U-Boot binary to both check its
>     validity and to find other data to load. Sometimes this header may
>     only be a few bytes of information, and sometimes this might simply
>     be space that needs to be reserved for a post-processing tool.
>
> However, the actual start of the boot0-hook in the U-Boot today is right
> after the vector-table (which is 0x40 long), which has a few interesting
> consequences for various architectures:
> - sunxi: doesn’t matter
> - socfpga: boot0 hook relies on something being in front of it, as it uses
>         a ".balign 64, …” to advance to 0x40
> - rockchip: comes too late to allow inserting the word-sized field at the
>         very start (and to move the vectors back by a word).
>
> Now having looked at the implementation in
>         arch/arm/mach-socfpga/include/mach/boot0.h
> it is clear why Kever’s change breaks this code: .balign will not forward
> to 0x40 (after all, 0x0 is also 64-byte aligned).
>
> Once the boot0 hook is at the beginning of the binary (as always intended),
> this will need to become a .space or .fill directive.
>
>>> That said, I read your comment to mean that the following changes would
>>> work for SoCFPGA:
>>> 1.arch/arm/lib/vectors.S:
>>> #if CONFIG_IS_ENABLED(BOOT0_HOOK)
>>> … pull in the boot0 hook, which needs to contain the vectors
>>> #else
>>> b reset
>>> … remaining vectors …
>>> #endif
>>> 2.boot0.h (for socfpga):
>>> b reset
>>> … remaining vectors …
>>> /* now at 0x40 */
>>> … whatever currently lives in the boot0.h for socfpga ...
>>>
>>> Ok?
>>
>> I'm not sure I understand what you're trying to say. IIRC the SoCFPGA
>> bootrom checks the content at 0x40-0x48 in SRAM and then jumps to 0x50
>> if the content is valid. Otherwise it reloads the content from
>> SD/SPI/NAND…
>
> Thanks for the background info. With this, it should be possible to create
> a new version of the patch that also correctly handles socfpga.

Sounds like this is figured out, great!

- Simon