On 09.11.2016 10:14, Pitchumani Sivanupandi wrote:
On Tuesday 08 November 2016 02:57 PM, Georg-Johann Lay wrote:
On 08.11.2016 08:08, Pitchumani Sivanupandi wrote:
I have updated patch to include the flash size as well. Took that info from
device headers (it was fed into crt's device information note section also).

The new option would render -mn-flash superfluous, but we should keep it for
backward compatibility.
Ok.
Shouldn't link_pmem_wrap then be removed from link_relax, i.e. from
LINK_RELAX_SPEC?  And what happens if relaxation is off?
Yes. Removed link_pmem_wrap from link_relax.
Disabling relaxation doesn't change -mpmem-wrap-around behavior.

Now, wrap around behavior is changed as follows:

For 8K flash devices:
Device specs adds --pmem-wrap-around=8k linker option if -mno-pmem-wrap-around
is NOT enabled.
It makes the --pmem-wrap-around=8k linker option default for 8k flash devices.

For 16/32/64K flash devices:
Spec string 'link_pmem_wrap' added to all 16/32/64k flash devices specs.
Other wise no changes i.e. It adds --pmem-wrap-around=16/32/64k option if
-mpmem-wrap-around option is enabled.

For other devices, no changes in device specs.

Reg tested with default and -mrelax options enabled. No issues.

Regards,
Pitchumani

gcc/ChangeLog

2016-11-08  Pitchumani Sivanupandi <pitchuman...@atmel.com>

    * config/avr/avr-arch.h (avr_mcu_t): Add flash_size member.
    * config/avr/avr-devices.c(avr_mcu_types): Add flash size info.
    * config/avr/avr-mcu.def: Likewise.
    * config/avr/gen-avr-mmcu-specs.c (print_mcu): Remove hard-coded prefix
    check to find wrap-around value, instead use MCU flash size. For 8k flash
    devices, update link_pmem_wrap spec string to add --pmem-wrap-around=8k.
    * config/avr/specs.h: Remove link_pmem_wrap from LINK_RELAX_SPEC and
    add to linker specs (LINK_SPEC) directly.

flashsize-and-wrap-around.patch

diff --git a/gcc/config/avr/avr-mcus.def b/gcc/config/avr/avr-mcus.def
index 6bcc6ff..9d4aa1a 100644

 /* Classic, == 128K.  */
-AVR_MCU ("avr31",            ARCH_AVR31, AVR_ERRATA_SKIP,
NULL,                    0x0060, 0x0, 2)
-AVR_MCU ("atmega103",        ARCH_AVR31, AVR_ERRATA_SKIP,
"__AVR_ATmega103__",     0x0060, 0x0, 2)
-AVR_MCU ("at43usb320",       ARCH_AVR31, AVR_ISA_NONE,
"__AVR_AT43USB320__",       0x0060, 0x0, 2)
+AVR_MCU ("avr31",            ARCH_AVR31, AVR_ERRATA_SKIP,
NULL,                    0x0060, 0x0, 2, 0x20000)
+AVR_MCU ("atmega103",        ARCH_AVR31, AVR_ERRATA_SKIP,
"__AVR_ATmega103__",     0x0060, 0x0, 2, 0x20000)
+AVR_MCU ("at43usb320",       ARCH_AVR31, AVR_ISA_NONE,
"__AVR_AT43USB320__",       0x0060, 0x0, 2, 0x10000)

This looks incorrect: either .flash_size should be 0x20000 or n_flash be 1.
As you draw the information from internal hardware descriptions, I'd guess
that the new information is more reliable?

...as this also determines whether AT43USB320supports ELPM this also means
that the device is in the wrong multilib set?

I couldn't find the data sheet at atmel.com, and the one I found on the net
only mentions 64KiB program memory.  It mentions LPM on pp. 9 but has no
reference to the supported instruction set.  From the manual I would conclude
that this device should be avr3, not avr31?
Yes. I couldn't find any other source other than the datasheet in net.
This device do not have internal program memory. Flash size is set to 64K
as the device could address only 64K. No RAMPZ register, so no ELPM. Moved
device to AVR3 architecture.

 /* Classic, > 8K, <= 64K.  */
-AVR_MCU ("avr3",             ARCH_AVR3, AVR_ISA_NONE, NULL,                    
    0x0060, 0x0, 1)
-AVR_MCU ("at43usb355",       ARCH_AVR3, AVR_ISA_NONE, "__AVR_AT43USB355__",    
    0x0060, 0x0, 1)
-AVR_MCU ("at76c711",         ARCH_AVR3, AVR_ISA_NONE, "__AVR_AT76C711__",      
    0x0060, 0x0, 1)
+AVR_MCU ("avr3",             ARCH_AVR3, AVR_ISA_NONE, NULL,                    
    0x0060, 0x0, 1, 0x6000)
+AVR_MCU ("at43usb355",       ARCH_AVR3, AVR_ISA_NONE, "__AVR_AT43USB355__",    
    0x0060, 0x0, 1, 0x6000)
+AVR_MCU ("at76c711",         ARCH_AVR3, AVR_ISA_NONE, "__AVR_AT76C711__",      
    0x0060, 0x0, 1, 0x4000)
+AVR_MCU ("at43usb320",       ARCH_AVR3, AVR_ISA_NONE, "__AVR_AT43USB320__",    
    0x0060, 0x0, 1, 0x10000)
 /* Classic, == 128K.  */
-AVR_MCU ("avr31",            ARCH_AVR31, AVR_ERRATA_SKIP, NULL,                
    0x0060, 0x0, 2)
-AVR_MCU ("atmega103",        ARCH_AVR31, AVR_ERRATA_SKIP, "__AVR_ATmega103__", 
    0x0060, 0x0, 2)
-AVR_MCU ("at43usb320",       ARCH_AVR31, AVR_ISA_NONE, "__AVR_AT43USB320__",   
    0x0060, 0x0, 2)
+AVR_MCU ("avr31",            ARCH_AVR31, AVR_ERRATA_SKIP, NULL,                
    0x0060, 0x0, 2, 0x20000)
+AVR_MCU ("atmega103",        ARCH_AVR31, AVR_ERRATA_SKIP, "__AVR_ATmega103__", 
    0x0060, 0x0, 2, 0x20000)
 /* Classic + MOVW + JMP/CALL.  */

If at43usb320 is in the wrong multilib, then this should be handled as separate issue / patch together with its own PR. Sorry for the confusion. I just noticed that some fields don't match...

It is not even clear to me from the data sheet if avr3 is the correct multilib or perhaps avr35 (if it supports MOVW) or even avr5 (if it also has MUL) as there is no reference to the exact instruction set -- Atmochip will know.

Moreover, such a change should be sync'ed with avr-libc as all multilib stuff is hand-wired there: no use of --print-foo meta information retrieval by avr-libc :-((

I filed PR78275 and https://savannah.nongnu.org/bugs/index.php?49565 for this 
one.

Johann

Reply via email to