Hi All
On 12/6/19 2:48 PM, Giulio Benetti wrote:
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?
This is what i implemented to fix this issue. Here is my proposal [1], but i need some
feedback from some boards maintainers.
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=146876
Thanks
Patrice
Sorry for this mess!
Best regards