[meta-freescale] smarc-samx6i board support

[Otavio Salvador]

Hello Nikita,

On Mon, Dec 8, 2014 at 11:00 AM, Nikita Yushchenko
<nyushchenko at 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