[U-Boot] Booting on RK3399

Simon Glass sjg at chromium.org
Fri Jan 4 20:12:58 UTC 2019


Hi Mark,

On Fri, 4 Jan 2019 at 12:43, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>
> > From: Simon Glass <sjg at chromium.org>
> > Date: Thu, 3 Jan 2019 16:25:36 -0700
> >
> > Hi Mark,
> >
> > On Thu, 3 Jan 2019 at 04:23, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> > >
> > > > From: Simon Glass <sjg at chromium.org>
> > > > Date: Wed, 2 Jan 2019 20:37:45 -0700
> > > >
> > > > > Haven't tested flashing eMMC with rkdeveloptool myself, but that
> > > > > should work on the firefly as well.
> > > > >
> > > > > Another complication as that the serial console speed defaults to
> > > > > 1500000 which isn't supported by all serial-to-USB chips and frankly
> > > >
> > > > Yes I seem to have one that supports this, so this is fine.
> > >
> > > Just be aware that you'll need to patch TF-A to configure the serial
> > > port to 1500000 as well.  Probably just a matter of changing
> > > RK3399_BAUDRATE in plat/rockchip/rk3399/rk3399_def.h.
> >
> > OK, did that.
> > Here are the results:
> >
> > v2018.01
> > U-Boot SPL board init"Synchronous Abort" handler, esr 0x00070000
> > ELR:     e2030000a891a6e4
> > "Synchronous Abort" handler, esr 0x
> >
> > v2018.03
> > U-Boot SPL board init"Synchronous Abort" handler, esr 0xffff0000
> > elr: 00000000ff8ca6fc lr : ffff0000ffffa7bc
> > "Synchronous Abort" handler, esr 0x
> >
> > v2018.05
> > U-Boot SPL board init"Synchronous Abort" handler, esr 0x00070000
> > elr: 00000000ff8ca7a4 lr : 00000000ff8ca864
> > "Synchronous Abort" handler, esr 0x
> >
> > v2018.07
> > U-Boot SPL board init"Synchronous Abort" handler, esr 0xff000000
> > elr: 00000000ff8ca8f0 lr : 00000000ff8ca9b0
> > "Synchronous Abort" handler, esr 0x
> >
> > v2018.09
> > U-Boot SPL board init
> > (no more output)
> >
> > mainline:
> > U-Boot SPL board init
> > (no more output)
> >
> >
> > It died when I call printf() at the start of board_init_r(). If I put
> > printf() anywhere inside spl_relocate_stack_gd() it is happy. Also
> > putc() works OK. So perhaps the code that calls that function is doing
> > something wrong? Some sort of stack problem?
>
> Strange.  This is what I get
>
> U-Boot SPL board init
> Trying to boot from MMC1
> NOTICE:  BL31: v2.0(debug):2.0
> NOTICE:  BL31: Built : 12:46:24, Oct 21 2018
> INFO:    GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
> INFO:    plat_rockchip_pmu_init(1593): pd status 3e
> INFO:    BL31: Initializing runtime services
> INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
> INFO:    BL31: Preparing for EL3 exit to normal world
> INFO:    Entry point address = 0x200000
> INFO:    SPSR = 0x3c9
>
>
> U-Boot 2019.01-rc2-00127-g08337cd648-dirty (Jan 04 2019 - 19:31:14 +0100)
>
> Model: Firefly-RK3399 Board
> ...
>
>
> That is *with* the dts diff (see below) though.  Without that diff, it
> hangs after:
>
> U-Boot SPL board init
> Trying to boot from MMC2
>
>
> So obviously that diff is needed to boot properly from uSD.  I'll send
> out a git patch with a proper commit messages in a bit.

Yes I have the diff. What toolchain version are you using?

Regards,
Simon

>
> Cheers,
>
> Mark
>
>
> diff --git a/arch/arm/dts/rk3399-firefly.dts b/arch/arm/dts/rk3399-firefly.dts
> index be350866a7..f90e7e88db 100644
> --- a/arch/arm/dts/rk3399-firefly.dts
> +++ b/arch/arm/dts/rk3399-firefly.dts
> @@ -15,7 +15,7 @@
>
>         chosen {
>                 stdout-path = &uart2;
> -               u-boot,spl-boot-order = &sdhci, &sdmmc;
> +               u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc;
>         };
>
>         backlight: backlight {


More information about the U-Boot mailing list