avr-libc-dev
[Top][All Lists]
Advanced

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

RE: [avr-libc-dev] Re: [RFC] Unified ELF file


From: Eric Weddington
Subject: RE: [avr-libc-dev] Re: [RFC] Unified ELF file
Date: Sun, 23 Sep 2007 21:38:04 -0600


> -----Original Message-----
> From:
> address@hidden
> [mailto:address@hidden
> org] On Behalf Of Colin O'Flynn
> Sent: Saturday, September 22, 2007 11:31 PM
> To: avr-libc-dev
> Subject: [avr-libc-dev] Re: [RFC] Unified ELF file
>
> Hello,
>
> > - How can the API be changed to ensure that all fuse bytes
> are set by the
> > user?
>
> Not fixing that problem, but what about providing some
> indication that not all
> fuse bytes were set?
>
> By this I mean providing a "magic sequence" at the end of the
> fuse bytes. So
> the ELF file in the .fuse section looks like:

I've been thinking about a different approach, but I don't have all the
answers.

What about doing something like this?:
- Add code to the startup code (gcrt1.S) to add the new fuse sections
(.fuse, .lfuse, .hfuse, .efuse), with the default values which are #included
from avr/fuse.h, via variables that are set as weak references.
- Then, a user can set this variable in their C code with any new value via
the macros in avr/fuse.h.

The advantages that I see would be that the default values would always be
guaranteed to be in the ELF file, even if the user did not explicitly assign
them. The reason why to put this in the startup code is that this is the
only thing in avr-libc (currently) that is built per-device. The main C (and
math) library is built per-architecture. That way we can be sure to get the
correct device defaults in.

I have done some experimental work on this so far. However, I'll be the
first to admit that I'm not a wizard with the assembler. I'm having some
difficulty in getting the startup code set up with variables that are weak
references, located custom sections, that can be changed in the end-user's C
code. Hopefully this overall idea has merit. If someone has suggestions on
how to do the implementation, I'm certainly open to it.

Eric Weddington






reply via email to

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