[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Loader Building was RE: Please help me.. fernando!
- Date: Wed, 4 Jul 2001 19:04:55 +0200
- From: fernando.ruiz at ctv.es (Fernando RUIZ CASAS (E-mail))
- Subject: Loader Building was RE: Please help me.. fernando!
In my opinion a loader doesn't must to have a OS inside.
The boot prom in the PC bios hasn't a DOS or similar.
Only a stupid loader from initial boot sector or similar.
Do you known that the old IBM-PC had a loader trough the
I have implemented the termios programming serial devices in my
BSP in the device serial drivers .
Several kinds of devices.
* With termios style,
* without it (raw devices avoiding the big overhead),
* with timing in non blocked read/write using
the RTEMS resources (wait with events until the interrupt signals the
reception or transmision, even the end of transmision in order to change
the line status in a half duplex comunication over 485 bus by example.
But all of this always is in the application. The loader always wastes a
little bit of memory and a little monitor to inspect the board status only.
If you want a RTEMS loaded system you need another philosophy.
You need a complete monitor in RTEMS environment.
With the result of your binary compilation you need extract a
list with all the global and public symbols of your bin image.
("num" bintool is perfect to make it)
The prototype includes comunications resources
(your termios posix serial programming)
You need reserve a big section in the memory in order to load
Imaginate a DOS with the memory program space.
Well. With the global symbols address like
You build a asm source like this
.equ _rtems_configuration_table 0x00120030
After the compilation of this source you get a
rtems_globals.o module contains only the
global symbols with the real address in your board.
A new environment of compilation with a new linkcmds ld file
including like availiable area ONLY the memory program space
defined in the RTEMS monitor image. And your need link
the programs with a new rtems_globals.o module before rtemsall.a.
With this system your code call a the global symbol in lieu of
reload the printf code in the new binary image.
Think in a DOS diskete running with the bios adress of memory position and
To call a DOS/BIOS only the intr table is necesary. The rtems global
is your interrupt bios table but for your own RTEMS OS.
In this point the new image binaries contains only the user code leaving at
rom image all the printf(),create_task() and more code routines inside the
You only need a shell (like the COMMAND.COM) in order to manage commands and
new user commands.
In RTEMS YOU HAVE IT.
In order to load new programs if you implement the monitor with tcp/ip you
a shell with telnetd already implmented and ftp to load the new user
programs and data.
A 'run file' command is the only commnand to pass the file binary image
the program area reserved in the PROM rtems image.
After of this a internal rammain() call gives the control at the new binary
file loaded in the reserved area.
This is the well known linux bfd loader by example.
The only big program is the relocation of several programs at same time.
Only a big image file at time is posible. But your new programs can use
the rtems resources with several tasks running.
You need of course set up the PROM image with a lot of rtems resources
like RTEMS TASKS high, and LIBIO_FILE_DESCRIPTORS and SEMAPHORES, etc.
I have already implemented the same net protocol used in my loader
in rtems environment. You can move memory, files, exec remote shells,
and more WITHOUT the BIG OVERHEAD of TCP/IP. Like starting point
is a wonderful place. You can route the packets, reply, snife, and more
like tcp/ip but only the ip/udp philosophy is implemented.
The client programs are builded in Linux and Windows.
A lot of BSP have been builded with the loader net protocol.
400 cpu's are linked now in the stations railway network in Spain.
The sound and the data are transmited with this protocol simple
Do you want more explanation?
Don't worry about of dificulty of this. All of this has been implemented by
me before that I known RTEMS world.
I have litle (80C32) PAD computers with rom/ram code to delivery
and the client programs was in ram but the bios was in rom.
The new version of client program was loaded every time
that the clients link the PAD to the PC server.
The same philosophy.
The user code was very small because the "printf" and more were in ROM.
Fernando RUIZ CASAS
home:correo at fernando-ruiz.com
work:fernando.ruiz at ctv.es
Please CC at two email addres in order to answer you from my house or home.
> -----Mensaje original-----
> De: Deck Su Jang [mailto:iam139 at hanmail.net]
> Enviado el: miercoles, 04 de julio de 2001 15:50
> Para: fernando.ruiz at ctv.es
> Asunto: Please help me.. fernando!
> Hi.. I am student of Knagwon Univ. in South Korea.
> Thank you for your post advices and helps.
> I have a plan to modify download function in your Bootloader.
> The download function uses TFTP to download, So I'll modify
> it as serial downloading.
> I have find out that RTEMS supports POSIX termios library for
> serial programming.
> I compiled your Bootloader program with make command for
> testing. But the binary size was so big. (400k after strip command)
> I thougth as your bootloader includes RTEMS kernel.
> In my think, A bootloader program shouldn't contain any
> operating system. Is this right?
> You said to me that I must compile the loader program with
> m68k-gcc only.. So,
> I had compiled with m68k-gcc, but there was errors as can't
> find serveral header files.
> How can I build a program without RTEMS kernel with RTEMS APIs?
> Everything is too difficult to me..-_-;
> Have a great day with full happiness!
> ?? ???, Daum
> ?? ?? ?? E-mail ?? ????
> ??? ?? ????? Daum??