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:
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.
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!
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.
I’m having the same problem, and I don’t understand your answer. I tried the link to balenaEtcher and copied the flash image again, but I still don’t have that folder.
I have created a custom Linux build from your Docker build environment because I needed some changes to the Linux kernel. After going through that, the image doesn’t seem to have the microchip specific FPGA folder mentioned in the original post. Can you please explain, and let us know if there is way to just grab those files from a repo somewhere?
Or are those kernel device files? Is there a kernel build option I need to specify to get that added in?
There are far far too many variables in your equation to say anything meaningful about your particular problem, save the fact that the “files” you’re missing are made by kernel drivers.
6.1 and 6.6 have different “files”, so you’ll need the right script, depending your kernel version.
From my understanding, once you update the Linux image to Ubuntu 24.04, the change gateware script also changes. Since this is the problem:
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
This was the solution I needed. I just tried this new script and it works. Apparently, I unknowingly got involved with a much different Linux version and its associated FPGA update structure. Thank you!
It’s not quite as simple as that, because the Ubuntu version really doesn’t have any bearing whatsoever on the location and naming of the control files.
They are governed exclusively by what kernel version you run.
If you did an sudo apt update && apt upgrade after deploying the latest image,
you should be good to go; otherwise, we’ll have to kick this one upstairs…
