Using U-boot as MQX bootloader

[tfe]

I am attempting to boot MQX using U-boot, and I was hoping it would be something as straightforward as using the "go" command in U-boot. Unfornunately that is not the case. Here's my output:

U-Boot 2015.04-dirty (May 19 2015 - 13:00:05)  CPU:   Freescale Vybrid VF610 at 396 MHz Reset cause: EXTERNAL RESET Board: vf610twr I2C:   ready DRAM:  128 MiB WARNING: Caches not enabled NAND:  256 MiB MMC:   FSL_SDHC: 0 In:    serial Out:   serial Err:   serial Net:   FEC Error: FEC address not set.  Hit any key to stop autoboot:  0  switch to partitions #0, OK mmc0 is current device 91608 bytes read in 67 ms (1.3 MiB/s) ## Starting application at 0x80000000 ...

And then it just hangs.

Following is the boot procedure:

baudrate=115200 => load mmc 0:1 $loadaddr /mqxapp.bin 91608 bytes read in 68 ms (1.3 MiB/s) => echo $loadaddr 0x80000000 => go $loadaddr ## Starting application at 0x80000000 ...

"mqxapp.bin" is produced using fromelf and is based the "hello2" example project found in "[MQX_ROOT]/mqx/examples":

fromelf --bincombined --fpu=vfpv4 --output=mqxapp.bin hello2_twrvf65gs10_a5.axf

The build target is "DDR Release" using "ddr.scf" provided with the VF610twr BSP:

#define CODE_BASE_ADDR_START    0x80000000 #define CODE_BASE_ADDR_END      0x800ffff0 #define CODE_SIZE               (CODE_BASE_ADDR_END - CODE_BASE_ADDR_START)  #define DATA_BASE_ADDR_START    0x80100000 #define DATA_BASE_ADDR_END      0x87fffff0 #define DATA_SIZE               (DATA_BASE_ADDR_END - DATA_BASE_ADDR_START)

I imagine that the provided scatter file ("ddr.scf") is not suitable to be used with U-boot, and I cannot seem to find any relevant documentation that explain this process in detail. Does anyone have some pointers on how to boot MQX using U-boot on Vybrid?

​EDIT: ​Formatting and spelling.

[jackblather]

You may want to first try to run the MQX program in the onchip RAM (OCRAM) which is at 0x3f00_0000 to 0x3f07_ffff. This will eliminate any DDR3 configuration issues.

I don't know if your "fromelf" command is correct or not, but here is what I use: fromelf --bin --output=<.bin output file> <.axf file produced by linker>

Also, remove the "--fpu" option to eliminate FPU setup issues, too.

One more thing, your load address and boot address are probably going to have be different. Look in the linker output map file (mapfile.map?) to see where the boot address is. If you're using GCC/DS-5, it's labeled "Image Entry Point". In my project it's at 0x3f000485. If you are executing out of DDR3, will be something like 0x80000485. This may very well be your entire problem - wrong jump-to address.

[tfe]

Thank you for your response.

I see from "mapfile.txt" that the Image Entry Point is 0x80000000, but when attempting to load MQX from this location, execution freezes after "## Starting application at 0x80000000 ...".

Doing the same for OCRAM produce the same result.

I should also note that I made the changes you mentioned in the "fromelf"-command, but yielding little result.

[jackblather]

Can you single-step using a debugger? Do you have a debugger that works with your development environment? That would be most helpful.

Does your MQX program have access to a hardware serial port? Will it be able to say "Hello, world!" ?

Can your program turn on an LED or toggle a port that you can monitor with an oscilloscope or voltmeter?

[tfe]

I have previously used DS-5 on Linux for development and an ULINK pro D for debugging. Thus I feel confident the code is sound.

I attempted to load the "hello_world"-project from the Vybrid Sample Code using the procedure above, which seemed to work. The scatter file from "hello_world" does not seem to be compatible with my MQX project. Mimicking the "hello_world" scatter file does not seem to work either.

One of the first things my MQX program does, is to write out a "run"-statement, so using printing or LEDs for debugging might not be viable as I expect that the problem in either MQX init or at program load.

[jackblather]

Are you able to single-step through MQX and find out where it dies?

[tfe]

Corrections: I was finally able to probe MQX when booting using U-Boot. This link mention disabling the DDR init when booting from U-boot, but this is unsuccessful. This leads me suspect that there might be other inits that might cause issues?

Did you have something in mind?

[jackblather]

How far are you able to single-step in MQX? There isn't that much initialization that goes on. You could single-step through the entire thing and see if it actually launches your MQX task. I was wondering if MQX chokes during the init process.

Are you running on a custom board or something off-the-shelf like the Vybrid Tower?

I did not have to bypass the DDR init in U-Boot as I'm running MQX out of the OCRAM. That might be the first step you could try.

[tfe]

I am running on the TWR-VF65GS10 dev-kit.

I am able to step through the init-process without any snags, but it does not seem to enter my main task. Loading the same image onto the target using the ULINKpro D debugger, omitting u-boot, works just fine, but no luck when loading from the SD card.

I was finally able to locate the line where everything snags:

   [ kernel/init_gpio.c:146 ]: SPI0_MCR &= ~((0x3 << 28) | (0x1 << 14)); // DSPI to 0x00 & enables module clock

The ULINKpro debugger list the SPI_MCR registry as unavailable at this line when booting from u-boot.

[jackblather · Accepted solution]

Make sure the SPI0 clock is gated. U-boot does not do this for you. I wonder if the ULINKpro D debugger turns it on for you or something. See the register description for CCM_CCGR0[CG12]. That field is two bits wide. Give it the value of 0x2. Once you do that, hopefully the SPI registers will come alive.

[tfe]

Thank you, this worked perfectly.

For any fellow googlers out there: Attached is a u-boot script that enables all clock gates from the CCM. It needs to be compiled by the mkimage-utility (bundled with u-boot: [u-boot root]/tools/mkimage) using the following command:

  export MKIMAGE=[u-boot root]/tools/mkimage

  $MKIMAGE -A arm -O u-boot -T script -C none -a 0 -e 0 -d ./prep.uboot ./prep.script

It can then be executed using the source-command in u-boot.

[tfe]

Not when booting from U-Boot