compiling kernel: redboot and uboot - Embedded

This is a discussion on compiling kernel: redboot and uboot - Embedded ; Hi all. I'm trying to compile a bootable kernel via LTIB for a BSP (ADS by Freescale) that recommends the use of RedBoot as bootloader. At the moment I'm using a board (phyCORE) that has uBoot as bootloader pre-load, just ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: compiling kernel: redboot and uboot

  1. compiling kernel: redboot and uboot

    Hi all.
    I'm trying to compile a bootable kernel via LTIB for a BSP (ADS by
    Freescale) that recommends the use of RedBoot as bootloader.
    At the moment I'm using a board (phyCORE) that has uBoot as bootloader
    pre-load, just to make some attempts and train me in the use of a
    linux-embedded board.

    If i try to use my compiled kernel during a NFS boot procedure, the
    system hangs up on "Uncompressing Linux ..... ok, booting the kernel".
    This doesn't happen, obvsiously, when I use the pre-compiled kernel for
    my board.

    I don't want you to resolve my problem, I'd just like to know (if
    someone knows it) what is the link between a bootloader and the kernel
    compilation, given a BSP.

    I found an option in the kernel configuration that concerns Redboot
    (CONFIG_MTD_REDBOOT_PARTS), I disabled it, but nothing changes.


    Thank in advance.
    Best regards

    AM

  2. Re: compiling kernel: redboot and uboot

    AMel wrote:
    > I'm trying to compile a bootable kernel via LTIB for a BSP (ADS by
    > Freescale) that recommends the use of RedBoot as bootloader.
    > At the moment I'm using a board (phyCORE) that has uBoot as bootloader
    > pre-load, just to make some attempts and train me in the use of a
    > linux-embedded board.
    >
    > If i try to use my compiled kernel during a NFS boot procedure, the
    > system hangs up on "Uncompressing Linux ..... ok, booting the kernel".
    > This doesn't happen, obvsiously, when I use the pre-compiled kernel for
    > my board.


    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?

    > I don't want you to resolve my problem, I'd just like to know (if
    > someone knows it) what is the link between a bootloader and the kernel
    > compilation, given a BSP.
    >
    > I found an option in the kernel configuration that concerns Redboot
    > (CONFIG_MTD_REDBOOT_PARTS), I disabled it, but nothing changes.


    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

  3. Re: compiling kernel: redboot and uboot


    Juergen Beisert ha scritto:
    > AMel wrote:
    >> I'm trying to compile a bootable kernel via LTIB for a BSP (ADS by
    >> Freescale) that recommends the use of RedBoot as bootloader.
    >> At the moment I'm using a board (phyCORE) that has uBoot as bootloader
    >> pre-load, just to make some attempts and train me in the use of a
    >> linux-embedded board.
    >>
    >> If i try to use my compiled kernel during a NFS boot procedure, the
    >> system hangs up on "Uncompressing Linux ..... ok, booting the kernel".
    >> This doesn't happen, obvsiously, when I use the pre-compiled kernel for
    >> my board.

    >
    > 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.
    >


    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?

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


    I use an iMX31.

    >> I don't want you to resolve my problem, I'd just like to know (if
    >> someone knows it) what is the link between a bootloader and the kernel
    >> compilation, given a BSP.
    >>
    >> I found an option in the kernel configuration that concerns Redboot
    >> (CONFIG_MTD_REDBOOT_PARTS), I disabled it, but nothing changes.

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


  4. Re: compiling kernel: redboot and uboot

    On Mar 18, 4:00 am, AMel
    wrote:
    > Juergen Beisert ha scritto:
    >
    >
    >
    > > AMel wrote:
    > >> I'm trying to compile a bootable kernel via LTIB for a BSP (ADS by
    > >> Freescale) that recommends the use of RedBoot as bootloader.
    > >> At the moment I'm using a board (phyCORE) that has uBoot as bootloader
    > >> pre-load, just to make some attempts and train me in the use of a
    > >> linux-embedded board.

    >
    > >> If i try to use my compiled kernel during a NFS boot procedure, the
    > >> system hangs up on "Uncompressing Linux ..... ok, booting the kernel".
    > >> This doesn't happen, obvsiously, when I use the pre-compiled kernel for
    > >> my board.

    >
    > > 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.

    >
    > 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?
    >
    > > May I ask you, what processor is running on your board? i.MX27 or i.MX31?

    >
    > I use an iMX31.
    >
    > >> I don't want you to resolve my problem, I'd just like to know (if
    > >> someone knows it) what is the link between a bootloader and the kernel
    > >> compilation, given a BSP.

    >
    > >> I found an option in the kernel configuration that concerns Redboot
    > >> (CONFIG_MTD_REDBOOT_PARTS), I disabled it, but nothing changes.

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


    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.

  5. Re: compiling kernel: redboot and uboot

    AMel wrote:
    > Juergen Beisert ha scritto:
    >> AMel wrote:
    >>> I'm trying to compile a bootable kernel via LTIB for a BSP (ADS by
    >>> Freescale) that recommends the use of RedBoot as bootloader.
    >>> At the moment I'm using a board (phyCORE) that has uBoot as bootloader
    >>> pre-load, just to make some attempts and train me in the use of a
    >>> linux-embedded board.
    >>>
    >>> If i try to use my compiled kernel during a NFS boot procedure, the
    >>> system hangs up on "Uncompressing Linux ..... ok, booting the kernel".
    >>> This doesn't happen, obvsiously, when I use the pre-compiled kernel for
    >>> my board.

    >>
    >> 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.
    >>

    >
    > 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'.


    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!

    > Could it be the real problem?
    > And what exactly uboot needs to send to the kernel?


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

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

    >
    > I use an iMX31.


    So it is an PCM037, right?

    >>> I don't want you to resolve my problem, I'd just like to know (if
    >>> someone knows it) what is the link between a bootloader and the kernel
    >>> compilation, given a BSP.
    >>>
    >>> I found an option in the kernel configuration that concerns Redboot
    >>> (CONFIG_MTD_REDBOOT_PARTS), I disabled it, but nothing changes.

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


    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


  6. Re: compiling kernel: redboot and uboot

    Juergen Beisert ha scritto:
    > AMel wrote:
    >> Juergen Beisert ha scritto:
    >>> AMel wrote:
    >>>> I'm trying to compile a bootable kernel via LTIB for a BSP (ADS by
    >>>> Freescale) that recommends the use of RedBoot as bootloader.
    >>>> At the moment I'm using a board (phyCORE) that has uBoot as bootloader
    >>>> pre-load, just to make some attempts and train me in the use of a
    >>>> linux-embedded board.
    >>>>
    >>>> If i try to use my compiled kernel during a NFS boot procedure, the
    >>>> system hangs up on "Uncompressing Linux ..... ok, booting the kernel".
    >>>> This doesn't happen, obvsiously, when I use the pre-compiled kernel for
    >>>> my board.
    >>> 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.
    >>>

    >> 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'.

    >
    > 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!
    >

    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?
    >> Could it be the real problem?
    >> And what exactly uboot needs to send to the kernel?

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

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

    >> I use an iMX31.

    >
    > So it is an PCM037, right?
    >

    yes.
    >>>> I don't want you to resolve my problem, I'd just like to know (if
    >>>> someone knows it) what is the link between a bootloader and the kernel
    >>>> compilation, given a BSP.
    >>>>
    >>>> I found an option in the kernel configuration that concerns Redboot
    >>>> (CONFIG_MTD_REDBOOT_PARTS), I disabled it, but nothing changes.
    >>> U-Boot forwards the mtdparts kernel command line option to the kernel. So
    >>> the kernel do not need any partitioning information in the flash.

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


    thank you
    regards

  7. Re: compiling kernel: redboot and uboot

    AMel wrote:

    > Juergen Beisert ha scritto:
    >> AMel wrote:
    >>> Juergen Beisert ha scritto:
    >>>> AMel wrote:
    >>>>> I'm trying to compile a bootable kernel via LTIB for a BSP (ADS by
    >>>>> Freescale) that recommends the use of RedBoot as bootloader.
    >>>>> At the moment I'm using a board (phyCORE) that has uBoot as bootloader
    >>>>> pre-load, just to make some attempts and train me in the use of a
    >>>>> linux-embedded board.
    >>>>>
    >>>>> If i try to use my compiled kernel during a NFS boot procedure, the
    >>>>> system hangs up on "Uncompressing Linux ..... ok, booting the kernel".
    >>>>> This doesn't happen, obvsiously, when I use the pre-compiled kernel
    >>>>> for my board.
    >>>> 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.
    >>>>
    >>> 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'.

    >>
    >> 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!
    >>

    > 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.


    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.

    > Is it so important the mach type?


    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.

    >>> Could it be the real problem?
    >>> And what exactly uboot needs to send to the kernel?

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

    > what do you exactly mean?


    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

  8. Re: compiling kernel: redboot and uboot

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

    I'll make some tests

    bye

    Juergen Beisert ha scritto:
    > AMel wrote:
    >
    >> Juergen Beisert ha scritto:
    >>> AMel wrote:
    >>>> Juergen Beisert ha scritto:
    >>>>> AMel wrote:
    >>>>>> I'm trying to compile a bootable kernel via LTIB for a BSP (ADS by
    >>>>>> Freescale) that recommends the use of RedBoot as bootloader.
    >>>>>> At the moment I'm using a board (phyCORE) that has uBoot as bootloader
    >>>>>> pre-load, just to make some attempts and train me in the use of a
    >>>>>> linux-embedded board.
    >>>>>>
    >>>>>> If i try to use my compiled kernel during a NFS boot procedure, the
    >>>>>> system hangs up on "Uncompressing Linux ..... ok, booting the kernel".
    >>>>>> This doesn't happen, obvsiously, when I use the pre-compiled kernel
    >>>>>> for my board.
    >>>>> 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.
    >>>>>
    >>>> 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'.
    >>> 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!
    >>>

    >> 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.

    >
    > 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.
    >
    >> Is it so important the mach type?

    >
    > 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.
    >
    >>>> Could it be the real problem?
    >>>> And what exactly uboot needs to send to the kernel?
    >>> Other way: The kernel must know something about the mach-type it receives
    >>> from u-boot.
    >>>

    >> what do you exactly mean?

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


  9. Re: compiling kernel: redboot and uboot

    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:
    > thank you very much! now it's all clear.
    > your explanation is very useful!
    >
    > I'll make some tests
    >
    > bye
    >
    > Juergen Beisert ha scritto:
    >> AMel wrote:
    >>
    >>> Juergen Beisert ha scritto:
    >>>> AMel wrote:
    >>>>> Juergen Beisert ha scritto:
    >>>>>> AMel wrote:
    >>>>>>> I'm trying to compile a bootable kernel via LTIB for a BSP (ADS by
    >>>>>>> Freescale) that recommends the use of RedBoot as bootloader.
    >>>>>>> At the moment I'm using a board (phyCORE) that has uBoot as
    >>>>>>> bootloader
    >>>>>>> pre-load, just to make some attempts and train me in the use of a
    >>>>>>> linux-embedded board.
    >>>>>>>
    >>>>>>> If i try to use my compiled kernel during a NFS boot procedure, the
    >>>>>>> system hangs up on "Uncompressing Linux ..... ok, booting the
    >>>>>>> kernel".
    >>>>>>> This doesn't happen, obvsiously, when I use the pre-compiled kernel
    >>>>>>> for my board.
    >>>>>> 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.
    >>>>>>
    >>>>> 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'.
    >>>> 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!
    >>>>
    >>> 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.

    >>
    >> 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.
    >>
    >>> Is it so important the mach type?

    >>
    >> 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.
    >>
    >>>>> Could it be the real problem?
    >>>>> And what exactly uboot needs to send to the kernel?
    >>>> Other way: The kernel must know something about the mach-type it
    >>>> receives
    >>>> from u-boot.
    >>>>
    >>> what do you exactly mean?

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


+ Reply to Thread