Custom I.MX6

repoman · ‎01-24-2014

I am currently working on a new hardware platform based on the I.MX6Q. I have been heavily using the reference schematics for the SABRE Platform and a bit of cross referencing to the SABRE Lite designs provided by Freescale.

I am to the point where I am very satisfied with the schematics and will start the layout soon. One thing that I am heavily interested in is being able to customize the Freescale BSP for U-Boot and potentially Yocto to ensure support. I do not mind working through the ins and outs of this process but I am uncertain as to a good starting point. I have enough requisite documentation and have used the SABRE Lite board here to become familiar and comfortable building U Boot and Yocto images, placing on SD cards, and running them. However, I want to ensure that I properly and concisely can build up the supported packages so that they may eventually be supported by the community at large and available for those that would like to use them.

Is there a good reference for building up the customized board support packages/U boot and even potentially adding in a layer/patch to Yocto? My thoughts currently is that I should be able to modify the SABRE platform reference BSP sources (renamed of course) so that the IOMUX settings for the pads of the I.MX6 are correctly configured for the modes that are different. Most of the modes are exactly the same but there are a couple items I wish to breakout on this custom hardware to eventually use (Such as both parallel display interfaces, the MIPI port, and the DSI port along with some added boot utilities such as having two bootable EEPROMs for boot verification - as a short list). I have read through the Freescale documentation about custom BSP which heavily resides on using LTIB. I would eventually like to first be able to run a Yocto built image (thus mentioned here) and believe that some of the hardware BSP information must be required for Yocto but have found very little pointing to the actually references other than the Machine layers. However, I am not as versed in all of this to this point.

Any thoughts, comments, questions would be greatly appreciated and thank you for the time,

John

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

GregDyess · ‎10-21-2014

Check the "Daisychain" for UART1 RX in the IOMUX Tool. That is something often overlooked and is not set automagically by the IOMUX tool.

repoman · ‎06-12-2014

I wanted to update this post. I have completed a new board design and actually have received the Prototypes as of today. This new board is called Aristeus. The main features of the board are a split between the Sabre-Lite and Sabre-SDB.

The form factor of the design is COM Express. I heavily adopted the Type 6 standard because that is something I use at work all the time. There are deviations such as: The PEG port is overloaded to be the multimedia interface for the ARM. All of the PEG lanes are used to bring out CSI0, DISP1, MIPI-CSI, and MIPI-DSI. These are all multimedia oriented items that I am hoping to use with my work (thus the initial project for this board).

This design has the MMPF0100 power system. The RGMII interface is routed to a KSZ9031 instead of the 9021 only because the 9031 is newer. The Design has a 7 port USB2517i Hub interface on the host port. The USB OTG port is dedicated as an output. This should ease the bring up of the board and trouble shooting. There is also a PCI Express switch which enables the signal lane PCI Express from the I.MX6 to attach to potentially several other devices. Most, if not all, of these peripherals will require software support (I know the KSZ9031 is in u boot and I believe the 2517i or maybe a similar one is as well).

Since I received the prototypes, I did spend much time going over the U boot layers prior to even looking at the OS level layers. I wanted to get a "Manufacturing" tool set ready to be able to test these boards. As most projects go, I have not been able to load U boot using either the MfgTool2.exe provided by freescale OR the imx_usb_loader program. What I have been able to do:

- Check the power system. All power appears okay and at the expected voltages (No smoke, no boom... awesome for a prototype)

- The I.MX6Q appears to be somewhat on. The 24MHz and 32.768KHz oscillators are both active and stable.

- The I.MX6Q OTG interface enumerates as the Freescale Semiconductor device which attached in Linux. I have also been able to "see" the device with the two manufacturing tools above.

What is missing: I cannot seem to get any console data from U boot. I have been worried that I missed a boot step or have erred somewhere. The BOOT_MODE pins are configured to perform Internal boot with GPIO overrides. Since the SSTV25 is blank, then the device defaults into the Serial Download mode. I was able to get the MfgTool2 to download the "reference" board files. I know that this occurred because: as the tool cycled, the current on the power supply would spike up, stabilize, come down, and repeat. I probed the DDR3 as well and can see both DDR3 clocks and (what appears to me right now) as randomness on data/address lines. I have not set up a proper test to ensure DDR3. The levels, slew rate, and periodicity of the DDR3 clocks was perfect -- which inherently made me happy. However, the appearance that the core was doing something did not produce any console output. I have so far not determined exactly what is wrong but I have looked at UART1, UART2 and UART3 to find no activity thus far in the interfaces. I know there are some differences into which board uses which interface. The standard boards that the MfgTool2 uses may use a different pin set than my choice (SD3_DATA6 and DATA7 are used for UART1 specifically).

This all leads me to the next piece. What other items can I try to keep moving forward? What have I missed? I have been thinking the last couple hours that it could be boot selection or GPIO pulls. I have added pullups to force the GPIO overrides to select ECSPI1 with CS1. This implementation actually has two boot EEPROMS (both ECSPI1 but different chip selects). I removed one thinking maybe this was causing an issue but had no affect. I may try to find all of the possible UART1/UART3 pin locations and try all of them tomorrow once attempting another round of image downloads.

Is there a better toolsuite for board bringup? I do have DS-5 and a DSTREAM but am waiting on a carrier which has the JTAG header ported out (All of my standard COM Express header's do not have a JTAG implementation (not part of the standard)).

Thanks for the time,

John

LeonardoSandova · ‎01-24-2014

I share two links which may help you at this time:

1 Yocto Project Board Support Package Developer's Guide

This is the official tutorial which explains how to create a Yocto BSP layer.

2. https://github.com/Freescale/meta-fsl-arm-extra

These are the BSP layers for Freescale's ARM base boards. You should understand how things all done on these layers, so you can replicate on your own.

repoman · ‎01-24-2014

Thanks for the links. I had found the Yocto Project Board Support Package guide but was uncertain as to exactly where to find the machine layer. I will experiment with adding a custom machine and ensure it builds (probably by replicating the current one for my SABRE Lite board) and make sure all is well.

Thank you again.

Custom I.MX6

Custom I.MX6

i.MX6_All

i.MX6Quad

Yocto Project