Allow to build the skr mini with STM32F103R(E) env

[tpruvot]

Some recent SKR Mini boards are shipped with a STM32F103RET6 SoC (512kb)
instead of the RCT6 (256k)

It can be built with the "STM32F103R" env which is made for the 512k RE

[tpruvot]

maybe this env entry should be renamed to STM32F103RE

[thinkyhead]

I've added a commit renaming everything with STM32F103RE or other prefix, as appropriate.

[saeugetier]

The bootloader on the Mini E3 does a range check. Updating the firmware via SD card and bootloader doesn't work with stock configuration, if binary is bigger than 234kb. The binary can only be flashed via Debugger or patched bootloader. Patching the bootloader is quite easy: the flash comes with no memory protection. You have to find the value 0x08004000 in the first 28kb of flash and change the value to 0x08008000.

[looxonline]

@saeugetier have you tested the patch? Thinking of using openOCD with a Rpi to patch but I'm always nervous to be the test dummy with a bootloader.

[saeugetier]

@looxonline yes. The patch is tested.

The update via SD card of larger binaries works. I have loaded the content of the flash and did a binary comparision with the compiled binary. Both contents are the same.

I analyzed the bootloader with radare2. I figured out that both values 0x08000700 and 0x08004000 are hardcoded in the bootloader. Both values are used nearby. I think I found a substraction. I don't remember quite well. But the change seemed logical to me. I looked for same check sum calculation, but I found none. That's why I did the binary comparison, in order to check whether any value is written into flash and overwriting contents of the firmware.

The bootloader might change. So patching the bootloader via OpenOCD might be quite dangerous. What do you think?

[looxonline]

@saeugetier What tool did you use to write the patch to the bootloader? Was it just the standard STM32 debugger?

I suppose one option is to write some custom application that patches the bootloader from normal program code space which would theoretically work if the flash is not protected and be the most user friendly for people who are not familiar with debugging tools but it does run the risk of soft bricking the board if something goes wrong during the write.

[saeugetier]

@looxonline I used the J-Link Debugger probe for downloading and uploading the flash. But with use of OpenOCD mostly every debug adapter can be used.

One option would be checking the checksum of the bootloader. If the checksum matches, the bootloader will be patched. The binary patching was done via radare2. But as the address of the value is known, a bash or python script may be used.

[looxonline]

@saeugetier So when you changed the value of 0x08004000 to 0x08008000 surely you also needed to adjust the checksum? I assumed that value resides within the bootloader code area.

Just to be sure that we are on the same page here is my understanding:
1.) There is a range check built into the E3 bootloader which rejects any binary on the SD card that is larger than 234kB.
2.) You found the bytes in the bootloader which define the size of the file for the range check. Changing 0x08004000 to 0x08008000 causes the bootloader to compare against file sizes that can fit on the 512k part.
3.) You were able to patch this part of flash by writing directly to it using your debug tool. Here is where I am not 100% sure on what you did. Did you read the entire bootloader out of flash, modify it locally and then write it back using the debug tool?
4.) Depending on what you did in the above step, did you need to re-calculate the checksum for the bootloader after you made the changes or did the tool that you use (radare2) automatically re-calculate the checksum?
5.) If you have already patched the bootloader and have a binary would you be able to make it available so that we can just program it directly using a debugger?

[saeugetier]

@looxonline there is no checksum in memory, which has to be modified. Only the variable for size check has to be updated.

1.) There is a range check in the bootloader refusing to flash an application bigger than 256kb - 28kb. I first wrote 234kb (which is wrong), the size constraint is 228kb.
2.) Yes
3.) I first extracted the content of the first 28kb flash. With the tool radare2 i searched for the position of 0x08004000 in memory. Then I replaced it with 0x08008000, This variable is used for range check. After replacing the value, the bootloader accepts binaries greater than 228kb. Replacing the value is not limited to the tool radare2. It can be done via other tools.
4.) The checksum over the first 28kb of flash can be used to detect both: The unmodified and modified bootloader. The bootloader is not used by the bootloader. It is used just for detecting a modifieable bootloader. No checksum in flash memory is involved.
5.) I'm not sure, if I am allowed to redistribute the binary file of the bootloader. Does anybody know, whether it is legal to distribute the modified bootloader? I asked Bigtreetech for the bootloader code. But they said that they cannot share it with me.

[looxonline]

OK. We are 100% on the same page.

I do worry that if the average user tries to patch their bootloader then there will be some soft bricked boards. I really like the idea of a special binary for the E3 which is designed to boot, check whether the bootloader has already been modified (using the checksum), modify it if it has not and then simply flash an LED so that the user can see that the process was successful. Once it has been modified the user can load a Marlin binary back onto the SD card and the bootloader will flash it. In this way users don't have to be concerned with debugging tools.

Maybe the "special" binary could also check if the part supports 512k but there would need to be a readable fuse within the MCU that indicates the model.

I'll see what is involved in writing this simple binary and try to push something out this weekend. In the meanwhile I will see if I can write to flash using OpenOCD and a raspberry pi over the SWD interface since these are the tools that most users have available to them.

[saeugetier]

