- Welcome to Trenz Electronic GmbH Support Forum.
Recent posts
#71
UltraScale / Re: TE0820 POR with JTAG TE079...
Last post by pema - November 24, 2023, 10:16:43 AMHi John,
yes I realize that you cant know what AMD over the xsct/xsdb sends.
Can you please tell me what is the purpose from the "Button (Reset_n)" on the JTAG TE0790 2x6 Pin Header ? Input? output?
Thanks.
yes I realize that you cant know what AMD over the xsct/xsdb sends.
Can you please tell me what is the purpose from the "Button (Reset_n)" on the JTAG TE0790 2x6 Pin Header ? Input? output?
Thanks.
#72
UltraScale / Re: TE0820 POR with JTAG TE079...
Last post by JH - November 23, 2023, 01:47:51 PMHi,
I can't tell you what AMD transmits and how, only AMD knows that.
Instead of HW Reset U+ Zynq has mechanism to reboot via JTAG, I think that's what AMD try when they say reboot.
But there are different depths of reboot possible, not all of them reset all registers and re-evaluate the boot mode again, so this does not always work
You can check if you find some mechanism from TRM:
https://docs.xilinx.com/r/en-US/ug1085-zynq-ultrascale-trm
And U+ Zynq register description:
https://docs.xilinx.com/r/en-US/ug1087-zynq-ultrascale-registers
or you create you custom carrier with microcontroller, which can force reset.
br
John
Quotethat's not possible or much effort. xsct/sdb use JTAG for communication. JTAG is only one channel from FTDI(translate USB to JTAG) which is routed through the CPLD. CPLD is only Levelshifter with the advance that you can change Pinout from the 2,54mm pinheader if needed.
The signal from connector J2 pin G already gives this signal right ?. How is the signal activated from the xsct/xsdb?
I can't tell you what AMD transmits and how, only AMD knows that.
Instead of HW Reset U+ Zynq has mechanism to reboot via JTAG, I think that's what AMD try when they say reboot.
But there are different depths of reboot possible, not all of them reset all registers and re-evaluate the boot mode again, so this does not always work
You can check if you find some mechanism from TRM:
https://docs.xilinx.com/r/en-US/ug1085-zynq-ultrascale-trm
And U+ Zynq register description:
https://docs.xilinx.com/r/en-US/ug1087-zynq-ultrascale-registers
or you create you custom carrier with microcontroller, which can force reset.
br
John
#73
UltraScale / Re: TE0820 POR with JTAG TE079...
Last post by pema - November 23, 2023, 01:04:08 PMHi John,
many thanks for your reply. Yes I have a TE706 carrier.
I will have to solder a wire RST to J2 pin G in the JTAG adapter.
The signal from connector J2 pin G already gives this signal right ?. How is the signal activated from the xsct/xsdb?
Many thanks
Have a nice weekend.
many thanks for your reply. Yes I have a TE706 carrier.
I will have to solder a wire RST to J2 pin G in the JTAG adapter.
The signal from connector J2 pin G already gives this signal right ?. How is the signal activated from the xsct/xsdb?
Many thanks
Have a nice weekend.
#74
UltraScale / Re: TE0820 POR with JTAG TE079...
Last post by JH - November 23, 2023, 12:25:21 PMHi,
CPLD Code is available on the download area, here is a link to update instructions and download:
https://wiki.trenz-electronic.de/display/PD/TE0790+CPLD+Firmware
Links to other TE0790 documentation an downloads:
https://wiki.trenz-electronic.de/display/PD/TE0790+Resources
If you get access from TE0790 programmer to the module depends on the carrier.
Which carrier did you use?
TE0706?
br
John
CPLD Code is available on the download area, here is a link to update instructions and download:
https://wiki.trenz-electronic.de/display/PD/TE0790+CPLD+Firmware
Links to other TE0790 documentation an downloads:
https://wiki.trenz-electronic.de/display/PD/TE0790+Resources
If you get access from TE0790 programmer to the module depends on the carrier.
Which carrier did you use?
TE0706?
br
John
#75
Trenz Electronic FPGA Modules / Re: Slow QSPI on TE0720: "Warn...
Last post by M Kirberg - November 23, 2023, 11:52:05 AMOk...
One thing: please never mix Vivado and Petalinux versions. Though it might work this leads to problems.
Apart from that: We have no experience with the 20XX.1 versions, we only have designs for 20XX.2.
Can you try our reference design for the TE0720?
One thing: please never mix Vivado and Petalinux versions. Though it might work this leads to problems.
Apart from that: We have no experience with the 20XX.1 versions, we only have designs for 20XX.2.
Can you try our reference design for the TE0720?
#76
Trenz Electronic FPGA Modules / Re: Slow QSPI on TE0720: "Warn...
Last post by AaronB - November 23, 2023, 04:57:07 AMVivado 2018.1 and Petalinux 2019.1
#77
Trenz Electronic FPGA Modules / Re: Slow QSPI on TE0720: "Warn...
Last post by M Kirberg - November 22, 2023, 04:04:04 PMHi,
that is strange, what versions of tools are you on?
br
that is strange, what versions of tools are you on?
br
#78
Trenz Electronic FPGA Modules / Re: TE0890 - Power Consumption...
Last post by gathertearful - November 22, 2023, 10:56:41 AMI also have the same problem. I found the answer the best until I read your article. I tried pulling the CS0 signal high to turn off the IC and it worked fine. Thank.
#79
Trenz Electronic FPGA Modules / Slow QSPI on TE0720: "Warning:...
Last post by AaronB - November 21, 2023, 06:43:58 PMAny tips on getting the QSPI boot to use the correct clock frequency when booting petalinux from QSPI?
I'm using a TE0720, the boot code shows "SoM: TE0720-00-0C F SC REV:00"
Its installed on a custom board, and I'm trying to boot petalinux from QSPI.
eMMC boot is fast, but I can't do that because the system won't boot if there is no Micro SD card in the slot, due to the "voltage select" issue. Having a placeholder micro SD card in the slot at all times is not an option for my use case. I have had success with removing the external SD card from my hardware configuration, but I'm trying to avoid that if possible.
So now I'm trying QSPI booting, but it seems really slow.
During boot, there is a warning about clock speed limited to 100kHz, followed by a long pause while the flash is read. It takes 4 seconds to load a 12MB image.ub file, which is slower than my requirements will allow.
At the uboot command prompt, I can manually force a 50 MHz clock speed, and it loads in 2 seconds, which is better.
However, I'd like to know if there is something I can do to ensure faster QSPI clock speeds.
The Vivado config for the QSPI speeds is attached, and the device tree snippet that was automatically generated is shown below. Note that it shows a max clock speed of 50Mhz (0x2faf080).
If I manually stop at the uboot prompt and measure things, I can MANUALLY configure the subsystem with a 50 Mhz clock. How can I get this by default?
Here are some example uboot logs.
First, the default one I get by allowing the boot to continue on its own. the read takes 4 seconds:
Next, one where I manually specify the speed option to 50Mhz, and it takes 2 seconds:
Finally, one where I manually set the speed to 100Khz as a comparison, and the read takes 4 seconds as we might expect:
For the moment I will try manually overriding the u-boot variable that loads the kernel into memory and does an "sf probe 0". If I change this to "sf probe 0 50000000", this may accomplish my goal, but I'm confused as to what might be going wrong in my configuration that requires this.
I'm using a TE0720, the boot code shows "SoM: TE0720-00-0C F SC REV:00"
Its installed on a custom board, and I'm trying to boot petalinux from QSPI.
eMMC boot is fast, but I can't do that because the system won't boot if there is no Micro SD card in the slot, due to the "voltage select" issue. Having a placeholder micro SD card in the slot at all times is not an option for my use case. I have had success with removing the external SD card from my hardware configuration, but I'm trying to avoid that if possible.
So now I'm trying QSPI booting, but it seems really slow.
During boot, there is a warning about clock speed limited to 100kHz, followed by a long pause while the flash is read. It takes 4 seconds to load a 12MB image.ub file, which is slower than my requirements will allow.
At the uboot command prompt, I can manually force a 50 MHz clock speed, and it loads in 2 seconds, which is better.
However, I'd like to know if there is something I can do to ensure faster QSPI clock speeds.
The Vivado config for the QSPI speeds is attached, and the device tree snippet that was automatically generated is shown below. Note that it shows a max clock speed of 50Mhz (0x2faf080).
Code Select
spi@e000d000 {
clock-names = "ref_clk", "pclk";
clocks = <0x1 0xa 0x1 0x2b>;
compatible = "xlnx,zynq-qspi-1.0";
status = "okay";
interrupt-parent = <0x4>;
interrupts = <0x0 0x13 0x4>;
reg = <0xe000d000 0x1000>;
#address-cells = <0x1>;
#size-cells = <0x0>;
is-dual = <0x0>;
num-cs = <0x1>;
spi-rx-bus-width = <0x4>;
spi-tx-bus-width = <0x4>;
flash@0 {
compatible = "jedec,spi-nor";
reg = <0x0>;
#address-cells = <0x1>;
#size-cells = <0x1>;
spi-max-frequency = <0x2faf080>;
partition@0x00000000 {
label = "boot";
reg = <0x0 0x500000>;
};
partition@0x00500000 {
label = "bootenv";
reg = <0x500000 0x20000>;
};
partition@0x00520000 {
label = "kernel";
reg = <0x520000 0xc10000>;
};
partition@0x01130000 {
label = "data";
reg = <0x1130000 0xed0000>;
};
};
};
If I manually stop at the uboot prompt and measure things, I can MANUALLY configure the subsystem with a 50 Mhz clock. How can I get this by default?
Here are some example uboot logs.
First, the default one I get by allowing the boot to continue on its own. the read takes 4 seconds:
Code Select
[2023-11-21 11:32:17.373] Hit any key to stop autoboot: 0
[2023-11-21 11:32:17.376] Warning: SPI speed fallback to 100 kHz
[2023-11-21 11:32:17.380] SF: Detected n25q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB
[2023-11-21 11:32:17.387] device 0 offset 0x520000, size 0xc10000
[2023-11-21 11:32:21.448] SF: 12648448 bytes @ 0x520000 Read: OK
Next, one where I manually specify the speed option to 50Mhz, and it takes 2 seconds:
Code Select
[2023-11-21 11:37:46.725] Zynq> sf probe 0 50000000
[2023-11-21 11:37:54.960] SF: Detected n25q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB
[2023-11-21 11:37:54.968] Zynq> boot
[2023-11-21 11:38:01.401] SF: Detected n25q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB
[2023-11-21 11:38:01.407] device 0 offset 0x520000, size 0xc10000
[2023-11-21 11:38:03.446] SF: 12648448 bytes @ 0x520000 Read: OK
Finally, one where I manually set the speed to 100Khz as a comparison, and the read takes 4 seconds as we might expect:
Code Select
[2023-11-21 11:39:10.933] Zynq> sf probe 100000
[2023-11-21 11:39:21.905] SF: Detected n25q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB
[2023-11-21 11:39:21.912] Zynq> boot
[2023-11-21 11:39:25.408] SF: Detected n25q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB
[2023-11-21 11:39:25.415] device 0 offset 0x520000, size 0xc10000
[2023-11-21 11:39:29.477] SF: 12648448 bytes @ 0x520000 Read: OK
For the moment I will try manually overriding the u-boot variable that loads the kernel into memory and does an "sf probe 0". If I change this to "sf probe 0 50000000", this may accomplish my goal, but I'm confused as to what might be going wrong in my configuration that requires this.
#80
Trenz Electronic FPGA Modules / Re: TE0705 USB over-current si...
Last post by mgillott - November 21, 2023, 02:44:25 PMFound the source for the CPLD !
The USB_OC signal and a few other signals are read by an I2C interface configured on MIO10 and MIO11 of the connected module.
So I imagine these signals are actually not used unless a suitable driver is created for these GPIOs ?
Malc
The USB_OC signal and a few other signals are read by an I2C interface configured on MIO10 and MIO11 of the connected module.
So I imagine these signals are actually not used unless a suitable driver is created for these GPIOs ?
Malc