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

[Georg-Johann Lay]

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?

Yes.

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);
  __builtin_unreachable();
}

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.

Johann

--

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