Different bootloader allows smaller non-maple firmwares

[kagebarton]

So I've started hardware modding my Aquila 1.0.1 board. I've replaced the RCT6 with the RET6 chip, and using a bootloader found on an old reddit post and a cheap ST-Link V2 I was able to flash the bootloader onto the blank chip. It booted and flash firmware from the SD card just as expected.

To my surprise, only non-maple firmwares worked, and size-wise they are much smaller than the ones compiled with the maple environment.

I did backup my original RCT6 before replacing it, so I decided to extract the bootloader from it (1st 28k of the backup) and flash it onto the RET6 using the ST-Link. It booted, flashed firmware from SD card, but now only maple firmwares worked.

I'm attaching both bootloaders here in case anyone else want to try this. Maybe the maple dependency was down to the bootloader, and using a different one could let us use much smaller non-maple builds and gain lots of space for features.

bootloaders.zip

[classicrocker883]

this is good news. and would explain why non-maple does not work. funny thing too is on the Creality 427 which uses STM32--RET6, you can flash either or maple/non-maple and it works fine.

so I wonder why that isn't the case on yours. did you use a GD32 or STM32 when swapping chips?

[kagebarton]

I used a GD32F103RET6, didn't know if any of the surrounding pull down resistors or bypass capacitors would be different so I didn't try an STM, or the GD32F303RET6 Creality uses on some boards for that matter.

The one problem I've encountered with the new bootloader is that it has the 230kb size limit baked into it, so it won't flash anything larger from SD. I can still flash larger files directly using ST-Link though (offset 0x08007000) and it works fine.

[Weresk]

this is good news. and would explain why non-maple does not work. funny thing too is on the Creality 427 which uses STM32--RET6, you can flash either or maple/non-maple and it works fine.

so I wonder why that isn't the case on yours. did you use a GD32 or STM32 when swapping chips?

It worked out for me too! The problem was in bootloader. Now i can flash non maple firmware. How to change configs to build non maple firmware?

[classicrocker883]

just go into platform.ini and change default environment (default_envs) to STM32F103RC_creality.

you may need to change MOTHERBOARD to BOARD_CREALITY_V4 because off hand I'm not sure if the one for Aquila accepts the

the thing is this depends on the chip... if it is N32, you may be able to only unlock it's full 512k potential, because what set it apart from GD32 is code within the "maple" directory.

[Weresk]

Thanks, Do library libproui need to be replaced with new ones? As far as I know they are old due to compatibility with maple and we can use gcode view mriscoc's implementation?

[classicrocker883]

if I understand the question, the new libproui library isnt compatible with this because the code (functions names and such) had to remain the same old names.

what did you mean by "use gcode view mriscoc's implementation"? what is that exactly?

[Weresk]

I thought you weren't using new libproui anymore, because mriscoc deprecated maple env last summer. And now then we found solution to use new non maple env we can use new libproui..

[classicrocker883]

youre right I am not using the new libproui, it is still the old one w/ maple env. also, the new libproui has taken much code and stuff away and moved into the new libproui. so those things that I wish to change or edit are not available to. I am actually trying to move away from having that special library altogether if I could. for instance I had to rewrite and rename some code in order so I can work on and fix issues.

the thing is now there is the solution to use non Maple env, but not everyone will be able to perform the fix for a different bootloader.

technically, it is possible to tweak the code enough for the Maple env to work with the new libproui. one main setback which is another reason why I don't do that is the filament runout sensor. for some reason, having that enabled causes that issue.

if you want to know how I did that, using MRiscoC's source code repo - Ender3V2S1-Released, just go into buildroot/share/PlatformIO/scripts/proui.py and add with the similar code

  gd32f10 = _GetMarlinEnv(MarlinEnv, 'MAPLE_STM32F1')

  elif gd32f10:
    arch = 'stm32f1/'
    print ('GD32F1 Architecture detected')

there are a couple other changes elsewhere that need to be done, but this is the start of it.