Hello everyone,
it is my first post here, so I would like to start thanking everybody contributing to Mender !
I am integrating Mender on a Xilinx Zynq-7000 board. Xilinx bootloader and U-boot are located on a bootable 32MB NAND flash, and rootfs A / rootfs B / data are located on a 4GB eMMC (no boot partition).
But eMMC should be prepared (formatted, files copied) without ethernet connection on production devices. The only accessible links are JTAG (to flash NAND) and UART.
I considered 2 solutions:
-
UART file transfer: boot on a ramdisk from NAND and use a UART file transfer protocol to get the sdimg, then dd it. I did not went this way because it seems unstable and extremely slow, plus the procedure was starting to get complicated (I cannot transfer a 4GB sdimg to 1GB ram, so it requires generating a smaller sdimg and resize data partition afterwards) ;
-
manual partitioning: boot on a ramdisk from NAND and apply following procedure:
- create partition starting from 8MB to 8MB+ ‘rootfs_part_size’ ;
- create partition starting from 8MB + ‘rootfs_part_size’ to '8MB+ ‘rootfs_part_size’ * 2
- create partition starting from 8MB + ‘rootfs_part_size’ * 2 to end of eMMC.
- mkfs.ext4 on 3 created partitions
- extract rootfs (format cpio.gz) to partition #1 and #2
- extract ${DEPLOY_DIR}/data.tar (containing fw_env.config) to partition #3
I chose manual partitioning which I find simpler (no file transfer, NAND is only flashed once) and my goal is to get partitioning/extracting part automated with a script.
It’s seems to be working so far, but since I did not find any information about that, I’ve got several questions:
- why everything has to be 8MB aligned ? (dft value of MENDER_PARTITION_ALIGNMENT_KB) ;
- if it does, 'rootfs_part_size’ needs to be 8MB aligned too, right ? Does the end of data partition too ?
- why is uboot environment redundant, is it in case of memory corruption ?
-
${DEPLOY_DIR}/data.tar only contains u-boot/fw_env.config. Mender seems to be working fine without /data/mender/ directory, but is it true ?
- more generally, does my procedure seem reliable ?
Thanks a lot in advance !
Nicolas
why everything has to be 8MB aligned ? (dft value of MENDER_PARTITION_ALIGNMENT_KB )
No hard requirement for this to be 8MB, and you can adjust this to your hardware layout. But the goal is to align things to erase block sizes, but this can be hard to figure out on eMMC, what the physical erase block size is.
The workaround is to set this to 8MB (overestimation) and this value would be aligned regardless of what the actual physical erase block size is.
- if it does, 'rootfs_part_size ’ needs to be 8MB aligned too, right ? Does the end of data partition too ?
You would typically want all parts to be “block aligned”, otherwise you could overlap between parts, e.g by writing to one part you could potentially erase content on a different part.
- why is uboot environment redundant, is it in case of memory corruption ?
It has to be redundant to achieve robustness against power loss during update. And it is not really a redundant environment, but U-boot deploys a A/B update strategy to the environment when “redundant” is enabled.
- ${DEPLOY_DIR}/data.tar only contains u-boot/fw_env.config . Mender seems to be working fine without /data/mender/ directory, but is it true ?
Hm, it should also contain a mender/device_info
file, and without this it not will function correctly when you try to perform an update.
- more generally, does my procedure seem reliable ?
Looks sane to me and a really nice optimization to speed up things.
Thanks a lot !
Hm, it should also contain a mender/device_info
file, and without this it not will function correctly when you try to perform an update.
Unfortunately I’m stuck on rocko so that could explain why I don’t have /data/mender/device_type
(is that what you meant ?) in ${DEPLOY_DIR}/data.tar
. On rocko this file is installed only when building sdimg
image type. I think I can easily add a recipe that install this file too if needed.
Also, I’ve looked at master branch and it looks like mender.conf
is under /data/mender
, whereas on rocko it’s under /etc/mender
, will it work properly ?
Unfortunately I’m stuck on rocko so that could explain why I don’t have /data/mender/device_type
(is that what you meant ?) in ${DEPLOY_DIR}/data.tar
. On rocko this file is installed only when building sdimg
image type. I think I can easily add a recipe that install this file too if needed.
Yes, that is the file I was referring to. If you find a acceptable workaround please feel free to send a PR to the rocko branch as well.
Also, I’ve looked at master branch and it looks like mender.conf
is under /data/mender
, whereas on rocko it’s under /etc/mender
, will it work properly ?
Nowadays the mender client is able to read mender.conf
from multiple locations and merge them, you can read some of the background info here,
https://tracker.mender.io/browse/MEN-2073
It should work just fine to only have it in /etc/mender/mender.conf
assuming that it contains all the information. You can read more about how mender.conf
works here,
https://docs.mender.io/2.0/client-configuration/configuration-file
Sorry for the late response! Thank you again for all the information.
I did a small change to install device_type
in /data/mender
when I don’t generate sdimg.
I had a look at the Contributing Guide but I’m not sure about a PR, are there some mandatory tests to pass for submitting ? Should I need to check the code on following branches (sumo and thud) to check that my change is compatible ?
I found out that if I want to produce .mender artifact compatible with my manual partitioning, I should abide by the rootfs size calculation done in mender-setup-install.inc
.
So to obtain a 128MB rootfs, I set the following values:
MENDER_BOOT_PART_SIZE_MB = "0"
MENDER_PARTITIONING_OVERHEAD_KB = "0"
MENDER_DATA_PART_SIZE_MB = "0"
MENDER_STORAGE_TOTAL_SIZE_MB = "280" #(8MB (partition table) + 2*8MB (uenv) + 2*128MB (rootfs))
MENDER_PARTITION_ALIGNMENT_KB is not set (8MB kept by default)
It seems to work fine this way, once again do you find any problem with that ?
but I’m not sure about a PR, are there some mandatory tests to pass for submitting ?
There are tests that need to pass, but these will be triggered when you create an PR and not something that you need to run locally.
Should I need to check the code on following branches (sumo and thud) to check that my change is compatible ?
The change can probably be isolated to “rocko” as the behavior has changed on how /data is populated on sumo and thud and I do not think that this problem exists there.
It seems to work fine this way, once again do you find any problem with that ?
I do not see any problems.