Re: rk3188 (radxa rock pro) boot failure w/ barebox 2018-04 and later

["Панов Андрей" <rockford@yandex.ru>]

[-- Attachment #1: Type: text/plain, Size: 2370 bytes --]

Hi!

Attached patch fixed the problem.

in arch/arm/cpu/uncompress.c global_variable_offset() was called before relocation.

And we have TEXT_BASE = 0 (since CONFIG_*_RELOCATABLE is set and it is not configurable)

Arch memory starts at 0x60000000 and image linked at 0x0, so global_variable_offset() returns 0x60000000

We're running around 0x60000000 and at
       image_end = (void *)&image_end_marker + global_variable_offset();
&image_end_marker is 0x6000XXXXX
image_end goes at 0x60000000 more than it is actually

After relocation global_variable_offset() becomes zero.

So if we move 
       image_end = (void *)&image_end_marker + global_variable_offset();
after relocation it will point to right location.

I am not sure it is true for all architectures, but in current state it is wrong when memory is not starts at 0.

13.09.2018, 15:38, "Sam Ravnborg" <sam@ravnborg.org>:
> Hi S.
>
> On Thu, Sep 13, 2018 at 01:18:54PM +0200, perachet7@gmail.com wrote:
>>  Hey list,
>>
>>  Between 2018-04 and 2018-05 tar release, barebox stops booting on rk3188
>>  (radxa rock pro).
>>
>>  A git bisect reveals (see end of mail for commit detail):
>>          first bad commit: [2a94e821ba2e64890ac47b9ba177c7b6585b23be] ARM: For
>>  relocatable image force TEXT_BASE 0x0.
>>
>>  As was suggested on #barebox, I tried setting TEXT_BASE=0x10 at this commit
>>  but it's a no fix.
>>
>>  It is however booting even later releases if the trailing "if !RELOCATABLE" is
>>  removed. I have yet to have a deeper look at the code modified by
>>  HAVE_CONFIGURABLE_TEXT_BASE and RELOCATABLE.
>>
>>  Furthermore, it seems the commit itself is only triggering a boot failure. The
>>  proper code causing it is probably hiding someplace else.
>>
>>  Any direction, ideas or hints given is appreciated.
>
> I was hit by a do-not-boot issue as well after upgrading to 2018.05.
> In my case this was due to a fix to get_runtime_offset()
> It turned out that I had subtraced the value, not added.
> Looks like an artifict from some code I copied some time ago.
>
> Maybe this hint can help you, and maybe this is totally unrelated.
>
> Good luck chasing it down.
>
>         Sam
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox

-- 
Андрей

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: variable_offset.diff --]
[-- Type: text/x-diff; name="variable_offset.diff", Size: 927 bytes --]

diff --git a/arch/arm/cpu/uncompress.c b/arch/arm/cpu/uncompress.c
index b07087e4c..708c04c1f 100644
--- a/arch/arm/cpu/uncompress.c
+++ b/arch/arm/cpu/uncompress.c
@@ -50,8 +50,6 @@ void __noreturn barebox_multi_pbl_start(unsigned long membase,
        void *pg_start;
        unsigned long pc = get_pc();
 
-       image_end = (void *)&image_end_marker + global_variable_offset();
-
        if (IS_ENABLED(CONFIG_PBL_RELOCATABLE)) {
                /*
                 * If we run from inside the memory just relocate the binary
@@ -64,6 +62,8 @@ void __noreturn barebox_multi_pbl_start(unsigned long membase,
                        relocate_to_adr(membase);
        }
 
+       image_end = (void *)&image_end_marker + global_variable_offset();
+
        /*
         * image_end is the image_end_marker defined above. It is the last location
         * in the executable. Right after the executable the build process adds



[-- Attachment #3: Type: text/plain, Size: 149 bytes --]

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox