compiling kernel: redboot and uboot

The pre-compiled kernel seems to know something about your board your own kernel may not know. For example the mach type, u-boot forwards to the starting kernel.

May I ask you, what processor is running on your board? i.MX27 or i.MX31?

U-Boot forwards the mtdparts kernel command line option to the kernel. So the kernel do not need any partitioning information in the flash.

JB

But if I compile my own kernel using the same (I guess) options that I have for the pre-compiled kernel, why my kernel doesn't start (hard qustion!!!)? I admit that the "mach" type of my new kernel is not 'phy-CORE-something' but 'ADS'. Could it be the real problem? And what exactly uboot needs to send to the kernel?

I use an iMX31.

The precompiled kernel is a kernel binary you got from your vendor, right ? And nothing you compiled on your machine works (even if you have the same kernel configuration as the precompiled kernel) ? So what that suggests to me is that your build environment is NQR (not quite right). If you are cross-compiling from within another architecture/platform (ie: i386) make sure you have an appropriate cross-compiler and have the proper environmental variables (eg: ARCH) set appropriately. When thats done, start with the same kernel version as the precompiled kernel and use the same configuration as it is. When you compile it, the resulting image will usually reside under .../linux/arch/ /boot/ directory. To start off with rename the image to the exact name of the precompiled kernel and replace it on your NFS share. This way you eliminate almost all issues other than the integrity of your compiled binary for the target platform.

It seems using "MACH_TYPE_MX31ADS" as the mach type. What does it mean "my own kernel"? Do you are using the sources provided by your board vendor or a "fresh" kernel from kernel.org? The latter one must fail, due to it does not know anything about your specific hardware. AND: Using the MX31ADS does not help, as both cards differ!

Other way: The kernel must know something about the mach-type it receives from u-boot.

So it is an PCM037, right?

Check, if your own kernel uses the same UART for console output than the pre compiled one. Check if your kernel assumes the same clock reference than vendor's kernel.

JB

I use the kernel provided by Freescale in their LTIB package. The Freescal version is 2.6.22, the Phytec version is 2.6.19, so the configuration files differ a bit. Is it so important the mach type?

what do you exactly mean?

yes.

thank you regards

Your UBoot forwards the "MACH_TYPE_MX31ADS" to your kernel, and the kernel decide to use the arch/arm/mach-mx3/mx31ads.c information for runtime. Create a diff of the files arch/arm/mach-mx3/mx31ads.c and arch/arm/mach-mx3/pcm037.c and you might find the reason why it fails on your pcm037 target.

Yes. It decides about the BSP to be used at runtime. For example you can build a kernel with mx31ads and pcm037 support. At runtime the mach type selects the right configuration.

What should the kernel do if it doesn't know anything about the hardware it currently run on (and cannot detect any hardware at runtime)?

JB

thank you very much! now it's all clear. your explanation is very useful!

I'll make some tests

bye

Juergen Beisert ha scritto:

Nothing new... The kernel compilation is almost impossible due to different versions.

But at least I have understood a bit more how the things work!

AMel ha scritto: