kein Rücksprung aus Funktionen in NRWW section?

Einen Bootloader schreibt man mit Vorteil in ASM, und dann sind die push 
und pop genau da wo du sie haben moechtest.

hallo,
so ganz verstehe ich das problem der zwei-teilung der nrww nicht. du 
kannst doch genau so gut an den beginn der nrww springen, und da dort 
auch die BLS beginnen lassen. oder irre ich da?

aber gehen wir mal davon aus, die adresse ist vorgegeben. dann zeig mal 
bitte her bitte, wie du kompilierst und linkst.
bye kosmo

Hallo,

Das mit der Unterteilung der NRWW sections hab ich gemacht, damit meine 
Startfunction immer an der Adresse vom boot reset vector liegt. Damit 
hat es aber, glaube ich, weniger zu tun. Wenn ich das ändere und nur 
eine NRWW section nehme, sind nach dem compilieren auch keine push/pops 
in der lss-Datei zu sehen. Vielleicht gibt es irgendwelche compiler 
flags, um dies bei Funktionen im NRWW Bereich zu aktivieren. Im 
folgenden mal das makefile.


## General Flags
PROJECT = ir2ps2
MCU = atmega32
TARGET = ir2ps2.elf
CC = avr-gcc

## Options common to compile, link and assembly rules
COMMON = -mmcu=$(MCU)

## Compile options common for all C compilation units.
CFLAGS = $(COMMON)
CFLAGS += -Wall -gdwarf-2 
-DF_CPU=8000000  -Os  -fsigned-char
CFLAGS += -Wp,-M,-MP,-MT,$(*F).o,-MF,dep/$(@F).d

## Assembly specific flags
ASMFLAGS = $(COMMON)
ASMFLAGS += -x assembler-with-cpp -Wa,-gdwarf2

## Linker flags
LDFLAGS = $(COMMON)
LDFLAGS += -minit-stack=0x800  -Wl,-Map=ir2ps2.map
LDFLAGS += -Wl,-section-start=.bootloader=0x7e00
LDFLAGS += -Wl,-section-start=.bootcode=0x7000
LDFLAGS += -Wl,-section-start=.finit9=0x6fd0


## Intel Hex file production flags
HEX_FLASH_FLAGS = -R .eeprom

HEX_EEPROM_FLAGS = -j .eeprom
HEX_EEPROM_FLAGS += --set-section-flags=.eeprom="alloc,load"
HEX_EEPROM_FLAGS += --change-section-lma .eeprom=0


## Include Directories
INCLUDES = -I"C:\winavr\test."

## Objects that must be built in order to link
OBJECTS = ir2ps2.o keyboard.o

## Build
all: $(TARGET) ir2ps2.hex ir2ps2.eep ir2ps2.lss

## Compile
ir2ps2.o: ../ir2ps2.c
  $(CC) $(INCLUDES) $(CFLAGS) -c   $< -o $@

keyboard.o: ../keyboard.c
  $(CC) $(INCLUDES) $(CFLAGS) -c   $< -o $@

##Link
$(TARGET): $(OBJECTS)
   $(CC) $(LDFLAGS) $(OBJECTS) $(LIBDIRS) $(LIBS) -o $(TARGET)

%.hex: $(TARGET)
  avr-objcopy -O ihex $(HEX_FLASH_FLAGS)  $< $@

%.eep: $(TARGET)
  avr-objcopy $(HEX_EEPROM_FLAGS) -O ihex $< $@

%.lss: $(TARGET)
  avr-objdump -h -S $< > $@

## Clean target
.PHONY: clean
clean:
  -rm -rf $(OBJECTS) ir2ps2.elf dep/ ir2ps2.hex ir2ps2.eep ir2ps2.lss 
ir2ps2.map


## Other dependencies
-include $(shell mkdir dep 2>/dev/null) $(wildcard dep/*)

hallo,

>Den API-Call an den Bootloaderstart zu legen, hätte das Problem, wie der
>Bootloader dann zweifelsfrei erkennen kann, ob es ein Reset oder eben
>ein API-Call ist

da biete das reset-register hilfreiche dienste. so denn keine runtime 
oder irgendwr anders böses das schon geclear-ed hat.

>Außerdem gibt es ja 4 Möglichkeiten, wo der Bootstart liegen kann

das ist richtig.
die kann man meines wissens nach aber nur von aussen ändern. somit ist 
es auch kein problem, im gleichem atemzug den richtigen wert zu setzen.

@OP: der gcc und der linker wissen rein gar nichts von irgendwelchen 
NRWW-sections. der code ist daher exakt der gleiche (der selbe?) wie für 
andere speicherbereiche. ich kann nur vermuten, dass deine 
schreib-routinen lediglich die macros aus der boot.h sind. keine ahnung, 
ob das geht, nur so eine idee.

bye kosmo

Wozu braucht's denn die push/pops ? Zum rumspringen brauchts die nicht, 
denn das ist mit rjmp, rcall & ret getan. (Funktions-)Parameter ? 
Muessen nicht auf'm Stack sein. Ist der Stack denn ueberhaupt schon 
definiert ?