* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
@ 2020-03-11 11:28 Major A
2020-03-12 8:15 ` Michal Simek
0 siblings, 1 reply; 29+ messages in thread
From: Major A @ 2020-03-11 11:28 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-03-11 11:28 ZynqMP boot: no messages from SPL other than "Debug uart enabled" Major A
@ 2020-03-12 8:15 ` Michal Simek
2020-03-12 9:12 ` Major A
0 siblings, 1 reply; 29+ messages in thread
From: Michal Simek @ 2020-03-12 8:15 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-03-12 8:15 ` Michal Simek
@ 2020-03-12 9:12 ` Major A
2020-03-12 10:32 ` Michal Simek
0 siblings, 1 reply; 29+ messages in thread
From: Major A @ 2020-03-12 9:12 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-03-12 9:12 ` Major A
@ 2020-03-12 10:32 ` Michal Simek
2020-03-12 11:38 ` Major A
0 siblings, 1 reply; 29+ messages in thread
From: Michal Simek @ 2020-03-12 10:32 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 29+ messages in thread* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-03-12 10:32 ` Michal Simek
@ 2020-03-12 11:38 ` Major A
2020-03-12 11:44 ` Michal Simek
0 siblings, 1 reply; 29+ messages in thread
From: Major A @ 2020-03-12 11:38 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-03-12 11:38 ` Major A
@ 2020-03-12 11:44 ` Michal Simek
2020-03-12 12:01 ` Major A
0 siblings, 1 reply; 29+ messages in thread
From: Michal Simek @ 2020-03-12 11:44 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 29+ messages in thread* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-03-12 11:44 ` Michal Simek
@ 2020-03-12 12:01 ` Major A
2020-03-12 12:06 ` Michal Simek
0 siblings, 1 reply; 29+ messages in thread
From: Major A @ 2020-03-12 12:01 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 29+ messages in thread* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-03-12 12:01 ` Major A
@ 2020-03-12 12:06 ` Michal Simek
2020-03-12 13:24 ` Major A
0 siblings, 1 reply; 29+ messages in thread
From: Michal Simek @ 2020-03-12 12:06 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 29+ messages in thread* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-03-12 12:06 ` Michal Simek
@ 2020-03-12 13:24 ` Major A
2020-03-12 13:31 ` Michal Simek
0 siblings, 1 reply; 29+ messages in thread
From: Major A @ 2020-03-12 13:24 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-03-12 13:24 ` Major A
@ 2020-03-12 13:31 ` Michal Simek
2020-03-12 14:19 ` Major A
0 siblings, 1 reply; 29+ messages in thread
From: Michal Simek @ 2020-03-12 13:31 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-03-12 13:31 ` Michal Simek
@ 2020-03-12 14:19 ` Major A
2020-03-12 15:22 ` Michal Simek
0 siblings, 1 reply; 29+ messages in thread
From: Major A @ 2020-03-12 14:19 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-03-12 14:19 ` Major A
@ 2020-03-12 15:22 ` Michal Simek
2020-04-23 9:02 ` Major A
0 siblings, 1 reply; 29+ messages in thread
From: Michal Simek @ 2020-03-12 15:22 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-03-12 15:22 ` Michal Simek
@ 2020-04-23 9:02 ` Major A
2020-04-24 12:14 ` Michal Simek
0 siblings, 1 reply; 29+ messages in thread
From: Major A @ 2020-04-23 9:02 UTC (permalink / raw)
To: u-boot
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-Card/td-p/926649
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
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-04-23 9:02 ` Major A
@ 2020-04-24 12:14 ` Michal Simek
2020-04-27 22:00 ` Major A
0 siblings, 1 reply; 29+ messages in thread
From: Michal Simek @ 2020-04-24 12:14 UTC (permalink / raw)
To: u-boot
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-Card/td-p/926649
>
>
> 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
^ permalink raw reply [flat|nested] 29+ messages in thread* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-04-24 12:14 ` Michal Simek
@ 2020-04-27 22:00 ` Major A
2020-04-28 6:42 ` Michal Simek
0 siblings, 1 reply; 29+ messages in thread
From: Major A @ 2020-04-27 22:00 UTC (permalink / raw)
To: u-boot
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-Card/td-p/926649
>>
>>
>> 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
>
>
>
>
^ permalink raw reply [flat|nested] 29+ messages in thread* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-04-27 22:00 ` Major A
@ 2020-04-28 6:42 ` Michal Simek
2020-04-28 9:29 ` Major A
0 siblings, 1 reply; 29+ messages in thread
From: Michal Simek @ 2020-04-28 6:42 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-04-28 6:42 ` Michal Simek
@ 2020-04-28 9:29 ` Major A
2020-04-28 9:33 ` Michal Simek
0 siblings, 1 reply; 29+ messages in thread
From: Major A @ 2020-04-28 9:29 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-04-28 9:29 ` Major A
@ 2020-04-28 9:33 ` Michal Simek
2020-04-28 10:53 ` Major A
0 siblings, 1 reply; 29+ messages in thread
From: Michal Simek @ 2020-04-28 9:33 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 29+ messages in thread* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-04-28 9:33 ` Michal Simek
@ 2020-04-28 10:53 ` Major A
2020-04-28 11:16 ` Michal Simek
0 siblings, 1 reply; 29+ messages in thread
From: Major A @ 2020-04-28 10:53 UTC (permalink / raw)
To: u-boot
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
>
^ permalink raw reply [flat|nested] 29+ messages in thread* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-04-28 10:53 ` Major A
@ 2020-04-28 11:16 ` Michal Simek
2020-04-28 11:25 ` Major A
0 siblings, 1 reply; 29+ messages in thread
From: Michal Simek @ 2020-04-28 11:16 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 29+ messages in thread* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-04-28 11:16 ` Michal Simek
@ 2020-04-28 11:25 ` Major A
2020-04-28 11:29 ` Michal Simek
0 siblings, 1 reply; 29+ messages in thread
From: Major A @ 2020-04-28 11:25 UTC (permalink / raw)
To: u-boot
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
>
^ permalink raw reply [flat|nested] 29+ messages in thread* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-04-28 11:25 ` Major A
@ 2020-04-28 11:29 ` Michal Simek
2020-04-28 13:34 ` Major A
0 siblings, 1 reply; 29+ messages in thread
From: Michal Simek @ 2020-04-28 11:29 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-04-28 11:29 ` Michal Simek
@ 2020-04-28 13:34 ` Major A
2020-04-28 13:55 ` Michal Simek
0 siblings, 1 reply; 29+ messages in thread
From: Major A @ 2020-04-28 13:34 UTC (permalink / raw)
To: u-boot
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
>
^ permalink raw reply [flat|nested] 29+ messages in thread* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-04-28 13:34 ` Major A
@ 2020-04-28 13:55 ` Michal Simek
2020-04-28 14:21 ` Major A
0 siblings, 1 reply; 29+ messages in thread
From: Michal Simek @ 2020-04-28 13:55 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 29+ messages in thread* ZynqMP boot: no messages from SPL other than "Debug uart enabled"
2020-04-28 13:55 ` Michal Simek
@ 2020-04-28 14:21 ` Major A
[not found] ` <3ab17480-431a-e0e3-c2af-e1639a2d07a6@xilinx.com>
0 siblings, 1 reply; 29+ messages in thread
From: Major A @ 2020-04-28 14:21 UTC (permalink / raw)
To: u-boot
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%
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2020-04-30 11:10 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-11 11:28 ZynqMP boot: no messages from SPL other than "Debug uart enabled" Major A
2020-03-12 8:15 ` Michal Simek
2020-03-12 9:12 ` Major A
2020-03-12 10:32 ` Michal Simek
2020-03-12 11:38 ` Major A
2020-03-12 11:44 ` Michal Simek
2020-03-12 12:01 ` Major A
2020-03-12 12:06 ` Michal Simek
2020-03-12 13:24 ` Major A
2020-03-12 13:31 ` Michal Simek
2020-03-12 14:19 ` Major A
2020-03-12 15:22 ` Michal Simek
2020-04-23 9:02 ` Major A
2020-04-24 12:14 ` Michal Simek
2020-04-27 22:00 ` Major A
2020-04-28 6:42 ` Michal Simek
2020-04-28 9:29 ` Major A
2020-04-28 9:33 ` Michal Simek
2020-04-28 10:53 ` Major A
2020-04-28 11:16 ` Michal Simek
2020-04-28 11:25 ` Major A
2020-04-28 11:29 ` Michal Simek
2020-04-28 13:34 ` Major A
2020-04-28 13:55 ` Michal Simek
2020-04-28 14:21 ` Major A
[not found] ` <3ab17480-431a-e0e3-c2af-e1639a2d07a6@xilinx.com>
[not found] ` <6b4c296f-fb91-fd84-f5c8-7b4f542034e4@gmail.com>
2020-04-30 10:20 ` Fwd: " Major A
[not found] ` <4f8b4b6a-c97d-38b8-5a74-98bbc916cb3a@xilinx.com>
2020-04-30 11:01 ` Major A
2020-04-30 11:03 ` Michal Simek
2020-04-30 11:10 ` Major A
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.