PineTime Software Images
#1
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.
#2
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-...ticles/dfu

Sent from my Pixel 4 XL using Tapatalk
#3
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-...ticles/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: wasp-os and MicroPython, Pinebook Pro:  Debian Bullseye
#4
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
#5
(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 Smile

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?
Working on InfiniTime, the FOSS firmware for the PineTime: https://github.com/InfiniTimeOrg/InfiniTime

Mastodon : https://mastodon.codingfield.com/@JF
Twitter : https://twitter.com/codingfield
Matrix : @JF002:matrix.org
#6
(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.
PineTime: wasp-os and MicroPython, Pinebook Pro:  Debian Bullseye


Possibly Related Threads…
Thread Author Replies Views Last Post
  PineTime at FOSDEM jmlich 5 625 02-07-2024, 11:48 PM
Last Post: tllim
  PineTime turns off when removed from cradle tynstar 0 183 01-31-2024, 11:57 AM
Last Post: tynstar
  PineTime and Amazfish on Ubuntu Touch jmlich 1 646 10-14-2023, 04:12 PM
Last Post: tllim
  PineTime is dead!! Markdanni123 12 13,507 09-18-2023, 10:17 PM
Last Post: ccchan234
  PineTime Sleep Tracking any_mouse 12 12,016 07-10-2023, 05:41 PM
Last Post: davidair
  PineTime Dead out of box? henkery 1 1,152 03-12-2023, 04:34 PM
Last Post: henkery
  Pinetime almost dead... only shows Infinitime logo. lightweight 8 6,514 02-11-2023, 09:30 AM
Last Post: alexmitroff
  PineTime beginner MV1791 2 2,089 01-09-2023, 11:52 PM
Last Post: Canyonless
  Struggling to detect Pinetime over bluetooth John45595 0 1,121 11-20-2022, 11:06 PM
Last Post: John45595
  PineTime Dev Kit for sale igor.bljahhin 2 3,132 10-19-2022, 05:34 AM
Last Post: peatord

Forum Jump:


Users browsing this thread: 1 Guest(s)