On Fri, 2019-09-27 at 11:50 +1000, Jonathan Gray wrote: > On Thu, Sep 26, 2019 at 09:38:43PM -0400, Kurt Miller wrote: > > > > On Fri, 2019-09-27 at 10:12 +1000, Jonathan Gray wrote: > > > > > > On Thu, Sep 26, 2019 at 12:28:56PM -0400, Kurt Miller wrote: > > > > > > > > > > > > I've been trying to get the rock64 to work with u-boot 2019.10rc4 > > > > with the help of solene@ and a motivated user with this board. > > > > (I don't have one to test with). The Rock64 is close to fully > > > > working with 2019.10rc4 u-boot but is experiencing a similar issue > > > > to what NetBSD has reported on the u-boot list. > > > > > > > > https://marc.info/?t=156888926600002&r=1&w=2 > > > > > > > > When booting miniroot66.fs with the u-boot TPL the install > > > > eventually fails with a kernel panic as seen below on > > > > solene@'s board. Using rkbin TPL the install completes > > > > and the resulting system appears stable in light testing. > > > > > > > > I have attached the diffs I'm using to the ports > > > > sysutils/arm-trusted-firmware and sysutils/u-boot. > > > > I modified the u-boot port to build idbloader with both > > > > u-boot TPL and rkbin TPL. > > > It isn't clear what the license on rkbin is. It is binary only but does > > > it allow distribution? > > Yea, there's no license at all and no matter how much digging > > I do, I can't find one. > > > > Mostly I was trying to point out that the rock64 board is > > having the same issues that NetBSD is having with the TPL > > layer in the forthcoming 2019.10 release and providing a > > way for people with the Rock64 board to verify it. > > > > I'm not sure if there's much I can do to get the TPL layer > > fixed but it would be great if the 2019.10 release could > > replace the 2017.09-rockchip-ayufan firmware that most > > people are using and doesn't work all that well on OpenBSD. > > > > Although I think the sysutils/arm-trusted-firmware change > > could go in now, since the BL31 layer for rk3328 has been > > confirmed to work by two people and it removes one more > > binary blob for that board. > Yes, I think you should commit the arm-trusted-firmware change. > > For U-Boot I would like to get rockpro64 support without breaking the > other targets. I will see if updating linaro gcc to a newer release > gives smaller codesize for the am335x SPL. > > Perhaps we wait for rock64 support in U-Boot to work without depending > on rkbin.
Yea, lets see how things play out. An alternative if the TPL issues are not fixed would be to provide the mkimage tool and u-boot-spl-dtb.bin for boards with TPL issues like rock64 and rockpro64 so that a user could combine the rkbin TPL with the SPL to create a working idbloader.img. Another thing I noticed is that the mkimage tool needed to prepare the rkbin TPL/memory files for use is the same for many of the boards we build on aarch64. ls build/*/tools/mkimage | xargs md5 MD5 (build/a64-olinuxino/tools/mkimage) = 0a4e12767bf11ec4503a079c25dc0c6f MD5 (build/bananapi_m64/tools/mkimage) = 0a4e12767bf11ec4503a079c25dc0c6f MD5 (build/firefly-rk3399/tools/mkimage) = 0a4e12767bf11ec4503a079c25dc0c6f MD5 (build/mvebu_espressobin-88f3720/tools/mkimage) = 41ee34de89f48092109e9058cc167aae MD5 (build/mvebu_mcbin-88f8040/tools/mkimage) = 41ee34de89f48092109e9058cc167aae MD5 (build/nanopi_a64/tools/mkimage) = 0a4e12767bf11ec4503a079c25dc0c6f MD5 (build/nanopi_neo2/tools/mkimage) = 0a4e12767bf11ec4503a079c25dc0c6f MD5 (build/orangepi_pc2/tools/mkimage) = 0a4e12767bf11ec4503a079c25dc0c6f MD5 (build/orangepi_prime/tools/mkimage) = 0a4e12767bf11ec4503a079c25dc0c6f MD5 (build/orangepi_win/tools/mkimage) = 0a4e12767bf11ec4503a079c25dc0c6f MD5 (build/pine64-lts/tools/mkimage) = 0a4e12767bf11ec4503a079c25dc0c6f MD5 (build/pine64_plus/tools/mkimage) = 0a4e12767bf11ec4503a079c25dc0c6f MD5 (build/pinebook/tools/mkimage) = 0a4e12767bf11ec4503a079c25dc0c6f MD5 (build/qemu_arm64/tools/mkimage) = 41ee34de89f48092109e9058cc167aae MD5 (build/rock64-rk3328/tools/mkimage) = 0a4e12767bf11ec4503a079c25dc0c6f MD5 (build/rockpro64-rk3399/tools/mkimage) = 0a4e12767bf11ec4503a079c25dc0c6f MD5 (build/rpi_3/tools/mkimage) = 41ee34de89f48092109e9058cc167aae MD5 (build/sopine_baseboard/tools/mkimage) = 0a4e12767bf11ec4503a079c25dc0c6f There appears to be only two variations in that list. -Kurt
