Skip to content

core/include/init.h: a new initialization concept #4155

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 35 commits into from
Closed

core/include/init.h: a new initialization concept #4155

wants to merge 35 commits into from

Conversation

jfischer-no
Copy link
Contributor

This PR introduces another initialization concept for core, subsystems and drivers.

Currently the RIOT will be initialized somehow like:

reset_isr
 |-------------- board_init
 |                    |--------------------- leds_init
 |                    L--------------------- cpu_init
 |
 |-------------- __libc_init_array
 |                    L--------------------- _init
 |                                              L-------------- uart_stdio_init
 |
 L-------------- kernel_init
                      L---------------------- idle
                      L---------------------- main_trampoline
                                                |-------------- auto_init
                                                L-------------- main

This PR uses macros to make sorted function pointers and place it in a particular area. The macros are sorted by the linker. After the reset, the assorted functions are called in a defined order.
Currently the loop inside __libc_init_array will be used to call the functions. Of course we can move the loop to reset_isr. Advantage is that the drivers and subsystems can initialize itself in defined order. You do not need to change/complete auto_init if you will add new driver or subsystem.

With this PR the RIOT can be initialized somehow like:

reset_isr
 |--------------------- leds_init
 |--------------------- cpu_init
 |--------------------- core (logging, scheduler, idle ?)
 |--------------------- drivers (register drivers)
 |--------------------- uart_stdio_init
 |--------------------- subsystem
 |--------------------- system (networking, usbdev stack)
 |--------------------- auto_init
 L--------------------- main_trampoline
                               L--------------------- main

This PR is WIP and works only on ARMs. I need help to get it adapted for MSP430 and AVR.

Well then, what do you think about it?

@jfischer-no jfischer-no added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet Area: core Area: RIOT kernel. Handle PRs marked with this with care! Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR labels Oct 26, 2015
@kaspar030
Copy link
Contributor

interesting.

some thoughts & questions:

  • we've been avoiding linker magic so far. have to rediscuss this.
  • we're executing all auto_init within main's stack in order to keep the ISR stack minimal. guess that could be easily changed.
  • why differentiate core, module, submodule?
  • how do you realize conditional auto_init (if defined (A) && defined (B) auto_init (C) endif)?

This PR is WIP and works only on ARMs. I need help to get it adapted for MSP430 and AVR.

One of the reasons we're still managing auto_init.c by hand...

@Kijewski
Copy link
Contributor

I think auto_init has to be done in the main thread because it might spawn threads. I think there was a problem once upon a time when auto_init was invoked in the start-up sequece before the threading was started.

This was referenced Oct 27, 2015
Closed
Closed
@OlegHahm OlegHahm modified the milestone: Release 2016.03 Dec 8, 2015
@jfischer-no jfischer-no mentioned this pull request Jan 26, 2016
Merged
@haukepetersen
Copy link
Contributor

Though I think this approach is quite elegant for cortex based platforms, I am still very skeptical about linker section based approaches that have to be followed/implemented by all platforms. Especially for MSP430 and AVR8 we are (as the standard toolchains dictate this) using supplied linker scripts, which we can't easily edit. So making this approach work for all RIOT supported platforms would mean that we get this PR to work even with those untouched linkerscripts. So I guess the next step needs to be showing that this concept here will also work for those platforms.

@jfischer-no
Copy link
Contributor Author

Should work out of the box for msp430 and AVR8, not have hardware for testing yet, but:

objdump -t bin/arduino-mega2560/init_test.elf

00800496 l     O .preinit_array.2.submod        00000002 __initcall_submod_init_test2
00800498 l     O .preinit_array.3.module        00000002 __initcall_module_init_test3
0080049a l     O .preinit_array.1.driver        00000002 __initcall_driver_init_test1
0080049c l     O .preinit_array.0.core  00000002 __initcall_core_init_test0

objdump -t bin/msb-430/init_test.elf

00000200 l     O .preinit_array.2.submod        00000002 __initcall_submod_init_test2
00000202 l     O .preinit_array.3.module        00000002 __initcall_module_init_test3
00000204 l     O .preinit_array.1.driver        00000002 __initcall_driver_init_test1
00000206 l     O .preinit_array.0.core  00000002 __initcall_core_init_test0

@jfischer-no
Copy link
Contributor Author

