search

devanlai / dapboot

DFU Bootloader for STM32 chips
Other
337 stars 111 forks source link

GD32F30x support #35

Closed obra closed 3 years ago

obra commented 3 years ago

I'm strongly leaning toward using dapboot for our new keyboard built around a GD32F303. Based on all available documentation, the GD32F303 is, essentially, a GD32F103, but with a Cortex M4, more flash, and more RAM. And so, in theory, should be pretty straightforward for dapboot to support.

It appears that we'd want GD32F303 support for opencm3. It also appears that https://github.com/nanovna/libopencm3-gd32f3/ has already done that work in their OpenOCD fork. It also looks like upstream rejected a PR to add that implementation.

Before I go off and potentially do something ill-advised, @devanlai, do you have any sage advice?

devanlai commented 3 years ago

Hi @obra,

First, I'm flattered that you're considering using dapboot as a bootloader, but I would feel remiss if I didn't mention that it looks like the GD32F303 probably also has a builtin ROM bootloader that works over USB - probably using ST's DfuSe protocol.

It's often possible to jump to the ROM bootloader from your main application, which gets you almost all of the benefits of using a custom bootloader for almost no effort. The user experience might be a little worse with the ROM bootloader since you can't customize the product strings or provide MS OS descriptors to do the magic WinUSB driver installation, but it's a fairly common compromise.

Second, I don't have any experience with GD32 parts, but I see that for the stm32duino bootloader, the GD32F103 port config looks like it's not doing anything special for GD32 vs STM32.

From my recollection, GD32 support in libopencm3 has been rejected in the past mostly because it involved a lot of duplicated code that would require most future STM32 changes to be manually duplicated for GD32 and then retested. I think if you wanted to get GD32 support upstreamed, it would be a great service to the community, but it would also involve quite a bit of back-and-forth refactoring and cleanup to get it to the point where it would be accepted.

Personally, if I were trying to port a bootloader to the GD32, I would probably just make a fork using nanovna's gd32 port of libopencm32 and not lose any sleep over whether there's a path back to the mainline. Bootloaders typically aren't growing new features every week and it's standard practice for applications based on libopencm3 to pin the specific fork/version using submodules anyways.

obra commented 3 years ago

<3 for the quick and comprehensive answer.

Sadly, the GD32F303 is specced as only supporting DFU over USART. We'd have to go up to the F305 before we got a vendor USB DFU bootloader. (And I agree 100% with your assessment of the tradeoffs. I might still end up with our own bootloader, just so we could provide a better user experience while flashing, but I'd not really be weating it.)

GD32 support in libopencm3 has been rejected in the past mostly because it involved a lot of duplicated code

That matches what I'm seeing. If we end up using the chip for more projects, it may indeed be worth the effort to upstream stuff.

Thanks!

it's standard practice for applications based on libopencm3 to pin the specific fork/version using submodules anyways

That's fantastically useful context and information.