Recent Posts

Pages: 1 ... 8 9 [10]
91
UltraScale / TE0820: QSPI write access under Linux
« Last post by uli on January 05, 2023, 10:02:04 AM »
Hi,

I'm trying to access the QSPI flash on my TE0820 under Linux. It's marked RW193, so it should be a Micron MT25QU512ABB8E12-0SIT.
However, the Linux kernel (Xilinix 5.10) does not recognize it:
...
[    2.608219] spi-nor spi0.0: unrecognized JEDEC id bytes: 10 5d 90 08 22 00
[    2.608244] spi-nor: probe of spi0.0 failed with error -2
...
According to https://wiki.trenz-electronic.de/display/PD/PCN-20190110a+TE0820-03-*+SPI+Flash+and+eMMC+Change
there was a BOM change:
#1 Change SPI Flash from N25Q512A11G1240E to MT25QU512ABB8E12-0SIT

Type: BOM change

Reason: N25Q512A11G1240E became obsolete.

Impact:  None. Both have same JEDEC ID BB20h and manufacturer ID 20h.

So, I'm puzzled why I'm getting a totally different JEDEC ID. Is that a known problem?
When copying the chip definition for BB20h in the kernel to the ID above the kernel can probe the QSPI chip:
...
[    2.605194] spi-nor spi0.0: trying to lock already unlocked area
[    2.605200] spi-nor spi0.0: mt25qu512b (131072 Kbytes)
...
And /dev/mtd0 is available:
root@zynqmp-zu2cg-1i:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 08000000 00020000 "spi0.0"

But erasing it with ubiformat fails with:
root@zynqmp-zu2cg-1i:~# ubiformat /dev/mtd0
ubiformat: mtd0 (nor), size 134217728 bytes (128.0 MiB), 1024 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 1 bytes
libscan: scanning eraseblock 0 --  0 % complete  libmtd: error!: cannot read 64 bytes from mtd0 (eraseblock 0, offset 0)
        error 110 (Connection timed out)
ubiformat: error!: failed to scan mtd0 (/dev/mtd0)

I can't understand why the JEDEC ID is so completely different, nor why the erase fails. Anybody got a clue?

Thanks in advance,
Uli
92
Hi,

you should see and activate this AXI interface if you doubleclick on the ZYNQ7 PS IP under PS-PL Configuration -> AXI Non Secure Enablement -> GP Master AXI Interface -> M AXI GP0 Interface.

I recommend you to use our latest reference design 2021.2 and add your own application/IPs there -> https://wiki.trenz-electronic.de/display/PD/TE0715+Test+Board

Download here: https://shop.trenz-electronic.de/de/Download/?path=Trenz_Electronic/Modules_and_Module_Carriers/4x5/TE0715/Reference_Design/2021.2/test_board

good luck!

93
Hi,

I am using trenz TE0701-06 carrier board with TE0715-04 SOM. My board part number in Vivado is XC7Z030sbg485-1. When I place ZYNQ PS in block design I do not get the following signals/pins on ZYNQ IP Block:

1)  M_AXI_GP0
2)  M_AXI_GP0_ACLK

I also checked on PS-PL configuration and could not even find GP Master AXI Interface settings. Why My ZYNQ is not GP MASTER AXI block?
94
Trenz Electronic FPGA Modules / Re: TE0720 I2C interface
« Last post by JH on January 05, 2023, 06:54:33 AM »
Hi,
I've add a PDF export to the attachment.
br
John
95
Trenz Electronic FPGA Modules / Re: TE0720 I2C interface
« Last post by bigguiness on January 05, 2023, 12:31:59 AM »
BTW, is there a PDF (or cleaner, printable) version of the TE0720 CPLD information?

Thanks
96
Trenz Electronic FPGA Modules / Re: TE0720 I2C interface
« Last post by bigguiness on January 05, 2023, 12:12:32 AM »
Update...

