Details | Last modification | View Log | RSS feed
| Rev | Author | Line No. | Line |
|---|---|---|---|
| 1601 | tullio | 1 | --------------------------------------------- |
| 2 | Dynalink Demo. |
||
| 3 | --------------------------------------------- |
||
| 4 | This is the Dynalink for S.H.A.R.K demo. |
||
| 5 | Source files are in /shark/projects/dynademo |
||
| 6 | The SHARK kernel and the user application |
||
| 7 | are compiled seperatly by; |
||
| 8 | |||
| 9 | make_os.mk |
||
| 10 | make_app.mk |
||
| 11 | |||
| 12 | The resulting OS kernel file is a default |
||
| 13 | SHARK mutliboot compliant ELF executable. |
||
| 14 | The resluting user Application is an ELF object file. |
||
| 15 | |||
| 16 | Also included is a small test data.bin file |
||
| 17 | to illustrate the use of extra data module parsing through GRUB. |
||
| 18 | |||
| 19 | The idea is to boot the SHARK kernel through GRUB, |
||
| 20 | and parsing the User Application plus any needed |
||
| 21 | data files as 'boot modules'. |
||
| 22 | GRUB usage example: |
||
| 23 | |||
| 24 | # For booting SHARK image from HD |
||
| 25 | title S.H.A.R.K + Boot Modules from HD 0,0 |
||
| 26 | kernel (hd0,0)/boot/os mount root=/dev/hda1 |
||
| 27 | module (hd0,0)/boot/sh_app.bin |
||
| 28 | module (hd0,0)/boot/data.bin |
||
| 29 | |||
| 30 | This could be a possible solution to get by |
||
| 31 | certain GPL restrictions since no GPL code |
||
| 32 | resides in the user application. |
||
| 33 | The user application is dynamicly linked |
||
| 34 | after the kernel is loaded. |
||
| 35 | |||
| 36 | Another advantage is that we have a simple |
||
| 37 | way of loading data files without the need for |
||
| 38 | an IDE-driver plus Filesystem. |
||
| 39 | Good enough for a few embedded solutions. |
||
| 40 | |||
| 41 | ------------------------------------------------------------- |
||
| 42 | Dynalink code |
||
| 43 | ------------------------------------------------------------- |
||
| 44 | The Dynalinker is based on Luca Abenia's code |
||
| 45 | as used in the FD32 project. |
||
| 46 | Source files are in /shark/dynalink |
||
| 47 | The Dynalink makefile produces libdynalink.a |
||
| 48 | which is compiled into the kernel by adding SHARKOPT =" __DYNALINK__" |
||
| 49 | |||
| 50 | Also not that I added a section to config.mk as |
||
| 51 | you can see in the included config.mk |
||
| 52 | |||
| 53 | # added for dynalink [lex] |
||
| 54 | ifndef DYNALINK |
||
| 55 | LINK_OPT = -Bstatic -Ttext $(MEM_START) -s -nostartfiles -nostdlib -L$(LIB_PATH) -L$(OSLIB_PATH) |
||
| 56 | else |
||
| 57 | LINK_OPT = -Bstatic |
||
| 58 | endif |
||
| 59 | |||
| 60 | Operation: |
||
| 61 | The Dynalinker supports only ELF objects. |
||
| 62 | Everything else is loaded and treated as Data objects. |
||
| 63 | |||
| 64 | After the SHARK kernel is booted it will execute main() |
||
| 65 | which sole purpose here is to process all parsed |
||
| 66 | boot modules, link any valid ELF objects |
||
| 67 | and put the results in a dynalink_module_list struct. |
||
| 68 | This struct is then used to run the actual User Application |
||
| 69 | and to hold info about possible data files in memory |
||
| 70 | that the User Application can use. |
||
| 71 | |||
| 72 | The dynalinker uses a syscall_table to export/import the symbols. |
||
| 73 | (review dynalink.c) |
||
| 74 | Not all SHARK/Library functions needs to be exported! |
||
| 75 | This is of course just an example. |
||
| 76 | |||
| 77 | |||
| 78 | /Lex Nahumury 5:41 19-7-06 |
||
| 79 | |||
| 80 | |||
| 81 | |||
| 82 | |||
| 83 |