Attempt to update Rock64 to head -r355976 failed to boot afterwards, anyone have a recent FreeBSD booting a Rock64?
Mark Millard
marklmi at yahoo.com
Mon Dec 23 06:23:30 UTC 2019
On 2019-Dec-22, at 21:14, Klaus Küchemann <maciphone2 at googlemail.com> wrote:
> Well , for the u-boot-versions from Kurt Miller I use, you can read :
> http://openbsd-archive.7691.n7.nabble.com/RockPro64-dmesg-hang-td372109.html
> &
> http://openbsd-archive.7691.n7.nabble.com/Various-rockchip-u-boot-aarch64-improvements-td374802.html
>
> Both versions boot FreeBSD as well on Rock64&RockPro64 . If you want you can ask Kurt for permission to use his versions and greet him from me.
>
> Afaik the following fbsd-port doesn’t fix the 4GB-issue for RockPro64 : https://www.freshports.org/search.php?query=rockpro64&search=go&num=10&stype=name&method=match&deleted=excludedeleted&start=1&casesensitivity=caseinsensitive
> whereas Kurt`s version does as you can read in the obsd-mailing list.
I've no access to a RockPro64 but others may have an interest
in the alterative.
The Rock64 that I have access to has 4 GiBytes of RAM and seems
to be able to use it just fine. Given forcing the intended .dtb
file to be used, the Rock64 oddity for now, for my context, is
that my non-debug kernel builds seems to require boot -v in
order to boot. (This was not true before I updated. Also,
unfortunately, it had been a while since I'd updated.)
It took a while to identify the two issues and how to avoid
them. But I'm fine with operating in the odd context and
at least reporting if I later discover that the behavior has
changed in some way.
Thanks again for the notes.
> Unfortunately I don’t own a MACCHIATObin so don’t know if that machine is fbsd-bootable by Kurt`s uboot-2019.10
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-arm
mailing list