[Top][All Lists]

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

Re: [avr-gcc-list] Parm to application

From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] Parm to application
Date: Sun, 26 Aug 2012 15:44:36 +0200
User-agent: Thunderbird (Windows/20100228)

Parthasaradhi Nayani schrieb:
From: Georg-Johann Lay

With int x __attribute__((section (".bootdata")));
you can use x in the known way, it's only about locating .bootdata
to whatever location you deem appropriate.  Read the linker manual.

This appears to be the only best way!!! This means I create a
section, say .bootdata with some address in the boot loader. Create
exactly the same section with the same address in the actual
application section. Since the boot loader starts first, it writes
whatever data to be passed into this section and when application
gets executed, it reads this section. Am I right?


You can also arrange it in a way so that the application does not
waste the .bootdata space:  Pass the data before RAMEND.  In
the application init, initialize SP to REMEND-SIZE and before
calling main, "pop" the data from stack and fill main's parameters.

Notice that if you have constructors, they don't have this
information available.  Or you need an other approach than passing
the data to main as argc/argv/env.

One point to consider - boot loader is somewhat a permanent fixture
in flash, whereas application(s) can keep changing or updated. Should
the compiler version be same for both? will the ordering of variables
change with versions? If this remains same, then the above approach
is best as of now, else the same compiler has to be used for future
updates of application.

The compiler version does not matter.  What matters is the liker script
and the linker options you use.  And the data layout.  Relying on a
specific data sequence is relying on undefined behavior.

Read [1] for hints on how to avoid that.

I would actually prefer to call application main with parameters from boot section.

Calling main from boot does not sound sane. How do you know the address of main? How do you run startup code to initialize .data and .bss, setup SP, call constructors, etc.? How do you reset the hardware like communication I/O?

There are two issues -

1. I/Os can be initialized in the boot section as the boot loader will
be specific to the target board.

Don't jump to 0.  Use a hardware reset, e.g. WDT.  If that's prohibited
by the hardware because you cannot pick the reset location and would
reenter the boot again, then I'd reset the touched hardware by hand.

2. SP setup etc., will have to be done afresh in the application portion.

This is handled by the startup code by crt*.o and parts of libgcc.a.

When I mentioned calling main, it is actually calling application startup
(00 address). This is not possible any way (I guess).

Maybe you can get away with something like

extern void __attribute__((noreturn))
start_app (int argc) __asm__ ("0");

int x;
void boot (void)
  start_app (x);

or a, at your option, a similar inline assembler construct with
local register variables.

This means you must not pass any data in memory, i.e. you
cannot use the default main interface because argv points
to string array in memory.  Moreover, you will have to save
the data so that it survives startup code.  In the end you
might be better of by passing the data in a fixed RAM location.



[1] http://lists.gnu.org/archive/html/avr-gcc-list/2012-08/msg00056.html

reply via email to

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