* [meta-fsl-arm][PATCH 1/4] core-image-weston: Fail gracefully if using incompatible DISTRO_FEATURES
@ 2015-06-17 18:02 Otavio Salvador
2015-06-17 18:02 ` [meta-fsl-arm][PATCH 2/4] fsl-default-providers.inc: Move content to imx-base.inc and mxs-base.inc Otavio Salvador
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: Otavio Salvador @ 2015-06-17 18:02 UTC (permalink / raw)
To: meta-freescale Mailing List; +Cc: Otavio Salvador
Vivante GPU driver cannot operate in X11 and Wayland in same
distribution as it needs to have different libraries installed. So in
case 'x11' is in DISTRO_FEATURES, Wayland is disabled.
Fixes [YOCTO: #7814].
Change-Id: Ibde60384b1146ecb0aad353cfbc44163b21b4fc1
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
recipes-graphics/images/core-image-weston.bbappend | 4 ++++
1 file changed, 4 insertions(+)
create mode 100644 recipes-graphics/images/core-image-weston.bbappend
diff --git a/recipes-graphics/images/core-image-weston.bbappend b/recipes-graphics/images/core-image-weston.bbappend
new file mode 100644
index 0000000..6e33067
--- /dev/null
+++ b/recipes-graphics/images/core-image-weston.bbappend
@@ -0,0 +1,4 @@
+# FIXME: Vivante GPU driver cannot operate in X11 and Wayland in same
+# distribution as it needs to have different libraries installed. So
+# in case 'x11' is in DISTRO_FEATURES, Wayland is disabled.
+CONFLICT_DISTRO_FEATURES_append_mx6 = " x11"
--
2.4.3
^ permalink raw reply related [flat|nested] 23+ messages in thread
* [meta-fsl-arm][PATCH 2/4] fsl-default-providers.inc: Move content to imx-base.inc and mxs-base.inc
2015-06-17 18:02 [meta-fsl-arm][PATCH 1/4] core-image-weston: Fail gracefully if using incompatible DISTRO_FEATURES Otavio Salvador
@ 2015-06-17 18:02 ` Otavio Salvador
2015-06-17 18:33 ` Nikolay Dimitrov
2015-06-17 18:02 ` [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe Otavio Salvador
2015-06-17 18:02 ` [meta-fsl-arm][PATCH 4/4] imx-base.inc: Use linux-fslc-mx6 for all i.MX6 by default Otavio Salvador
2 siblings, 1 reply; 23+ messages in thread
From: Otavio Salvador @ 2015-06-17 18:02 UTC (permalink / raw)
To: meta-freescale Mailing List; +Cc: Otavio Salvador
The fsl-default-providers.inc is very simple and makes harder to
understand the defaults assumed for i.MX SoCs.
This patch moves the contents of it to the imx-base.inc and
mxs-base.inc so it can be more easily changed.
Change-Id: Ica5e155959dee881be089accc735c6aba6cd0e4d
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
conf/machine/include/fsl-default-providers.inc | 6 ------
conf/machine/include/imx-base.inc | 5 ++++-
conf/machine/include/mxs-base.inc | 5 ++++-
3 files changed, 8 insertions(+), 8 deletions(-)
delete mode 100644 conf/machine/include/fsl-default-providers.inc
diff --git a/conf/machine/include/fsl-default-providers.inc b/conf/machine/include/fsl-default-providers.inc
deleted file mode 100644
index c738d49..0000000
--- a/conf/machine/include/fsl-default-providers.inc
+++ /dev/null
@@ -1,6 +0,0 @@
-# Freescale BSP default providers
-
-PREFERRED_PROVIDER_virtual/xserver = "xserver-xorg"
-PREFERRED_PROVIDER_virtual/kernel ??= "linux-imx"
-PREFERRED_PROVIDER_u-boot ??= "u-boot-fslc"
-PREFERRED_PROVIDER_virtual/bootloader ??= "u-boot-fslc"
diff --git a/conf/machine/include/imx-base.inc b/conf/machine/include/imx-base.inc
index 51625eb..fc50ee1 100644
--- a/conf/machine/include/imx-base.inc
+++ b/conf/machine/include/imx-base.inc
@@ -2,11 +2,12 @@
include conf/machine/include/fsl-default-settings.inc
include conf/machine/include/fsl-default-versions.inc
-include conf/machine/include/fsl-default-providers.inc
include conf/machine/include/soc-family.inc
# Set specific make target and binary suffix
+PREFERRED_PROVIDER_u-boot ??= "u-boot-fslc"
+PREFERRED_PROVIDER_virtual/bootloader ??= "u-boot-fslc"
UBOOT_MAKE_TARGET = "u-boot.imx"
UBOOT_SUFFIX ?= "imx"
@@ -18,6 +19,7 @@ UBOOT_ENTRYPOINT_mx6sl = "0x80008000"
UBOOT_ENTRYPOINT_mx6sx = "0x80008000"
UBOOT_ENTRYPOINT_vf = "0x80008000"
+PREFERRED_PROVIDER_virtual/xserver = "xserver-xorg"
XSERVER_DRIVER = "xf86-video-fbdev"
XSERVER_DRIVER_mx5 = "xf86-video-imxfb"
XSERVER_DRIVER_mx6 = "xf86-video-imxfb-vivante"
@@ -107,6 +109,7 @@ PREFERRED_PROVIDER_virtual/libgl_mx6sx ?= "imx-gpu-viv"
PREFERRED_PROVIDER_virtual/libgl_mx6sl ?= "mesa"
PREFERRED_PROVIDER_virtual/libg2d_mx6 ?= "imx-gpu-viv"
+PREFERRED_PROVIDER_virtual/kernel ??= "linux-imx"
PREFERRED_PROVIDER_virtual/kernel_mx3 ?= "linux-fslc"
SDCARD_ROOTFS ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3"
diff --git a/conf/machine/include/mxs-base.inc b/conf/machine/include/mxs-base.inc
index a6c34e1..8632f15 100644
--- a/conf/machine/include/mxs-base.inc
+++ b/conf/machine/include/mxs-base.inc
@@ -2,19 +2,22 @@
include conf/machine/include/fsl-default-settings.inc
include conf/machine/include/fsl-default-versions.inc
-include conf/machine/include/fsl-default-providers.inc
include conf/machine/include/soc-family.inc
include conf/machine/include/tune-arm926ejs.inc
SOC_FAMILY = "mxs"
+PREFERRED_PROVIDER_virtual/kernel ??= "linux-imx"
PREFERRED_PROVIDER_virtual/kernel_mx23 ?= "linux-fslc"
+PREFERRED_PROVIDER_u-boot ??= "u-boot-fslc"
+PREFERRED_PROVIDER_virtual/bootloader ??= "u-boot-fslc"
UBOOT_ENTRYPOINT = "0x40008000"
UBOOT_MAKE_TARGET = "u-boot.sb"
UBOOT_SUFFIX = "sb"
+PREFERRED_PROVIDER_virtual/xserver = "xserver-xorg"
XSERVER = "xserver-xorg \
xf86-input-evdev \
xf86-video-fbdev"
--
2.4.3
^ permalink raw reply related [flat|nested] 23+ messages in thread
* [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe
2015-06-17 18:02 [meta-fsl-arm][PATCH 1/4] core-image-weston: Fail gracefully if using incompatible DISTRO_FEATURES Otavio Salvador
2015-06-17 18:02 ` [meta-fsl-arm][PATCH 2/4] fsl-default-providers.inc: Move content to imx-base.inc and mxs-base.inc Otavio Salvador
@ 2015-06-17 18:02 ` Otavio Salvador
2015-06-17 18:28 ` Nikolay Dimitrov
2015-06-17 18:02 ` [meta-fsl-arm][PATCH 4/4] imx-base.inc: Use linux-fslc-mx6 for all i.MX6 by default Otavio Salvador
2 siblings, 1 reply; 23+ messages in thread
From: Otavio Salvador @ 2015-06-17 18:02 UTC (permalink / raw)
To: meta-freescale Mailing List; +Cc: Otavio Salvador
This recipe provides the FSL Community's i.MX6 Linux which is a Linux
kernel based on Freescale 3.14.28-1.0.0 GA release, used by FSL
Community BSP in order to provide support for i.MX6 based platforms.
The fork includes the official Linux kernel stable updates, backported
features and fixes coming from the vendors, kernel community or FSL
Community itself.
This version is based on 3.14.44 stable release and includes following
changes on top of both kernels:
9e71c2c ARM: imx_v6_v7_defconfig: Enable kexec support
3b15ffa Revert "net: fec: fix the warning found by dma debug"
3183696 mmc: sdhci-esdhc-imx: Fixup runtime PM conditions during ->probe()
434d1b2 ARM: 8338/1: kexec: Relax SMP validation to improve DT compatibility
33bb67d gpio: generic: clamp retured value to [0,1]
192f32d ARM: imx6sl: Disable imx6sl-specific code when imx6sl SOC support is disabled
Change-Id: I0d5b21a0381c64b323c73cded73a93a4f218f50d
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
recipes-kernel/linux/linux-fslc-mx6/defconfig | 414 ++++++++++++++++++++++
recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb | 16 +
2 files changed, 430 insertions(+)
create mode 100644 recipes-kernel/linux/linux-fslc-mx6/defconfig
create mode 100644 recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb
diff --git a/recipes-kernel/linux/linux-fslc-mx6/defconfig b/recipes-kernel/linux/linux-fslc-mx6/defconfig
new file mode 100644
index 0000000..85d7000
--- /dev/null
+++ b/recipes-kernel/linux/linux-fslc-mx6/defconfig
@@ -0,0 +1,414 @@
+CONFIG_KERNEL_LZO=y
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_LOG_BUF_SHIFT=18
+CONFIG_CGROUPS=y
+CONFIG_RELAY=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_EXPERT=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_PERF_EVENTS=y
+# CONFIG_SLUB_DEBUG is not set
+# CONFIG_COMPAT_BRK is not set
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODVERSIONS=y
+CONFIG_MODULE_SRCVERSION_ALL=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_GPIO_PCA953X=y
+CONFIG_ARCH_MXC=y
+CONFIG_MACH_IMX51_DT=y
+CONFIG_MACH_EUKREA_CPUIMX51SD=y
+CONFIG_SOC_IMX50=y
+CONFIG_SOC_IMX53=y
+CONFIG_SOC_IMX6Q=y
+CONFIG_SOC_IMX6SL=y
+CONFIG_SOC_IMX6SX=y
+CONFIG_SOC_VF610=y
+# CONFIG_SWP_EMULATE is not set
+CONFIG_SMP=y
+CONFIG_VMSPLIT_2G=y
+CONFIG_PREEMPT=y
+CONFIG_AEABI=y
+CONFIG_HIGHMEM=y
+CONFIG_CMA=y
+CONFIG_CMDLINE="noinitrd console=ttymxc0,115200"
+CONFIG_KEXEC=y
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_DEFAULT_GOV_INTERACTIVE=y
+CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
+CONFIG_CPU_FREQ_GOV_POWERSAVE=y
+CONFIG_CPU_FREQ_GOV_USERSPACE=y
+CONFIG_CPU_FREQ_GOV_ONDEMAND=y
+CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
+CONFIG_ARM_IMX6Q_CPUFREQ=y
+CONFIG_CPU_IDLE=y
+CONFIG_VFP=y
+CONFIG_NEON=y
+CONFIG_BINFMT_MISC=m
+CONFIG_PM_RUNTIME=y
+CONFIG_PM_DEBUG=y
+CONFIG_PM_TEST_SUSPEND=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+CONFIG_IPV6=y
+CONFIG_NETFILTER=y
+CONFIG_VLAN_8021Q=y
+CONFIG_LLC2=y
+CONFIG_CAN=y
+CONFIG_CAN_FLEXCAN=y
+CONFIG_CAN_M_CAN=y
+CONFIG_BT=y
+CONFIG_BT_RFCOMM=y
+CONFIG_BT_RFCOMM_TTY=y
+CONFIG_BT_BNEP=y
+CONFIG_BT_BNEP_MC_FILTER=y
+CONFIG_BT_BNEP_PROTO_FILTER=y
+CONFIG_BT_HIDP=y
+CONFIG_BT_HCIBTUSB=y
+CONFIG_BT_HCIBTSDIO=y
+CONFIG_BT_HCIUART=y
+CONFIG_BT_HCIUART_H4=y
+CONFIG_BT_HCIUART_BCSP=y
+CONFIG_BT_HCIUART_ATH3K=y
+CONFIG_BT_HCIBCM203X=y
+CONFIG_BT_ATH3K=y
+CONFIG_CFG80211=y
+CONFIG_MAC80211=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_STANDALONE is not set
+CONFIG_DMA_CMA=y
+CONFIG_CMA_SIZE_MBYTES=320
+CONFIG_IMX_WEIM=y
+CONFIG_CONNECTOR=y
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_JEDECPROBE=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_CFI_STAA=y
+CONFIG_MTD_PHYSMAP_OF=y
+CONFIG_MTD_DATAFLASH=y
+CONFIG_MTD_M25P80=y
+CONFIG_MTD_SST25L=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_GPMI_NAND=y
+CONFIG_MTD_NAND_MXC=y
+CONFIG_MTD_SPI_NOR=y
+CONFIG_SPI_FSL_QUADSPI=y
+CONFIG_MTD_UBI=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=65536
+CONFIG_EEPROM_AT24=y
+CONFIG_EEPROM_AT25=y
+# CONFIG_SCSI_PROC_FS is not set
+CONFIG_BLK_DEV_SD=y
+CONFIG_SCSI_MULTI_LUN=y
+CONFIG_SCSI_CONSTANTS=y
+CONFIG_SCSI_LOGGING=y
+CONFIG_SCSI_SCAN_ASYNC=y
+# CONFIG_SCSI_LOWLEVEL is not set
+CONFIG_ATA=y
+CONFIG_SATA_AHCI_PLATFORM=y
+CONFIG_AHCI_IMX=y
+CONFIG_PATA_IMX=y
+CONFIG_NETDEVICES=y
+# CONFIG_NET_VENDOR_BROADCOM is not set
+CONFIG_CS89x0=y
+CONFIG_CS89x0_PLATFORM=y
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_MICROCHIP is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+CONFIG_SMC91X=y
+CONFIG_SMC911X=y
+CONFIG_SMSC911X=y
+# CONFIG_NET_VENDOR_STMICRO is not set
+CONFIG_USB_PEGASUS=m
+CONFIG_USB_RTL8150=m
+CONFIG_USB_RTL8152=m
+CONFIG_USB_USBNET=m
+CONFIG_USB_NET_CDC_EEM=m
+CONFIG_ATH_CARDS=y
+CONFIG_ATH6KL=m
+CONFIG_ATH6KL_SDIO=m
+CONFIG_BRCMFMAC=m
+# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
+CONFIG_INPUT_EVDEV=y
+CONFIG_INPUT_EVBUG=m
+CONFIG_KEYBOARD_GPIO=y
+CONFIG_KEYBOARD_SNVS_PWRKEY=y
+CONFIG_KEYBOARD_IMX=y
+CONFIG_MOUSE_PS2=m
+CONFIG_MOUSE_PS2_ELANTECH=y
+CONFIG_INPUT_TOUCHSCREEN=y
+CONFIG_TOUCHSCREEN_EGALAX=y
+CONFIG_TOUCHSCREEN_ELAN=y
+CONFIG_TOUCHSCREEN_MAX11801=y
+CONFIG_TOUCHSCREEN_MC13783=y
+CONFIG_TOUCHSCREEN_TSC2007=y
+CONFIG_TOUCHSCREEN_STMPE=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_MMA8450=y
+CONFIG_INPUT_ISL29023=y
+CONFIG_SERIO_SERPORT=m
+# CONFIG_LEGACY_PTYS is not set
+# CONFIG_DEVKMEM is not set
+CONFIG_SERIAL_IMX=y
+CONFIG_SERIAL_IMX_CONSOLE=y
+CONFIG_SERIAL_FSL_LPUART=y
+CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
+CONFIG_FSL_OTP=y
+# CONFIG_I2C_COMPAT is not set
+CONFIG_I2C_CHARDEV=y
+# CONFIG_I2C_HELPER_AUTO is not set
+CONFIG_I2C_ALGOPCF=m
+CONFIG_I2C_ALGOPCA=m
+CONFIG_I2C_IMX=y
+CONFIG_SPI=y
+CONFIG_SPI_IMX=y
+CONFIG_GPIO_SYSFS=y
+CONFIG_POWER_SUPPLY=y
+CONFIG_SABRESD_MAX8903=y
+CONFIG_SENSORS_MAX17135=y
+CONFIG_SENSORS_MAG3110=y
+CONFIG_THERMAL=y
+CONFIG_CPU_THERMAL=y
+CONFIG_IMX_THERMAL=y
+CONFIG_DEVICE_THERMAL=y
+CONFIG_WATCHDOG=y
+CONFIG_IMX2_WDT=y
+CONFIG_MFD_DA9052_I2C=y
+CONFIG_MFD_MC13XXX_SPI=y
+CONFIG_MFD_MC13XXX_I2C=y
+CONFIG_MFD_MAX17135=y
+CONFIG_MFD_SI476X_CORE=y
+CONFIG_MFD_STMPE=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_ANATOP=y
+CONFIG_REGULATOR_DA9052=y
+CONFIG_REGULATOR_MAX17135=y
+CONFIG_REGULATOR_MC13783=y
+CONFIG_REGULATOR_MC13892=y
+CONFIG_REGULATOR_PFUZE100=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_MEDIA_RADIO_SUPPORT=y
+CONFIG_MEDIA_RC_SUPPORT=y
+CONFIG_RC_DEVICES=y
+CONFIG_IR_GPIO_CIR=y
+CONFIG_MEDIA_USB_SUPPORT=y
+CONFIG_USB_VIDEO_CLASS=m
+CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_VIDEO_MXC_OUTPUT=y
+CONFIG_VIDEO_MXC_CAPTURE=m
+CONFIG_MXC_CAMERA_OV5640=m
+CONFIG_MXC_CAMERA_OV5642=m
+CONFIG_MXC_CAMERA_OV5640_MIPI=m
+CONFIG_MXC_TVIN_ADV7180=m
+CONFIG_MXC_IPU_DEVICE_QUEUE_SDC=m
+CONFIG_VIDEO_MXC_IPU_OUTPUT=y
+CONFIG_VIDEO_MXC_PXP_V4L2=y
+CONFIG_VIDEO_MXC_CSI_CAMERA=m
+CONFIG_MXC_VADC=m
+CONFIG_SOC_CAMERA=y
+CONFIG_VIDEO_MX3=y
+CONFIG_V4L_MEM2MEM_DRIVERS=y
+CONFIG_VIDEO_CODA=y
+CONFIG_RADIO_SI476X=y
+CONFIG_SOC_CAMERA_OV2640=y
+CONFIG_DRM=y
+CONFIG_DRM_VIVANTE=y
+CONFIG_FB=y
+CONFIG_FB_MXS=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_LCD_CLASS_DEVICE=y
+CONFIG_LCD_L4F00242T03=y
+CONFIG_LCD_PLATFORM=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_PWM=y
+CONFIG_FB_MXC_SYNC_PANEL=y
+CONFIG_FB_MXC_LDB=y
+CONFIG_FB_MXC_MIPI_DSI=y
+CONFIG_FB_MXC_TRULY_WVGA_SYNC_PANEL=y
+CONFIG_FB_MXC_HDMI=y
+CONFIG_FB_MXC_EINK_PANEL=y
+CONFIG_FB_MXS_SII902X=y
+CONFIG_FB_MXC_DCIC=m
+CONFIG_HANNSTAR_CABC=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
+CONFIG_LOGO=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_USB_AUDIO=m
+CONFIG_SND_SOC=y
+CONFIG_SND_IMX_SOC=y
+CONFIG_SND_SOC_EUKREA_TLV320=y
+CONFIG_SND_SOC_IMX_CS42888=y
+CONFIG_SND_SOC_IMX_WM8962=y
+CONFIG_SND_SOC_IMX_SGTL5000=y
+CONFIG_SND_SOC_IMX_MQS=y
+CONFIG_SND_SOC_IMX_SPDIF=y
+CONFIG_SND_SOC_IMX_MC13783=y
+CONFIG_SND_SOC_IMX_HDMI=y
+CONFIG_SND_SOC_IMX_SI476X=y
+CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_MXC=y
+CONFIG_USB_ACM=m
+CONFIG_USB_STORAGE=y
+CONFIG_USB_CHIPIDEA=y
+CONFIG_USB_CHIPIDEA_UDC=y
+CONFIG_USB_CHIPIDEA_HOST=y
+CONFIG_USB_SERIAL=m
+CONFIG_USB_SERIAL_GENERIC=y
+CONFIG_USB_SERIAL_FTDI_SIO=m
+CONFIG_USB_SERIAL_OPTION=m
+CONFIG_USB_EHSET_TEST_FIXTURE=m
+CONFIG_NOP_USB_XCEIV=y
+CONFIG_USB_MXS_PHY=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_CONFIGFS=m
+CONFIG_USB_CONFIGFS_SERIAL=y
+CONFIG_USB_CONFIGFS_ACM=y
+CONFIG_USB_CONFIGFS_OBEX=y
+CONFIG_USB_CONFIGFS_NCM=y
+CONFIG_USB_CONFIGFS_ECM=y
+CONFIG_USB_CONFIGFS_ECM_SUBSET=y
+CONFIG_USB_CONFIGFS_RNDIS=y
+CONFIG_USB_CONFIGFS_EEM=y
+CONFIG_USB_CONFIGFS_MASS_STORAGE=y
+CONFIG_USB_CONFIGFS_F_LB_SS=y
+CONFIG_USB_CONFIGFS_F_FS=y
+CONFIG_USB_ZERO=m
+CONFIG_USB_ETH=m
+CONFIG_USB_G_NCM=m
+CONFIG_USB_GADGETFS=m
+CONFIG_USB_MASS_STORAGE=m
+CONFIG_USB_G_SERIAL=m
+CONFIG_MMC=y
+CONFIG_MMC_UNSAFE_RESUME=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_SDHCI_ESDHC_IMX=y
+CONFIG_MXC_IPU=y
+CONFIG_MXC_GPU_VIV=y
+CONFIG_MXC_MIPI_CSI2=y
+CONFIG_MXC_MLB150=m
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_ONESHOT=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_BACKLIGHT=y
+CONFIG_LEDS_TRIGGER_GPIO=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_INTF_DEV_UIE_EMUL=y
+CONFIG_RTC_DRV_MC13XXX=y
+CONFIG_RTC_DRV_MXC=y
+CONFIG_RTC_DRV_SNVS=y
+CONFIG_DMADEVICES=y
+CONFIG_MXC_PXP_V2=y
+CONFIG_IMX_SDMA=y
+CONFIG_MXS_DMA=y
+CONFIG_STAGING=y
+CONFIG_STAGING_MEDIA=y
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_IIO=y
+CONFIG_VF610_ADC=y
+CONFIG_PWM=y
+CONFIG_PWM_IMX=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT2_FS_XATTR=y
+CONFIG_EXT2_FS_POSIX_ACL=y
+CONFIG_EXT2_FS_SECURITY=y
+CONFIG_EXT3_FS=y
+CONFIG_EXT3_FS_POSIX_ACL=y
+CONFIG_EXT3_FS_SECURITY=y
+CONFIG_EXT4_FS=y
+CONFIG_EXT4_FS_POSIX_ACL=y
+CONFIG_EXT4_FS_SECURITY=y
+CONFIG_QUOTA=y
+CONFIG_QUOTA_NETLINK_INTERFACE=y
+# CONFIG_PRINT_QUOTA_WARNING is not set
+CONFIG_AUTOFS4_FS=y
+CONFIG_FUSE_FS=y
+CONFIG_ISO9660_FS=m
+CONFIG_JOLIET=y
+CONFIG_ZISOFS=y
+CONFIG_UDF_FS=m
+CONFIG_MSDOS_FS=m
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_JFFS2_FS=y
+CONFIG_UBIFS_FS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
+CONFIG_NFS_V4=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS_DEFAULT="cp437"
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ASCII=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_ISO8859_15=m
+CONFIG_NLS_UTF8=y
+CONFIG_DEBUG_FS=y
+CONFIG_MAGIC_SYSRQ=y
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_DEBUG_BUGVERBOSE is not set
+# CONFIG_FTRACE is not set
+CONFIG_SECURITYFS=y
+CONFIG_CRYPTO_USER=y
+CONFIG_CRYPTO_TEST=m
+CONFIG_CRYPTO_GCM=y
+CONFIG_CRYPTO_CBC=y
+CONFIG_CRYPTO_CTS=y
+CONFIG_CRYPTO_LRW=y
+CONFIG_CRYPTO_XTS=y
+CONFIG_CRYPTO_MD4=y
+CONFIG_CRYPTO_MD5=y
+CONFIG_CRYPTO_MICHAEL_MIC=y
+CONFIG_CRYPTO_RMD128=y
+CONFIG_CRYPTO_RMD160=y
+CONFIG_CRYPTO_RMD256=y
+CONFIG_CRYPTO_RMD320=y
+CONFIG_CRYPTO_SHA1=y
+CONFIG_CRYPTO_SHA512=y
+CONFIG_CRYPTO_TGR192=y
+CONFIG_CRYPTO_WP512=y
+CONFIG_CRYPTO_BLOWFISH=y
+CONFIG_CRYPTO_CAMELLIA=y
+CONFIG_CRYPTO_DES=y
+CONFIG_CRYPTO_TWOFISH=y
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
+CONFIG_CRYPTO_DEV_FSL_CAAM=y
+CONFIG_CRYPTO_DEV_FSL_CAAM_SM=y
+CONFIG_CRYPTO_DEV_FSL_CAAM_SM_TEST=y
+CONFIG_CRYPTO_DEV_FSL_CAAM_SECVIO=y
+CONFIG_CRC_CCITT=m
+CONFIG_CRC_T10DIF=y
+CONFIG_CRC7=m
+CONFIG_LIBCRC32C=m
+CONFIG_FONTS=y
+CONFIG_FONT_8x8=y
+CONFIG_FONT_8x16=y
diff --git a/recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb b/recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb
new file mode 100644
index 0000000..daf396d
--- /dev/null
+++ b/recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb
@@ -0,0 +1,16 @@
+# Copyright (C) 2015 O.S. Systems Software LTDA.
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SUMMARY = "FSL Community BSP i.MX6 Linux kernel with backported features and fixes"
+DESCRIPTION = "Linux kernel based on Freescale 3.14.28 GA release, used by FSL Community BSP in order to \
+provide support for i.MX6 based platforms and include official Linux kernel stable updates, backported \
+features and fixes coming from the vendors, kernel community or FSL Community itself."
+
+include linux-fslc.inc
+
+PV .= "+git${SRCPV}"
+
+SRCBRANCH = "3.14-1.0.x-mx6"
+SRCREV = "9e71c2c628a48c6892a01ea98a818a41357981c1"
+
+COMPATIBLE_MACHINE = "(mx6)"
--
2.4.3
^ permalink raw reply related [flat|nested] 23+ messages in thread
* [meta-fsl-arm][PATCH 4/4] imx-base.inc: Use linux-fslc-mx6 for all i.MX6 by default
2015-06-17 18:02 [meta-fsl-arm][PATCH 1/4] core-image-weston: Fail gracefully if using incompatible DISTRO_FEATURES Otavio Salvador
2015-06-17 18:02 ` [meta-fsl-arm][PATCH 2/4] fsl-default-providers.inc: Move content to imx-base.inc and mxs-base.inc Otavio Salvador
2015-06-17 18:02 ` [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe Otavio Salvador
@ 2015-06-17 18:02 ` Otavio Salvador
2 siblings, 0 replies; 23+ messages in thread
From: Otavio Salvador @ 2015-06-17 18:02 UTC (permalink / raw)
To: meta-freescale Mailing List; +Cc: Otavio Salvador
The linux-fslc-mx6 recipe provides the FSL Community's i.MX6 Linux
which is a Linux kernel based on Freescale GA release, used by FSL
Community BSP in order to provide support for i.MX6 based platforms.
Every machine can override this value but by default the
linux-fslc-mx6 is now used.
Change-Id: Ia80ad8b9a0a8347197a64062513e18ca5e204a3a
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
conf/machine/include/imx-base.inc | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/conf/machine/include/imx-base.inc b/conf/machine/include/imx-base.inc
index fc50ee1..f64ba6b 100644
--- a/conf/machine/include/imx-base.inc
+++ b/conf/machine/include/imx-base.inc
@@ -109,8 +109,11 @@ PREFERRED_PROVIDER_virtual/libgl_mx6sx ?= "imx-gpu-viv"
PREFERRED_PROVIDER_virtual/libgl_mx6sl ?= "mesa"
PREFERRED_PROVIDER_virtual/libg2d_mx6 ?= "imx-gpu-viv"
-PREFERRED_PROVIDER_virtual/kernel ??= "linux-imx"
-PREFERRED_PROVIDER_virtual/kernel_mx3 ?= "linux-fslc"
+# Handle default kernel
+IMX_DEFAULT_KERNEL = "linux-imx"
+IMX_DEFAULT_KERNEL_mx3 = "linux-fslc"
+IMX_DEFAULT_KERNEL_mx6 = "linux-fslc-mx6"
+PREFERRED_PROVIDER_virtual/kernel ??= "${IMX_DEFAULT_KERNEL}"
SDCARD_ROOTFS ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3"
IMAGE_FSTYPES ?= "tar.bz2 ext3 sdcard"
--
2.4.3
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe
2015-06-17 18:02 ` [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe Otavio Salvador
@ 2015-06-17 18:28 ` Nikolay Dimitrov
2015-06-17 18:30 ` Otavio Salvador
0 siblings, 1 reply; 23+ messages in thread
From: Nikolay Dimitrov @ 2015-06-17 18:28 UTC (permalink / raw)
To: Otavio Salvador, meta-freescale Mailing List
Hi Otavio,
On 06/17/2015 09:02 PM, Otavio Salvador wrote:
> This recipe provides the FSL Community's i.MX6 Linux which is a Linux
> kernel based on Freescale 3.14.28-1.0.0 GA release, used by FSL
> Community BSP in order to provide support for i.MX6 based platforms.
>
> The fork includes the official Linux kernel stable updates, backported
> features and fixes coming from the vendors, kernel community or FSL
> Community itself.
>
> This version is based on 3.14.44 stable release and includes following
> changes on top of both kernels:
>
> 9e71c2c ARM: imx_v6_v7_defconfig: Enable kexec support
> 3b15ffa Revert "net: fec: fix the warning found by dma debug"
> 3183696 mmc: sdhci-esdhc-imx: Fixup runtime PM conditions during ->probe()
> 434d1b2 ARM: 8338/1: kexec: Relax SMP validation to improve DT compatibility
> 33bb67d gpio: generic: clamp retured value to [0,1]
> 192f32d ARM: imx6sl: Disable imx6sl-specific code when imx6sl SOC support is disabled
>
> Change-Id: I0d5b21a0381c64b323c73cded73a93a4f218f50d
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> ---
> recipes-kernel/linux/linux-fslc-mx6/defconfig | 414 ++++++++++++++++++++++
> recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb | 16 +
> 2 files changed, 430 insertions(+)
> create mode 100644 recipes-kernel/linux/linux-fslc-mx6/defconfig
> create mode 100644 recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb
I personally think that the naming of this kernel will cause confusion.
Regards,
Nikolay
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe
2015-06-17 18:28 ` Nikolay Dimitrov
@ 2015-06-17 18:30 ` Otavio Salvador
2015-06-17 18:38 ` Nikolay Dimitrov
0 siblings, 1 reply; 23+ messages in thread
From: Otavio Salvador @ 2015-06-17 18:30 UTC (permalink / raw)
To: Nikolay Dimitrov; +Cc: meta-freescale Mailing List
On Wed, Jun 17, 2015 at 3:28 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> On 06/17/2015 09:02 PM, Otavio Salvador wrote:
>> This recipe provides the FSL Community's i.MX6 Linux which is a Linux
>> kernel based on Freescale 3.14.28-1.0.0 GA release, used by FSL
>> Community BSP in order to provide support for i.MX6 based platforms.
>>
>> The fork includes the official Linux kernel stable updates, backported
>> features and fixes coming from the vendors, kernel community or FSL
>> Community itself.
>>
>> This version is based on 3.14.44 stable release and includes following
>> changes on top of both kernels:
>>
>> 9e71c2c ARM: imx_v6_v7_defconfig: Enable kexec support
>> 3b15ffa Revert "net: fec: fix the warning found by dma debug"
>> 3183696 mmc: sdhci-esdhc-imx: Fixup runtime PM conditions during ->probe()
>> 434d1b2 ARM: 8338/1: kexec: Relax SMP validation to improve DT
>> compatibility
>> 33bb67d gpio: generic: clamp retured value to [0,1]
>> 192f32d ARM: imx6sl: Disable imx6sl-specific code when imx6sl SOC support
>> is disabled
>>
>> Change-Id: I0d5b21a0381c64b323c73cded73a93a4f218f50d
>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>> ---
>> recipes-kernel/linux/linux-fslc-mx6/defconfig | 414
>> ++++++++++++++++++++++
>> recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb | 16 +
>> 2 files changed, 430 insertions(+)
>> create mode 100644 recipes-kernel/linux/linux-fslc-mx6/defconfig
>> create mode 100644 recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb
>
>
> I personally think that the naming of this kernel will cause confusion.
Any suggestion?
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [meta-fsl-arm][PATCH 2/4] fsl-default-providers.inc: Move content to imx-base.inc and mxs-base.inc
2015-06-17 18:02 ` [meta-fsl-arm][PATCH 2/4] fsl-default-providers.inc: Move content to imx-base.inc and mxs-base.inc Otavio Salvador
@ 2015-06-17 18:33 ` Nikolay Dimitrov
2015-06-17 18:38 ` Otavio Salvador
0 siblings, 1 reply; 23+ messages in thread
From: Nikolay Dimitrov @ 2015-06-17 18:33 UTC (permalink / raw)
To: Otavio Salvador, meta-freescale Mailing List
Hi Otavio,
On 06/17/2015 09:02 PM, Otavio Salvador wrote:
> The fsl-default-providers.inc is very simple and makes harder to
> understand the defaults assumed for i.MX SoCs.
>
> This patch moves the contents of it to the imx-base.inc and
> mxs-base.inc so it can be more easily changed.
>
> Change-Id: Ica5e155959dee881be089accc735c6aba6cd0e4d
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> ---
> conf/machine/include/fsl-default-providers.inc | 6 ------
> conf/machine/include/imx-base.inc | 5 ++++-
> conf/machine/include/mxs-base.inc | 5 ++++-
> 3 files changed, 8 insertions(+), 8 deletions(-)
> delete mode 100644 conf/machine/include/fsl-default-providers.inc
>
> diff --git a/conf/machine/include/fsl-default-providers.inc b/conf/machine/include/fsl-default-providers.inc
> deleted file mode 100644
> index c738d49..0000000
> --- a/conf/machine/include/fsl-default-providers.inc
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -# Freescale BSP default providers
> -
> -PREFERRED_PROVIDER_virtual/xserver = "xserver-xorg"
> -PREFERRED_PROVIDER_virtual/kernel ??= "linux-imx"
> -PREFERRED_PROVIDER_u-boot ??= "u-boot-fslc"
> -PREFERRED_PROVIDER_virtual/bootloader ??= "u-boot-fslc"
> diff --git a/conf/machine/include/imx-base.inc b/conf/machine/include/imx-base.inc
> index 51625eb..fc50ee1 100644
> --- a/conf/machine/include/imx-base.inc
> +++ b/conf/machine/include/imx-base.inc
> @@ -2,11 +2,12 @@
>
> include conf/machine/include/fsl-default-settings.inc
> include conf/machine/include/fsl-default-versions.inc
> -include conf/machine/include/fsl-default-providers.inc
>
> include conf/machine/include/soc-family.inc
>
> # Set specific make target and binary suffix
> +PREFERRED_PROVIDER_u-boot ??= "u-boot-fslc"
> +PREFERRED_PROVIDER_virtual/bootloader ??= "u-boot-fslc"
We had a discussion about why should both u-boot and virtual/bootloader
to be set at the same value, at the same time. My experience with
Dizzy/Fido shows that I can usually get away with only setting the
u-boot preferred provider. Is it possible at some point to have only
one of these variables?
> UBOOT_MAKE_TARGET = "u-boot.imx"
> UBOOT_SUFFIX ?= "imx"
>
> @@ -18,6 +19,7 @@ UBOOT_ENTRYPOINT_mx6sl = "0x80008000"
> UBOOT_ENTRYPOINT_mx6sx = "0x80008000"
> UBOOT_ENTRYPOINT_vf = "0x80008000"
>
> +PREFERRED_PROVIDER_virtual/xserver = "xserver-xorg"
> XSERVER_DRIVER = "xf86-video-fbdev"
> XSERVER_DRIVER_mx5 = "xf86-video-imxfb"
> XSERVER_DRIVER_mx6 = "xf86-video-imxfb-vivante"
> @@ -107,6 +109,7 @@ PREFERRED_PROVIDER_virtual/libgl_mx6sx ?= "imx-gpu-viv"
> PREFERRED_PROVIDER_virtual/libgl_mx6sl ?= "mesa"
> PREFERRED_PROVIDER_virtual/libg2d_mx6 ?= "imx-gpu-viv"
>
> +PREFERRED_PROVIDER_virtual/kernel ??= "linux-imx"
> PREFERRED_PROVIDER_virtual/kernel_mx3 ?= "linux-fslc"
>
> SDCARD_ROOTFS ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ext3"
> diff --git a/conf/machine/include/mxs-base.inc b/conf/machine/include/mxs-base.inc
> index a6c34e1..8632f15 100644
> --- a/conf/machine/include/mxs-base.inc
> +++ b/conf/machine/include/mxs-base.inc
> @@ -2,19 +2,22 @@
>
> include conf/machine/include/fsl-default-settings.inc
> include conf/machine/include/fsl-default-versions.inc
> -include conf/machine/include/fsl-default-providers.inc
>
> include conf/machine/include/soc-family.inc
> include conf/machine/include/tune-arm926ejs.inc
>
> SOC_FAMILY = "mxs"
>
> +PREFERRED_PROVIDER_virtual/kernel ??= "linux-imx"
> PREFERRED_PROVIDER_virtual/kernel_mx23 ?= "linux-fslc"
>
> +PREFERRED_PROVIDER_u-boot ??= "u-boot-fslc"
> +PREFERRED_PROVIDER_virtual/bootloader ??= "u-boot-fslc"
> UBOOT_ENTRYPOINT = "0x40008000"
> UBOOT_MAKE_TARGET = "u-boot.sb"
> UBOOT_SUFFIX = "sb"
>
> +PREFERRED_PROVIDER_virtual/xserver = "xserver-xorg"
> XSERVER = "xserver-xorg \
> xf86-input-evdev \
> xf86-video-fbdev"
>
Regards,
Nikolay
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe
2015-06-17 18:30 ` Otavio Salvador
@ 2015-06-17 18:38 ` Nikolay Dimitrov
2015-06-17 18:39 ` Otavio Salvador
0 siblings, 1 reply; 23+ messages in thread
From: Nikolay Dimitrov @ 2015-06-17 18:38 UTC (permalink / raw)
To: Otavio Salvador; +Cc: meta-freescale Mailing List
Hi Otavio,
On 06/17/2015 09:30 PM, Otavio Salvador wrote:
> On Wed, Jun 17, 2015 at 3:28 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>> On 06/17/2015 09:02 PM, Otavio Salvador wrote:
>>> This recipe provides the FSL Community's i.MX6 Linux which is a Linux
>>> kernel based on Freescale 3.14.28-1.0.0 GA release, used by FSL
>>> Community BSP in order to provide support for i.MX6 based platforms.
>>>
>>> The fork includes the official Linux kernel stable updates, backported
>>> features and fixes coming from the vendors, kernel community or FSL
>>> Community itself.
>>>
>>> This version is based on 3.14.44 stable release and includes following
>>> changes on top of both kernels:
>>>
>>> 9e71c2c ARM: imx_v6_v7_defconfig: Enable kexec support
>>> 3b15ffa Revert "net: fec: fix the warning found by dma debug"
>>> 3183696 mmc: sdhci-esdhc-imx: Fixup runtime PM conditions during ->probe()
>>> 434d1b2 ARM: 8338/1: kexec: Relax SMP validation to improve DT
>>> compatibility
>>> 33bb67d gpio: generic: clamp retured value to [0,1]
>>> 192f32d ARM: imx6sl: Disable imx6sl-specific code when imx6sl SOC support
>>> is disabled
>>>
>>> Change-Id: I0d5b21a0381c64b323c73cded73a93a4f218f50d
>>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>>> ---
>>> recipes-kernel/linux/linux-fslc-mx6/defconfig | 414
>>> ++++++++++++++++++++++
>>> recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb | 16 +
>>> 2 files changed, 430 insertions(+)
>>> create mode 100644 recipes-kernel/linux/linux-fslc-mx6/defconfig
>>> create mode 100644 recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb
>>
>>
>> I personally think that the naming of this kernel will cause confusion.
>
> Any suggestion?
Anything that doesn't contain "fslc", like "linux-fsl", "linux-imx",
"linux-imx6" or similar.
What do you think?
Regards,
Nikolay
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [meta-fsl-arm][PATCH 2/4] fsl-default-providers.inc: Move content to imx-base.inc and mxs-base.inc
2015-06-17 18:33 ` Nikolay Dimitrov
@ 2015-06-17 18:38 ` Otavio Salvador
2015-06-17 19:27 ` Nikolay Dimitrov
0 siblings, 1 reply; 23+ messages in thread
From: Otavio Salvador @ 2015-06-17 18:38 UTC (permalink / raw)
To: Nikolay Dimitrov; +Cc: meta-freescale Mailing List
On Wed, Jun 17, 2015 at 3:33 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> On 06/17/2015 09:02 PM, Otavio Salvador wrote:
...
>> # Set specific make target and binary suffix
>> +PREFERRED_PROVIDER_u-boot ??= "u-boot-fslc"
>> +PREFERRED_PROVIDER_virtual/bootloader ??= "u-boot-fslc"
>
>
> We had a discussion about why should both u-boot and virtual/bootloader
> to be set at the same value, at the same time. My experience with
> Dizzy/Fido shows that I can usually get away with only setting the
> u-boot preferred provider. Is it possible at some point to have only
> one of these variables?
Yes; this needs to be cleaned up but I didn't find the time to do so.
If you want to jump in, be my guest ;-)
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe
2015-06-17 18:38 ` Nikolay Dimitrov
@ 2015-06-17 18:39 ` Otavio Salvador
2015-06-17 19:25 ` Nikolay Dimitrov
0 siblings, 1 reply; 23+ messages in thread
From: Otavio Salvador @ 2015-06-17 18:39 UTC (permalink / raw)
To: Nikolay Dimitrov; +Cc: meta-freescale Mailing List
On Wed, Jun 17, 2015 at 3:38 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> On 06/17/2015 09:30 PM, Otavio Salvador wrote:
>> On Wed, Jun 17, 2015 at 3:28 PM, Nikolay Dimitrov <picmaster@mail.bg>
>> wrote:
>>>
>>> On 06/17/2015 09:02 PM, Otavio Salvador wrote:
>>>>
>>>> This recipe provides the FSL Community's i.MX6 Linux which is a Linux
>>>> kernel based on Freescale 3.14.28-1.0.0 GA release, used by FSL
>>>> Community BSP in order to provide support for i.MX6 based platforms.
>>>>
>>>> The fork includes the official Linux kernel stable updates, backported
>>>> features and fixes coming from the vendors, kernel community or FSL
>>>> Community itself.
>>>>
>>>> This version is based on 3.14.44 stable release and includes following
>>>> changes on top of both kernels:
>>>>
>>>> 9e71c2c ARM: imx_v6_v7_defconfig: Enable kexec support
>>>> 3b15ffa Revert "net: fec: fix the warning found by dma debug"
>>>> 3183696 mmc: sdhci-esdhc-imx: Fixup runtime PM conditions during
>>>> ->probe()
>>>> 434d1b2 ARM: 8338/1: kexec: Relax SMP validation to improve DT
>>>> compatibility
>>>> 33bb67d gpio: generic: clamp retured value to [0,1]
>>>> 192f32d ARM: imx6sl: Disable imx6sl-specific code when imx6sl SOC
>>>> support
>>>> is disabled
>>>>
>>>> Change-Id: I0d5b21a0381c64b323c73cded73a93a4f218f50d
>>>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>>>> ---
>>>> recipes-kernel/linux/linux-fslc-mx6/defconfig | 414
>>>> ++++++++++++++++++++++
>>>> recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb | 16 +
>>>> 2 files changed, 430 insertions(+)
>>>> create mode 100644 recipes-kernel/linux/linux-fslc-mx6/defconfig
>>>> create mode 100644 recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb
>>>
>>>
>>>
>>> I personally think that the naming of this kernel will cause confusion.
>>
>>
>> Any suggestion?
>
>
> Anything that doesn't contain "fslc", like "linux-fsl", "linux-imx",
> "linux-imx6" or similar.
>
> What do you think?
I think it is important to provide the credit to fslc as this is not
an fsl initiative or a generic imx kernel.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe
2015-06-17 18:39 ` Otavio Salvador
@ 2015-06-17 19:25 ` Nikolay Dimitrov
2015-06-17 19:32 ` Daiane Angolini
2015-06-17 19:45 ` Otavio Salvador
0 siblings, 2 replies; 23+ messages in thread
From: Nikolay Dimitrov @ 2015-06-17 19:25 UTC (permalink / raw)
To: Otavio Salvador; +Cc: meta-freescale Mailing List
Hi Otavio,
On 06/17/2015 09:39 PM, Otavio Salvador wrote:
> On Wed, Jun 17, 2015 at 3:38 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>> On 06/17/2015 09:30 PM, Otavio Salvador wrote:
>>> On Wed, Jun 17, 2015 at 3:28 PM, Nikolay Dimitrov <picmaster@mail.bg>
>>> wrote:
>>>>
>>>> On 06/17/2015 09:02 PM, Otavio Salvador wrote:
>>>>>
>>>>> This recipe provides the FSL Community's i.MX6 Linux which is a Linux
>>>>> kernel based on Freescale 3.14.28-1.0.0 GA release, used by FSL
>>>>> Community BSP in order to provide support for i.MX6 based platforms.
>>>>>
>>>>> The fork includes the official Linux kernel stable updates, backported
>>>>> features and fixes coming from the vendors, kernel community or FSL
>>>>> Community itself.
>>>>>
>>>>> This version is based on 3.14.44 stable release and includes following
>>>>> changes on top of both kernels:
>>>>>
>>>>> 9e71c2c ARM: imx_v6_v7_defconfig: Enable kexec support
>>>>> 3b15ffa Revert "net: fec: fix the warning found by dma debug"
>>>>> 3183696 mmc: sdhci-esdhc-imx: Fixup runtime PM conditions during
>>>>> ->probe()
>>>>> 434d1b2 ARM: 8338/1: kexec: Relax SMP validation to improve DT
>>>>> compatibility
>>>>> 33bb67d gpio: generic: clamp retured value to [0,1]
>>>>> 192f32d ARM: imx6sl: Disable imx6sl-specific code when imx6sl SOC
>>>>> support
>>>>> is disabled
>>>>>
>>>>> Change-Id: I0d5b21a0381c64b323c73cded73a93a4f218f50d
>>>>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>>>>> ---
>>>>> recipes-kernel/linux/linux-fslc-mx6/defconfig | 414
>>>>> ++++++++++++++++++++++
>>>>> recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb | 16 +
>>>>> 2 files changed, 430 insertions(+)
>>>>> create mode 100644 recipes-kernel/linux/linux-fslc-mx6/defconfig
>>>>> create mode 100644 recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb
>>>>
>>>>
>>>>
>>>> I personally think that the naming of this kernel will cause confusion.
>>>
>>>
>>> Any suggestion?
>>
>>
>> Anything that doesn't contain "fslc", like "linux-fsl", "linux-imx",
>> "linux-imx6" or similar.
>>
>> What do you think?
>
> I think it is important to provide the credit to fslc as this is not
> an fsl initiative or a generic imx kernel.
I think the credit already goes everywhere - source code license,
author's rights in each file, etc. To be honest, I was thinking mostly
about functionality and not about credit.
So, in terms of functionality this kernel sits somewhere between
mainline and FSL releases, is that correct?
Regards,
Nikolay
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [meta-fsl-arm][PATCH 2/4] fsl-default-providers.inc: Move content to imx-base.inc and mxs-base.inc
2015-06-17 18:38 ` Otavio Salvador
@ 2015-06-17 19:27 ` Nikolay Dimitrov
0 siblings, 0 replies; 23+ messages in thread
From: Nikolay Dimitrov @ 2015-06-17 19:27 UTC (permalink / raw)
To: Otavio Salvador; +Cc: meta-freescale Mailing List
Hi Otavio,
On 06/17/2015 09:38 PM, Otavio Salvador wrote:
> On Wed, Jun 17, 2015 at 3:33 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>> On 06/17/2015 09:02 PM, Otavio Salvador wrote:
> ...
>>> # Set specific make target and binary suffix
>>> +PREFERRED_PROVIDER_u-boot ??= "u-boot-fslc"
>>> +PREFERRED_PROVIDER_virtual/bootloader ??= "u-boot-fslc"
>>
>>
>> We had a discussion about why should both u-boot and virtual/bootloader
>> to be set at the same value, at the same time. My experience with
>> Dizzy/Fido shows that I can usually get away with only setting the
>> u-boot preferred provider. Is it possible at some point to have only
>> one of these variables?
>
> Yes; this needs to be cleaned up but I didn't find the time to do so.
> If you want to jump in, be my guest ;-)
My question was whether you added both variables by knowing that this
will be the long-term solution, or it was just inherited as code from
the current recipes :D. Thanks for clarifying this.
Regards,
Nikolay
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe
2015-06-17 19:25 ` Nikolay Dimitrov
@ 2015-06-17 19:32 ` Daiane Angolini
2015-06-17 19:45 ` Otavio Salvador
1 sibling, 0 replies; 23+ messages in thread
From: Daiane Angolini @ 2015-06-17 19:32 UTC (permalink / raw)
To: Nikolay Dimitrov; +Cc: meta-freescale Mailing List, Otavio Salvador
On Wed, Jun 17, 2015 at 4:25 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> Hi Otavio,
>
>
> On 06/17/2015 09:39 PM, Otavio Salvador wrote:
>>
>> On Wed, Jun 17, 2015 at 3:38 PM, Nikolay Dimitrov <picmaster@mail.bg>
>> wrote:
>>>
>>> On 06/17/2015 09:30 PM, Otavio Salvador wrote:
>>>>
>>>> On Wed, Jun 17, 2015 at 3:28 PM, Nikolay Dimitrov <picmaster@mail.bg>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 06/17/2015 09:02 PM, Otavio Salvador wrote:
>>>>>>
>>>>>>
>>>>>> This recipe provides the FSL Community's i.MX6 Linux which is a Linux
>>>>>> kernel based on Freescale 3.14.28-1.0.0 GA release, used by FSL
>>>>>> Community BSP in order to provide support for i.MX6 based platforms.
>>>>>>
>>>>>> The fork includes the official Linux kernel stable updates, backported
>>>>>> features and fixes coming from the vendors, kernel community or FSL
>>>>>> Community itself.
>>>>>>
>>>>>> This version is based on 3.14.44 stable release and includes following
>>>>>> changes on top of both kernels:
>>>>>>
>>>>>> 9e71c2c ARM: imx_v6_v7_defconfig: Enable kexec support
>>>>>> 3b15ffa Revert "net: fec: fix the warning found by dma debug"
>>>>>> 3183696 mmc: sdhci-esdhc-imx: Fixup runtime PM conditions during
>>>>>> ->probe()
>>>>>> 434d1b2 ARM: 8338/1: kexec: Relax SMP validation to improve DT
>>>>>> compatibility
>>>>>> 33bb67d gpio: generic: clamp retured value to [0,1]
>>>>>> 192f32d ARM: imx6sl: Disable imx6sl-specific code when imx6sl SOC
>>>>>> support
>>>>>> is disabled
>>>>>>
>>>>>> Change-Id: I0d5b21a0381c64b323c73cded73a93a4f218f50d
>>>>>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>>>>>> ---
>>>>>> recipes-kernel/linux/linux-fslc-mx6/defconfig | 414
>>>>>> ++++++++++++++++++++++
>>>>>> recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb | 16 +
>>>>>> 2 files changed, 430 insertions(+)
>>>>>> create mode 100644 recipes-kernel/linux/linux-fslc-mx6/defconfig
>>>>>> create mode 100644
>>>>>> recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I personally think that the naming of this kernel will cause confusion.
>>>>
>>>>
>>>>
>>>> Any suggestion?
>>>
>>>
>>>
>>> Anything that doesn't contain "fslc", like "linux-fsl", "linux-imx",
>>> "linux-imx6" or similar.
>>>
>>> What do you think?
>>
>>
>> I think it is important to provide the credit to fslc as this is not
>> an fsl initiative or a generic imx kernel.
>
>
> I think the credit already goes everywhere - source code license,
> author's rights in each file, etc. To be honest, I was thinking mostly
> about functionality and not about credit.
I'm OK with revisiting this kernel provider naming topic. Because it's
always healthy to rework or reorganize, and because it's a while (I
think more than 3 years?) that we had this discussion in the past. So,
I do want to hear suggestions as well.
However, if this kernel provider get a name change, linux-fslc must
follow the same pattern. At the end, they point to the same git
repository, which is going to follow the same pattern as well.
Daiane
>
> So, in terms of functionality this kernel sits somewhere between
> mainline and FSL releases, is that correct?
>
> Regards,
> Nikolay
>
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe
2015-06-17 19:25 ` Nikolay Dimitrov
2015-06-17 19:32 ` Daiane Angolini
@ 2015-06-17 19:45 ` Otavio Salvador
2015-06-18 13:40 ` Daiane Angolini
1 sibling, 1 reply; 23+ messages in thread
From: Otavio Salvador @ 2015-06-17 19:45 UTC (permalink / raw)
To: Nikolay Dimitrov; +Cc: meta-freescale Mailing List
On Wed, Jun 17, 2015 at 4:25 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> On 06/17/2015 09:39 PM, Otavio Salvador wrote:
>>
>> On Wed, Jun 17, 2015 at 3:38 PM, Nikolay Dimitrov <picmaster@mail.bg>
>> wrote:
>>>
>>> On 06/17/2015 09:30 PM, Otavio Salvador wrote:
>>>>
>>>> On Wed, Jun 17, 2015 at 3:28 PM, Nikolay Dimitrov <picmaster@mail.bg>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 06/17/2015 09:02 PM, Otavio Salvador wrote:
>>>>>>
>>>>>>
>>>>>> This recipe provides the FSL Community's i.MX6 Linux which is a Linux
>>>>>> kernel based on Freescale 3.14.28-1.0.0 GA release, used by FSL
>>>>>> Community BSP in order to provide support for i.MX6 based platforms.
>>>>>>
>>>>>> The fork includes the official Linux kernel stable updates, backported
>>>>>> features and fixes coming from the vendors, kernel community or FSL
>>>>>> Community itself.
>>>>>>
>>>>>> This version is based on 3.14.44 stable release and includes following
>>>>>> changes on top of both kernels:
>>>>>>
>>>>>> 9e71c2c ARM: imx_v6_v7_defconfig: Enable kexec support
>>>>>> 3b15ffa Revert "net: fec: fix the warning found by dma debug"
>>>>>> 3183696 mmc: sdhci-esdhc-imx: Fixup runtime PM conditions during
>>>>>> ->probe()
>>>>>> 434d1b2 ARM: 8338/1: kexec: Relax SMP validation to improve DT
>>>>>> compatibility
>>>>>> 33bb67d gpio: generic: clamp retured value to [0,1]
>>>>>> 192f32d ARM: imx6sl: Disable imx6sl-specific code when imx6sl SOC
>>>>>> support
>>>>>> is disabled
>>>>>>
>>>>>> Change-Id: I0d5b21a0381c64b323c73cded73a93a4f218f50d
>>>>>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>>>>>> ---
>>>>>> recipes-kernel/linux/linux-fslc-mx6/defconfig | 414
>>>>>> ++++++++++++++++++++++
>>>>>> recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb | 16 +
>>>>>> 2 files changed, 430 insertions(+)
>>>>>> create mode 100644 recipes-kernel/linux/linux-fslc-mx6/defconfig
>>>>>> create mode 100644
>>>>>> recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I personally think that the naming of this kernel will cause confusion.
>>>>
>>>>
>>>>
>>>> Any suggestion?
>>>
>>>
>>>
>>> Anything that doesn't contain "fslc", like "linux-fsl", "linux-imx",
>>> "linux-imx6" or similar.
>>>
>>> What do you think?
>>
>>
>> I think it is important to provide the credit to fslc as this is not
>> an fsl initiative or a generic imx kernel.
>
>
> I think the credit already goes everywhere - source code license,
> author's rights in each file, etc. To be honest, I was thinking mostly
> about functionality and not about credit.
>
> So, in terms of functionality this kernel sits somewhere between
> mainline and FSL releases, is that correct?
Yes; it is FSL release + stable releases + vendor/community fixes
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe
2015-06-17 19:45 ` Otavio Salvador
@ 2015-06-18 13:40 ` Daiane Angolini
2015-06-18 13:58 ` Otavio Salvador
0 siblings, 1 reply; 23+ messages in thread
From: Daiane Angolini @ 2015-06-18 13:40 UTC (permalink / raw)
To: Otavio Salvador; +Cc: meta-freescale Mailing List
On Wed, Jun 17, 2015 at 4:45 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Wed, Jun 17, 2015 at 4:25 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>> On 06/17/2015 09:39 PM, Otavio Salvador wrote:
>>>
>>> On Wed, Jun 17, 2015 at 3:38 PM, Nikolay Dimitrov <picmaster@mail.bg>
>>> wrote:
>>>>
>>>> On 06/17/2015 09:30 PM, Otavio Salvador wrote:
>>>>>
>>>>> On Wed, Jun 17, 2015 at 3:28 PM, Nikolay Dimitrov <picmaster@mail.bg>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On 06/17/2015 09:02 PM, Otavio Salvador wrote:
>>>>>>>
>>>>>>>
>>>>>>> This recipe provides the FSL Community's i.MX6 Linux which is a Linux
>>>>>>> kernel based on Freescale 3.14.28-1.0.0 GA release, used by FSL
>>>>>>> Community BSP in order to provide support for i.MX6 based platforms.
>>>>>>>
>>>>>>> The fork includes the official Linux kernel stable updates, backported
>>>>>>> features and fixes coming from the vendors, kernel community or FSL
>>>>>>> Community itself.
>>>>>>>
>>>>>>> This version is based on 3.14.44 stable release and includes following
>>>>>>> changes on top of both kernels:
>>>>>>>
>>>>>>> 9e71c2c ARM: imx_v6_v7_defconfig: Enable kexec support
>>>>>>> 3b15ffa Revert "net: fec: fix the warning found by dma debug"
>>>>>>> 3183696 mmc: sdhci-esdhc-imx: Fixup runtime PM conditions during
>>>>>>> ->probe()
>>>>>>> 434d1b2 ARM: 8338/1: kexec: Relax SMP validation to improve DT
>>>>>>> compatibility
>>>>>>> 33bb67d gpio: generic: clamp retured value to [0,1]
>>>>>>> 192f32d ARM: imx6sl: Disable imx6sl-specific code when imx6sl SOC
>>>>>>> support
>>>>>>> is disabled
>>>>>>>
>>>>>>> Change-Id: I0d5b21a0381c64b323c73cded73a93a4f218f50d
>>>>>>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>>>>>>> ---
>>>>>>> recipes-kernel/linux/linux-fslc-mx6/defconfig | 414
>>>>>>> ++++++++++++++++++++++
>>>>>>> recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb | 16 +
>>>>>>> 2 files changed, 430 insertions(+)
>>>>>>> create mode 100644 recipes-kernel/linux/linux-fslc-mx6/defconfig
>>>>>>> create mode 100644
>>>>>>> recipes-kernel/linux/linux-fslc-mx6_3.14-1.0.x.bb
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I personally think that the naming of this kernel will cause confusion.
>>>>>
>>>>>
>>>>>
>>>>> Any suggestion?
>>>>
>>>>
>>>>
>>>> Anything that doesn't contain "fslc", like "linux-fsl", "linux-imx",
>>>> "linux-imx6" or similar.
>>>>
>>>> What do you think?
>>>
>>>
>>> I think it is important to provide the credit to fslc as this is not
>>> an fsl initiative or a generic imx kernel.
>>
>>
>> I think the credit already goes everywhere - source code license,
>> author's rights in each file, etc. To be honest, I was thinking mostly
>> about functionality and not about credit.
>>
>> So, in terms of functionality this kernel sits somewhere between
>> mainline and FSL releases, is that correct?
>
> Yes; it is FSL release + stable releases + vendor/community fixes
I've been thinking about this issue. And this provider (for imx6 only)
may make sense to have "fslc" sufix, exactly because it has freescale
+ community patches
However, the other (currently linux-fslc) does not make sense. Maybe
linux-cmt makes more sense today.
I remember one of the arguments to not use only "linux" and use a
prefix was that it's not a pure mainline provider (it clones from
github) and because it leave the "linux" only for internal kernels
Any other suggestion?
Daiane
>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.br http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe
2015-06-18 13:40 ` Daiane Angolini
@ 2015-06-18 13:58 ` Otavio Salvador
2015-06-18 15:32 ` Nikolay Dimitrov
2015-06-18 17:10 ` Nikolay Dimitrov
0 siblings, 2 replies; 23+ messages in thread
From: Otavio Salvador @ 2015-06-18 13:58 UTC (permalink / raw)
To: Daiane Angolini; +Cc: meta-freescale Mailing List
On Thu, Jun 18, 2015 at 10:40 AM, Daiane Angolini <daiane.list@gmail.com> wrote:
> On Wed, Jun 17, 2015 at 4:45 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Wed, Jun 17, 2015 at 4:25 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>>> So, in terms of functionality this kernel sits somewhere between
>>> mainline and FSL releases, is that correct?
>>
>> Yes; it is FSL release + stable releases + vendor/community fixes
>
> I've been thinking about this issue. And this provider (for imx6 only)
> may make sense to have "fslc" sufix, exactly because it has freescale
> + community patches
>
> However, the other (currently linux-fslc) does not make sense. Maybe
> linux-cmt makes more sense today.
>
> I remember one of the arguments to not use only "linux" and use a
> prefix was that it's not a pure mainline provider (it clones from
> github) and because it leave the "linux" only for internal kernels
>
> Any other suggestion?
I think we need to consider some things here:
linux-fslc is a kernel tree we maintain
u-boot-fslc is a u-boot tree we maintain
both have same goals and the idea is to provide a place to share
patches and backports.
The motivation to make the 3.14 is because FSL is not taking the fixes
and security updates from stable, so a place to merge those seems to
be beneficial. I don't want a plethora of names as it makes harder for
people to contribute and share work so I propose two solutions:
linux-fslc_4.0.bb
linux-fslc-mx6_3.14-1.0.x.bb
or
linux-fslc_4.0.bb
linux-fslc_3.14-1.0.x-mx6.bb
Both works.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe
2015-06-18 13:58 ` Otavio Salvador
@ 2015-06-18 15:32 ` Nikolay Dimitrov
2015-06-18 16:21 ` Otavio Salvador
2015-06-18 16:47 ` Ann Thornton
2015-06-18 17:10 ` Nikolay Dimitrov
1 sibling, 2 replies; 23+ messages in thread
From: Nikolay Dimitrov @ 2015-06-18 15:32 UTC (permalink / raw)
To: Otavio Salvador, Daiane Angolini; +Cc: meta-freescale Mailing List
Hi Daiane, Otavio,
On 06/18/2015 04:58 PM, Otavio Salvador wrote:
> On Thu, Jun 18, 2015 at 10:40 AM, Daiane Angolini
> <daiane.list@gmail.com> wrote:
>> On Wed, Jun 17, 2015 at 4:45 PM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
>>> On Wed, Jun 17, 2015 at 4:25 PM, Nikolay Dimitrov
>>> <picmaster@mail.bg> wrote:
>>>> So, in terms of functionality this kernel sits somewhere
>>>> between mainline and FSL releases, is that correct?
>>>
>>> Yes; it is FSL release + stable releases + vendor/community
>>> fixes
>>
>> I've been thinking about this issue. And this provider (for imx6
>> only) may make sense to have "fslc" sufix, exactly because it has
>> freescale + community patches
>>
>> However, the other (currently linux-fslc) does not make sense.
>> Maybe linux-cmt makes more sense today.
>>
>> I remember one of the arguments to not use only "linux" and use a
>> prefix was that it's not a pure mainline provider (it clones from
>> github) and because it leave the "linux" only for internal kernels
>>
>> Any other suggestion?
>
> I think we need to consider some things here:
>
> linux-fslc is a kernel tree we maintain u-boot-fslc is a u-boot tree
> we maintain
>
> both have same goals and the idea is to provide a place to share
> patches and backports.
>
> The motivation to make the 3.14 is because FSL is not taking the
> fixes and security updates from stable, so a place to merge those
> seems to be beneficial. I don't want a plethora of names as it makes
> harder for people to contribute and share work so I propose two
> solutions:
>
> linux-fslc_4.0.bb linux-fslc-mx6_3.14-1.0.x.bb
>
> or
>
> linux-fslc_4.0.bb linux-fslc_3.14-1.0.x-mx6.bb
>
> Both works.
Thanks for sharing your ideas, this helps me to understand somewhat
better the motivation behind creating these linux kernel providers.
So, my comments are not to oppose any changes/improvements at all, but
just to add a more global perspective on where the Yocto kernel
providers fit in the long chain between mainline and the OEM:
1. linux-mainline
-----------------
Good generic imx6 support, no support for ASRC, VPU. Regarding the GPU -
Jon Nettleton is working on the etnaviv code, so probably some day we'll
have a fully open GPU support there. Until then - no GPU support in
mainline, only basic FB on hdmi/lvds (parallel lcd probably also works,
but I haven't tested it). Supported by the kernel developers.
2. linux-fslc
-------------
Almost mainline. Here we collect patches that either will take very long
to be applied in mainline, or are inappropriate for mainline (but still
useful for Yocto users). As stability and features should be as good
mainline, if not slightly better due to custom fixes for Yocto.
Supported by Yocto community.
3. linux-as-proposed-by-otavio
------------------------------
Man-in-the middle. Forward-ported FSL code, back-ported important
patches from mainline. Probably something like "linux-imx-next". Who
will support this code?
4. linux-imx
------------
THE FSL kernel. Freescale's team is doing a great job, and there are
more or less regular releases with good overall quality. It's quite
normal/expected that this kernel version will always lag behind
mainline. One thing which bothers me is that there's no way for the
community to interact with the FSL BSP team, which means no transparent
way to submit/track/resolve issues. This same role is currently being
played by the Yocto community due to several individuals who have
internal access to the FSL BSP team and can help pushing through issues.
Supported by Yocto community (including FSL engineers).
So, even if I like the idea that #3 will have newer code than #4, the
main question is who will support it (support means both development and
validation)?
Regards,
Nikolay
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe
2015-06-18 15:32 ` Nikolay Dimitrov
@ 2015-06-18 16:21 ` Otavio Salvador
2015-06-18 16:38 ` Nikolay Dimitrov
2015-06-18 16:47 ` Ann Thornton
1 sibling, 1 reply; 23+ messages in thread
From: Otavio Salvador @ 2015-06-18 16:21 UTC (permalink / raw)
To: Nikolay Dimitrov; +Cc: meta-freescale Mailing List
On Thu, Jun 18, 2015 at 12:32 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> On 06/18/2015 04:58 PM, Otavio Salvador wrote:
>>
>> On Thu, Jun 18, 2015 at 10:40 AM, Daiane Angolini
>> <daiane.list@gmail.com> wrote:
>>>
>>> On Wed, Jun 17, 2015 at 4:45 PM, Otavio Salvador
>>> <otavio@ossystems.com.br> wrote:
>>>>
>>>> On Wed, Jun 17, 2015 at 4:25 PM, Nikolay Dimitrov
>>>> <picmaster@mail.bg> wrote:
>>>>>
>>>>> So, in terms of functionality this kernel sits somewhere
>>>>> between mainline and FSL releases, is that correct?
>>>>
>>>>
>>>> Yes; it is FSL release + stable releases + vendor/community
>>>> fixes
>>>
>>>
>>> I've been thinking about this issue. And this provider (for imx6
>>> only) may make sense to have "fslc" sufix, exactly because it has
>>> freescale + community patches
>>>
>>> However, the other (currently linux-fslc) does not make sense.
>>> Maybe linux-cmt makes more sense today.
>>>
>>> I remember one of the arguments to not use only "linux" and use a
>>> prefix was that it's not a pure mainline provider (it clones from
>>> github) and because it leave the "linux" only for internal kernels
>>>
>>> Any other suggestion?
>>
>>
>> I think we need to consider some things here:
>>
>> linux-fslc is a kernel tree we maintain u-boot-fslc is a u-boot tree
>> we maintain
>>
>> both have same goals and the idea is to provide a place to share
>> patches and backports.
>>
>> The motivation to make the 3.14 is because FSL is not taking the
>> fixes and security updates from stable, so a place to merge those
>> seems to be beneficial. I don't want a plethora of names as it makes
>> harder for people to contribute and share work so I propose two
>> solutions:
>>
>> linux-fslc_4.0.bb linux-fslc-mx6_3.14-1.0.x.bb
>>
>> or
>>
>> linux-fslc_4.0.bb linux-fslc_3.14-1.0.x-mx6.bb
>>
>> Both works.
>
>
> Thanks for sharing your ideas, this helps me to understand somewhat
> better the motivation behind creating these linux kernel providers.
>
> So, my comments are not to oppose any changes/improvements at all, but
> just to add a more global perspective on where the Yocto kernel
> providers fit in the long chain between mainline and the OEM:
>
> 1. linux-mainline
> -----------------
> Good generic imx6 support, no support for ASRC, VPU. Regarding the GPU -
> Jon Nettleton is working on the etnaviv code, so probably some day we'll
> have a fully open GPU support there. Until then - no GPU support in
> mainline, only basic FB on hdmi/lvds (parallel lcd probably also works,
> but I haven't tested it). Supported by the kernel developers.
>
> 2. linux-fslc
> -------------
> Almost mainline. Here we collect patches that either will take very long
> to be applied in mainline, or are inappropriate for mainline (but still
> useful for Yocto users). As stability and features should be as good
> mainline, if not slightly better due to custom fixes for Yocto.
> Supported by Yocto community.
>
> 3. linux-as-proposed-by-otavio
> ------------------------------
> Man-in-the middle. Forward-ported FSL code, back-ported important
> patches from mainline. Probably something like "linux-imx-next". Who
> will support this code?
>
> 4. linux-imx
> ------------
> THE FSL kernel. Freescale's team is doing a great job, and there are
> more or less regular releases with good overall quality. It's quite
> normal/expected that this kernel version will always lag behind
> mainline. One thing which bothers me is that there's no way for the
> community to interact with the FSL BSP team, which means no transparent
> way to submit/track/resolve issues. This same role is currently being
> played by the Yocto community due to several individuals who have
> internal access to the FSL BSP team and can help pushing through issues.
> Supported by Yocto community (including FSL engineers).
>
>
> So, even if I like the idea that #3 will have newer code than #4, the
> main question is who will support it (support means both development and
> validation)?
#2 linux-fslc is a tree to host fslc modified kernels. It has no
compromise to be mainline only.
#3 allow us to share work among vendors and bring fixes while reusing
the work done by FSL BSP team, board vendors and community.
#4 has no support; as soon you port it to your board it is
non-supported kernel. As soon you move away of their BSP release it is
non-supported kernel and plus it does not have patches applied once
tagged (nor security or fixes) so any change needs to wait for next
GA.
To be honest, FSL does not apply fixes until next GA so there is no
way to improve their kernel, u-boot, whatever. We try to fill the gap
here and avoid work duplication.
The amount of duplicated work done by board vendors is insane, I am
trying to improve it as much as I can.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe
2015-06-18 16:21 ` Otavio Salvador
@ 2015-06-18 16:38 ` Nikolay Dimitrov
2015-06-18 16:47 ` Otavio Salvador
0 siblings, 1 reply; 23+ messages in thread
From: Nikolay Dimitrov @ 2015-06-18 16:38 UTC (permalink / raw)
To: Otavio Salvador; +Cc: meta-freescale Mailing List
Hi Otavio,
On 06/18/2015 07:21 PM, Otavio Salvador wrote:
> On Thu, Jun 18, 2015 at 12:32 PM, Nikolay Dimitrov
> <picmaster@mail.bg> wrote:
>> On 06/18/2015 04:58 PM, Otavio Salvador wrote:
>>>
>>> On Thu, Jun 18, 2015 at 10:40 AM, Daiane Angolini
>>> <daiane.list@gmail.com> wrote:
>>>>
>>>> On Wed, Jun 17, 2015 at 4:45 PM, Otavio Salvador
>>>> <otavio@ossystems.com.br> wrote:
>>>>>
>>>>> On Wed, Jun 17, 2015 at 4:25 PM, Nikolay Dimitrov
>>>>> <picmaster@mail.bg> wrote:
>>>>>>
>>>>>> So, in terms of functionality this kernel sits somewhere
>>>>>> between mainline and FSL releases, is that correct?
>>>>>
>>>>>
>>>>> Yes; it is FSL release + stable releases + vendor/community
>>>>> fixes
>>>>
>>>>
>>>> I've been thinking about this issue. And this provider (for
>>>> imx6 only) may make sense to have "fslc" sufix, exactly
>>>> because it has freescale + community patches
>>>>
>>>> However, the other (currently linux-fslc) does not make sense.
>>>> Maybe linux-cmt makes more sense today.
>>>>
>>>> I remember one of the arguments to not use only "linux" and
>>>> use a prefix was that it's not a pure mainline provider (it
>>>> clones from github) and because it leave the "linux" only for
>>>> internal kernels
>>>>
>>>> Any other suggestion?
>>>
>>>
>>> I think we need to consider some things here:
>>>
>>> linux-fslc is a kernel tree we maintain u-boot-fslc is a u-boot
>>> tree we maintain
>>>
>>> both have same goals and the idea is to provide a place to share
>>> patches and backports.
>>>
>>> The motivation to make the 3.14 is because FSL is not taking the
>>> fixes and security updates from stable, so a place to merge
>>> those seems to be beneficial. I don't want a plethora of names
>>> as it makes harder for people to contribute and share work so I
>>> propose two solutions:
>>>
>>> linux-fslc_4.0.bb linux-fslc-mx6_3.14-1.0.x.bb
>>>
>>> or
>>>
>>> linux-fslc_4.0.bb linux-fslc_3.14-1.0.x-mx6.bb
>>>
>>> Both works.
>>
>>
>> Thanks for sharing your ideas, this helps me to understand somewhat
>> better the motivation behind creating these linux kernel
>> providers.
>>
>> So, my comments are not to oppose any changes/improvements at all,
>> but just to add a more global perspective on where the Yocto kernel
>> providers fit in the long chain between mainline and the OEM:
>>
>> 1. linux-mainline ----------------- Good generic imx6 support, no
>> support for ASRC, VPU. Regarding the GPU - Jon Nettleton is
>> working on the etnaviv code, so probably some day we'll have a
>> fully open GPU support there. Until then - no GPU support in
>> mainline, only basic FB on hdmi/lvds (parallel lcd probably also
>> works, but I haven't tested it). Supported by the kernel
>> developers.
>>
>> 2. linux-fslc ------------- Almost mainline. Here we collect
>> patches that either will take very long to be applied in mainline,
>> or are inappropriate for mainline (but still useful for Yocto
>> users). As stability and features should be as good mainline, if
>> not slightly better due to custom fixes for Yocto. Supported by
>> Yocto community.
>>
>> 3. linux-as-proposed-by-otavio ------------------------------
>> Man-in-the middle. Forward-ported FSL code, back-ported important
>> patches from mainline. Probably something like "linux-imx-next".
>> Who will support this code?
>>
>> 4. linux-imx ------------ THE FSL kernel. Freescale's team is
>> doing a great job, and there are more or less regular releases with
>> good overall quality. It's quite normal/expected that this kernel
>> version will always lag behind mainline. One thing which bothers
>> me is that there's no way for the community to interact with the
>> FSL BSP team, which means no transparent way to
>> submit/track/resolve issues. This same role is currently being
>> played by the Yocto community due to several individuals who have
>> internal access to the FSL BSP team and can help pushing through
>> issues. Supported by Yocto community (including FSL engineers).
>>
>>
>> So, even if I like the idea that #3 will have newer code than #4,
>> the main question is who will support it (support means both
>> development and validation)?
>
> #2 linux-fslc is a tree to host fslc modified kernels. It has no
> compromise to be mainline only.
>
> #3 allow us to share work among vendors and bring fixes while reusing
> the work done by FSL BSP team, board vendors and community.
>
> #4 has no support; as soon you port it to your board it is
> non-supported kernel. As soon you move away of their BSP release it
> is non-supported kernel and plus it does not have patches applied
> once tagged (nor security or fixes) so any change needs to wait for
> next GA.
>
> To be honest, FSL does not apply fixes until next GA so there is no
> way to improve their kernel, u-boot, whatever. We try to fill the gap
> here and avoid work duplication.
>
> The amount of duplicated work done by board vendors is insane, I am
> trying to improve it as much as I can.
I see, and fully agree with the explanations. My current understanding
(could be wrong) is that the current FSL drivers in 3.14.28 are not
possible to be rebased to newer mainline kernels, is that correct?
That's why I commented about the possible confusion, as for me it's good
to see in the kernel name whether it has or has not support for the SoC
bells/whistles (-mainline/-fslc vs -imx).
If my assumption is wrong and these drivers *can* be rebased while
retaining compatibility with the binary blobs, than probably #2 and #3
start to look like something that can be merged (what Daiane said also).
Regards,
Nikolay
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe
2015-06-18 15:32 ` Nikolay Dimitrov
2015-06-18 16:21 ` Otavio Salvador
@ 2015-06-18 16:47 ` Ann Thornton
1 sibling, 0 replies; 23+ messages in thread
From: Ann Thornton @ 2015-06-18 16:47 UTC (permalink / raw)
To: meta-freescale
[-- Attachment #1: Type: text/plain, Size: 4292 bytes --]
Thanks for the kind words, Nikolay. We are trying to respond more quickly.
Ann Thornton
On 6/18/2015 10:32 AM, Nikolay Dimitrov wrote:
> Hi Daiane, Otavio,
>
> On 06/18/2015 04:58 PM, Otavio Salvador wrote:
>> On Thu, Jun 18, 2015 at 10:40 AM, Daiane Angolini
>> <daiane.list@gmail.com> wrote:
>>> On Wed, Jun 17, 2015 at 4:45 PM, Otavio Salvador
>>> <otavio@ossystems.com.br> wrote:
>>>> On Wed, Jun 17, 2015 at 4:25 PM, Nikolay Dimitrov
>>>> <picmaster@mail.bg> wrote:
>>>>> So, in terms of functionality this kernel sits somewhere
>>>>> between mainline and FSL releases, is that correct?
>>>>
>>>> Yes; it is FSL release + stable releases + vendor/community
>>>> fixes
>>>
>>> I've been thinking about this issue. And this provider (for imx6
>>> only) may make sense to have "fslc" sufix, exactly because it has
>>> freescale + community patches
>>>
>>> However, the other (currently linux-fslc) does not make sense.
>>> Maybe linux-cmt makes more sense today.
>>>
>>> I remember one of the arguments to not use only "linux" and use a
>>> prefix was that it's not a pure mainline provider (it clones from
>>> github) and because it leave the "linux" only for internal kernels
>>>
>>> Any other suggestion?
>>
>> I think we need to consider some things here:
>>
>> linux-fslc is a kernel tree we maintain u-boot-fslc is a u-boot tree
>> we maintain
>>
>> both have same goals and the idea is to provide a place to share
>> patches and backports.
>>
>> The motivation to make the 3.14 is because FSL is not taking the
>> fixes and security updates from stable, so a place to merge those
>> seems to be beneficial. I don't want a plethora of names as it makes
>> harder for people to contribute and share work so I propose two
>> solutions:
>>
>> linux-fslc_4.0.bb linux-fslc-mx6_3.14-1.0.x.bb
>>
>> or
>>
>> linux-fslc_4.0.bb linux-fslc_3.14-1.0.x-mx6.bb
>>
>> Both works.
>
> Thanks for sharing your ideas, this helps me to understand somewhat
> better the motivation behind creating these linux kernel providers.
>
> So, my comments are not to oppose any changes/improvements at all, but
> just to add a more global perspective on where the Yocto kernel
> providers fit in the long chain between mainline and the OEM:
>
> 1. linux-mainline
> -----------------
> Good generic imx6 support, no support for ASRC, VPU. Regarding the GPU -
> Jon Nettleton is working on the etnaviv code, so probably some day we'll
> have a fully open GPU support there. Until then - no GPU support in
> mainline, only basic FB on hdmi/lvds (parallel lcd probably also works,
> but I haven't tested it). Supported by the kernel developers.
>
> 2. linux-fslc
> -------------
> Almost mainline. Here we collect patches that either will take very long
> to be applied in mainline, or are inappropriate for mainline (but still
> useful for Yocto users). As stability and features should be as good
> mainline, if not slightly better due to custom fixes for Yocto.
> Supported by Yocto community.
>
> 3. linux-as-proposed-by-otavio
> ------------------------------
> Man-in-the middle. Forward-ported FSL code, back-ported important
> patches from mainline. Probably something like "linux-imx-next". Who
> will support this code?
>
> 4. linux-imx
> ------------
> THE FSL kernel. Freescale's team is doing a great job, and there are
> more or less regular releases with good overall quality. It's quite
> normal/expected that this kernel version will always lag behind
> mainline. One thing which bothers me is that there's no way for the
> community to interact with the FSL BSP team, which means no transparent
> way to submit/track/resolve issues. This same role is currently being
> played by the Yocto community due to several individuals who have
> internal access to the FSL BSP team and can help pushing through issues.
> Supported by Yocto community (including FSL engineers).
>
>
> So, even if I like the idea that #3 will have newer code than #4, the
> main question is who will support it (support means both development and
> validation)?
>
> Regards,
> Nikolay
--
Ann Thornton
/Microcontrollers Software and Applications
Freescale Semiconductors
email: Ann.Thornton@freescale.com/
[-- Attachment #2: Type: text/html, Size: 7144 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe
2015-06-18 16:38 ` Nikolay Dimitrov
@ 2015-06-18 16:47 ` Otavio Salvador
0 siblings, 0 replies; 23+ messages in thread
From: Otavio Salvador @ 2015-06-18 16:47 UTC (permalink / raw)
To: Nikolay Dimitrov; +Cc: meta-freescale Mailing List
On Thu, Jun 18, 2015 at 1:38 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> On 06/18/2015 07:21 PM, Otavio Salvador wrote:
...
>> #2 linux-fslc is a tree to host fslc modified kernels. It has no
>> compromise to be mainline only.
>>
>> #3 allow us to share work among vendors and bring fixes while reusing
>> the work done by FSL BSP team, board vendors and community.
>>
>> #4 has no support; as soon you port it to your board it is
>> non-supported kernel. As soon you move away of their BSP release it
>> is non-supported kernel and plus it does not have patches applied
>> once tagged (nor security or fixes) so any change needs to wait for
>> next GA.
>>
>> To be honest, FSL does not apply fixes until next GA so there is no
>> way to improve their kernel, u-boot, whatever. We try to fill the gap
>> here and avoid work duplication.
>>
>> The amount of duplicated work done by board vendors is insane, I am
>> trying to improve it as much as I can.
>
>
> I see, and fully agree with the explanations. My current understanding
> (could be wrong) is that the current FSL drivers in 3.14.28 are not
> possible to be rebased to newer mainline kernels, is that correct?
Correct; some can be adapted to work on top of mainline kernel however
this is another derivative work.
> That's why I commented about the possible confusion, as for me it's good
> to see in the kernel name whether it has or has not support for the SoC
> bells/whistles (-mainline/-fslc vs -imx).
>
> If my assumption is wrong and these drivers *can* be rebased while
> retaining compatibility with the binary blobs, than probably #2 and #3
> start to look like something that can be merged (what Daiane said also).
Some features can be forward-ported but this is another possible fork
to be started, I won't commit to this myself at this moment.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe
2015-06-18 13:58 ` Otavio Salvador
2015-06-18 15:32 ` Nikolay Dimitrov
@ 2015-06-18 17:10 ` Nikolay Dimitrov
2015-06-18 17:40 ` Otavio Salvador
1 sibling, 1 reply; 23+ messages in thread
From: Nikolay Dimitrov @ 2015-06-18 17:10 UTC (permalink / raw)
To: Otavio Salvador, Daiane Angolini; +Cc: meta-freescale Mailing List
Hi Otavio,
On 06/18/2015 04:58 PM, Otavio Salvador wrote:
[snip]
>
> linux-fslc_4.0.bb linux-fslc-mx6_3.14-1.0.x.bb
>
> or
>
> linux-fslc_4.0.bb linux-fslc_3.14-1.0.x-mx6.bb
Understood. Then here's my proposal, which I hope aligns with what you
already outlined:
1. Drop SOC name from the provider name
...in order to have more SOCs benefit from the same efforts. First,
patches in non-soc-specific common areas can be reused as-is (ext4
patches anyone :D?), and second, it would be great to have 1 repository
where all these efforts are concentrated, not separate for each separate
SoC (also, there are drivers for IP-blocks which are reused 1:1 across
SoCs).
2. Make sure the provider name doesn't contain a delimited string of
"fsl", "imx" or "mx"
... to make sure the provider is not confused with the FSL provider, and
to give due credit to the upstream + community efforts.
3. Drop the GA release version from the provider name
...for several reasons:
- it will limit the ability to merge patches from different GA releases
(if/when such need arises)
- to not confuse it with FSL GA releases
- sooner or later due to upstream patches merged this code will be
further and further away from the FSL release point.
So I think that a provider name like...
linux-fslc_3.14.28
linux-fslc_3.17.4
linux-fslc_4.0
...seems practical.
(I can only make the educated guess that "fslc" = "Freescale community",
but "fsl-community" really seems quite long).
Regards,
Nikolay
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe
2015-06-18 17:10 ` Nikolay Dimitrov
@ 2015-06-18 17:40 ` Otavio Salvador
0 siblings, 0 replies; 23+ messages in thread
From: Otavio Salvador @ 2015-06-18 17:40 UTC (permalink / raw)
To: Nikolay Dimitrov; +Cc: meta-freescale Mailing List
On Thu, Jun 18, 2015 at 2:10 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> On 06/18/2015 04:58 PM, Otavio Salvador wrote:
>> linux-fslc_4.0.bb linux-fslc-mx6_3.14-1.0.x.bb
>>
>> or
>>
>> linux-fslc_4.0.bb linux-fslc_3.14-1.0.x-mx6.bb
>
>
> Understood. Then here's my proposal, which I hope aligns with what you
> already outlined:
>
> 1. Drop SOC name from the provider name
> ...in order to have more SOCs benefit from the same efforts. First,
> patches in non-soc-specific common areas can be reused as-is (ext4
> patches anyone :D?), and second, it would be great to have 1 repository
> where all these efforts are concentrated, not separate for each separate
> SoC (also, there are drivers for IP-blocks which are reused 1:1 across
> SoCs).
>
> 2. Make sure the provider name doesn't contain a delimited string of
> "fsl", "imx" or "mx"
> ... to make sure the provider is not confused with the FSL provider, and
> to give due credit to the upstream + community efforts.
>
> 3. Drop the GA release version from the provider name
> ...for several reasons:
> - it will limit the ability to merge patches from different GA releases
> (if/when such need arises)
> - to not confuse it with FSL GA releases
> - sooner or later due to upstream patches merged this code will be
> further and further away from the FSL release point.
>
> So I think that a provider name like...
>
> linux-fslc_3.14.28
> linux-fslc_3.17.4
> linux-fslc_4.0
>
> ...seems practical.
>
> (I can only make the educated guess that "fslc" = "Freescale community", but
> "fsl-community" really seems quite long).
Yes, "fslc" stands for FSL Community.
There are reasons behind the use of another provider, the main ones are:
- avoid use of version pinning (PREFERRED_VERSION_...);
- make the SoC it targets explicit;
The 3.14.28-1.0.0-GA has only been tested on the *boards* listed in
the release notes. If you take this and use it in another board, this
is not supported by Freescale.
In case you take the 3.14.28-1.0.0-GA kernel and use it in another
SoC, it is at your risk. Freescale does not test the code changes on
the other SoCs so even if some IP components are shared they were not
tested and even checked when the changes in the drivers and
architecture code were done.
In summary the linux-fslc-mx6 is now a 3.14.44 kernel which merges
3.14.28-1.0.0-GA and should ONLY be used for i.MX6 SoCs. There is no
test or check of this tree for another SoCs.
The shared tree for all SoCs are the ones we maintain based on
mainline (4.0, 4.1...) and this can be expected to work on all SoCs.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2015-06-18 17:40 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-17 18:02 [meta-fsl-arm][PATCH 1/4] core-image-weston: Fail gracefully if using incompatible DISTRO_FEATURES Otavio Salvador
2015-06-17 18:02 ` [meta-fsl-arm][PATCH 2/4] fsl-default-providers.inc: Move content to imx-base.inc and mxs-base.inc Otavio Salvador
2015-06-17 18:33 ` Nikolay Dimitrov
2015-06-17 18:38 ` Otavio Salvador
2015-06-17 19:27 ` Nikolay Dimitrov
2015-06-17 18:02 ` [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe Otavio Salvador
2015-06-17 18:28 ` Nikolay Dimitrov
2015-06-17 18:30 ` Otavio Salvador
2015-06-17 18:38 ` Nikolay Dimitrov
2015-06-17 18:39 ` Otavio Salvador
2015-06-17 19:25 ` Nikolay Dimitrov
2015-06-17 19:32 ` Daiane Angolini
2015-06-17 19:45 ` Otavio Salvador
2015-06-18 13:40 ` Daiane Angolini
2015-06-18 13:58 ` Otavio Salvador
2015-06-18 15:32 ` Nikolay Dimitrov
2015-06-18 16:21 ` Otavio Salvador
2015-06-18 16:38 ` Nikolay Dimitrov
2015-06-18 16:47 ` Otavio Salvador
2015-06-18 16:47 ` Ann Thornton
2015-06-18 17:10 ` Nikolay Dimitrov
2015-06-18 17:40 ` Otavio Salvador
2015-06-17 18:02 ` [meta-fsl-arm][PATCH 4/4] imx-base.inc: Use linux-fslc-mx6 for all i.MX6 by default Otavio Salvador
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.