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

BeagleV
1

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!

2

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,

3

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!

task
task649×384 12.3 KB

4

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.