Hi Marcos,
I don't know if I can solve this problem, but I can at least answer a
few of your questions. Hopefully someone more knowledgeable can fill in
the gaps.
On Mon, Jan 23, 2017 at 02:34:11PM -0200, Marcos Scheeren wrote:
[...]
> To my understanding, the newt create-image command outputs an .img with the
> bootloader sector, the sectors headers, and the two application sectors,
> needed for the bootloader to properly locate, identify and load the
> applications.
The .img file only contains:
* image header
* image binary
The contents of a .img file occupy a single image slot. The boot loader
slot and the second image slot are untouched when you upload an image.
A .img file, as opposed to a .bin file, is only useful if you are using
the boot loader. The boot loader knows how to read the image header and
determine where the image executable actually begins. If you aren't
using a boot loader, then you need to upload a .bin file to address 0 so
that the hardware jumps straight into the image on boot. This process
is minimally described here:
https://mynewt.apache.org/latest/os/modules/split/split/
> And my "low-level bootloader knowledge" ends here :( So the questions are:
>
> - Are there any ways to output a single .elf or .bin file already with the
> sectors headers (maybe convert the .img file) so I can load it using the
> GDB extended-remote mode? Or that would require further work, like changing
> the newt golang sources?
That sounds like a manufacturing image. A manufacturing image contains
the entire contents of a device's flash; it is intended to be built into
every unit during the early stages of manufacturing. In particular, a
manufacturing image contains:
* boot loader
* image in slot 0
* (optional) image in slot 1 or split image
* (optional) user data
There is some basic documentation for creating mfg images here:
http://mynewt.apache.org/latest/newt/command_list/newt_mfg/
This process should definitely work, as we use it frequently. However,
the documentation may be lacking, so please don't hestitate to follow up
with questions.
> Thanks.
> Other than that, really appreciate the architecture of the OS!
Chris
