Loader Building was RE: Please help me.. fernando!

Wed Jul 4 17:04:55 UTC 2001

Hi.
 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
 keyboard socket?

 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
 ram programs.
 Imaginate a DOS with the memory program space.

 Well. With the global symbols address like

  rtems_configuration_table 0x00120030

 You build a asm source like this

   .text
   .global _rtems_configuration_table
   .equ    _rtems_configuration_table 0x00120030
   ...
   .end

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
functions
 availiables.
 To call a DOS/BIOS only the intr table is necesary. The rtems global
symbols module
 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
the
rom image all the printf(),create_task() and more code routines inside the
PROM.

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
have also
 a shell with telnetd already implmented and ftp to load the new user
programs and data.
 (New files).
 A 'run file' command is the only commnand to pass the file binary image
into
 the program area reserved in the PROM rtems image.

 After of this a internal rammain() call gives the control at the new binary
image
 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
 but useful.

 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검색
> http://www.daum.net
>