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

Major A andras.g.major at gmail.com
Tue Apr 28 12:53:37 CEST 2020


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
> 


More information about the U-Boot mailing list