[meta-freescale] Right lib-imx/firmware-imx ... versions

[Jens Rehsack]

Am 23.07.2014 um 19:31 schrieb Jens Rehsack <rehsack at gmail.com>:

It's a bit ago ... but for the records (and pay back a little bit)

> Am 23.07.2014 um 17:45 schrieb Daiane Angolini <daiane.list at gmail.com>:
> 
>> On Wed, Jul 23, 2014 at 11:51 AM, Jens Rehsack <rehsack at gmail.com> wrote:
>>> 
>>> Am 23.07.2014 um 16:19 schrieb Daiane Angolini <daiane.list at gmail.com>:
>>> 
>>>> On Tue, Jul 22, 2014 at 2:24 AM, Jens Rehsack <rehsack at gmail.com> wrote:
>>>>> Hi,
>>>>> 
>>>>> as mentioned in my very first post here, we're trying to get a board
>>>>> running with yocto with a bsp for linux-imx-3.0.35_4.1.0 (bdde708).
>>>>> 
>>>>> As firmware-imx we have 3.0.35_4.0.0 (tried 3.10.17, too - without
>>>>> difference).
>>>> 
>>>> Long story short: Stick to one branch and use it, with the kernel
>>>> version and the imx-lib/gpu/imx-vpu/firmware version already there. It
>>>> was what we tested someway.
>>> 
>>> But there is no Yocto support for imx-lib-3.0.35_4.1.0, neither that
>>> imx-vpu nor gpu-viv-lib-mxq version. Only 3.10.9 and 3.10.17 is included
>>> (daisy has only 3.10.17).
>> 
>> I don´t remember exactly which version was used in each branch. Sorry.
>> I can only say to you that using the branch as-is, was enough to my
>> uses.
>> 
>> 
>>>> Or, let´s be more practical. Have you tested your GPU integration?
>>>> What is the GPU driver version in your kernel, and your GPU user-space
>>>> version?
>>> 
>>> Nope, how can I do that (fsl for dummies - I'm happy controlling Yocto
>>> meanwhile). Just bitbake imx-test or something more?
>> 
>> 
>> For this kernel:
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-kernel/linux/linux-imx_3.0.35.bb?h=dora
>> 
>> Use this GPU user space
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-graphics/gpu-viv-bin-mx6q?h=dora
>> 
>> hfp or sfp....
>> 
>> The Original 3.0.35-4.0.1 is not compatible with
>> gpu-viv-bin-mx6q_3.10.9-1.0.0, that´s why there is a patch to upgrade
>> 3.0.35 to GPU driver p13
> 
> I didn't see that patch, digging for unless ... bsp porting isn't an option.

Found such a patch in old wandboard kernels - I reused some more of the patches
there ...

>> However, it does not mean that this combination is free of bug.
>> 
>> And remember it´s only a hint. As you said at first, community does
>> not support linux-imx-3.0.35 any more.
> 
> I took a look into differences between imx_3.10.17_1.0.0_ga and
> wandboard_imx_3.10.17_1.0.0_ga to get a picture what I have to hack to
> port the bsp from 3.0.35 to 3.10.17 - but I miss the place where
> previously platform initialization happened (arch/arm/mach-mx6/board-mx6q_sabresd.*)
> 
> Is there a suitable guide explaining bsp porting from imx_3.0.35_4.1.0 to
> imx_3.10.17_1.0.0?

Daiane, because you also was involved into https://community.freescale.com/thread/304414:

I digged a lot deeper, tried https://github.com/wandboard-org/linux/commit/7cbd06b2904c1855109084ca6b0c84990bc69233
and debugged and proved more there ...
I also tried to get a picture of vmm by browsing "Understanding The Linux Virtual Memory Manager" by Mel Gorman.

My result: When no swap is configured (and the box has none - because of 1GB RAM and 4GB Flash there is not really space for swap), the memory runs full by page-caching disk files.

There could be several ways out to ensure system is not crashing when pages for DMA are allocated by eg. XBMC, gplay or whatever wants to use the VPU.

1) continuously drop page cache (our measurement tells in our configuration every 15sec is fine even for 4K movies)
2) implement better dma page cache as v4l2 patch demonstrates (pre-alloc 256M and serve dma pages from there, use smart allocation as SmartHeap does and https://github.com/wandboard-org/linux/commit/7cbd06b2904c1855109084ca6b0c84990bc69233 drafts ...)
3) modify vpu dma allocator to interfere with page cache and drop oldest cache entries
4) find a way to simulate swap-conditions without really paging out

Any hints choosing the optimal decision will be appreciated :)

Best regards
-- 
Jens Rehsack
rehsack at gmail.com