Go Down

Topic: New optiboot; beta testers welcome... (Read 116 times) previous topic - next topic

skyjumper

#135
Jan 18, 2012, 02:35 am Last Edit: Jan 18, 2012, 02:43 am by skyjumper Reason: 1

My 1284s are still in their tube, and the Sanguino I have somewhere that would be easiest to test with is "missing." :-(



If someone can email me the bootloader patched for the 1284P as a hex file, I can test it easily. I have plenty of apps that well exceed the 64KB barrier ;-)

maniacbug

#136
Jan 18, 2012, 02:52 am Last Edit: Jan 18, 2012, 02:54 am by maniacbug Reason: 1

If someone can email me the bootloader patched for the 1284P as a hex file, I can test it easily. I have plenty of apps that well exceed the 64KB barrier ;-)


Just sent it to you.

On an unrelated note, the 328p bootloader is now 522 bytes!  10 bytes over.  Using avr-gcc 4.5.3, binutils 2.21, avr-libc 1.7.

EDIT: This is using the tip, 5ec3f2030308.

skyjumper


skyjumper

No good...


         Programmer Type : STK500
         Description     : Atmel STK500 Version 1.x firmware
         Hardware Version: 3
         Firmware Version: 4.4
         Vtarget         : 0.3 V
         Varef           : 0.3 V
         Oscillator      : 28.800 kHz
         SCK period      : 3.3 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9705
avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: efuse reads as 0
avrdude: reading input file "rp4n_big.cpp.hex"
avrdude: writing flash (127350 bytes):

Writing | ################################################   | 96% 23.02s
avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x64
Writing | ################################################## | 100% 33.14s

avrdude: failed to write flash memory, rc=-4

avrdude: stk500_cmd(): programmer is out of sync

westfw

Quote
the 328p bootloader is now 522 bytes! [avr-gcc 4.5.3]

Hmm.  Still 500 bytes using 4.3.2
It didn't get bigger from the recent patches, did it?  They weren't expected to change the 328 binary at all!

maniacbug


avrdude: writing flash (127350 bytes):

Writing | ################################################   | 96% 23.02s
avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x64


Hmm, it looks like it got to 96% of a 127k file.  That's pretty good.  I say try on something smaller like 75k.

skyjumper



avrdude: writing flash (127350 bytes):

Writing | ################################################   | 96% 23.02s
avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x64


Hmm, it looks like it got to 96% of a 127k file.  That's pretty good.  I say try on something smaller like 75k.


working on it...

westfw

Quote
avr-gcc 4.5.3

Did you find this somewhere convenient, or put it together from scratch?

skyjumper

Actually 127,350 was probably too big because of the space reserved for the boot loader.

I had some trouble compiling a HEX file bigger than 64K. So, I took my big file and cut it down with an editor. I didn't expect it to run, but I did expect it to program in and verify. Here is what I get:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9705
avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: efuse reads as 0
avrdude: reading input file "RP4N_big.hex"
avrdude: writing flash (127350 bytes):

Writing | ################################################## | 100% 22.81s

avrdude: 127350 bytes of flash written
avrdude: verifying flash memory against RP4N_big.hex:
avrdude: load data flash data from input file RP4N_big.hex:
avrdude: input file RP4N_big.hex contains 127350 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 26.72s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x10000
         0xf9 != 0x0c
avrdude: verification error; content mismatch

avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: efuse reads as 0
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

maniacbug

#144
Jan 18, 2012, 06:27 am Last Edit: Jan 18, 2012, 06:30 am by maniacbug Reason: 1

Quote
avr-gcc 4.5.3

Did you find this somewhere convenient, or put it together from scratch?


As convenient as it gets.  "apt-get install gcc-avr" from latest Ubuntu 64, 11.10.  http://packages.ubuntu.com/oneiric/gcc-avr

Also for fun just tried it on my hand-built gcc-4.6.2, and in that case it's 524 bytes.  That toolset was self-built (no patches) pulled directly from gnu.org:

* binutils 2.22 ftp://ftp.gnu.org/gnu/binutils/binutils-2.22.tar.bz2
* gcc 4.6.2 ftp://ftp.gnu.org/gnu/gcc/gcc-4.6.2/gcc-core-4.6.2.tar.bz2
* g++ 4.6.2 ftp://ftp.gnu.org/gnu/gcc/gcc-4.6.2/gcc-g++-4.6.2.tar.bz2
* avr-libc 1.8.0 http://download.savannah.gnu.org/releases/avr-libc/avr-libc-1.8.0.tar.bz2

Anyway this is no problem for me because I can easily bump up to the next bootloader size, but probably worth knowing about because now 500 bytes are wasted.

westfw

Ah.  I'll have to update/reinstall my ubuntu vm.  10.x looks set back to 4.3 (and the update isn't going so well.  Grr.)
Fink LOOKS like it should install 4.5.3 as well, but it's not finding what it thinks is the correct version of binutils.

maniacbug

Fink?  So you run mac?

I did this on mac, running CMarrin's avrtools distro http://avr.marrin.org/2011/04/24/mac-avr-toolchain/
    - avr-binutils (version 2.21)
    - avr-gcc (version 4.5.2)
        - gmp (version 5.0.1)
        - mpfr (version 3.01)
        - mpc (version 0.9)
    - avr-libc (version 1.7.1)

It came in at 496 bytes.

sixeyes

The optiboot website says Mega support coming soon. Does the current version support Megas? I'm really after faster uploads as it seems to take ages to program and my code is only 20k in size.

Iain

westfw

preliminary analysis shows that some functions got shorter (thus 4.5.2 going down to 496), but 4.5.3 lost the ability to chain jumps.  This adds about an instruction per command.  Also, I think it's broken.  There's some code that assumes that a stack frame is set up, but since the build suppresses all the normal initialization, it isn't...

Also, disassembly seems to be broken :-(   Ubuntu seems to only be installing binutils 2.20 now.   I wonder if that's this problem?


westfw

I don't currently have any plans to support the Mega boards.  I've updated the (long obsolete) homepage to remove the "coming in a few days" list...

Go Up