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?

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.

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.

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.

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 ;)

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,....

@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?

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.

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!

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).

Here it is :) #1482

Many thanks to Prusa for replying to this thread.

we don’t distribute it as part of the BBF files on our website

I stand corrected, and agree that the bootloader is not distributed in the BBF downloaded from Prusa's website. It is, however, distributed on the board's flash. It is also clearly intended to be linked with it as part of the process in utils/build.py.

The Buddy firmware is in no way dependant on it and is fully functional without it... the firmware and the bootloader form an aggregate.

This is not entirely accurate. The bootloader and Buddy firmware communicate bidirectionally via shared memory. Using shared memory to communicate is generally considered dynamic linking, which does make programs a combined work.

We can only see one side of the communication since the bootloader is closed source. At the very least we can see that the firmware communicates update mode flags (set via the GUI menu) to the bootloader, and the bootloader communicates the status of the appendix to the firmware. Perhaps there is more. Here are some code excerpts:

https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/master/src/common/shared_config.h

typedef struct {
    uint8_t fw_update_flag;
    uint8_t model_specific_flags; // ~ "reserved1" originally
    ...
} data_exchange_t;

 /* to exchnage data between bootloader and application */
 /* this section is filled with zeros on each application start */
  .boot_fw_data_exchange 0x20000000 :
  {
  	_sboot_fw_data_exchange = .;  /* global symbol at start */
    KEEP (*(.boot_fw_data_exchange))
    . = ALIGN(4); /* allignment is important as 4 bytes are written to zero at once in startup code*/
    _eboot_fw_data_exchange = .;  /* global symbol at the end */
  } >RAM AT> FLASH /* AT> FLASH added to avoid the binary size increase*/

