Add instruction partials to etcher supported device types #236

mehalter · 2021-06-22T17:28:50Z

This PR replaces the deprecated instruction generation approach that was being implemented in #173.

Change-type: major
See: https://www.flowdock.com/app/rulemotion/pub/threads/AE_IXh9Xs_I7MYOHS98oLb0xaya
Signed-off-by: Micah Halter micah@balena.io

mehalter · 2021-06-22T17:30:09Z

contracts/hw.device-type/jn30b-nano/contract.json

@@ -22,8 +22,14 @@
      "internal": true
    },
    "media": {
-      "installation": "dfu"


Need to investigate this device type more. It was listing the installation media as internal storage, but the instructions in the Dashboard indicate that it boots from an SD card. If anyone knows which is correct please drop a comment

Looks like it depends on the revision... which makes things harder...

JN30B Revision 4 (38346-4)

removed eMMC and add micro SD card

See: https://auvidea.eu/download/manual/JN30/JN30_manual.pdf
See: https://auvidea.eu/product/70787/

Ah I see, this is definitely where contact versions will be able to handle this very nicely I think. Basically we can have different contracts for different versions of the board which should all be stored historically so we can change the instructions for a specific version change of the hardware and track these changes.

mehalter · 2021-08-20T16:44:54Z

@balena-ci rebase

mehalter · 2022-04-21T18:40:18Z

After long discussions we have decided to move from identifying an "installation method" to identifying default boot methods and alternative boot methods and being able to identify what boot method is being used. For example:

If there is a flashProtocol defined then we know that we need to flash directly to the device. We can identify which protocols etcher supports to decide how the flashing needs to happen. In this case jetsonFlash is not supported by etcher so we will need to give jetson flashing specific instructions:

    "flashProtocol": "jetsonFlash",
    "media": {
      "defaultBoot": "internal",
      "altBoot": []
    },

Another example of a flashProtocol that Etcher does support would be RPIBOOT which is a flash protocol utilized by the Balena Fin:

    "flashProtocol": "RPIBOOT",
    "media": {
      "defaultBoot": "internal",
      "altBoot": []
    },

If the defaultBoot is internal and there is an alternative boot method like sdcard and no flashProtocol defined, then we know this is an installation where we need to flash to the sdcard with etcher and that sd card will have a flasher image to write to the internal storage

    "media": {
      "defaultBoot": "internal",
      "altBoot": ["sdcard"]
    },

If the defaultBoot is something not internal and there is no flashProtocol then we know the device will need to boot off of an external media in which we flash BalenaOS onto directly like a raspberry pi might have this definition:

    "media": {
      "defaultBoot": "sdcard",
      "altBoot": []
    },

So far I have gone through and updated all of the non-discontinued device types to have the necessary partials for the instructions as well as updated media and flashProtocol definitions in their contracts. I did not include definitions for the generic device types as we are planning on deprecating and removing these (to my knowledge).

Lastly there is one more lingering question regarding the raspberrypicm4-ioboard contract where it supports both the "CM4 Lite" and "CM4 eMMC" boards. The former boots off an SD card and the latter does a direct flash to the eMMC with RPIBOOT flash protocol. We need to decide how we want to represent this in a contract. I think the best approach would be to split these device types into separate contracts.

Edit: The raspberrypicm4-ioboard comment has been resolved.

thgreasi · 2022-05-04T16:02:08Z

@mehalter WRT raspberrypicm4-ioboard, wouldn't the following work v ?

    "flashProtocol": "RPIBOOT",
    "media": {
      "defaultBoot": "internal",
      "altBoot": ["sdcard"]
    },

contracts/hw.device-type/asus-tinker-board-s/contract.json

thgreasi

Feel free to self-certify after checking these comments 👍

contracts/hw.device-type/raspberrypicm4-ioboard/contract.json

contracts/hw.device-type/raspberrypi3/contract.json

contracts/hw.device-type/raspberrypi0-2w-64/contract.json

contracts/hw.device-type/orangepi-plus2/contract.json

thgreasi · 2022-05-17T13:29:23Z

contracts/hw.device-type/beaglebone-green-wifi/contract.json

+    "bootDeviceExternal": [
+      "Power up the {{name}} while holding down the small button near the SD slot. You need to keep it pressed until the blue LEDs start flashing wildly."
+    ],
+    "flashIndicator": ["5 seconds after the LEDs have stopped flashing wildly"],


Was the On some boards the leds will shut down completely." part that we had before wrong?

contracts/hw.device-type/coral-dev/contract.json

thgreasi · 2022-05-17T13:48:46Z

contracts/hw.device-type/imx8m-var-dart/contract.json

+      "defaultBoot": "internal",
+      "altBoot": ["sdcard"]


Just to double-check: In case we care to reason whether this is a flasher DT, should we check the defaultBoot & altBoot combination?

Ah, yeah in the cases where the defaultBoot method is internal and there is no flash method specified (i.e. we can't directly flash the internal storage) we need to check the altBoot method to see how it is going to flash the internal storage.

Are there cases where we use an external media to flash another external media for booting? I think that is a case that is not covered in our current set up, but I don't think that that ever comes up.

I don't know of enough DTs to answer this. The devices team will probably know.

contracts/hw.device-type/intel-edison/contract.json

thgreasi · 2022-05-17T14:03:20Z

contracts/hw.device-type/jn30b-nano/contract.json

@@ -22,8 +22,14 @@
      "internal": true
    },
    "media": {
-      "installation": "dfu"


Looks like it depends on the revision... which makes things harder...

JN30B Revision 4 (38346-4)

removed eMMC and add micro SD card

See: https://auvidea.eu/download/manual/JN30/JN30_manual.pdf
See: https://auvidea.eu/product/70787/

mehalter · 2022-05-26T16:51:40Z

@balena-ci rebase

mehalter · 2022-05-26T17:03:57Z

@balena-ci rebase

Change-type: major Signed-off-by: Micah Halter <micah@balena.io>

mehalter · 2022-05-27T15:02:16Z

@balena-ci I self-certify!

mehalter added enhancement versionbot/pr-draft Draft PR - Don't merge this PR automatically labels Jun 22, 2021

mehalter self-assigned this Jun 22, 2021

mehalter commented Jun 22, 2021

View reviewed changes

mehalter mentioned this pull request Jun 22, 2021

Add contract partial based instruction generation balena-io/balena-sdk#1101

Merged

7 tasks

ghost force-pushed the add-device-type-partials branch from ccc1caa to 397f6f6 Compare August 20, 2021 16:45

mehalter force-pushed the add-device-type-partials branch 2 times, most recently from 5e2ef11 to b270f6c Compare April 21, 2022 18:23

thgreasi reviewed May 5, 2022

View reviewed changes

contracts/hw.device-type/asus-tinker-board-s/contract.json Show resolved Hide resolved

mehalter force-pushed the add-device-type-partials branch from b270f6c to 742b808 Compare May 12, 2022 16:56

thgreasi reviewed May 17, 2022

View reviewed changes

mehalter force-pushed the add-device-type-partials branch from 742b808 to b8433a0 Compare May 26, 2022 16:49

ghost force-pushed the add-device-type-partials branch from b8433a0 to d83d9e2 Compare May 26, 2022 16:52

mehalter force-pushed the add-device-type-partials branch from d83d9e2 to ade56bc Compare May 26, 2022 17:03

ghost force-pushed the add-device-type-partials branch from ade56bc to ead70c3 Compare May 26, 2022 17:04

mehalter force-pushed the add-device-type-partials branch 5 times, most recently from dea063a to 4c3eacd Compare May 27, 2022 14:49

Clean up installation method and add instruction partials

62794cb

Change-type: major Signed-off-by: Micah Halter <micah@balena.io>

mehalter force-pushed the add-device-type-partials branch from 4c3eacd to 62794cb Compare May 27, 2022 14:59

ghost approved these changes May 27, 2022

View reviewed changes

ghost merged commit ac86710 into master May 27, 2022

ghost deleted the add-device-type-partials branch May 27, 2022 15:02

vipulgupta2048 mentioned this pull request Feb 21, 2023

patch: Add docs to contracts for instructions partials #364

Merged

This pull request was closed.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add instruction partials to etcher supported device types #236

Add instruction partials to etcher supported device types #236

mehalter commented Jun 22, 2021 •

edited

Loading

mehalter Jun 22, 2021

thgreasi May 17, 2022

mehalter May 25, 2022

mehalter commented Aug 20, 2021

mehalter commented Apr 21, 2022 •

edited

Loading

thgreasi commented May 4, 2022

thgreasi left a comment

thgreasi May 17, 2022

thgreasi May 17, 2022

mehalter May 25, 2022

mehalter May 25, 2022

thgreasi May 26, 2022

thgreasi May 17, 2022

mehalter commented May 26, 2022

mehalter commented May 26, 2022

mehalter commented May 27, 2022

Add instruction partials to etcher supported device types #236

Add instruction partials to etcher supported device types #236

Conversation

mehalter commented Jun 22, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mehalter commented Aug 20, 2021

mehalter commented Apr 21, 2022 • edited Loading

thgreasi commented May 4, 2022

thgreasi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mehalter commented May 26, 2022

mehalter commented May 26, 2022

mehalter commented May 27, 2022

mehalter commented Jun 22, 2021 •

edited

Loading

mehalter commented Apr 21, 2022 •

edited

Loading