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

perachet7 at gmail.com perachet7 at gmail.com
Fri Sep 14 14:41:45 PDT 2018


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 at ravnborg.org>:
> > Hi S.
> > 
> > On Thu, Sep 13, 2018 at 01:18:54PM +0200, perachet7 at 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 at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/barebox
> 
> -- 
> Андрей







More information about the barebox mailing list