| Message ID | 1347643742-19966-2-git-send-email-jose.goncalves@inov.pt |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
Dear José Miguel Gonçalves, > Jumping to board_init_r is not performed due to a bug on address > computation. Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards. > Relocation offsets are not needed when building SPL. Do they cause any trouble? > Signed-off-by: José Miguel Gonçalves <jose.goncalves@inov.pt> > --- > Changes for v2: > - None > --- > arch/arm/cpu/arm926ejs/start.S | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/cpu/arm926ejs/start.S > b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 > --- a/arch/arm/cpu/arm926ejs/start.S > +++ b/arch/arm/cpu/arm926ejs/start.S > @@ -325,7 +325,7 @@ _nand_boot_ofs: > .word nand_boot > #else > ldr r0, _board_init_r_ofs > - ldr r1, _TEXT_BASE > + adr r1, _start > add lr, r0, r1 > add lr, lr, r9 > /* setup parameters for board_init_r */ > @@ -338,12 +338,14 @@ _board_init_r_ofs: > .word board_init_r - _start > #endif > > +#ifndef CONFIG_SPL_BUILD > _rel_dyn_start_ofs: > .word __rel_dyn_start - _start > _rel_dyn_end_ofs: > .word __rel_dyn_end - _start > _dynsym_start_ofs: > .word __dynsym_start - _start > +#endif > > /* > ************************************************************************* Best regards, Marek Vasut
On 09/15/2012 07:03 PM, Marek Vasut wrote: > Dear José Miguel Gonçalves, > >> Jumping to board_init_r is not performed due to a bug on address >> computation. > Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any > misbehavior on my arm926 boards. Maybe because you are not using it to build an SPL? Please check the same chunk of code in other start.S for arm1176 and armv7. They have the same code that I put for arm926ejs. > >> Relocation offsets are not needed when building SPL. > Do they cause any trouble? No! Just not needed. > >> Signed-off-by: José Miguel Gonçalves <jose.goncalves@inov.pt> >> --- >> Changes for v2: >> - None >> --- >> arch/arm/cpu/arm926ejs/start.S | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm/cpu/arm926ejs/start.S >> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 >> --- a/arch/arm/cpu/arm926ejs/start.S >> +++ b/arch/arm/cpu/arm926ejs/start.S >> @@ -325,7 +325,7 @@ _nand_boot_ofs: >> .word nand_boot >> #else >> ldr r0, _board_init_r_ofs >> - ldr r1, _TEXT_BASE >> + adr r1, _start >> add lr, r0, r1 >> add lr, lr, r9 >> /* setup parameters for board_init_r */ >> @@ -338,12 +338,14 @@ _board_init_r_ofs: >> .word board_init_r - _start >> #endif >> >> +#ifndef CONFIG_SPL_BUILD >> _rel_dyn_start_ofs: >> .word __rel_dyn_start - _start >> _rel_dyn_end_ofs: >> .word __rel_dyn_end - _start >> _dynsym_start_ofs: >> .word __dynsym_start - _start >> +#endif >> >> /* >> ************************************************************************* > Best regards, > Marek Vasut > Best regards, José Gonçalves
Dear José Miguel Gonçalves, > On 09/15/2012 07:03 PM, Marek Vasut wrote: > > Dear José Miguel Gonçalves, > > > >> Jumping to board_init_r is not performed due to a bug on address > >> computation. > > > > Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any > > misbehavior on my arm926 boards. > > Maybe because you are not using it to build an SPL? I do ... and I use CONFIG_SPL_TEXT_BASE properly . > Please check the same chunk of code in other start.S for arm1176 and > armv7. They have the same code that I put for arm926ejs. Please wait and please first explain what is the issue. > >> Relocation offsets are not needed when building SPL. > > > > Do they cause any trouble? > > No! Just not needed. > > >> Signed-off-by: José Miguel Gonçalves <jose.goncalves@inov.pt> > >> --- > >> > >> Changes for v2: > >> - None > >> > >> --- > >> > >> arch/arm/cpu/arm926ejs/start.S | 4 +++- > >> 1 file changed, 3 insertions(+), 1 deletion(-) > >> > >> diff --git a/arch/arm/cpu/arm926ejs/start.S > >> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 > >> --- a/arch/arm/cpu/arm926ejs/start.S > >> +++ b/arch/arm/cpu/arm926ejs/start.S > >> > >> @@ -325,7 +325,7 @@ _nand_boot_ofs: > >> .word nand_boot > >> > >> #else > >> > >> ldr r0, _board_init_r_ofs > >> > >> - ldr r1, _TEXT_BASE > >> + adr r1, _start > >> > >> add lr, r0, r1 > >> add lr, lr, r9 > >> /* setup parameters for board_init_r */ > >> > >> @@ -338,12 +338,14 @@ _board_init_r_ofs: > >> .word board_init_r - _start > >> > >> #endif > >> > >> +#ifndef CONFIG_SPL_BUILD > >> > >> _rel_dyn_start_ofs: > >> .word __rel_dyn_start - _start > >> > >> _rel_dyn_end_ofs: > >> .word __rel_dyn_end - _start > >> > >> _dynsym_start_ofs: > >> .word __dynsym_start - _start > >> > >> +#endif > >> > >> /* > >> > >> ********************************************************************* > >> **** > > > > Best regards, > > Marek Vasut > > Best regards, > José Gonçalves Best regards, Marek Vasut
On 09/16/2012 11:06 AM, Marek Vasut wrote: > Dear José Miguel Gonçalves, > >> On 09/15/2012 07:03 PM, Marek Vasut wrote: >>> Dear José Miguel Gonçalves, >>> >>>> Jumping to board_init_r is not performed due to a bug on address >>>> computation. >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any >>> misbehavior on my arm926 boards. >> Maybe because you are not using it to build an SPL? > I do ... and I use CONFIG_SPL_TEXT_BASE properly . > >> Please check the same chunk of code in other start.S for arm1176 and >> armv7. They have the same code that I put for arm926ejs. > Please wait and please first explain what is the issue. The issue is what I've explained in the patch comments. Without this change the code never reaches board_init_r in the SPL and I think I have all the configurations correctly set. If the bug is not from here please suggest me what I need to change in the configuration in order to correctly boot my board. > >>>> Relocation offsets are not needed when building SPL. >>> Do they cause any trouble? >> No! Just not needed. >> >>>> Signed-off-by: José Miguel Gonçalves <jose.goncalves@inov.pt> >>>> --- >>>> >>>> Changes for v2: >>>> - None >>>> >>>> --- >>>> >>>> arch/arm/cpu/arm926ejs/start.S | 4 +++- >>>> 1 file changed, 3 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/arch/arm/cpu/arm926ejs/start.S >>>> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 >>>> --- a/arch/arm/cpu/arm926ejs/start.S >>>> +++ b/arch/arm/cpu/arm926ejs/start.S >>>> >>>> @@ -325,7 +325,7 @@ _nand_boot_ofs: >>>> .word nand_boot >>>> >>>> #else >>>> >>>> ldr r0, _board_init_r_ofs >>>> >>>> - ldr r1, _TEXT_BASE >>>> + adr r1, _start >>>> >>>> add lr, r0, r1 >>>> add lr, lr, r9 >>>> /* setup parameters for board_init_r */ >>>> >>>> @@ -338,12 +338,14 @@ _board_init_r_ofs: >>>> .word board_init_r - _start >>>> >>>> #endif >>>> >>>> +#ifndef CONFIG_SPL_BUILD >>>> >>>> _rel_dyn_start_ofs: >>>> .word __rel_dyn_start - _start >>>> >>>> _rel_dyn_end_ofs: >>>> .word __rel_dyn_end - _start >>>> >>>> _dynsym_start_ofs: >>>> .word __dynsym_start - _start >>>> >>>> +#endif >>>> >>>> /* >>>> >>>> ********************************************************************* >>>> **** >>> Best regards, >>> Marek Vasut >> Best regards, >> José Gonçalves > Best regards, > Marek Vasut Best regards, José Gonçalves
Dear José Miguel Gonçalves, > On 09/16/2012 11:06 AM, Marek Vasut wrote: > > Dear José Miguel Gonçalves, > > > >> On 09/15/2012 07:03 PM, Marek Vasut wrote: > >>> Dear José Miguel Gonçalves, > >>> > >>>> Jumping to board_init_r is not performed due to a bug on address > >>>> computation. > >>> > >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any > >>> misbehavior on my arm926 boards. > >> > >> Maybe because you are not using it to build an SPL? > > > > I do ... and I use CONFIG_SPL_TEXT_BASE properly . > > >> Please check the same chunk of code in other start.S for arm1176 and > >> armv7. They have the same code that I put for arm926ejs. > > > > Please wait and please first explain what is the issue. > > The issue is what I've explained in the patch comments. "Jumping to board_init_r is not performed due to a bug on address computation." Ok, I don't know how to replicate the bug from this comment or what effects it causes or ... well, anything. So please, try to be more elaborate in your patch description next time. Anyway .. > Without this > change the code never reaches board_init_r in the SPL and I think I have > all the configurations correctly set. I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only to load the real U-Boot from whatever media, so you usually use either NAND SPL or something like that. What do you boot the rest from ? > If the bug is not from here please > suggest me what I need to change in the configuration in order to > correctly boot my board. > > >>>> Relocation offsets are not needed when building SPL. > >>> > >>> Do they cause any trouble? > >> > >> No! Just not needed. > >> > >>>> Signed-off-by: José Miguel Gonçalves <jose.goncalves@inov.pt> > >>>> --- > >>>> > >>>> Changes for v2: > >>>> - None > >>>> > >>>> --- > >>>> > >>>> arch/arm/cpu/arm926ejs/start.S | 4 +++- > >>>> 1 file changed, 3 insertions(+), 1 deletion(-) > >>>> > >>>> diff --git a/arch/arm/cpu/arm926ejs/start.S > >>>> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 > >>>> --- a/arch/arm/cpu/arm926ejs/start.S > >>>> +++ b/arch/arm/cpu/arm926ejs/start.S > >>>> > >>>> @@ -325,7 +325,7 @@ _nand_boot_ofs: > >>>> .word nand_boot > >>>> > >>>> #else > >>>> > >>>> ldr r0, _board_init_r_ofs > >>>> > >>>> - ldr r1, _TEXT_BASE > >>>> + adr r1, _start > >>>> > >>>> add lr, r0, r1 > >>>> add lr, lr, r9 > >>>> /* setup parameters for board_init_r */ > >>>> > >>>> @@ -338,12 +338,14 @@ _board_init_r_ofs: > >>>> .word board_init_r - _start > >>>> > >>>> #endif > >>>> > >>>> +#ifndef CONFIG_SPL_BUILD > >>>> > >>>> _rel_dyn_start_ofs: > >>>> .word __rel_dyn_start - _start > >>>> > >>>> _rel_dyn_end_ofs: > >>>> .word __rel_dyn_end - _start > >>>> > >>>> _dynsym_start_ofs: > >>>> .word __dynsym_start - _start > >>>> > >>>> +#endif > >>>> > >>>> /* > >>>> > >>>> ****************************************************************** > >>>> *** **** > >>> > >>> Best regards, > >>> Marek Vasut > >> > >> Best regards, > >> José Gonçalves > > > > Best regards, > > Marek Vasut > > Best regards, > José Gonçalves
On 09/16/2012 04:36 PM, Marek Vasut wrote: > Dear José Miguel Gonçalves, > >> On 09/16/2012 11:06 AM, Marek Vasut wrote: >>> Dear José Miguel Gonçalves, >>> >>>> On 09/15/2012 07:03 PM, Marek Vasut wrote: >>>>> Dear José Miguel Gonçalves, >>>>> >>>>>> Jumping to board_init_r is not performed due to a bug on address >>>>>> computation. >>>>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any >>>>> misbehavior on my arm926 boards. >>>> Maybe because you are not using it to build an SPL? >>> I do ... and I use CONFIG_SPL_TEXT_BASE properly . >>>> Please check the same chunk of code in other start.S for arm1176 and >>>> armv7. They have the same code that I put for arm926ejs. >>> Please wait and please first explain what is the issue. >> The issue is what I've explained in the patch comments. > "Jumping to board_init_r is not performed due to a bug on address computation." > > Ok, I don't know how to replicate the bug from this comment or what effects it > causes or ... well, anything. So please, try to be more elaborate in your patch > description next time. Anyway .. My bad. I should be more explicit on the patch description. >> Without this >> change the code never reaches board_init_r in the SPL and I think I have >> all the configurations correctly set. > I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only > to load the real U-Boot from whatever media, so you usually use either NAND SPL > or something like that. > > What do you boot the rest from ? Both SPL and U-Boot are in NAND Flash. The board's SPL code in board/boardcon/mini2416/mini2416_spl.c that needs this patch was based on existing code from arch/arm/cpu/arm926ejs/davinci/spl.c and arm/cpu/armv7/omap-common/spl.c The need to call relocate_code() in board_init_f() is explained on the SPL source comment, i.e., only to initialize .bss before we could use it in board_init_r() (in the serial driver initialization). > >> If the bug is not from here please >> suggest me what I need to change in the configuration in order to >> correctly boot my board. >> >>>>>> Relocation offsets are not needed when building SPL. >>>>> Do they cause any trouble? >>>> No! Just not needed. >>>> >>>>>> Signed-off-by: José Miguel Gonçalves <jose.goncalves@inov.pt> >>>>>> --- >>>>>> >>>>>> Changes for v2: >>>>>> - None >>>>>> >>>>>> --- >>>>>> >>>>>> arch/arm/cpu/arm926ejs/start.S | 4 +++- >>>>>> 1 file changed, 3 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/arch/arm/cpu/arm926ejs/start.S >>>>>> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 >>>>>> --- a/arch/arm/cpu/arm926ejs/start.S >>>>>> +++ b/arch/arm/cpu/arm926ejs/start.S >>>>>> >>>>>> @@ -325,7 +325,7 @@ _nand_boot_ofs: >>>>>> .word nand_boot >>>>>> >>>>>> #else >>>>>> >>>>>> ldr r0, _board_init_r_ofs >>>>>> >>>>>> - ldr r1, _TEXT_BASE >>>>>> + adr r1, _start >>>>>> >>>>>> add lr, r0, r1 >>>>>> add lr, lr, r9 >>>>>> /* setup parameters for board_init_r */ >>>>>> >>>>>> @@ -338,12 +338,14 @@ _board_init_r_ofs: >>>>>> .word board_init_r - _start >>>>>> >>>>>> #endif >>>>>> >>>>>> +#ifndef CONFIG_SPL_BUILD >>>>>> >>>>>> _rel_dyn_start_ofs: >>>>>> .word __rel_dyn_start - _start >>>>>> >>>>>> _rel_dyn_end_ofs: >>>>>> .word __rel_dyn_end - _start >>>>>> >>>>>> _dynsym_start_ofs: >>>>>> .word __dynsym_start - _start >>>>>> >>>>>> +#endif >>>>>> >>>>>> /* >>>>>> >>>>>> ****************************************************************** >>>>>> *** **** >>>>> Best regards, >>>>> Marek Vasut >>>> Best regards, >>>> José Gonçalves >>> Best regards, >>> Marek Vasut >> Best regards, >> José Gonçalves
Dear José Miguel Gonçalves, > On 09/16/2012 04:36 PM, Marek Vasut wrote: > > Dear José Miguel Gonçalves, > > > >> On 09/16/2012 11:06 AM, Marek Vasut wrote: > >>> Dear José Miguel Gonçalves, > >>> > >>>> On 09/15/2012 07:03 PM, Marek Vasut wrote: > >>>>> Dear José Miguel Gonçalves, > >>>>> > >>>>>> Jumping to board_init_r is not performed due to a bug on address > >>>>>> computation. > >>>>> > >>>>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any > >>>>> misbehavior on my arm926 boards. > >>>> > >>>> Maybe because you are not using it to build an SPL? > >>> > >>> I do ... and I use CONFIG_SPL_TEXT_BASE properly . > >>> > >>>> Please check the same chunk of code in other start.S for arm1176 and > >>>> armv7. They have the same code that I put for arm926ejs. > >>> > >>> Please wait and please first explain what is the issue. > >> > >> The issue is what I've explained in the patch comments. > > > > "Jumping to board_init_r is not performed due to a bug on address > > computation." > > > > Ok, I don't know how to replicate the bug from this comment or what > > effects it causes or ... well, anything. So please, try to be more > > elaborate in your patch description next time. Anyway .. > > My bad. I should be more explicit on the patch description. > > >> Without this > >> change the code never reaches board_init_r in the SPL and I think I have > >> all the configurations correctly set. > > > > I wonder why you'd ever want to reach board_init_r in the SPL. SPL is > > there only to load the real U-Boot from whatever media, so you usually > > use either NAND SPL or something like that. > > > > What do you boot the rest from ? > > Both SPL and U-Boot are in NAND Flash. > > The board's SPL code in board/boardcon/mini2416/mini2416_spl.c that > needs this patch was based on existing code from > arch/arm/cpu/arm926ejs/davinci/spl.c and arm/cpu/armv7/omap-common/spl.c CCing Tom, he's the SPL expert. > The need to call relocate_code() in board_init_f() is explained on the > SPL source comment, i.e., only to initialize .bss before we could use it > in board_init_r() (in the serial driver initialization). > > >> If the bug is not from here please > >> suggest me what I need to change in the configuration in order to > >> correctly boot my board. > >> > >>>>>> Relocation offsets are not needed when building SPL. > >>>>> > >>>>> Do they cause any trouble? > >>>> > >>>> No! Just not needed. > >>>> > >>>>>> Signed-off-by: José Miguel Gonçalves <jose.goncalves@inov.pt> > >>>>>> --- > >>>>>> > >>>>>> Changes for v2: > >>>>>> - None > >>>>>> > >>>>>> --- > >>>>>> > >>>>>> arch/arm/cpu/arm926ejs/start.S | 4 +++- > >>>>>> 1 file changed, 3 insertions(+), 1 deletion(-) > >>>>>> > >>>>>> diff --git a/arch/arm/cpu/arm926ejs/start.S > >>>>>> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 > >>>>>> --- a/arch/arm/cpu/arm926ejs/start.S > >>>>>> +++ b/arch/arm/cpu/arm926ejs/start.S > >>>>>> > >>>>>> @@ -325,7 +325,7 @@ _nand_boot_ofs: > >>>>>> .word nand_boot > >>>>>> > >>>>>> #else > >>>>>> > >>>>>> ldr r0, _board_init_r_ofs > >>>>>> > >>>>>> - ldr r1, _TEXT_BASE > >>>>>> + adr r1, _start > >>>>>> > >>>>>> add lr, r0, r1 > >>>>>> add lr, lr, r9 > >>>>>> /* setup parameters for board_init_r */ > >>>>>> > >>>>>> @@ -338,12 +338,14 @@ _board_init_r_ofs: > >>>>>> .word board_init_r - _start > >>>>>> > >>>>>> #endif > >>>>>> > >>>>>> +#ifndef CONFIG_SPL_BUILD > >>>>>> > >>>>>> _rel_dyn_start_ofs: > >>>>>> .word __rel_dyn_start - _start > >>>>>> > >>>>>> _rel_dyn_end_ofs: > >>>>>> .word __rel_dyn_end - _start > >>>>>> > >>>>>> _dynsym_start_ofs: > >>>>>> .word __dynsym_start - _start > >>>>>> > >>>>>> +#endif > >>>>>> > >>>>>> /* > >>>>>> > >>>>>> *************************************************************** > >>>>>> *** *** **** > >>>>> > >>>>> Best regards, > >>>>> Marek Vasut > >>>> > >>>> Best regards, > >>>> José Gonçalves > >>> > >>> Best regards, > >>> Marek Vasut > >> > >> Best regards, > >> José Gonçalves
Hi, On Sun, Sep 16, 2012 at 5:36 PM, Marek Vasut <marex@denx.de> wrote: > Dear José Miguel Gonçalves, > >> On 09/16/2012 11:06 AM, Marek Vasut wrote: >> > Dear José Miguel Gonçalves, >> > >> >> On 09/15/2012 07:03 PM, Marek Vasut wrote: >> >>> Dear José Miguel Gonçalves, >> >>> >> >>>> Jumping to board_init_r is not performed due to a bug on address >> >>>> computation. >> >>> >> >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any >> >>> misbehavior on my arm926 boards. >> >> >> >> Maybe because you are not using it to build an SPL? >> > >> > I do ... and I use CONFIG_SPL_TEXT_BASE properly . >> >> >> Please check the same chunk of code in other start.S for arm1176 and >> >> armv7. They have the same code that I put for arm926ejs. >> > >> > Please wait and please first explain what is the issue. >> >> The issue is what I've explained in the patch comments. > > "Jumping to board_init_r is not performed due to a bug on address computation." > > Ok, I don't know how to replicate the bug from this comment or what effects it > causes or ... well, anything. So please, try to be more elaborate in your patch > description next time. Anyway .. Same for me - I have no idea what you are trying to fix here. In my SPL configuration, _TEXT_BASE and _start point to the same location, so please explain why they are different on your board. >> Without this >> change the code never reaches board_init_r in the SPL and I think I have >> all the configurations correctly set. > > I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only > to load the real U-Boot from whatever media, so you usually use either NAND SPL > or something like that. > Marek, going into board_init_r is fine for SPL, for example the davinci SPL does some hw initialization in board_init_f and then loads u-boot in board_init_r. Regards, Christian > What do you boot the rest from ? > >> If the bug is not from here please >> suggest me what I need to change in the configuration in order to >> correctly boot my board. >> >> >>>> Relocation offsets are not needed when building SPL. >> >>> >> >>> Do they cause any trouble? >> >> >> >> No! Just not needed. >> >> >> >>>> Signed-off-by: José Miguel Gonçalves <jose.goncalves@inov.pt> >> >>>> --- >> >>>> >> >>>> Changes for v2: >> >>>> - None >> >>>> >> >>>> --- >> >>>> >> >>>> arch/arm/cpu/arm926ejs/start.S | 4 +++- >> >>>> 1 file changed, 3 insertions(+), 1 deletion(-) >> >>>> >> >>>> diff --git a/arch/arm/cpu/arm926ejs/start.S >> >>>> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 >> >>>> --- a/arch/arm/cpu/arm926ejs/start.S >> >>>> +++ b/arch/arm/cpu/arm926ejs/start.S >> >>>> >> >>>> @@ -325,7 +325,7 @@ _nand_boot_ofs: >> >>>> .word nand_boot >> >>>> >> >>>> #else >> >>>> >> >>>> ldr r0, _board_init_r_ofs >> >>>> >> >>>> - ldr r1, _TEXT_BASE >> >>>> + adr r1, _start >> >>>> >> >>>> add lr, r0, r1 >> >>>> add lr, lr, r9 >> >>>> /* setup parameters for board_init_r */ >> >>>> >> >>>> @@ -338,12 +338,14 @@ _board_init_r_ofs: >> >>>> .word board_init_r - _start >> >>>> >> >>>> #endif >> >>>> >> >>>> +#ifndef CONFIG_SPL_BUILD >> >>>> >> >>>> _rel_dyn_start_ofs: >> >>>> .word __rel_dyn_start - _start >> >>>> >> >>>> _rel_dyn_end_ofs: >> >>>> .word __rel_dyn_end - _start >> >>>> >> >>>> _dynsym_start_ofs: >> >>>> .word __dynsym_start - _start >> >>>> >> >>>> +#endif >> >>>> >> >>>> /* >> >>>> >> >>>> ****************************************************************** >> >>>> *** **** >> >>> >> >>> Best regards, >> >>> Marek Vasut >> >> >> >> Best regards, >> >> José Gonçalves >> > >> > Best regards, >> > Marek Vasut >> >> Best regards, >> José Gonçalves > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot
On 09/17/2012 07:28 AM, Christian Riesch wrote: > Hi, > > On Sun, Sep 16, 2012 at 5:36 PM, Marek Vasut <marex@denx.de> wrote: >> Dear José Miguel Gonçalves, >> >>> On 09/16/2012 11:06 AM, Marek Vasut wrote: >>>> Dear José Miguel Gonçalves, >>>> >>>>> On 09/15/2012 07:03 PM, Marek Vasut wrote: >>>>>> Dear José Miguel Gonçalves, >>>>>> >>>>>>> Jumping to board_init_r is not performed due to a bug on address >>>>>>> computation. >>>>>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any >>>>>> misbehavior on my arm926 boards. >>>>> Maybe because you are not using it to build an SPL? >>>> I do ... and I use CONFIG_SPL_TEXT_BASE properly . >>>>> Please check the same chunk of code in other start.S for arm1176 and >>>>> armv7. They have the same code that I put for arm926ejs. >>>> Please wait and please first explain what is the issue. >>> The issue is what I've explained in the patch comments. >> "Jumping to board_init_r is not performed due to a bug on address computation." >> >> Ok, I don't know how to replicate the bug from this comment or what effects it >> causes or ... well, anything. So please, try to be more elaborate in your patch >> description next time. Anyway .. > Same for me - I have no idea what you are trying to fix here. In my > SPL configuration, _TEXT_BASE and _start point to the same location, > so please explain why they are different on your board. They are different because of how start.S is implemented in arm926ejs. In my SPL map file I see: .text 0x0000000000000000 0xc24 arch/arm/cpu/arm926ejs/start.o(.text) .text 0x0000000000000000 0x120 arch/arm/cpu/arm926ejs/start.o 0x0000000000000000 _start 0x0000000000000040 _TEXT_BASE 0x0000000000000044 _bss_start_ofs 0x0000000000000048 _bss_end_ofs 0x000000000000004c _end_ofs 0x0000000000000050 IRQ_STACK_START_IN 0x0000000000000074 relocate_code >>> Without this >>> change the code never reaches board_init_r in the SPL and I think I have >>> all the configurations correctly set. >> I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only >> to load the real U-Boot from whatever media, so you usually use either NAND SPL >> or something like that. >> > Marek, going into board_init_r is fine for SPL, for example the > davinci SPL does some hw initialization in board_init_f and then loads > u-boot in board_init_r. > Regards, Christian > >> What do you boot the rest from ? >> >>> If the bug is not from here please >>> suggest me what I need to change in the configuration in order to >>> correctly boot my board. >>> >>>>>>> Relocation offsets are not needed when building SPL. >>>>>> Do they cause any trouble? >>>>> No! Just not needed. >>>>> >>>>>>> Signed-off-by: José Miguel Gonçalves <jose.goncalves@inov.pt> >>>>>>> --- >>>>>>> >>>>>>> Changes for v2: >>>>>>> - None >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> arch/arm/cpu/arm926ejs/start.S | 4 +++- >>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-) >>>>>>> >>>>>>> diff --git a/arch/arm/cpu/arm926ejs/start.S >>>>>>> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 >>>>>>> --- a/arch/arm/cpu/arm926ejs/start.S >>>>>>> +++ b/arch/arm/cpu/arm926ejs/start.S >>>>>>> >>>>>>> @@ -325,7 +325,7 @@ _nand_boot_ofs: >>>>>>> .word nand_boot >>>>>>> >>>>>>> #else >>>>>>> >>>>>>> ldr r0, _board_init_r_ofs >>>>>>> >>>>>>> - ldr r1, _TEXT_BASE >>>>>>> + adr r1, _start >>>>>>> >>>>>>> add lr, r0, r1 >>>>>>> add lr, lr, r9 >>>>>>> /* setup parameters for board_init_r */ >>>>>>> >>>>>>> @@ -338,12 +338,14 @@ _board_init_r_ofs: >>>>>>> .word board_init_r - _start >>>>>>> >>>>>>> #endif >>>>>>> >>>>>>> +#ifndef CONFIG_SPL_BUILD >>>>>>> >>>>>>> _rel_dyn_start_ofs: >>>>>>> .word __rel_dyn_start - _start >>>>>>> >>>>>>> _rel_dyn_end_ofs: >>>>>>> .word __rel_dyn_end - _start >>>>>>> >>>>>>> _dynsym_start_ofs: >>>>>>> .word __dynsym_start - _start >>>>>>> >>>>>>> +#endif >>>>>>> >>>>>>> /* >>>>>>> >>>>>>> ****************************************************************** >>>>>>> *** **** >>>>>> Best regards, >>>>>> Marek Vasut >>>>> Best regards, >>>>> José Gonçalves >>>> Best regards, >>>> Marek Vasut >>> Best regards, >>> José Gonçalves Best regards, José Gonçalves
Hi, On Mon, Sep 17, 2012 at 10:34 AM, José Miguel Gonçalves <jose.goncalves@inov.pt> wrote: > On 09/17/2012 07:28 AM, Christian Riesch wrote: >> >> Hi, >> >> On Sun, Sep 16, 2012 at 5:36 PM, Marek Vasut <marex@denx.de> wrote: >>> >>> Dear José Miguel Gonçalves, >>> >>>> On 09/16/2012 11:06 AM, Marek Vasut wrote: >>>>> >>>>> Dear José Miguel Gonçalves, >>>>> >>>>>> On 09/15/2012 07:03 PM, Marek Vasut wrote: >>>>>>> >>>>>>> Dear José Miguel Gonçalves, >>>>>>> >>>>>>>> Jumping to board_init_r is not performed due to a bug on address >>>>>>>> computation. >>>>>>> >>>>>>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any >>>>>>> misbehavior on my arm926 boards. >>>>>> >>>>>> Maybe because you are not using it to build an SPL? >>>>> >>>>> I do ... and I use CONFIG_SPL_TEXT_BASE properly . >>>>>> >>>>>> Please check the same chunk of code in other start.S for arm1176 and >>>>>> armv7. They have the same code that I put for arm926ejs. >>>>> >>>>> Please wait and please first explain what is the issue. >>>> >>>> The issue is what I've explained in the patch comments. >>> >>> "Jumping to board_init_r is not performed due to a bug on address >>> computation." >>> >>> Ok, I don't know how to replicate the bug from this comment or what >>> effects it >>> causes or ... well, anything. So please, try to be more elaborate in your >>> patch >>> description next time. Anyway .. >> >> Same for me - I have no idea what you are trying to fix here. In my >> SPL configuration, _TEXT_BASE and _start point to the same location, >> so please explain why they are different on your board. > > > They are different because of how start.S is implemented in arm926ejs. > > In my SPL map file I see: > > .text 0x0000000000000000 0xc24 > arch/arm/cpu/arm926ejs/start.o(.text) > .text 0x0000000000000000 0x120 arch/arm/cpu/arm926ejs/start.o > 0x0000000000000000 _start > 0x0000000000000040 _TEXT_BASE > 0x0000000000000044 _bss_start_ofs > 0x0000000000000048 _bss_end_ofs > 0x000000000000004c _end_ofs > 0x0000000000000050 IRQ_STACK_START_IN > 0x0000000000000074 relocate_code So _start is 0x00000000, and in your config/include/include/configs/mini2416.h you have #define CONFIG_SPL_TEXT_BASE 0x00000000 and in arch/arm/cpu/arm926ejs/start.S we have .globl _TEXT_BASE _TEXT_BASE: #ifdef CONFIG_NAND_SPL /* deprecated, use instead CONFIG_SPL_BUILD */ .word CONFIG_SYS_TEXT_BASE #else #ifdef CONFIG_SPL_BUILD .word CONFIG_SPL_TEXT_BASE #else .word CONFIG_SYS_TEXT_BASE #endif #endif So ldr r1, _TEXT_BASE should be the same as adr r1, _start However, if you do not load your SPL to 0x00000000 but to another address and execute it from there, it will be different, since adr uses relative adressing, right? Are you sure you are loading it to 0x00000000? Regards, Christian > > > >>>> Without this >>>> change the code never reaches board_init_r in the SPL and I think I have >>>> all the configurations correctly set. >>> >>> I wonder why you'd ever want to reach board_init_r in the SPL. SPL is >>> there only >>> to load the real U-Boot from whatever media, so you usually use either >>> NAND SPL >>> or something like that. >>> >> Marek, going into board_init_r is fine for SPL, for example the >> davinci SPL does some hw initialization in board_init_f and then loads >> u-boot in board_init_r. >> Regards, Christian >> >>> What do you boot the rest from ? >>> >>>> If the bug is not from here please >>>> suggest me what I need to change in the configuration in order to >>>> correctly boot my board. >>>> >>>>>>>> Relocation offsets are not needed when building SPL. >>>>>>> >>>>>>> Do they cause any trouble? >>>>>> >>>>>> No! Just not needed. >>>>>> >>>>>>>> Signed-off-by: José Miguel Gonçalves <jose.goncalves@inov.pt> >>>>>>>> --- >>>>>>>> >>>>>>>> Changes for v2: >>>>>>>> - None >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> arch/arm/cpu/arm926ejs/start.S | 4 +++- >>>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-) >>>>>>>> >>>>>>>> diff --git a/arch/arm/cpu/arm926ejs/start.S >>>>>>>> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 >>>>>>>> --- a/arch/arm/cpu/arm926ejs/start.S >>>>>>>> +++ b/arch/arm/cpu/arm926ejs/start.S >>>>>>>> >>>>>>>> @@ -325,7 +325,7 @@ _nand_boot_ofs: >>>>>>>> .word nand_boot >>>>>>>> >>>>>>>> #else >>>>>>>> >>>>>>>> ldr r0, _board_init_r_ofs >>>>>>>> >>>>>>>> - ldr r1, _TEXT_BASE >>>>>>>> + adr r1, _start >>>>>>>> >>>>>>>> add lr, r0, r1 >>>>>>>> add lr, lr, r9 >>>>>>>> /* setup parameters for board_init_r */ >>>>>>>> >>>>>>>> @@ -338,12 +338,14 @@ _board_init_r_ofs: >>>>>>>> .word board_init_r - _start >>>>>>>> >>>>>>>> #endif >>>>>>>> >>>>>>>> +#ifndef CONFIG_SPL_BUILD >>>>>>>> >>>>>>>> _rel_dyn_start_ofs: >>>>>>>> .word __rel_dyn_start - _start >>>>>>>> >>>>>>>> _rel_dyn_end_ofs: >>>>>>>> .word __rel_dyn_end - _start >>>>>>>> >>>>>>>> _dynsym_start_ofs: >>>>>>>> .word __dynsym_start - _start >>>>>>>> >>>>>>>> +#endif >>>>>>>> >>>>>>>> /* >>>>>>>> >>>>>>>> >>>>>>>> ****************************************************************** >>>>>>>> *** **** >>>>>>> >>>>>>> Best regards, >>>>>>> Marek Vasut >>>>>> >>>>>> Best regards, >>>>>> José Gonçalves >>>>> >>>>> Best regards, >>>>> Marek Vasut >>>> >>>> Best regards, >>>> José Gonçalves > > > Best regards, > José Gonçalves > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot
Hi Christian, On 09/17/2012 10:03 AM, Christian Riesch wrote: > Hi, > > On Mon, Sep 17, 2012 at 10:34 AM, José Miguel Gonçalves > <jose.goncalves@inov.pt> wrote: >> On 09/17/2012 07:28 AM, Christian Riesch wrote: >>> Hi, >>> >>> On Sun, Sep 16, 2012 at 5:36 PM, Marek Vasut <marex@denx.de> wrote: >>>> Dear José Miguel Gonçalves, >>>> >>>>> On 09/16/2012 11:06 AM, Marek Vasut wrote: >>>>>> Dear José Miguel Gonçalves, >>>>>> >>>>>>> On 09/15/2012 07:03 PM, Marek Vasut wrote: >>>>>>>> Dear José Miguel Gonçalves, >>>>>>>> >>>>>>>>> Jumping to board_init_r is not performed due to a bug on address >>>>>>>>> computation. >>>>>>>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any >>>>>>>> misbehavior on my arm926 boards. >>>>>>> Maybe because you are not using it to build an SPL? >>>>>> I do ... and I use CONFIG_SPL_TEXT_BASE properly . >>>>>>> Please check the same chunk of code in other start.S for arm1176 and >>>>>>> armv7. They have the same code that I put for arm926ejs. >>>>>> Please wait and please first explain what is the issue. >>>>> The issue is what I've explained in the patch comments. >>>> "Jumping to board_init_r is not performed due to a bug on address >>>> computation." >>>> >>>> Ok, I don't know how to replicate the bug from this comment or what >>>> effects it >>>> causes or ... well, anything. So please, try to be more elaborate in your >>>> patch >>>> description next time. Anyway .. >>> Same for me - I have no idea what you are trying to fix here. In my >>> SPL configuration, _TEXT_BASE and _start point to the same location, >>> so please explain why they are different on your board. >> >> They are different because of how start.S is implemented in arm926ejs. >> >> In my SPL map file I see: >> >> .text 0x0000000000000000 0xc24 >> arch/arm/cpu/arm926ejs/start.o(.text) >> .text 0x0000000000000000 0x120 arch/arm/cpu/arm926ejs/start.o >> 0x0000000000000000 _start >> 0x0000000000000040 _TEXT_BASE >> 0x0000000000000044 _bss_start_ofs >> 0x0000000000000048 _bss_end_ofs >> 0x000000000000004c _end_ofs >> 0x0000000000000050 IRQ_STACK_START_IN >> 0x0000000000000074 relocate_code > So _start is 0x00000000, and in your > config/include/include/configs/mini2416.h you have > > #define CONFIG_SPL_TEXT_BASE 0x00000000 > > and in arch/arm/cpu/arm926ejs/start.S we have > > .globl _TEXT_BASE > _TEXT_BASE: > #ifdef CONFIG_NAND_SPL /* deprecated, use instead CONFIG_SPL_BUILD */ > .word CONFIG_SYS_TEXT_BASE > #else > #ifdef CONFIG_SPL_BUILD > .word CONFIG_SPL_TEXT_BASE > #else > .word CONFIG_SYS_TEXT_BASE > #endif > #endif > > So > > ldr r1, _TEXT_BASE > > should be the same as > > adr r1, _start > > However, if you do not load your SPL to 0x00000000 but to another > address and execute it from there, it will be different, since adr > uses relative adressing, right? Are you sure you are loading it to > 0x00000000? Not an expert on ARM assembly, so cannot give any feedback on the differences between adr and ldr mnemonics. What I know for a fact is that the S3C2416, when booting from it's internal ROM, makes a copy of the first 8KB of the NAND flash to an internal RAM (named SteppingStone), maps it at address 0 and the jumps to the start of it. This mapping is not clear in Samsung's user manual but I retrieved that information from here: http://barebox.org/documentation/barebox-2011.05.0/dev_s3c24xx_arch.html > > Regards, Christian > >> >> >>>>> Without this >>>>> change the code never reaches board_init_r in the SPL and I think I have >>>>> all the configurations correctly set. >>>> I wonder why you'd ever want to reach board_init_r in the SPL. SPL is >>>> there only >>>> to load the real U-Boot from whatever media, so you usually use either >>>> NAND SPL >>>> or something like that. >>>> >>> Marek, going into board_init_r is fine for SPL, for example the >>> davinci SPL does some hw initialization in board_init_f and then loads >>> u-boot in board_init_r. >>> Regards, Christian >>> >>>> What do you boot the rest from ? >>>> >>>>> If the bug is not from here please >>>>> suggest me what I need to change in the configuration in order to >>>>> correctly boot my board. >>>>> >>>>>>>>> Relocation offsets are not needed when building SPL. >>>>>>>> Do they cause any trouble? >>>>>>> No! Just not needed. >>>>>>> >>>>>>>>> Signed-off-by: José Miguel Gonçalves <jose.goncalves@inov.pt> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> Changes for v2: >>>>>>>>> - None >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> arch/arm/cpu/arm926ejs/start.S | 4 +++- >>>>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-) >>>>>>>>> >>>>>>>>> diff --git a/arch/arm/cpu/arm926ejs/start.S >>>>>>>>> b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 >>>>>>>>> --- a/arch/arm/cpu/arm926ejs/start.S >>>>>>>>> +++ b/arch/arm/cpu/arm926ejs/start.S >>>>>>>>> >>>>>>>>> @@ -325,7 +325,7 @@ _nand_boot_ofs: >>>>>>>>> .word nand_boot >>>>>>>>> >>>>>>>>> #else >>>>>>>>> >>>>>>>>> ldr r0, _board_init_r_ofs >>>>>>>>> >>>>>>>>> - ldr r1, _TEXT_BASE >>>>>>>>> + adr r1, _start >>>>>>>>> >>>>>>>>> add lr, r0, r1 >>>>>>>>> add lr, lr, r9 >>>>>>>>> /* setup parameters for board_init_r */ >>>>>>>>> >>>>>>>>> @@ -338,12 +338,14 @@ _board_init_r_ofs: >>>>>>>>> .word board_init_r - _start >>>>>>>>> >>>>>>>>> #endif >>>>>>>>> >>>>>>>>> +#ifndef CONFIG_SPL_BUILD >>>>>>>>> >>>>>>>>> _rel_dyn_start_ofs: >>>>>>>>> .word __rel_dyn_start - _start >>>>>>>>> >>>>>>>>> _rel_dyn_end_ofs: >>>>>>>>> .word __rel_dyn_end - _start >>>>>>>>> >>>>>>>>> _dynsym_start_ofs: >>>>>>>>> .word __dynsym_start - _start >>>>>>>>> >>>>>>>>> +#endif >>>>>>>>> >>>>>>>>> /* >>>>>>>>> >>>>>>>>> >>>>>>>>> ****************************************************************** >>>>>>>>> *** **** >>>>>>>> Best regards, >>>>>>>> Marek Vasut >>>>>>> Best regards, >>>>>>> José Gonçalves >>>>>> Best regards, >>>>>> Marek Vasut >>>>> Best regards, >>>>> José Gonçalves >> >> Best regards, >> José Gonçalves > Best regards, José Gonçalves
On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote: > Dear Jos? Miguel Gon?alves, > > > On 09/16/2012 11:06 AM, Marek Vasut wrote: > > > Dear Jos? Miguel Gon?alves, > > > > > >> On 09/15/2012 07:03 PM, Marek Vasut wrote: > > >>> Dear Jos? Miguel Gon?alves, > > >>> > > >>>> Jumping to board_init_r is not performed due to a bug on address > > >>>> computation. > > >>> > > >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any > > >>> misbehavior on my arm926 boards. > > >> > > >> Maybe because you are not using it to build an SPL? > > > > > > I do ... and I use CONFIG_SPL_TEXT_BASE properly . > > > > >> Please check the same chunk of code in other start.S for arm1176 and > > >> armv7. They have the same code that I put for arm926ejs. > > > > > > Please wait and please first explain what is the issue. > > > > The issue is what I've explained in the patch comments. > > "Jumping to board_init_r is not performed due to a bug on address computation." > > Ok, I don't know how to replicate the bug from this comment or what effects it > causes or ... well, anything. So please, try to be more elaborate in your patch > description next time. Anyway .. > > > Without this > > change the code never reaches board_init_r in the SPL and I think I have > > all the configurations correctly set. > > I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only > to load the real U-Boot from whatever media, so you usually use either NAND SPL Here's a good point for me to jump in, I think. There's two things to understand: - In the current in-tree SPL implementations the code flow is board_init_f calls relocate_code() to clear the BSS _and_ get our jump to board_init_r. It does not actually relocate the running U-Boot, just clears the BSS. board_init_r is what calls the things to load and boot the next stage (U-Boot or Linux). - In my series this has been changed slightly to be board_init_f calls memset and then board_init_r directly. So this patch should not be needed once rebased on that series.
On 09/17/2012 12:18:31 PM, Tom Rini wrote: > On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote: > > Dear Jos? Miguel Gon?alves, > > > > > On 09/16/2012 11:06 AM, Marek Vasut wrote: > > > > Dear Jos? Miguel Gon?alves, > > > > > > > >> On 09/15/2012 07:03 PM, Marek Vasut wrote: > > > >>> Dear Jos? Miguel Gon?alves, > > > >>> > > > >>>> Jumping to board_init_r is not performed due to a bug on > address > > > >>>> computation. > > > >>> > > > >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't > detect any > > > >>> misbehavior on my arm926 boards. > > > >> > > > >> Maybe because you are not using it to build an SPL? > > > > > > > > I do ... and I use CONFIG_SPL_TEXT_BASE properly . > > > > > > >> Please check the same chunk of code in other start.S for > arm1176 and > > > >> armv7. They have the same code that I put for arm926ejs. > > > > > > > > Please wait and please first explain what is the issue. > > > > > > The issue is what I've explained in the patch comments. > > > > "Jumping to board_init_r is not performed due to a bug on address > computation." > > > > Ok, I don't know how to replicate the bug from this comment or what > effects it > > causes or ... well, anything. So please, try to be more elaborate > in your patch > > description next time. Anyway .. > > > > > Without this > > > change the code never reaches board_init_r in the SPL and I think > I have > > > all the configurations correctly set. > > > > I wonder why you'd ever want to reach board_init_r in the SPL. SPL > is there only > > to load the real U-Boot from whatever media, so you usually use > either NAND SPL > > Here's a good point for me to jump in, I think. There's two things to > understand: > - In the current in-tree SPL implementations the code flow is > board_init_f calls relocate_code() to clear the BSS _and_ get our > jump > to board_init_r. It does not actually relocate the running U-Boot, > just clears the BSS. board_init_r is what calls the things to load > and boot the next stage (U-Boot or Linux). > > - In my series this has been changed slightly to be board_init_f calls > memset and then board_init_r directly. So this patch should not be > needed once rebased on that series. So you've removed the ability to relocate at all? What about hardware where you boot from an I/O buffer, that you need to get out of in order to load more pages? -Scott
Dear Tom Rini, > On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote: > > Dear Jos? Miguel Gon?alves, > > > > > On 09/16/2012 11:06 AM, Marek Vasut wrote: > > > > Dear Jos? Miguel Gon?alves, > > > > > > > >> On 09/15/2012 07:03 PM, Marek Vasut wrote: > > > >>> Dear Jos? Miguel Gon?alves, > > > >>> > > > >>>> Jumping to board_init_r is not performed due to a bug on address > > > >>>> computation. > > > >>> > > > >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect > > > >>> any misbehavior on my arm926 boards. > > > >> > > > >> Maybe because you are not using it to build an SPL? > > > > > > > > I do ... and I use CONFIG_SPL_TEXT_BASE properly . > > > > > > > >> Please check the same chunk of code in other start.S for arm1176 and > > > >> armv7. They have the same code that I put for arm926ejs. > > > > > > > > Please wait and please first explain what is the issue. > > > > > > The issue is what I've explained in the patch comments. > > > > "Jumping to board_init_r is not performed due to a bug on address > > computation." > > > > Ok, I don't know how to replicate the bug from this comment or what > > effects it causes or ... well, anything. So please, try to be more > > elaborate in your patch description next time. Anyway .. > > > > > Without this > > > change the code never reaches board_init_r in the SPL and I think I > > > have all the configurations correctly set. > > > > I wonder why you'd ever want to reach board_init_r in the SPL. SPL is > > there only to load the real U-Boot from whatever media, so you usually > > use either NAND SPL > > Here's a good point for me to jump in, I think. There's two things to > understand: > - In the current in-tree SPL implementations the code flow is > board_init_f calls relocate_code() to clear the BSS _and_ get our jump > to board_init_r. It does not actually relocate the running U-Boot, > just clears the BSS. board_init_r is what calls the things to load > and boot the next stage (U-Boot or Linux). > > - In my series this has been changed slightly to be board_init_f calls > memset and then board_init_r directly. So this patch should not be > needed once rebased on that series. Do we need to do all the relocation in assembler code btw? Can it not be moved into C code and made generic across all platforms (module the stack adjustment and a few minor things) ? Best regards, Marek Vasut
On 17-09-2012 18:18, Tom Rini wrote: > On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote: >> Dear Jos? Miguel Gon?alves, >> >>> On 09/16/2012 11:06 AM, Marek Vasut wrote: >>>> Dear Jos? Miguel Gon?alves, >>>> >>>>> On 09/15/2012 07:03 PM, Marek Vasut wrote: >>>>>> Dear Jos? Miguel Gon?alves, >>>>>> >>>>>>> Jumping to board_init_r is not performed due to a bug on address >>>>>>> computation. >>>>>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any >>>>>> misbehavior on my arm926 boards. >>>>> Maybe because you are not using it to build an SPL? >>>> I do ... and I use CONFIG_SPL_TEXT_BASE properly . >>>>> Please check the same chunk of code in other start.S for arm1176 and >>>>> armv7. They have the same code that I put for arm926ejs. >>>> Please wait and please first explain what is the issue. >>> The issue is what I've explained in the patch comments. >> "Jumping to board_init_r is not performed due to a bug on address computation." >> >> Ok, I don't know how to replicate the bug from this comment or what effects it >> causes or ... well, anything. So please, try to be more elaborate in your patch >> description next time. Anyway .. >> >>> Without this >>> change the code never reaches board_init_r in the SPL and I think I have >>> all the configurations correctly set. >> I wonder why you'd ever want to reach board_init_r in the SPL. SPL is there only >> to load the real U-Boot from whatever media, so you usually use either NAND SPL > Here's a good point for me to jump in, I think. There's two things to > understand: > - In the current in-tree SPL implementations the code flow is > board_init_f calls relocate_code() to clear the BSS _and_ get our jump > to board_init_r. It does not actually relocate the running U-Boot, > just clears the BSS. board_init_r is what calls the things to load > and boot the next stage (U-Boot or Linux). > > - In my series this has been changed slightly to be board_init_f calls > memset and then board_init_r directly. So this patch should not be > needed once rebased on that series. OK Tom. I will start working on rebasing the MINI2416 board support on the new SPL framework. If I have any doubts I will get in touch with you... Best regards, José Gonçalves
On Mon, Sep 17, 2012 at 12:23:53PM -0500, Scott Wood wrote: > On 09/17/2012 12:18:31 PM, Tom Rini wrote: > >On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote: > >> Dear Jos? Miguel Gon?alves, > >> > >> > On 09/16/2012 11:06 AM, Marek Vasut wrote: > >> > > Dear Jos? Miguel Gon?alves, > >> > > > >> > >> On 09/15/2012 07:03 PM, Marek Vasut wrote: > >> > >>> Dear Jos? Miguel Gon?alves, > >> > >>> > >> > >>>> Jumping to board_init_r is not performed due to a bug on > >address > >> > >>>> computation. > >> > >>> > >> > >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't > >detect any > >> > >>> misbehavior on my arm926 boards. > >> > >> > >> > >> Maybe because you are not using it to build an SPL? > >> > > > >> > > I do ... and I use CONFIG_SPL_TEXT_BASE properly . > >> > > >> > >> Please check the same chunk of code in other start.S for > >arm1176 and > >> > >> armv7. They have the same code that I put for arm926ejs. > >> > > > >> > > Please wait and please first explain what is the issue. > >> > > >> > The issue is what I've explained in the patch comments. > >> > >> "Jumping to board_init_r is not performed due to a bug on > >address computation." > >> > >> Ok, I don't know how to replicate the bug from this comment or > >what effects it > >> causes or ... well, anything. So please, try to be more > >elaborate in your patch > >> description next time. Anyway .. > >> > >> > Without this > >> > change the code never reaches board_init_r in the SPL and I > >think I have > >> > all the configurations correctly set. > >> > >> I wonder why you'd ever want to reach board_init_r in the SPL. > >SPL is there only > >> to load the real U-Boot from whatever media, so you usually use > >either NAND SPL > > > >Here's a good point for me to jump in, I think. There's two things to > >understand: > >- In the current in-tree SPL implementations the code flow is > > board_init_f calls relocate_code() to clear the BSS _and_ get > >our jump > > to board_init_r. It does not actually relocate the running U-Boot, > > just clears the BSS. board_init_r is what calls the things to load > > and boot the next stage (U-Boot or Linux). > > > >- In my series this has been changed slightly to be board_init_f calls > > memset and then board_init_r directly. So this patch should not be > > needed once rebased on that series. > > So you've removed the ability to relocate at all? What about > hardware where you boot from an I/O buffer, that you need to get out > of in order to load more pages? Then you do that instead. Getting from board_init_f to _r is setup at the arch level, weakly, and with what it must perform documented.
On Mon, Sep 17, 2012 at 07:26:06PM +0200, Marek Vasut wrote: > Dear Tom Rini, > > > On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote: > > > Dear Jos? Miguel Gon?alves, > > > > > > > On 09/16/2012 11:06 AM, Marek Vasut wrote: > > > > > Dear Jos? Miguel Gon?alves, > > > > > > > > > >> On 09/15/2012 07:03 PM, Marek Vasut wrote: > > > > >>> Dear Jos? Miguel Gon?alves, > > > > >>> > > > > >>>> Jumping to board_init_r is not performed due to a bug on address > > > > >>>> computation. > > > > >>> > > > > >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect > > > > >>> any misbehavior on my arm926 boards. > > > > >> > > > > >> Maybe because you are not using it to build an SPL? > > > > > > > > > > I do ... and I use CONFIG_SPL_TEXT_BASE properly . > > > > > > > > > >> Please check the same chunk of code in other start.S for arm1176 and > > > > >> armv7. They have the same code that I put for arm926ejs. > > > > > > > > > > Please wait and please first explain what is the issue. > > > > > > > > The issue is what I've explained in the patch comments. > > > > > > "Jumping to board_init_r is not performed due to a bug on address > > > computation." > > > > > > Ok, I don't know how to replicate the bug from this comment or what > > > effects it causes or ... well, anything. So please, try to be more > > > elaborate in your patch description next time. Anyway .. > > > > > > > Without this > > > > change the code never reaches board_init_r in the SPL and I think I > > > > have all the configurations correctly set. > > > > > > I wonder why you'd ever want to reach board_init_r in the SPL. SPL is > > > there only to load the real U-Boot from whatever media, so you usually > > > use either NAND SPL > > > > Here's a good point for me to jump in, I think. There's two things to > > understand: > > - In the current in-tree SPL implementations the code flow is > > board_init_f calls relocate_code() to clear the BSS _and_ get our jump > > to board_init_r. It does not actually relocate the running U-Boot, > > just clears the BSS. board_init_r is what calls the things to load > > and boot the next stage (U-Boot or Linux). > > > > - In my series this has been changed slightly to be board_init_f calls > > memset and then board_init_r directly. So this patch should not be > > needed once rebased on that series. > > Do we need to do all the relocation in assembler code btw? Can it not be moved > into C code and made generic across all platforms (module the stack adjustment > and a few minor things) ? I think people have posted patches for this before and yes, once CONFIG_NEEDS_MANUAL_RELOC dies it should be all possible to do in C, so long as it doesn't grow in size or doesn't grow in size that would be problematic (remember the 4kb people).
Dear Tom Rini, > On Mon, Sep 17, 2012 at 07:26:06PM +0200, Marek Vasut wrote: > > Dear Tom Rini, > > > > > On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote: > > > > Dear Jos? Miguel Gon?alves, > > > > > > > > > On 09/16/2012 11:06 AM, Marek Vasut wrote: > > > > > > Dear Jos? Miguel Gon?alves, > > > > > > > > > > > >> On 09/15/2012 07:03 PM, Marek Vasut wrote: > > > > > >>> Dear Jos? Miguel Gon?alves, > > > > > >>> > > > > > >>>> Jumping to board_init_r is not performed due to a bug on > > > > > >>>> address computation. > > > > > >>> > > > > > >>> Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't > > > > > >>> detect any misbehavior on my arm926 boards. > > > > > >> > > > > > >> Maybe because you are not using it to build an SPL? > > > > > > > > > > > > I do ... and I use CONFIG_SPL_TEXT_BASE properly . > > > > > > > > > > > >> Please check the same chunk of code in other start.S for arm1176 > > > > > >> and armv7. They have the same code that I put for arm926ejs. > > > > > > > > > > > > Please wait and please first explain what is the issue. > > > > > > > > > > The issue is what I've explained in the patch comments. > > > > > > > > "Jumping to board_init_r is not performed due to a bug on address > > > > computation." > > > > > > > > Ok, I don't know how to replicate the bug from this comment or what > > > > effects it causes or ... well, anything. So please, try to be more > > > > elaborate in your patch description next time. Anyway .. > > > > > > > > > Without this > > > > > change the code never reaches board_init_r in the SPL and I think I > > > > > have all the configurations correctly set. > > > > > > > > I wonder why you'd ever want to reach board_init_r in the SPL. SPL is > > > > there only to load the real U-Boot from whatever media, so you > > > > usually use either NAND SPL > > > > > > Here's a good point for me to jump in, I think. There's two things to > > > understand: > > > - In the current in-tree SPL implementations the code flow is > > > > > > board_init_f calls relocate_code() to clear the BSS _and_ get our > > > jump to board_init_r. It does not actually relocate the running > > > U-Boot, just clears the BSS. board_init_r is what calls the things > > > to load and boot the next stage (U-Boot or Linux). > > > > > > - In my series this has been changed slightly to be board_init_f calls > > > > > > memset and then board_init_r directly. So this patch should not be > > > needed once rebased on that series. > > > > Do we need to do all the relocation in assembler code btw? Can it not be > > moved into C code and made generic across all platforms (module the > > stack adjustment and a few minor things) ? > > I think people have posted patches for this before and yes, once > CONFIG_NEEDS_MANUAL_RELOC dies it should be all possible to do in C, so > long as it doesn't grow in size or doesn't grow in size that would be > problematic (remember the 4kb people). How does MANUAL_RELOC interfere with that? Eg. on ARM, it can already be shifted to C. Then if we made it generic enough, those MANUAL_RELOC platforms could simply adopt the C code. Best regards, Marek Vasut
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/17/12 10:48, Marek Vasut wrote: > Dear Tom Rini, > >> On Mon, Sep 17, 2012 at 07:26:06PM +0200, Marek Vasut wrote: >>> Dear Tom Rini, >>> >>>> On Sun, Sep 16, 2012 at 05:36:47PM +0200, Marek Vasut wrote: >>>>> Dear Jos? Miguel Gon?alves, >>>>> >>>>>> On 09/16/2012 11:06 AM, Marek Vasut wrote: >>>>>>> Dear Jos? Miguel Gon?alves, >>>>>>> >>>>>>>> On 09/15/2012 07:03 PM, Marek Vasut wrote: >>>>>>>>> Dear Jos? Miguel Gon?alves, >>>>>>>>> >>>>>>>>>> Jumping to board_init_r is not performed due to a >>>>>>>>>> bug on address computation. >>>>>>>>> >>>>>>>>> Is your CONFIG_SYS_TEXT_BASE configured correctly? >>>>>>>>> I don't detect any misbehavior on my arm926 >>>>>>>>> boards. >>>>>>>> >>>>>>>> Maybe because you are not using it to build an SPL? >>>>>>> >>>>>>> I do ... and I use CONFIG_SPL_TEXT_BASE properly . >>>>>>> >>>>>>>> Please check the same chunk of code in other start.S >>>>>>>> for arm1176 and armv7. They have the same code that I >>>>>>>> put for arm926ejs. >>>>>>> >>>>>>> Please wait and please first explain what is the >>>>>>> issue. >>>>>> >>>>>> The issue is what I've explained in the patch comments. >>>>> >>>>> "Jumping to board_init_r is not performed due to a bug on >>>>> address computation." >>>>> >>>>> Ok, I don't know how to replicate the bug from this comment >>>>> or what effects it causes or ... well, anything. So please, >>>>> try to be more elaborate in your patch description next >>>>> time. Anyway .. >>>>> >>>>>> Without this change the code never reaches board_init_r >>>>>> in the SPL and I think I have all the configurations >>>>>> correctly set. >>>>> >>>>> I wonder why you'd ever want to reach board_init_r in the >>>>> SPL. SPL is there only to load the real U-Boot from >>>>> whatever media, so you usually use either NAND SPL >>>> >>>> Here's a good point for me to jump in, I think. There's two >>>> things to understand: - In the current in-tree SPL >>>> implementations the code flow is >>>> >>>> board_init_f calls relocate_code() to clear the BSS _and_ get >>>> our jump to board_init_r. It does not actually relocate the >>>> running U-Boot, just clears the BSS. board_init_r is what >>>> calls the things to load and boot the next stage (U-Boot or >>>> Linux). >>>> >>>> - In my series this has been changed slightly to be >>>> board_init_f calls >>>> >>>> memset and then board_init_r directly. So this patch should >>>> not be needed once rebased on that series. >>> >>> Do we need to do all the relocation in assembler code btw? Can >>> it not be moved into C code and made generic across all >>> platforms (module the stack adjustment and a few minor things) >>> ? >> >> I think people have posted patches for this before and yes, once >> CONFIG_NEEDS_MANUAL_RELOC dies it should be all possible to do in >> C, so long as it doesn't grow in size or doesn't grow in size >> that would be problematic (remember the 4kb people). > > How does MANUAL_RELOC interfere with that? Eg. on ARM, it can > already be shifted to C. Then if we made it generic enough, those > MANUAL_RELOC platforms could simply adopt the C code. Yes, one of the platforms that already has C code for ELF relocation (x86, iirc) could be made more generic and I think someone (Graeme?) already started this a long time ago as part of making a generic set of functions for board_init_{f,r}. Just can't make it for all platforms until everyone has ELF is the point I was poorly making. - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQV2VKAAoJENk4IS6UOR1W3McP/1htBzFzXXPULGOO+1zanoaO T2tmJZ9f4gHNIY6gnCdU7SlW4mhZPEFlwHD+JwPmIS7ZhGcPxVn9Vgl+r0fpEZHW VBY1bGeSGmaLhziiT+9MmaUqKUx6IFN5nZX0ypYcHS1ZTo1JztvLSUrSdOnOYHWx DXXPwNIreUctwIpyjNrhu93e39ep1AYb1ZW+o57Sj4+uGqt8+G9FpEjdxMQrjKqh r88j7XRgfWNPiqLwuGy+7HHEXnQGDum3Aml/ojO3WSzpZYXZQ4zC4MTND+TwzSi6 h3+nB3OfYktPgFWRDYQt8VyWPl9beVHzhac3o6sF5SiclQyya0liCCNsSbDSKf/G Zjpjg5cOAmPMMUs1ZXq2Ve5wMxb0alArzxZuMZ/ZA1gRDjazFErvYCUzAQFkDAZz zB6YMNc1+iCaYyaeNOqvJdMOZXAIoGLx5bbv9dzsnYc45jeU1ScDywcOQC2jTYFf jnzmqzh/6EJW2gfWW33XdxbHsDOZeEfCzJFmK7/vEbVW0TrkiCMJjHzf/jdguABQ jhusLwYYJr5yNlwq16RmiPxIaUhBrCFLY5cxLiSTd4v0DdbqyaTC7MEadjKQLpBW /LA5ImhXr/ORhfNTrVQjDSRhAGdmi2L0GVTurHJ2I6SCIVesu/ioMCGY3sy+aizK H3jl0yobGtRNFamgK+Ld =ncZ8 -----END PGP SIGNATURE-----
Hi José, On Fri, 14 Sep 2012 18:28:52 +0100, José Miguel Gonçalves <jose.goncalves@inov.pt> wrote: > Jumping to board_init_r is not performed due to a bug on address computation. > Relocation offsets are not needed when building SPL. > > Signed-off-by: José Miguel Gonçalves <jose.goncalves@inov.pt> > --- > Changes for v2: > - None > --- > arch/arm/cpu/arm926ejs/start.S | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S > index 6f05f1a..2da5342 100644 > --- a/arch/arm/cpu/arm926ejs/start.S > +++ b/arch/arm/cpu/arm926ejs/start.S > @@ -325,7 +325,7 @@ _nand_boot_ofs: > .word nand_boot > #else > ldr r0, _board_init_r_ofs > - ldr r1, _TEXT_BASE > + adr r1, _start > add lr, r0, r1 > add lr, lr, r9 > /* setup parameters for board_init_r */ > @@ -338,12 +338,14 @@ _board_init_r_ofs: > .word board_init_r - _start > #endif > > +#ifndef CONFIG_SPL_BUILD > _rel_dyn_start_ofs: > .word __rel_dyn_start - _start > _rel_dyn_end_ofs: > .word __rel_dyn_end - _start > _dynsym_start_ofs: > .word __dynsym_start - _start > +#endif > > /* > ************************************************************************* Deferring decision on this one until after 2012.10. Amicalement,
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -325,7 +325,7 @@ _nand_boot_ofs: .word nand_boot #else ldr r0, _board_init_r_ofs - ldr r1, _TEXT_BASE + adr r1, _start add lr, r0, r1 add lr, lr, r9 /* setup parameters for board_init_r */ @@ -338,12 +338,14 @@ _board_init_r_ofs: .word board_init_r - _start #endif +#ifndef CONFIG_SPL_BUILD _rel_dyn_start_ofs: .word __rel_dyn_start - _start _rel_dyn_end_ofs: .word __rel_dyn_end - _start _dynsym_start_ofs: .word __dynsym_start - _start +#endif /* *************************************************************************
Jumping to board_init_r is not performed due to a bug on address computation. Relocation offsets are not needed when building SPL. Signed-off-by: José Miguel Gonçalves <jose.goncalves@inov.pt> --- Changes for v2: - None --- arch/arm/cpu/arm926ejs/start.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)