The current scripts used the standard mount binary at /bin/mount
for mounting the partitions. Systemd however seems to have a monitor
that eventually umounts such partitions if not mounted by systemd's
specific command 'systemd-mount`.
For platforms using systemd, we need to use this binary together with
parameter --no-block so that partitions are mounted correctly during
the boot process.
This commit merges the two scripts for Digi-handled partitions into
just one:
mount_bootparts.sh
\
+--> mount_digiparts.sh
/
mount_partition.sh
The merged script:
- checks if running with systemd, to use its binary.
- checks if running with busybox, to not use the unsupported '-o'
attribute.
- checks if mounting the 'linux' partition, to mount it read-only.
- checks for already-attached UBI devices, to avoid re-attaching.
This commit also combines the Digi-handled partitions (linux, update)
into the same udev rule, to simplify it, and breaks the rules lines
for readability.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6744
Error message was being printed upon successful copy of the
MAC addresses file, instead of upon failure.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Latest release r10007.1 updates the following files from qca6574au-le-2-2-1_qca_oem
repo at meta_build/firmware/pcie/:
- qwlan30.bin -> qwlan30.bin (60ac4486fba393294b590f86117f5539)
- utf30.bin -> utf.bin (c15794509d8a8435d4244fea699d99b3)
and the following files from meta_build/firmware/sdio/:
- qwlan30.bin -> qwlan30.bin (4421b30ca259ab73bbfa79df807e0b47)
- utf30.bin -> utf30.bin (b2651762aa1d620349593905efab326b)
Update Bluetooth firmware from qca6574au-le-2-2-1_qca_oem repo at
cnss_proc_1/btfm_proc/bt/wcss/bsp/rom/build/SCAQBAF/Test_Files/Linux/
- rampatch_tlv_3.2.tlv -> rampatch_tlv_3.2.tlv (72d28614afd0abe5846c1758099282e3)
- nvm_tlv_3.2.bin -> nvm_tlv_3.2.bin (3de46ea023570b86cabb9502b92a1fed)
Note: nvm_tlv_3.2.bin based on original md5sum
a97cdfe80e8109cf3574f74cd3c73fc7 but changed byte at
offset 0x36 from 0x82 to 0x02 (IBS).
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6725
Remove our .bbappend, which was wrongly making this recipe compatible with the
imx8. Directly port NXP's recipe (v5.4.39), which is newer than the one in
meta-freescale (v5.4.38).
https://jira.digi.com/browse/DEL-6722
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Change the license type from "MIT" to "Proprietary". This change was taken
from the imx-sc-firmware recipe.
https://jira.digi.com/browse/DEL-6722
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Otherwise, users that are behind corporate firewalls might not be able to
obtain the package sources.
https://jira.digi.com/browse/DEL-6663
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
The 'soc_type' variable was already set by fastboot to "imx8qxp"
so the U-Boot board code that was setting this to just "8qxp" has
been changed to set it to "imx8qxp".
Update the scripts accordingly.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DUB-901
On some scenarios, like when booting from NFS, the root filesystem is not
writteable. When this happens the qualcomm.sh is not able to write the MAC
file which so the wireless driver fails to load.
The arguments that U-Boot uses when booting from NFS using dboot result in
the root filesystem being mounted as read-only, but at some point it is
remounted as read/write. This happens after trying to load the wireless
driver, though.
Currently this is the only scenario in which we can reproduce the problem,
and there are several other processes in DEY that require a writeable root
filesystem (wireless SSID editing, Dropbear SSH key-gen and u-boot-fw-utils)
so remount the rootfs as writteable as a workaround.
While on it improve the script a bit to notify on error trying to create
this file, just in case this happens in other scenarios.
https://jira.digi.com/browse/DEL-5854
Signed-off-by: Jose Diaz de Grenu <Jose.DiazdeGrenu@digi.com>
All the dependencies of the required symbols are also added.
These are easier to mantain and enable the minimum support. If extra
features are required they shuold be explicitly added.
https://jira.digi.com/browse/DEL-6681
Signed-off-by: Jose Diaz de Grenu <Jose.DiazdeGrenu@digi.com>
This commit fixes two issues:
- Comparison clause uses only one equal sign
- Fix soc_type for Dual variants because the supported soc types
for the imx8 processor are: 8qm, 8qxp, and 8dx
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
These images were broken in many ways, including ethernet not working and Linux
not booting. For now, revert back to the build command that was used in
DEY-2.6-r1.
https://jira.digi.com/browse/DEL-6677
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
When using virtualization, ammend the kernel configuration so that docker
is supported.
https://jira.digi.com/browse/DEL-6681
Signed-off-by: Jose Diaz de Grenu <Jose.DiazdeGrenu@digi.com>
The meta-freescale-3rdparty layer used for the mainline bsp support does
not support the WiFi interface on thud. WiFi is currently merged on master
so it will probably be available on Zeus (2.8).
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
After the recent changes to generate the bootable artifacts, these are
now formed using the ${MACHINE} variable rather than the string in
${UBOOT_CONFIG} array, so the underscores must be changed with dashes.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
The artifacts that must go inside the installer ZIP image are not anymore
the ones in UBOOT_CONFIG. For CC8X, the artifacts are combinations of
UBOOT_CONFIG and RAM_CONFIGS.
This commit adds a function 'get_bootable_artifacts()' to boot-artifacts class
to generate a new variable BOOTABLE_ARTIFACTS with the list of bootable
artifacts DEY produces.
The installer recipe can then simply iterate on that list, rather than
needing to calculate it by itself.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6641
The existing loops were iterating through all RAM_CONFIGS, but
they must only iterate over those that match the RAM size on the
platform's UBOOT_CONFIG.
This commit adds a Python class 'boot-artifacts' to get the list of matching
combinations of RAM_CONFIGS and UBOOT_CONFIG so that the iteration
is easier to do than nesting loops inside one another.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6641
The recipe was creating a variable with the value of another one from
the main recipe, just to refer to the bootable artifact prefix.
We can now use instead the new UBOOT_PREFIX variable.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
A variable called IMAGE_BOOTLOADER was being used without distinction for
referring to two different things:
- the recipe that builds the bootable artifacts
- the prefix of those artifacts
The value of this is "u-boot" for most platforms, but "imx-boot" for the
CC8X based platforms.
The name of the variable is misleading, so this commit splits it into two:
- BOOTLOADER_IMAGE_RECIPE, to refer to the recipe
- UBOOT_PREFIX, to refer to the prefix of the bootable artifact
With the separation, the variable UBOOT_SYMLINK becomes a generic formed
one, so it is moved to digi-defaults.inc.
While on it, fix the image_types_digi.bbclass which was not making use of
the original variable to establish all the dependencies.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Similar to the way the u-boot recipe does, create a symlink to the default
bootable artifact.
Since they are overwritten on every loop, this requires that the default
RAM configuration is set the last on the list of RAM_CONFIGS (same
convention than the one used on UBOOT_CONFIGS).
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6641
With the rework to support variants, the machine name (actually the
UBOOT_CONFIG) was removed from the filename. Re-add it using
${MACHINE_NAME} which is more appropriate than the ${UBOOT_CONFIG} which
contains the RAM size (now present in ${ramc}).
While on it, remove one of the two symlinks on DEPLOYDIR. Only one makes
sense.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6641
Now the U-Boot binaries contain the RAM frequency and bus width, not just
only the RAM size.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6641
There are several U-Boot binaries, depending on RAM size, at the moment:
- u-boot.bin-ccimx8x_sbc_pro512MB
- u-boot.bin-ccimx8x_sbc_pro1GB
- u-boot.bin-ccimx8x_sbc_pro2GB
and several SCFW files, depending on frequency, size, bus width, at the
moment:
- scfw_tcm.bin-1.2GHz_512B_16bit
- scfw_tcm.bin-1.2GHz_1GB_16bit
- scfw_tcm.bin-1.2GHz_1GB_32bit
- scfw_tcm.bin-1.2GHz_2GB_32bit
From these, we need to combine those that match the RAM size, to produce
bootable images for the different variants.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6641
With the arrival of DualX variants, the device tree files have been renamed
to contain the SOC type (8qxp, or 8dx). This is determined by a new U-Boot
variable 'soc_type'.
Default to "8qxp" if the variable is not defined (old U-Boots).
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6641
With the arrival of DualX variants, the devicetree files have changed
their names to include the soc type (qxp, dx).
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6641
Even though our ccimx6 and ccimx6qp images were using Linux v4.9 sources
correctly, they were using the same recipe as our images with Linux v4.14.
Technically, both recipes are identical (save for the branch name), but each
Linux version should have its own recipe.
Also, make sure that ccimx6/ccimx6qp images are built with our version of the
linux-imx-headers recipe instead of the one in meta-freescale.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
We want to run the script if the 'wireless' node exits on the device tree.
This is to facilitate disabling of the wireless by removing that node.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6616
Hector Palacios
Gabriel Valcazar
Gonzalo Ruiz
Jose Diaz de Grenu
Arturo Buzarra
Alex Gonzalez
Mike Engel