Pavel, thanks for the excellent detail provided. I will try and expand
on a couple of parts being discussed.
On 27/07/2016 10:00, Pavel Pisa wrote:
On Wednesday 27 of July 2016 01:01:29 Saeed Ehteshamifar wrote:
1. How to generate *tar* array? Since on top of dl-tar.c it's been noted
that it's automatically generated. If I'm not wrong, by making a tar image,
RTEMS puts all binary objects within a single tar file and calls them
dynamically at run-time, right?
I am not sure at this moment, how it is done by mainline samples makefiles
but simplified command sequence from my examples follows.
The rtems_waf support (https://git.rtems.org/chrisj/rtems_waf.git/) now
provides a simple way to add files via an embedded tar file to an
executable. You can:
rtems.root_filesystem(bld, 'rootfs',
['etc/rc.conf',
'x',
'y',
'z'],
'rootfs.tar', 'rootfs-tar.o')
Just add 'rootfs-tar.o' to list of source to link. Add code to your
application to untar the files:
extern int _binary_rootfs_tar_start;
extern int _binary_rootfs_tar_size;
static void
expand_rootfs_tarfile(void)
{
rtems_status_code sc;
rtems_printer printer;
rtems_print_printer_printf(&printer);
sc = Untar_FromMemory_Print((void *)(&_binary_rootfs_tar_start),
(size_t)&_binary_rootfs_tar_size,
&printer);
if (sc != RTEMS_SUCCESSFUL)
fprintf(stderr, "error: untar failed: %s\n",
rtems_status_text(sc));
}
2. What's the difference between dl01.exe and dl01.pre? Both are executable
but running dl01.pre leads to "unresolved externals" and the execution
hangs.
You need to link list of symbols to the base executable image
to inform runtime linker which symbols are available.
There are two ways you can manage symbols and it depends on your system
architecture and available services in your running target.
You can embed the symbols in the base image. To do this you need two
link passes. The first link pass brings the executable together so you
can get a list of symbols. This is used to create a symbol table you add
to the second link pass. The way the symbol table is created and linked
allows it to adjust to a different memory map created by the second link
pass.
The second method is loading an external symbol table. This is a single
link process and again you create a symbols object file which is
external. Instead of a 2nd phase of linking you simply make the symbol's
object file available to the running target and you dynamically load it
before any other modules. In this case the symbol addresses are fixed to
the addresses in the executable.
An example of an embedded symbol table is a target that does not have a
flash file system or a network to load external symbols. It is also used
when you do not want to have to configuration control the kernel image
and the symbols. The two link passes added complexity to your build system.
An example of external symbols is a team development environment where a
boot loader such as iPXE or uboot loads a kernel from the network and
you load the symbols via the network as well. When you move to a
production build the symbols are loaded into a local file system.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
