(Linux) Problems installing Mayhem firmware to PortaPack H2+

[phil-stumpy]

I separately purchased a PortaPack H2+R3 and HackRF One but am having trouble installing the Mayhem firmware to the PortaPack. My HackRF One is running the latest firmware (2023.01.1) as shown in the output from hackrf_info:

hackrf_info version: 2023.01.1
libhackrf version: 2023.01.1 (0.8)
Found HackRF
Index: 0
Serial number: 0000000000000000010961dc2a3a3d4f
Board ID Number: 4 (HackRF One)
Firmware Version: 2023.01.1 (API:1.07)
Part ID Number: 0xa000cb3c 0x00584765
Hardware Revision: r9
Hardware appears to have been manufactured by Great Scott Gadgets.
Hardware supported by installed firmware:
    HackRF One

I downloaded the latest nightly Mayhem build (230208) to be sure that it would be built from the same base firmware and tried to install it using the command hackrf_spiflash -w portapack-h1_h2-mayhem.bin, but received the following error:

File size 1004328 bytes.
Checking target device compatibility
Compatibility test failed.

I'm running Ubuntu 22.04.1 LTS. When I switch the PortaPack/HackRF on the screen flashes briefly before reverting to a black screen, so I don't have any option to select "HackRF Mode". I've tried rebooting whilst holding the LEFT button, and separately whilst holding the UP button, but the display just does the same thing each time (flashing briefly before reverting to a black screen).

Both the PortaPack and HackRF are both new devices so I have not previously updated the firmware on either device.

[gullradriel]

Hello.
From my investigations, looking at hackrf_spiflash code, your board fails at that test:

if (!ignore_compat_check) {
			printf("Checking target device compatibility\n");
			result = compatibility_check(data, length, device);
			if (result) {
				printf("Compatibility test failed.\n");
				fclose(infile);
				infile = NULL;
				return EXIT_FAILURE;
			}
		}

There are a few cases where the compatibility check is failing without outputting any informations about the failure.
As the code states, there is a flag (-i) to disable compatibility check.:

hackrf_spiflash -i -w portapack-h1_h2-mayhem.bin

The last firmware is having more boot up keys: Please see https://github.com/eried/portapack-mayhem/wiki/Won't-boot

[gullradriel]

Please not that I do not support or endorse any failure ;-p

[phil-stumpy]

So I guess my first problem is actually being able to ensure that the PortaPack is in "HackRF mode" before trying to update the firmware. I have tried holding each of the buttons down as I switch on the device, but none of them seem to help me get past the black screen.

[phil-stumpy]

Ok, so I can see why the compatibility check is failing. The function compatibility_check starts as follows:

        uint8_t* fw_info = data + FW_INFO_LOCATION;
	if (strncmp((char*) fw_info + FW_MAGIC_OFFSET, "HACKRFFW", 8) != 0) {
		// Couldn't find firmware info structure,
		// revert to old compatibility check method if possible.
		if (board_id != BOARD_ID_HACKRF1_R9) {
			return compatibility_check_og(data, length, device);
		}

		return EXIT_FAILURE;
	}

The portapack-h1_h2-mayhem.bin firmware doesn't contain the "HACKRFFW" magic at the expected offset (or at all in fact) so it drops down to check the board_id, which in my case is BOARD_ID_HACKRF1_R9 (i.e. the latest available hardware), and doesn't try the old compatibility check (which would be passed because the string "HackRF One" is contained within the firmware). At this point the compatibility check fails.

It looks like GSG are using a new firmware info structure on the latest boards? Not sure how this would affect the flashing process if I chose to ignore the compatibility check ...

[phil-stumpy]

Ah, so looking through the portapack-h1_h2-mayhem.bin firmware blob, it does contain the "HACKRFFW" magic but not at the location expected by the hackrf_spiflash tool. The hackrf_spiflash tool expects the magic to be at offset 0x400, but it's at offset 0xEAF7C within the portapack-h1_h2-mayhem.bin firmware blob?

There is also a hackrf_one_usb.bin firmware blob within the nightly build, but this doesn't appear to contain the "HACKRFFW" magic at all so not sure what it's used for ...

[phil-stumpy]

disabling the compatibility check, with the -i option, enables me to flash portapack-h1_h2-mayhem.bin to my device. Unfortunately, no matter which button I press when I switch on, I am unable to get past the black screen problem. Does this mean that the latest HackRF One build (R9) no longer provides the correct display drivers? Is there a way to determine what display drivers I have available and which one I need for my device?

[phil-stumpy]

Apologies for the spam ... so after disconnecting my HRF1/PP from the USB and then reconnecting it, my device can no longer be found - the USB LED on the HRF1 does not light up when connected.

The only way I have found to re-establish the USB connection is to detach the PP and enter DFU mode on the HRF1, then use dfu-util to write the original hackrf_one_usb.dfu back to the device. After letting dfu-util reset USB back to runtime mode, I then have to reflash using hackrf_spiflash -w hackrf_one_usb.bin to get back to an original working state.

[avhoboken]

Hi Phil,
I'm facing a similar problem although using older hardware. After updating the PP with the latest firmware/sdcard I can't get it to work anymore. I got my HackRF one working again by flashing the hackrf_one_usb.dfu but as soon as I connect the PP to my HackRF it's not recognised anymore by Windows Ubuntu host and screens stays black, despite all tried troubleshooting options. DFU mode also doesn't work anymore.
So if you have found the solution please share with us :)

