RockPro64 with latest image fails to boot?

Emmanuel Vadot manu at bidouilliste.com
Thu Aug 6 15:50:30 UTC 2020


On Thu, 6 Aug 2020 17:44:43 +0200
Søren Schmidt <soren.schmidt at gmail.com> wrote:

> 
> 
> > On 6 Aug 2020, at 17.27, Emmanuel Vadot <manu at bidouilliste.com> wrote:
> > 
> > On Thu, 6 Aug 2020 17:19:41 +0200
> > Søren Schmidt <soren.schmidt at gmail.com> wrote:
> > 
> >> 
> >>> On 6 Aug 2020, at 13.51, Emmanuel Vadot <manu at bidouilliste.com> wrote:
> >>>> 
> >>>> 
> >>>> However, it also fails with my previously good -current release, so that points pretty squarely at u-boot 2020.07. I?ll try to go back to 2020.04 (plus patches to find 4G etc).
> >>> 
> >>> What patches are you talking about ?
> >> 
> >> With the stock 2020.04 from ports I had to apply this patch manually to get u-boot to find all 4G?s of memory:
> >> 
> > 
> > That shouldn't be needed, I know I don't need it (same with others
> > that have the boards and tested the latest image).
> > So it's clear that your problem is DRAM related (which can explain the
> > random freeeze or panic), but that doesn't really explain why you don't
> > have problems with NetBSD, which version of u-boot are they using ?
> 
> They use a custom version of eyufan?s u-boot an old 2019 something..
> 
> > P.S.: That would have been good to start your recent mails by saying
> > that you needed a patch for u-boot ...
> 
> I don?t need them for 2020.07 that finds 4G just fine on the rockpro64 but they where needed for 2020.04 (found them on the u-boot homepage back when, its a known problem fixed in .07).

 It's not in 2020.07 (see
https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi)
so maybe some changes made the dram controller finding all the 4GiB but
it's not correctly initialized.

> --
> Søren Schmidt
> sos at deepcore.dk / sos at freebsd.org
> "So much code to hack, so little time"
> 
> 
> 


-- 
Emmanuel Vadot <manu at bidouilliste.com>


More information about the freebsd-arm mailing list