All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
@ 2019-11-25 16:18 Giulio Benetti
  2019-12-05 22:09 ` Tom Rini
  2020-01-16 14:40 ` Tom Rini
  0 siblings, 2 replies; 18+ messages in thread
From: Giulio Benetti @ 2019-11-25 16:18 UTC (permalink / raw)
  To: u-boot

At the moment entry_point is set to image_get_load(header) that sets it
to "load address" instead of "entry point", assuming entry_point is
equal to load_addr, but it's not true. Then load_addr is set to
"entry_point - header_size", but this is wrong too since load_addr is
not an entry point.

So use image_get_ep() for entry_point assignment and image_get_load()
for load_addr assignment.

Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
---
 common/spl/spl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index f1ad8dc9da..cdae346753 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -261,9 +261,9 @@ int spl_parse_image_header(struct spl_image_info *spl_image,
 			spl_image->entry_point = image_get_ep(header);
 			spl_image->size = image_get_data_size(header);
 		} else {
-			spl_image->entry_point = image_get_load(header);
+			spl_image->entry_point = image_get_ep(header);
 			/* Load including the header */
-			spl_image->load_addr = spl_image->entry_point -
+			spl_image->load_addr = image_get_load(header) -
 				header_size;
 			spl_image->size = image_get_data_size(header) +
 				header_size;
-- 
2.20.1

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
  2019-11-25 16:18 [U-Boot] [PATCH] spl: fix entry_point equal to load_addr Giulio Benetti
@ 2019-12-05 22:09 ` Tom Rini
  2019-12-06 12:46   ` Patrice CHOTARD
  2020-01-16 14:40 ` Tom Rini
  1 sibling, 1 reply; 18+ messages in thread
From: Tom Rini @ 2019-12-05 22:09 UTC (permalink / raw)
  To: u-boot

On Mon, Nov 25, 2019 at 05:18:20PM +0100, Giulio Benetti wrote:

> At the moment entry_point is set to image_get_load(header) that sets it
> to "load address" instead of "entry point", assuming entry_point is
> equal to load_addr, but it's not true. Then load_addr is set to
> "entry_point - header_size", but this is wrong too since load_addr is
> not an entry point.
> 
> So use image_get_ep() for entry_point assignment and image_get_load()
> for load_addr assignment.
> 
> Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191205/41ba8521/attachment.sig>

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
  2019-12-05 22:09 ` Tom Rini
@ 2019-12-06 12:46   ` Patrice CHOTARD
  2019-12-06 12:58     ` Simon Goldschmidt
  0 siblings, 1 reply; 18+ messages in thread
From: Patrice CHOTARD @ 2019-12-06 12:46 UTC (permalink / raw)
  To: u-boot

Hi

This patch is breaking the STM32MP15 basic boot (spl => u-boot).

I will send a fix proposal.

Thanks

Patrice

On 12/5/19 11:09 PM, Tom Rini wrote:
> On Mon, Nov 25, 2019 at 05:18:20PM +0100, Giulio Benetti wrote:
>
>> At the moment entry_point is set to image_get_load(header) that sets it
>> to "load address" instead of "entry point", assuming entry_point is
>> equal to load_addr, but it's not true. Then load_addr is set to
>> "entry_point - header_size", but this is wrong too since load_addr is
>> not an entry point.
>>
>> So use image_get_ep() for entry_point assignment and image_get_load()
>> for load_addr assignment.
>>
>> Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
> Applied to u-boot/master, thanks!
>

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
  2019-12-06 12:46   ` Patrice CHOTARD
@ 2019-12-06 12:58     ` Simon Goldschmidt
  2019-12-06 13:34       ` Tom Rini
  0 siblings, 1 reply; 18+ messages in thread
From: Simon Goldschmidt @ 2019-12-06 12:58 UTC (permalink / raw)
  To: u-boot

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 :-(

Regards,
Simon

>
> I will send a fix proposal.
>
> Thanks
>
> Patrice
>
> On 12/5/19 11:09 PM, Tom Rini wrote:
> > On Mon, Nov 25, 2019 at 05:18:20PM +0100, Giulio Benetti wrote:
> >
> >> At the moment entry_point is set to image_get_load(header) that sets it
> >> to "load address" instead of "entry point", assuming entry_point is
> >> equal to load_addr, but it's not true. Then load_addr is set to
> >> "entry_point - header_size", but this is wrong too since load_addr is
> >> not an entry point.
> >>
> >> So use image_get_ep() for entry_point assignment and image_get_load()
> >> for load_addr assignment.
> >>
> >> Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
> > Applied to u-boot/master, thanks!
> >

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
  2019-12-06 12:58     ` Simon Goldschmidt
@ 2019-12-06 13:34       ` Tom Rini
  2019-12-06 13:37         ` Simon Goldschmidt
  2019-12-06 13:48         ` Giulio Benetti
  0 siblings, 2 replies; 18+ messages in thread
From: Tom Rini @ 2019-12-06 13:34 UTC (permalink / raw)
  To: u-boot

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191206/062462e2/attachment.sig>

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
  2019-12-06 13:34       ` Tom Rini
@ 2019-12-06 13:37         ` Simon Goldschmidt
  2019-12-06 13:44           ` Tom Rini
  2019-12-06 13:48         ` Giulio Benetti
  1 sibling, 1 reply; 18+ messages in thread
From: Simon Goldschmidt @ 2019-12-06 13:37 UTC (permalink / raw)
  To: u-boot

On Fri, Dec 6, 2019 at 2:34 PM Tom Rini <trini@konsulko.com> 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!

Looking at the branch a few lines up I can understand why this seemed
like a small change. I hadn't seen this before Patrice's mail, either.

Let me test this on socfpga_socrates tomorrow, I could still be wrong since
this is from reading the code and binary only. But entry_point should be 0
in my u-boot.img if I'm not mistaken, and that should break it.

Regards,
Simon

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
  2019-12-06 13:37         ` Simon Goldschmidt
@ 2019-12-06 13:44           ` Tom Rini
  0 siblings, 0 replies; 18+ messages in thread
From: Tom Rini @ 2019-12-06 13:44 UTC (permalink / raw)
  To: u-boot

On Fri, Dec 06, 2019 at 02:37:52PM +0100, Simon Goldschmidt wrote:
> On Fri, Dec 6, 2019 at 2:34 PM Tom Rini <trini@konsulko.com> 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!
> 
> Looking at the branch a few lines up I can understand why this seemed
> like a small change. I hadn't seen this before Patrice's mail, either.
> 
> Let me test this on socfpga_socrates tomorrow, I could still be wrong since
> this is from reading the code and binary only. But entry_point should be 0
> in my u-boot.img if I'm not mistaken, and that should break it.

Maybe I just haven't had enough coffee or time to think, but that sounds
like entry_point being set wrong somewhere.  Of course, if it's being
set wrong somewhere and it's not self-contained within U-Boot to correct
it (iow external scripts/docs), we have to deal with that reality.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191206/93682a81/attachment.sig>

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
  2019-12-06 13:34       ` Tom Rini
  2019-12-06 13:37         ` Simon Goldschmidt
@ 2019-12-06 13:48         ` Giulio Benetti
  2019-12-06 14:04           ` Patrice CHOTARD
  2019-12-06 14:05           ` Simon Goldschmidt
  1 sibling, 2 replies; 18+ messages in thread
From: Giulio Benetti @ 2019-12-06 13:48 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
  2019-12-06 13:48         ` Giulio Benetti
@ 2019-12-06 14:04           ` Patrice CHOTARD
  2019-12-06 17:23             ` Giulio Benetti
  2019-12-06 14:05           ` Simon Goldschmidt
  1 sibling, 1 reply; 18+ messages in thread
From: Patrice CHOTARD @ 2019-12-06 14:04 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
  2019-12-06 13:48         ` Giulio Benetti
  2019-12-06 14:04           ` Patrice CHOTARD
@ 2019-12-06 14:05           ` Simon Goldschmidt
  2019-12-06 14:55             ` Tom Rini
  1 sibling, 1 reply; 18+ messages in thread
From: Simon Goldschmidt @ 2019-12-06 14:05 UTC (permalink / raw)
  To: u-boot

On Fri, Dec 6, 2019 at 2:49 PM Giulio Benetti
<giulio.benetti@benettiengineering.com> 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

Well, CONFIG_SYS_UBOOT_START is only set in 15 files in include/configs, so I
guess a lot more boards might be broken...

>
> 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

That might work, but I wonder if this is the correct time in the release to do
so.

Regards,
Simon

>
> What do you think?
>
> Sorry for this mess!
>
> Best regards
> --
> Giulio Benetti
> Benetti Engineering sas

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
  2019-12-06 14:05           ` Simon Goldschmidt
@ 2019-12-06 14:55             ` Tom Rini
  2019-12-07 21:28               ` Simon Goldschmidt
  0 siblings, 1 reply; 18+ messages in thread
From: Tom Rini @ 2019-12-06 14:55 UTC (permalink / raw)
  To: u-boot

On Fri, Dec 06, 2019 at 03:05:55PM +0100, Simon Goldschmidt wrote:
> On Fri, Dec 6, 2019 at 2:49 PM Giulio Benetti
> <giulio.benetti@benettiengineering.com> 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
> 
> Well, CONFIG_SYS_UBOOT_START is only set in 15 files in include/configs, so I
> guess a lot more boards might be broken...
> 
> >
> > 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
> 
> That might work, but I wonder if this is the correct time in the release to do
> so.

Yes, at this point in the cycle the best option is to revert the
original commit and for the next release bring it back after applying
Patrice's series to fix the bogus default to CONFIG_SYS_UBOOT_START and
cleaning up defconfigs.  Sorry again for all the troubles!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191206/d6beab66/attachment.sig>

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
  2019-12-06 14:04           ` Patrice CHOTARD
@ 2019-12-06 17:23             ` Giulio Benetti
  0 siblings, 0 replies; 18+ messages in thread
From: Giulio Benetti @ 2019-12-06 17:23 UTC (permalink / raw)
  To: u-boot

Hi Patrice,

On 12/6/19 3:04 PM, Patrice CHOTARD wrote:
>> 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

Yes, I've missed it for few minutes.
Thanks for solving this.

Best regards
-- 
Giulio Benetti
Benetti Engineering sas

> feedback from some boards maintainers.
> 
> [1] https://patchwork.ozlabs.org/project/uboot/list/?series=146876
> 
> Thanks
> 
> Patrice
> 
>>
>> Sorry for this mess!
>>
>> Best regards

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
  2019-12-06 14:55             ` Tom Rini
@ 2019-12-07 21:28               ` Simon Goldschmidt
  2020-01-10 14:57                 ` Giulio Benetti
  0 siblings, 1 reply; 18+ messages in thread
From: Simon Goldschmidt @ 2019-12-07 21:28 UTC (permalink / raw)
  To: u-boot

Hi Tom,

On Fri, Dec 6, 2019 at 3:55 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Dec 06, 2019 at 03:05:55PM +0100, Simon Goldschmidt wrote:
> > On Fri, Dec 6, 2019 at 2:49 PM Giulio Benetti
> > <giulio.benetti@benettiengineering.com> 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
> >
> > Well, CONFIG_SYS_UBOOT_START is only set in 15 files in include/configs, so I
> > guess a lot more boards might be broken...
> >
> > >
> > > 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
> >
> > That might work, but I wonder if this is the correct time in the release to do
> > so.
>
> Yes, at this point in the cycle the best option is to revert the
> original commit and for the next release bring it back after applying
> Patrice's series to fix the bogus default to CONFIG_SYS_UBOOT_START and
> cleaning up defconfigs.  Sorry again for all the troubles!

I just wanted to confirm socfpga_gen5 doesn't boot with this patch
but it's ok again now you reverted it.

Regards,
Simon

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
  2019-12-07 21:28               ` Simon Goldschmidt
@ 2020-01-10 14:57                 ` Giulio Benetti
  2020-01-10 21:51                   ` Tom Rini
  0 siblings, 1 reply; 18+ messages in thread
From: Giulio Benetti @ 2020-01-10 14:57 UTC (permalink / raw)
  To: u-boot

Hi All,

On 12/7/19 10:28 PM, Simon Goldschmidt wrote:
> Hi Tom,
> 
> On Fri, Dec 6, 2019 at 3:55 PM Tom Rini <trini@konsulko.com> wrote:
>>
>> On Fri, Dec 06, 2019 at 03:05:55PM +0100, Simon Goldschmidt wrote:
>>> On Fri, Dec 6, 2019 at 2:49 PM Giulio Benetti
>>> <giulio.benetti@benettiengineering.com> 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
>>>
>>> Well, CONFIG_SYS_UBOOT_START is only set in 15 files in include/configs, so I
>>> guess a lot more boards might be broken...
>>>
>>>>
>>>> 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
>>>
>>> That might work, but I wonder if this is the correct time in the release to do
>>> so.
>>
>> Yes, at this point in the cycle the best option is to revert the
>> original commit and for the next release bring it back after applying
>> Patrice's series to fix the bogus default to CONFIG_SYS_UBOOT_START and
>> cleaning up defconfigs.  Sorry again for all the troubles!
> 
> I just wanted to confirm socfpga_gen5 doesn't boot with this patch
> but it's ok again now you reverted it.

Now that patches:
https://patchwork.ozlabs.org/patch/1205064/
https://patchwork.ozlabs.org/patch/1205063/

and 2020.01 has been released, can you please commit this patch?

I've re-submitted also on patchset to Add i.MXRT family since it's 
needed to boot Linux:
https://patchwork.ozlabs.org/project/uboot/list/?series=152468

Kind regards
-- 
Giulio Benetti
Benetti Engineering sas

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
  2020-01-10 14:57                 ` Giulio Benetti
@ 2020-01-10 21:51                   ` Tom Rini
  0 siblings, 0 replies; 18+ messages in thread
From: Tom Rini @ 2020-01-10 21:51 UTC (permalink / raw)
  To: u-boot

On Fri, Jan 10, 2020 at 03:57:47PM +0100, Giulio Benetti wrote:
> Hi All,
> 
> On 12/7/19 10:28 PM, Simon Goldschmidt wrote:
> > Hi Tom,
> > 
> > On Fri, Dec 6, 2019 at 3:55 PM Tom Rini <trini@konsulko.com> wrote:
> > > 
> > > On Fri, Dec 06, 2019 at 03:05:55PM +0100, Simon Goldschmidt wrote:
> > > > On Fri, Dec 6, 2019 at 2:49 PM Giulio Benetti
> > > > <giulio.benetti@benettiengineering.com> 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
> > > > 
> > > > Well, CONFIG_SYS_UBOOT_START is only set in 15 files in include/configs, so I
> > > > guess a lot more boards might be broken...
> > > > 
> > > > > 
> > > > > 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
> > > > 
> > > > That might work, but I wonder if this is the correct time in the release to do
> > > > so.
> > > 
> > > Yes, at this point in the cycle the best option is to revert the
> > > original commit and for the next release bring it back after applying
> > > Patrice's series to fix the bogus default to CONFIG_SYS_UBOOT_START and
> > > cleaning up defconfigs.  Sorry again for all the troubles!
> > 
> > I just wanted to confirm socfpga_gen5 doesn't boot with this patch
> > but it's ok again now you reverted it.
> 
> Now that patches:
> https://patchwork.ozlabs.org/patch/1205064/
> https://patchwork.ozlabs.org/patch/1205063/
> 
> and 2020.01 has been released, can you please commit this patch?
> 
> I've re-submitted also on patchset to Add i.MXRT family since it's needed to
> boot Linux:
> https://patchwork.ozlabs.org/project/uboot/list/?series=152468

Yes, this is on my list of things to get back to as I clear out parts of
my queue, thanks for the reminder.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200110/cb9536a8/attachment.sig>

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
  2019-11-25 16:18 [U-Boot] [PATCH] spl: fix entry_point equal to load_addr Giulio Benetti
  2019-12-05 22:09 ` Tom Rini
@ 2020-01-16 14:40 ` Tom Rini
  2020-01-16 14:46   ` Giulio Benetti
  1 sibling, 1 reply; 18+ messages in thread
From: Tom Rini @ 2020-01-16 14:40 UTC (permalink / raw)
  To: u-boot

On Mon, Nov 25, 2019 at 05:18:20PM +0100, Giulio Benetti wrote:

> At the moment entry_point is set to image_get_load(header) that sets it
> to "load address" instead of "entry point", assuming entry_point is
> equal to load_addr, but it's not true. Then load_addr is set to
> "entry_point - header_size", but this is wrong too since load_addr is
> not an entry point.
> 
> So use image_get_ep() for entry_point assignment and image_get_load()
> for load_addr assignment.
> 
> Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200116/c5b088d8/attachment.sig>

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
  2020-01-16 14:40 ` Tom Rini
@ 2020-01-16 14:46   ` Giulio Benetti
  2020-01-16 14:49     ` Tom Rini
  0 siblings, 1 reply; 18+ messages in thread
From: Giulio Benetti @ 2020-01-16 14:46 UTC (permalink / raw)
  To: u-boot

Hi Tom,

+Stefano B.

On 1/16/20 3:40 PM, Tom Rini wrote:
> On Mon, Nov 25, 2019 at 05:18:20PM +0100, Giulio Benetti wrote:
> 
>> At the moment entry_point is set to image_get_load(header) that sets it
>> to "load address" instead of "entry point", assuming entry_point is
>> equal to load_addr, but it's not true. Then load_addr is set to
>> "entry_point - header_size", but this is wrong too since load_addr is
>> not an entry point.
>>
>> So use image_get_ep() for entry_point assignment and image_get_load()
>> for load_addr assignment.
>>
>> Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
> 
> Applied to u-boot/master, thanks!

It's been already committed by Stefano Babic in imx and you've pulled 
from him.

Sorry that I've submitted it twice!

Best regards
-- 
Giulio Benetti
Benetti Engineering sas

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
  2020-01-16 14:46   ` Giulio Benetti
@ 2020-01-16 14:49     ` Tom Rini
  0 siblings, 0 replies; 18+ messages in thread
From: Tom Rini @ 2020-01-16 14:49 UTC (permalink / raw)
  To: u-boot

On Thu, Jan 16, 2020 at 03:46:15PM +0100, Giulio Benetti wrote:
> Hi Tom,
> 
> +Stefano B.
> 
> On 1/16/20 3:40 PM, Tom Rini wrote:
> > On Mon, Nov 25, 2019 at 05:18:20PM +0100, Giulio Benetti wrote:
> > 
> > > At the moment entry_point is set to image_get_load(header) that sets it
> > > to "load address" instead of "entry point", assuming entry_point is
> > > equal to load_addr, but it's not true. Then load_addr is set to
> > > "entry_point - header_size", but this is wrong too since load_addr is
> > > not an entry point.
> > > 
> > > So use image_get_ep() for entry_point assignment and image_get_load()
> > > for load_addr assignment.
> > > 
> > > Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
> > 
> > Applied to u-boot/master, thanks!
> 
> It's been already committed by Stefano Babic in imx and you've pulled from
> him.
> 
> Sorry that I've submitted it twice!

Ah, I missed git saying there was nothing to do while applying that part
of the mbox.  No worries.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200116/39f65bf7/attachment.sig>

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2020-01-16 14:49 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-25 16:18 [U-Boot] [PATCH] spl: fix entry_point equal to load_addr Giulio Benetti
2019-12-05 22:09 ` Tom Rini
2019-12-06 12:46   ` Patrice CHOTARD
2019-12-06 12:58     ` Simon Goldschmidt
2019-12-06 13:34       ` Tom Rini
2019-12-06 13:37         ` Simon Goldschmidt
2019-12-06 13:44           ` Tom Rini
2019-12-06 13:48         ` Giulio Benetti
2019-12-06 14:04           ` Patrice CHOTARD
2019-12-06 17:23             ` Giulio Benetti
2019-12-06 14:05           ` Simon Goldschmidt
2019-12-06 14:55             ` Tom Rini
2019-12-07 21:28               ` Simon Goldschmidt
2020-01-10 14:57                 ` Giulio Benetti
2020-01-10 21:51                   ` Tom Rini
2020-01-16 14:40 ` Tom Rini
2020-01-16 14:46   ` Giulio Benetti
2020-01-16 14:49     ` Tom Rini

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.