ZynqMP boot: no messages from SPL other than "Debug uart enabled"

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Major A]

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

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Michal Simek]

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

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Major A]

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

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Michal Simek]

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

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Major A]

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

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Michal Simek]

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

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Major A]

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

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Michal Simek]

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

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Major A]

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

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Michal Simek]

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

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Major A]

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

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Michal Simek]

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

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Major A]

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
> 

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Michal Simek]

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

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Major A]

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
> 
> 
> 
> 

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Michal Simek]

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

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Major A]

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

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Michal Simek]

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

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Major A]

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
> 

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Michal Simek]

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

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Major A]

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
> 

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Michal Simek]

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

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Major A]

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
> 

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Michal Simek]

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

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Major A]

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%

Fwd: Re: ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Major A]

Hi Michal,

> can you please try these files in SD boot mode?

Done, here are two logs, both in SD boot mode.

First, log.sd is with SD card inserted (with the image files that 
apparently refuse to work other than the early UART message).

The other file, log.no-sd, is with no card inserted.

Cheers,

    Andr?s

-------------- next part --------------
A non-text attachment was scrubbed...
Name: log.sd
Type: chemical/x-mdl-sdfile
Size: 1804 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200430/29db97cf/attachment.sd>
-------------- next part --------------

****** Xilinx System Debugger (XSDB) v2019.2
  **** Build date : Nov  6 2019-22:12:26
    ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.


xsdb% cd
xsdb% cd ../../home/u-boot
xsdb% pwd
C:/home/u-boot
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) Stopped at 0xfffcc484 (Breakpoint)
udelay() at lib/time.c: 178
178: couldn't open "<u-boot build path>/lib/time.c": no such file or directory
Info: Breakpoint 0 status:
   target 9: {Address: 0xfffcc484 Type: Hardware}
xsdb% Info: Cortex-A53 #0 (target 9) Stopped at 0xfffcc484 (Breakpoint)
178: couldn't open "<u-boot build path>/lib/time.c": no such file or directory
xsdb%

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Major A]

Hi Michal,

Sorry I misunderstood your message, and I didn't spot the attached 
files.  Now I booted with those two files, there's no output on the 
UARTs whatsoever.  Is there anything else I can try?

Cheers,

   Andr?s


On 30/04/2020 12:33, Michal Simek wrote:
> Hi,
> 
> On 30. 04. 20 12:19, Major A wrote:
>> Hi Michal,
>>
>>> can you please try these files in SD boot mode?
>>
>> Done, here are two logs, both in SD boot mode.
>>
>> First, log.sd is with SD card inserted (with the image files that
>> apparently refuse to work other than the early UART message).
>>
>> The other file, log.no-sd, is with no card inserted.
> 
> we don't understand each other. I sent you boot.bin and image.itb. Just
> copy them to SD card, switch board to sd boot mode and power it up.
> 
> Thanks,
> Michal
> 

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Michal Simek]

hi,

that's quite weird. Did you try any petalinux bsp and boot petalinux
boot.bin on that board to make sure that board is fine?

M

On 30. 04. 20 13:01, Major A wrote:
> Hi Michal,
> 
> Sorry I misunderstood your message, and I didn't spot the attached
> files.? Now I booted with those two files, there's no output on the
> UARTs whatsoever.? Is there anything else I can try?
> 
> Cheers,
> 
> ? Andr?s
> 
> 
> On 30/04/2020 12:33, Michal Simek wrote:
>> Hi,
>>
>> On 30. 04. 20 12:19, Major A wrote:
>>> Hi Michal,
>>>
>>>> can you please try these files in SD boot mode?
>>>
>>> Done, here are two logs, both in SD boot mode.
>>>
>>> First, log.sd is with SD card inserted (with the image files that
>>> apparently refuse to work other than the early UART message).
>>>
>>> The other file, log.no-sd, is with no card inserted.
>>
>> we don't understand each other. I sent you boot.bin and image.itb. Just
>> copy them to SD card, switch board to sd boot mode and power it up.
>>
>> Thanks,
>> Michal
>>

ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Major A]

