Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[STM]32 FreeRtos #1

Open
tb-killa opened this issue May 7, 2014 · 10 comments
Open

[STM]32 FreeRtos #1

tb-killa opened this issue May 7, 2014 · 10 comments

Comments

@tb-killa
Copy link

tb-killa commented May 7, 2014

Hello,

i see your nice Code and show if I could get them understandable.

We work on some Sort of STM32 Board with FreeRtos as Base System.
I check if i get some Sort of Dynamic "Apps" (each FreeRtos Thread) with Position Independent Code working.

Do you done something like this maybe ?

First of all I will check if I get your Code working with STM32 Processor Type.

Please tell me which Parts I have to check !?

Best regards

Oliver

@wictory
Copy link
Member

wictory commented May 8, 2014

Hi,

the code is capable of doing run-time and task migration, and includes a run-time dynamic linker. A link to a publication on run-time updating is here http://tucs.fi/publications/attachment.php?fname=inpHoLuLaLi13c.full.pdf . You could start with looking at a simple run-time updating example in rtdl/System/arch/arm9_novm/arm9_rtudemo/main.c which changes the software running in a thread between rtuappv1 and rtuappv2. The apps reside in rtdl/App/rtu_appv1.c and rtdl/App/rtu_appv2.c respectively.

We have not run the software on STM32, but I do not why it couldn't run on that as well since we have run it on both arm9 and cortex-a9 already.

Best regards
Wictor

@tb-killa
Copy link
Author

tb-killa commented May 8, 2014

Hi Wictor,

thank you very much for the Answer.

I check your PDF File. ... looks cool ...

If I use my memory bank (1Mb) and i know that every "App" would be max
sized lets say 30kb (check if App would be build) ...
I could build up the half of memory bank (500kb) and build a bank sized
memory bank [bank 1 / bank 2 / bank ...]
If i now build my "App" with my own linker Script lets you do it with the
"App" linker Script and build them with -fpic or -fpie in elf format
(position independent Code)
i could put them with my own writer Script to one of my banks right ???

If i know the Address of the Bank Nr. (Start + End) I could easy point to
the "App" Thread from the Elf Header right ???

Hope you understand what I will do ??

Best regards

Oliver

2014-05-08 11:42 GMT+02:00 Wictor Lund [email protected]:

Hi,

the code is capable of doing run-time and task migration, and includes a
run-time dynamic linker. A link to a publication on run-time updating is
here
http://tucs.fi/publications/attachment.php?fname=inpHoLuLaLi13c.full.pdf. You could start with looking at a simple run-time updating example in
rtdl/System/arch/arm9_novm/arm9_rtudemo/main.c which changes the software
running in a thread between rtuappv1 and rtuappv2. The apps reside in
rtdl/App/rtu_appv1.c and rtdl/App/rtu_appv2.c respectively.

We have not run the software on STM32, but I do not why it couldn't run on
that as well since we have run it on both arm9 and cortex-a9 already.

Best regards
Wictor


Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-42530608
.

@wictory
Copy link
Member

wictory commented May 9, 2014

Hi,

I think I understand what you mean, and it sounds possible. You can set up task register entries with task_register(name_of_task, address_of_elfh), and remove them if necessary. You should remember that if you want to link "App" to symbols in the OS, you will though need the symbols from the OS somewhere, we have done it so that the OS itself is an ELF binary with symbols included.

Could you tell me more about your use-case, are all of the elf's included in the binary at compile-time, or will you download new ones at some later stage? This might matter for how you want to perform your linking process.

Best regards
Wictor

@tb-killa
Copy link
Author

tb-killa commented May 9, 2014

Hi

I use my STM32F429 Discovery Board. It included Graphic Display and
Touchscreen so i could easily Debug my Code.

These Typ of Board use 2 x 1MB Flash Storage Banks:

I build up some Sort of OS which stands on top of Freertos.

