ZynqMP boot: no messages from SPL other than "Debug uart enabled"
Hi everyone,
Please forgive me if this issue has already been discussed somewhere, I haven't been able to find the solution after searching and playing around for the past week.
I have a ZynqMP board (Xilinx ZCU102 V1.1) and would like to install my own Linux on it, based on the U-Boot SPL. After playing around with the Xilinx version of U-Boot and various sources for ATF as well as PMUFW, I've now settled on mainstream U-Boot (from git, master branch) as the code I'd like to use. There's an issue there already: if I run
make DEVICE_TREE="zynqmp-zcu102-rev1.0" xilinx_zynqmp_virt_defconfig
then the default device tree in .config ends up being "zynqmp-zcu100-revC", there's no sign of my DEVICE_TREE parameter making it into .config . In any case, I fixed this manually, then I also enabled early UART output and UART debugging.
After each build, I copy spl/boot.bin to the SD card and try to boot the ZCU102.
The real issue is that, whatever I do, whichever version or configuration of U-Boot I compile, I get a message "Debug uart enabled" from the early UART code, but then nothing. Everyone else on the internet seems to see at least a few more lines of output, usually starting with "U-Boot SPL 2020.04-rc3-00108-gdb41d985f6" or similar (this string was taken from the boot.bin I copied to the SD card, so it's there!), whereas I see nothing at all.
If I turn early UART off, then I don't even get the "Debug uart enabled" message. Simply nothing. Also no complaints about bl31 or PMUFW in case I deliberately built without them.
The board works fine with Petalinux, and it passes all hardware tests, so it should be OK. I'm monitoring all four UARTs exposed through the USB device interface, just in case something is routed to the wrong UART. But again, nothing.
I'm stuck, I'd appreciate any help.
Cheers,
András
Hi,
the issue is likely related to incorrect DDR configuration. BSS and Malloc space are in DDR.
rev1.1 has different DDR sodimm module then rev1.0. The change is handled by fsbl via spd detection and aligning some parameters.
I have generated psu init from vivado 2019.2 for 1.1 revision and send it to mailing list. I didn't test it on hw but please test it and let me know.
Build it like this. export DEVICE_TREE="zynqmp-zcu102-rev1.1" make xilinx_zynqmp_virt_defconfig make -j
Thanks, Michal
On 11. 03. 20 12:28, Major A wrote:
Hi everyone,
Please forgive me if this issue has already been discussed somewhere, I haven't been able to find the solution after searching and playing around for the past week.
I have a ZynqMP board (Xilinx ZCU102 V1.1) and would like to install my own Linux on it, based on the U-Boot SPL. After playing around with the Xilinx version of U-Boot and various sources for ATF as well as PMUFW, I've now settled on mainstream U-Boot (from git, master branch) as the code I'd like to use. There's an issue there already: if I run
make DEVICE_TREE="zynqmp-zcu102-rev1.0" xilinx_zynqmp_virt_defconfig
then the default device tree in .config ends up being "zynqmp-zcu100-revC", there's no sign of my DEVICE_TREE parameter making it into .config . In any case, I fixed this manually, then I also enabled early UART output and UART debugging.
After each build, I copy spl/boot.bin to the SD card and try to boot the ZCU102.
The real issue is that, whatever I do, whichever version or configuration of U-Boot I compile, I get a message "Debug uart enabled" from the early UART code, but then nothing. Everyone else on the internet seems to see at least a few more lines of output, usually starting with "U-Boot SPL 2020.04-rc3-00108-gdb41d985f6" or similar (this string was taken from the boot.bin I copied to the SD card, so it's there!), whereas I see nothing at all.
If I turn early UART off, then I don't even get the "Debug uart enabled" message. Simply nothing. Also no complaints about bl31 or PMUFW in case I deliberately built without them.
The board works fine with Petalinux, and it passes all hardware tests, so it should be OK. I'm monitoring all four UARTs exposed through the USB device interface, just in case something is routed to the wrong UART. But again, nothing.
I'm stuck, I'd appreciate any help.
Cheers,
András
Hi Michal,
the issue is likely related to incorrect DDR configuration. BSS and Malloc space are in DDR. > rev1.1 has different DDR sodimm module then rev1.0.
Thanks, this never occurred to me as Xilinx says to use rev1.0 software for rev1.1 boards, so that's what I did.
I have generated psu init from vivado 2019.2 for 1.1 revision and send it to mailing list. I didn't test it on hw but please test it and let me know.
I had already done that in the past (feed Vivado 2019.2 psu file into u-boot), with no success. Unfortunately, your patch doesn't help either, the behaviour is still exactly the same as before.
Build it like this. export DEVICE_TREE="zynqmp-zcu102-rev1.1" make xilinx_zynqmp_virt_defconfig make -j
For some reason, that's no enough: I have to manually set CONFIG_DEVICE_TREE because xilinx_zynqmp_virt_defconfig sets it wrong. In any case, behaviour is exactly the same as before.
Cheers,
András
Hi,
On 12. 03. 20 10:12, Major A wrote:
Hi Michal,
the issue is likely related to incorrect DDR configuration. BSS and Malloc space are in DDR. > rev1.1 has different DDR sodimm module then rev1.0.
Thanks, this never occurred to me as Xilinx says to use rev1.0 software for rev1.1 boards, so that's what I did.
First of all I sent v2 because of dt changes to see 1.1 revision and I have also tested it on real HW.
Yes normally it works like that newer board revision works with previous versions. But 1.1 is different case.
I have generated psu init from vivado 2019.2 for 1.1 revision and send it to mailing list. I didn't test it on hw but please test it and let me know.
I had already done that in the past (feed Vivado 2019.2 psu file into u-boot), with no success. Unfortunately, your patch doesn't help either, the behaviour is still exactly the same as before.
Build it like this. export DEVICE_TREE="zynqmp-zcu102-rev1.1" make xilinx_zynqmp_virt_defconfig make -j
For some reason, that's no enough: I have to manually set CONFIG_DEVICE_TREE because xilinx_zynqmp_virt_defconfig sets it wrong. In any case, behaviour is exactly the same as before.
With latest my queue it should be enough. https://github.com/michalsimek/u-boot/tree/mainline-v20200312
But I think that latest mainline should setup default in ITS properly. You can check it by looking at u-boot.its when build is done and find default configuration option which should point to 1.1 dt.
Here are jtag steps I have run.
Thanks, Michal
connect targets -set -filter {name =~ "PSU"}
set status [mrd -force -value 0xFFCA0038] set status [expr $status | 0x1C0] mwr -force 0xFFCA0038 $status
targets -set -filter {name =~ "MicroBlaze PMU"} dow pmu.elf con
targets -set -filter {name =~ "PSU"} mwr 0xffff0000 0x14000000 mask_write 0xFD1A0104 0x501 0x0
after 1000
targets -set -filter {name =~ "Cortex-A53 #0"} stop dow -data u-boot-spl-dtb.bin 0xfffc0000 memmap -file u-boot-spl rwr pc 0xfffc0000 bpadd -addr &udelay
if { [catch {con -block -timeout 3000} msg] } { puts "err: $msg" exit # do something to handle the error }
bpremove 0
dow -data u-boot.itb 0x10000000 con
Hi Michal,
First of all I sent v2 because of dt changes to see 1.1 revision and I have also tested it on real HW.
Just tried your patch v2 against mainline master branch, it still doesn't work on my board. I also checked your mainline-v20200312 branch, it's exactly the same: no output from any UART other than "Debug uart enabled" on UART0 if I enable it in menuconfig as "early UART".
For some reason, that's no enough: I have to manually set CONFIG_DEVICE_TREE because xilinx_zynqmp_virt_defconfig sets it wrong. In any case, behaviour is exactly the same as before.
With latest my queue it should be enough. https://github.com/michalsimek/u-boot/tree/mainline-v20200312
It's the same. CONFIG_DEFAULT_DEVICE_TREE becomes "zynqmp-zcu100-revC" whatever I do, there is no trace of the value specified in the DEVICE_TREE environment variable.
But I think that latest mainline should setup default in ITS properly. You can check it by looking at u-boot.its when build is done and find default configuration option which should point to 1.1 dt.
From the build using your mainline-v20200312 branch:
default = "config_1";
where config_1 is
description = "avnet-ultra96-rev1";
Here are jtag steps I have run.
I haven't set up JTAG yet.
Cheers,
András
Hi,
On 12. 03. 20 12:38, Major A wrote:
Hi Michal,
First of all I sent v2 because of dt changes to see 1.1 revision and I have also tested it on real HW.
Just tried your patch v2 against mainline master branch, it still doesn't work on my board. I also checked your mainline-v20200312 branch, it's exactly the same: no output from any UART other than "Debug uart enabled" on UART0 if I enable it in menuconfig as "early UART".
then you can add some more prints to see where it stucks.
For some reason, that's no enough: I have to manually set CONFIG_DEVICE_TREE because xilinx_zynqmp_virt_defconfig sets it wrong. In any case, behaviour is exactly the same as before.
With latest my queue it should be enough. https://github.com/michalsimek/u-boot/tree/mainline-v20200312
It's the same. CONFIG_DEFAULT_DEVICE_TREE becomes "zynqmp-zcu100-revC" whatever I do, there is no trace of the value specified in the DEVICE_TREE environment variable.
export DEVICE_TREE=... should cause that CONFIG_DEFAULT_DEVICE_TREE will remain assigned to zcu100 but SPL/u-boot proper will be using zcu102.
You can check it by looking at build folder ls spl/board/xilinx/zynqmp/ where you see which psu_init was used (recommend to make mrproper before you check this to remove old builds)
$ ls spl/board/xilinx/zynqmp/ built-in.o pm_cfg_obj.o tap_delays.o tap_delays.su zynqmp.o zynqmp.su zynqmp-zcu102-rev1.1
But I think that latest mainline should setup default in ITS properly. You can check it by looking at u-boot.its when build is done and find default configuration option which should point to 1.1 dt.
From the build using your mainline-v20200312 branch:
default = "config_1";
where config_1 is
description = "avnet-ultra96-rev1";
You should look at this. configurations { default = "config_17";
config_17 { description = "zynqmp-zcu102-rev1.1"; firmware = "atf"; loadables = "uboot"; fdt = "fdt_17"; };
Thanks, Michal
Hi Michal,
export DEVICE_TREE=... should cause that CONFIG_DEFAULT_DEVICE_TREE will remain assigned to zcu100 but SPL/u-boot proper will be using zcu102.
You can check it by looking at build folder ls spl/board/xilinx/zynqmp/ where you see which psu_init was used (recommend to make mrproper before you check this to remove old builds)
OK, that seems to be the case.
You should look at this. configurations { default = "config_17";
config_17 { description = "zynqmp-zcu102-rev1.1"; firmware = "atf"; loadables = "uboot"; fdt = "fdt_17"; };
That's what SHOULD be there, but it isn't. "default" points to "config_1", not 17. Why? And how do I change this (sorry for my ignorance, but editing the file and rebuilding u-boot doesn't work because the file gets overwritten)?
Cheers,
András
On 12. 03. 20 13:01, Major A wrote:
Hi Michal,
export DEVICE_TREE=... should cause that CONFIG_DEFAULT_DEVICE_TREE will remain assigned to zcu100 but SPL/u-boot proper will be using zcu102.
You can check it by looking at build folder ls spl/board/xilinx/zynqmp/ where you see which psu_init was used (recommend to make mrproper before you check this to remove old builds)
OK, that seems to be the case.
then simply change that CONFIG_DEFAULT_DEVICE_TREE to zynqmp-zcu102-rev1.1 and check that files.
You should look at this. configurations { default = "config_17";
config_17 { description = "zynqmp-zcu102-rev1.1"; firmware = "atf"; loadables = "uboot"; fdt = "fdt_17"; };
That's what SHOULD be there, but it isn't. "default" points to "config_1", not 17. Why? And how do I change this (sorry for my ignorance, but editing the file and rebuilding u-boot doesn't work because the file gets overwritten)?
And here should be default setup properly.
Try to use bash if you don't use it.
And logic is done via arch/arm/mach-zynqmp/mkimage_fit_atf.sh script
94 [ "x$(basename $dtname .dtb)" = "x${DEVICE_TREE}" ] && DEFAULT=$cnt
Thanks, Michal
Hi Michal,
Just to confirm and to eliminate any doubt:
When I build u-boot SPL for the ZCU102, u-boot actually forces me to supply a bl31.bin file, so that's what I did. Apart from that, I expect the SPL to print its welcome message (which I have yet to see) on the UART and complain about other components (such as PMUFW, u-boot proper, etc.) missing. Is that correct?
If it is, then there are only two components that can be wrong: u-boot SPL and ATF (bl31.bin), am I right?
Also, I assume that bl31.bin is incorporated into spl/boot.bin, so I don't need to supply it externally, is that so?
Don't get me wrong, I already tested loads of configurations with various incarnations of PMUFW and configuration object, etc., and never ever have I seen the "U-Boot SPL" welcome message on the UART. I guess it just doesn't want to greet me for some reason or another.
Cheers,
András
Hi,
On 12. 03. 20 14:24, Major A wrote:
Hi Michal,
Just to confirm and to eliminate any doubt:
When I build u-boot SPL for the ZCU102, u-boot actually forces me to supply a bl31.bin file, so that's what I did. Apart from that, I expect the SPL to print its welcome message (which I have yet to see) on the UART and complain about other components (such as PMUFW, u-boot proper, etc.) missing. Is that correct?
PMUFW needs to be loaded and can be built from SDK/VITIS or taken from petalinux.
bl31 is ATF - also you can build it or take it externally.
If it is, then there are only two components that can be wrong: u-boot SPL and ATF (bl31.bin), am I right?
Also, I assume that bl31.bin is incorporated into spl/boot.bin, so I don't need to supply it externally, is that so?
ATF is not the part of boot.bin. PMUFW is the part of boot.bin.
Don't get me wrong, I already tested loads of configurations with various incarnations of PMUFW and configuration object, etc., and never ever have I seen the "U-Boot SPL" welcome message on the UART. I guess it just doesn't want to greet me for some reason or another.
If you blame spl just use fsbl instead. ATF/PMUFW can be taken from petalinux to find out which component is failing for you.
M
Hi Michal,
ATF is not the part of boot.bin. PMUFW is the part of boot.bin.
I'm confused. U-boot requires bl31.bin while building but not PMUFW (unless a non-default configuration option is set). Just to confirm that I'm thinking straight: ATF must be supplied in the form of a file bl31.bin in the SD card root directory in order for SPL to load it?
Cheers,
András
hi,
On 12. 03. 20 15:19, Major A wrote:
Hi Michal,
ATF is not the part of boot.bin. PMUFW is the part of boot.bin.
I'm confused. U-boot requires bl31.bin while building but not PMUFW (unless a non-default configuration option is set). Just to confirm that I'm thinking straight: ATF must be supplied in the form of a file bl31.bin in the SD card root directory in order for SPL to load it?
SD boot flow boot.bin which contains u-boot SPL and PMUFW.
SPL looks for u-boot.itb on fat partition which is U-Boot fit image which contains u-boot-nodtb, ATF(bl31.bin) and dtbs. It means flow is PMUFW on PMU, SPL -> ATF -> U-Boot proper.
bl31.bin is only required for u-boot.itb generation. If you don't pass it it won't be included in u-boot.itb. I haven't tested SPL-> U-Boot in EL3 but it doesn't make too much sense anyway.
Thanks, Michal
Hi Michal,
I've had to take a break because, as it turned out, my ZCU102 was defective. Now that I have a working one, I can go on with my frustrating quest for a bootable image.
So now that the patches to u-boot for the ZCU102 Rev. 1.1 are in git master, I started again from scratch, building ATF, PMUFW with patch and config object, and u-boot.
Once the builds finish, I place the files
spl/boot.bin
and
u-boot.itb
on the SD card and try to boot. Sadly, as before, the only result I get on the first UART channel is a line
Debug uart enabled
sometimes followed by
### ERROR ### Please RESET the board ###
but nothing else.
My suspicion is that the PMUFW or its configuration object isn't right. I use Luca's code from here to build both:
https://github.com/lucaceresoli/zynqmp-pmufw-builder.git
I also found an issue here:
https://forums.xilinx.com/t5/ACAP-and-SoC-Boot-and/Booting-ZCU-102-from-SD-C...
It appears that there are at least two incompatible subrevisions of the board, both labeled Rev. 1.1. Could it be that the current PMUFW (or whatever) just won't work with the current revision?
How do I figure out what the h*** is going on?
Cheers,
András
On 12/03/2020 16:22, Michal Simek wrote:
hi,
On 12. 03. 20 15:19, Major A wrote:
Hi Michal,
ATF is not the part of boot.bin. PMUFW is the part of boot.bin.
I'm confused. U-boot requires bl31.bin while building but not PMUFW (unless a non-default configuration option is set). Just to confirm that I'm thinking straight: ATF must be supplied in the form of a file bl31.bin in the SD card root directory in order for SPL to load it?
SD boot flow boot.bin which contains u-boot SPL and PMUFW.
SPL looks for u-boot.itb on fat partition which is U-Boot fit image which contains u-boot-nodtb, ATF(bl31.bin) and dtbs. It means flow is PMUFW on PMU, SPL -> ATF -> U-Boot proper.
bl31.bin is only required for u-boot.itb generation. If you don't pass it it won't be included in u-boot.itb. I haven't tested SPL-> U-Boot in EL3 but it doesn't make too much sense anyway.
Thanks, Michal
Hi,
On 23. 04. 20 11:02, Major A wrote:
Hi Michal,
I've had to take a break because, as it turned out, my ZCU102 was defective. Now that I have a working one, I can go on with my frustrating quest for a bootable image.
So now that the patches to u-boot for the ZCU102 Rev. 1.1 are in git master, I started again from scratch, building ATF, PMUFW with patch and config object, and u-boot.
Once the builds finish, I place the files
spl/boot.bin
and
u-boot.itb
on the SD card and try to boot. Sadly, as before, the only result I get on the first UART channel is a line
Debug uart enabled
sometimes followed by
### ERROR ### Please RESET the board ###
but nothing else.
My suspicion is that the PMUFW or its configuration object isn't right. I use Luca's code from here to build both:
https://github.com/lucaceresoli/zynqmp-pmufw-builder.git
I also found an issue here:
https://forums.xilinx.com/t5/ACAP-and-SoC-Boot-and/Booting-ZCU-102-from-SD-C...
It appears that there are at least two incompatible subrevisions of the board, both labeled Rev. 1.1. Could it be that the current PMUFW (or whatever) just won't work with the current revision?
How do I figure out what the h*** is going on?
That boards should have just different DDR memory because origin was EOL.
Take a look at this mainline commit. commit 47cc45a91ccc86c718fef7e8a00188e1047cf3dd arm64: zynqmp Add support for zcu102 rev1.1
You need to also add pmu.bin and pmu_obj.bin
CONFIG_PMUFW_INIT_FILE="pmu.bin" CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE="pmu_obj.bin"
pmu.bin is just binary from pmu.elf which you can take from petalinux or build it yourself. pmu_obj.bin based on Luca's way. I personally is taking it from petalinux fsbl. I didn't try it for a while but this was sort of latest version.
$ cat extract-pmufw #!/bin/bash # Written by Michal Simek
FSBL=fsbl PMCFG=pmu_obj.bin
PM_END=`aarch64-linux-gnu-objdump -D ${FSBL}.elf | sed -n '/<XPm_ConfigObject>:/,/^$/p' | tail -n 2 | head -n 1 | cut -c 5-12 | awk '{printf ("0x%s",$1)}'` PM_START=`aarch64-linux-gnu-objdump -D ${FSBL}.elf | sed -n '/<XPm_ConfigObject>:/,/^$/p' | head -n 1 | awk '{printf ("0x%s",$1)}'`
FSBL_START=`aarch64-linux-gnu-readelf -a ${FSBL}.elf | grep "Entry point address" | awk '{print $4}'`
PM_OBJECT_START=`echo $((${PM_START} - ${FSBL_START}))` PM_OBJECT_SIZE=`echo $((${PM_END} - ${PM_START}))` PM_OBJECT_SIZE=`echo $((${PM_OBJECT_SIZE} + 4))`
echo "FSBL starting address ${FSBL_START}" echo "FSBL object addresses ${PM_START} ${PM_END}" echo "OBJECT start ${PM_OBJECT_START} size ${PM_OBJECT_SIZE}"
aarch64-linux-gnu-objcopy -O binary ${FSBL}.elf ${FSBL}.bin
# Extracting config object dd if=${FSBL}.bin of=${PMCFG} bs=1 skip=${PM_OBJECT_START} count=${PM_OBJECT_SIZE} > /dev/null 2>&1
And then simply build it like this. export DEVICE_TREE=zynqmp-zcu102-rev1.1 make xilinx_zynqmp_virt_defconfig make -j8
If you want to have ATF just copy bl31.bin to u-boot root ro use BL31 variable to generate u-boot.itb with it.
And that should be it.
Thanks, Michal
Hi Michal,
Thanks for your script, I tried it, it can extract the PMU config object from the FSBL generated by Vitis, but the SD card I prepare this way still doesn't boot.
It does one thing differently than before, though: the line
### ERROR ### Please RESET the board ###
appears EVERY time, not just occasionally.
Any ideas what I'm doing wrong?
Cheers,
András
On 24/04/2020 14:14, Michal Simek wrote:
Hi,
On 23. 04. 20 11:02, Major A wrote:
Hi Michal,
I've had to take a break because, as it turned out, my ZCU102 was defective. Now that I have a working one, I can go on with my frustrating quest for a bootable image.
So now that the patches to u-boot for the ZCU102 Rev. 1.1 are in git master, I started again from scratch, building ATF, PMUFW with patch and config object, and u-boot.
Once the builds finish, I place the files
spl/boot.bin
and
u-boot.itb
on the SD card and try to boot. Sadly, as before, the only result I get on the first UART channel is a line
Debug uart enabled
sometimes followed by
### ERROR ### Please RESET the board ###
but nothing else.
My suspicion is that the PMUFW or its configuration object isn't right. I use Luca's code from here to build both:
https://github.com/lucaceresoli/zynqmp-pmufw-builder.git
I also found an issue here:
https://forums.xilinx.com/t5/ACAP-and-SoC-Boot-and/Booting-ZCU-102-from-SD-C...
It appears that there are at least two incompatible subrevisions of the board, both labeled Rev. 1.1. Could it be that the current PMUFW (or whatever) just won't work with the current revision?
How do I figure out what the h*** is going on?
That boards should have just different DDR memory because origin was EOL.
Take a look at this mainline commit. commit 47cc45a91ccc86c718fef7e8a00188e1047cf3dd arm64: zynqmp Add support for zcu102 rev1.1
You need to also add pmu.bin and pmu_obj.bin
CONFIG_PMUFW_INIT_FILE="pmu.bin" CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE="pmu_obj.bin"
pmu.bin is just binary from pmu.elf which you can take from petalinux or build it yourself. pmu_obj.bin based on Luca's way. I personally is taking it from petalinux fsbl. I didn't try it for a while but this was sort of latest version.
$ cat extract-pmufw #!/bin/bash # Written by Michal Simek
FSBL=fsbl PMCFG=pmu_obj.bin
PM_END=`aarch64-linux-gnu-objdump -D ${FSBL}.elf | sed -n '/<XPm_ConfigObject>:/,/^$/p' | tail -n 2 | head -n 1 | cut -c 5-12 | awk '{printf ("0x%s",$1)}'` PM_START=`aarch64-linux-gnu-objdump -D ${FSBL}.elf | sed -n '/<XPm_ConfigObject>:/,/^$/p' | head -n 1 | awk '{printf ("0x%s",$1)}'`
FSBL_START=`aarch64-linux-gnu-readelf -a ${FSBL}.elf | grep "Entry point address" | awk '{print $4}'`
PM_OBJECT_START=`echo $((${PM_START} - ${FSBL_START}))` PM_OBJECT_SIZE=`echo $((${PM_END} - ${PM_START}))` PM_OBJECT_SIZE=`echo $((${PM_OBJECT_SIZE} + 4))`
echo "FSBL starting address ${FSBL_START}" echo "FSBL object addresses ${PM_START} ${PM_END}" echo "OBJECT start ${PM_OBJECT_START} size ${PM_OBJECT_SIZE}"
aarch64-linux-gnu-objcopy -O binary ${FSBL}.elf ${FSBL}.bin
# Extracting config object dd if=${FSBL}.bin of=${PMCFG} bs=1 skip=${PM_OBJECT_START} count=${PM_OBJECT_SIZE} > /dev/null 2>&1
And then simply build it like this. export DEVICE_TREE=zynqmp-zcu102-rev1.1 make xilinx_zynqmp_virt_defconfig make -j8
If you want to have ATF just copy bl31.bin to u-boot root ro use BL31 variable to generate u-boot.itb with it.
And that should be it.
Thanks, Michal
Hi,
On 28. 04. 20 0:00, Major A wrote:
Hi Michal,
Thanks for your script, I tried it, it can extract the PMU config object from the FSBL generated by Vitis, but the SD card I prepare this way still doesn't boot.
It does one thing differently than before, though: the line
### ERROR ### Please RESET the board ###
Can you please try xilinx u-boot master branch instead?
Tap delay programming can be one of the reason. But the best would be to load it via jtag and look at backtrace where the problem is.
Thanks, Michal
Hi Michal,
Thanks for your script, I tried it, it can extract the PMU config object from the FSBL generated by Vitis, but the SD card I prepare this way still doesn't boot.
It does one thing differently than before, though: the line
### ERROR ### Please RESET the board ###
Can you please try xilinx u-boot master branch instead?
Sadly, the result is exactly the same as before. BTW, the Rev1.1 changes are not in master yet, I had to enter them manually.
Tap delay programming can be one of the reason. But the best would be to load it via jtag and look at backtrace where the problem is.
How do I debug it via JTAG? Any instructions on that somewhere?
Cheers,
András
On 28. 04. 20 11:29, Major A wrote:
Hi Michal,
Thanks for your script, I tried it, it can extract the PMU config object from the FSBL generated by Vitis, but the SD card I prepare this way still doesn't boot.
It does one thing differently than before, though: the line
### ERROR ### Please RESET the board ###
Can you please try xilinx u-boot master branch instead?
Sadly, the result is exactly the same as before. BTW, the Rev1.1 changes are not in master yet, I had to enter them manually.
Tap delay programming can be one of the reason. But the best would be to load it via jtag and look at backtrace where the problem is.
How do I debug it via JTAG? Any instructions on that somewhere?
here is xsdb script which loads it via jtag.
+connect +targets -set -filter {name =~ "PSU"} + +set status [mrd -force -value 0xFFCA0038] +set status [expr $status | 0x1C0] +mwr -force 0xFFCA0038 $status + +targets -set -filter {name =~ "MicroBlaze PMU"} +dow pmu.elf +con + + +targets -set -filter {name =~ "PSU"} +mwr 0xffff0000 0x14000000 +mask_write 0xFD1A0104 0x501 0x0 + +after 1000 + + +targets -set -filter {name =~ "Cortex-A53 #0"} +stop +dow -data u-boot-spl-dtb.bin 0xfffc0000 +memmap -file u-boot-spl +rwr pc 0xfffc0000 +bpadd -addr &udelay + +if { [catch {con -block -timeout 3000} msg] } { + puts "err: $msg" + exit + # do something to handle the error +} +
At this stage your DDR should be up and running. You can check it by mrd 0 10 for example to see if DDR is stable
+bpremove 0 + +dow -data u-boot.itb 0x10000000
Then this shouldn't fail.
+con
And if you get to reset then you stop cpu and you can call bt to get trace where you were.
Thanks, Michal
Hi Michal,
Xilinx doesn't like me. Here's the output and where I get stuck:
xsdb% targets -set -filter {name =~ "PSU"} no targets found with "name =~ "PSU"". available targets: 1 whole scan chain (DR shift through all zeroes) xsdb%
Any ideas? Any jumpers I failed to set? Boot mode is set to JTAG.
Cheers,
András
On 28/04/2020 11:33, Michal Simek wrote:
On 28. 04. 20 11:29, Major A wrote:
Hi Michal,
Thanks for your script, I tried it, it can extract the PMU config object from the FSBL generated by Vitis, but the SD card I prepare this way still doesn't boot.
It does one thing differently than before, though: the line
### ERROR ### Please RESET the board ###
Can you please try xilinx u-boot master branch instead?
Sadly, the result is exactly the same as before. BTW, the Rev1.1 changes are not in master yet, I had to enter them manually.
Tap delay programming can be one of the reason. But the best would be to load it via jtag and look at backtrace where the problem is.
How do I debug it via JTAG? Any instructions on that somewhere?
here is xsdb script which loads it via jtag.
+connect +targets -set -filter {name =~ "PSU"}
+set status [mrd -force -value 0xFFCA0038] +set status [expr $status | 0x1C0] +mwr -force 0xFFCA0038 $status
+targets -set -filter {name =~ "MicroBlaze PMU"} +dow pmu.elf +con
+targets -set -filter {name =~ "PSU"} +mwr 0xffff0000 0x14000000 +mask_write 0xFD1A0104 0x501 0x0
+after 1000
+targets -set -filter {name =~ "Cortex-A53 #0"} +stop +dow -data u-boot-spl-dtb.bin 0xfffc0000 +memmap -file u-boot-spl +rwr pc 0xfffc0000 +bpadd -addr &udelay
+if { [catch {con -block -timeout 3000} msg] } {
puts "err: $msg"exit# do something to handle the error+}
At this stage your DDR should be up and running. You can check it by mrd 0 10 for example to see if DDR is stable
+bpremove 0
+dow -data u-boot.itb 0x10000000
Then this shouldn't fail.
+con
And if you get to reset then you stop cpu and you can call bt to get trace where you were.
Thanks, Michal
Hi,
On 28. 04. 20 12:53, Major A wrote:
Hi Michal,
Xilinx doesn't like me. Here's the output and where I get stuck:
xsdb% targets -set -filter {name =~ "PSU"} no targets found with "name =~ "PSU"". available targets: 1 whole scan chain (DR shift through all zeroes) xsdb%
Any ideas? Any jumpers I failed to set? Boot mode is set to JTAG.
check jtag ta - that you see the board. Reset the board, check that jtag mode pins again.
Thanks, Michal
Hi Michal,
"ta" returns the same thing whatever I do:
1 whole scan chain (DR shift through all zeroes)
Any ideas? SW6 is set to on/on/on/on. Anything else that needs setting?
Cheers,
András
On 28/04/2020 13:16, Michal Simek wrote:
Hi,
On 28. 04. 20 12:53, Major A wrote:
Hi Michal,
Xilinx doesn't like me. Here's the output and where I get stuck:
xsdb% targets -set -filter {name =~ "PSU"} no targets found with "name =~ "PSU"". available targets: 1 whole scan chain (DR shift through all zeroes) xsdb%
Any ideas? Any jumpers I failed to set? Boot mode is set to JTAG.
check jtag ta - that you see the board. Reset the board, check that jtag mode pins again.
Thanks, Michal
On 28. 04. 20 13:25, Major A wrote:
Hi Michal,
"ta" returns the same thing whatever I do:
1 whole scan chain (DR shift through all zeroes)
Any ideas? SW6 is set to on/on/on/on. Anything else that needs setting?
not really. I don't have 1.1 version here but you can also try off/off/off/off. But it should be written in user guide.
Board has jtag via two connectors - via usb (next to uart) or via standard xilinx jtag 2x7 connector. Try both. I am quite sure that you need to change something to get one working.
Also use different USB without usb hubs. But jtag is so simply that it should just work.
Thanks, Michal
Hi Michal,
It turns out that the JTAG chain was interrupted by an FMC card. After removing it, this is what your JTAG commands give me (starting at the point where it gets interesting):
xsdb% dow -data spl/u-boot-spl-dtb.bin 0xfffc0000 100% 0MB 0.2MB/s 00:00 Successfully downloaded <u-boot path>/spl/u-boot-spl-dtb.bin xsdb% memmap -file spl/u-boot-spl xsdb% rwr pc 0xfffc0000 xsdb% bpadd -addr &udelay 0 xsdb% Info: Breakpoint 0 status: target 9: {Address: 0xfffcc484 Type: Hardware} xsdb% con -block -timeout 3000 Info: Cortex-A53 #0 (target 9) Running xsdb% Info: Cortex-A53 #0 (target 9) Stopped at 0xfffcc484 (Breakpoint) udelay() at lib/time.c: 178 178: couldn't open "<u-boot path>/lib/time.c": no such file or directory xsdb% bpremove 0 xsdb% dow -data u-boot.itb 0x10000000 100% 1MB 0.2MB/s 00:08 Successfully downloaded <u-boot path>/u-boot.itb xsdb% con
At this point, there is no more console output.
Question: does this look like what you expect? Why is there a reference to lib/time.c in a binary file, and with an absolute path on top of that? The file isn't there because I only copied the files loaded into the debugger from the u-boot repository (they are on two different computers because xsdb only works on a Windows machine). So, lib/time.c is there on the build machine but not on the xsdb one.
What next?
András
On 28/04/2020 13:29, Michal Simek wrote:
On 28. 04. 20 13:25, Major A wrote:
Hi Michal,
"ta" returns the same thing whatever I do:
1 whole scan chain (DR shift through all zeroes)
Any ideas? SW6 is set to on/on/on/on. Anything else that needs setting?
not really. I don't have 1.1 version here but you can also try off/off/off/off. But it should be written in user guide.
Board has jtag via two connectors - via usb (next to uart) or via standard xilinx jtag 2x7 connector. Try both. I am quite sure that you need to change something to get one working.
Also use different USB without usb hubs. But jtag is so simply that it should just work.
Thanks, Michal
On 28. 04. 20 15:34, Major A wrote:
Hi Michal,
It turns out that the JTAG chain was interrupted by an FMC card. After removing it, this is what your JTAG commands give me (starting at the point where it gets interesting):
I am missing here loading pmufw elf file.
xsdb% dow -data spl/u-boot-spl-dtb.bin 0xfffc0000 100% 0MB 0.2MB/s 00:00 Successfully downloaded <u-boot path>/spl/u-boot-spl-dtb.bin xsdb% memmap -file spl/u-boot-spl xsdb% rwr pc 0xfffc0000 xsdb% bpadd -addr &udelay 0 xsdb% Info: Breakpoint 0 status: target 9: {Address: 0xfffcc484 Type: Hardware} xsdb% con -block -timeout 3000 Info: Cortex-A53 #0 (target 9) Running xsdb% Info: Cortex-A53 #0 (target 9) Stopped at 0xfffcc484 (Breakpoint) udelay() at lib/time.c: 178 178: couldn't open "<u-boot path>/lib/time.c": no such file or directory xsdb% bpremove 0 xsdb% dow -data u-boot.itb 0x10000000 100% 1MB 0.2MB/s 00:08 Successfully downloaded <u-boot path>/u-boot.itb xsdb% con
At this point, there is no more console output.
then you should stop it and show where cpu stops, ta, rrd and bt to see where you are.
Question: does this look like what you expect? Why is there a reference to lib/time.c in a binary file, and with an absolute path on top of that? The file isn't there because I only copied the files loaded into the debugger from the u-boot repository (they are on two different computers because xsdb only works on a Windows machine). So, lib/time.c is there on the build machine but not on the xsdb one.
xsdb log above looks good to me. xsdb is also working on Linux
Thanks, Michal
Hi Michal,
I am missing here loading pmufw elf file.
See below the entire log.
Cheers,
András
****** Xilinx System Debugger (XSDB) v2019.2 **** Build date : Nov 6 2019-22:12:26 ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.
xsdb% source script attempting to launch hw_server
****** Xilinx hw_server v2019.2 **** Build date : Nov 6 2019 at 22:12:23 ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.
INFO: hw_server application started INFO: Use Ctrl-C to exit hw_server application
****** Xilinx hw_server v2019.2
**** Build date : Nov 6 2019 at 22:12:23
** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.
INFO: hw_server application started
INFO: Use Ctrl-C to exit hw_server application
INFO: To connect to this hw_server instance use url: TCP:127.0.0.1:3121
Downloading Program -- C:/home/u-boot/pmufw.elf section, .vectors.reset: 0xffdc0000 - 0xffdc0007 section, .vectors.sw_exception: 0xffdc0008 - 0xffdc000f section, .vectors.interrupt: 0xffdc0010 - 0xffdc0017 section, .vectors.hw_exception: 0xffdc0020 - 0xffdc0027 section, .text: 0xffdc0050 - 0xffdd108b section, .rodata: 0xffdd108c - 0xffdd31a3 section, .data: 0xffdd31a4 - 0xffdd749b section, .sdata2: 0xffdd749c - 0xffdd749f section, .sdata: 0xffdd74a0 - 0xffdd749f section, .sbss: 0xffdd74a0 - 0xffdd749f section, .bss: 0xffdd74a0 - 0xffddb4cb section, .srdata: 0xffddb4cc - 0xffddbdef section, .stack: 0xffddbdf0 - 0xffddcdef section, .xpbr_serv_ext_tbl: 0xffddf6e0 - 0xffddfadf 100% 0MB 0.2MB/s 00:00 Setting PC to Program Start Address 0xffdd02a0 Successfully downloaded C:/home/u-boot/pmufw.elf Info: MicroBlaze PMU (target 13) Running Info: Cortex-A53 #0 (target 9) Stopped at 0xffff0000 (External Debug Request) 100% 0MB 0.2MB/s 00:00 Successfully downloaded C:/home/u-boot/spl/u-boot-spl-dtb.bin Info: Cortex-A53 #0 (target 9) Running Info: Breakpoint 0 status: target 9: {Address: 0xfffcc484 Type: Hardware} xsdb% Info: Cortex-A53 #0 (target 9) Stopped at 0xfffcc484 (Breakpoint) udelay() at lib/time.c: 178 178: couldn't open "<u-boot build-dir>/lib/time.c": no such file or directory xsdb% bpremove 0 xsdb% dow -data u-boot.itb 0x10000000 100% 1MB 0.2MB/s 00:08 Successfully downloaded C:/home/u-boot/u-boot.itb xsdb% con Info: Cortex-A53 #0 (target 9) Running xsdb% stop Cannot halt processor core, timeout xsdb% stop Cannot halt processor core, timeout xsdb% ta 1 PS TAP 2 PMU 13 MicroBlaze PMU (Sleeping. No clock) 3 PL 4 PSU 5 RPU (Reset) 6 Cortex-R5 #0 (RPU Reset) 7 Cortex-R5 #1 (RPU Reset) 8 APU 9* Cortex-A53 #0 (Running) 10 Cortex-A53 #1 (Power On Reset) 11 Cortex-A53 #2 (Power On Reset) 12 Cortex-A53 #3 (Power On Reset) xsdb% con Already running xsdb% stop Cannot halt processor core, timeout xsdb% ta 1 PS TAP 2 PMU 13 MicroBlaze PMU (Sleeping. No clock) 3 PL 4 PSU 5 RPU (Reset) 6 Cortex-R5 #0 (RPU Reset) 7 Cortex-R5 #1 (RPU Reset) 8 APU 9* Cortex-A53 #0 (Running) 10 Cortex-A53 #1 (Power On Reset) 11 Cortex-A53 #2 (Power On Reset) 12 Cortex-A53 #3 (Power On Reset) xsdb% rrd r0: N/A r1: N/A r2: N/A r3: N/A r4: N/A r5: N/A r6: N/A r7: N/A r8: N/A r9: N/A r10: N/A r11: N/A r12: N/A r13: N/A r14: N/A r15: N/A r16: N/A r17: N/A r18: N/A r19: N/A r20: N/A r21: N/A r22: N/A r23: N/A r24: N/A r25: N/A r26: N/A r27: N/A r28: N/A r29: N/A r30: N/A sp: N/A pc: 00000000fffc78e4 cpsr: N/A vfp sys dbg acpu_gic xsdb% bt xsdb%
participants (2)
-
Major A -
Michal Simek