+- PINE64 (https://forum.pine64.org)
+-- Forum: PineTime (https://forum.pine64.org/forumdisplay.php?fid=134)
+--- Forum: General Discussion on PineTime (https://forum.pine64.org/forumdisplay.php?fid=135)
+--- Thread: PineTime Software Images (/showthread.php?tid=9779)
PineTime Software Images - VMMainFrame - 05-02-2020
In the Pine64 Wiki several devices like the ROCK64 and Pinebook have an entry called Software Images. This contains pre-built downloadable software and operating systems for the hardware. PineTime in the Wiki does not have anything like this.
There are several software systems available for the PineTime, like Rust, wasp-os, RIOT, FREERTOS and more. But there don't seem to be any pre-built flashable images available. If someone wants to install the Rust system, for example, they have to download software from GitHub, SDKs etc. and build the flashable images themselves. If someone wants to check out the state of the various available systems for the PineTime they will have to download multiple groups of software and build multiple images.
If there was a Software Images section in the Wiki with the latest flashable images (or links to them) for each different software system for the PineTime, users could easily evaluate each system. The images would also require documentation on how to flash or load and use the software.
This will require the co-operation of the software developers of course. It will require extra work from them. Ideally as each package gets more features added the latest image will be made available.
This might speed up the testing of the PineTime and its software.
PineTime Software Images - lupyuen - 05-02-2020
One solution is to get firmware updates over Bluetooth working for each of our PineTime firmware platforms.
Once that's ready, PineTime Owners will be able to download the firmware image for each platform and flash it to PineTime easily via their phones. No more building from scratch and flashing with different scripts.
I'm writing a doc that explains to PineTime Developers what we need to code to support Bluetooth DFU. Also in the doc is a proposed Flash ROM Layout that I hope all PineTime Developers will adopt, to make it easy to switch firmware platforms.
Here's the work in progress:
https://lupyuen.github.io/pinetime-rust-mynewt/articles/dfu
Sent from my Pixel 4 XL using Tapatalk
RE: PineTime Software Images - danielt - 05-04-2020
I'm planning to release binaries for wasp-os once I've finished the M2 features. I recently got OTA bootloader updates working (*don't* play with this feature just yet if you have glued the back on). There are a couple of features I might delay until M3 but I definitely want to get the device to remember the current time through reset.
(05-02-2020, 08:13 PM)lupyuen Wrote: Also in the doc is a proposed Flash ROM Layout that I hope all PineTime Developers will adopt, to make it easy to switch firmware platforms.
Here's the work in progress:
https://lupyuen.github.io/pinetime-rust-mynewt/articles/dfu
mcuboot is an excellent place to start from.
However I think the flash layout would be dramatically better if it took advantage of the SPI flash. Only code that will be executed need go in the internal flash (e.g. bootloader and active firmware image) everything else can be offloaded to the SPI flash which will more than double the maximum application size. In the current proposal, 232KB is way to small for a real application. I'm sure there is tuning and weightloss possible but some of the littlevgl firmwares are already 250K code size *excluding* the BT stack.
The other thing about the flash layout that would be worth considering is whether it can be made softdevice compatible. The softdevice is linked to run at 0x1000 so the bootloader partition would likely have to be split into a vector table at 0x0 and a main bootloader at the end of the flash).
Supporting softdevice is clearly not required to run the free software BLE stacks. However a universal bootloader isn't actually universal would mean having to write "reloader" applications to to nuke the universal bootloader and replace it with a softdevice bootloader and vice versa so that users can experiment with any softdevice firmwares that are available.
PineTime Software Images - lupyuen - 05-04-2020
Interesting points... Will consider that in the design. Yes I'm planning to use External SPI for storing the Standby Firmware Image... Will write more about this once I have documented the simplest MCUBoot setup.
Would you be OK if I helped to port wasp-os to use NimBLE and MCUBoot instead of SoftDevice?
This would be highly educational for understanding how well NimBLE and MCUBoot can integrate with any PineTime firmware.
Sent from my Pixel 4 XL using Tapatalk
RE: PineTime Software Images - JF002 - 05-04-2020
(05-04-2020, 03:39 AM)danielt Wrote: The other thing about the flash layout that would be worth considering is whether it can be made softdevice compatible. The softdevice is linked to run at 0x1000 so the bootloader partition would likely have to be split into a vector table at 0x0 and a main bootloader at the end of the flash).
Supporting softdevice is clearly not required to run the free software BLE stacks. However a universal bootloader isn't actually universal would mean having to write "reloader" applications to to nuke the universal bootloader and replace it with a softdevice bootloader and vice versa so that users can experiment with any softdevice firmwares that are available.
The softdevice is really complex, and, as far as I understand, relies on a MBR located at 0x0. This MBR forwards the IRQ to the softdevice or the applications according to the state of the softdevice. I don't know if it does anything else.
I also don't know how to deal with this in a universal bootloader? Is it possible to chain the MBR with a custom bootloader, the softdevice and the application?
You are totally right, we are still quite far away from the universal bootloader of our dreams
Oh, and for the OP, who asked about a list of flashable image, there is a list of ongoing projects in the wiki. Some projects provide releases with compiled binaries, and even binaries built with a CI which you can flash using a SWD debugger.
Maybe we can add on the list of Development efforts in the wiki a link to the last binary available?
RE: PineTime Software Images - danielt - 05-05-2020
(05-04-2020, 11:58 AM)JF002 Wrote: The softdevice is really complex, and, as far as I understand, relies on a MBR located at 0x0. This MBR forwards the IRQ to the softdevice or the applications according to the state of the softdevice. I don't know if it does anything else.
I also don't know how to deal with this in a universal bootloader? Is it possible to chain the MBR with a custom bootloader, the softdevice and the application?
I think the trick needed it to replace the MBR with our own (I called this the vector table in my last post). There a blog post that gives some strong clues about how to do that: https://aykevl.nl/2018/01/mbr-softdevice-internals . For initial development to enable open source BLE stacks I think it can simply update the vector table to adopt mcuboot at the end of internal flash and be done.
Other than that all that is required is to arrange for the softdevice to fit, alongside the application that uses it, within the main application slot so that the softdevice can work when it is copied here.
In other words.
Code:
Internal flash:
0x00000000 FreeMBR 4k
0x00001000 Application slot 492k
0x0007C000 mcuboot 16k
SPI flash:
Update slot 492k
Recovery slot 492k
Scratch 4k (may be better in internal flash before bootloader
File system Rest of SPI flash?A softdevice application would come as a single binary with the SD and application merged together...
PS Above a recovery slot is also proposed. This is used to avoid bricking when both application and update slots do not contain a working application (for example if both crashed before bringing up OTA update suppport due to something recently added to the file system then it would be hard to recover so the recovery slot allows us to have a "simple" BLE OTA update program that can be deployed in emergencies.