u-boot not reaching 2nd stage with SD boot

David Kronstein1

My custom DM8148 board is not booting properly from an SD card. I'm using u-boot modified to use UART4 for console, and the board has 4 of MT41J64M16JT-15E (128Mx16) RAM chips. On release of reset, there's a 100ms burst of activity from the SD card, followed by the DDR clock starting (400MHz) and then a burst of activity on the DDR3, followed by nothing. I'm not seeing any output on the UART.

After running the DDR3 init scripts provided for DDR3 leveling, I can use CCS to access the RAM successfully (I can fill with 0s and Fs , and both read back properly), so the RAM appears to be working.

The one difference in SD card connections between my board and the EVM is that I don't have the SD write protect pin connected. Would that make u-boot halt? Does u-boot look at either the SDCD or SDWP pins?

Has anyone else had this problem? How would I go about debugging this?

over 12 years ago

0 David Kronstein1 over 12 years ago

Prodigy 90 points

Just when you give up and ask for help, you make progress...

I tried the stock u-boot, and that seems to work (but the console messages go to UART0 which is used for something else on the board). I modified u-boot by changing the UART base address from 0x48020000 (UART0) to 0x481a8000 (UART4), and changing the pin mux header as needed. It seems this address change causes u-boot to hang. I can go in with a hex editor, modify the stock MLO u-boot file with the new address, and it fails to boot.

I believe I did everything required as indicated in the PSP porting document for changing the u-boot UART, am I missing something?

0 Hongfeng Wang over 12 years ago in reply to David Kronstein1

Genius 3925 points

SDCD matters. If it's not asserted, then uboot thinks there's no card inserted, it will keep printing letter C on the console.
You can hook up a scope to your UART's TX data line, see if there's any activity.

0 BenM over 12 years ago in reply to Hongfeng Wang

Expert 2220 points

SDCD shouldn't matter until the kernel tries to access the SD card (such as when it tries to mount the filesystem if you are running it off the sd card). I believe it polls the sd card in uboot. Have you gone through the DDR software write leveling process? Also, what version of silicon are you using? If you are using newer silicon with older UBOOT it will not know what to do with the new ID and revert to thinking that it is old silicon and then crash.

0 David Kronstein1 over 12 years ago in reply to BenM

Prodigy 90 points

