I own an IGEPv2 Rev.C board which is a Texas Instrument OMAP3 DM3730 ARM embedded platform very similar to the Beagleboard-MX board but with more peripherals and a 512 NAND flash memory. This board is part of a family of embedded boards known as IGEP-based boards (another popular board from this family is the IGEP COM module).
IGEP’s manufacturer (ISEE) provides a very complete SDK and documentation on how to build a bootable image for the device and use all its features. The SDK is composed of an custom boot-loader (based on TI x-loader and u-boot), a custom kernel (based on v2.6.37 kernel from TI’s arago project), the Linaro ARM cross-toolchain and a root file system with all the necessary software and example code on how to make the best use of the board features. This makes the IGEPv2 a really competitive platform for embedded DIY projects.
Probably ISEE has its reasons to ship a custom kernel and boot-loader instead of their mainline counterparts but I (being a FOSS hacker) wanted to use upstream software on my board. So I started yet another hobby project to do on my (lately very scarce) free time to hack the kernel and u-boot and make them able to boot my IGEPv2 Rev.C board.
Fortunately, ISEE engineers have been pushing support for their IGEP board family to the mainline Linux kernel even though this kernel is not supported by their company. They do this on their free time because they understand the benefits of having their code as close as upstream as possible thus minimizing the size of the patch-set they need to carry on and forward port every time they move to a newer kernel release. But since they do on their spare time, it usually doesn’t support the latest version of their boards (such as the latest IGEPv2 Rev.C I own).
Also, ISEE used to ship u-boot as the IGEP family boot-loader before developing their own boot-loader (igep-x-loader). So it turned out that I only needed to add a few patches to the upstream kernel and u-boot to make them work with my board.
The first issue I had is that previous IGEP boards came with an OneNAND flash memory while newer boards use a NAND flash memory. So the first patch to the kernel was to to give NAND support to the IGEP. With this patch I was able to boot an upstream kernel using ISEE’s custom boot-loader.
The next step was to add the needed support to u-boot. This was a little more complicated since ISEE has not used u-boot for a while and u-boot has added recently a major feature which eliminates the need of a first stage loader (such as TI’s x-loader). Now u-boot has a framework known as SPL (Second Program Loader) that uses the same code base to generate both the first stage and second stage boot-loaders.
So, besides adding NAND support and a compile config option to choose the flash memory type to be used on an IGEP board I added SPL support for IGEP boards and updated the IGEP default kernel command line arguments to use the OMAP-specific serial driver and the EXT4 file system
With these patches my board booted with mainline u-boot and kernel but I found an issue on the IGEP kernel platform code that assumed the boot-loader would set the OMAP mux pin connected to the LAN9221i ethernet chip IRQ line as GPIO input mode (which was true with igep-x-loader but not with u-boot anymore). This should be made on the kernel anyways so the fix was just a trivial one-liner patch to the kernel.
All these patches are upstream now, so to test it just use the latest v3.6-rc4 kernel from Linus and u-boot master branch (git://git.denx.de/u-boot.git).
I had a lot of fun hacking this and my next step is to migrate the IGEP platform code to device trees. So, if anyone else owns an IGEPv2 or an IGEP COM module and is interested on using mainline software instead of ISEE custom one, please contact me so we can share the efforts 🙂
Pingback: Device Tree support for IGEPv2 (and IGEP COM Module) | Blog | Javier Martinez Canillas
I want to use u-boot and a version 3 kernel with an SD card. I build u-boot and copied MLO and u-boot.img to an SD card. I also placed a kernel image (v3.7) on the boot partition but the board doesn’t boot. The only thing I see in putty is:
U-Boot SPL 2014.04-rc1-00235-g3290733 (Mar 07 2014 – 12:37:09)
SPL: Please implement spl_start_uboot() for your board
SPL: Direct Linux boot not active!
U-Boot 2014.04-rc1-00235-g3290733 (Mar 07 2014 – 12:37:09)
OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz
IGEPv2 + LPDDR/NAND
DRAM: 512 MiB
NAND: 512 MiB
MMC: OMAP SD/MMC: 0
Error: Bad compare! failed
Error: Bad compare! failed
Error: Bad compare! failed
NAND read from offset 260000 failed -74
*** Warning – readenv() failed, using default environment
Are you able to provide a bit more information to get the same results as you are getting?
* I used a Samsung 16Gb SD card and Kingston 2Gb card
* I fixed the geometry of the SD card (the kingston)
* I followed the standard procedure to prepare the SD card, first partition type = 0C (FAT32)
* I used boot.cmd and uEnv.txt
* I used the latest version of U-Boot, obtained from GIT
* I used a kernel from http://www.kernel.org
All I see are the lines in my previous comment. I’m a bit stuck. Another thing that troubles me is that IGEP claims that the only proper working kernel is 2.6 while your posts and Enrico’s posts also indicate that newer versions are working.
Issue was solved in u-boot-arm and not in u-boot, the version I am using. A patch written by Enrico on the 25th of januari solved the problem, here is the url:
Sorry for the late response, I completely missed your comments.
I’m glad that you found the fix from Enric, it should land in mainline soon.
I’m not sure if you received my reply but I am missing it here.
I’m using u-boot-arm 2014-rc2 and Linux 3.14. When booting the board, there is no output via DVI. Are you having the same problem?
Hello Freddy, sorry for the late response but I don’t get notifications when a comment is added to the blog.
You should better post your questions to email@example.com and cc me (javier at dowhile0 dot org).
For DVI output I think you are missing the following patch-set that correctly sets the display PLL clock rates: