Creating a Customized mx6dl Kernel

[leoschwab]

Now that I finally have some rudimentary competence in creating Yocto recipes for an i.MX6 system, it's time to get the kernel ready for our custom board.

First problem is that the source code kicked out by the IOMux tool (the tool the HW designers use to make pin assignments) bears no resemblance whatsoever to the extant code in the kernel (or U-Boot, apparently).  It looks like I can translate it by hand, however.  (Actually, now that I think about it, I might even be able to auto-translate it.  Hmm; must look into that...)

...Where was I?  Oh, yes.  I've been following the directions in the "i.MX 6Solo/6DualLite BSP Porting Guide."  I've successfully cloned an existing U-Boot config, which will become the config for our board.  So that's building and running.  Things go pear-shaped, however, when I try to assign a new MACH_TYPE value.  The BSP Porting Guide says:

The first board dependent function inside init_sequence[] array is board_init(). board_init() is implemented inside board/freescale/mx6_<custom board name>.c.  At this point the most important tip is the following line of code:

...

gd->bd->bi_arch_number = MACH_TYPE_MX6_<reference board name>; /* board id for Linux */

...

To customize your board ID, go to the registration process at http://www.arm.linux.org.uk/developer/machines/

I temporarily created a new MACH_TYPE definition out of thin air, giving it the value 8192 (well out of the way of all other existing values).

The moment I do this, the kernel fails to boot.  U-Boot loads it and decompress it but, after that, nothing.

The BSP Porting Guide discusses cloning configs for U-Boot, but is less than forthcoming on how to create custom Linux board configs (and no, I've never done this before).  Further, the defconfig files found in FSL's Yocto recipes are somewhat confusing.  For example, the defconfig for the 'imx6dlsabresd' board contains the following entries:

CONFIG_MACH_MX6Q_ARM2=y

CONFIG_MACH_MX6Q_SABRELITE=y

CONFIG_MACH_MX6Q_SABRESD=y

CONFIG_MACH_MX6Q_SABREAUTO=y

This basically invokes four different board definitions in the kernel build (board-mx6q_arm2.c, board-mx6q_sabrelite.c, board-mx6q_sabresd.c, board-mx6q_sabreauto.c).  As such, it's unclear which one I should be cloning for our board.  My attempts so far have been unsuccessful.

Can anyone point me as some resources that will help me create a custom Linux board config?

Schwab

[leoschwab]

Ping?

How about I just simplify the question to this:  When I build a kernel image for an i.MX6DL SABRESD board, the following entries appear in the kernel .config file:

CONFIG_MACH_MX6Q_ARM2=y

CONFIG_MACH_MX6Q_SABRELITE=y

CONFIG_MACH_MX6Q_SABRESD=y

CONFIG_MACH_MX6Q_SABREAUTO=y

Now, call me naive ('cause I am; I've never messed with the Linux kernel in this way before), but I'm under the impression that each of these CONFIG entries specifies a particular board type.  Yet four board types are turned on.  Is there a reason for this?  What patterns should I be following to set up the config for our custom board?

[varsmolta]

There can be multiple machine configurations compiled into the kernel. The bootloader passes the machine type id to the kernel, at which time the correct configuration is loaded. Look here for a nice explanation: http://free-electrons.com/doc/kernel-porting.pdf

You may have a mismatch in the u-boot machine ID vs the kernel machine ID. Both numbers should match:

Common Problems - Linux kernel doesnt boot - RidgeRun Developer Connection

[controlhorus]

Hello

varsmolta wrote:

There can be multiple machine configurations compiled into the kernel. The bootloader passes the machine type id to the kernel, at which time the correct configuration is loaded

:smileyshocked: Sorry, news to me.  And a lot of questions comes.

Are you sure? If the kernel can be used for several machines, why the kernel does not have into itself the code to recognize the processor in which it is running? It is a good thing to have the kernel linked to u-boot? I don´t see it clearly.

Is there any way to know which machines configurations a kernel have?

For example: I loaded a yocto dylan - linux-boundary image on a imx6Q Sabre Lite board. I had video and network working.

Then I changed to linux-fslc and now I have no video and no network. I have no changed u-boot. Is it possible that linux-fscl kernel need a different uboot?

Thanks

[leoschwab]

Diego Gonzalez wrote:

Are you sure? If the kernel can be used for several machines, why the kernel does not have into itself the code to recognize the processor in which it is running? It is a good thing to have the kernel linked to u-boot? I don´t see it clearly.

I'm still fairly new at this but, as near as I've been able to work out, you can have any number of machine types compiled in to the kernel.  Which one actually gets used depends on the "MACH_TYPE_" value, which is handed to the kernel by U-Boot.  Dive into U-Boot's source and look in the board_init() function for your particular board.  You'll see an assignment to gd->bd->bi_arch_number, which gets handed to Linux.  Linux looks through its list of compiled-in machine types, and launches the one that matches.

One reason you might want to do things this way is so that you need only compile a single kernel image that supports "everything" (therefore only one build to test and keep track of), and only U-Boot needs to be machine-specific.

Is there any way to know which machines configurations a kernel have?

Apart from looking at the kernel .config file?  Dunno offhand.  However, the kernel does assemble a list of compiled-in machine types (that's how it searches for a matching MACH_TYPE_ value.  It might be possible to dump the table out in some way...

For example: I loaded a yocto dylan - linux-boundary image on a imx6Q Sabre Lite board. I had video and network working.

Then I changed to linux-fslc and now I have no video and no network. I have no changed u-boot. Is it possible that linux-fscl kernel need a different uboot?

It isn't clear whether, when you tried 'linux-fslc', you also paired it up with 'u-boot-fslc'.  Did you give that a go?

[controlhorus]

Hi Leo

I suppose it have to be that way. Thanks for source tips. I will look at it.

Forget the linux-fslc thing. At some point, we came to think that linux-fslc was a linux from freescale: is not so.

Thanks again

[leoschwab]

Should have said so earlier, but thank you; that got me pointed in the right direction, and now the kernel is coming up.