HOWTO Custom board support (based on MX35 3DS)

[MartenLootsma1z]

Hi,

I would like to know the possibilities of using the mainline kernel for our platform.

We have a platform with an IMX35 processor. It is a custom board, based on the MX35 3DS (v1.5), some differences:

 - NOR flash

 - MC13982

 - FEC ethernet

 and last but not least: the usage of pinning is different.

For now we use a kernel based on the SDK1_5 (2.6.26 kernel) from Freescale with our own patches (and bugfixes). For that we added to arch/arm/mach-mx35/ our board specific files (stored in our own svn repository).

We would like to update our kernel, for that we could merge our changes into the new SDK's from Freescale, but I prefer to use the mainline kernel with our changes in git (with which I have not more experience than 'git clone'). That leaves me a few questions:

 1. do you think is it worth the effort to try the mainline kernel for our platform?

 2. how do we store our board specific files in a local git?

 3. how can we suggest bug fixes (we sent them to Freescale but without result)?

 4. is the toolchain from Freescale with GCC 4.1 sufficient?

Best regards,

Marten Lootsma

[MartenLootsma1z]

Thank you, I will try it

[RobertSchwebel]

I use OSELAS.Toolchain-2011.03.0, which has gcc-4.5.2. You can download it from our homepage and build it yourself with ptxdist if you like, it is open source.

[MartenLootsma1z]

The error seems to be cause by a change in GCC. I will try a toolchain with GCC higher than 4.1.2 (which I currently use from SDK1_5).

[RobertSchwebel]

I just tried mx3_defconfig in 3.0 and it compiles. Maybe your compiler is broken, where did you get your toolchain from?

[MartenLootsma1z]

Hi Robert,

Thank you for your fast reply.

The chips we use are already defined (the board is in production, with an 2.6.26 kernel). For NOR flash we use Numonyx Strata P30 (32MB), which is surely supported by the kernel. The 'difficult' part is to make the BSP.

Unfortunately I can not request for commercial support, the interest in a newer kernel is not (yet) from within the company but personal interest to try and learn.

I asked about the toolchain because when I take a vanilla kernel and I load arch/arm/mx3_defconfig as config I got the following error on compilation:

make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
[...]
  LD      arch/arm/plat-mxc/devices/built-in.o
  LD      arch/arm/plat-mxc/built-in.o
  CC      kernel/sched.o
kernel/sched_idletask.c: In function 'pick_next_task_idle': /mnt/sandbox/Projects/MB2/linux-2.6/arch/arm/include/asm/atomic.h:42: error: impossible constraint in 'asm'
make[1]: *** [kernel/sched.o] Error 1
make: *** [kernel] Error 2

This error I get when compiling the 3.0, the 2.6.35 and the 2.6.39 kernel (with the standard arch/arm/mx3_defconfig config). What can cause the error?

[RobertSchwebel]

Hi Marten,

This should be an easy target: MX35 is well supported in the mainline!

• Why do you want to use NOR flash? Is it already decided which chips you will use?
• MC13982 is supported in general, but you need to specify the details about which sub-components are required.
• FEC ethernet is supported.

The pin differences are no problem at all - they just have to be specified when defining the board specific port in the kernel.

If you have your own changes separated nicely, it is no problem at all to port them to a recent kernel. I would suggest that you start with a recent kernel - 3.0 works quite fine on MX35.

Regarding your questions:

• Yes, going with the mainline kernel on MX35 is perfectly fine!
• If I would make the BSP, I would manage it (and the platform specific patches) with ptxdist, which is a great build system for this kind of task (of course it is - we have written it :-) It makes it really easy to store the BSP in git.
• If you have bug fixes, they should be done following the standard kernel methods (canonical patches etc) and communicated to the right community mailing lists. I'm pretty sure you'll get answers there...
• Regarding the toolchain, you can use almost any toolchain which is available for that processor. We have an arm1136 toolchain in OSELAS.Toolchain which generates optimized code for hardware vfp.

However, there are many details which are worth to be known. Please drop me a note if you need commercial support. Pengutronix maintains the mainline port for the i.MX family in the official kernel, so we have a lot of experience with that kind of tasks.