mirror of
https://github.com/RfidResearchGroup/proxmark3.git
synced 2026-10-01 10:48:25 +00:00
iceman1001andClaude Opus 5 (1M context)
43fe6c3eb8
The 1 MB block branch exists for the ARM .data section: start.c's uncompress_data_section() reads one 4-byte length and does one LZ4_decompress_safe(), so .data has to arrive as a single block. It was selected by 'num_infiles == 1', which is not what tells the two callers apart. A build that skips LF, FeliCa and ISO15693 leaves FPGA_BITSTREAMS holding just fpga_pm3_hf.bit, so the bitstream took that same branch and was packed as one 42 kB block. get_from_fpga_combined_stream() decompresses into a FPGA_RING_BUFFER_BYTES buffer, 16 kB since83c3f81b1: [#] inflate returned: -13247 [#] reset_fpga_stream failed Before83c3f81b1the copy was clamped with MIN(FPGA_RING_BUFFER_BYTES, ...) whatever buffer_size said, so the blocks came out at 30 kB and the 30 kB ring buffer still took them. That is why the commit looks like the cause - it only removed the clamp that was covering for the wrong branch. Add -s for the single block case and let the FPGA path always chop at FPGA_RING_BUFFER_BYTES, however many bitstreams went in: 4 bitstreams 169344 in -> 106933 out, byte identical to before 1 bitstream 42172 in -> 28718 out, 3 blocks 13265/13206/2247, was 1 block of 27627 .data (-s) 14944 in -> 8786 out, byte identical to the obj/fullimage.data.bin.z in tree Also hand the ring buffer back when reset_fpga_stream() fails. The early return left it allocated for the rest of the session, which is the reporter's [#] BigBuf_size............. 48116 [#] Available memory........ 31732 48116 - 31732 is 16384, exactly FPGA_RING_BUFFER_BYTES. No CAPABILITIES_VERSION bump: fpga_all.bit.z is objcopy'd into the same fullimage as the decompressor that reads it, so nothing here is client facing. Reported and correctly diagnosed by @ewangsoft. Fixes #3599 Co-Authored-By: Claude Opus 5 (1M context)