Hi Ez-team and other, happy to join!
I am very happy with my Pluto since months, learning a lot. Yes it's a learning SDR tool, well documented.
I flashed several firmwares, and compiled my own running since few weeks. Very instructive, robust device, never had an issue.
Few days ago I released a version and user contact me over internet to report DFU flashing failing at around 22-23 MB.
I must admit my firmware is big (31MB) but tested with no issue on several Plutos.
Thanks to this patient guy, we finally rejected all problems regarding cables, OS windows vs linux, and dfu-util version 0.8 vs 0.9, because I finally was able to reproduce the issue on my side using a brand new unboxed pluto.
This pluto was running firmware 0.28, upgraded to 0.29 then to my own firmware.
So, depending on the pluto, flashing over 22MB is working (or not)... from the same computer.
Result after flashing a 26MB size firmware file (never fail at same point):
dfu-util -a firmware.dfu -D pluto.dfu dfu-util 0.8
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.Copyright 2010-2014 Tormod Volden and Stefan SchmidtThis program is Free Software and has ABSOLUTELY NO WARRANTYPlease report bugs to firstname.lastname@example.org
Match vendor ID from file: 0456Match product ID from file: b673Opening DFU capable USB device...ID 0456:b674Run-time device DFU version 0110Claiming USB DFU Interface...Setting Alternate Setting #1 ...Determining device status: state = dfuIDLE, status = 0dfuIDLE, continuingDFU mode device DFU version 0110Device returned transfer size 4096Copying data from PC to DFU deviceDownload [====================== ] 88% 23044096 bytes failed!state(10) = dfuERROR, status(14) = Something went wrong, but the device does not know what it was
After looking around fit_size parameter on NVRAM, obviously reflashing uboot.dfu ... lot of hours later I found this difference on the startup:
- Faulty unit: (failed at 23MB, then dowgraded to AD firmware).
Jan 1 00:00:02 (none) user.info kernel: m25p80 spi32765.0: SPI-NOR-UniqueID 104473222a870010ffff0c003eadd519eeJan 1 00:00:02 (none) user.info kernel: m25p80 spi32765.0: n25q256a (32768 Kbytes)Jan 1 00:00:02 (none) user.notice kernel: 4 ofpart partitions found on MTD device spi32765.0Jan 1 00:00:02 (none) user.notice kernel: Creating 4 MTD partitions on "spi32765.0":Jan 1 00:00:02 (none) user.notice kernel: 0x000000000000-0x000000100000 : "qspi-fsbl-uboot"Jan 1 00:00:02 (none) user.notice kernel: 0x000000100000-0x000000120000 : "qspi-uboot-env"Jan 1 00:00:02 (none) user.notice kernel: 0x000000120000-0x000000200000 : "qspi-nvmfs"Jan 1 00:00:02 (none) user.notice kernel: 0x000000200000-0x000002000000 : "qspi-linux"
- Working unit ( 31MB flashed)
Jan 1 00:00:04 (none) user.info kernel: m25p80 spi32765.0: SPI-NOR-UniqueID 104400b8399100151500080041ef64d7bcJan 1 00:00:04 (none) user.warn kernel: m25p80 spi32765.0: found n25q512a, expected n25q256aJan 1 00:00:04 (none) user.info kernel: m25p80 spi32765.0: n25q512a (65536 Kbytes)Jan 1 00:00:04 (none) user.notice kernel: 4 ofpart partitions found on MTD device spi32765.0Jan 1 00:00:04 (none) user.notice kernel: Creating 4 MTD partitions on "spi32765.0":Jan 1 00:00:04 (none) user.notice kernel: 0x000000000000-0x000000100000 : "qspi-fsbl-uboot"Jan 1 00:00:04 (none) user.notice kernel: 0x000000100000-0x000000120000 : "qspi-uboot-env"Jan 1 00:00:04 (none) user.notice kernel: 0x000000120000-0x000000200000 : "qspi-nvmfs"Jan 1 00:00:04 (none) user.notice kernel: 0x000000200000-0x000002000000 : "qspi-linux"
Seems the flash model and block-size are not the same, this is confirmed from diagnostic reports coming from 2 plutos. All these boards are revB (working and not working over 22MB).
Discussing with a third guy who owns two pluto , he realized the second pluto can be flashed over 22MB ...thinking until now it was the maximum limit.
Could this explain the flashing failure.? Any workaround for this issue ? Did I miss an important patch or a message here ? (Vivado 2017.4 here)
Joining the bad and good diagnostics reports.
BTW I'm not used to play on uboot, and don't have JTAG cable ;)
Ask if you need more information. Thanks a lot !
To make a long story short. Some people may have noticed - after we initially shipped the first 1000 units, we were out of stock for a very long time. The issue was that the SPI NOR flashes were on global shortage with insane lead times.
So we decided to build a batch with 64MBytes instead of 32MByte. In addition these flashes were even automotive grade and super expensive.
You can determine which type you have by reading the iio context attributes.
Library version: 0.16 (git tag: v0.16)
Compiled with backends: local xml ip usb serial
IIO context created with local backend.
Backend version: 0.16 (git tag: v0.16)
Backend description string: Linux pluto 4.14.0-41914-g0272a4d #275 SMP PREEMPT Wed Dec 19 17:06:14 CET 2018 armv7l
IIO context has 7 attributes:
hw_model: Analog Devices PlutoSDR Rev.B (Z7010-AD9363)
The ones with 64M read
while the ones with 32M read
So bottom line - PlutoSDR has 32M, that's whats in the spec - you must not assume 64M.
Thank you for this quick and detailed answer.
mhennerich said:So bottom line - PlutoSDR has 32M, that's whats in the spec - you must not assume 64M.
I fully understand and was not even thinking about 64MB.. just focusing on the number 32 :)
I more concerned by the fact I never had problem to flash firmwares up to 31MB until now, as expected and according to the data specs.
However, I'm just discovering I'm stuck at 23MB firmware-size on some devices ... and this one was recently purchased. That's why I'm surprised.
So you mean the first 1000 revB boards are not able to support firmwares over than 23MB ?
BtW thanks for the nice PDF available .
The first 2 MBytes are reserved for uboot, env and nvmfs
but the remaining 30M should be available for firmware.
I need to see If I can replicate the issue on my side.
Thank you for the interest in my question Michael.
You can reproduce it with every DFU file over 23 MB , not only my firmware.
Ok for the first 2 Mbytes, no problem. I'm always counting nvram+uboot, kernel, and filesystem as three separate things to calculate my next firmware size.
Looking forward to your answer, take your time, now we have a first explanation to this flashing issue Thanks.
I know what’s going on. We bottom protect the 1Mbyte of SPI NOR flash to protect the initial u-boot. However u-boot doesn’t handle bottom protect and ST NOR flashes with more than 3 block protection bits. The SPI flashes we use have 4 BPs, and in addition we must bottom protect for ZYNQ SPI boot.
What happens now is that the spi_flash mtd driver in u-boot thinks the top ¼ of the flash is locked, and thus aborts any mtd write by DFU which covers this area.
The Linux mass storage drive updates should not be affected by this, since we explicitly disabled NOR lock and unlocking for the flash devices used on Pluto.
So the recommendation for briked Pluto’s is to use DFU update only with the official firmware.
Once Linux is recovered use the mass storage drive update feature for custom and potentially larger firmware blobs.
There is a trick in the danger zone that I don’t want to keep back:
If you unlock the SPI flash, the issue described above won’t apply and you can use DFU to the entire size.
Please be aware that unlocking is potentially dangerous since you could also overwrite your initial u-boot used for device recovery!
If you accidentally delete it, you need a JTAG cable and tools to recover the Pluto.
If you have access to the UART console on P1, you can interrupt the boot by holding down CTRL-C during reset.
Then type following commands to un-protect the SPI flash:
Pluto> sf probe && sf protect unlock 0 100000
If you don’t have UART access, you can overwrite some u-boot environmental variables from Linux using fw_setenv command.
In the blow example we append the unlock command to the dfu_ram command which is executed in case you issue a device_reboot ram command from Linux.
# fw_setenv dfu_ram 'sf probe && sf protect unlock 0 100000;echo Entering DFU RAM mode ... && run dfu_ram_info && dfu 0 ram 0'
# device_reboot ram
After that you power cycle the unit and it is unlocked.