No longer need to call `conf_load()`

[Christopher Collins]

Hello all,

I am about to merge a PR
(https://github.com/apache/mynewt-core/pull/1075) which eliminates the
need to explicitly call `conf_load()`.  Nothing bad will happen if your
app continues to call `conf_load()`, but the call can be safely removed
after the PR is merged.

Background-
The `sys/config` package is used for persisting data across reboots.  To
restore all the persisted data from flash, an app had to manually call
`conf_load()`, typically from `main()`.  It would be preferable for the
data to get loaded automatically during system initialization, but
this is not possible; the underlying storage containing the config data
is not ready for use until the application explicitly initializes it in
`main()`.  Typically, config data is stored in a flash circular buffer
(fcb), something which sysinit and syscfg know nothing about, and which
must be manually initialzed by the app.  Thus, `conf_load()` during
sysinit would fail.  

The PR referenced above causes `conf_load()` to be called automatically,
but it delays the call until the default event queue begins being
processed.  Typically, the default event queue is processed in an
infinite loop at the end of `main()`, so delaying the call to
`conf_load()` to this point gives `main()` the opportunity to initialize
FCBs and other storage first.

Issue-
Packages may attempt to access persisted data before `conf_load()` has
been called.  This issue has always existed, but the referenced PR
exacerbates it.  This issue can arise in a number of ways:

(1) Package tries to use persisted data during sysinit.
(2) High priority task tries to use persisted data as soon as it starts
running.
(3) Package that runs in the default task tries to use persisted data
immediately after sysinit completes.

(1) and (2) were always an issue.  (3) is a new issue that arises if an
app takes advantage of the automatic call to `conf_load()`.  If your app
uses a package which tries to use persisted data immediately on startup,
then you may want to continue calling `conf_load()` from `main()`.

Thanks,
Chris

Renaming BSP for Nucleo-F767zi board

[Fabio Utzig]

Hello,

Just a heads up, I have a PR (https://github.com/apache/mynewt-core/pull/1092) 
that renames the Nucleo-F767zi BSP which might break some existing targets that 
might be using it. This updates it follow a standard that was used for all 
other STM32 Nucleo boards (nucleo-f303k8, nucleo-f303re, nucleo-f401re, 
nucleo-f413re, nucleo-f413zh).

Best,
Fabio

Re: linking woes with weak linkage

[Andrey Serdtsev]

Hi,

Since every mynewt package built as standalone library, possibly this is 
the case: 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15833.html
Anyway, IMO, it would be better to avoid use of weak linkage. It's a bit 
confusing. May be the better choice is to add some kind of 
stm32_cpu_specific_setup() call to stm32_common package.


BR,
Andrey


On 16.05.2018 05:35, markus wrote:

I'm sure it's just my newt kung-fu that isn't strong enough, here is
what I'm trying to do:

in the package hw/mcu/stm/stm32_common there is a function called
(let's say):

stm32_hal_timer_get_freq

for specific processors I want to overwrite that function, so I
implement the same function in package hw/mcu/stm/stm32f3xx.

Now I tought if I make the implementation in stm32_common a weak symbol
the linker would pick up the processor specific version if one was
supplied.

As it turns out that's not the case. The reason seeming to be that
stm32_common is linked before stm32f3xx, so the linker resolve the
symbol from stm32_common.

If I rename the package "stm32_common" to "~stm32_common" it gets
linked after "stm32f3xx" and the linker picks up the correct
implementation.

Is there a better way of telling newt to link one library before
another one?

Note that the stm32f3xx package has a dependency on the
stm32_common package