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
This recipe was updated in NXP's 4.14.98-2.0.1 patch release.
https://jira.digi.com/browse/DEL-6618
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
The new HWID fields make U-Boot create new variable 'module_ram'.
If it exists use it to select the U-Boot file to use during
firmware update. If not, fall back to old method of using the
variant code and the hard-coded table of variants.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6598
The new HWID fields make U-Boot create new variable 'module_ram'.
If it exists calculate new HWID fields to check if the SOM has
Wi-Fi, Bluetooth, etc. in order to select the device tree file.
If not, fall back to old method of using the variant code and
the hard-coded table of variants.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6598
P2P disabled is the default in the kernel module, so passing here the
parameter to 'modprobe' does nothing but prevents to set the parameter
in the kernel command line.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
The new development branch is based on NXP's v4.14.98 BSP.
https://jira.digi.com/browse/DEL-6603
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This is the version used in meta-fsl-bsp-release branch sumo-4.14.98-2.0.0_ga
for the imx8qxp.
https://jira.digi.com/browse/DEL-6603
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This recipe's package is meant for packages that require NXP-specific linux
headers.
https://jira.digi.com/browse/DEL-6603
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This is the version used in meta-fsl-bsp-release branch sumo-4.14.98-2.0.0_ga.
https://jira.digi.com/browse/DEL-6603
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This is the version used in meta-fsl-bsp-release branch sumo-4.14.98-2.0.0_ga.
When using v1.5, we used a .bbappend to change the revision of the v1.5 recipe
in meta-freescale. Since we're upgrading to a version that isn't supported in
the other layers yet, remove the .bbappend and add the entire v2.0 recipe.
https://jira.digi.com/browse/DEL-6603
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This is the version used in meta-fsl-bsp-release branch sumo-4.14.98-2.0.0_ga.
https://jira.digi.com/browse/DEL-6603
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Update NXP's .bbclass files with the ones in meta-fsl-bsp-release branch
sumo-4.14.98-2.0.0_ga.
https://jira.digi.com/browse/DEL-6603
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Digi Embedded Yocto 2.6-r1.3
Manually changed recipes to use the master branches instead of the fixed SHA1
from the last release.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
These dependencies went missing when we deleted our first .bb file and replaced
it with a .bbappend. Without these dependencies, the build can sometimes fail.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Removing the flag breaks the build of the freetype package and possibly others.
Leave the flag as it is for now.
This reverts commit e4cbeafa1c.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This option configures gcc to use PIE by default, which is good from a security
standpoint. However, the files necessary to compile applications statically
with PIE support are missing from glibc, causing builds to fail. Said files
were removed on purpose in poky commit 472c86127ab57759588e5ec53c75ebb52667f094
because static PIE binaries apparently don't work very well when using gcc 7.x.
Instead of enabling static PIE support for glibc and risking runtime failures,
revert to our old situation and remove default PIE suport for gcc.
https://jira.digi.com/browse/DEL-6558
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This variant is exactly the same as variant 0x02, but with a new revision
of the i.MX6UL silicon.
https://jira.digi.com/browse/DEL-6555
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This recipe adds a script and a related systemd service that
configures two GPIOs (user defined, or else platform-defaults) as
output and sets them to the appropriate value for initializing the
XBee socket:
- XBEE_SLEEP_RQ: is set low, for running the XBee
- XBEE_RESET_N: is set low and then high, to reset the XBee
The service triggers on the condition that the UART TTY device node
pointed to by variable XBEE_UART exists.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6366
In the update to thud, the recipe for this package was updated in
meta-freescale with a newer revision that, among other things, breaks
compatibility with the parameters we use to recover closed devices via USB.
Even if we change these parameters to obtain a configuration equivalent to the
one we've always had, closed devices still won't boot because the internal
logic of the tool has changed a lot.
Instead of patching the tool for this very specific use-case, revert to the
version we've been using in DEY 2.2 and 2.4.
https://jira.digi.com/browse/DEL-6520
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Hector Palacios
Mike Engel
Gabriel Valcazar
Javier Viguera
Arturo Buzarra
Alex Gonzalez