How to Link Bootloader.hex into Application.elf

Go To Last Post
45 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all

for production purpose i wan't to have a complete *.elf
file ( *.elf, containing fuses, eeprom, flash ).

So with AVR studio, i can easily produce an *.elf file for my application, but how can i add-link a separate
defined bootloader ( standard one, e.g. bootloader.hex )
to this *.elf file ?

BR Zimmi

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, i will check it.

BR Zimmi

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Hi sternst

now i tried it, i could arrange the *.hex file conversion to an object file *.o ( boot.hex to boot.o ).

..but im strggling to bring my linker to link that to start of bootsection ( xmega to e.g. 0x4000 )..
[linker is not really linking it in]..
maybe it's, because of the 2 first 'helpings' in your forum link, don't work anymore [Answers from JohanEkdahl and Skwit], was there a relevant information for me, how to bring the linker on the right way ?
[change of makefile, ok, but where can i set the Linking adress, as is see @ hex to bin i loose the destination adress ! so i need to tell the linker the destination, normally as i understand it correctly it thakes the destination out of the map file ! ]
Do you have a hint for me ?
BR Zimmi

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
maybe it's, because of the 2 first 'helpings' in your forum link, don't work anymore [Answers from JohanEkdahl and Skwit], was there a relevant information for me, how to bring the linker on the right way ?
No.

Quote:
i could arrange the *.hex file conversion to an object file *.o ( boot.hex to boot.o ) ... as is see @ hex to bin ...
So you currently have elf -> hex -> bin -> o?
Why are you taking the detour over the hex file? Directly create the bin file from the bootloader elf file.
elf -> bin -> o

Quote:
but where can i set the Linking adress
You set the address the same way as during the bootloader linking, just by relocating the section you have chosen in the bin->o step.

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Directly create the bin file from the bootloader elf file.
elf -> bin -> o

When you step to "bin" you will lose addressing info so that will need to be re-injected later on I guess. I'm sure avr-objcopy has options for setting section base addresses though.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

Directly create the bin file from the bootloader elf file.
elf -> bin -> o
When you step to "bin" you will lose addressing info so that will need to be re-injected later on I guess.
Of course. Did I write that that would solve his address problem? ;-)
It was merely a proposal to simplify the whole process by eliminating one step.

clawson wrote:
I'm sure avr-objcopy has options for setting section base addresses though.
Yes it has. But is that really an absolute address then? The last authority related to addresses is the linker. Any address set before is more like a relative address.
Since you choose in the bin->o step your own unique section (therefore not handled by the linker script) it could work to set the address already there, but I would set the address later during linking to be on the safe side.

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh sorry, I see what you mean - more caffeine needed here ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Why are you taking the detour over the hex file? Directly create the bin file from the bootloader elf file.
elf -> bin -> o

Hi sternst
this is not what i want, i really only want to link to the application, bootloaders flash, not its fuses and lockbits. Fuses, lockbits and EEprom default shall be defined and coming from the application...
So coming to the original point, i need
an production elf file with all this stuff in appl+bootloader+appleepr+applfuses+appllock.

Now, maybe i am to stupid to adapt it, maybe i need to be a little more concrete.
Attached ther is the for the complier and linker, so what do i need to add here
that it will link the boot16k.o to 0x4000 resp. 0x2000 Flash adress ?

Many thanks for your effort anyway.
BR MZimmi

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
this is not what i want, i really only want to link to the application, bootloaders flash, not its fuses and lockbits. Fuses, lockbits and EEprom default shall be defined and coming from the application...
You can export into the bin file whatever you want. It is exactly the same as with the hex file, it is only a different output format.

Quote:
Attached ther is the for the complier and linker, so what do i need to add here
that it will link the boot16k.o to 0x4000 resp. 0x2000 Flash adress ?

LDFLAGS += -Wl,--section-start=XXX=0x4000