Src]
--[Core] Contains Std Librarys and other Stuff like Hardware Layers ...
--[Boot] Contains IAP Bootloader Stuff for getting Over the Air Updates /
Pushing / Deleting Apps working
--[FW] Contains Vendor Stuff like FreeRtos / Bluetooth Stack

I build up my own Bootloader with the IAP Methods from STM.
I check on UART Port for some magic Strings and let the IAP Bootloader
start.

My Flash Storage Bank is divided into different Parts
[Bootloader][Recovery][OS][Bank1][Bank2][Bank.........]

From now I would build up different "Apps" who are at Real own Applications
run in seperated FreeRtos Tasks with Full Access to the Hardware of my
Board.

For these Stepp I create my own library (static) which contains the
Functions who needing for my different Types of Apps (Graphics / Hardware
Layer like GPIO).

Lets says we build one App called "LED-Blink".

I build up my Folder Structure like these:

[FolderName:LED-Blink]
-include
--library header files (.h)
-library
--library file (
.a)
-src
--LED-Blink file (*.c)
--app.ld File

Should I build up in my ld file own Entry Point ?

For the Future Part of Work I will bring the ld file to the minimalist i
can.

ENTRY(??????)

MEMORY

{

APP (rwx) : ORIGIN = 0, LENGTH = 24K

}

SECTIONS

{

.text :

{

    *(.text)

    *(.text.*)

    *(.rodata)

    *(.rodata*)

} > APP
.data :
{

    KEEP(*(.data))

    *(.data.*)

} > APP
.bss :
{

    *(.bss)

    *(.bss.*)

} > APP
DISCARD :
{

    libc.a ( * )

    libm.a ( * )

    libgcc.a ( * )

    *(.eh_frame)

}

}

Could I build up like these schematic ??

I will build each App with only the one ld File so in the Near of Future
another Person could also build up Apps without have to modificate these
Parts.
The App should compiled at the own One so the Core OS is Compiled at own
too ...

On Upload i show for free App-Banks and flash them to one of these Banks ..
I could define in my own Code the Start and End Address of each Bank so i
could use them to point to these App.

For these Apps I will bring in some Sort of TaskManager.

Init: Allocating Memorie
APP-Loop: The working Code
DeInit: Release Memorie

At the moment everything is working except for the dynamic app integration.
My first Tests are done with only one Compile of binary ... everything
static ... like normal Build ....

Hope you could follow my Dev Process ;) ?

Best regards

Oliver

2014-05-09 9:26 GMT+02:00 Wictor Lund [email protected]:

Hi,

I think I understand what you mean, and it sounds possible. You can set up
task register entries with task_register(name_of_task, address_of_elfh),
and remove them if necessary. You should remember that if you want to link
"App" to symbols in the OS, you will though need the symbols from the OS
somewhere, we have done it so that the OS itself is an ELF binary with
symbols included.

Could you tell me more about your use-case, are all of the elf's included
in the binary at compile-time, or will you download new ones at some later
stage? This might matter for how you want to perform your linking process.

Best regards
Wictor


Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-42640104
.

@wictory
Copy link
Member

wictory commented May 9, 2014

Hi,

I think I got the important parts. In the ELF header there is a always an entry point, it is set to the symbol start if nothing else is specified. You can read more abount it here: http://www.math.utah.edu/docs/info/ld_3.html#SEC19

Unfortunately, currently the code will load the code into volatile memory from the ELF's, I'm not sure if this is ok for you. At some point we ran the code directly from the ELF's but because of our choice of platform we decided to go this way. If you are interested I could look into how this change could be reverted.

Best regards
Wictor

@tb-killa
Copy link
Author

Hi wictor,

Is the entry point in the elf header which i could point to start the
application code?

If my code base for the dynamic loadable stuff is working i will check if i
could modified the elf header for other included Information like app
name,crc check,other variables.

Please explain the two parts you describe:

load the code into volatile memory from the ELF's

ran the code directly from the ELF's

After that describe i could say if you should tell me how to revert your
pointed changes.

Oliver

