Hi,
1) It seems like moving the bootloader over to FCB would be a good
thing. I don’t understand requiring both a NFFS and FCB implementation.
Why not just FCB to keep things simple?
2) I have one feature request or maybe it is a design change.
Currently the when talking to the OS and getting a list of images
it replies with the version of the image. Versions are fine and
I think the OS needs to reply with version info. However I think
the images should be indexed and stored via the firmware image’s
embedded buildid. I would like the buildid to be The-One-True-Id
for a build. Given that it is a SHA256 of the firmware it would
be exceedingly rare to have a SHA256 collision vs having collisions
in user supplied versions. Therefore if the image list could reply
with something like:
{
"Images": [
[“f50200f8256235434440c73dc79705daf1462d23395e7b6e0f299a78946b5159”,
“1.2.3.4"],
[“7723a4bad19e23989ba4dad1b593e44a950a7fe9b10163fdd25a577454caf9e2”,
“1.2.3.4"]
]
}
or even,
{
"Images": [
“f50200f8256235434440c73dc79705daf1462d23395e7b6e0f299a78946b5159:1.2.3.4",
“7723a4bad19e23989ba4dad1b593e44a950a7fe9b10163fdd25a577454caf9e2:1.2.3.4"
]
}
then we have good visibility into what the device really has.
-res
> On Apr 7, 2016, at 12:24 PM, marko kiiskila <[email protected]> wrote:
>
> Hi,
>
> I went through the same though process, and ended in same place :)
>
> We can avoid code duplication by having a version of slinky that has
> #if directives for NFFS vs FCB specific pieces. And then have other
> apps that includes this slinky, while selecting between the 2 options.
> And then specifying target you could pick one of these.
>
> But I’m not keen on that one either, because I feel it would make it
> harder to understand what exactly it is that you’re building.
>
> And like you say, this is only problem for these sample apps of ours,
> which we’ve tried to make as generic as possible.
>
>> On Apr 7, 2016, at 11:25 AM, Christopher Collins <[email protected]> wrote:
>>
>> Upon reflection, this idea has problems of its own. The app still
>> needs to initialize the specific flash storage package being used. So,
>> sorry for posting before thinking! The idea could be salvaged with the
>> use of some #if directives in the app code, but I am not sure this is
>> any better than duplicating the entire app.
>>
>> I think the problem you described won't be applicable to most apps. The
>> example apps are affected by this because they are meant to be as
>> generic as possible.
>>
>> Chris
>>
>> On Thu, Apr 07, 2016 at 11:03:07AM -0700, Christopher Collins wrote:
>>> That mostly sounds good to me, though I agree that the need to duplicate
>>> app code is not ideal.
>>>
>>> Here is an alternative idea:
>>> * Both fs and fcb export a suitable API (e.g., "bootapi").
>>> * By default, apps depend on nffs.
>>> * If a particular feature is set in the target, the app depends on
>>> fcb instead.
>>>
>>> Something like:
>>>
>>> pkg.deps.base:
>>> - libs/os
>>> - sys/log
>>> - libs/newtmgr
>>> - libs/console/full
>>> - libs/shell
>>>
>>> pkg.deps: [pkg.deps.base, fs/nffs]
>>> pkg.deps.FCB_BOOT.OVERWRITE: [pkg.deps.base, sys/config, sys/fcb]
>>>
>>> I may have gotten the yaml syntax wrong, but I think the concept works.
>>>
>>> Chris
>
