http://forums.leaflabs.com/topic.php?id=1847 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:16:34 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=1847&page=2#post-11676 Tue, 10 Jul 2012 17:50:16 +0000 mbolivar 11676@http://forums.leaflabs.com/ <blockquote><p> the current situation is proof that multiple branches is not maintainable </p></blockquote> <p>as if we needed more proof ;). yes, we know we botched the bootloader, and we're very, very sorry.</p> <p>i'd like to use necromant's, but it's been tougher to read over the patches since there are so many huge commits, and other jobs struck which kept me from paying enough attention to this. given that, i think what i'm going to do is just treat it as a new program and read the sources from the top of the tree. after that, yes, i'll probably just end up replacing the contents of our repo with his in a single giant merge. </p> http://forums.leaflabs.com/topic.php?id=1847#post-11672 Tue, 10 Jul 2012 16:14:59 +0000 tormod 11672@http://forums.leaflabs.com/ <p>For fresh, ready-to-use toolchains, look no further: <a href="https://launchpad.net/gcc-arm-embedded" rel="nofollow">https://launchpad.net/gcc-arm-embedded</a></p> <p>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.</p> <p>Well, unless you gonna jump directly to Necromant's version... </p> http://forums.leaflabs.com/topic.php?id=1847#post-11185 Sat, 09 Jun 2012 14:25:32 +0000 Necromant 11185@http://forums.leaflabs.com/ <p>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.<br /> Currently, at my github there are 2 branches. master and 'uberstable'<br /> '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.<br /> If you are feeling adventurous enough, grab a copy and post the results, that will help a lot. </p> http://forums.leaflabs.com/topic.php?id=1847#post-11178 Fri, 08 Jun 2012 19:13:15 +0000 mbolivar 11178@http://forums.leaflabs.com/ <p>Also, tormod is right about this:</p> <blockquote><p> 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. </p></blockquote> <p>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. </p> http://forums.leaflabs.com/topic.php?id=1847#post-11177 Fri, 08 Jun 2012 18:59:51 +0000 mbolivar 11177@http://forums.leaflabs.com/ <p>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. </p> http://forums.leaflabs.com/topic.php?id=1847#post-11128 Thu, 07 Jun 2012 05:46:03 +0000 Necromant 11128@http://forums.leaflabs.com/ <p>Ah, I see. Then forget it - I'll figure out myself, and post results later. </p> http://forums.leaflabs.com/topic.php?id=1847#post-11127 Thu, 07 Jun 2012 05:35:15 +0000 mbolivar 11127@http://forums.leaflabs.com/ <blockquote><p> You can grab the toolchain I used here: <a href="http://up.ncrmnt.org/pub/arm-ncrmnt-eabi-newlib/" rel="nofollow">http://up.ncrmnt.org/pub/arm-ncrmnt-eabi-newlib/</a> </p></blockquote> <p>Great; thanks. Grabbing them now.</p> <blockquote><p> 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. </p></blockquote> <p>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 :). </p> http://forums.leaflabs.com/topic.php?id=1847#post-11126 Thu, 07 Jun 2012 05:25:00 +0000 Necromant 11126@http://forums.leaflabs.com/ <p>Great. Just posted about that to github, and then saw your post here.<br /> I' using Agilia Linux right now. I've also done some brief testing under FreeBSD, but nothing more than just compiling.<br /> Windoze compilation if no cygwin installed might require some Makefile adjustments, though, haven't tested that at all.</p> <p>You can grab the toolchain I used here: <a href="http://up.ncrmnt.org/pub/arm-ncrmnt-eabi-newlib/" rel="nofollow">http://up.ncrmnt.org/pub/arm-ncrmnt-eabi-newlib/</a><br /> It's made with crosstool-ng, config's embedded. Binaries are for x86 &amp; x86_64 linux. CodeSourcery also works, but I prefer my own one. </p> <p>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. </p> http://forums.leaflabs.com/topic.php?id=1847#post-11124 Thu, 07 Jun 2012 04:59:23 +0000 mbolivar 11124@http://forums.leaflabs.com/ <p>Necromant:</p> <blockquote><p> I also incorporated some more fixes, see merge request at github. </p></blockquote> <p>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?</p> <blockquote><p> 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. </p></blockquote> <p>Cool, sounds interesting. </p> http://forums.leaflabs.com/topic.php?id=1847#post-11103 Wed, 06 Jun 2012 08:28:02 +0000 Necromant 11103@http://forums.leaflabs.com/ <p>@mbolivar: I also incorporated some more fixes, see merge request at github.<br /> 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. </p> http://forums.leaflabs.com/topic.php?id=1847#post-11093 Wed, 06 Jun 2012 03:02:09 +0000 mbolivar 11093@http://forums.leaflabs.com/ <p>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. </p> http://forums.leaflabs.com/topic.php?id=1847#post-11031 Fri, 01 Jun 2012 13:04:34 +0000 Necromant 11031@http://forums.leaflabs.com/ <p>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. </p> http://forums.leaflabs.com/topic.php?id=1847#post-11026 Fri, 01 Jun 2012 08:54:08 +0000 Necromant 11026@http://forums.leaflabs.com/ <p>Okay, here it goes rebased upon the maple-bootloader git.<br /> <a href="https://github.com/nekromant/maple-bootloader" rel="nofollow">https://github.com/nekromant/maple-bootloader</a><br /> 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 &amp; FreeBSD.<br /> I'll merge the flash&amp;debug stuff into the new makefile asap </p> http://forums.leaflabs.com/topic.php?id=1847#post-11025 Fri, 01 Jun 2012 07:22:15 +0000 Necromant 11025@http://forums.leaflabs.com/ <p>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. </p> <p>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.</p> <p>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> <p>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. </p> http://forums.leaflabs.com/topic.php?id=1847#post-11024 Fri, 01 Jun 2012 06:57:29 +0000 tormod 11024@http://forums.leaflabs.com/ <p>Hi,<br /> 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.</p> <p>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.</p> <p>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. </p>