I.MX6Q Custom Board and Freescale SDK 1.1

repoman · ‎06-16-2014

I wanted to add another update to this thread. I have been working on the software for this new board as I think that is the only problem I have been having.

As an aside: I spent this weekend following several guides found on the web that pertained to building the arm-none-eabi- toolchains. However, it seems that there is an issue with an assembly file, Trap.S, when building newlib-1.17 or later? It may have been a build issue or other problem. I don't know. I was able to build the arm-none-eabi toolchain using the standard gcc tools (specifically 4.6.4). However, the Freescale build SDK could not seem to find assert.h which is probably in the newlib which I couldn't get to build? I decided to move back to code sourcery. My experiment in building the tools started with the issues I posted on Friday where the prototype boards "seemed" to run (i.e.: current draw changed when loading binaries using the manufacturer tool but I never had console.

I decided to move to Code Sourcery (specifically 4.7.2 (Sourcery CodeBench Lite 2012.09-63). There is probably a newer version but this one is specifically called out in the Freescale 1.1 SDK. I then spent some of the weekend creating a project in the Freescale SDK which could be built and run on the custom board.

My process:

Step 1: Read all of the associated guides. The detailed level of reading is minimal as long as you follow the broad swaths

Step 2: In the "iMX6_Platform_SDK/board/mx6dq/", create a directory <my board> for use.

Step 3: Start with or directly implement an iomux output using the "iMX6_Platform_SDK/tools/windows/iomux/iomux.exe". (I am running a Windows 7 machine with an Ubuntu 12.04 VM)

Step 3.1: After porting in the nuance details of the hardware design, generate the associated code. The Design file for the iomux is going to be a *.xml. The iomux tool then generates an iomux_config.h and a rev_a_iomux folder with the intricacies to program the board through the SDK.

Step 4: I copied the DCD.c and the Makefile from the smart_device folder. I did this because I used the references from Freescale in the design of this board.

Step 5: Work through all of the compilation errors of ./tools/build_sdk -target mx6dq -board <my board>

Issues I corrected:

Step 5.1: [brute force] In hardware_modules.c, change the debug ports to the one that is on your board. For my custom board, I modified them to UART1 as I chose this as the debug interface. The board actually outputs UART1, UART2, and UART3.

Step 5.2: In sdk/drivers/board_id.h, Add to the section where board declarations occur

#elif defined (BOARD_<my board>)

#define BOARD_TYPE BOARD_TYPE_<my board>

#else

This will help to register your board in the SDK

Step 5.3: In sdk/drivers/src/board_id.c, modify the function board_name switch statement to use your board and 'print' a name. This will show up in the terminal SDK output (Otherwise it will say unknown).

Step 5.4: In apps/obds/, I modified the Makefile to remove the src/tests/gpio_led.c and src/test/gps_test.c. This board has neither an LED to a GPIO nor a GPS module. This allowed me to bypass several errors (warnings really) that occurred in the build process.

Step 5.5: In /tools/build_sdk, add a field under valid_builds to be able to "register" your board in the structure. This is important as build_sdk won't know your board otherwise!

Step 5.6: Under the # Board area of config.mk (/mk/config.mk), follow the convention and add a -DBOARD_<myboard> with the else ifeq structure and then define the board as well.

Note: I may have made a couple other modifications but I am pretty certain that is it.

Step 6: Run ./tools/build_sdk -target mx6dq -board <my board> and let the whole area complete.

After getting through the SDK update, I ended up with output/mx6dq and a bunch of folders including the sdk_unit_test folder. In this folder, there is a subfolder with myboard and rev number. In that folder, there are several files including sdk_unit_test_ALL.bin. This binary file is the culmination of all of the SDK tests and is now build for my custom board.

Per the Manufacturing Tool v2 from Freescale, I then modified the way the manufacturing tool worked to allow for a new command set to program my board (at least initially).

I modified ucl2.xml by adding (this roughly can be found on page 8 of the README for the manufacturing tool):

<CMD state="BootStrap" type="boot" body="Recovery" file="sdk_unit_test_ALL.bin">Loading

SDK image</CMD>

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

<!--

-->

</LIST>

I then modified the cfg.ini to use the name = DWLD_IN_SDP. Then I turned my board on, the board attached to my machine as the SDP loader. In windows it shows up as a HID compliant device. In linux (if you attach it to the VM), it shows up as the in the Freescale Semiconductor Recovery mode with the mx6DQ VID and PID using lsusb.

I then launched the MfgTool2.exe found in the Mfgtools-Rel-4.1.0_130816_MX6Q_UPDATED. I had to work through some issues getting the ucl2.xml and the cfg.ini to play nicely. Specifically, the README doesn't include the state= parameter on each line. I am assuming that v1 didn't need this but v2 definitely does! I then hit start and the code was loaded.

On my serial terminal I then received:

**************************************************************************<CR><LF>

Platform SDK (1.1) for MX6DQ TO1.2 Aristeus rev. A<CR><LF>

Build: Jun 16 2014, 10:49:51<CR><LF>

**************************************************************************<CR><LF>

========== Clock frequencies ===========<CR><LF>

CPU: 792000 kHz<CR><LF>

DDR: 528000 kHz<CR><LF>

IPG: 66000 kHz<CR><LF>

Debug UART: 80000000 Hz<CR><LF>

========================================<CR><LF>

SDK Unit Tests<CR><LF>

--------------<CR><LF>

<ESC>[01m<ESC>[35mt<ESC>[00m - tempmon test<CR><LF>

<ESC>[01m<ESC>[35md<ESC>[00m - usdhc test<CR><LF>

<ESC>[01m<ESC>[35mm<ESC>[00m - microseconds timer test<CR><LF>

<ESC>[01m<ESC>[35mwa<ESC>[00m - watchdog test<CR><LF>

<ESC>[01m<ESC>[35mo<ESC>[00m - ocotp test<CR><LF>

<ESC>[01m<ESC>[35mwp<ESC>[00m - cpu workpoint test<CR><LF>

<ESC>[01m<ESC>[35mmc<ESC>[00m - multicore test<CR><LF>

Select test to run:<CR><LF>

The control codes turn the characters to a color if in VT100 terminal emulation mode. I am using indigo terminal so the standard terminal just shows the control codes (which I prefer). I believe all of the clock frequency parameters are read from the chip through the hardware interfaces after the DCD programs them (if I have the control flow correctly). I also have DDR3 memory up and running. I can probe the memory and "see" activity; whether valid or not is a holistically different story. On my board, the COM Express as 12V goes from 250mA of draw to roughly 450mA of draw.

The next issue I have: It appears that I can't communicate through the UART1 serial interface after this point. The SDK is presumably waiting on input ("Select test to run:" is usually a prompt right?). The codes to run the tests are

e

g

i

w

s

r

v

t

u

d

c

m

wa

mo

wp

mh

ip

mc

sa

q

I can send characters out. I can see the characters transmitting even with the Oscilloscope. But the I.MX6Q doesn't respond. I am wondering if somewhere have I not configured the SDK in all cases to ensure that the SD3_DATA6 and SD3_DATA7 ports remain in the control of UART1 (this is the configuration on my board)? Or is it running and just not responding because it hung up somewhere else.

Also: The Manufacturing tool doesn't seem to ever go to a completion state and the progress bar never turns from blue to green even though the system has "jumped". During one of the downloads, I added <CMD state="Updater" type="push" body="$ echo Update Complete!">Done</CMD> but have since commented it out as shown above. When I added it, the bar did turn green? But this could have been a fluke... unless this is how the MfgTool "knows" the that physical board has moved on?

The lack of serial communication post the splash message concerns me as probably a software issue? Has anyone out there seen or experienced this issue? Or does anyone have a greater insight into the SDK?

Thanks,
John

repoman · ‎06-17-2014

I found the issue to this.

The IOMux.exe autogenerated code somehow configured the SD3_DATA6 and DATA7 pins to be correct in the file. However, the Daisy Chain hardware descriptor for the receive channel was setup wrong (set to the default CSI pin). After finding this, the whole SDK work s properly.

I have seen been attempting to port U boot over. I have successfully ported it over to the point that everything compiles. I am able to use the Mfg V2 Tool provided by Freescale to load the U boot but either the device or the tool is continuously resetting?

I am leaning to the device resetting. I downloaded the latest u boot from git to start with. The earlier version on an earlier VM was lost due to the VM being gone. But I had backed up where I had left off with Aristeus.

U-Boot 2014.07-rc3-00068-gd8a97f9-dirty (Jun 17 2014 - 16:22:32)

CPU: Freescale i.MX6Q rev1.2 at 792 MHz

Reset cause: POR

Board: Aristeus

I2C: ready

DRAM: 1 GiB

Board Init Called

MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2

SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB

*** Warning - bad CRC, using default environment

No panel detected: default to HDMI

Display: HDMI (1024x768)

In: serial

Out: serial

Err: serial

Net: Board eth init called

I modified a few lines in the u boot code to pipe out the message "Board Init Called" and "Board eth init called". I did this to try and determine where the hang/reset is occuring? After the Net: prints from the u boot software, the system reboot. As I said, I don't know that this is u boot failing and restarting or if the manufacturing tool is doing this because the manufacturing tool never goes "green" and indicated a success even though I am starting to get terminal output.

By the way: The Freescale 1.1 SDK runs completely fine and does not re boot. I have run all of the tests in the SDK successfully. I even ran the stream benchmark utility which completed and said that everything verified successfully (may be a default message but the source code shows many messages as possible and only one is the success).

Any thoughts from the Community at large as to how to continue with the U boot progression? Could this be DDR3 initialization? Or could it be external device initialization? Especially since it appears to be at the network. I have connected the RGMII to a KSZ9031 and updated the U boot firmware to attempt to use the KSZ9031. I have also tried to remove the Ethernet support entirely to see if u boot would not continue but it still seems to call board_eth_init(bd_t *bis) from somewhere but I have not found where. I have been trying to trace back to the outputs but am getting bogged down since I am by no means a U boot Guru.

Thanks for reading my stumbling through this process,

John

alejandrolozan1 · ‎06-24-2014

Hi,

Which changes did you perform to remove the ethernet support?

The mfgtool saves U-boot in the SD. Have you checked the log of mfgtool to see what the error is?

Best Regards,

Alejandro

repoman · ‎06-30-2014

Alejandro,

I'm using the main line U boot directly. If you are building U boot, you can remove the:

CONFIG_FEC_MXC

CONFIG_CMD_NET

CONFIG_CMD_MII

CONFIG_CMD_DHCP

CONFIG_CMD_PING

and any other related items for the Ethernet. This will disable the use and bringup of the Ethernet. This would be the best way to remove out Ethernet. Luckily, it turned out I hadn't installed gawk on my host machine which was causing a weird build error. Once I installed gawk, then the assembly routine udelay() worked instead of hanging the CPU (which is why I removed Ethernet in the first place).

It was able to check the log but the log is only representative of what is communicated between the tool and the processor and what commands are being executed based on the Profiles\<directory>\OS Firmware\ucl2.xml file.

Hope this helps,

John

I.MX6Q Custom Board and Freescale SDK 1.1

I.MX6Q Custom Board and Freescale SDK 1.1

i.MX6Quad