Hello,
we have migrated our design to 2019.1. We managed to mitigate several issues, e.g. reading MAC address from EEPROM etc., but now a few issues remain, including:
- System ILA is not working. Vivado 2019.1 bitstream seems to be ok though, as it works with Petalinux 2018.2 generated FSBL, U-Boot and Linux. Colleagues report that this issue existed in 2018.3, too.
- QSPI nor-flash MTD block device access does work unreliable, writing and reading back fails. However, U-Boot and FSBL have no issues to load the boot images from QSPI.
Does anyone already have experience with migrating TE820 to 2019.1?
Will Trenz provide a reference design?
Thank you very much in advance,
Timor
Hello,
QuoteSystem ILA is not working.
What does not work? Did you change this kernel settings:
- https://wiki.trenz-electronic.de/display/PD/TE0820+Test+Board#TE0820TestBoard-Kernel
--> has only effect if you use linux, in case of barmetal it's no matter
Quote. reading MAC address from EEPROM
check xilinx has moved EEPROM MAC access from platform-top.h to uboot config (petalinux-config -c u-boot)
QuoteQSPI nor-flash MTD block device access does work unreliable, writing and reading back fails
Did you use the same device tree entry like on your 18.3 design?
Quote
Does anyone already have experience with migrating TE820 to 2019.1?
Can't say at the moment if I generate 19.1 design or if I publish next time 19.2. I will decide when I start with to test 19.1
br
John
Thank you very much for your reply, John.
The CPU Idle settings might be a good idea to investigate. Currently we have all these settings enabled - we will try this out.
MAC adress from EEPROM is done, and essentially this is the only change to the device tree. The other change is a clock renaming for a custom IP. Both device tree changes should not have any impact on the QSPI.
Please note that we migrated from 2018.2.
One more question, the Petalinux generated device tree (system-conf.dtsi) has this entry for our QSPI + NOR flash:
&qspi {
#address-cells = <1>;
#size-cells = <0>;
flash0: flash@0 {
compatible = "n25q512a","micron,m25p80";
spi-tx-bus-width=<1>;
spi-rx-bus-width=<4>;
reg = <0x0>;
#address-cells = <1>;
#size-cells = <1>;
spi-max-frequency = <108000000>;
partition@0x00000000 {
...
which looks correct to me. However, I have no idea, where the "compatible" and "spi-max-frequency" settings come from. They appear to be correct, but where would be the right place to modify these settings? I wasn't able to find any reference, anywhere. Also, I noticed you are using the "jedec-spi-nor" compatible string. Is that the preferred way?
Thanks again,
Timor
Hi,
QuoteMAC adress from EEPROM is done, and essentially this is the only change to the device tree.
sorry I didn't read carfully your last post, I thought you mean it was EEPROM MAC was not working...
Quote"jedec-spi-nor" compatible string
is more general, we have different assembly options with sometimes different size and flash manufacturer, so we can use one linux for all variants of a module series (we generate linux only for different DDR size). Linux detect correct flash normaly over ID, see boot log.
QuotePlease note that we migrated from 2018.2.
Some note only: For the Vivado Project, this works in the most cases, if Xilinx did not changed to much on the IPs and if the older Vivado version is not so far away. But for FSBL, PMU... should create with the source code of the new installation and for petalinux you should always create a new petalinux project and inserted all changes again. And you should never mix binaries from different Vivado/SDK/Petalinux versions.
br
John
Thanks again, John. This info is really helpful.
Although we tried the Petalinux migration script to update the Petalinux project to 2019.1, I also created a fresh 2019.1 project and compared the configuration. Our project is extremely similar to the default one, every difference can be explained and looks good.
Even with a fresh Petalinux project, the generated device tree contains the QSPI n25q512a at 108 MHz. I agree that Linux does probe the type of the flash, but how about the max frequency?
Thanks,
Timor
Hi,
max speed depends on PS setup and used QSPI flash(see datasheet). We use normaly default setup, but as I know for higher speed, it's important, that the feedback CLK Pin of the QSPI Interface is enabled in the PS-IP.
br
John
Hi John,
I know about the feedback pin and we have properly configured it. Still, the QSPI does not achieve 108 MHz (which is the max speed mentioned in the datasheet) in linux. When manually set to half clock frequency (54 MHz) it works perfectly. In FSBL and u-boot, QSPI works at 108 MHz clock rate.
There are quite a few changes to the kernel QSPI drivers in 2019.1:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841901/Linux+ZynqMP+GQSPI+Driver
Most of them are related to clock speed and tap delay settings. Probably something is not right there - but for now 54 MHz is good enough for us so I stop investigating the issue.
thanks for the feedback.
So if it works on fsbl and Uboot, maybe check what's set in the device tree or modify device tree by yourself, see also
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841754/Zynqmp+QSPI+Driver
https://github.com/Xilinx/linux-xlnx/blob/master/Documentation/devicetree/bindings/spi/spi-zynqmp-qspi.txt
br
John