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


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: 0xffdc - 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 0x (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 "/lib/time.c": no such file or 
directory

xsdb% bpremove 0
xsdb% dow -data u-boot.itb 0x1000
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/Ar1:  N/A
  r2:  N/Ar3:  N/A
  r4:  N/Ar5:  N/A
  r6:  N/Ar7:  N/A
  r8:  N/Ar9:  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/Asp:  N/A
  pc: fffc78e4  cpsr:  N/A
 vfp sys
 dbgacpu_gic
xsdb% bt
xsdb%

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

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 0xfffc
> 100%    0MB   0.2MB/s  00:00
> Successfully downloaded /spl/u-boot-spl-dtb.bin
> xsdb% memmap -file spl/u-boot-spl
> xsdb% rwr pc 0xfffc
> xsdb% bpadd -addr 
> 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 "/lib/time.c": no such file or directory
> xsdb% bpremove 0
> xsdb% dow -data u-boot.itb 0x1000
> 100%    1MB   0.2MB/s  00:08
> Successfully downloaded /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

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


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 0xfffc
100%0MB   0.2MB/s  00:00
Successfully downloaded /spl/u-boot-spl-dtb.bin
xsdb% memmap -file spl/u-boot-spl
xsdb% rwr pc 0xfffc
xsdb% bpadd -addr 
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 "/lib/time.c": no such file or directory
xsdb% bpremove 0
xsdb% dow -data u-boot.itb 0x1000
100%1MB   0.2MB/s  00:08
Successfully downloaded /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

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

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

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


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

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

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

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


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 0x 0x1400
+mask_write 0xFD1A0104 0x501 0x0
+
+after 1000
+
+
+targets -set -filter {name =~ "Cortex-A53 #0"}
+stop
+dow -data u-boot-spl-dtb.bin  0xfffc
+memmap -file u-boot-spl
+rwr pc 0xfffc
+bpadd -addr 
+
+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 0x1000

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

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

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 0x 0x1400
+mask_write 0xFD1A0104 0x501 0x0
+
+after 1000
+
+
+targets -set -filter {name =~ "Cortex-A53 #0"}
+stop
+dow -data u-boot-spl-dtb.bin  0xfffc
+memmap -file u-boot-spl
+rwr pc 0xfffc
+bpadd -addr 
+
+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 0x1000

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

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


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

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

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

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

2020-04-27 Thread 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
'/:/,/^$/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
'/:/,/^$/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

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

2020-04-24 Thread 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
'/:/,/^$/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
'/:/,/^$/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

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

2020-04-23 Thread 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

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

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

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


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

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

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

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


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

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

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

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


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

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

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

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


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

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

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 0x 0x1400
mask_write 0xFD1A0104 0x501 0x0

after 1000


targets -set -filter {name =~ "Cortex-A53 #0"}
stop
dow -data u-boot-spl-dtb.bin  0xfffc
memmap -file u-boot-spl
rwr pc 0xfffc
bpadd -addr 

if { [catch {con -block -timeout 3000} msg] } {
puts "err: $msg"
exit
# do something to handle the error
}

bpremove 0

dow -data u-boot.itb 0x1000
con

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


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

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