Re: [avr-gcc-list] Parm to application
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
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Parm to application
From: Bob Paddock Subject: Re: [avr-gcc-list] Parm to application > Calling main from boot does not sound sane. >BootLoaders end by jumping (using a call would not be sane) to >absolute address zero. >The vector table from address zero takes care of getting to the the >first .init section and in turn main(). Yes I am doing a jump to 00 from boot loader when I am done. In fact while in boot loader the vector table is shifted to boot section as I am using some interrupts and before going to application section, vector table is shifted back to 00. This is working fine. Regards Nayani___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Parm to application
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?
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.
>> 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.
2. SP setup etc., will have to be done afresh in the application portion. When
I mentioned calling main, it is
actually calling application startup (00 address). This is not possible any way
(I guess).
Thank you.
Regards
Nayani___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Parm to application
> Calling main from boot does not sound sane. BootLoaders end by jumping (using a call would not be sane) to absolute address zero. The vector table from address zero takes care of getting to the the first .init section and in turn main(). ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Parm to application
Parthasaradhi Nayani schrieb:
From: Georg-Johann Lay
Reserve a piece of RAM that does not depend on how the application
is compiled, for example at the start of .data (bump .data to a later
location) or at the top of the stack (initialize SP to RAMEND-offset).
In the boot loader, write the data to that reserved space.
It should also be okay to call main from .init8 by hand if
you prefer C, e.g.
main (argc, argv);
_exit (0);
or
main (argc, argv, env);
_exit (0);
Hello Johann,
Thank you for your reply. Yes this was one approach that is possible,
but it is pretty much dependent on absolute address. Passing arguments
to main is actually not possible in a bare bone system right?
An outline of a possible approach is above. You'll have to call main
from the startup code or fallthu to .init9.
*Any* LDS depends on absolute addresses, and likewise any address
computation. There is nothing like position independent data or
dynamic linking or GOT tables or MMU on AVR...
Just use symbolic addresses as usual, put them in dedicates sections,
and arrange your linker script and/or command options and startup
code to (co)operate with them.
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.
or is there any method?
See above
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?
Johann
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Parm to application
From: Wim Lewis To: avr-gcc-list@nongnu.org >The problem I see is that the boot loader doesn't necessarily run every >time the mcu is started (unless BOOTRST is set). In my case BOOTRST is set, so every time there is a reset, boot loader is invoked. >You could define a static variable in SRAM or EEPROM which the >bootloader could write some information to, if you wanted a simple way >to communicate from the bootloader to the main application, but you'd >also have to detect the common case where the bootloader didn't run >first and RAM has random or old data in it. (Similarly the bootloader >could put some special values in registers; you'd have to modify the >startup routine not to clobber them.) Yes it is possible to use EEPROM, but I was looking for a more ideal solution. The best will be to call application main with parameters this is not possible in this kinda situation (bare bones system) or is it? >You might be better off stepping back and considering whether the >problem you are trying to solve really requires communication between >the bootloader and the main program at all. Thanks for the suggestion. In fact I am actually trying to prune down boot code and change the application side. However I am still curious to know if there is a method of calling main with arguments!! Thank you for your time. Regards Nayani ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Parm to application
From: Georg-Johann Lay >Reserve a piece of RAM that does not depend on how the application >is compiled, for example at the start of .data (bump .data to a later >location) or at the top of the stack (initialize SP to RAMEND-offset). >In the boot loader, write the data to that reserved space. >It should also be okay to call main from .init8 by hand if >you prefer C, e.g. > main (argc, argv); > _exit (0); >or > main (argc, argv, env); > _exit (0); Hello Johann, Thank you for your reply. Yes this was one approach that is possible, but it is pretty much dependent on absolute address. Passing arguments to main is actually not possible in a bare bone system right? or is there any method?I would actually prefer to call application main with parameters from boot section. Regards Nayani___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Parm to application
Parthasaradhi Nayani schrieb: Hello all, I have a boot loader and an application on a Mega168. As boot loader and application are two different entities, is there any way the boot loader can pass a parameter to application code? Would like something like main (int argc, char *argv[]) Reserve a piece of RAM that does not depend on how the application is compiled, for example at the start of .data (bump .data to a later location) or at the top of the stack (initialize SP to RAMEND-offset). In the boot loader, write the data to that reserved space. In the application, write a startup function for section .init8, preferably as naked assembler, that reads that data and prepares it according to the ABI, i.e. pass argc in r24/25 etc. Then call main (int, char*[]) and receive the arguments. It should also be okay to call main from .init8 by hand if you prefer C, e.g. main (argc, argv); _exit (0); or main (argc, argv, env); _exit (0); Johann ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Parm to application
On 8/25/12 10:35 PM, Parthasaradhi Nayani wrote: > Hello all, > I have a boot loader and an application on a Mega168. As boot loader and > application are two different entities, is there any way the boot loader > can pass a parameter to application code? Would like something like main > (int argc, char *argv[]). Any suggestions please? Thank you. The problem I see is that the boot loader doesn't necessarily run every time the mcu is started (unless BOOTRST is set). You could define a static variable in SRAM or EEPROM which the bootloader could write some information to, if you wanted a simple way to communicate from the bootloader to the main application, but you'd also have to detect the common case where the bootloader didn't run first and RAM has random or old data in it. (Similarly the bootloader could put some special values in registers; you'd have to modify the startup routine not to clobber them.) You might be better off stepping back and considering whether the problem you are trying to solve really requires communication between the bootloader and the main program at all. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] Parm to application
Hello all, I have a boot loader and an application on a Mega168. As boot loader and application are two different entities, is there any way the boot loader can pass a parameter to application code? Would like something like main (int argc, char *argv[]). Any suggestions please? Thank you. Regards, Nayani ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
