Tree: e831c16548

1.0.x

1.1.x

1.2.x

2.0.x

2.1.x

2.2.x

2.3.x

2.4.x

2.5.x

2.6.x

2.7.x

3.0.x

4.0.x

automatic_bootstrap_artifact

change-dependabot-prefix

create-pull-request/patch

master

patch-1

pr_475

revert-252-rm-only-tag-2.2.x

1.0.0

1.1.0

1.1.1

1.2.0

1.2.1

1.2.2

2.0.0

2.0.1

2.1.0

2.2.0

2.2.1

2.2.2

2.2.2-build1

2.3.0

2.3.1

2.4.0

2.5.0

2.5.2

2.5.3

2.6.0

2.6.1

2.6.2

2.7.0-build1

3.0.0

3.0.1

3.0.2

4.0.0

4.0.1

Branches Tags

${ item.name }

Create tag ${ searchTerm }

Create branch ${ searchTerm }

from 'e831c16548'

${ noResults }

Commit Graph

4 Commits (e831c16548f3f0fa58534bb3903ae586b58962f9)

Author	SHA1	Message	Date
Ole Petter	83684f80ca	MEN-3051: Update the rockpro64 config to use the new img_path variable Changelog: None Signed-off-by: Ole Petter <ole.orhagen@northern.tech>	5 years ago
Lluis Campos	68b91cbeb2	MEN-2794: Adjust the expected S3 locations for the binaries The S3 path now follows the pattern: /mender/mender-convert/uboot/<dev-family>/<dev-config>-<uboot-ver>.tar For RPi and BBB these are automatically published form the CI Pipeline of repo mender-convert-integration-scripts while for RockPro64 they have been manually moved (as we expect this to be a one time integration). Reworked a bit also the *_BINARIES variable so that we can keep the u-boot version in the base config files and let the childs only define the a config name. Changelog: None Signed-off-by: Lluis Campos <lluis.campos@northern.tech>	5 years ago
Mirza Krak	7320b42f0b	Implement MENDER_COPY_BOOT_GAP feature This is necessary for the U-boot -> EFI -> GRUB integration to be complete as many boards embedd the U-Boot binary at the start of the SD/eMMC a.k.a boot-gap. When MENDER_COPY_BOOT_GAP is enabled, it will be copied from the input disk image to the output ".sdimg" MEN-2784 Changelog: Title Signed-off-by: Mirza Krak <mirza.krak@northern.tech>	5 years ago
Mirza Krak	fac622517c	MEN-2608: add mender-convert (version 2) The goals of the re-write was to achieve the following: 1. It should be easy to extend the tool to support other boards or distributions 2. We should not compile code in the tool (rely on binaries built elsewhere) compiling code increases complexity, due to requirement of toolchains etc. 3. The tool shall not be designed around specific hardware/platform types - This is the case today with the usage of --device-type flag 4 The tool should be to convert images without knowing anything about the hardware/platform relates to above 3. 5. Configuration interface should be simplified - command line flags -> configuration files 6. Platform specific code shall be provided trough “hooks”, and are not part of the “core” mender-convert code 7. It shall be easy to extend functionality - support for rootfs overlay to inject user applications/configurations - ability to override how the Mender Artifact is generated (to be able to sign and include state-scripts) 8. Code structure should be modular - Eases Maintenance and possibility of making isolated changes Changelog: Title Signed-off-by: Mirza Krak <mirza.krak@northern.tech>	6 years ago