cool. thanks Johny. Any chance you can finish writing/documenting this up and possibly add it to the mainline?
On Wed, Apr 29, 2015 at 6:02 PM, Johny Mattsson <[email protected]> wrote: > On 30 April 2015 at 04:03, Eric Decker <[email protected]> wrote: > >> On Wed, Apr 29, 2015 at 9:06 AM, Li, Wenting <[email protected]> wrote: >> >>> >>> 1. I want to put an application in the bootloader section and the other >>> part in the applicatioin section, because I need the capability to write to >>> internal flash. But the whole TOS image is too big to fit in bootloader >>> section. So can I selectively choose a component to stay in bootloader >>> section, and the other parts outside. >>> >> >> no >> > > Make that a "no, not easily" :) > > For what you're wanting to do, you'll definitely want to use TosBoot. Even > so, with an AVR you'll need a few extra tweaks to work with/around the > flash programming restrictions. It's been a few years since I worked in > this area, but as a very brief summary, for remote firmware upgrade you > need to: > > - Use TosBoot to provider basic loader functionality, and get ensure it's > installed in the privileged/bootloader area of the flash. > > - Put the flash writing/erasing routines for the AVR into TosBoot, and the > function prototypes for them in some header file somewhere. > > - Generate a linking library from the TosBoot binary, containing only the > symbols for your flash read/write functions. > > - Create the volumes-{something}.xml to specify partitioning of your flash > - you'll need at least two application volumes to allow downloading and > switching to new firmware. There's a TEP or intro on how all that bit works > (I've forgotten most of it by now *cough*); It's probably together with the > rest of the TosBoot information. > > - Add "-Wl,-R$(path_to_above_generated.lib)" to your application > Makefile's LDFLAGS, to allow the linker to resolve your flash read/write > functions. > > - Include the header file for the flash read/write in whichever module > handles receiving new firmware data, and call them from there. Since these > functions actually reside in the boot loader area of the flash, they're > allowed to do the reprogramming. You're effectively sharing these functions > between both TosBoot and your application. This is the key to making it all > work. > > - All the other details that I've glossed over or forgotten about :) > > - And finally, be very very very careful if you ever need to make changes > to your TosBoot, since if you change the address of the read/write > functions, Things Will Break(tm). If possible, place those functions at > fixed addresses to avoid such headaches. > > > > >> How can I do it if TinyOS only allows the upload of one packaged system >>> image? >>> >> >> you can't in the context of TinyOS. The question above is outside the >> scope of how TinyOS gets built. >> >> You are actually asking a question about how to you make use of the >> embedded atmel environment. And how do you load two different pieces of >> code into the Atmel flash and have them cooperate in some fashion. >> >> TinyOS doesn't directly support doing those kinds of things. >> > > While, as Eric says, there's no direct support for it, the structure does > work quite well for slotting it in though, largely thanks to TosBoot. > > > >> You can do this but it is outside the scope of how TinyOS works. So it >> is something that you would have to figure out. >> > > Having been in the position of having to figure those things out, allow me > to point you at our (now somewhat outdated) TinyOS fork with support for > the atxm256, including the above mentioned boot loader / reprogramming > support. The most interesting file to peruse is probably the TosBoot > Makefile: > > > https://github.com/DiUS/tinyos-siflex02/blob/master/tos/lib/tosboot/Makefile > > The siflex02 & modflex related targets have the relevant bits. > > Getting it all to work isn't what I'd call trivial, but it *is* doable if > you're willing to put the time into it! > > > Good luck, > /Johny > -- > Johny Mattsson > Senior Software Engineer > > DiUS Computing Pty. Ltd. > > *where ideas are engineered * > -- Eric B. Decker Senior (over 50 :-) Researcher
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
