[U-Boot] [PATCH] spl: fix entry_point equal to load_addr

[Giulio Benetti <giulio.benetti@benettiengineering.com>]

Hello Tom, all,

On 12/6/19 2:34 PM, Tom Rini wrote:
> On Fri, Dec 06, 2019 at 01:58:46PM +0100, Simon Goldschmidt wrote:
>> On Fri, Dec 6, 2019 at 1:46 PM Patrice CHOTARD <patrice.chotard@st.com> wrote:
>>>
>>> Hi
>>>
>>> This patch is breaking the STM32MP15 basic boot (spl => u-boot).
>>
>> Looking at socfpga gen5 u-boot.img, this is probably broken as well.
>>
>> And I don't even see any RB or TB tags here :-(
> 
> Ugh, what the heck?  I applied this because I looked over the changes
> and they seemed correct.  I'm quite willing to just revert this but I
> would like to know how it's breaking.  Sorry all!
> 

IMHO this is due to wrong images creation with mkinage, especially when 
passing parameters with -a and -e flags.

In my case I need them to be:
-a 0x80002000 (load address) => CONFIG_SYS_TEXT_BASE
-e 0x800023FD (entry point where SPL jumps to) => CONFIG_SYS_UBOOT_START

So *maybe* on STM32MP1 and other broken boards -e 
(CONFIG_SYS_UBOOT_START) is not equal to -a (CONFIG_SYS_TEXT_BASE) as 
was assumed before(but wrong).

Indeed CONFIG_SYS_UBOOT_START is set to 0 if not specified in 
u-boot/Makefile:
`
# U-Boot entry point, needed for booting of full-blown U-Boot
# from the SPL U-Boot version.
#
ifndef CONFIG_SYS_UBOOT_START
CONFIG_SYS_UBOOT_START := 0
endif
`

So probably broken boards try to jump to absolute 0.
A solving patch would be:
ifndef CONFIG_SYS_UBOOT_START
CONFIG_SYS_UBOOT_START := CONFIG_SYS_TEXT_BASE
endif

What do you think?

Sorry for this mess!

Best regards
-- 
Giulio Benetti
Benetti Engineering sas