avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avrdude-dev] [task #5093] Add support for reading ELF files.


From: Dave N6NZ
Subject: Re: [avrdude-dev] [task #5093] Add support for reading ELF files.
Date: Wed, 09 May 2007 10:55:57 -0700
User-agent: Thunderbird 1.5 (X11/20051201)

As long as we are talking about tweaking linker scripts...

(dodges incoming missiles...)

The subject of using bootloader routines in application code comes up fairly frequently, and in fact I've been thinking about how to do that for my own projects. There are several ways to go about this. The solutions that seem to me to be the cleanest involve slight tweaks to the linkage methodology.

Here is one proposal:
1) Build bootloader and application separately.
2) In both, include an entryjumps.S something like the following:
#include <avr/io.h>
     .section .entryjumps
    .global shared1
shared1:
    jmp sf_shared1
    .global shared2
shared2:
    jmp sf_shared2
    .end
3) in bootloader, define and use sf_sharedX() functions
4) in application call sharedX() functions
5) When linking the bootloader, link with entryjumps.S, and place the .entryjumps section at a well-known location, either by passing a command line parameter or using a default (I haven't thought that through completely). 6) When linking the application, link with entryjumps.S, and again place .entryjumps section at the well-known location. But... the linker script should discard the actual code. It only needs the entry point definitions.

It would be nice if all of this could be present in the default linker script, but be invisible unless the user actually defines a .entryjumps section. I'm not a real whiz at linker scripts so I'm not quite sure how to do that. Also, what should the "well-known location" be? Right after the bootloader's interrupt vectors? At the very end of flash?

Anyway, that is one idea. Thoughts?

-dave

Joerg Wunsch wrote:
As Colin O'Flynn wrote:

Alas, each AVR might have a different default fuse, so we cannot
simply use 0xff as the default value.

If we got the default fuse programmed in the avrdude configuration
file, you could also add a command that brought the AVR back to
"factory" state. Handy if you were prototyping with a device than
wanted to put it away into a drawer, or just pulled a random device
out of a drawer... make the fuse bytes something sane.

The defaults need to go into avr-libc, one way or the other.  My
current idea is to add the blurb to gcrt1.S, as this file is
custom-compiled for each and any different AVR, so per-device defaults
(which come in the form of macros from <avr/ioXXX.h>) can easily be
compiled into it.  These defaults will then be overwritten by the
user-API macros like LFUSE() etc., replacing the library defaults.

The final load file (as avrdude sees it) will the either see the
library's defaults, or the customized values.

I think the idea might work, but I'm afraid I won't be able to draft a
proof-of-concept implementation of the entire toolchain before leaving
for vacation next week.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]