Mity CPU Platforms » MitySOM-335x (ARM Cortex-A8 Based Products)

Hi.

The TI SDK works with the MityARM-3359, but you need to replace u-Boot and the Kernel (the mityarm335x_wip branch, currently) with ports from Critical Link in order for it to work correctly. Now, both of these programs are currently based directly off an SDK release from TI, so all of the device driver code and platform code is basically the same as what TI is providing. We are planning to track TI SDK releases periodically to pick up "blessed" patches and kernel upgrades as TI publishes them.

The major differences in u-Boot are in some of the lower level pin-muxing (the SOM is different from the boards from TI), DDR configuration, and PMIC configuration. The u-Boot port will likely not need much attention unless you are planning to boot from something other than NAND or MMC or UART (and eventually ethernet).

For the kernel, we do not require you to install a separate EEPROM with associated ID on your host board (though you may if you so desire), and the initialization code is decoupled from the TI EVM code. We did this because tracking to updates to the SDK is far easier if we can isolate any CL provided code from the TI code, and we wanted better control over how our SOM came up. We also didn't want to deal with potential ID conflicts, etc., with TI assigned numbers and customer (or CL) assigned numbers. We also didn't want to require customers to have to have an EEPROM on their baseboards. That model also tends to start bloating code (the more baseboards you define the more init code you have to continue to add into your source tree, potentially compiling it all into your kernel image). We had hoped to be able to leverage device tree for handling different baseboards/hostboards, but the driver code and platform support code from TI at this time isn't ready for that technique. Perhaps in the future....

The kernel port basically introduces a couple of files in the arch/arm/mach-omap2 directory. One is the board board-mityarm335x.c file, which is basically like the board-am335xevm.c. It configures all of the common SOM stuff that should be consistent between any design using the module (PMIC setup, on board NAND, on board NOR, low level CPU initialization, etc.). It is keyed off the separate MACHINE_ID (registered in the mainline BTW). The second file is the baseboard-mityarm335x-devkit.c. This file represents platform initialization code specific to a given host/baseboard. The idea is that a new baseboard-***.c file would be generated for each new hostboard type. The baseboard-***.c file gets picked up in the Kconfig/Makefile via a "MityARM-335x baseboard" choice option.

Hope this helps....

-Mike

Hey Mike, that helps a lot. One reason I was asking about the EEPROM because we plan to cable a 24-bit LCD/touchscreen into our carrier board and based on the ULCD7 code it seemed like they were relying on the EEPROM to detect the LCD/touchscreen.

I agree that detecting baseboard based on EEPROM may not be the cleanest solution. Looking at the PSP kernel board-am335xevm.c and your baseboard-mityarm335x-devkit.c it looks like both platforms set up the LCD/TSC as platform devices. So according to you we should probably setup our own baseboard-***.c and define platform devices as necessary using evm/mityarm-devkit as a reference?

Thanks,
Ali

Yes,

You should be defining your own baseboard-***.c file if you are making a custom board using the baseboard-mityarm335x-devkit.c as a reference.

-Mike