Replace XXX by the name you have chosen for the section when generating boot16k.o.
(I hope you have read the other thread completely and you haven't chosen the same name as in the example in the FAQ)

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sternst wrote:
Quote:
this is not what i want, i really only want to link to the application, bootloaders flash, not its fuses and lockbits. Fuses, lockbits and EEprom default shall be defined and coming from the application...
You can export into the bin file whatever you want. It is exactly the same as with the hex file, it is only a different output format.

Quote:
Attached ther is the for the complier and linker, so what do i need to add here
that it will link the boot16k.o to 0x4000 resp. 0x2000 Flash adress ?

LDFLAGS += -Wl,--section-start=XXX=0x4000

Replace XXX by the name you have chosen for the section when generating boot16k.o.
(I hope you have read the other thread completely and you haven't chosen the same name as in the example in the FAQ)

.. now a get 2 Linker Errors, see attached screenshot..

.. generator of *.o file w. following lines

avr-objcopy -I ihex -O binary xMega32D4_BL.hex foo.bin
avr-objcopy --rename-section .data=.bootmem.data,contents,alloc,load,readonly,data -I binary -O elf32-avr foo.bin xMega32D4_BL.o
avr-nm xMega32D4_BL.o 

whats wrong... ?!

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Add --binary-architecture avr:102 to the second avr-objcopy command to get rid of the first error.

Try changing the --section_start=bootmem=0x4000 to --section_start,.bootmem.data=0x4000 to get rid of the second error.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK here's an example I just tried that appears to have worked. take from this what you will. So I started with this source in test.c:

#include

int main(void) {
  DDRB = 0xFF;
  PORTB = 0x55;
  while(1);
}

I built that (for mega16) with a -Ttext=0x3800 intending it to be my "bootloader"(*). I then converted test.elf to binary:

avr-objcopy -O binary -R .eeprom -R .fuse -R .lock test.elf boot.bin

I then converted that binary back to a linkable .o file:

E:\avr>avr-objcopy --rename-section .data=.boot,contents,alloc,load,readonly,data -I binary -O elf32-avr boot.bin boot.o

E:\avr>avr-nm boot.o
0000007a R _binary_boot_bin_end
0000007a A _binary_boot_bin_size
00000000 R _binary_boot_bin_start

E:\avr>avr-readelf -a boot.o
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           Atmel AVR 8-bit microcontroller
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          208 (bytes into file)
  Flags:                             0x82
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         5
  Section header string table index: 2

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .boot             PROGBITS        00000000 000034 00007a 00   A  0   0  1

as the data gets converted back to .data I chose to rename the section to be .boot and the readelf output confirms that worked.

I then made a one line change to the source that was now going to be my "application" (0xAA not 0x55):

#include

int main(void) {
  DDRB = 0xFF;
  PORTB = 0xAA;
  while(1);
}

and changed the Makefile used to build this to add:

LDFLAGS += boot.o -Wl,--section-start=.boot=0x3800

I then built test.c again with these new options added and it finally generated this:

E:\avr>type test.hex
:100000000C942A000C9434000C9434000C943400AA
:100010000C9434000C9434000C9434000C94340090
:100020000C9434000C9434000C9434000C94340080
:100030000C9434000C9434000C9434000C94340070
:100040000C9434000C9434000C9434000C94340060
:100050000C94340011241FBECFE5D4E0DEBFCDBF29
:100060000E9436000C943B000C9400008FEF87BB7D
:0A0070008AEA88BBFFCFF894FFCFA7
:103800000C942A1C0C94341C0C94341C0C94341C02
:103810000C94341C0C94341C0C94341C0C94341CE8
:103820000C94341C0C94341C0C94341C0C94341CD8
:103830000C94341C0C94341C0C94341C0C94341CC8
:103840000C94341C0C94341C0C94341C0C94341CB8
:103850000C94341C11241FBECFE5D4E0DEBFCDBFD5
:103860000E94361C0C943B1C0C94001C8FEF87BBF1
:0A38700085E588BBFFCFF894FFCF79
:00000001FF

As I hope you can see this contains two virtually identical copies of the same thing - one "app" linked at 0x0000 and one boot loader linked at 0x3800

BTW 8AEA = LDI R24,0xAA, 85E5 = LDI R24,0x55 (the difference between the "two programs").

EDIT: (*) just realised that the initial Ttext=0x3800 was completely pointless (unless I planned to use the boootloader in isolation), I obviously set the actual boot code location with the later -Wl,--section-start=.boot=0x3800 in fact as the original 0x3800 location was lost in the elf->bin translation.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
EDIT: (*) just realised that the initial Ttext=0x3800 was completely pointless (unless I planned to use the boootloader in isolation), I obviously set the actual boot code location with the later -Wl,--section-start=.boot=0x3800 in fact as the original 0x3800 location was lost in the elf->bin translation.
No, the initial Ttext=0x3800 is important too, to correctly resolve all the addressing within the bootloader. The later -Wl,--section-start=.boot=0x3800 moves only a big chunk of binary data (therefore of course without resolving anything within it).

PS: You can omit it only if you can guarantee that all addressing within the bootloader is relative.

Stefan Ernst

Last Edited: Mon. Aug 20, 2012 - 04:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That caffeine this morning seems to have worn off :-( :oops:

(I'm too used to things using relocatable code!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is how I do it, I use AVR Studio 4, because Atmel Studio 6 can't save .elf files:

1) Program your bootloader code to the micro
2) Execute the bootloader and flash your app code within the bootloader's application.
3) Go back to AVR Studio 4
4) Read the HEX file from the micro and save, this will have the merged APP+BL
5) Now point to the HEX you read on the flash section, point to the EEP on the eemem section, and make sure that the fuses are set correctly.
6) Press Save ELF