Address 7E is the "SYNC Address" for the LTC1669.

It appears the PCA9685 responds to address 00 writes. This causes a Software Reset of the device.

Address 70 appears to also be associated with the PCA9685. It's a "LED All Call" address used to program all PCA9685 devices on the bus at the same time.

Looks like all the devices on my carrier board are working, at least from U-Boot.

Hartley
97
Trenz Electronic FPGA Modules / Re: TE0720 I2C interface
« Last post by bigguiness on January 04, 2023, 11:54:32 PM »
Hi John,

Still have not figured out how to get I2C bus 0 to work in Linux. But I have been able to scan the two busses in U-Boot (I added the <- comments to identify the known devices):

Code: [Select]
Zynq> i2c bus
Bus 0:  i2c@e0004000
Bus 1:  i2c@e0005000
Zynq> i2c dev 0
Setting bus to 0
Zynq> i2c probe
Valid chip addresses: 00 20 48 49 51 70 71 7E
Zynq> i2c dev 1
Setting bus to 1
Zynq> i2c probe
Valid chip addresses: 20 21 57 6F
Zynq> i2c bus
Bus 0:  i2c@e0004000  (active 0)
   00: generic_0, offset len 1, flags 0     <- ? (this address should be reserved I think)
   20: generic_20, offset len 1, flags 0    <- LTC1669 DAC
   48: generic_48, offset len 1, flags 0    <- LM75 Temperature Sensor
   49: generic_49, offset len 1, flags 0    <- LM75 Temperature Sensor
   51: generic_51, offset len 1, flags 0    <- 512Kb EEPROM
   70: generic_70, offset len 1, flags 0    <- ? (no device on my carrier at this address, possible problem with the PCA9685 address lines?)
   71: generic_71, offset len 1, flags 0    <- PCA9685 PWM
   7e: generic_7e, offset len 1, flags 0    <- ? (no device on my carrier at this address, possible problem with the PCA9685 address lines?)
Bus 1:  i2c@e0005000  (active 1)
   20: generic_20, offset len 1, flags 0    <- CPLD - I2C to GPIO block
   21: generic_21, offset len 1, flags 0    <- ? (is this part of the slave inside the CPLD?)
   57: generic_57, offset len 1, flags 0    <- ISL12020 RTC
   6f: generic_6f, offset len 1, flags 0    <- ISL12020 Battery Backed Registers

Do the Bus 1 devices look correct?

Do you have any comments on the "?" devices on both busses?

Thanks,
Hartley
98
Trenz Electronic FPGA Modules / Re: TE0720 I2C interface
« Last post by JH on January 04, 2023, 07:39:22 AM »
Hi,
I2C0 controller (MIO10/11) goes direct to B2B connector, so it' something on your carrier what you see there.
I2C1 controller goes over PL to CPLD.
You should see normally RTC there as UU(it's a little bit strange that you did see it with I2C detect but it was detected by drivers...UU means address is used by drivers...not more) and I2C slave inside the CPLD, see:
https://wiki.trenz-electronic.de/display/PD/TE0720+CPLD#TE0720CPLD-I2CtoGPIOblock

can you try out this command options one time:
i2cdetect -y -r 0 
i2cdetect -y -r 1
You should see full matrix in this case.
br
John

br
John
99
Trenz Electronic FPGA Modules / Re: TE0720 custom carrier no JTAG access
« Last post by JH on January 04, 2023, 07:01:11 AM »
Hi,
good to hear that it works now.

Quote
Unknown_Device_0
this is normally the Lattice CPLD, in this case  JTAGMODE was wrong.

br
John
100
Trenz Electronic FPGA Modules / Re: TE0720 custom carrier no JTAG access
« Last post by bigguiness on January 04, 2023, 12:07:10 AM »
I finally got the JTAG to work, but I'm not sure how....

Oh well...
Pages: 1 ... 8 9 [10]