SDCD is connected, it's just SDWP that's not (microSD doesn't have this).

I haven't gone through the write leveling process yet. I tried, but the documentation isn't clear as to where the "console" for the write leveling application actually appears. Is it the console window in CCS? Is it on a UART?

The main problem now seems to be changing the UART for u-boot. It seems to work properly using the default (UART0), but crashes when I change it to use UART4. Is there some difference between UART0's register set and UART4's that requires more than just changing the register address? Is 0x481A8000 the correct address base address for UART4 registers?

Is there a complete checklist of everything required for board bring-up? If I hadn't had these problems, I wouldn't have even known about the write leveling that needs to be done.

I'm using Rev 2.1 silicon.

0 Hongfeng Wang over 12 years ago in reply to David Kronstein1

Genius 3925 points

My DM8148 board also boots from microSD, write protection doesn't matter here, but SDCD does. make sure you have right voltage level, out first version PCB got it wrong so that I had to struggle a couple of days there.

I don't know how you verified factory bootloader is working since you are connected to UART0.

If this is a new board you are trying to bring up, it's probably some hardware difference between your board and EVM need you to change the uboot accordingly. You said you already checked pin mux, I suggest you double check that and your DDR3 configuration. For example, our board connect two DDR3 chips to one DDR interface, while the reference board connect them to both, this requires change of ddr_defs_ti814x.h.

you can also connect JTAG, step through the uboot code, see where it stops.

0 David Kronstein1 over 12 years ago

Prodigy 90 points

After a surprisingly large amount of effort, I was able to get the console (mostly) working
on UART4. There's some garbled data coming through when the kernel prints out the
info on which UARTS are available, but it works well enough.

Adventures in changing the u-boot UART

Changing UART in u-boot 1st stage


Change the UART base address per PSP porting guide
If using uart 4/5/6, PRCM registers need to be set to turn the UART on (u-boot only powers
up UART 0/1/2) Not doing this causes u-boot to hang.

Clock source register needs to be set to get the right clock frequency. Not doing this
causes uart to run at 4x speed (default clock is 192MHz instead of desired 48MHz)

in board/ti/ti8148/evm.c per_clocks_enable() add the following code. This is for
UART4, if other, change the CM_ALWON... define appropriately. Check the TRM
for which bitfield needs to be set in McBSP_UART_CLKSRC based on which
UART you're using

    __raw_writel((0x1 << 5), McBSP_UART_CLKSRC);
    while(__raw_readl(McBSP_UART_CLKSRC) != (0x1 << 5));    //Set UART4 clock source to 48MHz


    __raw_writel(0x2, CM_ALWON_UART_4_CLKCTRL);
    while(__raw_readl(CM_ALWON_UART_4_CLKCTRL) != 0x2);    //Added UART4 power on

The define for CM_ALWON_UART_4_CLKCTRL needs to be added to
include/asm/arch/cpu.h. Add the following lines to cpu.h:

#define CM_ALWON_UART_3_CLKCTRL        (PRCM_BASE + 0x1580)
#define CM_ALWON_UART_4_CLKCTRL        (PRCM_BASE + 0x1584)
#define CM_ALWON_UART_5_CLKCTRL        (PRCM_BASE + 0x1588)

Changing UART in u-boot 2nd stage

This depends on the pin mux (you may or may not need to modify anything), but for UART4
on EMAC pins, cpsw_pad_config() would change pin mux disabling the UART4 pins which
are on EMAC1 RGMII pins.

In board/ti/ti8148/evm.c cpsw_pad_config(), comment out lines like the following which
refer to rgmii1 (not used in my application)

        val = PAD258_CNTRL; /*rgmii1_rxd[2]*/
        PAD258_CNTRL = (volatile unsigned int) (BIT(18) | BIT(0));


Changing UART for low-level linux kernel messages

Follow the procedure in PSP porting guide. When modifying uncompress.h, the provided
DEBUG_LL_TI81XX definition doesn't work for UART4/5/6. Add a new definition

#define DEBUG_LL_TI814X(p, mach)                    \
    _DEBUG_LL_ENTRY(mach, TI814X_UART##p##_BASE, OMAP_PORT_SHIFT,    \
        TI814XUART##p)

and change the UART definition for the proper port number. Note that the number is 1 more
than the UART ID (ie for UART4, set the value to 5 as shown below

        /* TI8148 base boards using UART1 */
        DEBUG_LL_TI814X(5, ti8148evm);


For UART 4/5/6, arch/arm/mach-omap2/include/mach/debug-macro.S needs to be modified
to work, otherwise the UART value passed from uncompress.h will not be recognized, and
the kernel will hang.

At line 75 add
        cmp    \rp, #TI814XUART4    @ ti814x UART offsets different
        beq    84f            @ configure UART4
        cmp    \rp, #TI814XUART5    @ ti814x UART offsets different
        beq    85f            @ configure UART5
        cmp    \rp, #TI814XUART6    @ ti814x UART offsets different
        beq    86f            @ configure UART6

and at (now) line 109 add
84:        ldr    \rp, =UART_OFFSET(TI814X_UART4_BASE)
        b    98f
85:        ldr    \rp, =UART_OFFSET(TI814X_UART5_BASE)
        b    98f
86:        ldr    \rp, =UART_OFFSET(TI814X_UART6_BASE)
        b    98f

Processors

Processors forum

u-boot not reaching 2nd stage with SD boot

Adventures in changing the u-boot UART