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

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

[perachet7]

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.

Thanks.

cheers

S.



Following said commit:

git show 2a94e821ba2e64890ac47b9ba177c7b6585b23be
commit 2a94e821ba2e64890ac47b9ba177c7b6585b23be
Author: Sascha Hauer <s.hauer@pengutronix.de>
Date:   Fri Mar 9 09:12:08 2018 +0100

    ARM: For relocatable image force TEXT_BASE 0x0
    
    Nothing else should be used for the relocatable image case, so
    force TEXT_BASE to 0x0 and do not show it in the menu.
    
    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e7edc2ad4..563475205 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2,7 +2,7 @@ config ARM
        bool
        select HAS_KALLSYMS
        select HAS_CACHE
-       select HAVE_CONFIGURABLE_TEXT_BASE
+       select HAVE_CONFIGURABLE_TEXT_BASE if !RELOCATABLE
        select HAVE_IMAGE_COMPRESSION
        default y
 
@@ -19,6 +19,10 @@ config ARM_USE_COMPRESSED_DTB
        select UNCOMPRESS
        select LZO_DECOMPRESS
 
+config TEXT_BASE
+       hex
+       default 0x0
+
 menu "System Type"
 
 config BUILTIN_DTB



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

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

[Sam Ravnborg]

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

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

[Панов Андрей]

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

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

[perachet7]

Hey Sam,

Thanks for your reply.

First, there was a glitch while bisecting the thing. After all it was this 
commit:

  first bad commit: [f382224173ebf8a7fce42cf09179b5f6bc7dc6c9] ARM: scroll 
past image end without ld_var

git log f382224173ebf8a7fce42cf09179b5f6bc7dc6c9
commit f382224173ebf8a7fce42cf09179b5f6bc7dc6c9 (refs/bisect/bad)
Author: Sascha Hauer <s.hauer@pengutronix.de>
Date:   Tue Mar 13 08:26:21 2018 +0100

    ARM: scroll past image end without ld_var
    
    ld_var is going to be removed, cope without it. In the PBL image
    we want to get the location after the binary to the place where
    the compressed image is located. To do this Put a variable at
    the very end of the binary, get it's location and add an offset.
    
    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

triggering the boot failure. 

Note aside: Ironically, the related code is amongst other lines one that 
matches your description about get_runtime_offset().

BUT..

Turns out, the toolchain wasn't playing along. Using the standard cross-arm-
eabihf toolchain

  arm-linux-gnueabihf-gcc (Ubuntu/Linaro 7.3.0-16ubuntu3) 7.3.0

the above commit triggers this Does-Not-Boot situation. It would just hang 
once DDR is initialized. 


However, using the latest OSELAS toolchain provided by pengutronix

  arm-v7m-eabi-gcc (OSELAS.Toolchain-2018.02.0 7-20180201) 7.3.1 20180201

the boot failure just does not happen and bb v2018.09.0 is booting the rk3188 
quite happily:

DDR Version 1.04 20140217
In
DDR3
300MHz
Bus Width=32 Col=10 Bank=8 Row=15 CS=2 Die Bus-Width=16 Size=2048MB
Memory OK
OUT


barebox 2018.09.0 #39 Thu Sep 13 16:53:12 CEST 2018


Board: Radxa Rock
clk_register clk xin24m is already registered, skipping!
arc-emac 10204000.ethernet: ARC EMAC detected with id: 0x7fd02
mdio_bus: miibus0: probed
dw_mmc 10214000.dwmmc: registered as 10214000.dwmmc
mshc1: detected SD card version 1.0
mshc1: registered mshc1
netconsole: registered as netconsole-1
i2c-gpio i2c-gpio0: using pins 58 (SDA) and 59 (SCL)
malloc space: 0x9fefd660 -> 0xdfdfacbf (size 1023 MiB)
gpio-leds.6: probe permanently deferred
envfs: no envfs (magic mismatch) - envfs never written?
running /env/bin/init...

Hit any key to stop autoboot:    3

So, after all, _almost_ everything is fine.

barebox@Radxa Rock:/ saveenv 
saving environment
ERROR: dw_mmc 10214000.dwmmc: dwmci_write_data_pio: FIFO overflow timeout
ERROR: dw_mmc 10214000.dwmmc: dwmci_write_data_pio: FIFO flush timeout

One less to go, yet one to go.

cheers

S




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

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

[perachet7]

Hello,

Thank you for the patch. Verified and acknowledged, rk3188 w/ bb 2018.09.0 is 
booting when compiled using the 

  arm-linux-gnueabihf-gcc (Ubuntu/Linaro 7.3.0-16ubuntu3) 7.3.0

toolchain. Interestingly, it booted using the OSELAS toolchain; what kind of 
dark magic does get thrown at the code when using OSELAS?

rk3188 boot up (notice the -dirty tail to the version string because  
variable_offset.diff got patched in):

DDR Version 1.04 20140217
In
DDR3
300MHz
Bus Width=32 Col=10 Bank=8 Row=15 CS=2 Die Bus-Width=16 Size=2048MB
Memory OK
OUT


barebox 2018.09.0-dirty #40 Fri Sep 14 23:26:58 CEST 2018


Board: Radxa Rock
clk_register clk xin24m is already registered, skipping!
arc-emac 10204000.ethernet: ARC EMAC detected with id: 0x7fd02
mdio_bus: miibus0: probed
dw_mmc 10214000.dwmmc: registered as 10214000.dwmmc
mshc1: detected SD card version 1.0
mshc1: registered mshc1
netconsole: registered as netconsole-1
i2c-gpio i2c-gpio0: using pins 58 (SDA) and 59 (SCL)
malloc space: 0x9fefd660 -> 0xdfdfacbf (size 1023 MiB)
gpio-leds.6: probe permanently deferred
envfs: no envfs (magic mismatch) - envfs never written?
running /env/bin/init...

Hit any key to stop autoboot:    0
booting 'mshc1'
mount: No such file or directory
ext4 ext40: EXT2 rev 1, inode_size 128, descriptor size 32
mounted /dev/mshc1.0 on /mnt/mshc1.0
setting root node failed: Device or resource busy
oftree: Device or resource busy

Loading ARM Linux zImage '/mnt/mshc1.0/zImage'
commandline:  console=ttyS2,115200  root=/dev/mmcblk0p2 rootwait
arch_number: 3066

This is where the kernel won't start.

It looks like there are a couple of issues here:

1) envfs: no envfs (magic mismatch) - envfs never written?

2) mount: No such file or directory

3) setting root node failed: Device or resource busy

4) kernel does not boot: arch_number: 3066

Any ideas on those ones?

Thanks again and

cheers

S.

On Freitag, 14. September 2018 20:20:04 CEST you wrote:
> 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
> 
> -- 
> Андрей





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

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

[Sascha Hauer]

Hi,

On Fri, Sep 14, 2018 at 09:20:04PM +0300, Панов Андрей wrote:
> 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.

This patch only works for CONFIG_PBL_RELOCATABLE enabled. If it's not
enabled, then we will move the binary to its link address, but not the
compressed image behind the binary. After that image_end is correctly
calculated to the address behind the new image, but there's only
garbage.

I have a patch in preparation I'll post shortly.

Sascha

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

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


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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

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

[Sascha Hauer]

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 just sent a patch. Could you please give it a test?

Thanks
  Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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