Someone who has the hardware, MSP430 and Arduino (AVR), please can you test it for me?

@kaspar030
Copy link
Contributor

both show this:

2016-01-27 23:33:22,807 - INFO # init_pattern: 0x00000000

@kaspar030
Copy link
Contributor

@jfischer-phytec-iot: the functions should be called by the c library's constructor, right? are we sure those little libc's even have those?

@jfischer-no
Copy link
Contributor Author

@kaspar030

are we sure those little libc's even have those?

No, that's why I want to implement the init loop (current it uses one in the newlib) as an autoinit function (riots auto init). WIP. I try to organize the hardware.

@kaspar030
Copy link
Contributor

@jfischer-phytec-iot let's generalize this (see #4290).

Can we make the interface something like

INIT(group, size, priority)

with group being autoinit, netdev, saul, ... (different handlers...), and a size field so that structs can be put in there?

edit I don't like INIT as name, but can't come up with a better one currently...

@PeterKietzmann
Copy link
Member

Will the milestone change to over next release

@PeterKietzmann PeterKietzmann modified the milestones: Release 2016.07, Release 2016.04 Mar 23, 2016
@jfischer-no jfischer-no mentioned this pull request Jun 1, 2016
Closed
jfischer-no added 18 commits June 5, 2016 16:06
@jfischer-no
drivers/hdc1000: add saul interface
79bc71b
@jfischer-no
drivers/Makefile.include: add UNDEF for hdc1000_saul
a141355
@jfischer-no
boards/pba-d-01-kw2x: add hdc1000_params
0ce9dc1
@jfischer-no
boards/pba-d-01-kw2x/Makefile.dep: add hdc1000
ec1f1e3
@jfischer-no
drivers/mag3110: add saul interface
4fbda44
@jfischer-no
drivers/Makefile.include: add UNDEF for mag3110_saul
1b9a399
@jfischer-no
boards/pba-d-01-kw2x: add mag3110_params
3ae6a8c
@jfischer-no
boards/pba-d-01-kw2x/Makefile.dep: add mag3110
a5dd57b
@jfischer-no
drivers/tcs37727: add saul interface
9d02fd0
@jfischer-no
drivers/Makefile.include add UNDEF for tcs37727_saul
050ec86
@jfischer-no
boards/pba-d-01-kw2x: add tcs37727_params
392661c
@jfischer-no
boards/pba-d-01-kw2x/Makefile.dep: add tcs37727
8bb29f5
@jfischer-no
drivers/tmp006: add saul interface
3656010
@jfischer-no
drivers/Makefile.include: add UNDEF for tmp006_saul
036bd3e
@jfischer-no
boards/pba-d-01-kw2x: add tmp006_params
c8daea8
@jfischer-no
boards/pba-d-01-kw2x/Makefile.dep: add tmp006
3623cf6
@jfischer-no
cpu/samd21: use core_init
5e37fcc
@jfischer-no
boards/samr21-xpro: use new init procedure
82eb149
@kYc0o
Copy link
Contributor

kYc0o commented Jul 25, 2016

WIP -> postponed.

@kYc0o kYc0o modified the milestones: Release 2016.10, Release 2016.07 Jul 25, 2016
@miri64
Copy link
Member

miri64 commented Oct 31, 2016

Postponed due to feature freeze

@miri64 miri64 modified the milestones: Release 2017.01, Release 2016.10 Oct 31, 2016
@OlegHahm OlegHahm removed this from the Release 2017.01 milestone Jan 15, 2017
@OlegHahm
Copy link
Member

Let's remove the milestone until @jfischer-phytec-iot indicates that he has time to work on this again (or someone else picks it up).

@jfischer-no jfischer-no deleted the pr@system-init branch January 23, 2017 09:15
@OlegHahm
Copy link
Member

Development Procedures no. 10: "Closing an issue or pull request must always be accompanied by a comment indicating why it gets closed."

@jfischer-no
Copy link
Contributor Author

Also here, sorry, excessive cleansing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@haukepetersen haukepetersen

Labels
Area: core Area: RIOT kernel. Handle PRs marked with this with care! Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
8 participants
@jfischer-no @kaspar030 @Kijewski @haukepetersen @PeterKietzmann @kYc0o @miri64 @OlegHahm