[meta-freescale] [meta-fsl-arm][PATCH 3/3] imx6qsabrelite/defconfig: Enable devtmpfs

Eric Nelson eric.nelson at boundarydevices.com
Fri Dec 21 12:06:14 PST 2012


On 12/21/2012 12:24 PM, Otavio Salvador wrote:
> On Fri, Dec 21, 2012 at 5:12 PM, Eric Nelson
> <eric.nelson at boundarydevices.com> wrote:
>> On 12/21/2012 11:41 AM, Otavio Salvador wrote:
>>>
>>> On Fri, Dec 21, 2012 at 4:37 PM, Eric Nelson
>>> <eric.nelson at boundarydevices.com> wrote:
>>>>
>>>> On 12/21/2012 10:19 AM, Otavio Salvador wrote:
>>>>>
>>>>> On Fri, Dec 21, 2012 at 2:25 PM, Gary Thomas <gary at mlbassoc.com> wrote:
>>>>>>
>>>>>> Recent versions of udev (182 in OE-core) need devtmpfs to operate
>>>>>> correctly
>>>>>>
>>>>>> Signed-off-by: Gary Thomas <gary at mlbassoc.com>
>>>>>
>>>>> Merged to master with reworded commit log and bump PR.
>>>>>
>>>> Hi Otavio,
>>>>
>>>> I have a configuration patch to make, adding CONFIG_FEC_NAPI.
>>>>
>>>> Should I submit it with a bump in PR as you did, or without, so
>>>> that you can coordinate that?
>>>
>>>
>>> Please do it with bump in PR so it is easier for me.
>>>
>>>> The patch itself is to prevent network performance from cratering
>>>> under load as discussed in this blog post:
>>>>           http://boundarydevices.com/i-mx6-ethernet/
>>>>
>>>> And in this patch:
>>>>
>>>> https://github.com/boundarydevices/linux-imx6/commit/38d622938f1352a6550a5e38c624b46b6929439f
>>>>
>>>> Without it, network receive performance can get really bad under
>>>> load.
>>>
>>>
>>> Very nice! However you might like to simply sync the patch for your
>>> boundary tree (the patch compares FSL branch with Bondary ones) so
>>> this would be included. Or this should be applied in all boards?
>>>
>>
>> Well... I was thinking that I'd just push this one, since it has a much
>> bigger impact than the patches we made to flow control and error
>> handling.
>>
>> I think I was a bit mistaken though. I didn't catch that this line was
>> itself in a patch file:
>>          +# CONFIG_FEC_NAPI is not set
>>
>> I also didn't catch and don't quite understand how the defconfig file
>> is applied in the build process. Is 'nitrogen6x_defconfig' even used?
>>
>> I don't see CONFIG_FEC in the defconfig. Does that file somehow get
>> applied on top of a base configuration to apply Yocto specifics?
>
> The defconfig, at linux-imx-<version> is generated using the machine
> config and calling make savedefconfig; so it should be the shorter
> version and produce same .config as result of dependencies.
>
> So the build system copy the defconfig onto .config, run "yes 'n' |
> make oldconfig" and build the kernel.
>
> You can sync the 12.09.01 branch and update the patch at:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-kernel/linux/linux-imx-3.0.35/imx6qsabrelite/sync-boundary-changes.patch
>
> and updated:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-kernel/linux/linux-imx-3.0.35/imx6qsabrelite/defconfig
>
> As I did the trick of using sabrelite as fallback to nitrogen board
> (check https://github.com/Freescale/meta-fsl-arm-extra/blob/master/conf/machine/nitrogen6x.conf#L6)
> it will use those, except a nitrogen specific one is provided. I did
> it to avoid duplicating things and easy maintenance.
>

I think I understand this, but will need to walk the exercise to be
sure and it will likely take a couple of days before I can get to it.

>> There are some things in our boundary-L3.0.35_12.09.01_GA tree that
>> I was hoping to clean up before submitting
>>
>> In particular, we set things up to allow a single image to boot on
>> Quad->Solo that the Freescale team didn't like, so we'll probably
>
> It'd be nice indeed. Why they didn't like it?
>

This is the tricky bit, with a double-include of a header:

	https://github.com/boundarydevices/linux-imx6/commit/a11553187650003a3d88b187fd175b963b2fa957#L0R123

It's origin is in the observation that the board defines the pins
and pads, which are the same regardless of the CPU, but the
addresses are different. By including it twice, you get
two copies of the static mux-config arrays:

	https://github.com/boundarydevices/linux-imx6/blob/boundary-L3.0.35_12.09.01_GA/arch/arm/mach-mx6/pads-mx6_sabrelite.h#L49

Then one of them is selected at run-time based on the CPU:
	https://github.com/boundarydevices/linux-imx6/commit/a11553187650003a3d88b187fd175b963b2fa957#L0R141

>> revert it as we migrate to the 2012-10 branch, which will take a
>> couple of weeks.
>
> So revert back to several images depending on SoC model?
>

Yeah. That's certainly allows more optimization, since we can
remove stuff like SATA, which only applies on 6Quad and 6Dual.

> Regards,
>
> --
> 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
>




More information about the meta-freescale mailing list