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