[meta-freescale] [meta-fsl-arm][PATCH] linux-imx (3.0.35): Add Boundary Devices changes for imx6qsabrelite

[Otavio Salvador]

On Fri, Nov 30, 2012 at 12:57 PM, Gary Thomas <samoht.yrag at gmail.com> wrote:

> On 2012-11-30 05:44, Otavio Salvador wrote:
>
>>
>>
>>
>> On Fri, Nov 30, 2012 at 10:16 AM, Gary Thomas <samoht.yrag at gmail.com<mailto:
>> samoht.yrag at gmail.com>**> wrote:
>>
>>     On 2012-11-29 08:48, Otavio Salvador wrote:
>>
>>         We import the changes done in Bondary Devices tree and the
>> defconfig
>>         file provided by them.
>>
>>         Change-Id: I63e2d7560735586581fd13d5df60b**__3d5e90d73a3
>>         Signed-off-by: Otavio Salvador <otavio at ossystems.com.br <mailto:
>> otavio at ossystems.com.**br <otavio at ossystems.com.br>>>
>>
>>
>>
>>     This does make my touch screen work, thanks.  My camera module
>> (OV5640 based) does
>>     not work though, but I've not researched it much yet.
>>
>>     A couple of comments:
>>     * Could you put the changes under mx6q instead of imx6qsabrelite,
>> much like the other
>>        files/changes that are present?  I ask because I have a derivative
>> platform which has
>>        a different name (just sabrelite - I got tired of mistyping
>> imx6qsabrelite) and the
>>        patch was not applied until I moved it about.
>>
>>
>> It cannot; we need to apply it to the specific machine only and not all
>> mx6q machines.
>>
>
> I didn't see anything in the patch that would break other imx6q devices,
> plus the way you have it
> won't work if you wanted to also handle their newer nitrogen boards.
>
> No problem - I can use OVERRIDES to accomplish the same thing.  I just add
> this to my derivative sabrelite.conf:
>   OVERRIDES_append = ":imx6qsabrelite"


Yes; this is the way it can be done. When Boundary Devices send the
Nitrogen boards for meta-fsl-arm-extra, we may have an boudarydevices
override that share it among the boards however for now, this is the only
board from them supported.


>     * More changes are necessary to make this useful for the target "out
>> of the box", in particular:
>>        - U-Boot needs to pass additional command line parameters to make
>> the LCD panel work properly
>>
>>
>> It is better to document it ... I am not sure if we ought to default to
>> enable it or not for sabrelite. What do you think?
>>
>
> I'll propose some patches once I work out the details.  I'll make them
> target specific.


Good, thanks.


>        - I use the micro-SD slot as does the BoundaryDevices setup, but
>> U-Boot only wants to boot
>>          from the full size SD card
>>
>>
>> We can change it; if you can, please send the patch for us and we apply
>> it on U-Boot branch (https://github.com/Freescale/**
>> u-boot-imx/tree/patches-2012.**07<https://github.com/Freescale/u-boot-imx/tree/patches-2012.07>
>> )
>>
>
> Same with this.


Good :-)


>        - The touch screen needs some additional files/tuning for X to work
>> correctly (the X axis
>>          is backwards, etc)
>>
>>
>> If it uses evdev, we might try the newer xinput-callibrator that Mario (a
>> coworker) has send to meta-oe mailing list.
>>
>
> It does use evdev.  I have a working config file which I'll also send a
> patch for.


Good; please pick Mario's patch in meta-oe mailing list and give it a try.
I think it will make calibration just work.


>        - I'll investigate the camera soon (not top on my list yet)
>>
>>
>> Good.
>>
>>        - The recent changes, in particular xf86-video-imxfb-vivante, do
>> not build under Yocto/master
>>          which has moved to Xorg server version 1.13.
>>
>>
>> We're still working for danny so not yet in master; please stay in danny
>> as this is the platform we're using for daily work for now.
>>
>>        - Why is GCC not tuned for the Cortex-A9 (currently armv7a is
>> used)?  I rebuilt using
>>              DEFAULTTUNE = "cortexa9hf-neon"
>>          which works fine and is more in line with other Cortex-A9
>> platforms, e.g. PandaBoard.
>>
>>
>> hardfloat can be a problem for ABI in some applications.
>>
>
> It's what Ubuntu (and I think Linaro) are using now.  Again, something I
> can handle in my derivative.


We can check it again but it is important to check about ABI of binaries so
we can have them really working fine (GPU, VPU and maybe others).


>     I'll see about proposing patches for all of these soon
>>
>>
>> Very good; please do.
>>
>> But before looking at patches it is better for us to settle in what ought
>> to be done for defaults...
>
>
-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20121130/33e8d52b/attachment.html>