This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/DRA726: u-boot crashing issue

Part Number: DRA726
Other Parts Discussed in Thread: TLV320AIC3104

Tool/software: Linux

We have a new board using a DRA726 and I am having some issues with it getting a trap at address 0x40300040

If I disable ICACHE and DCACHE it goes a bit farther. It looks like it traps either in reserve_mmu()

void board_init_r(gd_t *dummy1, ulong dummy2)
{
    int i;

    debug(">>spl:board_init_r()\n");
    gd->bd = &bdata;

#if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF)) && \
        defined(CONFIG_ARM)
    dram_init_banksize();
    reserve_mmu();
    enable_caches();
#endif

#if defined(CONFIG_SYS_SPL_MALLOC_START)
    mem_malloc_init(CONFIG_SYS_SPL_MALLOC_START,
            CONFIG_SYS_SPL_MALLOC_SIZE);
    gd->flags |= GD_FLG_FULL_MALLOC_INIT;
#endif

With these disabled it will use a different malloc which fails.

With these disabled I get to this with the debugger, which would looks acceptable, it is not possible to halt u-boot so I cannot go farther

L 2016.05 (Mar 24 2017 - 15:12:29)
DRA722-GP ES2.0
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

and this if I run with the micro SD card, it traps at some point with it

U-Boot SPL 2016.05 (Mar 24 2017 - 08:32:14)
DRA722-GP ES2.0
Trying to boot from MMC1


  • Hi Michael,

    I have forwarded your question to an u-boot expert.

    Regards,
    Yordan
  • Michael

    So with disabling I & D CACHE, you are observing u-boot has been loaded by SPL but crashing .

    Can you check your DDR memory configuration. What is the DDR part used ? Is it same as TI-EVM or different ?

    Regards

    Ravi

  • I am working on this with some Engineers from our company division in Sweden. They have an identical hardware as the one I am working with.
    I was told this morning that they went around that problem. There are still some issues as you can see with our partner's message

    "Quite frequently we're getting prefetch_abort traps however. Do you think hardware could be behind this? We can't see where this trap originates from."

    As to your question, the RAM used is from Micron MT41K256M-16TW-107 x 2
    Timing with the automotive EMIF spreadsheet is set for the data rate 13333 with RCD, RP and CL at 13.5
    frequency is 666Mhz. Traces length was entered from the information given by our hardware gus.
    If that is a DRAM problem would it work better at 532Mhz?

    The RAM test passes, it finds all 512MB of RAM. Looking with the memory browser it doesn't seem to have anything that would point to erratic RAM. With the auto refresh I do not see anything going to red

    Michel
  • Funny typo, I don't know what gus means, it was supposed to be Hardware Guy and not Hardware Gus

    Michel
  • Michel

    What is your memory size, whether interleaved or not ? Did you set the DMM LISA map register correctly ?
    Refer to board/ti/dra7xx/evm.c for TI-EVM configuration.

    Since RAM test passed, memory configuration should be ok, but still check with above LISA map register configuration mapped correctly.

    If i understand correctly with I/D cache disabled, with MMC/SD boot you get the below message
    U-Boot SPL 2016.05 (Mar 24 2017 - 08:32:14)
    DRA722-GP ES2.0
    Trying to boot from MMC1

    Can you check, whether u-boot is loaded correctly from MMC/SD card to DDR. Use the debug prints and check it got stuck.

    Regards
    Ravi

  • There were several issues with I have resolved

    It turned out that it wasn't able to boot off the microSD card which is what we were trying to do. The QSPI is miswired so I cannot use it until the next revision of the hardware. I had no code in eMMC and didn't know if it was valid. Considering that I had random crashes in u-boot that was hard to test following the training video you have on the beagleboard and TI EVM using the same device (you should have one on the DRA devices)

    I first resolved the booting issue by switching from the u-boot approach you have on the automotive devices to the one used on the Sitara device. It then found my custom device tree. So far so good but at the end I ended up with a deadly crash. Our hardware guy didn't set the DDR correctly (16 bit instead of 32 bits) so it could only see 500MB instead of 1GB but that was not the cause of the crash.

    We first tried disabling the RTC (32khz crystal not populated), that didn't do the trick. I did notice that in u-boot I had to disable LPAE to keep u-boot from crashing 100% of the time. I hadn't done the same thing for the kernel. After disabling that it still crashed and our partners in Sweden removed the mention of RTCSS in the device tree of Linux and the problem went away.

    On the DDR, when I asked the hardware guy to change his settings to 32 bits I was then able to see the full 1GB. My system is on Linux and do not have an excel license for the windows I run on virtualbox so I had to use libreoffice and one of the basic script doesn't work so I have to ask someone else who has excel to run the script. It might be wise to replace the basic script with something better and more secure or double check to make sure it also work with libreoffice.

    I didn't go back to the debugger to see if I still get random crashes. Brad gave some guidance on ways to try to minimize those, I haven't had time to try those.

    Right now the main issue is the misc error message. How do I get rid of this? The new hardware will have the possibility to be populated but not the current hardware.
    I also tried with the industrial kernel from SDK 3.03 with identical results.

    [ 0.330427] ------------[ cut here ]------------
    [ 0.335260] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2523 _init.constprop.23+0x1fc/0x424()
    [ 0.345443] omap_hwmod: rtcss: doesn't have mpu register target base
    [ 0.352051] Modules linked in:
    [ 0.355280] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.45-actia #2
    [ 0.361979] Hardware name: Generic DRA72X (Flattened Device Tree)
    [ 0.368320] Backtrace:
    [ 0.370933] [<c0013b00>] (dump_backtrace) from [<c0013cfc>] (show_stack+0x18/0x1c)
    [ 0.378789] r7:c08cc7ec r6:60000013 r5:00000000 r4:c094088c
    [ 0.384706] [<c0013ce4>] (show_stack) from [<c02b5acc>] (dump_stack+0x8c/0xa0)
    [ 0.392217] [<c02b5a40>] (dump_stack) from [<c0034678>] (warn_slowpath_common+0x88/0xb8)
    [ 0.400604] r7:c08cc7ec r6:000009db r5:00000009 r4:db075e58
    [ 0.406518] [<c00345f0>] (warn_slowpath_common) from [<c00346e0>] (warn_slowpath_fmt+0x38/0x40)
    [ 0.415535] r8:000000ac r7:db18cfc0 r6:00000000 r5:00000000 r4:c07fb820
    [ 0.422521] [<c00346ac>] (warn_slowpath_fmt) from [<c08cc7ec>] (_init.constprop.23+0x1fc/0x424)
    [ 0.431540] r3:c07fd3dc r2:c07fb820
    [ 0.435293] r4:c0921494
    [ 0.437980] [<c08cc5f0>] (_init.constprop.23) from [<c08ccb44>] (__omap_hwmod_setup_all+0x48/0x98)
    [ 0.447263] r10:00000000 r9:c08c0600 r8:000000ac r7:db18cfc0 r6:c09196b0 r5:c091b870
    [ 0.455402] r4:c0921494
    [ 0.458090] [<c08ccafc>] (__omap_hwmod_setup_all) from [<c000988c>] (do_one_initcall+0x98/0x1e4)
    [ 0.467193] r5:c08ccafc r4:c09196b0
    [ 0.470960] [<c00097f4>] (do_one_initcall) from [<c08c0f40>] (kernel_init_freeable+0x1d4/0x268)
    [ 0.479974] r10:00000002 r9:c08c0600 r8:000000ac r7:c08fe820 r6:c090cae4 r5:c096d000
    [ 0.488116] r4:c096d000
    [ 0.490811] [<c08c0d6c>] (kernel_init_freeable) from [<c065d430>] (kernel_init+0x18/0xf4)
    [ 0.499290] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c065d418
    [ 0.507431] r4:c096d000
    [ 0.510123] [<c065d418>] (kernel_init) from [<c000fd18>] (ret_from_fork+0x14/0x3c)
    [ 0.517976] r5:c065d418 r4:00000000
    [ 0.521762] ---[ end trace 519efda632953689 ]---


    Those are handled only by the Cortex M4 and use the IPU1 comm interface.
    [ 0.534944] omap_hwmod: dcan1: _wait_target_disable failed
    [ 0.546997] omap_hwmod: dcan2: _wait_target_disable failed

    I2C1 is connected to the PMIC
    [ 0.599480] omap_hwmod: i2c1: _wait_target_disable failed



    The flooding of GBM error message is also a serious problem and from what Brad is telling me that is not going to be resolved until October. We go in production in May or June. My work around right now is to send the messages in the bit bucket. But I do not get any other message for debugging.
    Those messages, can they be disabled in the weston code or is it the binary blob that sends them?

    Last one would be the sound, the driver crashes.
    Device is TLV320AIC3104
    I2C3 is used

    Is my entry in the device tree correct?

    vdd_3v3: fixedregulator-vdd_3v3 {
    compatible = "regulator-fixed";
    regulator-name = "fixed-vdd-3v3";
    regulator-min-microvolt = <3300000>;
    regulator-max-microvolt = <3300000>;
    regulator-always-on;
    regulator-boot-on;
    };


    tlv320aic3104: tlv320aic3104@18 {
    #sound-dai-cells = <0>;
    compatible = "ti,tlv320aic3104";
    reg = <0x18>;

    assigned-clocks = <&clkoutmux2_clk_mux>;
    assigned-clock-parents = <&sys_clk2_dclk_div>;

    adc-settle-ms = <40>;
    AVDD-supply = <&vdd_3v3>;
    IOVDD-supply = <&vdd_3v3>;
    DRVDD-supply = <&vdd_3v3>;
    DVDD-supply = <&vdd_3v3>;

    status = "okay";
    };


    Michel
  • Hi Michael,

    I suggest you to create new threads for the different issues, so we can assign proper experts and keep track for each of the problems.

    Regards,
    Yordan