NanoPi Neo2 Porting Mender to Openwrt

what’s SRC_URI?

SRC_URI is a Yocto thing and you can ignore that.

@kacf, I was primarily asking about this (below),

“ClientProtocol”: “http”,
“HttpsClient”: {
“Certificate”: “”,
“Key”: “”
},

FYI and IMHO. Because golang is used for the mender app, it is bloated (6M+) by the statically included go libraries. This will be an impediment to mender usage on storage “challenged” devices. Suggestion: Create a C/C++ version of the mender app which can be linked to already existing standard libraries, reducing size, allowing deeper penetration into the embedded market. I’m sure you have heard this before.

@rossbcan, yes heard this before :slight_smile:

is this the artifact format I should be using?

…and(faint hope) has anyone created a bash script for packaging artifacts?

Yes that is the artifact format.

You can use the “mender-artifact” CLI tool to create these,

You typically run something like this,

mender-artifact write rootfs-image \
    --update ${BINARIES_DIR}/rootfs.ext4 \
    --output-path ${BINARIES_DIR}/${artifact_name}.mender \
    --artifact-name ${artifact_name} \
    --device-type ${device_type}

Oh, sorry I misunderstood. Certificate is I believe a remnant from when we wanted to use client certificates to identify the client. It has never been used, and should be removed completely. ServerCertificate is definitely the way to go.

So; mender.conf should like this:
{
“ClientProtocol”: “http”,
},
“RootfsPartA”: “/dev/mmcblk0p2”,
“RootfsPartB”: “/dev/mmcblk0p3”,
“UpdatePollIntervalSeconds”: 86400,
“InventoryPollIntervalSeconds”: 86400,
“RetryPollIntervalSeconds”: 30,
“ServerURL”: “https://mender.example.com/”,
“ServerCertificate”: “”
}
or, this?:
{
“RootfsPartA”: “/dev/mmcblk0p2”,
“RootfsPartB”: “/dev/mmcblk0p3”,
“UpdatePollIntervalSeconds”: 86400,
“InventoryPollIntervalSeconds”: 86400,
“RetryPollIntervalSeconds”: 30,
“ServerURL”: “https://mender.example.com/”,
“ServerCertificate”: “”
}

The second one

thanks…

I now know how to create artifacts and, am now pondering HOW to simply get the artifacts (from buildbots) to mender server.

According to the docs, we need
bash script / artifact creation <-> something <-> mender server get/put deployment API

The “something” is a black hole to our team, alternatives look ugly. Suggestions?

or, even better, an API bypass mechanism where we can just SCP or whatever files over. In addition, perhaps accept compressed image file and create artifacts on server? If not exist, consider this a feature request.

Regards;
Bill

The options are,

  1. Using the server API
  2. Using the mender-cli tool

Thanks, looking into it…

Not gonna make the mistake of not “reading the docs” again…

hit a snag (filling in niggly details in order to create mender artifacts). Mender depends on fw_setenv (linux command) to alter u-boot environment. The default env (from mender u-boot) is OK and boots. Yet, when I save the default env (u-boot command prompt: env default -a; saveenv) which writes current env to raw flash). the result is a cyclic boot scenario. Yes, I have checked that the flash env address and sizes are correct. (matches config_mender_defines.h)

/etc/fw_env.config:

# MTD device name	Device offset   Env. size	Flash sector size	Number of sectors
/dev/mmcblk0            0x400000        0x4000
/dev/mmcblk0            0x800000        0x4000

How do I insert Markdown for u-boot log to show where it goes off the rails?

uboot log:
apart from (bad) loading env from mmc - ok versus (good) loading default env, identical to and including here:

[ 0.000000] earlycon: uart0 at MMIO32 0x0000000001c28000 (options ‘’)
then;
(good): bootconsole [uart0] enabled
(bad): [ 0.000000] Internal error: undefined instruction: 0 [#1] PREEMPT SMP

The bad used to work until I (u-boot prompt): env default -a, then saveenv

Seen this before?

Regards;
Bill

To get markdown highlighting you just enclose the text you want to highlight with

```
log here
```

Waiting for full logs before I attempt to comment,

But could you also post output of

fdisk -l <your disk image

There might be a problem with overlaps between your first partition and U-boot environment, mostly guessing here as you run in to problems after running saveenv.

I agree with your diagnosis, especially if u-boot uses the fw_saveenv command in rootfs, since…

making boot progress: openwrt fw_printenv (which also sets u-boot env vars) is completely separate from u-boot config and version. Need to alter or delete this package and incorporate it to u-boot package so mender config is picked up. I suspect the cyclic boot problem (symptom, u-boot log " [ 0.000000] Internal error: undefined instruction: 0 [#1] PREEMPT SMP") is due to disconnect between u-boot config and fw_printenv config, resulting in writes to wrong flash locations). Pondering best way (minimal openwrt disruption) how to fix.

bad log:
U-Boot SPL 2018.11 (Feb 14 2019 - 20:43:07 +0000)
DRAM: 512 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.0(release):reboot-9355-g94993a7-dirty
NOTICE:  BL31: Built : 20:43:07, Feb 14 2019
NOTICE:  BL31: Detected Allwinner H5 SoC (1718)
NOTICE:  BL31: STUB PMIC setup code called


U-Boot 2018.11 (Feb 14 2019 - 20:43:07 +0000) Allwinner Technology

