search

maia-sdr / plutosdr-fw

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

Pluto plus build? #4

Closed LunaWuna closed 1 year ago

LunaWuna commented 1 year ago

is it possible to build a special build just for the pluto plus. here are the firmware changes it uses: https://github.com/plutoplus/plutoplus

daniestevez commented 1 year ago

Looking at the patches that are applied to the default ADI firmware to obtain the Pluto+ firmware, it doesn't seem too difficult to adapt the Maia SDR firmware for the Pluto+. With some modifications, these patches would apply to maia-sdr/plutosdr-fw. I think the result will work just fine.

However, I don't have a Pluto+, so I can't test this. I'm happy to give support to port Maia SDR to the Pluto+, but I need someone with access to a Pluto+ to lead this task. I can even do the modifications so that the patches apply cleanly, but someone will need to build the firmware image, test if it boots and works, and sort out any potential problems with my support.

Bringing Maia SDR to a new hardware platform is not only a one-time effort. It also means building and testing new releases, and making the necessary changes if required by new firmware versions (though I don't foresee huge changes for new versions once the first Pluto+ version works).

corvus-ch commented 1 year ago

Today I attended the talk by @daniestevez at the Software Defined Radio Academy 2023. I do own a Pluto+ and I offered my help on this subject.

@daniestevez can you please provide me a firmware built for the Pluto+ or provide me with documentation how I can try to build on my own?

daniestevez commented 1 year ago

@corvus-ch I have started by adding a Vivado project for the Pluto+ to maia-hdl. This builds a bitstream successfully. The remaining elements of the system (kernel, device tree, u-boot) still need to be done. I'll need to think of good way to include these in the repository to avoid as much code duplication as possible. I don't like the approach that the official plutoplus firmware uses (which is publishing diff's against ADI's firmware), because it seems quite difficult to maintain.

I have opened a draft PR https://github.com/maia-sdr/maia-sdr/pull/66

daniestevez commented 1 year ago

@corvus-ch here is an attempt at a Pluto+ Maia SDR firmware. In principle, this should work, but I wouldn't be surprised if it doesn't. Probably the file plutoplus.frm needs to be renamed to pluto.frm to flash using the USB mass storage method. plutoplus.zip

The draft PR with the changes is https://github.com/maia-sdr/plutosdr-fw/pull/7

corvus-ch commented 1 year ago

I tried updating the firmware by copying it to the USB device, and I also tried DFU.

For USB update, I had to rename the file to pluto.frm. After ejecting it, the drive came back almost instantly. The frm file was gone and an empty file FAILED got listed.

For DFU, I tried:

sudo dfu-util -a 1 - D plutoplus.dfu

Out of curiosity, I also downloaded https://github.com/maia-sdr/plutosdr-fw/releases/tag/maia-sdr-v0.2.1.

sudo dfu-util -a 0 -D boot.dfu
sudo dfu-util -a 1 -D pluto.dfu

So, what to conclude from this?

If I recall correctly, I somewhere read that the default Adalm Pluto firmware also works on the Pluto+ but with limitations. The one I recall is that use of the Ethernet port is not possible. I assume, something similar at play here. I do not know how I can verify this.

daniestevez commented 1 year ago

The current release of Maia SDR also works on the Pluto+ as is without modification

Wow! That came out as a surprise. From reading this diff I had the idea that the ADALM Pluto and the Pluto+ use different FPGA packages and completely different pinouts, so you cannot use an ADALM Pluto FPGA bitstream in the Pluto+ or vice versa. However, the possibility to use an ADALM Pluto in the Pluto+ seems to be even reconized in the README of the Pluto+ repository: "When using the official ADI-PlutoSDR firmware, please connect to URST-MI052.".

On a closer look, it seems that what they've done is to maintain the pinout on the FPGA wirebond pads level. The pins on the package are at completely different positions, and they are called completely different, but they are bonded to the same FPGA pads. For instance, in the ADALM Pluto, the rx_clk_in clock from the AD9363 goes to pin L12, and on the Pluto+ it goes to pin U18. Now, on a CLG225 package, which is what the ADALM Pluto uses, pin L12 is bonded to IO_L12P_T1_MRCC_34. On a CLG400 package, which is what the Pluto+ uses, pin U18 also goes to IO_L12P_T1_MRCC_34. I have only checked a few pins more, but I guess they've been careful with their pinout to be compatible with the ADALM Pluto bitstreams, even though programming a bitstream on a different package is really unorthodox.

For DFU, I tried:

To debug this I suggest the following. You need to connect a 1.8V TTL serial to USB adapter on the RXD and TXD pins (and GND) of J3. Then try to boot from RAM and see what messages you get on the serial. To boot from RAM, first boot into a working firmware and run

device_reboot ram

The device should go into DFU mode, waiting for a firmware to be booted from RAM. When DFU is ready, run

sudo dfu-util -D plutoplus.dfu -a firmware.dfu
sudo dfu-util -e -a firmware.dfu
LunaWuna commented 1 year ago

Testing on my pluto+ with that build, im also getting it re-appearing very quickly saying that its failed. however on the unmodified release, as expected the ethernet doesn't work.

corvus-ch commented 1 year ago

However, the possibility to use an ADALM Pluto in the Pluto+ seems to be even reconized in the README of the Pluto+ repository: "When using the official ADI-PlutoSDR firmware, please connect to URST-MI052.".

I must have glossed over this. That section explains some jumper settings. I happened to have the jumper set between URST and MI052. That is the configuration for the stock firmware, which also proved to work for the current release of MaiaSDR.

I Then loaded the custom firmware and then set the jumper between URST and MIO46. The observations are not:

So, my original struggle was a clear case of "you are holding it wrong". The MaiaSDR firmware provided, does work except for accessing the web UI via Ethernet.

My guess is, the web server is bound to a specific IP. Changing the configuration to make it listen on 0.0.0.0 instead of 192.168.2.1 should fix that.

daniestevez commented 1 year ago

Great. So the thing regarding URST-MI052 is that in the ADALM Pluto, MIO52 (one of the CPU GPIO pins) is used to control the reset of the USB PHY. In the Pluto+ Vivado configuration they're using MIO46 (another CPU GPIO pin) instead, for no apparent reason justifying the difference. Since they've gone to the effort of making the FPGA pinout compatible, they've also included a jumper on the board that allows working around this difference. If the jumper is not set correctly, I guess that the USB PHY will stay in reset.

My guess is, the web server is bound to a specific IP. Changing the configuration to make it listen on 0.0.0.0 instead of 192.168.2.1 should fix that.

No. The web server is bound to all interfaces in IP addresses. In fact, there is the ipaddrmulti option that assigns to the USB Ethernet all the IPs of the form 192.168.xx.1/24, and this works fine (you can access the HTTP server on any of these IPs). In your case this option will conflict with the Ethernet address 192.168.1.39. Can you confirm that you have ipaddrmulti disabled?

Since I don't know why you can't connect to 192.168.1.39:8000, can you paste the output of running these on the Pluto+ with Maia SDR:

ip link show
ip addr show
ip route show
netstat -ln

Also, can you try if you can access http://192.168.1.39:80? This should show ADI's default web server with some documentation. The problem might be something as simple as your network not being set up correctly and the machine replying to your ping 192.168.1.39 being other than the Pluto+.

Can you now flash the Maia SDR firmware via usb storage and/or via DFU? I don't think the problem with the USB reset MIO explains that you weren't able to do this before, since the difference would only be a problem once the new firmware is flashed and booted.

corvus-ch commented 1 year ago

My guess is, the web server is bound to a specific IP. Changing the configuration to make it listen on 0.0.0.0 instead of 192.168.2.1 should fix that.

Forget about that. I messed that up on the other side (configured IP addresses on the wrong NIC 🤦🏼). I can now confirm, it works flawlessly over the Ethernet connection. Please notify me if you still want to take a look at the output of all those ip/netstat commands.

Can you now flash the Maia SDR firmware via usb storage and/or via DFU? I don't think the problem with the USB reset MIO explains that you weren't able to do this before, since the difference would only be a problem once the new firmware is flashed and booted.

Firmware update via USB storage works for the original Adalm Pluto firmware and the current release of MaiaSDR. Flashing the Pluto+ as well as the custom build from #7 works only via DFU.

daniestevez commented 1 year ago

Please notify me if you still want to take a look at the output of all those ip/netstat commands.

Great! No need, since this is working.

Flashing the Pluto+ as well as the custom build from https://github.com/maia-sdr/plutosdr-fw/pull/7 works only via DFU.

Apparently this is the only problem now. I'd like to bring #7 to a point where it's able to build a release for Pluto+ that people can flash normally (via both usb storage and DFU). At this point it won't make any sense to install the ADALM Pluto Maia SDR release on the Pluto+, because that doesn't support Ethernet and the SD card. This problem appears to be the only blocker.

Can you give more detail of what works? There are two ways to use DFU. One is DFU RAM boot, in which the firmware is copied to RAM by DFU and then ran (this is what you do with device_reboot ram), and the other one is DFU flashing, in which the firmware is flashed to the QSPI, and then the device is rebooted, so it picks the new firmware from the QSPI when booting (this is what you do when you press the DFU button while applying power). The former is very useful to test firmware in a completely ephemeral way. The latter is useful to overwrite the firmware if you've managed to write a firmware that doesn't boot (in which case you cannot use the normal usb storage or network flashing procedures, which are the main methods of update).

It would be good to see the output of the UART console with the procedures that fail. The process of packing the firmware (both the .frm file for usb storage flashing and the .dfu file) is identical for the Pluto+ firmware repository and for the ADALM Pluto repository, so I don't see what could be going wrong. Perhaps it's some problem with your Pluto+ (maybe it's unable to write to the QSPI for some reason), so it would be helpful for other people to test this in their Pluto+'s (@LunaWuna also tested this, so maybe they can confirm how they've set up the MIO46 vs MIO52 jumper, in case this actually matters), and for you to test flashing a known working firmware in your Pluto+ (unless you've already done it recently).

LunaWuna commented 1 year ago

(@LunaWuna also tested this, so maybe they can confirm how they've set up the MIO46 vs MIO52 jumper, in case this actually matters), and for you to test flashing a known working firmware in your Pluto+ (unless you've already done it recently).

The current position is the default (MIO46 to URST). I'll attempt it with it set to MIO52 and report back.

corvus-ch commented 1 year ago

Can you give more detail of what works? […] and the other one is DFU flashing, in which the firmware is flashed to the QSPI, and then the device is rebooted, so it picks the new firmware from the QSPI when booting (this is what you do when you press the DFU button while applying power).

This is the one I used.

It would be good to see the output of the UART console with the procedures that fail.

I tested several combinations of firmware currently loaded and firmware loaded via USB storage. My findings are the following:

Current Update Result
plutosdr-fw-v0.33-3-gd382-dirty maia-sdr-plutosdr-fw-4 FAILED
plutosdr-fw-v0.33-3-gd382-dirty plutosdr-fw-maia-sdr-v0.2.1 OK
plutosdr-fw-v0.37 maia-sdr-plutosdr-fw-4 FAILED
plutosdr-fw-v0.37 plutosdr-fw-maia-sdr-v0.2.1 OK
plutosdr-fw-v0.37 plutosdr-fw-v0.33-3-gd382-dirty OK

Updating to maia-sdr-plutosdr-fw-4 did not result in any output on the serial.

In one case, updating to plutosdr-fw-v0.33-3-gd382-dirty failed and produced the following output:

spi-nor spi1.0: Erase operation failed.
spi-nor spi1.0: Attempted to modify a protected sector.
blk_update_request: I/O error, dev mtdblock0, sector 128 op 0x1:(WRITE) flags 0x4800 phys_seg 128 prio class 0
Buffer I/O error on dev mtdblock0, logical block 128, lost async page write
spi-nor spi1.0: Erase operation failed.
spi-nor spi1.0: Attempted to modify a protected sector.
blk_update_request: I/O error, dev mtdblock0, sector 256 op 0x1:(WRITE) flags 0x4800 phys_seg 128 prio class 0
Buffer I/O error on dev mtdblock0, logical block 256, lost async page write
spi-nor spi1.0: Erase operation failed.
spi-nor spi1.0: Attempted to modify a protected sector.
blk_update_request: I/O error, dev mtdblock0, sector 384 op 0x1:(WRITE) flags 0x4800 phys_seg 128 prio class 0
Buffer I/O error on dev mtdblock0, logical block 384, lost async page write
spi-nor spi1.0: Erase operation failed.
spi-nor spi1.0: Attempted to modify a protected sector.
blk_update_request: I/O error, dev mtdblock0, sector 512 op 0x1:(WRITE) flags 0x4800 phys_seg 128 prio class 0
Buffer I/O error on dev mtdblock0, logical block 512, lost async page write
spi-nor spi1.0: Erase operation failed.
spi-nor spi1.0: Attempted to modify a protected sector.
blk_update_request: I/O error, dev mtdblock0, sector 640 op 0x1:(WRITE) flags 0x4800 phys_seg 128 prio class 0
Buffer I/O error on dev mtdblock0, logical block 640, lost async page write
spi-nor spi1.0: Erase operation failed.
spi-nor spi1.0: Attempted to modify a protected sector.
blk_update_request: I/O error, dev mtdblock0, sector 768 op 0x1:(WRITE) flags 0x4800 phys_seg 128 prio class 0
Buffer I/O error on dev mtdblock0, logical block 768, lost async page write
spi-nor spi1.0: Erase operation failed.
spi-nor spi1.0: Attempted to modify a protected sector.
blk_update_request: I/O error, dev mtdblock0, sector 896 op 0x1:(WRITE) flags 0x800 phys_seg 119 prio class 0
Buffer I/O error on dev mtdblock0, logical block 896, lost async page write
spi-nor spi1.0: Erase operation failed.
spi-nor spi1.0: Attempted to modify a protected sector.

I can no longer reproduce this.

Generally, when ejecting the drive after copying a working .frm file to it, one of the LEDs starts flashing for quite a while (30+ seconds). For the failing Maia Pluto+ build, the LED does only blink for a few seconds. There is no output on the console when the flashing is going on.

Side note. My version of the Pluto+ seems to use 3.3v for the serial connection (the schema suggests it uses 1.8v). I was able to read the serial using my Raspberry Pi Debug Probe. However, I did only connect TX>RX from the Pluto to the probe to be on the safer side.

daniestevez commented 1 year ago

I think I've found the problem. The firmware update script checks that a magic string is present in the firmware image, and terminates otherwise. I modified this in the Maia SDR Pluto+ image, without giving it a second thought.

I will revert this modification and build a new image for testing.

daniestevez commented 1 year ago

Here is the new firmware image with this problem fixed: plutoplus.zip

corvus-ch commented 1 year ago

That worked. I was now able to flash the firmware through the USB drive.

What works?

What does not work?

What is supposed to work at this stage?

daniestevez commented 1 year ago

Everything was supposed to work with this firmware, so it's surprising that maia-httpd on port 8000 doesn't work, since it worked for you before when using DFU flashing with the Maia SDR Pluto+ firmware.

Just in case something was inconsistent in the previous build, I'm doing a make clean && make and will post the new firmware image when this finishes.

Regarding maia-httpd on port 8000, can you:

Regarding the SD card, I'm not 100% sure how the SD card is supposed to work on the Pluto+, but comparing with other Zynq's I've used with an SD card, you should get devices /dev/mmcblk0pN for partition N of the SD card. I guess lsblk is not installed in the rootfs, but that's not strictly necessary. Can you:

daniestevez commented 1 year ago

Here is a firmware image built from scratch: plutoplus.zip

corvus-ch commented 1 year ago

Please check https://gist.github.com/corvus-ch/1cc3d0c670c0ca5aba8c922fcb7e3d94 for various outputs.

This now starts to get weird. Looks like communication with the radio chip has died. I even switched back to maia-sdr-v0.2.1, which worked before, only to have the same failure when starting maia-httpd.

I am utterly lost here. Please advise what and how to debug further.

daniestevez commented 1 year ago

Regarding maia-httpd not starting:

# /root/maia-httpd 
Error: failed to open maia-sdr UIO

Caused by:
    UIO device not found

It seems that the kernel command line parameter is missing the uio_pdrv_genirq.of_id=uio_pdrv_genirq parameter required by Maia SDR. See the installation instructions for how to set this up. I wonder if you overwrote the u-boot configuration somehow, as this was working before.

Regarding the SD controller, it seems its correctly detected by the kernel:

mmc0: SDHCI controller on e0100000.mmc [e0100000.mmc] using ADMA

yet you don't have /dev/mmcblk0* devices. Do you have a working SD card inserted? Can you check if the SD card work with the (non-Maia-SDR) Pluto+ firmware?

corvus-ch commented 1 year ago

🤦🏼 I did reset boot to get a "clean" state but forgot about those parameters. Going through the installation instructions again, resolved the issue with maia-httpd.

As for the SD cared, it looks the same as the original Pluto+ firmware: seems to be detected in dmesg but no device to interact with it.

daniestevez commented 1 year ago

Thanks. This looks good.

For the SD card, perhaps someone else can try on their Pluto+, since maybe there's a hardware problem with your device.

Since it appears that the firmware is working, I will be taking the PRs out of draft status now and merging them in a few days.