Custom firmware installation on MK4 - _boot.bbf or _noboot.bbf?
I'm trying to flash custom firmware to fix a few annoyances with the stock firmware. I cloned the repository, built the firmware, cut the trace on the board, and flashed it, but it won't actually boot into the custom firmware - it just gets stuck on the bootloader screen with the progress bar halfway. I can re-flash the stock firmware and it works fine.
I didn't see any build errors or warnings. I was able to select "Ignore" when I got the signature verification error, so I assume that means the board modification was successful. The instructions I followed were for the MINI, and they mentioned a jumper on the board that doesn't seem to be present on the MK4. There was also a forum post that showed where the trace was on the MK4 that didn't mention the jumper.
When the firmware was built, it produced two firmware images: mk4_release_boot.bbf and mk4_release_noboot.bbf.
My main question is this: What is the difference between mk4_release_boot.bbf and mk4_release_noboot.bbf?
I assumed that mk4_release_boot contains a bootloader image and mk4_release_noboot does not. I used mk4_release_noboot because I didn't want to risk having it flash the bootloader and bricking the board, and none of my changes were to the bootloader anyway. I can't find any documentation on exactly how the two files differ or what it will do if I flash the _boot version.
RE: Custom firmware installation on MK4 - _boot.bbf or _noboot.bbf?
I figured it out by reading the source of the build scripts, so for future reference:
mk4_release_noboot.bbf is for running the firmware straight on the processor, without a bootloader present. I don't think this is useful to many users unless you have your own custom board.
mk4_release_boot.bbf is for running the firmware from the bootloader, and contains a bootloader image which will be flashed alongside it. The image is not built from the Prusa-Buddy-Firmware repo and is just a binary blob downloaded from Prusa's Amazon S3 bucket.
mk4_release_emptyboot.bbf is also for running the firmware from the bootloader, but does not contain the bootloader image. This is the one that ended up working for me. It is not built by default -- you have to pass --bootloader empty to build.py to get it.
Also, the instructions I found to force the bootloader to enter flashing mode were a little unclear. They said "press the selector button immediately after reset", but to get the timing right you have to mash the selector button until the flashing prompt shows up. At first I was just holding the button down but I guess that doesn't work properly.
RE: Custom firmware installation on MK4 - _boot.bbf or _noboot.bbf?
Well done! Not that easy to do... what are some of the changes you made?
Prusa MK4 since Jan 2024, Printables: @MikeB_1505898
RE: Custom firmware installation on MK4 - _boot.bbf or _noboot.bbf?
Well, so far, I've just disabled the auto-serial printing screen because I only use Octoprint to do control moves. I have an external USB number pad sitting right by the printer which is plugged into an old laptop which runs Octoprint, mjpeg-streamer, and a Python script which lets me use the number pad to move the head around, set the temperature, and various other actions. It was really annoying having it go into "printing mode" when I'm just raising the head up.
I plan to add a bunch of stuff to the Prusalink API, like being able to send GCode commands directly so I don't have to use Octoprint at all, and maybe some way to simulate button presses so I don't have to get up and go into the other room just to answer a prompt. I have the camera where it can see the display, but I could also have it dump the frame buffer as a QOI image.
Also, after a print finishes, it moves the head up really slowly and I'm kinda impatient. I already modified the End GCode in PrusaSlicer to increase the speed of the parking moves. If I'm standing there waiting to start the next print, it's annoying to have to wait.
RE: Custom firmware installation on MK4 - _boot.bbf or _noboot.bbf?
This is excellent! I just cloned the repo because I plan to make an MK4-Octoprint version of the firmware; essentially a version of the MK4 firmware that brings MK3s+ feature parity to the table.
I love the MK4 hardware (I just finished assembling mine three days ago), but the barely-OctoPrint-friendly firmware has really taken the wind out of my sails, almost to the point of feeling buyer's remorse.
Do you have (or plan to publish) a fork of your work? I'm a 15-year CPP veteran, but this sort of low-level hardware control development is seldom-explored territory for me.