CPU:   Allwinner H5 (SUN50I)
Model: FriendlyARM NanoPi NEO 2
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet@1c30000
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
384 bytes read in 1 ms (375 KiB/s)
## Executing script at 4fc00000
8894472 bytes read in 391 ms (21.7 MiB/s)
14258 bytes read in 2 ms (6.8 MiB/s)
## Flattened Device Tree blob at 4fa00000
   Booting using the fdt blob at 0x4fa00000
EHCI failed to shut down host controller.
EHCI failed to shut down host controller.
   Loading Device Tree to 0000000049ff9000, end 0000000049fff7b1 ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.14.99 (rossb@localhost.localdomain) (gcc version
7.4.0 (OpenWrt GCC 7.4.0 r9355-94993a7)) #0 SMP PREEMPT Thu Feb 14 20:43:07 2019

[    0.000000] Boot CPU: AArch64 Processor [410fd034]
[    0.000000] Machine model: FriendlyARM NanoPi NEO 2
[    0.000000] earlycon: uart0 at MMIO32 0x0000000001c28000 (options '')
[    0.000000] Internal error: undefined instruction: 0 [#1] PREEMPT SMP
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper  4.14.99 #0
[    0.000000] Hardware name: FriendlyARM NanoPi NEO 2 (DT)
[    0.000000] task: ffffff800888e400 task.stack: ffffff8008880000
[    0.000000] PC is at console_sysfs_notify+0x0/0x38
[    0.000000] LR is at register_console+0x318/0x3e8
[    0.000000] pc : [<ffffff80083703a0>] lr : [<ffffff80081007f8>] pstate: 60000
1c5
[    0.000000] sp : ffffff8008883d80
[    0.000000] x29: ffffff8008883d80 x28: ffffff8008769648
[    0.000000] x27: ffffff800882029c x26: 0000000000000000
[    0.000000] x25: ffffff800885686f x24: ffffff8008867450
[    0.000000] x23: ffffff8008903300 x22: 0000000000000000
[    0.000000] x21: ffffff8008903000 x20: ffffff80089032d0
[    0.000000] x19: ffffff80088c8f28 x18: 0000000059f50de0
[    0.000000] x17: 0000000049fff7b2 x16: 0000000000000002
[    0.000000] x15: ffffffffffffffff x14: 37303a33343a3032
[    0.000000] x13: 2034312062654620 x12: 7568542054504d45
[    0.000000] x11: ffffff8008883c70 x10: 0000000000000000
[    0.000000] x9 : ffffffffffffffff x8 : 0000000000000000
[    0.000000] x7 : 0000000000000007 x6 : 0000000000000005
[    0.000000] x5 : 0000000000000000 x4 : 0000000000000000
[    0.000000] x3 : ffffffffffffffff x2 : 0000000000000000
[    0.000000] x1 : ffffff800888e400 x0 : 0000000000000000
[    0.000000] Process swapper (pid: 0, stack limit = 0xffffff8008880000)
[    0.000000] Call trace:

undefined instruction is the “smoking gun”

Regards;
Bill

fdisk -l image

Disk /tmp/mender/phero-neo2-openwrt-mender-ext4-sdcard.img: 7948 MB, 7948206080 bytes, 15523840 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0xf3a74622

                                                Device Boot      Start         End      Blocks   Id  System
/tmp/mender/phero-neo2-openwrt-mender-ext4-sdcard.img1            2048       43007       20480    c  W95 FAT32 (LBA)
/tmp/mender/phero-neo2-openwrt-mender-ext4-sdcard.img2           43008     7518207     3737600   83  Linux
/tmp/mender/phero-neo2-openwrt-mender-ext4-sdcard.img3         7518208    14993407     3737600   83  Linux
/tmp/mender/phero-neo2-openwrt-mender-ext4-sdcard.img4        14993408    15523839      265216   83  Linux

Yeah this is your problem,

/tmp/mender/phero-neo2-openwrt-mender-ext4-sdcard.img1            2048       43007

The first partition starts at 0x100000, but your environment starts at 0x400000. So it will definitely overwrite your boot part when you run saveenv.

I would recommend to put your first partition at 0xC00000 (12MB offset, making it 4MB aligned)

openwrt fw_printenv (which also sets u-boot env vars) is completely separate from u-boot config and version. Need to alter or delete this package and incorporate it to u-boot package so mender config is picked up

Not necessarily. As long as the U-boot does the first saveenv it does not really matter what fw_printenv/fw_setenv has built-in as that will not be used as long as there is something stored on the flash.

There is also some logic in mender_setup which will make sure that the U-boot environment is saved once during first boot, specifically for this reason where fw_setenv/fw_getenv are built from different sources.

Ignore above, I misunderstood how this works.

Yes you need either need to fix-up fw_printenv/fw_setenv to make sure it has the same default env as U-boot, or make sure that U-boot writes the environment first.

does u-boot not use fw_setenv from rootfs?
Is there a u-boot script way:
if flash_env==corrupt; then save default env

does u-boot not use fw_setenv from rootfs?

No, it has its own commands saveenv/printenv. Though they probably share some code in the U-boot source.

if flash_env==corrupt; then save default env

Something like this could work,

"if test "${environment_saved}" != "1"; then "    \
    "setenv environment_saved 1; "                \
    "saveenv; "                                       \
"fi; "

Assuming that environment_saved variable is not in the U-boot default environment.

Thanks; re-doing flash layout. Will show fdisk (tomorrow)

re the uboot script, I was thinking:

"if test "${environment_crc_bad}" != "1"; then "    \
    "saveenv; "                                       \
"fi; "

which is maybe a good idea, in general…