[Brumi-2021]

Hi , let me copy / paste an old post from january that I shared in discord. In my case , dont ask me why , but I got the same problem than you. The strange way that I found to solve that H2+ (and H1) when no power up , just black LCD, it is the following one :
(1) disassembly both boards . (In my H2+ it is mandatory , because I can not activate DFU with both boards assembled . In case of H1 , no need to disassembly) .

(2) pic up Hackrf, and if you have correct LED green and correct USB Comm., flash it ,if H2+, with special fw jumbo77 1.43 (if H1 use official fw 1.43) binary (if it is not bricked ) (if it is bricked ,-no LED green
USB comm, you will need preliminary DFU bin to RAM additional step *) .

(3) assembly boards , confirm correct power up . (4) put the device in Hackrf mode and reflash latest Mayhem binary ex 1.60) ,.and in the first power up , keep pressing left button (in a H2+ with WM8731 big CPLD QFP100, ex my unit ) for > 2 secs till getting correct LCD display.

(After that intermediate process just black LCD-->1.43-->1.60 , from 1.60 onwards , you will be able to upgrade it to any new 1.6x directly , without that recover process) .
I hope it helps to someone you can comment here .
Cheers

[avhoboken]

Seems like the solution for me as well 👍
Got PP running again on 1.4.3 and 1.5.3. Upgrading to 1.5.4 and 1.6.0 still gives problem with display but I now suspect that empty backup battery is giving issues as date/time is not remembered. Just ordered a new cr1220, have to wait a few days for further testing

[Brumi-2021]

From fw version 1.5.4 onwards , it was introduced that PR #662 that uses the persistent memory to test and store the hardware and LCD config settings . And that memory uses the same back up voltage than the Real Time Clock calendar, both needs a healthy cell battery button voltage . But sometimes, in a reflashing process , although we got good battery cell button voltage, the unit seems to be bad initialized in those persistent bytes and we got strange black screen . (And probably doing those above steps we are re initializing them , just my guess ) .

[gullradriel]

I agree with @Brumi-2021 explanations. Maybe we should add something about it in the FAQ !

[gullradriel]

@Brumi-2021 done. Feel free to adjust :-)
https://github.com/eried/portapack-mayhem/wiki/Won't-boot

[gullradriel]

As the issue is resolved and now documented, I'm closing it.

[phil-stumpy]

Hi , let me copy / paste an old post from january that I shared in discord. In my case , dont ask me why , but I got the same problem than you. The strange way that I found to solve that H2+ (and H1) when no power up , just black LCD, it is the following one : (1) disassembly both boards . (In my H2+ it is mandatory , because I can not activate DFU with both boards assembled . In case of H1 , no need to disassembly) .

(2) pic up Hackrf, and if you have correct LED green and correct USB Comm., flash it ,if H2+, with special fw jumbo77 1.43 (if H1 use official fw 1.43) binary (if it is not bricked ) (if it is bricked ,-no LED green USB comm, you will need preliminary DFU bin to RAM additional step *) .

(3) assembly boards , confirm correct power up . (4) put the device in Hackrf mode and reflash latest Mayhem binary ex 1.60) ,.and in the first power up , keep pressing left button (in a H2+ with WM8731 big CPLD QFP100, ex my unit ) for > 2 secs till getting correct LCD display.

(After that intermediate process just black LCD-->1.43-->1.60 , from 1.60 onwards , you will be able to upgrade it to any new 1.6x directly , without that recover process) . I hope it helps to someone you can comment here . Cheers

Yeah I tried the jumbo77 firmware build but it still didn’t work correctly for the R9 hardware, so that doesn’t solve the problem sadly. Apparently GSG have submittier a pull request to the original PP firmware (sharebrained/portapack-hackrf#187) to add support. I’ll try and take a look to see what the changes are, that are required to get the Portapack supporting the latest hardware.

[bnazari]

Been looking at the 30+ changed files compared to the master https://github.com/sharebrained/portapack-hackrf, but Mayhem has added quite a lot of code that specifically addresses the max2837, for instance. Looks like max283x will be helpful, though. Any quick way of doing this or is this a line-by-line scrub? Might take some time to get R9 boards working with the H2.

[phil-stumpy]

I went through the changes submitted in the GSG pull request and, with a couple of additional edits, managed to get the Mayhem firmware working on the R9 build. I haven’t been through and tested all the Apps but the device is at least functional now.

I still lose USB connectivity after updating the firmware, so I need to figure out what’s going on there. I can work around the USB issue temporarily, using DFU mode as necessary.

So almost there … 😎

[Brumi-2021]

Good progress and good news !
I am not familiar with this R9 hackrf version.
You are almost there ... 💪let us know about it .

[phil-stumpy]

It turns out the USB issue was a misunderstanding on my part - once I switched correctly to "HackRF Mode" on the PortaPack I was able to successfully use the USB interface.

I've submitted a new Pull Request with the changes needed to get the Mayhem firmware working for the latest HackRF One R9. I've not been through and tested each of the Apps, but as far as I can tell there are no changes that should directly affect them.