* smarc-samx6i board support
@ 2014-12-08 13:00 Nikita Yushchenko
2014-12-08 13:33 ` Otavio Salvador
0 siblings, 1 reply; 4+ messages in thread
From: Nikita Yushchenko @ 2014-12-08 13:00 UTC (permalink / raw)
To: meta-freescale; +Cc: Gennady Kuznetsov
[-- Attachment #1: Type: text/plain, Size: 5290 bytes --]
Hi
Recently I was working on BSP for Kontron SMARC-sAMX6i board
(http://www.kontron.com/products/computeronmodules/smarc/smarc-samx6i.html),
based on Freescale Community BSP.
Currently I have (part of) things working, based on patched 3.10.17
linux-imx kernel, and I'm interested in contributing support for this
board. Could somebody please assist me on doing so?
I already have some items that are acceptable for vendor BSP, but
probably have to be reworked before inclusion. These are described
below. Any advice on these will be appreciated.
*) Support for hardware variations.
There are quite a few hardware options - some chosen at manufacture time
(which imx6 processor to use, board revision, if PCIe switch chip is
installed or not), some configured by external signals that come from
carrier board SMARC-sAMX6i is inserted into (e.g. SPI CS routing depends
on signal on SMARC BOOT_SEL pins). Even more variations are added by
possibility to insert SMARC-sAMX6i module into different carrier boards.
At beginning of my work I had access to vendor 3.0-based BSP for this
hardware. That BSP provided single kernel to support everything, by
means of large arch/arm/mach-mx6/board-smx6.c file that registered
things differently based on runtime-detected environment (i.e. cpu type,
GPIO reads) or kernel command line.
Normally device tree makes it easier to support different hardware, but
not here... With device tree based hardware description, support for N
hardware options results into need of 2^N device trees. To avoid that, I
created dtsi file with high usage of C preprocessor macros.
I'm attaching it to give idea how it looks like. C preprocessor is used
here both to select module options, and to provide "syntax sugar" to
describe carrier board (e.g. SMARC spec states that there is "GP I2C
bus" - so it could be referenced as "smarc_gp_i2c", not "i2cN", in
carrier's dts). So if support for other SMARC module is ever added, same
dts could be used for carrier board, just with different module dtsi.
Example dtsi file describing (part of) Kontron's SMARC evaluation
carrier board, is also attached.
With this approach, to get support for particular hardware variation,
one has to write a tiny dts that #define's several macros and #include's
dtsi files for module and carrier. Example is also attached.
This approach works, but I have not seen anything similar with other
hardware. Is this acceptable? If not, what should be used instead?
*) Display selection
Hardware provides several display interfaces (lcd, lvds, hdmi) and
mapping these into /dev/fbN devices is not obvious. Especially combined
with hardware variations: e.g. imx6q has 2 IPUs and thus can provide
lvds, lcd and hdmi at the same time - but imx6dl has only one IPU so no
more than two interfaces at a time.
SMARC connector includes pins for both lcd and lvds display interfaces,
however rest of the SMARC spec suggests that these are not intended to
be used at the same time (e.g. there is single "display power" line).
To get things more controllable, I decided to deal with "primary display
interface" as one of hardware variations, selectable by C preprocessor
macros. So /dev/fb0 (and /dev/fb1 for overlay layer) is always "primary
display", either on lcd and lvds, selectable by device tree. And
/dev/fb2 is always "secondary display" on hdmi.
How is display configuration handled with other hardware?
In the list postings, e.g. at
http://article.gmane.org/gmane.linux.embedded.yocto.meta-freescale/11448, I've
seen command line based configuration (video=mxcfb0:...). But how does
this combine with mxcfb definitions in device tree [including /asiases
node that binds mxcfb's to ids]?
*) Patches from upstream
I had to include some patches from kernel.org tree - to support more SPI
flash chips, to add gpio-backlight, etc
Is it ok to have linux-smx6 recipe that is linux-imx + some upstream
patches included directly info recipe? Or separate kernel tree has to
be set up? Or something else?
*) Ugly things
There are a couple of issues that I currently solve with rude hardcode.
- SMARC spec instructs to configure one of SMARC connector's pins just
before CPU goes into suspend. Older (pre-devicetree) linux-imx kernel
had board-specific suspend-resume hooks; these could be used to control
appropriate GPIO. Device tree based kernel do not provide such hooks
(and indeed these can't be really used without board-specific C code). I
had to patch imx6 suspend/resume code to toggle the GPIO.
- SMARC-sAMX6i has 4 GPIOs for PCIe reset - one for PCIe switch and one
for each of 3 switch downstream ports (that map to 3 SMARC PCIe
interfaces). I had to patch pcie-designware.c to deal with 4 reset GPIOs
instead of one.
Is it acceptable to have such rude hacks in linux-smx6 recipe? Or some
sane, mainlineable solutions should be found for these issues before
contributing board support to Freescale Community BSP?
*) No U-Boot
Currently I've done only kernel, vendor u-boot is kept untouched. Could
this be kept as-is for now, or u-boot recipe must be added together with
kernel recipe?
WBR,
Nikita Yushchenko,
Linux kernel engineer at RTsoft
[-- Attachment #2: imx6qdl-smx6.dtsi --]
[-- Type: text/plain, Size: 22710 bytes --]
/*
* The code contained herein is licensed under the GNU General Public
* License. You may obtain a copy of the GNU General Public License
* Version 2 or later at the following locations:
*
* http://www.opensource.org/licenses/gpl-license.html
* http://www.gnu.org/copyleft/gpl.html
*/
#if !defined(SMX6_CPU_IMX6Q) && !defined(SMX6_CPU_IMX6DL)
#error Please define CPU type
#endif
#if defined(SMX6_CPU_IMX6Q) && defined(SMX6_CPU_IMX6DL)
#error Please define single CPU type
#endif
#if !defined(SMX6_PANEL_LCD) && !defined(SMX6_PANEL_LVDS)
#error Please define panel interface type
#endif
#if defined(SMX6_PANEL_LCD) && defined(SMX6_PANEL_LVDS)
#error Please define single panel interface type
#endif
#ifdef SMX6_CPU_IMX6Q
#include "imx6q.dtsi"
#define SMX6_COMPATIBLE "kontron,imx6q-smx6", "fsl,imx6q"
#endif
#ifdef SMX6_CPU_IMX6DL
#define SMX6_COMPATIBLE "kontron,imx6dl-smx6", "fsl,imx6dl"
#include "imx6dl.dtsi"
#endif
#ifndef SMX6_MODEL
#define SMX6_MODEL "Kontron SMARC-sAMX6i module"
#endif
/ {
model = SMX6_MODEL;
compatible = SMX6_COMPATIBLE;
memory {
reg = <0x10000000 0x40000000>;
};
aliases {
mxcfb0 = &mxcfb1;
mxcfb1 = &mxcfb2;
spi0 = &ecspi4;
spi1 = &ecspi2;
};
sound-hdmi {
compatible = "fsl,imx6q-audio-hdmi",
"fsl,imx-audio-hdmi";
model = "imx-audio-hdmi";
hdmi-controller = <&hdmi_audio>;
};
mxcfb1: fb@0 {
compatible = "fsl,mxc_sdc_fb";
#ifdef SMX6_PANEL_LCD
disp_dev = "lcd";
#endif
#ifdef SMX6_PANEL_LVDS
disp_dev = "ldb";
#endif
interface_pix_fmt = "RGB24";
mode_str = "1280x800M@60";
default_bpp = <32>;
int_clk = <0>;
late_init = <0>;
status = "okay";
};
mxcfb2: fb@1 {
compatible = "fsl,mxc_sdc_fb";
disp_dev = "hdmi";
interface_pix_fmt = "RGB24";
mode_str ="1920x1080M@60";
default_bpp = <24>;
int_clk = <0>;
late_init = <0>;
status = "okay";
};
#ifdef SMX6_PANEL_LCD
lcd {
compatible = "fsl,lcd";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_lcd>;
ipu_id = <0>;
disp_id = <0>;
default_ifmt = "RGB24";
status = "okay";
};
#endif
smarc_pwm_backlight: backlight {
compatible = "pwm-backlight";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_backlight>;
pwms = <&pwm4 0 5000000>;
brightness-levels = <
0 1 2 3 4 5 6 7 8 9
10 11 12 13 14 15 16 17 18 19
20 21 22 23 24 25 26 27 28 29
30 31 32 33 34 35 36 37 38 39
40 41 42 43 44 45 46 47 48 49
50 51 52 53 54 55 56 57 58 59
60 61 62 63 64 65 66 67 68 69
70 71 72 73 74 75 76 77 78 79
80 81 82 83 84 85 86 87 88 89
90 91 92 93 94 95 96 97 98 99
100
>;
default-brightness-level = <80>;
enable-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
fb = <&mxcfb1>;
};
lcdpower {
compatible = "gpio-backlight";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_lcdpower>;
gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
default-on;
fb = <&mxcfb1>;
};
smx6_i2c_int: i2c-gpio-0 {
compatible = "i2c-gpio";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_i2c_gpio_0>;
gpios =
<&gpio1 28 0>, /* sda */
<&gpio1 30 0>; /* scl */
#address-cells = <1>;
#size-cells = <0>;
i2c-gpio,delay-us = <2>;
};
smarc_i2c_cam: i2c-gpio-1 {
compatible = "i2c-gpio";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_i2c_gpio_1>;
gpios =
<&gpio4 10 0>, /* sda */
<&gpio1 6 0>; /* scl */
#address-cells = <1>;
#size-cells = <0>;
i2c-gpio,delay-us = <2>;
};
smarc_i2c_lcd: i2c-gpio-2 {
compatible = "i2c-gpio";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_i2c_gpio_2>;
gpios =
<&gpio1 21 0>, /* sda */
<&gpio1 19 0>; /* scl */
#address-cells = <1>;
#size-cells = <0>;
i2c-gpio,delay-us = <2>;
};
regulators {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <0>;
reg_3v3_s5: regulator@0 {
compatible = "regulator-fixed";
reg = <0>;
regulator-name = "V_3V3_S5";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
regulator-always-on;
};
reg_1v8_s5: regulator@1 {
compatible = "regulator-fixed";
reg = <1>;
regulator-name = "V_1V8_S5";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-boot-on;
regulator-always-on;
};
reg_3v3_s0: regulator@2 {
compatible = "regulator-fixed";
reg = <2>;
regulator-name = "V_3V3_S0";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
regulator-always-on;
};
reg_1v0_s0: regulator@3 {
compatible = "regulator-fixed";
reg = <3>;
regulator-name = "V_1V0_S0";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-boot-on;
regulator-always-on;
};
};
gpio-keys {
compatible = "gpio-keys";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_keys>;
power {
label = "Power";
gpios = <&gpio6 16 1>;
linux,code = <116>; /* KEY_POWER */
gpio-key,wakeup;
debounce-interval = <1>;
};
sleep {
label = "Sleep";
gpios = <&gpio6 17 1>;
linux,code = <142>; /* KEY_SLEEP */
gpio-key,wakeup;
debounce-interval = <1>;
};
lid {
label = "Lid";
gpios = <&gpio5 0 1>;
linux,input-type = <5>; /* EV_SW */
linux,code = <0>; /* SW_LID */
gpio-key,wakeup;
debounce-interval = <1>;
};
};
v4l2_out {
compatible = "fsl,mxc_v4l2_output";
status = "okay";
};
};
#define smarc_ser0 uart1
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_uart1>;
fsl,uart-has-rtscts;
};
#define smarc_ser1 uart2
&uart2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_uart2>;
};
#define smarc_ser2 uart4
&uart4 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_uart4>;
fsl,uart-has-rtscts;
};
#define smarc_ser3 uart5
&uart5 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_uart5>;
};
&fec {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_enet_fec>;
phy-mode = "rgmii";
status = "okay";
};
#define smarc_spi0 ecspi4
&ecspi4 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_ecspi4>;
fsl,spi-num-chipselects = <3>;
cs-gpios = <&gpio3 24 0>, <&gpio3 29 0>, <&gpio3 25 0>;
status = "okay";
};
#define smarc_spi1 ecspi2
&ecspi2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_ecspi2>;
fsl,spi-num-chipselects = <2>;
cs-gpios = <&gpio2 26 0>, <&gpio2 27 0>;
status = "okay";
};
&usbotg {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_usbotg>;
/* no 'imx6-usb-charger-detection' since USB_OTG_CHD_B pin is not wired */
status = "okay";
};
&usbh1 {
status = "okay";
};
#define smarc_sdmmc usdhc2
&usdhc2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_usdhc2>;
bus-width = <8>;
cd-gpios = <&gpio1 4 0>; /* per schematics, always constant? */
};
#define smarc_sdio usdhc3
&usdhc3 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_usdhc3>;
bus-width = <4>;
cd-gpios = <&gpio6 14 0>;
wp-gpios = <&gpio1 26 0>;
};
#define SMARC_SDIO_PWR_EN_GPIO <&gpio1 29 0>
#ifndef SMX6_HIDE_EMMC
&usdhc4 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_usdhc4>;
bus-width = <8>;
no-1-8-v;
non-removable;
status = "okay";
};
#endif
#ifdef SMX6_PANEL_LVDS
&ldb {
mode = "sin0";
ipu_id = <0>;
disp_id = <0>;
sec_ipu_id = <0>;
sec_disp_id = <0>;
ext_ref = <1>;
status = "okay";
};
#endif
&pwm4 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_pwm4>;
status = "okay";
};
#define smarc_i2c_gp i2c1
&i2c1 {
clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_i2c1>;
status = "okay";
};
#ifndef SMX6_HDCP
#define smarc_i2c_hdmi i2c2
&i2c2 {
clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_i2c2>;
status = "okay";
hdmi: edid@50 {
compatible = "fsl,imx6-hdmi-i2c";
reg = <0x50>;
};
};
#endif
#define smarc_i2c_pm i2c3
&i2c3 {
clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_i2c3>;
status = "okay";
};
&pcie {
wake-up-gpio = <&gpio6 18 0>;
#ifdef SMX6_PCIE_SWITCH
reset-gpio = <&gpio2 0 GPIO_ACTIVE_LOW>,
<&gpio3 13 GPIO_ACTIVE_LOW>,
<&gpio3 14 GPIO_ACTIVE_LOW>,
<&gpio3 15 GPIO_ACTIVE_LOW>;
no-gen2;
#else
reset-gpio = <&gpio3 13 GPIO_ACTIVE_LOW>;
#endif
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_pcie>;
status = "okay";
};
#ifdef SMX6_CPU_IMX6Q
#define smarc_sata sata
#endif
#define smarc_can0 flexcan1
&flexcan1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_flexcan1>;
};
#define smarc_can1 flexcan2
&flexcan2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_flexcan2>;
};
&smx6_i2c_int {
pfuze100@08 {
compatible = "fsl,pfuze100";
reg = <0x08>;
/* Looks unused by pfuze100 driver */
interrupt-parent = <&gpio7>;
interrupts = <13 8>; /* 8 = level, active low */
regulators {
vsnvs {
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <3000000>;
regulator-boot-on;
regulator-always-on;
};
reg_v_core_s0: sw1ab {
regulator-name = "V_CORE_S0";
regulator-min-microvolt = <300000>;
regulator-max-microvolt = <1875000>;
regulator-boot-on;
regulator-always-on;
};
reg_vddsoc_s0: sw1c {
regulator-name = "V_VDDSOC_S0";
regulator-min-microvolt = <300000>;
regulator-max-microvolt = <1875000>;
regulator-boot-on;
regulator-always-on;
};
reg_3v15_s0: sw2 {
regulator-name = "V_3V15_S0";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
regulator-always-on;
};
/* sw3a/b is used in dual mode, but driver does not
* support it? anyway, no need to control DDR
* power - so just leaving dummy entries for sw3a
* and sw3b for now */
sw3a {
regulator-min-microvolt = <400000>;
regulator-max-microvolt = <1975000>;
regulator-boot-on;
regulator-always-on;
};
sw3b {
regulator-min-microvolt = <400000>;
regulator-max-microvolt = <1975000>;
regulator-boot-on;
regulator-always-on;
};
reg_1v8_s0: sw4 {
regulator-name = "V_1V8_S0";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
regulator-always-on;
};
reg_5v0_s0: swbst {
regulator-name = "V_5V0_S0";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5150000>;
};
vrefddr {
regulator-boot-on;
regulator-always-on;
};
/* Per schematics, of all VGEN's, only VGEN5 has some
usage ... but even that - over DNI resistor */
vgen1 {
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <1550000>;
};
vgen2 {
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <1550000>;
};
vgen3 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3300000>;
};
vgen4 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3300000>;
};
reg_2v5_s0: vgen5 {
regulator-name = "V_2V5_S0";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3300000>;
};
vgen6 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3300000>;
};
};
};
};
#ifndef SMX6_HIDE_SPI_FLASH
&smarc_spi0 {
m25p80@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "winbond,w25q64dw";
spi-max-frequency = <20000000>;
reg = <0>;
partition@0 {
label = "bootloader";
reg = <0x000000 0x0c0000>;
read-only;
};
partition@c0000 {
label = "environment";
reg = <0x0c0000 0x010000>;
};
partition@d0000 {
label = "user";
reg = <0x0d0000 0x730000>;
};
};
};
#endif
#ifdef SMX6_CPU_IMX6Q
#define smarc_sata sata
#endif
&hdmi_core {
#ifdef SMX6_CPU_IMX6Q
ipu_id = <1>;
disp_id = <0>;
#endif
#ifdef SMX6_CPU_IMX6DL
ipu_id = <0>;
disp_id = <1>;
#endif
status = "okay";
};
&hdmi_video {
#ifdef SMX6_HDCP
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_hdmi_video>;
fsl,hdcp;
#endif
status = "okay";
};
&hdmi_audio {
status = "okay";
};
&hdmi_cec {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_hdmi_cec>;
status = "okay";
};
/* comment out WGOR_B pin configuration for now - it causes board reboots */
/*&wdog1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_wdog1>;
};*/
&iomuxc {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_smx6_hog>;
hog {
pinctrl_smx6_hog: hoggrp-smx6 {
fsl,pins = <
/* SMARC GPIO lines - enable SION bit */
MX6QDL_PAD_EIM_DA0__GPIO3_IO00 0x4000b0b1
MX6QDL_PAD_EIM_DA1__GPIO3_IO01 0x4000b0b1
MX6QDL_PAD_EIM_DA2__GPIO3_IO02 0x4000b0b1
MX6QDL_PAD_EIM_DA3__GPIO3_IO03 0x4000b0b1
MX6QDL_PAD_EIM_DA4__GPIO3_IO04 0x4000b0b1
MX6QDL_PAD_EIM_DA5__GPIO3_IO05 0x4000b0b1
MX6QDL_PAD_EIM_DA6__GPIO3_IO06 0x4000b0b1
MX6QDL_PAD_EIM_DA7__GPIO3_IO07 0x4000b0b1
MX6QDL_PAD_EIM_DA8__GPIO3_IO08 0x4000b0b1
MX6QDL_PAD_EIM_DA9__GPIO3_IO09 0x4000b0b1
MX6QDL_PAD_EIM_DA10__GPIO3_IO10 0x4000b0b1
MX6QDL_PAD_EIM_DA11__GPIO3_IO11 0x4000b0b1
>;
};
};
uart1 {
pinctrl_smx6_uart1: uart1grp-smx6 {
fsl,pins = <
MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
MX6QDL_PAD_EIM_D20__UART1_RTS_B 0x1b0b1
MX6QDL_PAD_EIM_D19__UART1_CTS_B 0x1b0b1
>;
};
};
uart2 {
pinctrl_smx6_uart2: uart2grp-smx6 {
fsl,pins = <
MX6QDL_PAD_EIM_D27__UART2_RX_DATA 0x1b0b1
MX6QDL_PAD_EIM_D26__UART2_TX_DATA 0x1b0b1
>;
};
};
uart4 {
pinctrl_smx6_uart4: uart4grp-smx6 {
fsl,pins = <
MX6QDL_PAD_CSI0_DAT13__UART4_RX_DATA 0x1b0b1
MX6QDL_PAD_CSI0_DAT12__UART4_TX_DATA 0x1b0b1
MX6QDL_PAD_CSI0_DAT16__UART4_RTS_B 0x1b0b1
MX6QDL_PAD_CSI0_DAT17__UART4_CTS_B 0x1b0b1
>;
};
};
uart5 {
pinctrl_smx6_uart5: uart5grp-smx6 {
fsl,pins = <
MX6QDL_PAD_CSI0_DAT15__UART5_RX_DATA 0x1b0b1
MX6QDL_PAD_CSI0_DAT14__UART5_TX_DATA 0x1b0b1
>;
};
};
fec {
pinctrl_smx6_enet_fec: fecgrp-smx6 {
fsl,pins = <
MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b0b0
MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b0b0
MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b0b0
MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b0b0
MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b0b0
MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b0b0
MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b0b0
MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b0b0
MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b0b0
MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b0b0
MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
>;
};
};
ecspi2 {
pinctrl_smx6_ecspi2: ecspi2grp-smx6 {
fsl,pins = <
MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK 0x80000000
MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI 0x80000000
MX6QDL_PAD_EIM_OE__ECSPI2_MISO 0x80000000
MX6QDL_PAD_EIM_RW__GPIO2_IO26 0x80000000
MX6QDL_PAD_EIM_LBA__GPIO2_IO27 0x80000000
>;
};
};
ecspi4 {
pinctrl_smx6_ecspi4: ecspi4grp-smx6 {
fsl,pins = <
MX6QDL_PAD_EIM_D21__ECSPI4_SCLK 0x80000000
MX6QDL_PAD_EIM_D28__ECSPI4_MOSI 0x80000000
MX6QDL_PAD_EIM_D22__ECSPI4_MISO 0x80000000
/* In hardware, ECSPI4's SS0,SS1,SS3 are wired.
But spi-imx driver support only continuous
numbering, and only can use GPIOs (and not
ECSPI's hardware SS) for CS. So linux view
of CS numbers differs from hw view, and
pins are configured as GPIOs */
/* physical - CS2, in linux - CS0, either internal flash or SMARC CS0 */
MX6QDL_PAD_EIM_D24__GPIO3_IO24 0x80000000
/* physical - CS0, in linux - CS1, either SMARC CS0 or not-connected */
MX6QDL_PAD_EIM_D29__GPIO3_IO29 0x80000000
/* physical - CS3, in linux - CS2, SMARC CS1 */
MX6QDL_PAD_EIM_D25__GPIO3_IO25 0x80000000
>;
};
};
usbotg {
pinctrl_smx6_usbotg: usbothgrp-smx6 {
fsl,pins = <
MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x1f8b0
/* Comment out power and OC gpio's for now, since these
are not used by driver */
// MX6QDL_PAD_CSI0_PIXCLK__GPIO5_IO18 0x80000000 /* USB power */
// MX6QDL_PAD_CSI0_DATA_EN__GPIO5_IO20 0x80000000 /* USB OC */
>;
};
};
usdhc2 {
pinctrl_smx6_usdhc2: usdhc2grp-smx6 {
fsl,pins = <
MX6QDL_PAD_SD2_CLK__SD2_CLK 0x17059
MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17059
MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17059
MX6QDL_PAD_NANDF_D4__SD2_DATA4 0x17059
MX6QDL_PAD_NANDF_D5__SD2_DATA5 0x17059
MX6QDL_PAD_NANDF_D6__SD2_DATA6 0x17059
MX6QDL_PAD_NANDF_D7__SD2_DATA7 0x17059
MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x80000000 /* CD */
>;
};
};
usdhc3 {
pinctrl_smx6_usdhc3: usdhc3grp-smx6 {
fsl,pins = <
MX6QDL_PAD_SD3_CLK__SD3_CLK 0x17059
MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
MX6QDL_PAD_NANDF_CS1__GPIO6_IO14 0x80000000 /* CD */
MX6QDL_PAD_ENET_RXD1__GPIO1_IO26 0x80000000 /* WP */
/* FIXME: should this be moved to regulator's
group? */
MX6QDL_PAD_ENET_TXD1__GPIO1_IO29 0x80000000 /* PWR_EN */
>;
};
};
usdhc4 {
pinctrl_smx6_usdhc4: usdhc4grp-smx6 {
fsl,pins = <
MX6QDL_PAD_SD4_CLK__SD4_CLK 0x17059
MX6QDL_PAD_SD4_CMD__SD4_CMD 0x17059
MX6QDL_PAD_SD4_DAT0__SD4_DATA0 0x17059
MX6QDL_PAD_SD4_DAT1__SD4_DATA1 0x17059
MX6QDL_PAD_SD4_DAT2__SD4_DATA2 0x17059
MX6QDL_PAD_SD4_DAT3__SD4_DATA3 0x17059
MX6QDL_PAD_SD4_DAT4__SD4_DATA4 0x17059
MX6QDL_PAD_SD4_DAT5__SD4_DATA5 0x17059
MX6QDL_PAD_SD4_DAT6__SD4_DATA6 0x17059
MX6QDL_PAD_SD4_DAT7__SD4_DATA7 0x17059
>;
};
};
lcd {
pinctrl_smx6_lcd: lcdgrp-smx6 {
fsl,pins = <
MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 0x100f1
MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0x100f1
MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0x100f1
MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0x100f1
MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0x100f1
MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0x100f1
MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0x100f1
MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0x100f1
MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0x100f1
MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0x100f1
MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0x100f1
MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0x100f1
MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0x100f1
MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0x100f1
MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0x100f1
MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0x100f1
MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0x100f1
MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0x100f1
MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18 0x100f1
MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19 0x100f1
MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20 0x100f1
MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 0x100f1
MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 0x100f1
MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 0x100f1
MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x100f1
MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0x100f1 /* DE */
MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x100f1 /* HSYNC */
MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x100f1 /* VSYNC */
>;
};
};
backlight {
pinctrl_smx6_backlight: backlightgrp-smx6 {
fsl,pins = <
MX6QDL_PAD_SD1_DAT0__GPIO1_IO16 0x80000000
>;
};
};
lcdpower {
pinctrl_smx6_lcdpower: lcdpowergrp-smx6 {
fsl,pins = <
MX6QDL_PAD_SD1_DAT1__GPIO1_IO17 0x80000000
>;
};
};
pwm4 {
pinctrl_smx6_pwm4: pwm4grp-smx6 {
fsl,pins = <
MX6QDL_PAD_SD1_CMD__PWM4_OUT 0x80000000
>;
};
};
i2c1 {
pinctrl_smx6_i2c1: i2c1grp-smx6 {
fsl,pins = <
MX6QDL_PAD_CSI0_DAT8__I2C1_SDA 0x4001b8b1
MX6QDL_PAD_CSI0_DAT9__I2C1_SCL 0x4001b8b1
>;
};
};
i2c2 {
pinctrl_smx6_i2c2: i2c2grp-smx6 {
fsl,pins = <
MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
>;
};
};
i2c3 {
pinctrl_smx6_i2c3: i2c3grp-smx6 {
fsl,pins = <
MX6QDL_PAD_GPIO_5__I2C3_SCL 0x4001b8b1
MX6QDL_PAD_GPIO_16__I2C3_SDA 0x4001b8b1
>;
};
};
i2c-gpio-0 {
pinctrl_smx6_i2c_gpio_0: i2c-gpio-0grp-smx6 {
fsl,pins = <
/* SCL GPIO */
MX6QDL_PAD_ENET_TXD0__GPIO1_IO30 0x80000000
/* SDA GPIO */
MX6QDL_PAD_ENET_TX_EN__GPIO1_IO28 0x80000000
>;
};
};
i2c-gpio-1 {
pinctrl_smx6_i2c_gpio_1: i2c-gpio-1grp-smx6 {
fsl,pins = <
/* SCL GPIO */
MX6QDL_PAD_GPIO_6__GPIO1_IO06 0x80000000
/* SDA GPIO */
MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x80000000
>;
};
};
i2c-gpio-2 {
pinctrl_smx6_i2c_gpio_2: i2c-gpio-2grp-smx6 {
fsl,pins = <
/* SCL GPIO */
MX6QDL_PAD_SD1_DAT2__GPIO1_IO19 0x80000000
/* SDA GPIO */
MX6QDL_PAD_SD1_DAT3__GPIO1_IO21 0x80000000
>;
};
};
pcie {
pinctrl_smx6_pcie: pciegrp-smx6 {
fsl,pins = <
/* RST_PCIE_(SWITCH,A,B,C)# */
MX6QDL_PAD_NANDF_D0__GPIO2_IO00 0x80000000
MX6QDL_PAD_EIM_DA13__GPIO3_IO13 0x80000000
MX6QDL_PAD_EIM_DA14__GPIO3_IO14 0x80000000
MX6QDL_PAD_EIM_DA15__GPIO3_IO15 0x80000000
/* PCIE_WAKE# */
MX6QDL_PAD_SD3_DAT6__GPIO6_IO18 0x80000000
>;
};
};
flexcan1 {
pinctrl_smx6_flexcan1: flexcan1grp-smx6 {
fsl,pins = <
MX6QDL_PAD_GPIO_7__FLEXCAN1_TX 0x80000000
MX6QDL_PAD_GPIO_8__FLEXCAN1_RX 0x80000000
>;
};
};
flexcan2 {
pinctrl_smx6_flexcan2: flexcan2grp-smx6 {
fsl,pins = <
MX6QDL_PAD_KEY_COL4__FLEXCAN2_TX 0x80000000
MX6QDL_PAD_KEY_ROW4__FLEXCAN2_RX 0x80000000
>;
};
};
keys {
pinctrl_smx6_keys: keysgrp-smx6 {
fsl,pins = <
/* Power Button */
MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x80000000
/* SLEEP# */
MX6QDL_PAD_SD3_DAT7__GPIO6_IO17 0x80000000
/* LID# */
MX6QDL_PAD_EIM_WAIT__GPIO5_IO00 0x80000000
>;
};
};
hdmi_cec {
pinctrl_smx6_hdmi_cec: hdmi_cecgrp-smx6 {
fsl,pins = <
MX6QDL_PAD_EIM_A25__HDMI_TX_CEC_LINE 0x1f8b0
>;
};
};
hdmi_video {
pinctrl_smx6_hdmi_video: hdmi_videogrp-smx6 {
fsl,pins = <
MX6QDL_PAD_KEY_COL3__HDMI_TX_DDC_SCL 0x4001b8b1
MX6QDL_PAD_KEY_ROW3__HDMI_TX_DDC_SDA 0x4001b8b1
>;
};
};
wdog1 {
pinctrl_smx6_wdog1: wdoggrp-smx6 {
fsl,pins = <
MX6QDL_PAD_GPIO_9__WDOG1_B 0x80000000
>;
};
};
};
[-- Attachment #3: kontron-smarc-evaluation-carrier.dtsi --]
[-- Type: text/plain, Size: 2344 bytes --]
/*
* The code contained herein is licensed under the GNU General Public
* License. You may obtain a copy of the GNU General Public License
* Version 2 or later at the following locations:
*
* http://www.opensource.org/licenses/gpl-license.html
* http://www.gnu.org/copyleft/gpl.html
*/
/ {
regulators {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <0>;
/* PWM power.
This is stub for now, including voltage values.
Physically, LP8545 is used there. It could be described better */
carrier_pwm_reg: regulator@100 {
compatible = "regulator-fixed";
reg = <100>;
regulator-name = "V_31V9_BKLT";
regulator-min-microvolt = <12000000>;
regulator-max-microvolt = <12000000>;
regulator-boot-on;
regulator-always-on;
};
/* MicroSD slot power */
carrier_sdio_reg: regulator@101 {
compatible = "regulator-fixed";
reg = <101>;
regulator-name = "V_3V3_SDCARD";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
gpio = SMARC_SDIO_PWR_EN_GPIO;
enable-active-high;
};
/* CAN0 enable line */
can0_en_reg: regulator@102 {
compatible = "regulator-fixed";
reg = <102>;
regulator-name = "CAN0_EN";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
gpio = <&pm_gpio 6 0>;
enable-active-high;
};
/* CAN1 enable line */
can1_en_reg: regulator@103 {
compatible = "regulator-fixed";
reg = <103>;
regulator-name = "CAN1_EN";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
gpio = <&pm_gpio 7 0>;
enable-active-high;
};
};
};
&smarc_ser0 {
status = "okay";
};
&smarc_ser1 {
status = "okay";
};
&smarc_ser2 {
status = "okay";
};
&smarc_ser3 {
status = "okay";
};
&smarc_pwm_backlight {
power-supply = <&carrier_pwm_reg>;
};
&smarc_sdio {
status = "okay";
vmmc-supply = <&carrier_sdio_reg>;
no-1-8-v;
};
&smarc_i2c_pm {
pm_eeprom: at24@50 {
compatible = "at24,24c32";
pagesize = <8>;
reg = <0x50>;
};
pm_gpio: tca9554@22 {
compatible = "nxp,pca9554";
reg = <0x22>;
gpio-controller;
#gpio-cells = <2>;
};
};
#ifdef SMX6_CPU_IMX6Q
&smarc_sata {
status = "okay";
};
#endif
&smarc_can0 {
xceiver-supply = <&can0_en_reg>;
status = "okay";
};
&smarc_can1 {
xceiver-supply = <&can1_en_reg>;
status = "okay";
};
[-- Attachment #4: imx6q-smx6-lcd.dts --]
[-- Type: audio/vnd.dts, Size: 429 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: smarc-samx6i board support
2014-12-08 13:00 smarc-samx6i board support Nikita Yushchenko
@ 2014-12-08 13:33 ` Otavio Salvador
2014-12-12 8:22 ` Nikita Yushchenko
0 siblings, 1 reply; 4+ messages in thread
From: Otavio Salvador @ 2014-12-08 13:33 UTC (permalink / raw)
To: Nikita Yushchenko, Fabio Estevam
Cc: meta-freescale@yoctoproject.org, Gennady Kuznetsov
Hello Nikita,
On Mon, Dec 8, 2014 at 11:00 AM, Nikita Yushchenko
<nyushchenko@dev.rtsoft.ru> wrote:
> Recently I was working on BSP for Kontron SMARC-sAMX6i board
> (http://www.kontron.com/products/computeronmodules/smarc/smarc-samx6i.html),
> based on Freescale Community BSP.
Awesome :-)
> Currently I have (part of) things working, based on patched 3.10.17
> linux-imx kernel, and I'm interested in contributing support for this
> board. Could somebody please assist me on doing so?
I think you should go straight to the 3.10.31-1.1.0 beta kernel as
this board needs to go in master and the new GPU drivers does not work
on 3.10.17.
> I already have some items that are acceptable for vendor BSP, but
> probably have to be reworked before inclusion. These are described
> below. Any advice on these will be appreciated.
>
>
> *) Support for hardware variations.
>
> There are quite a few hardware options - some chosen at manufacture time
> (which imx6 processor to use, board revision, if PCIe switch chip is
> installed or not), some configured by external signals that come from
> carrier board SMARC-sAMX6i is inserted into (e.g. SPI CS routing depends
> on signal on SMARC BOOT_SEL pins). Even more variations are added by
> possibility to insert SMARC-sAMX6i module into different carrier boards.
>
> At beginning of my work I had access to vendor 3.0-based BSP for this
> hardware. That BSP provided single kernel to support everything, by
> means of large arch/arm/mach-mx6/board-smx6.c file that registered
> things differently based on runtime-detected environment (i.e. cpu type,
> GPIO reads) or kernel command line.
> Normally device tree makes it easier to support different hardware, but
> not here... With device tree based hardware description, support for N
> hardware options results into need of 2^N device trees. To avoid that, I
> created dtsi file with high usage of C preprocessor macros.
>
> I'm attaching it to give idea how it looks like. C preprocessor is used
> here both to select module options, and to provide "syntax sugar" to
> describe carrier board (e.g. SMARC spec states that there is "GP I2C
> bus" - so it could be referenced as "smarc_gp_i2c", not "i2cN", in
> carrier's dts). So if support for other SMARC module is ever added, same
> dts could be used for carrier board, just with different module dtsi.
> Example dtsi file describing (part of) Kontron's SMARC evaluation
> carrier board, is also attached.
>
> With this approach, to get support for particular hardware variation,
> one has to write a tiny dts that #define's several macros and #include's
> dtsi files for module and carrier. Example is also attached.
>
> This approach works, but I have not seen anything similar with other
> hardware. Is this acceptable? If not, what should be used instead?
Personally I think it'd be better to have a set of different dtb files
and an easy way to set it on the U-Boot environment. So user can
easily change among them.
If you ask me what would be the ideal solution I'd say it'd be to use
the recently added U-Boot SPL support (in U-Boot 2014.10 it has
support, use master from DENX for now work) as it would allow you to
use a single image and boot the Quad, Dual, DualLite and Solo variants
in a single image. All things you can guess from settings and
information of the carrier board can also be used to 'choose' the
proper DTB file.
> *) Display selection
>
> Hardware provides several display interfaces (lcd, lvds, hdmi) and
> mapping these into /dev/fbN devices is not obvious. Especially combined
> with hardware variations: e.g. imx6q has 2 IPUs and thus can provide
> lvds, lcd and hdmi at the same time - but imx6dl has only one IPU so no
> more than two interfaces at a time.
>
> SMARC connector includes pins for both lcd and lvds display interfaces,
> however rest of the SMARC spec suggests that these are not intended to
> be used at the same time (e.g. there is single "display power" line).
>
> To get things more controllable, I decided to deal with "primary display
> interface" as one of hardware variations, selectable by C preprocessor
> macros. So /dev/fb0 (and /dev/fb1 for overlay layer) is always "primary
> display", either on lcd and lvds, selectable by device tree. And
> /dev/fb2 is always "secondary display" on hdmi.
>
> How is display configuration handled with other hardware?
> In the list postings, e.g. at
> http://article.gmane.org/gmane.linux.embedded.yocto.meta-freescale/11448, I've
> seen command line based configuration (video=mxcfb0:...). But how does
> this combine with mxcfb definitions in device tree [including /asiases
> node that binds mxcfb's to ids]?
Take a look at how Boundary Devices has solved this. Their solution is
the most user-friendly one IMO.
> *) Patches from upstream
>
> I had to include some patches from kernel.org tree - to support more SPI
> flash chips, to add gpio-backlight, etc
>
> Is it ok to have linux-smx6 recipe that is linux-imx + some upstream
> patches included directly info recipe? Or separate kernel tree has to
> be set up? Or something else?
I'd say it would be nicer if you maintain it in your Git tree as it is
easier to 'rebase' it on top new kernel releases and like. But
applying patches is also acceptable.
Did you try to coordinate this effort with the vendor itself? A single
and coordinated effort is always the best solution as it avoids work
duplication.
> *) Ugly things
>
> There are a couple of issues that I currently solve with rude hardcode.
>
> - SMARC spec instructs to configure one of SMARC connector's pins just
> before CPU goes into suspend. Older (pre-devicetree) linux-imx kernel
> had board-specific suspend-resume hooks; these could be used to control
> appropriate GPIO. Device tree based kernel do not provide such hooks
> (and indeed these can't be really used without board-specific C code). I
> had to patch imx6 suspend/resume code to toggle the GPIO.
Fabio, do you know if Linux mainline has support for this kind of hook?
> - SMARC-sAMX6i has 4 GPIOs for PCIe reset - one for PCIe switch and one
> for each of 3 switch downstream ports (that map to 3 SMARC PCIe
> interfaces). I had to patch pcie-designware.c to deal with 4 reset GPIOs
> instead of one.
Fabio, do you know if Linux mainline has support for this kind of hook?
> Is it acceptable to have such rude hacks in linux-smx6 recipe? Or some
> sane, mainlineable solutions should be found for these issues before
> contributing board support to Freescale Community BSP?
Yes; that's why I think a vendor / community tree is preferred. Until
the kernel has support for it all you can easily keep those
"workarounds" in place using Git.
> *) No U-Boot
>
> Currently I've done only kernel, vendor u-boot is kept untouched. Could
> this be kept as-is for now, or u-boot recipe must be added together with
> kernel recipe?
You can add the vendor U-Boot recipe together and later work on
improving it. But yes, they need to come together or the board is
usuable.
--
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] 4+ messages in thread
* Re: smarc-samx6i board support
2014-12-08 13:33 ` Otavio Salvador
@ 2014-12-12 8:22 ` Nikita Yushchenko
2014-12-12 12:58 ` Otavio Salvador
0 siblings, 1 reply; 4+ messages in thread
From: Nikita Yushchenko @ 2014-12-12 8:22 UTC (permalink / raw)
To: Otavio Salvador, Fabio Estevam
Cc: meta-freescale@yoctoproject.org, Gennady Kuznetsov
Hello Otavio
Thanks for you replies.
I'm taking a time out to port my code to yocto master / 3.10.31 kernel,
to prepare u-boot recipe and to address issues discussed in the mail.
> Did you try to coordinate this effort with the vendor itself?
Yes, we work with Kontron on "official" BSP.
>> *) Support for hardware variations.
> ...
> If you ask me what would be the ideal solution I'd say it'd be to use
> the recently added U-Boot SPL support (in U-Boot 2014.10 it has
> support, use master from DENX for now work) as it would allow you to
> use a single image and boot the Quad, Dual, DualLite and Solo variants
> in a single image.
Hmm... could you provide a bit more details on this?
Does SPL stand for "secondary program loader"? How does this relate to
having single image for different hw configs?
>> *) Display selection
>> ...
> Take a look at how Boundary Devices has solved this. Their solution is
> the most user-friendly one IMO.
Do you mean what is described here -
http://boundarydevices.com/configuring-i-mx6-machines-different-screens-nitrogen6x-sabre-lite/
?
I still do not understand how this correlates with configuring displays
in device tree (just overrides it? then, what for to have display
configuration in device tree at all?)...
Nikita
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: smarc-samx6i board support
2014-12-12 8:22 ` Nikita Yushchenko
@ 2014-12-12 12:58 ` Otavio Salvador
0 siblings, 0 replies; 4+ messages in thread
From: Otavio Salvador @ 2014-12-12 12:58 UTC (permalink / raw)
To: Nikita Yushchenko
Cc: Fabio Estevam, meta-freescale@yoctoproject.org, Gennady Kuznetsov
On Fri, Dec 12, 2014 at 6:22 AM, Nikita Yushchenko
<nyushchenko@dev.rtsoft.ru> wrote:
> Hello Otavio
>
> Thanks for you replies.
>
> I'm taking a time out to port my code to yocto master / 3.10.31 kernel,
> to prepare u-boot recipe and to address issues discussed in the mail.
Right; I agree that the U-Boot should be the starting point here but I
also expect it to be changed during the Linux kernel port as sometimes
you make use its facilities to solve a problem / design requirement.
>>> *) Support for hardware variations.
>> ...
>> If you ask me what would be the ideal solution I'd say it'd be to use
>> the recently added U-Boot SPL support (in U-Boot 2014.10 it has
>> support, use master from DENX for now work) as it would allow you to
>> use a single image and boot the Quad, Dual, DualLite and Solo variants
>> in a single image.
>
> Hmm... could you provide a bit more details on this?
> Does SPL stand for "secondary program loader"? How does this relate to
> having single image for different hw configs?
Because the SPL is capable of identify the CPU type (Q, D, DL, S) and
load the right memory configuration. This is very good and easy a lot
the maintenance work for the BSP team while also makes customers life
easier as remove the CPU type compatibility from the manufacturing
process. Another nice feature is the possibility of boot speed
optimization as we can load the Linux kernel directly and avoid the
U-Boot CLI interface and hardware initialization which is not required
for boot.
Regarding the different hardware configs, if you have a way to detect
the availability of a carrier board, LCD, ..., you have the
possibility to choose the right DeviceTree accordingly.
>>> *) Display selection
>>> ...
>> Take a look at how Boundary Devices has solved this. Their solution is
>> the most user-friendly one IMO.
>
> Do you mean what is described here -
> http://boundarydevices.com/configuring-i-mx6-machines-different-screens-nitrogen6x-sabre-lite/
> ?
>
> I still do not understand how this correlates with configuring displays
> in device tree (just overrides it? then, what for to have display
> configuration in device tree at all?)...
No; this script has some nice ways to figure if a panel A or B is
connected. This can be user to choose the right DeviceTree to load,
for example.
--
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] 4+ messages in thread
end of thread, other threads:[~2014-12-12 12:58 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-08 13:00 smarc-samx6i board support Nikita Yushchenko
2014-12-08 13:33 ` Otavio Salvador
2014-12-12 8:22 ` Nikita Yushchenko
2014-12-12 12:58 ` 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.