I have my riscv board and for that i cloned meta-mender yocto layer but when building the mender-client is giving the go error please check below info for understanding.
mender-client recipe version = 3.4.0
go version = 1.14.1
yocto version = dunfell
compile time error:
ERROR: mender-client-3.3.0-r0 do_compile: oe_runmake failed
ERROR: mender-client-3.3.0-r0 do_compile: Execution of ‘/home/…/mender-client/3.3.0-r0/temp/run.do_compile.25755’ failed with exit code 1:
riscv64-oe-linux-go build -ldflags “-X github.com/mendersoftware/mender/conf.Version=3.3.0” -v
runtime/cgo
runtime/cgo
/home/…/tmp-glibc/work/riscv64-oe-linux/mender-client/3.3.0-r0/recipe-sysroot-native/usr/bin/riscv64-oe-linux/…/…/libexec/riscv64-oe-linux/gcc/riscv64-oe-linux/10.1.0/ld: $WORK/b082/_x008.o: in function x_cgo_thread_start': /usr/lib/go/src/runtime/cgo/gcc_util.c:21: undefined reference to _cgo_sys_thread_start’
collect2: error: ld returned 1 exit status
Makefile:85: recipe for target ‘mender’ failed
make: *** [mender] Error 2
WARNING: exit code 1 from a shell command.
ERROR: Logfile of failure stored in: /home/…/sources/build/tmp-glibc/work/riscv64-oe-linux/mender-client/3.3.0-r0/temp/log.do_compile.25755
Log data follows:
| DEBUG: Executing shell function do_compile
| WARNING: You are building with the mender-demo layer, which is not intended for production use
| WARNING: You are building with the default server certificate, which is not intended for production use
| NOTE: make -j 10 TAGS= V=1
| riscv64-oe-linux-go build -ldflags “-X github.com/mendersoftware/mender/conf.Version=3.3.0” -v
| runtime/cgo
| # runtime/cgo
| /home/…/sources/build/tmp-glibc/work/riscv64-oe-linux/mender-client/3.3.0-r0/recipe-sysroot-native/usr/bin/riscv64-oe-linux/…/…/libexec/riscv64-oe-linux/gcc/riscv64-oe-linux/10.1.0/ld: $WORK/b082/_x008.o: in function x_cgo_thread_start': | /usr/lib/go/src/runtime/cgo/gcc_util.c:21: undefined reference to _cgo_sys_thread_start’
| collect2: error: ld returned 1 exit status
| Makefile:85: recipe for target ‘mender’ failed
| make: *** [mender] Error 2
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| ERROR: Execution of ‘/home/…/sources/build/tmp-glibc/work/riscv64-oe-linux/mender-client/3.3.0-r0/temp/run.do_compile.25755’ failed with exit code 1:
| riscv64-oe-linux-go build -ldflags “-X github.com/mendersoftware/mender/conf.Version=3.3.0” -v
| runtime/cgo
| # runtime/cgo
| /home/…/sources/build/tmp-glibc/work/riscv64-oe-linux/mender-client/3.3.0-r0/recipe-sysroot-native/usr/bin/riscv64-oe-linux/…/…/libexec/riscv64-oe-linux/gcc/riscv64-oe-linux/10.1.0/ld: $WORK/b082/_x008.o: in function x_cgo_thread_start': | /usr/lib/go/src/runtime/cgo/gcc_util.c:21: undefined reference to _cgo_sys_thread_start’
| collect2: error: ld returned 1 exit status
| Makefile:85: recipe for target ‘mender’ failed
| make: *** [mender] Error 2
| WARNING: exit code 1 from a shell command.
|
ERROR: Task (/home/…/sources/meta-mender/meta-mender-core/recipes-mender/mender-client/mender-client_3.3.0.bb:do_compile) failed with exit code ‘1’
NOTE: Tasks Summary: Attempted 852 tasks of which 837 didn’t need to be rerun and 1 failed.
NOTE: Writing buildhistory
NOTE: Writing buildhistory took: 16 seconds
NOTE: Build completion summary:
NOTE: do_populate_sysroot: 0.0% sstate reuse(0 setscene, 2 scratch)
NOTE: do_package: 0.0% sstate reuse(0 setscene, 2 scratch)
NOTE: do_packagedata: 0.0% sstate reuse(0 setscene, 4 scratch)
Summary: 1 task failed:
/home/…/sources/meta-mender/meta-mender-core/recipes-mender/mender-client/mender-client_3.3.0.bb:do_compile
Summary: There were 2 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
Thanks for reaching out! I have been working a bit on RISC-V support, and the client should build and run fine on kirkstone. Any particular reason you are still on dunfell? Which board are you using?
The board I am using is hifive unmatched (FU740) and we are intentionally using dunfell branch of yocto ,the previous error has been resolved for me and mender is compiled fine but in meta-sifive and meta-riscv yocto layer the vendors provided wic.gz image format to boot the target board whereas mender dont have wic image concept to use ,as i read the mender documents it is supporting to sdimg and uefiimg , ubimg ,so will mender be working to support the wic image in future or if any other way to do it then please help me out to make mender success on riscv board.
Mender internally uses wic. The generated artifacts fall into two categories:
uefiimg, sdimg, ubiimg, ...: those are effectively wic images with all Mender pieces already in place. Those serve as initial images to provision devices.
mender: those are single partition images (= artifacts) that you can deploy to devices that have been provisioned with an initial image.
So you’d have to look into the requirements the board has in its wic description, then adjust the Mender integration accordingly, and after that flash one of the initial images.
Your explanation is clear to me and i understood effectively.
As you told adjust the Mender integration accordingly for my provision device, Let me tell you how initial artifact is generating for my device in wic.gz format, check below please.
1 .Their are four partitions created in initial image.
Device Start End Sectors Size Type
/dev/mmcblk0p1 34 2081 2048 1M HiFive Unleashed FSBL
/dev/mmcblk0p2 2082 10273 8192 4M HiFive Unleashed BBL
/dev/mmcblk0p3 16384 282623 266240 130M Microsoft basic data
/dev/mmcblk0p4 286720 54812671 54525952 26G Linux filesystem
here first partition contains first stage boot loader 2nd partition contains second stage boot loader 3rd contains kernel binaries and 4th partition has rootfs, so these all partitions are managed by .wks file in yocto .
2 . but first and second partitions assigned static fixed uuid so that ZSBL find to FSBL by checking the static uuid and FSBL also checking uuid for 2nd stage boot loader,
So this is my initial image content and partitions whereas mender only creating patitions like boot partition contains u-boot and active and inactive partion contains kernel+rootfs so how to manage it with my partions.
I am struggling with this please suggest me how to integrate it with mender according to my partitions to be set in mender initial image (as you told it can be any type).
Ah I see. In that case (the special partitions required), you will have to actually set up the wic file manually and reserve partitions that Mender needs. Then you configure the build accordingly to tell the Mender client which partitions to use in which meaning. The documentation on that is Partition configuration | Mender documentation
Thank you so much for your help , I got it how to create the extra partitions in mender initial image using MENDER_EXTRA_PARTS variable but it seams it is creating the extra partitions after the data partition and that is not my requirement ,My requirement is to create the partitions before the boot partion so that my board will understand the FSBL and 2nd stage boot loader from the first two partitions as i told you in previous post .
so to create new partition before boot partition is their any other way to do it .
Thank you @TheYoctoJester to support me
Finally the mender is integrated successfully and initial image is created for my target board and you can see below the partitions are created according to mender requirement.
sd card partitions on target board:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0 179:0 0 29.7G 0 disk
mmcblk0p1 179:1 0 16M 0 part /uboot
mmcblk0p2 179:2 0 3.8G 0 part /
mmcblk0p3 179:3 0 3.8G 0 part
mmcblk0p4 179:4 0 22.1G 0 part /data
when i booted my target board with sd card it is booted fine but after login it is continously resizing the boot partition with never ending log is coming see below.
root@# [ 120.205495] EXT4-fs (mmcblk0p4): resized to 3145729 blocks
[ 130.805974] EXT4-fs (mmcblk0p4): resized to 3670017 blocks
root@# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0 179:0 0 29.7G 0 disk
|-mmcblk0p1 179:1 0 16M 0 part /uboot
|-mmcblk0p2 179:2 0 3.8G 0 part /
|-mmcblk0p3 179:3 0 3.8G 0 part
`-mmcblk0p4 179:4 0 22.1G 0 part /data
root@Exaleap-Unmatched-Linux-1:~# [ 141.399427] EXT4-fs (mmcblk0p4): resized to 4194305 blocks
[ 152.604372] EXT4-fs (mmcblk0p4): resized to 4718593 blocks
[ 163.675359] EXT4-fs (mmcblk0p4): resized to 5242881 blocks
[ 175.056108] EXT4-fs (mmcblk0p4): resized to 5767169 blocks
[ 186.319577] EXT4-fs (mmcblk0p4): resized to 6291457 blocks
.
.
.
The issue has solved by disabling the mender-growfs-data feature and now it is not resizing the data partition but when i run mender to install the artifact in standalone mode then is gave me below error,
error:
root@Unmatched-Linux-1:~# mender install core-image-base-u740.mender
INFO[0002] Loaded configuration file: /var/lib/mender/mender.conf
INFO[0002] Loaded configuration file: /etc/mender/mender.conf
INFO[0002] ‘UpdateControlMapExpirationTimeSeconds’ is not set in the Mender configuration file. Falling back to the default of 2*UpdatePollIntervalSeconds
INFO[0002] ‘UpdateControlMapBootExpirationTimeSeconds’ is not set in the Mender configuration file. Falling back to the default of 600 seconds
INFO[0002] Output (stderr) from command “fw_printenv”: Cannot read environment, using default
INFO[0002] Output (stderr) from command “fw_printenv”: Cannot read default environment from file
INFO[0002] Output (stderr) from command “fw_printenv”: Cannot read environment, using default
INFO[0002] Output (stderr) from command “fw_printenv”: Cannot read default environment from file
ERRO[0002] Failed to read the current active partition: No match between boot and root partitions.: exit status 243
INFO[0002] Start updating from local image file: [core-image-base-u740.mender]
Installing Artifact of size 423362560…
INFO[0002] No public key was provided for authenticating the artifact
INFO[0002] Update Module path “/usr/share/mender/modules/v3” could not be opened (open /usr/share/mender/modules/v3: no such file or directory). Update modules will not be available
WARN[0002] Returning artifact name from /etc/mender/artifact_info file. This is a fallback, in case the information can not be retrieved from the database, and is only expected when an update has never been installed before.
INFO[0002] Output (stderr) from command “fw_printenv”: Cannot read environment, using default
INFO[0002] Output (stderr) from command “fw_printenv”: Cannot read default environment from file
INFO[0002] Output (stderr) from command “fw_printenv”: Cannot read environment, using default
INFO[0002] Output (stderr) from command “fw_printenv”: Cannot read default environment from file
ERRO[0002] Download failed: Payload: can not install Payload: core-image-base-u740.ext4: No match between boot and root partitions.: exit status 243
ERRO[0002] Payload: can not install Payload: core-image-base-u740.ext4: No match between boot and root partitions.: exit status 243
Great to hear you got it working! Is all of the additions needed for the integration so far in this thread? I would love to document this for future users as the first supported RISC-V board.
Concerning the problem, my understanding is that the fw_printenv command is not able to read the environment. Therefore it cannot get the information required to understand which partition is currently used and the client errs out. This command is provided by u-boot, and needs to know where the environment is located. So the next thing is to find that out. If you change something in the u-boot console and then saveenv, where does it end up? It could be a file, or some other persistent storage.
If you can provide the BSP in use respectively your additions, then I can also have a look.
