FPGA Folder Missing After Flashing New Ubuntu Image, Serial Over USB-C Lost, and Flashing Issues

Hello everyone,

I’m having some issues with my BeagleV Fire board and could really use some help from the community. Here’s a rundown of what happened and what I’ve tried so far:

Initially, I flashed a new Ubuntu 24 image onto the board. After booting, I noticed that the /sys/kernel/debug/fpga/ directory was missing, which I needed to update the gateware. This is the error text: Triggering FPGA Gateware Update (/sys/kernel/debug/fpga/microchip_exec_update)
/usr/share/microchip/gateware/update-gateware.sh: line 41: /sys/kernel/debug/fpga/microchip_exec_update: No such file or directory

The error showed whenever I’ve tried to change gateware with this command: sudo /usr/share/beagleboard/gateware/change-gateware.sh default (no matter what gateware)

The board rebooted as expected, but after that, it stopped connecting to my laptop via the USB-C serial connection. I can still access the serial output via a USB-to-UART adapter on the debug UART pins, which shows the HSS and U-Boot logs, but the USB-C serial functionality seems gone.

Since then, I’ve been trying to recover the board by reflashing the original Ubuntu image I had, beaglev-fire-ubuntu-23.04-20231121 (downloaded from BeagleV-Fire Ubuntu 2023-11-21 - BeagleBoard). I’ve attempted this multiple times using Balena Etcher on Windows, but every time, after the flashing process completes the verification stage, I get an error: Oops! Something went wrong! If it is a compressed image, please check that the archive is not corrupted. The writer process ended up unexpectedly.

I’ve tried both the old and new images several times, with different USB-C cables, but the result is the same. Here’s what I’ve observed and tried:

  1. Serial Output: Using USB-to-UART, I can see U-Boot (2022.01-linux4microchip+fpga-2023.02-dirty) starting, but it fails to boot properly. With the latest flash attempt, it loads /boot.scr from mmc 0:2, but I get Wrong image format for “source” command, and it drops to the U-Boot prompt.
  2. Manual Boot Attempts: I tried booting manually with:
    load mmc 0:2 0x80200000 /Image
    load mmc 0:2 0x8a000000 /mpfs-beaglev-fire.dtb
    setenv bootargs ‘root=/dev/mmcblk0p3 ro rootfstype=ext4 rootwait console=ttyS0,115200 earlycon loglevel=8’
    booti 0x80200000 - 0x8a000000
    This resulted in Bad Linux RISCV Image magic!. I also tried bootm with beaglev_fire.itb, but got Bad FIT kernel image format! (err=-22).

My goals are to:

  • Restore the board to a working state with Ubuntu 23.04.
  • Regain USB-C serial functionality.
  • Fix the FPGA gateware update process.

Has anyone encountered similar issues? Could this be a hardware problem (eMMC or USB-C port), or am I missing something in the flashing/boot process? I don’t have a FlashPro programmer. Any advice on next steps or tools I should try would be greatly appreciated!

Thanks in advance for your help!

This is because the flashing script needs to be updated to v6.6.x which changed from v6.1.x

For flashing please retry with version of etcher: balenaEtcher: known good versions

Regards,

Thank you very much for your suggestion! I’ve tried reflashing the Linux image with an older version of Balena Etcher, and it worked – the flashing process completed successfully. Now I am stuck with another problem. The USB-C connector is still unrecognizable on my laptop, and when looking at the serial output through a USB-to-UART terminal, I see that the boot process gets stuck here: [see attached photo – RCU stall on CPU 0]. I think it might be a problem with the gateware I uploaded last time – this is the one I used: Artifacts · Busted Wing / Gateware-serv-on-fire · GitLab (the latest one). Is there anything I should do to fix this? I suspect the gateware might be causing the boot issue, and I’m also wondering how to restore the USB-C serial functionality. Any advice would be greatly appreciated!

Now were moving into “new question” territory,
but the short answer is that you’re reading from memory locations
that have no hardware backing; noone’s home to satisfy the request,
so your CPU stalls.