Assistance appreciated with bringing up a new board

[dubravkomoravsk]

Hello,

We've made a new board with i.MX6 Solo CPU. We think all power supplies are good. USB OTG works and Mfg Tool "sees" the board. Memory calibration tool worked well and repeated memory stress tests showed no errors.

My problems is that I can't get mfg u-boot to show anything, any signs of activity. As far as I can say, I've made it in accordance with all Freescale's documentation. DCD table contains DDR3 initialization with values copy & pasted from Excel tool + added values from calibration. I've also added initialization of clocks, again from Excel tool. In board-specific initialization, I just configure single UART for debug printouts.

When downloading u-boot, Mfg Tool just shows "Loading u-boot" message indefinitely. If I close it, the process remains hanging and I must kill with Windows Task Manager.

If I don't use my u-boot but instead use for example u-boot-mx6q-sabresd.bin, then CPU appears to load boot, Mfg Tool downloads kernel and RAM filesystem and then hangs while jumping to kernel (almost certainly because this boot doesn't have proper DDR initialization for my board and almost certainly there is actually no meaningful contents in RAM). But this u-boot at least partially works, while mine doesn't work at all.

How can I debug the problem? Thanks in advance for any reply.

---------------------------------------------

Here is relevant contents from my ucl2.xml file. I'd like to use the usual combination, SPI flash for boot and soldered MMC for kernel and file system.

<UCL>

  <CFG>

    <STATE name="BootStrap" dev="MX6Q" vid="15A2" pid="0061"/>

    <STATE name="Updater"   dev="MSC" vid="066F" pid="37FF"/>

  </CFG>

  <LIST name="u-boot only" desc="Choose SPI and eMMC as media">

    <!--CMD state="BootStrap" type="boot" body="BootStrap" file ="u-boot-mx6q-sabresd.bin" >Loading U-boot</CMD-->

    <CMD state="BootStrap" type="boot" body="BootStrap" file ="u-boot.bin" >Loading U-boot</CMD>

    <CMD state="BootStrap" type="load" file="uImage" address="0x10800000"

      loadSection="OTH" setSection="OTH" HasFlashHeader="FALSE" >Loading Kernel.</CMD>

    <CMD state="BootStrap" type="load" file="initramfs.cpio.gz.uboot" address="0x10C00000"

      loadSection="OTH" setSection="OTH" HasFlashHeader="FALSE" >Loading Initramfs.</CMD>

    <CMD state="BootStrap" type="jump" > Jumping to OS image. </CMD>

    <CMD state="Updater" type="push" body="mknod class/mtd,mtd0,/dev/mtd0"/>

    <CMD state="Updater" type="push" body="mknod block,mtdblock0,/dev/mtdblock0,block"/>

    <CMD state="Updater" type="push" body="$ flash_eraseall -j /dev/mtd0">Erasing Boot partition</CMD>

    <CMD state="Updater" type="push" body="send" file="files/u-boot.bin">Sending U-Boot</CMD>

    <CMD state="Updater" type="push" body="$ dd if=$FILE of=/dev/mtdblock0 bs=512 seek=2 skip=2">write U-Boot to SPI-NOR</CMD>

-------------------------

As instructed by documentation, I've added this to my board header file:

	#define CONFIG_MFG
	#define CONFIG_CMDLINE_TAG
	#define CONFIG_REVISION_TAG
	#define CONFIG_SETUP_MEMORY_TAGS
	#define CONFIG_INITRD_TAG
	#define CONFIG_BOOTDELAY 0
	#define CONFIG_BOOTARGS "console=ttymxc0,115200 "\
	"rdinit=/linuxrc"
	#define CONFIG_BOOTCOMMAND	"bootm 0x10800000 0x10c00000"
	//; 0x10800000 is the load address of the kernel image. It neesd to be changed according to your specific platform memory configuration.
	//; 0x10c00000 is the initrd address. It needs to be changed according to your specific platform memory configuration.
	#define CONFIG_ENV_IS_NOWHERE 1 //;avoid reading U-Boot command from storage.

... and I also have this:

#define CONFIG_ARMV7    /* This is armv7 Cortex-A9 CPU core */

#define CONFIG_MXC

//#define CONFIG_MX6SL

//#define CONFIG_MX6SL_ARM2

#define CONFIG_MX6DL    // SOLO

#define CONFIG_MX6SOLO_DDR3

#define CONFIG_FLASH_HEADER

#define CONFIG_FLASH_HEADER_OFFSET 0x400

#define CONFIG_MX6_CLK32       32768

[dubravkomoravsk]

I've made some progress. Boot works and jumps to kernel. uImage uncompresses, starts executing code but stops (crashes?) in:

~/Documents/ltib/rpm/BUILD/linux-3.0.35/arch/arm/kernel/head.S, stext routine, line:

ARM( add pc, r10, #PROCINFO_INITFUNC )

Any hint what should I check?

Serial terminal works, I see printouts from u-boot and I can send commands to it. uImage and initram file systems are reported to be ok. Last printout is about kernel being decompressed and started, then nothing. I know the precise place the code stops working through toggling LEDs over GPIO pins. CONFIG_DEBUG_LL is enabled, but it doesn't seem to do anything.

----------

Edit 25.08.2014.

Managed to get to head.S, __turn_mmu_on:

mcr    p15, 0, r0, c1, c0, 0

@ write control reg

After that it dies, or it doesn't die right here but memory gets remapped in a way that prevents me from getting any output. Serial console still works in boot, but not in kernel.

[Yuri]

It makes sense - first - to debug new U-boot using JTAG.

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[dubravkomoravsk]

Another experiment I did was trying to toggle a LED connected to GPIO2-0. (The LED is not connected directly, but with adequate buffer/driver IC.) I've replaced the first four entries of DCD table with:

// GPIO2-0 to pad A18, mode Alt5

MXC_DCD_ITEM(1,    0x020E0284,    0x00000005)

// nothing special in pad configuration, tried with 100k pull up...

MXC_DCD_ITEM(2,    0x020E066C,    0x0001B0B0) // 100k pu

// ... and 100k pull down, no difference in behavior

//MXC_DCD_ITEM(2,    0x020E066C,    0x000130B0) // 100k pd

// set direction of pin0 to output

MXC_DCD_ITEM(3,    GPIO2_BASE_ADDR+4,    0x00000001)

// set value of pin0 to 0, nothing happens

MXC_DCD_ITEM(4,    GPIO2_BASE_ADDR,    0x00000000)

// ... or 1, nothing happens

//MXC_DCD_ITEM(4,    GPIO2_BASE_ADDR,    0x00000001)

Does this means that even the DCD table isn't executed? Why then doesn't Mfg Tool receive some error status from CPU, but instead becomes blocked? Or I have an issue somewhere in boot code even before DCD table gets executed (how do I fix that then, as I've made no changes in startup assembly code and standard libraries)?

[Yuri]

  Looks like GPIO module is not allowed in the DCD. Please refer to Table 8-37
(Valid DCD Address Ranges) of the i.MX6 DQ Reference Manual.

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[dubravkomoravsk]

Indeed, I've missed that, thanks.

I've made some progress, I am getting some code from boot to execute. It looks like 'printf' kills it, but I may have called it too early.

Dubravko