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

Juergen Beisert ha scritto:


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/
<yourarch>/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

Juergen Beisert ha scritto:

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: