mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: "s.hauer@pengutronix.de" <s.hauer@pengutronix.de>
To: "Baeuerle, Florian" <Florian.Baeuerle@allegion.com>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: [PATCH] ARM: phytec-phycard-imx27: Add debug UART support
Date: Mon, 27 Aug 2018 16:45:45 +0200	[thread overview]
Message-ID: <20180827144545.h7pld2edwwmnaoqw@pengutronix.de> (raw)
In-Reply-To: <96de0308ea2468972690c0f1709ab6029d8e22c7.camel@allegion.com>

On Mon, Aug 27, 2018 at 12:37:18PM +0000, Baeuerle, Florian wrote:
> Am Montag, den 27.08.2018, 14:10 +0200 schrieb Sascha Hauer:
> > On Thu, Aug 23, 2018 at 12:20:32PM +0000, Baeuerle, Florian wrote:
> > > Some background on that patch:
> > > 
> > > I've tried to get barebox master compiled with OSELAS 2018 running on a
> > > phycard-imx27. I had a few problems with that:
> > > 
> > > It turned out, that I can boot the resulting image as a seconds stage (from an
> > > older version of barebox), after commenting out pca100_usb_init(). I suppose
> > > that is not a real problem, but probably related to some clock setup that
> > > barebox master does somewhere during early boot (which I suppose, is skipped
> > > when booting it as 2nd stage).
> > > 
> > > However, when flashing the resulting image to NAND, there seems to be a bigger
> > > issue somewhere during early boot. This problem does not exist when compiling
> > > barebox master with OSELAS 2016.
> > 
> > I gave it a test and can confirm that the board boots when compiled with
> > OSELAS 2016 and no longer boots with OSELAS 2018.
> 
> Thanks for confirming this!
> > 
> > It's strange and I'm out of ideas for now. In
> > imx27_barebox_boot_nand_external() we have a place that copies the
> > initial image poprtion into SDRAM. It seems the SDRAM is never written
> > to - at least according to the information my BDI2000 gives me.
> 
> What could you observe with your debugger?
> I sadly do not have any hardware debugger available, so I was stuck with writing
> characters on the UART which IIRC was completely unsuccessful in
> imx27_barebox_boot_nand_external().

I can see that we execute this copy loop:

     518:	e592c000 	ldr	ip, [r2]
     51c:	e2822004 	add	r2, r2, #4
     520:	e580c000 	str	ip, [r0]
     524:	e1520001 	cmp	r2, r1
     528:	e2820332 	add	r0, r2, #-939524096	; 0xc8000000
     52c:	1afffff9 	bne	518 <imx27_barebox_boot_nand_external+0x18>

When stopping at 524 we have this register content:

         User     FIQ     Superv   Abort     IRQ      Undef
GPR00: a0000000 a0000000 a0000000 a0000000 a0000000 a0000000
GPR01: d8000800 d8000800 d8000800 d8000800 d8000800 d8000800
GPR02: d8000004 d8000004 d8000004 d8000004 d8000004 d8000004
GPR03: d80012a0 d80012a0 d80012a0 d80012a0 d80012a0 d80012a0
GPR04: d80012a0 d80012a0 d80012a0 d80012a0 d80012a0 d80012a0
GPR05: 28c04080 28c04080 28c04080 28c04080 28c04080 28c04080
GPR06: 22604914 22604914 22604914 22604914 22604914 22604914
GPR07: 062008cc 062008cc 062008cc 062008cc 062008cc 062008cc
GPR08: 04808005 20000061 04808005 04808005 04808005 04808005
GPR09: 2b3107cd 08930146 2b3107cd 2b3107cd 2b3107cd 2b3107cd
GPR10: 80140001 61081110 80140001 80140001 80140001 80140001
GPR11: 2310000d 00026000 2310000d 2310000d 2310000d 2310000d
GPR12: ea000012 a8080e28 ea000012 ea000012 ea000012 ea000012
GPR13: 294108a0 950200c0 ffffffec 45525940 80110208 82c00a08
GPR14: 89830033 19022184 d800005c 32010501 00140011 000d0812
PC   : d8000524
CPSR : 200000d3
SPSR :          00000010 00000010 00000010 00000010 00000010

So r0 correctly contains the destination address (0xa0000000), the ip
register (GPR12) contains the value read from 0xd8000000 (0xea000012),
but reading the memory at 0xa0000000 still contains the value that
was there before the first loop iteration, as if the memory was never
written to:

md 0xa0000000:
a0000000 : 0a884784 8340111c 00001004 02101308  .G....@.........
a0000010 : 50201a48 20a042c4 12d01504 10081000  H. P.B. ........
...

With OSELAS 2016 the copy loop looks a little different, but works as
expected.

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

  reply	other threads:[~2018-08-27 14:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-23  9:58 Florian Bäuerle
2018-08-23 12:20 ` Baeuerle, Florian
2018-08-24  7:16   ` Sascha Hauer
2018-08-27 12:10   ` Sascha Hauer
2018-08-27 12:37     ` Baeuerle, Florian
2018-08-27 14:45       ` s.hauer [this message]
2018-08-24  1:57 ` Andrey Smirnov
2018-08-31  9:46   ` Baeuerle, Florian
2018-09-10  8:05     ` [PATCH v2] " Florian Bäuerle

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=20180827144545.h7pld2edwwmnaoqw@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=Florian.Baeuerle@allegion.com \
    --cc=barebox@lists.infradead.org \
    /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