search

devanlai / dapboot

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

Add STM32L1 support #27

Closed karlp closed 4 years ago

karlp commented 4 years ago

now I've just got to get more usb functions into upstream locm3 :)

devanlai commented 4 years ago

These changes mostly look sane to me, though I don't have any L1 series hardware to test with. I do see when building that there's a warning about .data.ramfunctions, that's a little suspicious:

make V=1
...

arm-none-eabi-gcc -flto -Os -g --static -nostartfiles -specs=nano.specs -L../libopencm3/lib -T./stm32l1/stm32l1-standard.ld -Wl,-Map=dapboot.map -Wl,--gc-sections -mthumb -mcpu=cortex-m3 -msoft-float -mfix-cortex-m3-ldrd ./stm32l1/backup.o ./stm32l1/target_stm32l1.o dapboot.o dfu.o dummy.o usb_conf.o webusb.o winusb.o -lopencm3_stm32l1 -Wl,--start-group -lc -lgcc -lnosys -Wl,--end-group -o dapboot.elf
/tmp/cc5JW4GC.s: Assembler messages:
/tmp/cc5JW4GC.s:14: Warning: setting incorrect section attributes for .data.ramfunctions

Unfortunately, I'm not sure how to get at the temporary assembler file to see exactly what gcc is doing, but it probably relates to the special section attributes for flash_program_half_page(). For reference, I'm using GCC ARM 9-2019-q4-major 9.2.1 20191025.

karlp commented 4 years ago

Yeah, the assembly warnings are from the ram sections, and LTO being.... precious. GCC doesn't consider it a bug and I can't find any method of killing the warning. (other than removing LTO, which works, but... not ideal of course) Without the full set of attributes, LTO just lumps it into .text. (And then you get an assembler warning about the section being changed, if you have enough warnings)

shrugs To me this is just "LTO is teh suck" but that's not really a very effective way of moving forward on it. (bright side, warning is only for anyone building on L1?)

devanlai commented 4 years ago

Well, if you're satisfied with it for L1, that's good enough for me. (It looks like all of the L1 parts that have USB but not the ROM USB DfuSe bootloader are all NRND, so I'm not too worried about linker warnings for L1 only).

karlp commented 4 years ago

All the Low/Medium density -A parts, (STM32L151xx/6/8/B-A) are still active, with no Dfuse bootloader. the original (non-A) parts are indeed NRND, but they've just been replaced with the -A suffices. (More ram, fixed usb pull ups, less eeprom endurance)

karlp commented 4 years ago

There's a note in the third commit, that is kinda important actually,

"First, this requires c6e89adda836a98fc from upstream, which fixes flash unlocking added to the libopencm3 portion."

I didn't know what the best way of getting that into your local fork was though, but it's absolutely required for the l1 flash to work

devanlai commented 4 years ago

Oh, I missed that commit message. When I find some time, I can rebase a new fork with the winusb patches targetting the latest libopencm3 that should bring things up-to-date for the most part.

karlp commented 4 years ago

I'm hoping to use this to get the winusb stuff into upstream as well, and can then help forward porting the whole lot

devanlai commented 4 years ago

I've rebased my fork to bring it up to date with the latest locm3 master, so hopefully the STM32L1 target should work now, though I don't have any hardware to test it with.

I cleaned up the WinUSB string descriptor change and the USB 2.1 BOS changes a little bit while I was at it, though I'd have to deliberate a little more on whether the BOS changes make sense in the core USB stack or not.