bool appendix_exist() {
    const version_t *bootloader = (const version_t *)BOOTLOADER_VERSION_ADDRESS;

    if (bootloader->major >= 1 && bootloader->minor >= 1) {
        return !(ram_data_exchange.model_specific_flags & APPENDIX_FLAG_MASK);
    } else {
    ...

void sys_fw_update_on_restart_enable(void) {
    ram_data_exchange.fw_update_flag = FW_UPDATE_ENABLE;
}

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.

This is very good to hear. I do hope given the above, that Prusa honors the open source community and respects the terms of Marlin's GPLv3 by releasing the source code for the dynamically linked bootloader as soon as is reasonably possible.

Here it is :) #1482

Fantastic - thank you so much for uploading the latest version. We are all very excited about the upcoming release of the i3 MK4 and XL.

@matthewlloyd what you describe only applies, if the dynamically linked software is under gpl license. then you are correct, the linking software has also to comply with the gpl.

the other way around makes no sense whatsoever, because it would leave people unable to dynamically link non gpl libraries in their gpl projects.

i can not force, say microsoft, to open source their proprietary library by dynamically linking it in my gpl project, you see my point, right?

i can not force, say microsoft, to open source their proprietary library by dynamically linking it in my gpl project, you see my point, right?

The GPL specifically carves out an exception for "System Libraries", which applies for example to Microsoft's proprietary libraries, but does not apply here because a bootloader with bidirectional communication via shared memory does not meet the definition of a System Library. You can read the GPL FAQ here for more information: https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException.

The incorrect assertions in the rest of your comment are addressed in the GPL FAQ here, and in other places: https://www.gnu.org/licenses/gpl-faq.html#MoneyGuzzlerInc. In short, the GPL does not allow GPL-covered software to be linked (dynamically or otherwise) with closed source libraries, except for the System LIbrary exception as described above, and for aggregates, which this is not (see https://www.gnu.org/licenses/gpl-faq.html#MereAggregation).

Why is the source code for the bootloader such a big deal? It's a simple piece of software and obviously doing nothing magic with the printer.

Speculating, there are a plethora of reasons why Prusa at the moment can't (or would not like) to make the source public. For instance, all comments are written in Czech, or symbol names might not be "suitable" for the public eyes or simply lack of resources/priority issue. It's no point releasing the software to the public if it not has been cleaned up and reviewed, otherwise some one would start whine about the code look like garbage or is incomprehensible.

Ask your self, would you like Prusa to spend time on making the bootloader public or spend time acting on the bug reports on the actual printer FW. My stance is clear, bootloader seems rock solid, but the printer FW do need some extra attention. I do understand the idea behind free and open source software. But on this case, the software in question is not critical for the function of the hardware and does not restrict its usability.

To make it clear, my sole relation with Prusa is as a customer and I do hate closed source. Even though my bread and butter work is with closed source on embedded devices (like bootloaders...).

@ekholm I agree the source code for the bootloader is not a big deal. The bigger deal is why prusa thinks they need to keep it a secret.

This issue was opened in 2021. Therefore being busy right now can not be the reason for not open sourcing the code.

If they can release the firmware code and it is not in Czech or otherwise unrepresentative, then why should the bootloader code be.

Open sourcing the bootloader takes less them 5 minutes. They have the code all they need to do is a git push.

But you are also wrong. The bootloader is critical for the function of the hardware and it restricts its usability.

Also @CZDanol message implies they have a valid reason that is a secret.

For people that want to take a look: here is the disassembly of the mini 2.3.5 bootloader:

bootloader.s.zip

Using strings bootloader.bin on the file that @CZDanol linked you can find these strings:

Unable to verify the extruder type, check the wiring and connectors.

That is a bit scary. It sounds like they now also want to somehow link the extruders to the hardware ( Error messages for the wrong version of buddy board or the wrong printer are also in there). Or maybe future Extruders need signed Firmware updates?

Erasing XFLASH & EEPROM

I guess that "XFLASH" is an external Flash. Did not know they needed/used that.

assertion "%s" failed: file "%s", line %d%s%s

Hey they use assertions in production code. Good to know.

/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/src/newlib/newlib/libc/stdlib/mprec.c

And they use Jenkins on a Linux (Mac?) system. With gcc 10. And compiled the bootloader in 2021on October 18th. I hope they do more than a build server, but have many unit tests running there also. Do not know why they need to flash this information to every-bodies printers though.

Using hexdump -C -v bootloader.bin shows that there is a lot of empty space in the file. So maybe they are ashamed of their bootloader code?

Also this bootloader seems to be Mini specific. In the old version, we looked at, the name of the XL leaked. In this there is no reference to the XL. But this extruder type check error message,...

Unable to verify the extruder type, check the wiring and connectors.

This is nothing scary or secret, it is an error publicly documented in our knowledge base.

Now, the particular reason why bootloader needs to communicate with loveboard is to distinguish between MK3.5 and MK3.9/MK4 in order to disallow flashing mismatching firmware. Those printers share the same hardware (xbuddy board). Arguably, this string should not be present in the bootloader, but since all our bootloaders share the same codebase and we don't have LTO enabled yet, it is present in the binary.

I guess that "XFLASH" is an external Flash. Did not know they needed/used that.

XFLASH is indeed external flash which, as documented on our opensource page is indeed present on all our boards. STM32F4 platform only contains 2MB of FLASH (1MB of FLASH in case of MINI) so without XFLASH, there won't be any space for fonts, images, firmware for ESP Wi-Fi add-on, daughterboards on XL etc. All of this is public information and could be inferred directly by reading the documentation or the firmware source code.

/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/src/newlib/newlib/libc/stdlib/mprec.c

We are linking again standard arm toolchain, like we do in the firmware. Strings you are seeing come from their buildsystem and their build of newlib.

Using hexdump -C -v bootloader.bin shows that there is a lot of empty space in the file. So maybe they are ashamed of their bootloader code?

I don't understand why "empty space in the file" would be considered something to be ashamed of. That being said, there are some aspects of the codebase, mainly related to coding style, which could be improved.

Open sourcing the bootloader takes less them 5 minutes. They have the code all they need to do is a git push.

Reiterating on what was already told, opening the bootloader is not a decision I am allowed to make, although I would like it much more then answering questions like this on github 😫

Just dropping in to say that my offer to assist with open-sourcing the bootloader still stands- I'm the president of the Open Source Hardware Association and highly experienced in helping organizations take proprietary code through the process of publishing it under open source licenses. I'd be happy to listen to the concerns of Prusa's stakeholders and present a publication plan that addresses those as well as assist in any modifications needed to get the codebase into a publishable state.

Just dropping in to say that my offer to assist with open-sourcing the bootloader still stands- I'm the president of the Open Source Hardware Association and highly experienced in helping organizations take proprietary code through the process of publishing it under open source licenses. I'd be happy to listen to the concerns of Prusa's stakeholders and present a publication plan that addresses those as well as assist in any modifications needed to get the codebase into a publishable state.

...and I could pitch in some hours to do any required code reviewing or coding leg-work.

I looked into the disassembly and I now think I understand why open sourcing is such a big issue.

They have probably used some kind of Tool / Framework to write the bootloader. It is not just a pure C project like the Firmware.

If you look into the bootloader.bin file (or my posted disassembly) you will see that the it starts out with what seems to be a Vector Table followed by normal code. But that ends at address 0x30f. (that is very little code) Then a lot of 0x00 until 0x4000.(a big gap) At address 0x13160 we have 15 Strings that are fixed length of 150 bytes. With the 15th being strange. In other places we have the normal C style strings (0 terminated). Starting at address 0x1d160 for example.

In these sections there is something that should be normal code but is not only code:
0x4000 - 0x130bf
0x13ad0 - 0x1d169
0x13eda - 0x1dee6

Whatever is in these sections only partly can be de-compiled(illegal registers used or unknown instructions). It probably has some data mixed in or is encrypted.

At the very end there is a CRC and "2.3.5"(at address 0x1fffa) as ASCII. And that is basically it, the rest is 0x00.

So they most probably used some commercial proprietary tool that generated this mess. And that is the reason they can not open source it.

They probably thought that they could not do it themselves (with the crypto and not wanting to update the booloader all the time) and therefore went that route. Probably made financial sense to pay the tool vendor instead of programming it themselves.

And maybe we should have a discussion if open source vendors should be allowed to do such a thing. But to kick of that discussion Prusa would need to confess to doing it. Without that we just have the missing bootloader code as proof that Prusa printers are not open source, case closed!

@danopernis

STM32F4 platform only contains 2MB of FLASH (1MB of FLASH in case of MINI) so without XFLASH, there won't be any space for

but also

I don't understand why "empty space in the file" would be considered something to be ashamed of.

Maybe less empty space would make more functionality fit? And no XFLASH or a smaller XFLASh would make the board cheaper and would therefore allow for a cheaper or better printer.

@ekholm @theacodes I will bring this to internal meetings with some folks with more power/responsibility, but can't promise anything. I am sure you understand how difficult those tasks can be. Your willingness to help is much appreciated, at least by me personally.

@JustAnother1 sorry I am not reacting to you anymore. I wanted to provide some information for you in good faith but clearly I am just wasting my time here. You clearly lack expertise in embedded software engineering and reverse engineering, as any expert in the field would confirm. Being surprised about parts of the binary image containing data, not only executable code (as already told, there are fonts and keys to verify firmware signature in the firmware), expressing concerns about "empty space" (yes, zeroes may have their meaning even when they look empty to you), being surprised that not all strings are zero-terminated, making wild theories about "generated code" by some mysterious "tool vendor"...

I am willing to answer any meaningful questions, but this is just wasting time unfortunately.

To reiterate, bootloader is not open source at the moment, firmware is open source. Bootloader code is not required for modifying the firmware. Either you can remove "appendix" and let the bootloader flash your unsigned modified firmware, or you can build the firmware in the "noboot" preset and overwrite the entire FLASH. The sole task of the bootloader is to prevent flashing unsigned firmware. If you want to, you can lift the hood and do whatever you want to the printer.

I will bring this to internal meetings with some folks with more power/responsibility, but can't promise anything. I am sure you understand how difficult those tasks can be. Your willingness to help is much appreciated, at least by me personally.

Thank you! I'd spoken to Josef about it previously, but it's been quite a while and I think I remember him dealing with a new child at the time, so no worries.

Hi,
you do quite a lot of speculation....

I would be suprised if Prusa is using a commercial tool to create the bootloader. It's such a simple piece of software.
One thing that you absolutely want to avoid is to run out of space of the bootloader section. Unless you are really tight in space you would want some gap in between the bootloader and application code. So that you can upgrade the bootloader with a larger one if need be down the road.

It's not strange to have "unknown instructions" embedded in the code. A normal switch statement in C might end up as a jump table in the assembly.

Some speculation of my own, maybe they have sections in the bootloader section containing some minmal code and data to show on the display if external flash for some reason is not available. Then you might divide the bootloader section into chuncks continaing bootloader code, graphical data, etc Which would inevitable be some gaps between those sections.
Another reason for big gaps would be to have the possibility to install a new bootloader whilst preserving the old one if installation fails.

I don't know how large the external flash is, but firmware for the other boards as well as language translations, and graphics takes a lot of space. So even if the bootloader was not present at all, I doubt that the exernal flash could have been removed.

Just because you don't understand the layout or the code it does not mean that Prusa is doing some anything malicious.

br

I looked into the disassembly and I now think I understand why open sourcing is such a big issue.

They have probably used some kind of Tool / Framework to write the bootloader. It is not just a pure C project like the Firmware.

If you look into the bootloader.bin file (or my posted disassembly) you will see that the it starts out with what seems to be a Vector Table followed by normal code. But that ends at address 0x30f. (that is very little code) Then a lot of 0x00 until 0x4000.(a big gap) At address 0x13160 we have 15 Strings that are fixed length of 150 bytes. With the 15th being strange. In other places we have the normal C style strings (0 terminated). Starting at address 0x1d160 for example.

In these sections there is something that should be normal code but is not only code: 0x4000 - 0x130bf 0x13ad0 - 0x1d169 0x13eda - 0x1dee6

Whatever is in these sections only partly can be de-compiled(illegal registers used or unknown instructions). It probably has some data mixed in or is encrypted.

At the very end there is a CRC and "2.3.5"(at address 0x1fffa) as ASCII. And that is basically it, the rest is 0x00.

So they most probably used some commercial proprietary tool that generated this mess. And that is the reason they can not open source it.

They probably thought that they could not do it themselves (with the crypto and not wanting to update the booloader all the time) and therefore went that route. Probably made financial sense to pay the tool vendor instead of programming it themselves.

And maybe we should have a discussion if open source vendors should be allowed to do such a thing. But to kick of that discussion Prusa would need to confess to doing it. Without that we just have the missing bootloader code as proof that Prusa printers are not open source, case closed!

@danopernis

STM32F4 platform only contains 2MB of FLASH (1MB of FLASH in case of MINI) so without XFLASH, there won't be any space for

but also

I don't understand why "empty space in the file" would be considered something to be ashamed of.

Maybe less empty space would make more functionality fit? And no XFLASH or a smaller XFLASh would make the board cheaper and would therefore allow for a cheaper or better printer.

Thank you for your contribution to our project. This issue has not received any updates for 60 days and may be considered "stale." If this issue is still important to you, please add an update within the next 7 days to keep it open. Administrators can manually reopen the issue if necessary.