rk3188 (radxa rock pro) boot failure w/ barebox 2018-04 and later
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 <[email protected]> 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.
arch/arm/Kconfig +5 -1
@@ -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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
Hi S.
Quoted 12 lines · On Thu, Sep 13, 2018 at 01:18:54PM +0200, [email protected] 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: Forrelocatable image force
TEXT_BASE0x0.As was suggested on #barebox, I tried setting TEXT_BASE=0x10 at this commit but it's a no fix.
Quoted 8 lines
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_BASEand 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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
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 0x6000XXXXXimage_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" <[email protected]>:
Quoted 31 lines
Hi S.
Quoted 12 lines · On Thu, Sep 13, 2018 at 01:18:54PM +0200, [email protected] 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 forceTEXT_BASE0x0.As was suggested on #barebox, I tried setting TEXT_BASE=0x10 at this commit but it's a no fix.
Quoted 8 lines
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_BASEand 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.
Quoted 8 lines
Good luck chasing it down.
Sam
_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
--
Андрей
arch/arm/cpu/uncompress.c +2 -2
@@ -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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
Hi,
Quoted 12 lines · Панов Андрей
Hi!
Attached patch fixed the problem.
in
arch/arm/cpu/uncompress.cglobal_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
0x60000000and image linked at0x0, soglobal_variable_offset()returns0x60000000We're running around
0x60000000and atimage_end = (void *)&image_end_marker + global_variable_offset();
Quoted 8 lines
&image_end_markeris 0x6000XXXXXimage_endgoes at0x60000000more than it is actuallyAfter 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
Quoted 29 lines
arch/arm/cpu/uncompress.c +2
-2@@ -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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
Signature · 9 lines
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 [email protected] http://lists.infradead.org/mailman/listinfo/barebox
A message that is not in the archive (sent off-list or not yet received): [email protected]
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 Rockclk_register clk xin24m is already registered, skipping! arc-emac 10204000.ethernet: ARC EMAC detected with id: 0x7fd02mdio_bus: miibus0: probeddw_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 rootwaitarch_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.
Quoted 58 lines · On Freitag, 14. September 2018 20:20:04 CEST you wrote:
Hi!
Attached patch fixed the problem.
in
arch/arm/cpu/uncompress.cglobal_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
0x60000000and image linked at0x0, soglobal_variable_offset()returns0x60000000We're running around
0x60000000and atimage_end = (void *)&image_end_marker + global_variable_offset();
&image_end_markeris 0x6000XXXXXimage_endgoes at0x60000000more than it is actuallyAfter 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" <[email protected]>:Quoted 31 lines
Hi S.
Quoted 12 lines · On Thu, Sep 13, 2018 at 01:18:54PM +0200, [email protected] 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_BASE0x0.As was suggested on #barebox, I tried setting TEXT_BASE=0x10 at this
commit but it's a no fix.Quoted 8 lines
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 byHAVE_CONFIGURABLE_TEXT_BASEand 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.
Quoted 11 lines
Quoted 8 lines
Good luck chasing it down.
Sam
_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/bareboxSignature · 1 line
Андрей
_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
A message that is not in the archive (sent off-list or not yet received): [email protected]
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 <[email protected]> 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.
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 Rockclk_register clk xin24m is already registered, skipping! arc-emac 10204000.ethernet: ARC EMAC detected with id: 0x7fd02mdio_bus: miibus0: probeddw_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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
Quoted 12 lines · On Thu, Sep 13, 2018 at 01:18:54PM +0200, [email protected] 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: Forrelocatable image force
TEXT_BASE0x0.As was suggested on #barebox, I tried setting TEXT_BASE=0x10 at this commit but it's a no fix.
Quoted 8 lines
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_BASEand 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
Signature · 9 lines
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 [email protected] http://lists.infradead.org/mailman/listinfo/barebox