Yep; that clarifies things for me. Thanks!
> On Jun 21, 2016, at 2:09 PM, [email protected] wrote:
>
>
> The example was simplified to give folks the general idea.
>
> Practically, the loader=AIIC code would include whatever someone wanted it
> to include and it would compile and link as a stand alone app; in this
> case I used Bluetooth stack and firmware upgrade as an example. The AIDC
> would contain the stuff that is NOT in the AIIC.
>
> So to give a more complex case, suppose the AIIC used 60% of the bluetooth
> stack, that¹s all that would be included in there. If the application
> used 100% of the bluetooth stack, the remainder would be in the AIDC.
>
> This is a consequence of linking the AIIC as a stand-alone app, and then
> linking the AIDC using all the symbols present in the AIIC.
>
> Does that help or make it more confusing?
>
> Code would not be upgraded independently, as the AIDC is hard-linked to
> fixed symbol addresses in the AIIC. While it might be possible to create
> a new AIDC that used the same symbols from the AIIC, I was not intending
> to allow that.
>
> Paul
>
> On 6/21/16, 1:54 PM, "will sanfilippo" <[email protected]> wrote:
>
>> +1 on idea 1.
>>
>> Just a point of clarification though: why do you specfically break out
>> (in your example) the bluetooth stack size and the upgrade code size? I
>> think I was originally thinking about things slightly differently here in
>> that the bluetooth stack and upgrade image were combined into one ³image²
>> (they would not be separate) but that does not appear to be the case
>> here. Well, not sure actually. Can you upgrade the upgrade code
>> independently? Sorry if this is obvious and I am not quite getting it :-)
>>
>>> On Jun 21, 2016, at 12:31 PM, [email protected] wrote:
>>>
>>> I¹m working on split image feature and I think I just have one more
>>> major design issue to consider, and that is newt build related.
>>>
>>> First, a summary for folks who are unaware of this effort. The goal is
>>> to create an application in two pieces to fit into two image banks such
>>> that one piece would contain the bluetooth stack and firmware update
>>> application and the other would contain the primary customer application
>>> (that¹s the goal, but it would be defined generally to allow any split).
>>> These two are linked together with a special property that the upgrade
>>> app could run without the primary customer app but not vice versa. To
>>> give these names I call the independent one the AIIC (Application
>>> independent image component) and the customer app the ADIC (Application
>>> Dependent Image component). This would allow the following upgrade
>>> procedure with two flash images. At each step, there would always be a
>>> valid upgrade image loaded into the unit.
>>>
>>> 1. Erase the application image from the second image bank (still can
>>> recover since the upgrade image is valid)
>>> 2. Upload a new upgrade image to the second image bank (primary
>>> upgrade image still intact in case secondary fails)
>>> 3. Swap the upgrade images in the 1st and 2nd bank (if secondary
>>> doesn¹t boot, we can always revert)
>>> 4. Load the new application into the 2nd bank (if this fails, we
>>> still have the upgraded in the primary)
>>> 5. Complete
>>>
>>> This model allows a safe upgrade (because the upgrade image can always
>>> upgrade) while preserving more space for the application because the
>>> application doesn¹t have to duplicate the bluetooth stack and associated
>>> upgrade code.
>>>
>>> Consider this example, two 112k flash banks which we want to store a
>>> bluetooth application. Assume the following code sizes: Application size
>>> 32k, Bluetooth stack size 64k, Upgrade code size 16k. With two
>>> independent app images, each would be 112k filling the available
>>> sectors. However, if we split the image we would have an upgrade image
>>> of 80k and an app image of 32k (since it uses bluetooth and upgrade
>>> from the AIIC) leaving tons more space for sophisticated applications
>>> and more space for the upgrade as well.
>>>
>>> We decided to create this split image as a pair that are linked
>>> together during the build process. There will be no dynamic bindings
>>> like SWI or function table or anything like that. The goal is not to
>>> separate the OS/stack from the app, but just to be a bit more efficient
>>> about duplicating the large components like bluetooth. Thus, when up are
>>> updating one of the split images, you MUST update the other. Splitting
>>> the image makes this ³safe" as there will always be a bank filled with
>>> an image that is capable of performing an upgrade.
>>>
>>> Anyway, that was the background, now on to my design question
>>>
>>> The question I am investigating is how to formulate this in the newt
>>> build process. Here are two alternatives.
>>>
>>> IDEA1: I was thinking that I would have a single target to produce both
>>> of these image components. The target would still have one bsp, one
>>> build profile, but I would define a new token for the target called
>>> loader=xxx. This would define the loader AIIC that would go into the
>>> first image bank, and if ³loader" was defined, the app would be linked
>>> to run in the second image bank. Thus, if I were building a bluetooth
>>> app called foo, I would set loader=AIIC (contains upgrade and
>>> bluetooth) and then set app=foo. If ³loader² was not defined, I would
>>> ensure the newt tool would do a complete build of foo and link it into
>>> the first image bank.
>>>
>>> IDEA2: The alternative would be to have two separate targets. The AIDC
>>> target would have to reference the AIIC target and know that it was
>>> being built to be dependent on that bit. In this case, the AIIC target
>>> would be build as normal with no changes to the build system. Then the
>>> AIDC target would have to have a new tag that said that it was dependent
>>> on the other target. For example, in the app:foo target descriptor it
>>> would say split_image_dep=AIIC. This would cause newt to perform some
>>> special processing of the AIIC elf image, and ensure that we link the
>>> foo AIDC app to run out of the second image bank and reference common
>>> functions in the first image bank.
>>>
>>> In either case, the application will be build as a split image and will
>>> contain two elf files. One file will be the Application Independent
>>> AIIC) part, and another will be the application dependent (ADIC) part.
>>> These will both get converted to image files by newt create-image.
>>>
>>> Comments? My thoughts are that IDEA1 is the better of these two. It
>>> would allow newt to be split-image-aware during create-image and during
>>> download and debug. Any other ideas from someone more knowledgeable
>>> about newt?
>>>
>>> Paul
>>>
>>>
>>
>
