search

maia-sdr / plutosdr-fw

Maia SDR ADALM Pluto Firmware
https://maia-sdr.org
Other
25 stars 5 forks source link

Flashing large firmware images fails #3

Closed r4d10n closed 1 year ago

r4d10n commented 1 year ago

Congrats on the release Dani... Maia SDR is working wonderful... Looking forward to more features!

I tried to reinstall ADI Pluto firmware after trying Maia SDR, without luck by copying the pluto.frm to Mass Storage Disk (and ejecting), and also with update_frm.sh. I tried this on two of my revB Plutos.

Only method that worked was DFU, while making sure uboot-env.dfu was also dfu'ed to reinit the custom changes made with fw_setenv.

Cheers

daniestevez commented 1 year ago

Transferring the issue to the plutosdr-fw repository...

daniestevez commented 1 year ago

I have just checked that I can flash the ADI firmware v0.35 using the mass storage method on a Pluto rev. B that is running the Maia SDR v0.1.1 firmware.

Can you give more details about the problem? Does the LED flash rapidly after you eject the the mass storage device? After you attempt to flash the ADI firmware, does the Pluto boot to Linux correctly? What does the motd indicate when you log in by serial or ssh (you can also cat /etc/motd)?

r4d10n commented 1 year ago

I am using a custom build of ADI firmware (~26MB vs ~11MB (stock v0.35) vs 13MB (maia)), which is probably causing the problem. I tried using the stock v0.35 as you suggested and it is working fine.

I am able to install this custom build by copying the pluto.frm to a stock v0.35 installed Pluto, but not to a maia-sdr installed Pluto. The custom build fw is uploaded here for your reference.

LEDs do not flash when I copy the custom fw and eject the mass storage device, which means it is not loading the custom firmware copied to the device. When I reconnect, it shows motd for maia-sdr.

daniestevez commented 1 year ago

I think that the problem is that your custom firmware is too large. The Maia SDR firmware only leaves around 39.2MiB of free RAM, since most of the RAM is reserved for IQ recordings.

It seems that the update firmware procedure needs at least twice the firmware size of free RAM, since /sbin/update_frm.sh does

head -c -33 ${FILE} > /opt/firmware.frm

and both /opt/firmware.frm and the original firmware file sit in a RAM filesystem. This explains why attempting to flash a 26MB image won't work.

In principle it would be possible to rework /sbin/update_frm.sh so that it works in-place, without duplicating the firmware file in RAM.

Note that killing the maia-httpd process and removing everything in the /root directory (which contains the maia-httpd binary and its assets) will increase the amount of free RAM to 44.7MiB (I'm reading these values from the "available" column of free), but still this doesn't seem sufficient to flash a 26MB image (I didn't test it).