Skip to content

Locate FPGA bitstream via the firmware_info at start of flash - #1810

Open
martinling wants to merge 5 commits into
greatscottgadgets:mainfrom
martinling:bitstream-in-firmware-info
Open

Locate FPGA bitstream via the firmware_info at start of flash#1810
martinling wants to merge 5 commits into
greatscottgadgets:mainfrom
martinling:bitstream-in-firmware-info

Conversation

@martinling

Copy link
Copy Markdown
Member

These changes are intended to help simplify integration with PortaPack firmware.

Currently, normal hackrf_usb builds embed the FPGA bitstream image as a binary blob, the address of which is known at link time and used by the fpga_loader implementation. DFU and RAM-only builds omit the bitstream, and don't bring up the FPGA.

PortaPack firmwares embed a hackrf_usb firmware image which is copied to RAM and executed to put the device in USB mode. Having both codebases able to access the FPGA has previously been achieved by placing the bitstreams at a fixed offset in the flash, but this forces an arbitrary partitioning of the flash space.

Here's a nicer solution: put the bitstream address in the authoritative firmware_info structure, which is always located at an offset of 0x400 in the flash image, after the vector table.

After making that change, it's then easy to also fix #1739, by having DFU and RAM builds access the bitstream from flash in the same manner.

This commit does not bump the struct_version field, as that would
break compatibility with existing versions of hackrf_spiflash.

Instead, we add a magic field to indicate that a bitstream address
is present.
@martinling martinling added this to the harmony milestone Aug 21, 2026
This allows a firmware that has been embedded inside a larger image
to determine where it should find its bitstream in the flash.
Setting this option forces the bitstream not to be included in the
hackrf_usb image (as is already the case for RAM and DFU builds).

This may be useful for integration into other firmwares which seek
to embed a hackrf_usb firmware image whilst placing its bitstream
elsewhere. The loader will find the bitstream via the firmware_info
struct at the start of flash.
This is a best-effort approach. If a valid bitstream address is not
found in the flash, loading fails similarly to how it is skipped now.
@martinling
martinling force-pushed the bitstream-in-firmware-info branch from db84d04 to 2eeddc2 Compare August 21, 2026 17:55
@martinling
martinling marked this pull request as ready for review August 25, 2026 16:14
@mossmann
mossmann requested a review from mndza August 25, 2026 16:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

HackRF Pro does not work when booted from DFU

2 participants