Hi Michal,

Yes, I did.  The Petalinux image from here:

 
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841937/Zynq+UltraScale+MPSoC+Ubuntu+part+2+-+Building+and+Running+the+Ubuntu+Desktop+From+Sources

works fine.

Cheers,

   Andr?s


On 30/04/2020 13:03, Michal Simek wrote:
> hi,
> 
> that's quite weird. Did you try any petalinux bsp and boot petalinux
> boot.bin on that board to make sure that board is fine?
> 
> M
> 
> On 30. 04. 20 13:01, Major A wrote:
>> Hi Michal,
>>
>> Sorry I misunderstood your message, and I didn't spot the attached
>> files.? Now I booted with those two files, there's no output on the
>> UARTs whatsoever.? Is there anything else I can try?
>>
>> Cheers,
>>
>>  ? Andr?s
>>
>>
>> On 30/04/2020 12:33, Michal Simek wrote:
>>> Hi,
>>>
>>> On 30. 04. 20 12:19, Major A wrote:
>>>> Hi Michal,
>>>>
>>>>> can you please try these files in SD boot mode?
>>>>
>>>> Done, here are two logs, both in SD boot mode.
>>>>
>>>> First, log.sd is with SD card inserted (with the image files that
>>>> apparently refuse to work other than the early UART message).
>>>>
>>>> The other file, log.no-sd, is with no card inserted.
>>>
>>> we don't understand each other. I sent you boot.bin and image.itb. Just
>>> copy them to SD card, switch board to sd boot mode and power it up.
>>>
>>> Thanks,
>>> Michal
>>>
> 

Fwd: Re: ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Major A]

Hi Michal,

The link I sent discusses boards that are externally identical but still 
different, even though they are all labeled Rev1.1.  My understanding is 
that there are differences between boards other than the SODIMM issue 
(from Rev1.0 to Rev1.1).  Don't you have a reasonably new board (I guess 
anything with a 2019 build date should do to test the file that you sent 
me?  I'm pretty sure you only tested it on older boards (still Rev1.1, 
but older).

Cheers,

   Andr?s


On 05/05/2020 09:58, Michal Simek wrote:
> Hi,
> 
> yes there are new sodimms for sure that's why there is separate folder
> for this board revision.
> You can try to generate psu_init for 1.1 from vivado and then ddr
> configuration should be right.
> You can also use psu_init and run memory test on the top to see if ddr
> is configured properly.
> 
> Thanks,
> Michal
> 
> On 05. 05. 20 9:43, Major A wrote:
>> Hi Michal,
>>
>> I appreciate that, thanks for your help.? I mentioned this earlier but
>> never got a reply: can this have something to do with
>>
>>
>> https://forums.xilinx.com/t5/ACAP-and-SoC-Boot-and/Booting-ZCU-102-from-SD-Card/td-p/926649
>>
>>
>> by any chance?
>>
>> Cheers,
>>
>>  ? Andr?s
>>
>>
>> On 05/05/2020 08:14, Michal Simek wrote:
>>> On 04. 05. 20 16:41, Major A wrote:
>>>> Dear Michal,
>>>>
>>>> There's no output on the console whatsoever.? I tried booting off SD
>>>> directly, and also via JTAG and your script.
>>>
>>> I am out of ideas what can be wrong. It is just working on our revision
>>> 1.1. I can only recommend you to debug it step by step and see where you
>>> end and what can be wrong.
>>> I can imagine that your zcu102 can have older memory module but it is
>>> unlikely if it is new. Or something else is broken there.
>>>
>>> Just keep in your mind that SPL is not supported official recommend boot
>>> flow and it is community driven first stage bootloader.
>>> I can help with brainstorming but you need to debug it self to find out
>>> where the problem is.
>>>
>>> Thanks,
>>> Michal
>>>
>