Taken from this thread

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all, Halleluya it works !javascript:emoticon(':D')
thank you all !

@clawson: special thanks to your post from : Aug 20, 2012 - 05:43 PM, it was one i could really follow and understand, but even soo, it didn't work w. my ATxMega due to the AVR:102 Bug once again !

@jonsole: also special thanks to you, you broght me to the idea to try around avrobj-copy and formats, so your hint was not 100% solving the linker error but it helped to find a solution !

@ganzzinai: i know your solution because i did that also in the past, it has the clear disadvantage that it's not really comfortable, you need a target system connected, to care about the fuses ( correct target sys .. ).. so it's a way but also not really safe for a lot of products. Anyway, thanks for your contribution

So, last but not least for other collegues wich might be also fighting with xMega and GCC linker ( and it's pore/rare documentation )...

We need to add at Linker file: ( Standard Studio made Linker file, copied out and added one Line, afterwards use Option seperate Linker file ! )

LDFLAGS += boot_D4.o -Wl,--section-start=.boot=0x8000

..where boot_D4.o is my Bootloader File for xMegaD4..
and .boot=0x8000 is the bootloader section of 32k type

But first we need to generate linkable object file, so
Key element to create the boot_D4.o is, as often mentioned before, the w. it's not really transparent functionality..

Methode 1, coming from elf File:

avr-objcopy -O binary -R .eeprom -R .fuse -R .lock xMega32D4_BL.elf boot_D4.bin
 
avr-objcopy --rename-section .data=.boot,contents,alloc,load,readonly,data -I binary -B avr:102 -O elf32-avr boot_D4.bin boot_D4.o

.. it's also possible to do it with Bootloaders Hex File, just replace first line by

avr-objcopy -I ihex -O binary xMega32D4_BL.hex boot_D4.bin

..so the relevant point, to got it running' was to add @ second Line the Option >-B avr:102< to avoid the type conflict at linking !

So hope this might help other 'dummies' like me to get a little more control of the GCC linker w. AVR's and especially xMega's.

BR MZimmi :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm trying to achieve the same thing within Atmel Studio 6.

I have a Pre-build Event configure that correctly generates the object file for linking:

"$(ToolchainDir)\avr-objcopy.exe" -I ihex -O binary "$(SolutionDir)SideLoadLock\atxmega32a4u_104.hex" "$(OutputDirectory)\atxmega32a4u.bin"

"$(ToolchainDir)\avr-objcopy.exe" --rename-section .data=.boot,contents,alloc,load,readonly,data -I binary -B avr:102 -O elf32-avr "$(OutputDirectory)\atxmega32a4u.bin" "$(OutputDirectory)\atxmega32a4u.o"

I then added under AVR/GNU Linker->Miscellaneous->Other Linker Flags:

-Wl,--relax atxmega32a4u.o -Wl,--section-start=.boot=0x8000

When I build I get no errors. And the following lines appear in the map file:

...
.boot          0x00000000      0xfb6 atxmega32a4u.o
...
Address of section .boot set to 0x8000
...
LOAD linker stubs
.boot           0x00008000        0x0

And the resulting ELF file doesn't contain the boot loader. Does anyone have any suggestions?

Thanks, Ian.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't see you actually adding atxmega32a4u.o as a link object there? (though the .map suggests you are)

If you readelf/objdump the .o does it contain the expected data?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
I don't see you actually adding atxmega32a4u.o as a link object there? (though the .map suggests you are)

If you readelf/objdump the .o does it contain the expected data?

Sorry you'll have to bear with me - this is new territory for me. I have attached the output from readelf - it does contain the expected data (the bootloader binary).

I thought I added the link object on the command line for the linker. For the record here's what got executed when linking:

"C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.0.65\AVRToolchain\bin\avr-gcc.exe" -o SideLoadLock.elf  src/analog.o src/asf/common/boards/user_board/init.o src/fuses.o src/lock_logic.o src/mech_control.o src/nv_data.o src/serial_comms.o src/timer_periodic.o src/asf/common/services/clock/xmega/sysclk.o src/asf/common/services/hugemem/avr8/avr8_hugemem.o src/asf/common/services/ioport/xmega/ioport_compat.o src/asf/common/services/sleepmgr/xmega/sleepmgr.o src/asf/common/services/usb/class/cdc/device/udi_cdc.o src/asf/common/services/usb/class/cdc/device/udi_cdc_desc.o src/asf/common/services/usb/udc/udc.o src/asf/common/utils/stdio/read.o src/asf/common/utils/stdio/stdio_usb/stdio_usb.o src/asf/common/utils/stdio/write.o src/asf/xmega/drivers/adc/adc.o src/asf/xmega/drivers/adc/xmega_aau/adc_aau.o src/asf/xmega/drivers/cpu/ccp.o src/asf/xmega/drivers/dma/dma.o src/asf/xmega/drivers/nvm/nvm.o src/asf/xmega/drivers/nvm/nvm_asm.o src/asf/xmega/drivers/tc/tc.o src/asf/xmega/drivers/usb/usb_device.o src/asf/xmega/drivers/wdt/wdt.o src/main.o   -Wl,-Map="SideLoadLock.map" -Wl,--start-group  -Wl,--end-group -Wl,--gc-sections -mrelax -Wl,--relax atxmega32a4u.o -Wl,--section-start=.boot=0x8000  -mmcu=atxmega32a4u

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
-Wl,--gc-sections

Not a good idea in this case. Either drop that option, or include a dummy access to one of the symbols defined in atxmega32a4u.o in your code. Or perhaps it is possible to attach a "used" attribute to the .boot section on the objcopy command line.

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sternst wrote:

-Wl,--gc-sections

Not a good idea in this case. Either drop that option, or include a dummy access to one of the symbols defined in atxmega32a4u.o in your code. Or perhaps it is possible to attach a "used" attribute to the .boot section on the objcopy command line.

Thanks Stefan, that makes perfect sense. I disabled that optimisation and compiled but got a warning about overlapping sections. I thought this was due to my boot loader insertion but that turns out not to be the case. I removed the linking in of the boot loader and still got the following warning (I had renamed my .boot section to .usbboot to be sure the error below was not related, apparently .boot is already used elsewhere):

Error	12	section .BOOT loaded at [0000680a,0000684d] overlaps section .data loaded at [0000680a,00006ccf]		1	1	SideLoadLock

It seems the build relies on removing some sections that are not used, but that trashes the boot loader.

I tried adding a used attribute but got the following error from avr-objcopy:

avr-objcopy.exe: unrecognized section flag `used'
avr-objcopy.exe: supported flags: alloc, load, noload, readonly, debug, code, data, rom, share, contents

I am not sure how to include a dummy access to something in the boot loader section?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This .BOOT thing stems from using ASF. There've been threads about this before. Even if you are only using something like the ADC functions from ASF you still see this. It turns out that Xmega have ADC calibration bytes in the NVM part of the chip (alongside the signature row etc). It also turns out that ASF has an NVM that does not split reading and writing but offers both. The writing functions use SPM. It must be located in the bootloader section and they define .BOOT for this. So even though you are not using SPM writing functions (well not here anyway - obviously your bootloader does) you have code that thinks it needs to be located "up high". One solution would be to hack the ASF "NVM" library code and simply #if 0 out the parts that are not being used (the previous -gc-sections presumably did this!) or the alternative is to pander to its whims and give a --section-start=.BOOT= where is picked to be wel out of the way of real code so this dead code can be dumped there.

Personally I don't like this kind of design where redundant code is included and then it relies on -ffunction-sections/-gc-sections to cut it out later. Far better if either ASF's NVM had been designed to split things into nvmread/nvmwrite and you only use the one you want or there be a nvm.h where you #define NVM_USE_WRITE_FNS or something to say whether you want that stuff included in the build.

But there it is. It is what it is. Search out prior threads (maybe in Xmega forum) for ".BOOT" to learn more about this issue.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks to all for the help, I think I have something working but I am not sure how "correct" the process is. I am definitely willing to hear suggestions, but for now it works for me. Here's the changes I did to a standard project in Atmel Studio 6.0

Add a build event to convert the bootloader hex file to a suitable object file:

"$(ToolchainDir)\avr-objcopy.exe" -I ihex -O binary "$(SolutionDir)SideLoadLock\atxmega32a4u_104.hex" "$(OutputDirectory)\atxmega32a4u.bin"

"$(ToolchainDir)\avr-objcopy.exe" --rename-section .data=.usbboot,contents,alloc,load,readonly,data -I binary -B avr:102 -O elf32-avr "$(OutputDirectory)\atxmega32a4u.bin" "$(OutputDirectory)\atxmega32a4u.o"

Add a new flash segment, under Project->Properties->Toolchain->AVR/GNU Linker->Memory Settings->Flash Segment: .usbboot=0x4000
This adds the following to the linker command line:

-Wl,-section-start=.usbboot=0x8000

Include bootloader object file and prevent the section from being garbage collected, under Project->Properties->Toolchain->AVR/GNU Linker->Miscellaneous->Other Linker Flags: -Wl,--relax atxmega32a4u.o -Wl,--undefined=_binary_C__{....}_Debug_atxmega32a4u_bin_start

The {....} is where I have removed a full path that got integrated into a symbol name in the bootloader object file. I found out this name by executing the following on the bootloader object file:

avr-objdump.exe -t atxmega32a4u.o

The resulting ELF and HEX files from compilation now contain the application and bootloader at the correct address. Like I mentioned, I really don't know what I'm doing but it worked for me. If anyone knows a better/more correct way I'm all ears.

Cheers,
Ian.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

I'm tryingto include the boot hex file in the elf.

I already added this to the make file:

Section definition:

LDFLAGS += -Wl,--section-start=.bootloader=0x3800

Object creation in the "all:" (executed in Bluid order) :

@avr-objcopy -I ihex -O binary $(BOOTLOADER).hex $(BOOTLOADER).bin
@avr-objcopy.exe --rename-section .data=.bootloader,contents,alloc,load,readonly,data -I binary -O elf32-avr $(BOOTLOADER).bin ./$(OUTPUT)/bootloader.o

NOTE: BOOTLOADER is the name of my boot file

With this configuration i never seen the bootloader in my elf.

I have some wrong?

Thanks for all

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you using -gc-sections or not? If yes you need to read ALL of this thread.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Are you using -gc-sections or not? If yes you need to read ALL of this thread.

I'm not using the "gc-sections".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What does:

avr-objdump -h project.elf

show?

Oh and the obvious question: is ./$(OUTPUT)/bootloader.o given as an input to the link?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         00000014  00800100  0000174c  00001820  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  1 .text         0000174c  00000000  00000000  000000d4  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .bss          00000060  00800114  00800114  00001834  2**0
                  ALLOC
  3 .noinit       00000004  00800174  00800174  00001834  2**0
                  ALLOC
  4 .fuse         00000003  00820000  00820000  00001834  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  5 .lock         00000001  00830000  00830000  00001837  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  6 .debug_aranges 00000490  00000000  00000000  00001838  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_pubnames 00000d37  00000000  00000000  00001cc8  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_info   00003130  00000000  00000000  000029ff  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_abbrev 00000f98  00000000  00000000  00005b2f  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_line   00002b63  00000000  00000000  00006ac7  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_frame  00000720  00000000  00000000  0000962c  2**2
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_str    0000118a  00000000  00000000  00009d4c  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_loc    0000094a  00000000  00000000  0000aed6  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_ranges 00000488  00000000  00000000  0000b820  2**0
                  CONTENTS, READONLY, DEBUGGING
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And your answer to the "obvious question" above?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
And your answer to the "obvious question" above?

Im not shure where i define the .o as a input.

The .o is in the same forder than the other .o

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes but you obviously have to tell the linker to use it, it's not psychic and, no it doesn't just link every .o it finds in the directory (for all you know there could be some old files there from a previous project!).

If using AS6 probably the easiest answer is under Toolchain/Linker options go to the "miscellaneous" section and just enter the .o name there.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use a makefile and the toolchain menu is locked.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Adding:

LIBS = bootloader.o

to that could work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now i have the bootloader.o linked but is not in the elf file.

in the prjoect.map appear the .bootloader without the referenced file:

.......
.bootloader           0x00003800        0x0

.debug_ranges   0x00000000      0x488
 .debug_ranges  0x00000000       0x30 default/wdt_drv.o
......

some wrong with the section association

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The fact that the length is 0x0 really does look like it may have been removed by -gc-sections or there was nothing in it in the first place. Try avr-objdump -h on the bootloader.o file.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

softjad wrote:
I'm not using the "gc-sections".

LDFLAGS += -Wl,-Map=$(PROJECT).map,--cref,--gc-sections,--relax

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I removed the "gc-sections" and now i have the .boot section in the .elf file.

Now when i try to programm with th .elf, a error appear: "Some section of the file provided does not fit within the device memory"

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         00000014  00800100  0000194e  00001a42  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  1 .text         0000194e  00000000  00000000  000000f4  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .boot         00001000  00003800  00003800  00001a56  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .bss          00000061  00800114  00800114  00002a56  2**0
                  ALLOC
  4 .noinit       00000004  00800175  00800175  00002a56  2**0
                  ALLOC
  5 .fuse         00000003  00820000  00820000  00002a56  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  6 .lock         00000001  00830000  00830000  00002a59  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  7 .debug_aranges 00000490  00000000  00000000  00002a5a  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_pubnames 00000d37  00000000  00000000  00002eea  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_info   00003130  00000000  00000000  00003c21  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_abbrev 00000f98  00000000  00000000  00006d51  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_line   00002b63  00000000  00000000  00007ce9  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_frame  00000720  00000000  00000000  0000a84c  2**2
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_str    0000118a  00000000  00000000  0000af6c  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_loc    0000094a  00000000  00000000  0000c0f6  2**0
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_ranges 00000488  00000000  00000000  0000ca40  2**0
                  CONTENTS, READONLY, DEBUGGING

The start address of my bootloader is the 0x3800

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It appears to be saying SIZE=0x1000 for .boot. Exactly how were you expecting to fit 0x1000 between 0x3800 and (presumably?) 0x3FFF ?

EDIT: Looking back through the thread the device appears to be the 32U4? That's 32K. It has flash from 0x0000..0x7FFF. What would the bootloader be doing at 0x3800? However it is curious that you cannot fit 0x1000 bytes into the device at 0x3800 as that's just below half way through flash?

Looks like the base was supposed to be 0x7000 and 0x1000 *should* fit between there and 0x7FFF.

Last Edited: Wed. Sep 26, 2012 - 02:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
...
  2 .boot         00001000  00003800  00003800  00001a56  2**0
                  ^^^^^^^^

Obviously something is wrong on the way from the bootloader source code to bootloader.o.

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a AT90usb162 (16K).

To convert the source code i use this:

@avr-objcopy -I ihex -O binary $(BOOTLOADER).hex $(BOOTLOADER).bin
@avr-objcopy.exe --rename-section .data=.boot,contents,alloc,load,readonly,data -I binary -O elf32-avr $(BOOTLOADER).bin $(OUTPUT)/bootloader.o

and to define the .boot section i have:

LDFLAGS += -Wl,--section-start=.boot=0x3800
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well if it is 16K how do you hope to fit 4K of code in the 2K of space between 0x3800 and 0x3FFF?

Go back and look at $(BOOTLOADER).hex, exactly how much binary does it specify? (avr-size will work on .hex files by the way).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

2lostkiwis wrote:
Thanks to all for the help, I think I have something working but I am not sure how "correct" the process is. I am definitely willing to hear suggestions, but for now it works for me. Here's the changes I did to a standard project in Atmel Studio 6.0


Thanks for this, it is much appreciated. I am having trouble getting it to work though. It looks like the bootloader was correctly integrated:

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .boot         00001208  00020000  00020000  0001027e  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .noinit       00000007  00802004  00802004  00011486  2**0
                  ALLOC
  2 .bss          000011e7  00802010  00802010  00011486  2**0
                  ALLOC
  3 .text         000101a6  00000000  00000000  000000d4  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  4 .data         00000004  00802000  000101a6  0001027a  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  5 .stab         00002ee0  00000000  00000000  00011488  2**2
                  CONTENTS, READONLY, DEBUGGING
  6 .stabstr      00000bac  00000000  00000000  00014368  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_aranges 00000480  00000000  00000000  00014f18  2**3
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_info   00018c57  00000000  00000000  00015398  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_abbrev 00003bbf  00000000  00000000  0002dfef  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_line   00006d0b  00000000  00000000  00031bae  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_frame  00002158  00000000  00000000  000388bc  2**2
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_str    000054be  00000000  00000000  0003aa14  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_loc    0000bd0b  00000000  00000000  0003fed2  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_ranges 00001690  00000000  00000000  0004bbdd  2**0
                  CONTENTS, READONLY, DEBUGGING

But the XMEGA does not seem to boot into it. If I load up just the bootloader on its own it works fine (located at 0x2000, natch.)

I can't for the life of me see what is wrong here. Examining the .hex file shows exactly the same code as the bootloader on its own, located in the same place. Fuses are correct. If I load the application via the bootloader it operates as expected.

Any ideas?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I fixed it. I noticed that the .elf and .hex file time stamps were not in sync with bootloader.o. Did a complete re-build and it started working.

The build system does not appear to consider bootloader.o when deciding if it needs to re-link the project.

Thanks again for the useful info.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I got this also working combining xboot.elf to my own Makefile like this:

$(TARGET).elf: $(OBJ) xboot-master/xboot.elf
	$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJ) $(LIBS)
#	$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS)
	$(OBJCOPY) -O binary -R .eeprom -R .fuse -R .lock xboot-master/xboot.elf xboot.bin
	$(OBJCOPY) --rename-section .data=.boot,contents,alloc,load,readonly,data -I binary -B avr:104 -O elf32-avr xboot.bin xboot.o
	$(CC) $(CFLAGS) $(LDFLAGS) -o mergedfile.elf $(OBJ) xboot.o -Wl,--section-start=.boot=0x010000 $(LIBS)

The original Makefile had just the now commented line. What I don't understand is why I need "-B avr:104" flag. It doesn't work without it complaining about incompatible avr:102. I found out that 104 is atxmega4 for 64k+ xmegas (I have xmega64d4, which is listedthere) and 102 is xmega2 for below 64k xmegas.

Also xboot is setup for xmega64d4 and totally recompiled. At the end the mergedfile.elf verifies OK with the flash, which has separately programmed bootloader+application. So what was all about avr:102?

Another thing I don't understand is why I need to move section .boot not .xboot while:

avr-nm xboot.o
00000c08 R _binary_xboot_bin_end
00000c08 A _binary_xboot_bin_size
00000000 R _binary_xboot_bin_start

Putting .xboot in place of .boot in the Makefile makes it complain about `.boot' will not fit in region `lock'.