2014-05-09 15:40 GMT+02:00 Wictor Lund [email protected]:

Hi,

I think I got the important parts. In the ELF header there is a always an
entry point, it is set to the symbol start if nothing else is specified.
You can read more abount it here:
http://www.math.utah.edu/docs/info/ld_3.html#SEC19

Unfortunately, currently the code will load the code into volatile memory
from the ELF's, I'm not sure if this is ok for you. At some point we ran
the code directly from the ELF's but because of our choice of platform we
decided to go this way. If you are interested I could look into how this
change could be reverted.

Best regards
Wictor


Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-42666547
.

@wictory
Copy link
Member

wictory commented May 12, 2014

Hi,

Is the entry point in the elf header which i could point to start the
application code?

Yes. The entry point in the ELF header is the relative address from
where the application code starts.

Please explain the two parts you describe:

load the code into volatile memory from the ELF's

We currently use a corresponding procedure to what is used in Linux
(and other OS), i.e. to copy or just allocate all sections in the ELF
according to the relative addresses specified in the ELF. In practice
we allocate a continuous memory region of volatile to which we copy the
code sections, so that the data sections of the APP will be relative to
this. The downside of this is that the code segments will have to
reside in volatile memory, if there is not virtual memory available.

ran the code directly from the ELF's

This way of execution is not currently support (as I mentioned
earlier). Here we execute the code directly from flash but we (usually)
need to map the static memory regions to a static memory address, and
we can't use PIC.

Best Regards
Wictor

@tb-killa
Copy link
Author

Hi Wictor,

Okay from now I understand.

I start with Porting your Code to my Dev Basement.
First of all i check your Code for understanding .

Do you know some Tools for checking my Compiled "App.elf" file ?
If i Convert my elf to Bin ... does all the Informations like Entry Point
and so on are availible ?

And in your App Folder you have the app_startup.S File:

.global _start

.global main

_start:

B main

Why does this File exists and does we need them theoreticly ?

Could you explain what does these file exactly should done ?

With best regards

Oliver

2014-05-12 9:51 GMT+02:00 Wictor Lund [email protected]:

Hi,

Is the entry point in the elf header which i could point to start the
application code?

Yes. The entry point in the ELF header is the relative address from
where the application code starts.

Please explain the two parts you describe:

load the code into volatile memory from the ELF's

We currently use a corresponding procedure to what is used in Linux
(and other OS), i.e. to copy or just allocate all sections in the ELF
according to the relative addresses specified in the ELF. In practice
we allocate a continuous memory region of volatile to which we copy the
code sections, so that the data sections of the APP will be relative to
this. The downside of this is that the code segments will have to
reside in volatile memory, if there is not virtual memory available.

ran the code directly from the ELF's

This way of execution is not currently support (as I mentioned
earlier). Here we execute the code directly from flash but we (usually)
need to map the static memory regions to a static memory address, and
we can't use PIC.

Best Regards
Wictor


Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-42804379
.

@wictory
Copy link
Member

wictory commented May 14, 2014

Hi Oliver,

Do you know some Tools for checking my Compiled "App.elf" file ?
If i Convert my elf to Bin ... does all the Informations like Entry
Point and so on are availible ?

When you convert to bin, virtually all metadata disappears. The dynamic
linker needs this metadata.

And in your App Folder you have the app_startup.S File:

.global _start

.global main

_start:

B main

Why does this File exists and does we need them theoreticly ?

No it's not really needed you could just put the entry point to main.

Could you explain what does these file exactly should done ?

The idea behind this file is that it could contain whatever bootstrap
code needed to start up an App, it turned out it was never needed.

Best regards,
Wictor

@avinashckumar
Copy link

Hi Oliver, Wictor,

I, also am trying to get dynamic linking in FreeRTOS on an STM32 and I found this repo and thread very interesting. Still trying to get my head around all the docs and information.
Were you able to get this running, or did you have any major roadblock regarding this? Any help would be great!

Best Regards,
Avinash

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants