https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/1440 Skip to content Sign up * Why GitHub? Features - + Mobile - + Actions - + Codespaces - + Packages - + Security - + Code review - + Project management - + Integrations - + GitHub Sponsors - + Customer stories- * Team * Enterprise * Explore + Explore GitHub - Learn and contribute + Topics - + Collections - + Trending - + Learning Lab - + Open source guides - Connect with others + The ReadME Project - + Events - + Community forum - + GitHub Education - + GitHub Stars program - * Marketplace * Pricing Plans - + Compare plans - + Contact Sales - + Education - [ ] [search-key] * # In this repository All GitHub | Jump to | * No suggested jump to results * # In this repository All GitHub | Jump to | * # In this organization All GitHub | Jump to | * # In this repository All GitHub | Jump to | Sign in Sign up {{ message }} prusa3d / Prusa-Firmware-Buddy * Notifications * Star 266 * Fork 83 * Code * Issues 143 * Pull requests 32 * Security * Insights More * Code * Issues * Pull requests * Security * Insights New issue Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community. Pick a username [ ] Email Address [ ] Password [ ] [ ] Sign up for GitHub By clicking "Sign up for GitHub", you agree to our terms of service and privacy statement. We'll occasionally send you account related emails. Already on GitHub? Sign in to your account Jump to bottom [QUESTION] Where is the source code for the actual bootloader shipped with the Prusa Mini+? #1440 Open matthewlloyd opened this issue May 26, 2021 * 8 comments Open [QUESTION] Where is the source code for the actual bootloader shipped with the Prusa Mini+? #1440 matthewlloyd opened this issue May 26, 2021 * 8 comments Labels question Comments @matthewlloyd Copy link @matthewlloyd matthewlloyd commented May 26, 2021 * edited The Prusa Mini+ Buddy board ships with a bootloader pre-flashed at the factory. When compiling the firmware source code from this repository, the bootloader is downloaded in binary form by utils/bootstrap.py as part of the build process, from this URL: https:// prusa-buddy-firmware-dependencies.s3.eu-central-1.amazonaws.com/ bootloader-mini-1.0.0.zip This ZIP file contains a 128KB binary file named bootloader.bin: Archive: bootloader-mini-1.0.0.zip Length Date Time Name --------- ---------- ----- ---- 131069 2019-11-08 07:09 bootloader.bin 212 2019-11-08 07:09 __MACOSX/._bootloader.bin --------- ------- 131281 2 files The source code which generates this binary file, which contains executable ARM code, does not seem to be available anywhere in Prusa's GitHub repositories. This bootloader is distributed with the Prusa Mini+, in the flash memory on the ARM chip on the Buddy board, alongside and packaged together with the rest of the firmware, which of course is based on Marlin. It is also distributed in binary form, similarly packaged with Marlin, as part of the official firmware file downloadable from Prusa's website (https://www.prusa3d.com/drivers/). The entire project is a covered work under the terms of the GPL v3 license, as it is based on Marlin which is also GPL v3. I believe that Prusa is required to supply the complete source code for the entire firmware, including the bootloader, because it is packaged together in the distribution media which Prusa itself distributes, to form a larger program. Therefore, in order to comply with Marlin's source code license, I believe Prusa is required to supply the source code for the bootloader. I hereby request Prusa make available the source code for bootloader.bin. The text was updated successfully, but these errors were encountered: 39 @matthewlloyd matthewlloyd added the question label May 26, 2021 @matthewlloyd matthewlloyd changed the title [DEL:[QUESTION]Where is the source code for the actual bootloader shipped with the Prusa Mini+?:DEL] [INS:[QUESTION] Where is the source code for the actual bootloader shipped with the Prusa Mini+?:INS] May 26, 2021 @JustAnother1 Copy link @JustAnother1 JustAnother1 commented Jun 4, 2021 It is sad that prusa does not comment on this :-( They might think that as long as they do not link the bootloader against the firmware they don't need to provide the source. One could argue that the bootloader and the firmware are separate executables that are side by side in the chip and therefore different software. If that holds then they would not be required to publish the source. But I'm not a lawyer. But they also release the 3d files of the plastic parts and so much other stuff that they would not need to release. So why not the bootloader? Maybe they have a good reason? If you do $ strings bootloader.bin you get all the text contained in the binary file. strings.txt So the Bootloader can do an update from USB. And there is this string Developer firmware Maybe they don't want everybody to know how to create a Developer firmware ? Next we can do this $ arm-none-eabi-objdump -D -bbinary -marm bootloader.bin -Mforce-thumb > output.s that gives us a disassembly. output.s.zip Looking through that could take some time. A help could be Radare2 like this $ r2 -a arm -b 16 -m 0x08000000 -w bootloader.bin To understand how that works take a look here: https:// radare.gitbooks.io/radare2book/content/first_steps/intro.html So now who will be first to understand how the Developer firmware feature works? [?] 2 @matthewlloyd Copy link Author @matthewlloyd matthewlloyd commented Jun 5, 2021 * edited They might think that as long as they do not link the bootloader against the firmware they don't need to provide the source. GPLv3 is quite clear on this topic: 5. c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply ... to the whole of the work, and all its parts, regardless of how they are packaged. A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate. The first paragraph clearly applies. Prusa might argue that the combination of the bootloader and the main program is just an aggregate, but the license clearly states that it is not an aggregate if they are combined to form a larger program in or on a storage or distribution medium - and clearly the flash memory of the STM32F407 is a distribution medium. Furthermore, Marlin includes bootloaders, so the Prusa bootloader is "by its nature an extension of the covered work". Developer firmware Good find. Some disassembly reveals the "Developer firmware" message is activated if the 64-byte signature (normally produced from Prusa's private key, and verified using the public key in the bootloader) is filled with 0xFF. The signature is flashed at the start of the firmware image, at memory offsets 0x8020000 - 0x8020040. This is easy to arrange for with a small modification to the build script (specifically pack_fw.py, change 'sig = bytes(64)' to 'sig = b'\xff' * 64'). I'm not sure what the practical implication of this is. I already broke the appendix so I can't determine whether it allows the normal intact-appendix signature check to be bypassed or not, but it's a possibility. It may also bypass the SHA hash check. IMG_5365 Practically speaking, I'm currently trying to get Klipper running, and it would be a much easier task if I could see how the bootloader works. Another reason I could use the source is that the bootloader that shipped on my Mini+ was v1.1.0, but the binary bootloader downloaded by the build script is an old version v1.0.0; I've already accidentally downgraded and don't have a copy of the v1.1.0 bootloader binary to replace it, let alone the source. I hope they take care of this matter quickly, otherwise it may be necessary to escalate to their legal team, or the great man himself. @JustAnother1 Copy link @JustAnother1 JustAnother1 commented Jun 5, 2021 I used a original BBF file and changed the first 64 Bytes to 0xff. I could not flash that image. I did not see the Developer Firmware message. I have bootloader 1.1.0 and did not break the appendix. Could you share the BBF file that got you to "Developer firmware" ? Regarding Klipper: The bootloader will most probably only shift the start address of the firmware and the address of the Vector table. You can probably get both from the Lionker file used to compile the Prusa Firmware. With those changes it should be possible to put the Klippy Firmware into a BBF file and have it flashed and run as Develeoper firmwware. But the you will need to repeat that with every Klipper update that chenges the firmware,... Or as you have already broken the apendix, jsut use the SWD interface, get rid of the Bootloader and flash the Klipper firmware using SWD. You might want to sdisassemble the display unit and remove the foil from the screen, that will also remove that green thing in the bottom left corner. @matthewlloyd Copy link Author @matthewlloyd matthewlloyd commented Jun 5, 2021 I could not flash that image. That confirms breaking the appendix (or lifting BOOT0 etc.) is still necessary to open things up, even when uploading "Developer firmware". Could you share the BBF file that got you to "Developer firmware" ? Don't have it handy but it was identical to what you created by patching the first 64 bytes. DFU via USB seems more reliable than the stock bootloader (slow and occasionally ignored BBF updates on the USB drive). I added a cable to extend the 2-pin header outside the box, I just add the jumper and reset, then use dfu-util. SWD debugging is working too using OpenOCD. I have Klipper running - bootloader offset was the issue. Foil on the screen is to protect it from the appendix-shaped PCB projectile flying around the room ;) @JustAnother1 Copy link @JustAnother1 JustAnother1 commented Jun 5, 2021 I could not flash that image. That confirms breaking the appendix (or lifting BOOT0 etc.) is still necessary to open things up, even when uploading "Developer firmware". Not so fast. I used a different Bootloader than what you tested with. So it might be a new feature in the 1.1.0 version. They might have changed the Developer Firmware signature to something else or removed the feature completely. You can test if the "appendix" is the issue by connection BOOT0 and SWDIO to GND. That is all the appendix does. Now I also want to see the Source code of the Bootloader,.... @JustAnother1 Copy link @JustAnother1 JustAnother1 commented Jun 7, 2021 * edited @JohnnyDeer What is the Prusa position regarding GPL and the Bootloader? GPLv3 is quite clear on this topic: 1. c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply ... to the whole of the work, and all its parts, regardless of how they are packaged. A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate. The first paragraph clearly applies. Prusa might argue that the combination of the bootloader and the main program is just an aggregate, but the license clearly states that it is not an aggregate if they are combined to form a larger program in or on a storage or distribution medium - and clearly the flash memory of the STM32F407 is a distribution medium. Furthermore, Marlin includes bootloaders, so the Prusa bootloader is "by its nature an extension of the covered work". Can you point us to the Bootloader repository, or does Prusa have a different view on the license terms? @dragomirecky Copy link Member @dragomirecky dragomirecky commented Jun 15, 2021 Hey @matthewlloyd and @JustAnother1, Thank you for your patience regarding this issue. To answer the primary question here: the bootloader is a separate project from the Buddy firmware. The Buddy firmware is in no way dependant on it and is fully functional without it. The bootloader isn't part of the Buddy firmware, and we don't distribute it as part of the BBF files on our website (as mentioned in the first comment). Therefore, we believe that seen from the point of the GPLv3 license, the firmware and the bootloader form an aggregate, and we are not obliged to release the bootloader's source code. In the same way, the license does not require us to open source the source code of the stock bootloader pre-flashed by STMicroelectronics. But hey, that being said, we are planning to open-source the bootloader . Even though it is not a current priority, we are taking steps towards making it eventually happen. So now who will be first to understand how the Developer firmware feature works? Don't want to spoil the fun, but I have to say that there is no hidden "Developer Firmware" feature. The "Developer firmware" string you found in the disassembly appears when the firmware isn't signed. And to flash an unsigned firmware, you have to break the appendix first. So again, no hidden feature here - even all the printers at our offices have broken appendixes. but the binary bootloader downloaded by the build script is an old version v1.0.0; I've already accidentally downgraded and don't have a copy of the v1.1.0 bootloader binary to replace it Thanks for pointing this out! I just made a note to update the bootloader there. 4 [?] 12 @JustAnother1 Copy link @JustAnother1 JustAnother1 commented Jun 15, 2021 Thank you for your patience regarding this issue. To answer the primary question here: the bootloader is a separate project from the Buddy firmware. The Buddy firmware is in no way dependant on it and is fully functional without it. The bootloader isn't part of the Buddy firmware, and we don't distribute it as part of the BBF files on our website (as mentioned in the first comment). Therefore, we believe that seen from the point of the GPLv3 license, the firmware and the bootloader form an aggregate, and we are not obliged to release the bootloader's source code. In the same way, the license does not require us to open source the source code of the stock bootloader pre-flashed by STMicroelectronics. One might argue that the Prusa Bootloader and the Prusa Firmware share the same medium(Flash) but the ST Bootloader is in ROM, but I'm not a lawyer. But hey, that being said, we are planning to open-source the bootloader slightly_smiling_face. Even though it is not a current priority, we are taking steps towards making it eventually happen. It would be great if you could post the link to that (once it happened) here, so that others with the same question can find the link. but the binary bootloader downloaded by the build script is an old version v1.0.0; I've already accidentally downgraded and don't have a copy of the v1.1.0 bootloader binary to replace it Thanks for pointing this out! I just made a note to update the bootloader there. A link to the binary would also be appreciated (for the same reasons). Thank you for looking into this. Like I said before Prusa is opening up so much,also opening up the mechanical (printed) parts of the printer, so not opening up the Bootloader sounded wrong. I'm happy that this will be solved. Keep up the great work! 2 Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment Assignees No one assigned Labels question Projects None yet Milestone No milestone Linked pull requests Successfully merging a pull request may close this issue. None yet 3 participants @JustAnother1 @dragomirecky @matthewlloyd * (c) 2021 GitHub, Inc. * Terms * Privacy * Security * Status * Docs * Contact GitHub * Pricing * API * Training * Blog * About You can't perform that action at this time. You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.