I like the idea of an special binary, which patches the bootloader. I think this will not be too difficult to develop. Would be the easiest way to patch the bootloader even for unexperienced users.

[saeugetier]

If you need more information about the patching process, I can help you.

[looxonline]

I guess my only question is about the process to write to flash. From past experience I have found that on most MCUs individual bits can only be reset in flash (0) but not set (1). To set bits generally a block needs to be erased. This is confirmed by the flash writing process for the STM32F103 at https://www.st.com/content/ccc/resource/technical/document/programming_manual/10/98/e8/d4/2b/51/4b/f5/CD00283419.pdf/files/CD00283419.pdf/jcr:content/translations/en.CD00283419.pdf on page 14.

Changing 0x08004000 to 0x08008000 means that we need to reset one bit in the lower half-word and set a bit (MSB) in the same half-word. In order to set this bit surely that whole page needs to be erased first? If we are erasing the whole page then we would need to copy the contents into a RAM buffer, modify the value, erase the page and then write the contents back to that page. I cannot see a way of achieving the patch without going through this process. Is it possible that your radare2 tool does this process automatically?

[saeugetier]

@looxonline flash can only erased page by page. So content has to be stored to RAM before writing the modified content. You can use the HAL library from CubeMX. I have no experience with the arduino library for STM32.

Radare2 is a reverse engineering and analysis tool for the host computer. You cannot run it on the microcontroller. Radare2 can be scripted. So the binary patching process can be automated. But you will still need a connection between the microcontroller and debugger probe.

[sl1pkn07]

Hi @saeugetier, can you share the commands you use for patch the bootloader?

or is more a graphical than CLI process

greetings

[sl1pkn07]

any update about this? is safe to distribute a Xdelta file with the changes for patch the bootloader?

[saeugetier]

It seems that newer versions of the SKR Mini E3 boards ships with the smaller version STM32F103RC. So it is not safe in general.

Providing a manual for things to do with radare2, would be easier for me. I don't know any tools for xdelta. The solution with the xdelta may be costier.

[thinkyhead]

It seems that newer versions of the SKR Mini E3 boards ships with the smaller version STM32F103RC

What is your source for this information?

[saeugetier]

I saw some statement, that the newer version V1.2 often ships with the 256kb version. And I saw about it in the feedback of one order. If you look on the photos in feedbacks on aliexpress, you will see some photos with the RC. Maybe there is no rule and they just ship randomly sized chips on the board. I'm just waiting for my order with the SKR Mini E3 V1.2. So I cannot say what size it will have.

I don't know the current state. As this video shows, there might be no boot loader protection on the board at all.

I had no luck with uploading bigger binaries for the SKR Mini E3 V1.0. In my case there was a restriction of application file size. So I had to patch the bootloader. So there might be some changes in the whole design. The bootloader may develop.

[saeugetier]

Link to proofing image: https://ae01.alicdn.com/kf/U9f77192ff2b0444ca6c91d2b19929a834.jpg

[tpruvot]

please move to #15890, this PR is closed... the last fact is... even the RCT6 can use 512KB... :p

[looxonline]

There is no boot loader protection. The statement that there is was false. There is a pull request waiting to make 512k the default size since even the RC has512k even though the data sheet says 256k. Warm regards, Luke Harrison.

…

Sent from my iPhone

On 15 Nov 2019, at 14:31, Timm ***@***.***> wrote:  I saw some statement, that the newer version V1.2 often ships with the 256kb version. And I saw about it in the feedback of one order. If you look on the photos in feedbacks on aliexpress, you will see some photos with the RC. Maybe there is no rule and they just ship randomly sized chips on the board. I'm just waiting for my order with the SKR Mini E3 V1.2. So I cannot say what size it will have. I don't know the current state. As this video shows, there might be no boot loader protection on the board at all. I had no luck with uploading bigger binaries for the SKR Mini E3 V1.0. In my case there was a restriction of application file size. So I had to patch the bootloader. So there might be some changes in the whole design. The bootloader may develop. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[saeugetier]

There is no boot loader protection. The statement that there is was false.
There was.
Simple test:

1. Unmodified SKR Mini E3: Binary is bigger than >256kb-28kb. SKR Mini E3 doesn't update.
2. Patched SKR Mini E3: Same SD card, same files. SKR Mini E3 updates.
   There might be changes. As the manufacturer doesn't provide any change logs. So we cannot say, what version you have. If it works for you, you had luck.

There is a pull request waiting to make 512k the default size since even the RC has512k even though the data sheet says 256k.

Same again. If it works for you, you had luck. Even though, the label says it is an RC, the silicon inside might be an RE. But it is not guaranteed to be an RE.
Logistics and testing are a big part of chip manufacturers cost. So often the manufacturer places a "bigger" silicon into a device with the labeling of a smaller part, in order to save costs. But there is no guarantee that the part has a bigger flash. So it depends on which batch you received. And as I know it from ST, there are different silicons with different sizes of flash.

In the end, it is important, what does it mean to you: You can try to compile Marlin for the RE version. When the binary doesn't fit into flash memory, it will be truncated. The binary might run. Maybe you will notice after a certain time, that Marlin will crash.

In my opinion, the discussion can be closed.