mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: perachet7@gmail.com
To: "Панов Андрей" <rockford@yandex.ru>
Cc: barebox@lists.infradead.org
Subject: Re: rk3188 (radxa rock pro) boot failure w/ barebox 2018-04 and later
Date: Fri, 14 Sep 2018 23:41:45 +0200	[thread overview]
Message-ID: <5675177.9FAqIcoTBl@think-future.de> (raw)
In-Reply-To: <8463281536949204@think-future.de>

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

  parent reply	other threads:[~2018-09-14 21:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-13 11:18 perachet7
2018-09-13 12:37 ` Sam Ravnborg
2018-09-14 18:20   ` Панов Андрей
2018-09-17  6:37     ` Sascha Hauer
     [not found]   ` <8463281536949204@think-future.de>
2018-09-14 21:41     ` perachet7 [this message]
     [not found] ` <20180913123746.GA18653@think-future.de>
2018-09-14 21:33   ` perachet7
2018-09-17  7:30 ` Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5675177.9FAqIcoTBl@think-future.de \
    --to=perachet7@gmail.com \
    --cc=barebox@lists.infradead.org \
    --cc=rockford@yandex.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox