Description
This month I received a ZynqSDR/LibreSDR from aliexpress seller "HamGeek Store". It came with some minor differences from the zynqsdr_rev5.pdf that I found here (this was helpful, thanks!!).
Actually the only real difference I can see is that the AD7291 ADC for voltage monitoring is not populated, plus some related silkscreen changes:
- the pad for the ADC is marked "U28" on my silkscreen vs. "U29" in the PDF
- my +1.8V regulator is marked "U20" instead of "U28"
- my +3.3V regulator is marked "U29" instead of "U20"
This seems to close the circle..
I built the firmware from this repo, put it on an SD card, and this works. Now I'm trying to solve the various problems, and I'm not sure where to put my findings. Let me start with the QSPI flash.
The W25Q256JV seems like a wrong choice: it is not officially supported by AMD/Xilinx and Vivado cannot program it over JTAG.
With this repo the device tree for U-Boot has a compatible statement for the n25q256a type of SPI memory; also micron,m25p80 is listed, not sure how it works. But I guess other LibreSDRs are shipped with non-Winbond SPI flash?
When U-Boot is flashed to the QSPI with this device tree (as part of boot.dfu or boot.frm), U-Boot will fail to load (no output on /dev/ttyUSB2). When the compatible statement of the qspi node in 'u-boot-xlnx/arch/arm/dts/zynq-libre-sdr.dts' is changed to w25q256 (see here), U-Boot works.
But now when I also flash the libre.frm, it is dead again. I think this is because it writes above the first 16 MiB of the chip, where 3 byte addressing is no longer enough and 4 bytes per address are needed. This mode is not supported by the Zynq-7000 SPI controller, so the SPI memory has to be put into a 3 byte addressing mode where the controller writes the 4th address byte into a dedicated "Extended Address Register". Some context here. The Linux kernel driver (spi-nor) handles this, but it runs into a problem (from dmesg):
spi-nor spi1.0: found w25q256, expected n25q256a
spi-nor spi1.0: failed to read ear reg
spi-nor spi1.0: w25q256 (32768 Kbytes)
It can be used, but I suspect that the 3 byte addressing with the EAR is broken here, and when Linux writes to addresses >16MiB, it actually starts at 0 again, overwriting the boot code.
I should do a full write and readback to confirm this, or do a low-level analysis with SPI transactions, but I'm okay with just using the SD card instead.. maybe someone else will run into this and won't waste too much time.
speculation:
- is this a counterfeit W25Q256JV that doesn't care to implement 3-byte addressing?
- did all other designers avoid SPI flash that is not supported by Vivado, so this is some incompatibility that noone ever ran into or bothered to fix?
Activity