Search

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 30 Mar 2008 08:07 PM by  peter.barada@logicpd.com
iMX31 without MC13783 can't uncompress Linux kernel
 7 Replies
Sort:
You are not authorized to post a reply.
Author Messages
serkam
New Member
New Member
Posts:


--
11 Mar 2008 06:47 PM
    Dear Sirs

    We finished a board with iMX31LC ( BGA 0.8mm ), based 100% in the Litekit, but, without MC13783 ( companion chip ). In its place we designed a voltage sequencer using a Pic18F2321, LDOs and MOSFETs to switch the several voltages in proper sequence, as recommended by Freescale.

    For a while we are using the LogicLoader to debug the hardware and apparently, all things are going well.

    The board is stable, the LoLo runs stable, and I can run several routines for hardware tests without rangs.

    But, when I try to load Linux ( that runs perfectly in Litekit ), sistematically, a CRC error occurs when uncompressing the kernel.

    This is not a DDR RAM problem because I did several tests for memory integrity ( sequential, random, loops ), and all tests was done without a single error.

    Somebody can advise me about on what is happening?

    Perhaps some inputs of iMX31 that were connected to MC13783 and now left floating could induce these CRC errors?

    Any help will welcome.

    Thanks.
    peter.barada@logicpd.com
    New Member
    New Member
    Posts:72


    --
    13 Mar 2008 09:01 AM
    Where are you loading zImage to? If its too low in memory, then the uncompressed output will overlap the compressed data and CRC errors will occur.

    I load mine up at 0x80800000 and it fires up fine...
    serkam
    New Member
    New Member
    Posts:


    --
    13 Mar 2008 05:06 PM
    Peter

    Good evening

    I am loading the zImage at 0x81000000 (DDR RAM). This is the same address used in our 2 Litekits we have. And in both, the Linux loads and runs without problem. The Linux second stage loader ( loader.elf ) is running at 0x800d0000 ( exec entry point 0x800d03a8 ).

    What is strange is the fact that LoLo is running smoothly in our board ( at least apparently ). I can use almost all the commands it has. I can run my own routines without problem.

    As we did all possible tests in the hardware, we are wondering if the Logic Loader is impacting with the absence of MC13783 ( companion chip ) that in our board doesn't exist, when loading Linux. I saw that the LOADER.ELF uses the environment settled by LoLo ( such DDR initialization, for example ), as it do nothing about hardware setting. So, is it possible that something was not settled inside iMX31? I mean, as the LoLo is a kind of RTOS, it could be in a loop waiting for a response from MC13783 ( that doesn't exist in our board ) and the rest of initialization routine was not completed. ( I know, I know, I am travelling in warp space, but, in actual stage, looping for weeks around this issue, we started hunting ghosts... ).

    Anyway, thanks for your support.

    Best Regards

    Sergio Kamakura
    peter.barada@logicpd.com
    New Member
    New Member
    Posts:72


    --
    13 Mar 2008 08:38 PM
    Which version of LoLo are you using?

    IIRC, LoLo doesn't interact witht he Atlas chip, with voltages set to the Atlas defaults.

    I'll have to dig in the source to be sure.
    serkam
    New Member
    New Member
    Posts:


    --
    14 Mar 2008 03:28 PM
    Hi Peter

    Good afternoon.

    I am using 2.3.5p2 (11/21/2007) LoLo version. We upgraded our both Litekits to this version also.

    One curious situation occurred: if I execute my memory test routine using EXEC, my routine runs very slowly. If I execute it using JUMP, it executes in normal velocity, and apparently, the LoLo continues executing in background, as the 2 LEDs continues blinking in the nominal speed. In both cases, the USART1 can be used normally at 115.200 bps, so the PLL wasn't modified. Curious, isn't?

    Best Regards

    Sergio Kamakura
    bvmagaldi
    New Member
    New Member
    Posts:


    --
    30 Mar 2008 01:39 PM
    Hi Sergio,

    It's good to find other brazilians here, specially from Sao Paulo.

    Did you try to use LoLo 2.4.0 to boot your kernel? It seems the newer version have support for exec -t option, and this exclude the need for a second stage bootloader.
    Witch kernel version are you using ? And with what patch ? Could you post your error log here, so we could try to help you find a answer for the problem.
    You could also try to disable PMIC driver and MXC power management support in the kernel (I'm using 2.6.19.2 with Daniel's patch).

    Best Regards

    Bruno V. Magaldi
    --
    LabDev
    tombrus
    New Member
    New Member
    Posts:


    --
    30 Mar 2008 02:14 PM
    The difference between exec and jump is that exec switches off all caches and jump leaves them active. This explains the difference in performance you see.
    -Tom
    peter.barada@logicpd.com
    New Member
    New Member
    Posts:72


    --
    30 Mar 2008 08:07 PM
    LoLo 2.4.0 *does* expect to see the Atlas chip since the Atlas chip, out of reset, uses max core voltage which causes the i.MX31 to "degrade" which reduces its life. Hence LoLo on strartu will pull the voltage down to a "long life" level.

    As a result, you'll have trouble using it on a board that does not have the Atlas chip on CSPI2. I'm not sure how LoLo reacts to not having an Atals chip attached. Possible it may abort, leaving you with a brick.

    tombrus is indeed correct that exec shuts off caches, mmu, and interrupts before it "execs" the application wherase "jump" does not.

    "exec" is more intened to load an application/OS that takes over the world. It was booting Linux kernels that causes probelsm if MMU/cache or interrupts weren't properly disabled.
    You are not authorized to post a reply.