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
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,
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
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
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.
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
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
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
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
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
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%
>
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
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
>>>
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
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
>
>
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
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
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,
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:
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
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
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
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
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
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
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
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
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
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
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.
30 matches
Mail list logo
