platform: update galileo to 3.14 kernel
RFC PATCH 1/1 platform: update galileo to 3.14 kernel
Updating kernel for Galileo board BSP from 3.8 to 3.14
*Changed board defconfig to pull new 3.14 kernel *New kernel config file for 3.14 kernel *Changed defconfig to use new kernel config *Removed old 3.8 kernel config
--- board/intel/galileo/linux-3.14.config | 308 ++++++++++++++++++++++++++++++++++ board/intel/galileo/linux-3.8.config | 307 --------------------------------- configs/galileo_defconfig | 10 +- 3 files changed, 313 insertions(+), 312 deletions(-) create mode 100644 board/intel/galileo/linux-3.14.config delete mode 100644 board/intel/galileo/linux-3.8.config
board/intel/galileo/linux-3.14.config new file +308 -0
@@ -0,0 +1,308 @@ +# CONFIG_LOCALVERSION_AUTO is not set +# CONFIG_SWAP is not set +CONFIG_SYSVIPC=y +CONFIG_POSIX_MQUEUE=y +CONFIG_FHANDLE=y +CONFIG_KERNEL_LZMA=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_BSD_PROCESS_ACCT=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=18 +CONFIG_CGROUPS=y +CONFIG_CGROUP_FREEZER=y +CONFIG_CPUSETS=y +CONFIG_CGROUP_CPUACCT=y +CONFIG_RESOURCE_COUNTERS=y +CONFIG_CGROUP_SCHED=y +CONFIG_NAMESPACES=y +CONFIG_RELAY=y +CONFIG_BLK_DEV_INITRD=y +CONFIG_RD_BZIP2=y +CONFIG_RD_LZMA=y +CONFIG_SYSCTL_SYSCALL=y +# CONFIG_PCSPKR_PLATFORM is not set +CONFIG_EMBEDDED=y +# CONFIG_COMPAT_BRK is not set +CONFIG_JUMP_LABEL=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_LBDAF is not set +CONFIG_PARTITION_ADVANCED=y +CONFIG_BSD_DISKLABEL=y +# CONFIG_ZONE_DMA is not set +CONFIG_X86_INTEL_QUARK=y +CONFIG_M586TSC=y +CONFIG_X86_GENERIC=y +CONFIG_HPET_TIMER=y +CONFIG_PREEMPT_VOLUNTARY=y +CONFIG_X86_UP_IOAPIC=y +# CONFIG_X86_MCE_AMD is not set +# CONFIG_X86_16BIT is not set +CONFIG_X86_REBOOTFIXUPS=y +CONFIG_MICROCODE=y +CONFIG_X86_MSR=y +CONFIG_X86_CPUID=y +CONFIG_HIGHMEM64G=y +# CONFIG_COMPACTION is not set +# CONFIG_MTRR is not set +# CONFIG_ARCH_RANDOM is not set +CONFIG_EFI=y +CONFIG_EFI_STUB=y +CONFIG_EFI_CAPSULE=m +CONFIG_HZ_100=y +CONFIG_KEXEC=y +CONFIG_PHYSICAL_START=0x400000 +CONFIG_PHYSICAL_ALIGN=0x1000000 +# CONFIG_COMPAT_VDSO is not set +CONFIG_PM_RUNTIME=y +CONFIG_PM_DEBUG=y +CONFIG_PM_TRACE_RTC=y +CONFIG_ACPI_PROCFS=y +CONFIG_ACPI_PROCFS_POWER=y +CONFIG_ACPI_EC_DEBUGFS=y +# CONFIG_ACPI_BATTERY is not set +# CONFIG_ACPI_FAN is not set +CONFIG_ACPI_DEBUG=y +CONFIG_ACPI_PCI_SLOT=y +CONFIG_PCIEPORTBUS=y +CONFIG_PCI_MSI=y +CONFIG_PCI_DEBUG=y +CONFIG_PCI_IOAPIC=y +CONFIG_NET=y +CONFIG_PACKET=y +CONFIG_UNIX=y +CONFIG_INET=y +CONFIG_SYN_COOKIES=y +# CONFIG_IPV6_SIT is not set +CONFIG_IPV6_MULTIPLE_TABLES=y +CONFIG_IPV6_SUBTREES=y +CONFIG_VLAN_8021Q=m +CONFIG_VLAN_8021Q_GVRP=y +CONFIG_CAN=m +# CONFIG_CAN_GW is not set +CONFIG_CAN_J1939=m +CONFIG_CAN_VCAN=m +CONFIG_CAN_SLCAN=m +# CONFIG_CAN_DEV is not set +CONFIG_BT=m +CONFIG_BT_RFCOMM=m +CONFIG_BT_RFCOMM_TTY=y +CONFIG_BT_BNEP=m +CONFIG_BT_BNEP_MC_FILTER=y +CONFIG_BT_BNEP_PROTO_FILTER=y +CONFIG_BT_HIDP=m +CONFIG_BT_HCIBTUSB=m +CONFIG_CFG80211=m +CONFIG_CFG80211_WEXT=y +CONFIG_MAC80211=m +CONFIG_MAC80211_LEDS=y +CONFIG_RFKILL=m +CONFIG_RFKILL_INPUT=y +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +# CONFIG_FW_LOADER_USER_HELPER is not set +CONFIG_DEBUG_DEVRES=y +CONFIG_MTD=y +CONFIG_MTD_BLOCK=m +# CONFIG_PNP_DEBUG_MESSAGES is not set +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_LOOP_MIN_COUNT=2 +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_COUNT=1 +CONFIG_BLK_DEV_RAM_SIZE=81920 +CONFIG_EEPROM_AT24=m +CONFIG_EEPROM_93CX6=m +CONFIG_SCSI=y +CONFIG_BLK_DEV_SD=y +CONFIG_CHR_DEV_SG=y +CONFIG_SCSI_CONSTANTS=y +CONFIG_SCSI_SPI_ATTRS=y +# CONFIG_SCSI_LOWLEVEL is not set +CONFIG_NETDEVICES=y +CONFIG_TUN=y +# CONFIG_NET_VENDOR_3COM is not set +# CONFIG_NET_VENDOR_ADAPTEC is not set +# CONFIG_NET_VENDOR_ALTEON is not set +# CONFIG_NET_VENDOR_AMD is not set +# CONFIG_NET_VENDOR_ARC is not set +# CONFIG_NET_VENDOR_ATHEROS is not set +# CONFIG_NET_VENDOR_BROADCOM is not set +# CONFIG_NET_VENDOR_BROCADE is not set +# CONFIG_NET_VENDOR_CHELSIO is not set +# CONFIG_NET_VENDOR_CISCO is not set +# CONFIG_NET_VENDOR_DEC is not set +# CONFIG_NET_VENDOR_DLINK is not set +# CONFIG_NET_VENDOR_EMULEX is not set +# CONFIG_NET_VENDOR_EXAR is not set +# CONFIG_NET_VENDOR_HP is not set +# CONFIG_NET_VENDOR_I825XX is not set +# CONFIG_NET_VENDOR_MARVELL is not set +# CONFIG_NET_VENDOR_MELLANOX is not set +# CONFIG_NET_VENDOR_MICREL is not set +# CONFIG_NET_VENDOR_MICROCHIP is not set +# CONFIG_NET_VENDOR_MYRI is not set +# CONFIG_NET_VENDOR_NATSEMI is not set +# CONFIG_NET_VENDOR_NVIDIA is not set +# CONFIG_NET_VENDOR_OKI is not set +# CONFIG_NET_PACKET_ENGINE is not set +# CONFIG_NET_VENDOR_QLOGIC is not set +# CONFIG_NET_VENDOR_REALTEK is not set +# CONFIG_NET_VENDOR_RDC is not set +# CONFIG_NET_VENDOR_SEEQ is not set +# CONFIG_NET_VENDOR_SILAN is not set +# CONFIG_NET_VENDOR_SIS is not set +# CONFIG_NET_VENDOR_SMSC is not set +CONFIG_STMMAC_ETH=m +# CONFIG_STMMAC_PLATFORM is not set +CONFIG_STMMAC_PCI=m +# CONFIG_NET_VENDOR_SUN is not set +# CONFIG_NET_VENDOR_TEHUTI is not set +# CONFIG_NET_VENDOR_TI is not set +# CONFIG_NET_VENDOR_VIA is not set +# CONFIG_NET_VENDOR_WIZNET is not set +CONFIG_PHYLIB=y +CONFIG_PPP=m +CONFIG_PPP_DEFLATE=m +CONFIG_PPP_ASYNC=m +# CONFIG_RTL_CARDS is not set +# CONFIG_INPUT_MOUSEDEV is not set +CONFIG_INPUT_EVDEV=m +# CONFIG_INPUT_KEYBOARD is not set +# CONFIG_INPUT_MOUSE is not set +# CONFIG_SERIO is not set +CONFIG_VT_HW_CONSOLE_BINDING=y +CONFIG_LEGACY_PTY_COUNT=32 +CONFIG_SERIAL_NONSTANDARD=y +CONFIG_SERIAL_8250=y +# CONFIG_SERIAL_8250_PNP is not set +CONFIG_SERIAL_8250_CONSOLE=y +# CONFIG_SERIAL_8250_PCI is not set +CONFIG_SERIAL_8250_NR_UARTS=8 +CONFIG_SERIAL_8250_RUNTIME_UARTS=2 +CONFIG_SERIAL_8250_EXTENDED=y +CONFIG_SERIAL_8250_MANY_PORTS=y +CONFIG_SERIAL_8250_SHARE_IRQ=y +CONFIG_SERIAL_8250_DETECT_IRQ=y +CONFIG_SERIAL_8250_RSA=y +CONFIG_SERIAL_8250_DW=y +CONFIG_SERIAL_SC16IS7XX=m +CONFIG_SERIAL_SC16IS7XX_SPI=m +# CONFIG_HW_RANDOM is not set +CONFIG_HPET=y +# CONFIG_HPET_MMAP is not set +CONFIG_I2C=y +CONFIG_SPI_DEBUG=y +CONFIG_SPI_GPIO=y +CONFIG_SPI_PXA2XX=y +CONFIG_PTP_1588_CLOCK=y +CONFIG_GPIO_SCH=y +CONFIG_GPIO_PCA953X=y +CONFIG_GPIO_PCA953X_IRQ=y +CONFIG_GPIO_PCF857X=y +CONFIG_HWMON=m +CONFIG_SENSORS_LM75=m +# CONFIG_X86_PKG_TEMP_THERMAL is not set +CONFIG_MFD_INTEL_QUARK_HSUART_DMA=y +CONFIG_CY8C9540A=m +CONFIG_MFD_PCA9685=m +CONFIG_INTEL_QRK_GIP=m +CONFIG_INTEL_QRK_GIP_TEST=m +CONFIG_MEDIA_SUPPORT=m +CONFIG_MEDIA_CAMERA_SUPPORT=y +CONFIG_MEDIA_USB_SUPPORT=y +CONFIG_USB_VIDEO_CLASS=m +# CONFIG_USB_GSPCA is not set +# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set +# CONFIG_VGA_ARB is not set +# CONFIG_VGA_CONSOLE is not set +CONFIG_SOUND=m +CONFIG_SND=m +CONFIG_SND_USB_AUDIO=m +CONFIG_USB=m +# CONFIG_USB_DEFAULT_PERSIST is not set +CONFIG_USB_EHCI_HCD=m +CONFIG_USB_OHCI_HCD=m +CONFIG_USB_UHCI_HCD=m +CONFIG_USB_ACM=m +CONFIG_USB_STORAGE=m +CONFIG_USB_SERIAL=m +CONFIG_USB_SERIAL_GENERIC=y +CONFIG_USB_SERIAL_PL2303=m +CONFIG_USB_GADGET=m +CONFIG_USB_EG20T=m +CONFIG_USB_ZERO=m +CONFIG_USB_ETH=m +CONFIG_USB_MASS_STORAGE=m +CONFIG_USB_G_SERIAL=y +CONFIG_USB_G_ACM_MS=m +CONFIG_MMC=y +CONFIG_MMC_UNSAFE_RESUME=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_PCI=y +CONFIG_MMC_SDHCI_PLTFM=y +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=m +CONFIG_RTC_CLASS=y +# CONFIG_RTC_SYSTOHC is not set +CONFIG_DMADEVICES=y +CONFIG_DW_DMAC=y +CONFIG_UIO=y +CONFIG_STAGING=y +CONFIG_INTEL_QRK_THERMAL=y +CONFIG_INTEL_QRK_AUDIO_CTRL=m +CONFIG_INTEL_QRK_J1708=m +CONFIG_INTEL_QRK_ESRAM=y +# CONFIG_IOMMU_SUPPORT is not set +CONFIG_IIO=y +CONFIG_IIO_BUFFER_CB=y +CONFIG_IIO_LIS331DLH_INTEL_QRK=y +CONFIG_IIO_ST_ACCEL_3AXIS=y +CONFIG_AD7298=m +CONFIG_ADC1x8S102=m +CONFIG_IIO_SYSFS_TRIGGER=m +CONFIG_IIO_HRTIMER_TRIGGER=m +CONFIG_PWM=y +CONFIG_DMI_SYSFS=y +CONFIG_EFI_VARS=m +# CONFIG_EFI_RUNTIME_MAP is not set +CONFIG_EXT2_FS=y +CONFIG_EXT3_FS=y +# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set +CONFIG_EXT3_FS_POSIX_ACL=y +CONFIG_EXT3_FS_SECURITY=y +CONFIG_EXT4_FS=y +CONFIG_VFAT_FS=y +CONFIG_PROC_KCORE=y +CONFIG_TMPFS=y +CONFIG_TMPFS_POSIX_ACL=y +CONFIG_HUGETLBFS=y +# CONFIG_MISC_FILESYSTEMS is not set +CONFIG_NLS_DEFAULT="utf8" +CONFIG_NLS_CODEPAGE_437=y +CONFIG_NLS_CODEPAGE_850=y +CONFIG_NLS_ASCII=y +CONFIG_NLS_ISO8859_1=y +CONFIG_PRINTK_TIME=y +# CONFIG_ENABLE_WARN_DEPRECATED is not set +CONFIG_FRAME_WARN=2048 +# CONFIG_UNUSED_SYMBOLS is not set +CONFIG_HEADERS_CHECK=y +CONFIG_MAGIC_SYSRQ=y +CONFIG_DEBUG_MEMORY_INIT=y +CONFIG_DEBUG_STACKOVERFLOW=y +CONFIG_TIMER_STATS=y +CONFIG_LATENCYTOP=y +# CONFIG_FTRACE is not set +CONFIG_X86_PTDUMP=y +# CONFIG_DEBUG_RODATA_TEST is not set +CONFIG_DEBUG_SET_MODULE_RONX=y +# CONFIG_DOUBLEFAULT is not set +CONFIG_OPTIMIZE_INLINING=y +CONFIG_KEYS=y +CONFIG_KEYS_DEBUG_PROC_KEYS=y +CONFIG_SECURITY=y +CONFIG_SECURITY_NETWORK=y +# CONFIG_VIRTUALIZATION is not set +CONFIG_CRC_T10DIF=y
board/intel/galileo/linux-3.8.config deleted +0 -307
307 lines not on this page · raw message
configs/galileo_defconfig +5 -5
@@ -1,6 +1,6 @@ BR2_x86_x1000=y -# Linux headers same as kernel, a 3.8 series -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_8=y +# Linux headers same as kernel, a 3.14 series +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14=y # Binutils 2.25 is required as this enables stripping the LOCK prefix BR2_BINUTILS_VERSION_2_25_X=y BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV=y
@@ -11,10 +11,10 @@ BR2_ROOTFS_POST_BUILD_SCRIPT="board/intel/galileo/post-build.sh" BR2_ROOTFS_POST_IMAGE_SCRIPT="board/intel/galileo/post-image.sh" BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y -BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/mdr78/Linux-x1000.git" -BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="d1a51d55dc67022be6c2d15163ce6dd28540042f" +BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/padraigconnolly/Linux-x1000.git" +BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="ceeb288e39a4ba10643dec9ffb91baabf313f7d1" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y -BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/intel/galileo/linux-3.8.config" +BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/intel/galileo/linux-3.14.config" BR2_LINUX_KERNEL_INSTALL_TARGET=y BR2_TARGET_ROOTFS_EXT2=y BR2_TARGET_ROOTFS_EXT2_4=y
Signature · 1 line
2.5.5
RFC PATCH 1/1 platform: update galileo to 3.14 kernel
Quoted 5 lines · Padraig James Connolly
Updating kernel for Galileo board BSP from 3.8 to 3.14 ?*Changed board defconfig to pull new 3.14 kernel ?*New kernel config file for 3.14 kernel ?*Changed defconfig to use new kernel config ?*Removed old 3.8 kernel config
What is not working with the upstream kernel?
Btw, we are preparing some common infrastructure for Intel boards for Buildroot (*), it would be nice to re-integrate Galileo there as well.
(*) Will be published at some point later when we have done some testing, though seems you are working for Intel, so, we can show you this earlier.
Quoted 7 lines
?Signed-off-by: Padraig Connolly <[email protected]>
---
?board/intel/galileo/linux-3.14.config | 308
++++++++++++++++++++++++++++++++++
?board/intel/galileo/linux-3.8.config??| 307 -----------------------
----------
Signature · 2 lines
Andy Shevchenko <[email protected]> Intel Finland Oy
RFC PATCH 1/1 platform: update galileo to 3.14 kernel
Quoted 8 lines · Andy Shevchenko
Quoted 6 lines · Padraig James Connolly
Updating kernel for Galileo board BSP from 3.8 to 3.14 ?*Changed board defconfig to pull new 3.14 kernel ?*New kernel config file for 3.14 kernel ?*Changed defconfig to use new kernel config ?*Removed old 3.8 kernel config
Quoted 17 lines
What is not working with the upstream kernel?
Btw, we are preparing some common infrastructure for Intel boards for Buildroot (*), it would be nice to re-integrate Galileo there as well.
(*) Will be published at some point later when we have done some testing, though seems you are working for Intel, so, we can show you this earlier.
Quoted 8 lines
?Signed-off-by: Padraig Connolly <[email protected]>
---
?board/intel/galileo/linux-3.14.config | 308
++++++++++++++++++++++++++++++++++
?board/intel/galileo/linux-3.8.config??| 307 -----------------------
----------
Btw, for patches like this don't forget to add -C -M to get only changes.
Signature · 2 lines
Andy Shevchenko <[email protected]> Intel Finland Oy
Connolly
RFC PATCH 1/1 platform: update galileo to 3.14 kernel
Hi Andy,
I will use that in future emails thanks for the heads up.
Everything is working with the upstream kernel, I am just keeping it up to date with the current Intel Galileo BSP kernel.
Yes I am currently working at Intel. If you need help with this infrastructure, I can assist with the integration process of the Galileo Board.
Thanks,
Padraig Connolly <[email protected]>
Intel Shannon IRE
Quoted 8 lines · Andy Shevchenko
Quoted 6 lines · Padraig James Connolly
Updating kernel for Galileo board BSP from 3.8 to 3.14 ?*Changed board defconfig to pull new 3.14 kernel ?*New kernel config file for 3.14 kernel ?*Changed defconfig to use new kernel config ?*Removed old 3.8 kernel config
Quoted 17 lines
What is not working with the upstream kernel?
Btw, we are preparing some common infrastructure for Intel boards for Buildroot (*), it would be nice to re-integrate Galileo there as well.
(*) Will be published at some point later when we have done some testing, though seems you are working for Intel, so, we can show you this earlier.
Quoted 8 lines
?Signed-off-by: Padraig Connolly <[email protected]>
---
?board/intel/galileo/linux-3.14.config | 308
++++++++++++++++++++++++++++++++++
?board/intel/galileo/linux-3.8.config??| 307 -----------------------
----------
Btw, for patches like this don't forget to add -C -M to get only changes.
--
Andy Shevchenko <[email protected]> Intel Finland Oy
RFC PATCH 1/1 platform: update galileo to 3.14 kernel
In reply to Padraig James ConnollyHello,
Quoted 7 lines · Padraig James Connolly
Updating kernel for Galileo board BSP from 3.8 to 3.14
*Changed board defconfig to pull new 3.14 kernel *New kernel config file for 3.14 kernel *Changed defconfig to use new kernel config *Removed old 3.8 kernel configSigned-off-by Padraig Connolly <[email protected]>
Following the comments from Andy, I've marked this patch as Rejected. We indeed very much prefer defconfig that use the mainline kernel when possible.
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Connolly
RFC PATCH 1/1 platform: update galileo to 3.14 kernel
Hi Thomas,
Could you elaborate on this preference please, in the previous version for the Galileo the defconfig pulled the kernel in a similar way I have done. The future plan is once everything is approved, we will update R. Kinsella's repo with the 3.14 kernel and the defconfig will pull from there instead of mine as it did before. I'm only using my repo as a temp for working on.
Thanks,
Padraig Connolly
-----Original Message-----
From: buildroot [mailto:buildroot-bounces at busybox.net] On Behalf Of Thomas Petazzoni
Sent: Monday, August 22, 2016 3:34 PM
To: Connolly, Padraig <[email protected]>
Cc: buildroot at busybox.net; Andy Shevchenko <[email protected]>
Subject: Re: [Buildroot] [PATCH] [RFC] platform: update galileo to 3.14 kernel
Hello,
Quoted 6 lines · Padraig James Connolly
Updating kernel for Galileo board BSP from 3.8 to 3.14 *Changed board defconfig to pull new 3.14 kernel *New kernel config file for 3.14 kernel *Changed defconfig to use new kernel config *Removed old 3.8 kernel config
Signed-off-by Padraig Connolly <[email protected]>
Following the comments from Andy, I've marked this patch as Rejected. We indeed very much prefer defconfig that use the mainline kernel when possible.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
RFC PATCH 1/1 platform: update galileo to 3.14 kernel
Hello,
Quoted 6 lines · Padraig
Could you elaborate on this preference please, in the previous version for the Galileo the defconfig pulled the kernel in a similar way I have done. The future plan is once everything is approved, we will update R. Kinsella's repo with the 3.14 kernel and the defconfig will pull from there instead of mine as it did before. I'm only using my repo as a temp for working on.
It's pretty simple:
- If a platform has reasonable support in the mainline Linux kernel, then we prefer if our defconfigs use the mainline Linux kernel. By "reasonable" support, I mean support with sufficient features for the platform to actually be useful.
- If a platform doesn't have reasonable support in the mainline Linux kernel, then we accept defconfigs that use other Linux kernel trees (from vendors, or community maintained, etc.).
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Connolly
RFC PATCH 1/1 platform: update galileo to 3.14 kernel
Hi Thomas,
Currently there is support for the Quark X1000 SoC itself in the upstream Linux Kernel
but support for the Galileo Gen 1/2 is not fully upstream, there is a Galileo platform driver that is not upstream. There is also some fixes that affect the USB behavior that are not upstream either.
This means anything supported by the platform driver will not work with the upstream kernel, for example GPIO, I2C, and SPI. USB device support is also less reliable without the fix.
You can find the platform driver in our GitHub repo here :
https://github.com/padraigconnolly/Linux-x1000/tree/master/drivers/platform/x86/intel-quark
Thanks,
Padraig Connolly
-----Original Message-----
Hello,
Quoted 6 lines · Padraig
Could you elaborate on this preference please, in the previous version for the Galileo the defconfig pulled the kernel in a similar way I have done. The future plan is once everything is approved, we will update R. Kinsella's repo with the 3.14 kernel and the defconfig will pull from there instead of mine as it did before. I'm only using my repo as a temp for working on.
It's pretty simple:
- If a platform has reasonable support in the mainline Linux kernel, then we prefer if our defconfigs use the mainline Linux kernel. By "reasonable" support, I mean support with sufficient features for the platform to actually be useful.
- If a platform doesn't have reasonable support in the mainline Linux kernel, then we accept defconfigs that use other Linux kernel trees (from vendors, or community maintained, etc.).
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Kinsella
RFC PATCH 1/1 platform: update galileo to 3.14 kernel
Specifically the use of the platform driver was a result of broken ACPI support on the Galileo platforms. The DSDT table doesn't accurately describe the platform devices on these platforms, breaking the GPIO etc.
Once the platform was in the wild with the DSDT broken table, the only way to be sure that any given platform would work correctly was to use the platform driver.
This coupled with the USB fixes which are also un-upstreamable are the reason for the patched out-of-tree kernel.
Ray K
Quoted 52 lines · Padraig
Hi Thomas,
Currently there is support for the Quark X1000 SoC itself in the upstream Linux Kernel
but support for the Galileo Gen 1/2 is not fully upstream, there is a Galileo platform driver that is not upstream. There is also some fixes that affect the USB behavior that are not upstream either.This means anything supported by the platform driver will not work with the upstream kernel, for example GPIO, I2C, and SPI. USB device support is also less reliable without the fix.
You can find the platform driver in our GitHub repo here :
https://github.com/padraigconnolly/Linux-x1000/tree/master/drivers/platform/x86/intel-quarkThanks,
Padraig Connolly-----Original Message-----
Hello,
Quoted 6 lines · Padraig
Could you elaborate on this preference please, in the previous version for the Galileo the defconfig pulled the kernel in a similar way I have done. The future plan is once everything is approved, we will update R. Kinsella's repo with the 3.14 kernel and the defconfig will pull from there instead of mine as it did before. I'm only using my repo as a temp for working on.
It's pretty simple:
- If a platform has reasonable support in the mainline Linux kernel, then we prefer if our defconfigs use the mainline Linux kernel. By "reasonable" support, I mean support with sufficient features for the platform to actually be useful.
- If a platform doesn't have reasonable support in the mainline Linux kernel, then we accept defconfigs that use other Linux kernel trees (from vendors, or community maintained, etc.).
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
RFC PATCH 1/1 platform: update galileo to 3.14 kernel
In reply to ConnollyHello,
Quoted 9 lines · Padraig
Currently there is support for the Quark X1000 SoC itself in the upstream Linux Kernel
but support for the Galileo Gen 1/2 is not fully upstream, there is a Galileo platform driver that is not upstream. There is also some fixes that affect the USB behavior that are not upstream either.This means anything supported by the platform driver will not work with the upstream kernel, for example GPIO, I2C, and SPI. USB device support is also less reliable without the fix.
You can find the platform driver in our GitHub repo here :
https://github.com/padraigconnolly/Linux-x1000/tree/master/drivers/platform/x86/intel-quark
Then, it's fine to use a non-upstream kernel for this platform. Just update the existing galileo_defconfig.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Connolly
RFC PATCH 1/1 platform: update galileo to 3.14 kernel
Hi Thomas,
That's perfect, I will do that. I will also have to update the .config file as some of the configuration names have changed with the new 3.14 kernel.
Can you update the status of this patch or will I
submit a new one?
Thanks,
Padraig Connolly
-----Original Message-----
Hello,
Quoted 9 lines · Padraig
Currently there is support for the Quark X1000 SoC itself in the upstream Linux Kernel
but support for the Galileo Gen 1/2 is not fully upstream, there is a Galileo platform driver that is not upstream. There is also some fixes that affect the USB behavior that are not upstream either.This means anything supported by the platform driver will not work with the upstream kernel, for example GPIO, I2C, and SPI. USB device support is also less reliable without the fix.
You can find the platform driver in our GitHub repo here :
https://github.com/padraigconnolly/Linux-x1000/tree/master/drivers/platform/x86/intel-quark
Then, it's fine to use a non-upstream kernel for this platform. Just update the existing galileo_defconfig.
Best regards,
Thomas
Signature · 7 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
RFC PATCH 1/1 platform: update galileo to 3.14 kernel
In reply to ConnollyQuoted 9 lines · Padraig
Hi Thomas,
Currently there is support for the Quark X1000 SoC itself in the upstream Linux Kernel?
but support for the Galileo Gen 1/2 is not fully upstream, there is a Galileo platform driver that is not upstream.
There is also some fixes that affect the USB behavior that are not upstream either.
Quoted 3 lines
This means anything supported by the platform driver will not work with the upstream kernel,?
for example GPIO, I2C, and SPI.?
What is the "Galileo platform driver"? I'm pretty sure everything listed above is working in upstream and you are actually talking about _external_ (to Quark SoC) pinctrl driver which is indeed absent as any means of pinmuxing run-time in upstream.
I have no idea if it goes to category "reasonable support", though mention issue is applied to all similar boards (UP, Edison/Arduino, ...).
Comments below are not exactly related to Buildroot.
Quoted 1 line
?USB device support is also less reliable without the fix.
Is the fix going to be upstreamed?
Quoted 4 lines
You can find the platform driver in our GitHub repo here :?
https://github.com/padraigconnolly/Linux-
x1000/tree/master/drivers/platform/x86/intel-quark
Looking into this I can say the driver is not for upstream. The upstream drivers should utilize ACPI as much as possible, besides that fact I mentioned about pinctrl.
Quoted 5 lines · Ray
Specifically the use of the platform driver was a result of broken ACPI?
support on the Galileo platforms. The DSDT table doesn't accurately? describe the platform devices on these platforms, breaking the GPIO etc.
I do understand that.
Quoted 6 lines
?
Once the platform was in the wild with the DSDT broken table, the only?
way to be sure that any given platform would work correctly was to use?
the platform driver.
Nope. There are two mechanisms now to override and upgrade the ACPI table(s). Somewhere (Ostro?) I saw a direction to a right way.
Quoted 32 lines
Thanks,
Padraig Connolly-----Original Message-----
Hello,
Quoted 10 lines · Padraig
Could you elaborate on this preference please, in the previous version?
for the Galileo the defconfig pulled the kernel in a similar way I? have done.??The future plan is once everything is approved, we will? update R. Kinsella's repo with the 3.14 kernel and the defconfig will?
pull from there instead of mine as it did before.??I'm only using my?
repo as a temp for working on.It's pretty simple:
?- If a platform has reasonable support in the mainline Linux kernel, ???then we prefer if our defconfigs use the mainline Linux kernel. By ???"reasonable" support, I mean support with sufficient features for ???the platform to actually be useful.
?- If a platform doesn't have reasonable support in the mainline Linux ???kernel, then we accept defconfigs that use other Linux kernel trees ???(from vendors, or community maintained, etc.).
Signature · 2 lines
Andy Shevchenko <[email protected]> Intel Finland Oy
Kinsella
RFC PATCH 1/1 platform: update galileo to 3.14 kernel
Hi Andy,
Quoted 2 lines
What is the "Galileo platform driver"?
It is an out-of-tree driver for the Galileo platform.
Quoted 4 lines
I'm pretty sure everything listed
above is working in upstream and you are actually talking about _external_ (to Quark SoC) pinctrl driver which is indeed absent as any means of pinmuxing run-time in upstream.
The Galileo platform driver reserves some of the pin's for muxing, loads the GPIO expander, I2C and SPI drivers. As you point out later in your email much the same as can be achieved with ACPI override.
Quoted 2 lines
I have no idea if it goes to category "reasonable support", though mention issue is applied to all similar boards (UP, Edison/Arduino, ...).
I am afraid I don't understand.
Quoted 6 lines
Comments below are not exactly related to Buildroot.
Quoted 1 line
USB device support is also less reliable without the fix.
Is the fix going to be upstreamed?
No - from memory there was really no acceptable way to fix this issue upstream - it was pretty nasty.
Quoted 10 lines
Quoted 6 lines
Once the platform was in the wild with the DSDT broken table, the only
way to be sure that any given platform would work correctly was to use
the platform driver.Nope. There are two mechanisms now to override and upgrade the ACPI table(s). Somewhere (Ostro?) I saw a direction to a right way.
Yup - I am familiar with this, I know the guys who did the work. Using the ACPI override is another way to go - I haven't validated that Kernel and I don't know if it includes the USB fixes ( and others ).
We have however gone to the effort of validating the Kernel referred to in Padraig's patch.
Thanks,
Ray K
RFC PATCH 1/1 platform: update galileo to 3.14 kernel
Quoted 6 lines · Ray
Hi Andy,
I have no idea if it goes to category "reasonable support", thoughQuoted 2 lines
mention issue is applied to all similar boards (UP, Edison/Arduino, ...).
I am afraid I don't understand.
I meant that all ACPI-enabled boards are starving of pin mapping representation and thus pin muxing capability. There is neither standard for that in ACPI, nor possibility to do pin muxing from user space at run time.
I'm okay if you go for now with custom kernel, I hope situation will be changed somehow towards using upstream kernels.
Signature · 2 lines
Andy Shevchenko <[email protected]> Intel Finland Oy