Hi Hugh,
Ccing the Rockchip maintainers from https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/mainta... as neither appear to be subscribed to this mailing list.
Joanna
On 08/10/2019, 21:45, "TF-A on behalf of Hugh Cole-Baker via TF-A" <tf-a-bounces@lists.trustedfirmware.org on behalf of tf-a@lists.trustedfirmware.org> wrote:
Hi folks,
I've been using TF-A with mainline U-Boot recently as firmware & boot loader for a RK3399 Rockpro64 board. I'm compiling TF-A and U-boot based on this guide [1], using gcc 8.3.0 from Debian.
TF-A v2.1 works fine for this, but I recently tried to switch to TF-A latest master and found U-Boot gets stuck with this version.
The symptoms are: U-Boot TPL and SPL print starting messages like this:
U-Boot TPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50) Trying to boot from BOOTROM Returning to boot ROM...
U-Boot SPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50 +0000) Trying to boot from MMC2
...and then there is no more output when normally U-Boot proper would start, and go on to load the Linux kernel, etc.
Starting from v2.1, with git bisect I found the first 'bad' commit is: 0aad563c7480 rockchip: Update BL31_BASE to 0x40000 and that commit does change some RK3399-related files so seems likely.
I'm not sure how to debug further, any ideas on why boot is hanging after that change or how to get more debugging information?
Best regards, Hugh Cole-Baker
[1] https://github.com/u-boot/u-boot/blob/master/doc/README.rockchip -- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On 11 Oct 2019, at 16:57, Joanna Farley Joanna.Farley@arm.com wrote:
Hi Hugh,
Ccing the Rockchip maintainers from https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/mainta... as neither appear to be subscribed to this mailing list.
Joanna
On 08/10/2019, 21:45, "TF-A on behalf of Hugh Cole-Baker via TF-A" <tf-a-bounces@lists.trustedfirmware.org on behalf of tf-a@lists.trustedfirmware.org> wrote:
Hi folks,
I've been using TF-A with mainline U-Boot recently as firmware & boot loader for a RK3399 Rockpro64 board. I'm compiling TF-A and U-boot based on this guide [1], using gcc 8.3.0 from Debian.
TF-A v2.1 works fine for this, but I recently tried to switch to TF-A latest master and found U-Boot gets stuck with this version.
The symptoms are: U-Boot TPL and SPL print starting messages like this:
U-Boot TPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50) Trying to boot from BOOTROM Returning to boot ROM...
U-Boot SPL 2019.10-rc4-00037-gdac51e9aaf (Oct 06 2019 - 21:42:50 +0000) Trying to boot from MMC2
...and then there is no more output when normally U-Boot proper would start, and go on to load the Linux kernel, etc.
Starting from v2.1, with git bisect I found the first 'bad' commit is: 0aad563c7480 rockchip: Update BL31_BASE to 0x40000 and that commit does change some RK3399-related files so seems likely.
I'm not sure how to debug further, any ideas on why boot is hanging after that change or how to get more debugging information?
Best regards, Hugh Cole-Baker
[1] https://github.com/u-boot/u-boot/blob/master/doc/README.rockchip
TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
As far as I can tell, my issue is fixed by applying this patch to u-boot: https://patchwork.ozlabs.org/patch/1173719/
It seems like there was an incompatibility between the change to BL31_BASE in TF-A and the configuration in U-Boot for my board which had CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x50000
Thanks to Kever Yang for finding the cause and providing the solution.
tf-a@lists.trustedfirmware.org
-
Hugh Cole-Baker -
Joanna Farley