LeafLabs Garden

A place to share, learn, and grow...

1. 

   Necromant
   Member

   Hello, all.
   I've been playing around with the maple bootloader for some time, using it for my own homebrew hardware and eventually came up with a (massive) retailoring of it.
   Basically, I optimized some parts, sut up a bunch of warnings, moved all the board-specific config and init to separate files, so that adding support for a new board has become much simpler. I also retailored the Makefile from scratch to allow batch building for multiple boards with customization of usb descriptors and other settings per-board.
   My current work, based on the git master branch of maple bootloader can be found here: https://github.com/nekromant/ucboot/
   It is still quite hacky in places, and I'm still cleaning up various things, but it's working. I'm still poking around the code, to see if I can reduce the bootloader size as well. It still looks monsterous, since a usbHID bootloader for avr used to eat up as little as 2KiB, but avr is totally another story and architecture.
   Currently the maple bootloader from gitmaster results in a ~7KiB binary with -Os and no debug. I managed to reduce it to about 5.9 KiB and still want to squeeze more.
   Currently the only supported board is the te-stm32f103ret6kit (maple target should work, but I haven't tested) I had around, but I plan to add support for other boards as soon as I finish with the core stuff.
   Comments welcome.

   Posted 3 years ago #
2. 

   tormod
   Member

   Hi,
   Great initiative, I am sure the bootloader could need some love. Maybe you can base your git tree off the maple git tree so that we can more easily see what you have changed? The "initial commit of the cleaned up stuff" is not the best way to fork off a branch.

   I can imagine there are many fixes in there that would make sense to apply to the current code already without breaking any compatibility. I would suggest you break those out into separate commits so that they can be more easily accepted.

   A question though: If you manage to reduce the size so that the application code can be loaded at a lower address, an application will have to be recompiled for its new position. This will affect any distribution and sharing of binaries across different bootloader versions. I do not know the Maple community and whether this would be any issue, but for many other products and projects it would be troublesome. You could of course add backwards compatibility in your boot loader so that it also looks for an application at the old address.

   Posted 3 years ago #
3. 

   Necromant
   Member

   I did initially start with a fork, but in the end I had to start from scratch, since I didn't yet know what will it look like. At first I wanted to pop in kconfig, I use for my projects, but that was kind-of an overkill for such a project. I'll try to make a cleaner rebase this weekend, then.

   The backwards compatibility is already there. In my tree the app address is set in config.h per-board (actually, each board has a respective config.h usb_descriptors.c and board.c with all the custom stuff), so you can leave that at the old value for all the existing boards, so that noone would temper with it, unless he wants to. This will gives you the desired backwards compatibility automagically.

   You can also try -fpic for the app code, so that it would be position independant. I haven't played much with it, but it should theoretically work.

   P.S. Should the c_only_startup.s derived from medium density devices work on any stm32? I haven't yet done the diffs against the original, but so far hd and md look compatible.

   Posted 3 years ago #
4. 

   Necromant
   Member

   Okay, here it goes rebased upon the maple-bootloader git.
   https://github.com/nekromant/maple-bootloader
   Beware, that the changes are drastical in parts. Some Makefile parts, dealing to flashing the loader are missing, the old Makefile is still backed up as Makefile.old, but it no longer can build the project. I also haven't tried building it on the platforms other then Agilia Linux & FreeBSD.
   I'll merge the flash&debug stuff into the new makefile asap

   Posted 3 years ago #
5. 

   Necromant
   Member

   Ooops, looks like I can't edit older posts. It looks like there's a bug in bootloader, so when compiling with other then -O0, flash upload doesn't work. Somebody forgot that variables accessed in interrupts in dfu.c should be 'volatile'. Fixed in my git tree.

   Posted 3 years ago #
6. 

   mbolivar
   LeafLabs

   this sounds awesome. to say the bootloader could use some love is a drastic understatement; it's great to hear it's been getting some (separating hardware specific parts has been a TODO for so long...). thanks tons for posting and rebasing so we can see the diffs more clearly.

   Posted 3 years ago #
7. 

   Necromant
   Member

   @mbolivar: I also incorporated some more fixes, see merge request at github.
   Right now I'm working on getting my Xilinx Slave Serial Uplaoder driver to work with the DFU, as well as the SPI flash. The latter should be in parts copypaste from ST's USB FS KIT, should get through it in a week or so.

   Posted 3 years ago #
8. 

   mbolivar
   LeafLabs

   Necromant:

   I also incorporated some more fixes, see merge request at github.

   Saw that; thanks for the pull request! I'll set the wheels spinning to get it tested on (all boards) x (all platforms). What's your dev OS, btw?

   Right now I'm working on getting my Xilinx Slave Serial Uplaoder driver to work with the DFU, as well as the SPI flash. The latter should be in parts copypaste from ST's USB FS KIT, should get through it in a week or so.

   Cool, sounds interesting.

   Posted 3 years ago #
9. 

   Necromant
   Member

   Great. Just posted about that to github, and then saw your post here.
   I' using Agilia Linux right now. I've also done some brief testing under FreeBSD, but nothing more than just compiling.
   Windoze compilation if no cygwin installed might require some Makefile adjustments, though, haven't tested that at all.

   You can grab the toolchain I used here: http://up.ncrmnt.org/pub/arm-ncrmnt-eabi-newlib/
   It's made with crosstool-ng, config's embedded. Binaries are for x86 & x86_64 linux. CodeSourcery also works, but I prefer my own one.

   Btw. Do you know why the ST guys suggest setting the vector table address after the jump to the actual app code, and not while in the bootloader? I decided to save a little effort for the app, and put that in the loader code right now. Seems like it's working.

   Posted 3 years ago #
10. 

    mbolivar
    LeafLabs

    You can grab the toolchain I used here: http://up.ncrmnt.org/pub/arm-ncrmnt-eabi-newlib/

    Great; thanks. Grabbing them now.

    Btw. Do you know why the ST guys suggest setting the vector table address after the jump to the actual app code, and not while in the bootloader? I decided to save a little effort for the app, and put that in the loader code right now. Seems like it's working.

    Not sure what you mean -- if you're referring to something the bootloader does, I had basically no hand in writing it; that was done before I joined up with LeafLabs :).

    Posted 3 years ago #
11. 

    Necromant
    Member

    Ah, I see. Then forget it - I'll figure out myself, and post results later.

    Posted 3 years ago #
12. 

    mbolivar
    LeafLabs

    Status update for the forum: we've been emailing back and forth about these patches. Currently they're not working on Maple, at least on my test machine. Necromant conjectures that some optimizations may be failing when the board is plugged into a USB 2.0 hub. More information as it happens.

    Posted 3 years ago #
13. 

    mbolivar
    LeafLabs

    Also, tormod is right about this:

    I can imagine there are many fixes in there that would make sense to apply to the current code already without breaking any compatibility. I would suggest you break those out into separate commits so that they can be more easily accepted.

    We're (LeafLabs) excited about where this is going, but it's likely going to take a while to get this merged, as the patches are pretty raw right now.

    Posted 3 years ago #
14. 

    Necromant
    Member

    mbolivar pointed some issues regarding the maple boards, so I got myself something that looks and works like maple-ret6, and I'm in the process of testing it out.
    Currently, at my github there are 2 branches. master and 'uberstable'
    'uberstable' should be working now all the time, at least on most boards, see status matrix I've added. Master can and will have a lot of weird stuff happening around, so expect it to be broken quite often.
    If you are feeling adventurous enough, grab a copy and post the results, that will help a lot.

    Posted 3 years ago #
15. 

    tormod
    Member

    For fresh, ready-to-use toolchains, look no further: https://launchpad.net/gcc-arm-embedded

    mbolivar, I just noticed many things are cleaned up in the mini-boot branch but not in the master branch. Notably the per-board configuration is cleanly separated in mini-boot. I'd suggest you merge those changes into master as a first step in unifying all these different branches - the current situation is proof that multiple branches is not maintainable. Some #ifdef MAPLE_MINI and MAPLE_RET6 etc in config.h would be better.

    Well, unless you gonna jump directly to Necromant's version...

    Posted 3 years ago #

RSS feed for this topic

Reply »

You must log in to post.