[LS1043A] Custom board bring-up: Processor hangs and DDR3L

[mike_palmer]

Processor is a PLS1043AXE7QQB.

SDRAM is two (2) Alliance Memory AS4C512M16D3LA-10BIN DDR3L 8Gb DDR3L on CS0 in a 32-bit configuration.

We are using the LSDK 20.04 and have successfully built bl2.pbl and fip.bin and burned a uSD. The LS1043 is booting from the SD card but seems to crash at the stage where BL31 is to be loaded.

We've added debug messages (NOTICE, INFO etc) and see that the processor makes it to the call to dev->funcs->dev_init() in io_dev_init() where it seems to crash:

int io_dev_init(uintptr_t dev_handle, const uintptr_t init_params)
{
    int result = 0;

    assert(dev_handle != (uintptr_t)NULL);
    assert(is_valid_dev(dev_handle));
    io_dev_info_t *dev = (io_dev_info_t *)dev_handle;

    /* Absence of registered function implies NOP here */
    if (dev->funcs->dev_init != NULL) 
    { 
        result = dev->funcs->dev_init(dev, init_params); //<-- crashes here

        NOTICE( "io_dev_init(): dev->funcs->dev_init(...) returned (%i)\n", result );  
    }
	return result;
}

The crash is weird: After executing that line the debug messages show the processor is back in plat_get_image_source() but image_id is now '0' instead of '3'. When it reaches the end of this instance of plat_get_image_source() the processor seems to simply stop and hang. I suspect this is caused by something like a stack corruption given how it mysteriously ends up back in plat_get_image_source after attempting the device IO initialization.

Something else that is probably related is that we don't seem to be able to access any DDR address without the processor similarly hanging. So a bit of code such as:

void bl2_main( void )
{
    entry_point_info_t *next_bl_ep_info;
    NOTICE( "BL2: %s\n", version_string );
    NOTICE( "BL2: %s\n\n", build_message );

#if 1
    /* insert DDR read */
    printf( "DDR read attempt...\n );
    unsigned long val = ddr_in32( (uintptr_t *)0x82000000 );
    printf( "DDR val: %lx\n", val );
#endif
.
.
.

results in "DDR read attempt..." being printed to the console and then nothing.

It doesn't matter where in BL2 I place this, I get the same result. It feels like an access violation/exception but I didn't think the u-boot location in DDR was secure. It doesn't matter where in the DDR address space we attempt to access, the processor hangs each time. As the DDR registers are written in board_static_ddr() in ddr_init.c I assume the setup should be complete so attempting to use DDR in the early stages of bl2_main() should be okay. Or am I wrong?

I can successfully use this method to read and display OCRAM contents.

Of course it's possible we have a DDR controller initialization problem: Our bring up code is based on the LS1043ARDB code with ddr_init.c, platform_def.h and the RCW files modified for our use case. CONFIG_STATIC_DDR is defined, we've updated the static_1600 structure for our DDR3L layout and timing and so the DDR controller should be initialized.

If it was initialized but, say, the timing parameters were not correct I would expect to read DDR locations but get back nonsense. But even attempting to access the memory via pointers results in the processor hanging.

We're doing this blind at the moment as we don't yet have a JTAG TAP dongle or CW. At this point I'm hoping for non-JTAG suggestions -- code snippets, register reads etc -- that can help me verify the state of the DDR controller and whether or not, say, the entire DRAM0 region is privileged or there's some other explanation as to why the processor hangs during such read attempts.

Many thanks.

[mike_palmer]

Thanks ufedor. I've opened a ticket with NXP through our FAE. If I find anything out through that channel I'll update this thread.

[ufedor]

> At this point I'm hoping for non-JTAG suggestions

Sorry, you need to use CodeWarrior QCVS DDR Tool to determine correct settings for the DDR controller registers.

Also it is needed to check the DDR SDRAM connection - please provide corresponding schematics as PDF for inspection.