New Custom AM1802 Board Boot from SD Card

Hi George,

Please go through the below links for how to create a bootable SD card on AM180x processors.

Creating the bootable SD card for AM18xx EVM

http://processors.wiki.ti.com/index.php/GSG:_OMAP-L138_DVEVM_Additional_Procedures#Creating_bootable_SD_card_for_OMAP-L138_EVM_board

I hope you’re familiar with Linux host and tools chain setups for building and flashing U-boot and Linux kernel

Here is the Links

Sitara Linux Software Development guide

http://processors.wiki.ti.com/index.php/Sitara_Linux_Software_Developer%E2%80%99s_Guide

U-boot user guide

http://processors.wiki.ti.com/index.php/AMSDK_u-boot_User%27s_Guide

Create SD Card Script

http://processors.wiki.ti.com/index.php/Sitara_Linux_SDK_create_SD_card_script

AM18x Flash Tool user Guide

http://processors.wiki.ti.com/index.php/AM18x_Flash_Tool_User%27s_Guide

 Regards

Antony

• --------------------------------------------------------------------------------------------------------
  Please click the Verify Answer button on this post if it answers your question.
  --------------------------------------------------------------------------------------------------------

Hi Antony:

Thanks for providing the links all in 1 place. I'm a hardware guy (the software guys are in Europe) so I wanted to verify the board before shipping them the prototypes. I am familiar with Linux Host and compiling but I'm by no means an expert. I do have an Oracle VM running the Davinci-PSP-SDK-03_21_00_04_L138_VM_1 image as well as the Logic EVM so at least I can create the boot card and test on the EVM first (hopefully the SOM has the newer die revision to support SD Card booting).

I see a u-boot.bin in the /home/logic/AM1808_OMAP-L138/Images directory, is that going to be OK to start with? We've got

on the board.

Thanks,

George

While reading through these links again I found part of what was confusing me. Your first link for creating the bootable SD card for AM18xx EVM makes sense. But then when I read the instructions for Create SD Card Script at the bottom is a note saying this script won't work for AM18xx, http://processors.wiki.ti.com/index.php/Sitara_Linux_SDK_create_SD_card_script#AM180x_SD_Card_Boot

Should I use fdsik to make 2 additional partitions and then when I run the Creat SD Card Script I choose not to wipe out the partitions. I have gone through the actual script but I wonder how it chooses which partition to put the kernel and which partition to the FS on.

Hi George,

Yes, you can try fdisk and also i would like to highlight other option using CCS Flash programming Utilities.

This link is basically for OMAP-L138 but also applies for AM1808

http://processors.wiki.ti.com/index.php/OMAP-L138_Preparing_SD_Card_for_Boot

Download the Flash Utility from the Link http://sourceforge.net/projects/dvflashutils/files/OMAP-L138/v2.40/

Uncompress these files in the Linux side and transfer it to windows PC directory using flash thumb drive, if you've installed CCS in windows machine.

If you’ve installed CCS in linux machine please follow the steps outline in the wiki link

I Hope this works well for you

Regards

Antony

• --------------------------------------------------------------------------------------------------------
  Please click the Verify Answer button on this post if it answers your question.
  --------------------------------------------------------------------------------------------------------

I was not able to follow any of the links and create a valid bootable SD Card. The only way I was able to create one was to use fdisk and create 2 partitions with the first partition starting at the 25th cylinder.

I need to go through my notes becuase I ended up having to use information from multiple links. It would be good if the Wiki(s) was updated.

George,

I completely agree with you that the process for making a bootable SD card for AM18xx needs to be clearer.  One thing that really makes thing confusing is the fact that SD boot was introduced into the boot ROM in a later silicon revision.  So many of our SDK docs talk about "SD boot" but since it wasn't part of the boot ROM back then, that really meant "ubl from SPI and u-boot from SD".  Several of the links in this thread (like the flash writing tool) are built on that assumption, i.e. that you have UBL in SPI flash.  So I feel your pain, and as your reading through documentation if you are consciously trying to discern between "native" SD boot and the "SPI assisted SD boot" it can be very helpful.

So in particular I believe this page is talking about "native" SD boot:

http://processors.wiki.ti.com/index.php/GSG:_OMAP-L138_DVEVM_Additional_Procedures#Creating_bootable_SD_card_for_OMAP-L138_EVM_board

In particular, the boot ROM reads raw info from the SD card and the uflash utility is used to write that info to the card from the PC.  This forum thread looks like a good reference:

Making a bootable SD card on the AM1808EVM
http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/131719.aspx

The forum thread above seems to be one of the few places where someone actually got it working!  I hope that helps. 

Brad

I'm glad you feel my pain because this has been driving me crazy! I had expected to just find a bootable test image and start from that. I read quickly through that last post and I see that Dennis had to modify a script.  This was back in 2011 so I'm not sure what's been changed since then.

Is there anyone that has a known bootable image that could be loaded up on the site? I've used AISgen and loaded it on a card following most of what was talked about but with the luck I've been having who knows what steps I could have made an error.

I never did get an answer as to whether the D800K008 ROM displays any status messages on UART when it runs? I don't see anything happen on my UART but have confirmed that it does work with CCS. I'm guessing at this point that the messages to appear will be from uboot and since I don't see anything my guess is that my card really isn't configured correctly.

George Ioakimedes said:

Is there anyone that has a known bootable image that could be loaded up on the site? I've used AISgen and loaded it on a card following most of what was talked about but with the luck I've been having who knows what steps I could have made an error.

The main purpose of UBL is to configure your PLLs and DDR so that it can load u-boot into external memory.  The PLL/DDR settings are hardware specific so you won't be able to get a known good binary.  You need to take the settings you verified from your DDR testing with the gel file, and put those into UBL.  For starters you should be able to load and run UBL from CCS (to make sure it's working as expected).  Once you know UBL is working for your hardware then you can proceed to the next step of getting it to boot from SD.

Hold on!  I just made a good find. (Ok, so someone else in another thread pointed to it...)  I think this is the best page I've seen discussing the process of booting "natively" from SD card:

http://processors.wiki.ti.com/index.php/How_to_boot_OMAP-L138_LCDK_from_SD_card

The page above actually is much more recent (Aug/Sept 2012). I don't see any categories assigned to it though, so that's probably why nobody seems to know it exists!!!  I realize you're on wiki overload as you've had at least a dozen articles pointed out.  However, this one here seems far and away more complete and up-to-date than anything else I've seen.  So basically I'd recommend ignoring all the other suggestions we've been giving you and focus on that page!  I'll go ahead and add some categories to that page to make it easier for people to find.  And if you find that page to be very useful with respect to getting SD card booting, I may add some notes to the other wiki pages to try and steer people to that page.  I'll wait for your feedback before doing that...

One other thing I should mention here as background...  I mentioned in the last post about using UBL to configure your PLLs and DDR.  There's actually a much better, cleaner way of doing this using functionality in the bootloader.  By using the functionality in the bootloader, you can completely eliminate the need for UBL!  The page above is actually using that capability which I think is a great thing.  That eliminates an entire phase of booting...

Brad

OK, that looks a little more promising! I have to file my sales tax return today (yes, I procrastinated until the last day because some project had me pulled away from civilization!) so if I don't do that the State of California will send some thugs to come beat me up. The good news is that it has to be done today so if I don't get to this later today I will try this out first thing tomorrow morning.

Thanks again Brad, I wish you were around a week ago!

George

I didn't get too far. The first thing you need to do is build U-Boot but you need to apply a patch which means you need the source. So off I go to get the SDK:

1. Go to OMAP-L138 LCDK Linux SDK
2. I'm told you can download the SDK from http://www.ti.com/tool/linuxsdk-omapl138
3. Hmm, this page has an "Important Note" that the software below is NOT the latest version. To get the latest version I should go to http://www.ti.com/tool/bioslinuxmcsdk
4. This page lists 5 different packages, 2 are for SYSBIOS so I can ignore those, 1 is for DSP so I can ignore that, I see the one for ARM9 and it does say it's for OMAP-L138. Let's download http://software-dl.ti.com/sdoemb/sdoemb_public_sw/mcsdk/latest1/index_FDS.html
5. OK, I'm on yet another page. For fear of getting lost in Wiki hell I'm afraid to click on the Getting Started Link or the Users Guide. It says that it supports the OMAP-L138 Development Kit, is that the same as the OMAP-L138 LCDK? Does it matter?
6. So there's an installer for Windows or Linux. Not sure about the Windows installer as most if not all the instructions on the Wiki pages assume that your Host is Linux based. There's also the Arago source, is that really 2.9GB? Is the U-Boot source going to be with the Arago or the Linux? I'm thinking it should be in the MCSDK Installer for Linux
7. I download mcsdk_1_01_00_02_setuplinux.bin, chmod a+x the file, run it and I'm asked to select components. I don't see any of the choices reference having the u-boot source and if I select everything it requires 1.34GB of space to install. I deselect a few of them like DSPLIB, MATHLIB, SYSLINK, thinking I don't need those or at least not now. It's still going to take 821MB of disk space. Fortunately when I created my build VM I gave it extra space. Time to install and grab a cup of coffee.
8. Good news, I see the u-boot source in this directory, /home/logic/ti/mcsdk_1_01_00_02/board-support. The first page I started with said that I needed to apply a patch to u-boot before I built it but that patch was being applied to u-boot-2010.12-psp03.21.00.04.lcdk. Do I need to get the 2010 u-boot source or do you think the patch that was needed before has already been applied to the 2012 version I now have?
9. Now I'm also starting to wonder about the build. The MCSDK says that it relies on the Arago toolchain but I've got CodeSourcery from the AM180x SDK install.

So 2 big questions before I can continue. Since having the correct u-boot is vital to the board being able to boot from the SD card more research is required.

I'm really trying to be an open book in hopes that someone in TI will take notice about the pain one goes through trying to follow your Wikis. If you're willing to host 2.9GB download packages what's so hard about building some known working builds and hosting them?

A better idea is creating an online build tool that links with an online build environment, hosted say on AWS? You pick your processor, you use an online pinmux for that processor (or use some defaults), you then use an AISgen type tool, pick a FS, and click build. Off it goes and when done you can d/l an image that could be used to burn to NOR, NAND, or SD. You then could have the option to download the build environment so you could run it yourself and tweak it to your liking.

George Ioakimedes said:

So 2 big questions before I can continue. Since having the correct u-boot is vital to the board being able to boot from the SD card more research is required.

There's no requirement to have u-boot to boot from the SD card.  In fact, I'd recommend taking "baby steps" and start with something much simpler, e.g. if you have an application that blinks an LED that would be better.  The key purpose of the page I pointed you to is:

1. To help you understand the steps to take an executable (whether it be u-boot or blink_led) and use the AIS tooling to allow you to turn it into a bootable AIS image that will configure PLLs and DDR for you.
2. To teach you how to write that image to the SD card, i.e. whatever tooling is needed to format the SD card in a way that the boot ROM will understand.

So I think the whole question of how to get u-boot operational may be its own thread.  For right now I suggest that you concentrate solely on being able to take an executable (like blink_led) and get it to boot from an SD card.  The goal should be that you should be able to put an SD card into your unit, power it on, see the LED blinking, connect with your JTAG emulator, refresh the DDR window a few times to verify it is stable/unchanging, and perhaps poke a few values into DDR as a sanity check.  The DDR should function reliably after the SD boot, i.e. it should be configured by the boot ROM with the proper values because those values were built into the AIS image.

George Ioakimedes said:

what's so hard about building some known working builds and hosting them?

Isn't that what we do with our SDK?  The issue is that there's no such thing as a known good build that works for all hardware.  The software needs to be customized to account for differences in input clock, desired operation frequency, choice of DDR device, etc.

I thought booting u-boot would be the next step. I've used CCS and gel files to configure the DDR and successfully run the RAM test. I've also run the UART test in CCS and seen the output in a terminal window. I used the off-line pinmux utility to determine what the pinmux registers should be and modified the GEL script to write those values into the registers and have read them back successfully.

I figured the next step is to try and boot u-boot from the SD card since this would confirm that the SD card connections are correct as well as letting me know that the pinmux and other registers are configured correctly for my board. I had initially tried to do this and when it failed I thought perhaps something else was wrong with our board design. Reading through most of these wiki pages leads me to believe that in order to successfully boot from a sd card you first need to start with a u-boot version that is a "AIS formatted U-Boot binary for MMC/SD boot". So perhaps my initial test wasn't really done correctly?

I understand that there are many combinations possible but maybe not as many as the number of wiki pages I've run into ;) !

I didn't realize that the AISGen could be used to boot something other than u-boot. All of the pages referencing AISGen talk about u-boot and as you mentioned, it's a great place to start to poke around your hardware and see if it's working correctly.

So is a new thread dedicated solely to booting u-boot from a SD card for the AM180x the next step?

I re-read that list of steps from your previous post.  At the very end you had confusion over a patch. I could not find that comment on "the first page" which I assume was this one from step 1:

http://processors.wiki.ti.com/index.php/OMAP-L138_LCDK_Linux_SDK_Getting_Started_Guide?DCMP=dsp-c6-lcdk-120524&HQS=linuxsdkwiki

Was that the page you were referring to?  I looked all over for anything related to "u-boot" or "patch" but didn't see anything.  Generally speaking when you download an SDK that's been built for a specific processor we've started from an upstream version of u-boot and applied changes to it in order to get full support of our device.  Often times we include that as a patch so you can see precisely what was added from the upstream u-boot version.  The patch would already be applied though in the SDK itself.  That said, I'm speaking in generalities here because I could not find what you were referencing.  Please share the precise page and the precise quote so I can give a more complete answer.

It looks like all the steps you followed with respect to u-boot were correct in terms of downloading the proper files.

George Ioakimedes said:

So is a new thread dedicated solely to booting u-boot from a SD card for the AM180x the next step?

Let's see.  After re-reading your previous thread it's not as confusing as I thought.  Let's see if we can get it resolved all in this thread!  I do, however, still recommend breaking this into 2 distinct steps:

1. Create an extremely simple program as a tester.  It doesn't actually even have to do anything.  It can be a simple while(1) loop that sits and literally does nothing at all.  The purpose of this step is to get the AIS process correct.  If you get it all correct you should be able to power on your board, connect with CCS, and see that you are sitting there spinning in the while(1) loop as expected and that all the DDR, PSC, PLL, etc. have been configured as you wanted.  Note that when you connect with CCS for this step you do NOT want to have your gel file as part of your target configuration.  You are trying to validate that the Boot ROM properly configured everything based off your required configuration.  So you want CCS to act strictly as an "observer" here and not actually interfere with things.  Along those same lines, if you want symbolic debug of this project you should do "load symbols" instead of "load program" such that CCS doesn't physically copy anything into memory.
2. Then you move on to u-boot itself.  Since most of the hardware-specific items will already be handled by the AIS image, u-boot should more or less fire right up.  If you're using the same UART for output as the LCDK then that should be the case.  Having gone through step #1 first will make it easier to get past some of the common obstacles that would prevent you from completing this step!

George Ioakimedes said:

I understand that there are many combinations possible but maybe not as many as the number of wiki pages I've run into ;) !

Ha ha ha!  I laughed out loud at this one...  You might be right! 

By the way, I wanted to mention one other thing just to help illustrate the complexity of what you were proposing.  Let's say you want to run at 456 MHz and you have a 25 MHz input clock (ok, so maybe you only get up to 450 MHz).  Keep in mind that you need to operate at a higher voltage for 450 MHz.  So now you start to introduce dependencies to the power supply.  So then your software creation utility would need to understand if you have a fixed voltage that has already supplied the proper 1.3V or if you're using an I2C-configurable power supply that perhaps starts at 1.2V but needs to be sent a sequence of commands in order to go up to 1.3V  Then on top of that it would need to know which I2C bus it's connected, what are the proper commands to send, etc.  It gets really tough really fast!  I hope that sheds some light on why we insist on making this so difficult for you! ;-)

I'm glad I was able to make you laugh, it's the least I could for dragging you into this thread on a Saturday.

The patch I'm referring to is on http://processors.wiki.ti.com/index.php/How_to_boot_OMAP-L138_LCDK_from_SD_card it's at the top in a nice blue color:

NOTE

The released U-boot package requires a patch to be integrated. Find the patch here

Unzip the uflash.zip and copy the patch to the linux host where u-boot source is located. Follow below command to integrate it:

cd ti-sdk-omapl138-lcdk-01.00.00/board-support/u-boot-2010.12-psp03.21.00.04.lcdk/
patch -p1 < 0001-uflash-Add-support-to-write-ubl-to-MMC-SD-in-OMAPL13.patch 

This patch adds the required support to write u-boot binary to the SD/MMC card.

My idea about the online tool wasn't meant to be able to handle any combination but give you the basics to come up with something to start with. It basically would be a combination of AISGen, PinMux, and that DDR Timing Spreadsheet. I really don't think it would be too hard and if nothing else it would be EXTREMELY easier to maintain than all these out of date wiki pages.

Which BTW, this page with the u-boot patch has an error at the bottom of the page when it shows you how to use uflash

./uflash -d /dev/mmcblk0 -u u-boot_mmc.ais -p OMAPL138 -vv

The "-u" is incorrect, that's for when you are supplying a UBL which doesn't apply to any silicon purchased in the last century, well OK, the last year or 2 or 3? You need a -b (for u-boot). I'm also not sure about "-vv". That's 2 v's and not a w, and I only see a switch for -v (verbose) when looking at uflash.c.

FYI, it's not in the help (./uflash --help) but adding -v or -vv provides different results:

logic@logic-desktop:~/AM1808_OMAP-L138/U-Boot/uboot-03.21.00.04/tools/uflash$ sudo ./uflash -d /dev/sdf -b uboot-socius-sd.bin -p OMAPL138 -v
[sudo] password for logic: 
OMAPL138
U-Boot Size 184555
First partition starts at 305235(156280320)
Writing U-Boot Signature
Writing U-Boot
Done...
logic@logic-desktop:~/AM1808_OMAP-L138/U-Boot/uboot-03.21.00.04/tools/uflash$ sudo ./uflash -d /dev/sdf -b uboot-socius-sd.bin -p OMAPL138 -vv
OMAPL138
U-Boot Size 184555
First partition starts at 305235(156280320)
U-Boot Magic Number        : a1aced66
U-Boot Entry Point         : c1080000
U-Boot Number of Blocks    : 00000169
U-Boot Starting Block      : 00000075
Load U-Boot Address        : c1080000
Writing U-Boot Signature
Writing U-Boot
Done...

V for verbose, and VV for very verbose!

George Ioakimedes said:

Which BTW, this page with the u-boot patch has an error at the bottom of the page when it shows you how to use uflash

./uflash -d /dev/mmcblk0 -u u-boot_mmc.ais -p OMAPL138 -vv

I tend to think the above command is  actually correct.  The description might talk about -u being for UBL and -b being for u-boot.  What is it that the tool does different for UBL than for u-boot, i.e. why does it need to know?  I imagine that the reason is so that the tool knows where to write the file into flash.  That said, the boot ROM is looking for an AIS formatted image at the start of the SD card.  The ROM doesn't know or care whether that image is UBL or u-boot.  I suspect (though you'll have to confirm!) that the real difference between the commands is whether to write to the start of the SD card or to the first partition.  So that said, I believe the wiki page is correct, i.e. in the case where we've completely eliminated UBL by using AIS commands the first thing to load would be the u-boot.ais which should be written to the start of the SD card.  Looking at the printout from your other post it looks like your AIS image is being written to the first partition at a large offset.  I don't think that's the correct place.  I think if you used the command as documented in the wiki it would write your AIS-image to the start of the SD card which is where the boot ROM will look for it.

Perhaps you're right, at this point I could be convinced of almost anything. The problem which made me look at the source code to begin with is that using -u throws an error, well actually an error that is "Success":

logic@logic-desktop:~/AM1808_OMAP-L138/U-Boot/uboot-03.21.00.04/tools/uflash$ sudo ./uflash -d /dev/sdf -u uboot-socius-sd.bin -p OMAPL138 -vv
[sudo] password for logic: 
OMAPL138
File (null) Open Error : Success
Invalid U-Boot Size -1
logic@logic-desktop:~/AM1808_OMAP-L138/U-Boot/uboot-03.21.00.04/tools/uflash$ 

Are you having fun yet? I 100% agree with you about where the the file is written to is important. Why adding the -u cause the program to successfully fail I'm not sure. Is it my file? Is it the way I partitioned my card? Here's what my card looks like:

Command (m for help): p

Disk /dev/sdf: 8179 MB, 8179941376 bytes
255 heads, 63 sectors/track, 994 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000c9259

   Device Boot      Start         End      Blocks   Id  System
/dev/sdf1              20          25       48195    b  W95 FAT32
/dev/sdf2              26         994     7783492+  83  Linux

Command (m for help): 

George Ioakimedes said:

logic@logic-desktop:~/AM1808_OMAP-L138/U-Boot/uboot-03.21.00.04/tools/uflash$ sudo ./uflash -d /dev/sdf -u uboot-socius-sd.bin -p OMAPL138 -vv
[sudo] password for logic: 
OMAPL138
File (null) Open Error : Success
Invalid U-Boot Size -1
logic@logic-desktop:~/AM1808_OMAP-L138/U-Boot/uboot-03.21.00.04/tools/uflash$ 

Is that file the output of building u-boot, or did you take that file and put it through the AISgen utility?  You need to have the AIS formatted image.  I don't see "ais" in your file name anywhere so it's not clear.

No, sorry for the confusion, it is the AIS generated file. I thought the utility would add the extension of AIS but it doesn't.

I think perhaps the logic in uflash.c isn't correct for what we want to do?

if (!ubl_name)
		uboot_start_block = UBL_START_BLOCK;

	if (!strcmp(platform, "DM3XX")) {
		if (!uboot_load_address)
			uboot_load_address = DM3XX_UBOOT_LOAD_ADDRESS;
		if (!uboot_entry_point)
			uboot_entry_point = DM3XX_UBOOT_LOAD_ADDRESS;
	}

	if (!strcmp(platform, "OMAPL138")) {
		if (!uboot_load_address)
			uboot_load_address = DA850_UBOOT_LOAD_ADDRESS;
		if (!uboot_entry_point)
			uboot_entry_point = DA850_UBOOT_LOAD_ADDRESS;

and the defines are:

#define verbose_printf(x...)	if (verbose) printf(x)
#define BLOCK_SIZE		512UL

#define UBL_SIGN_START		1
#define UBL_SIGN_COUNT		24
#define UBL_MAGIC_NUM		0xA1ACED00
#define UBL_ENTRY_POINT		0x00000100
#define UBL_START_BLOCK		0x00000075
#define UBL_BLOCK_OFFSET	0x0000000A

#define UBOOT_SIGN_START		25
#define UBOOT_SIGN_COUNT		26
#define UBOOT_MAGIC_NUM			0xA1ACED66
#define DM3XX_UBOOT_LOAD_ADDRESS	0x81080000
#define DA850_UBOOT_LOAD_ADDRESS	0xC1080000

#define PART1_LBA_OFFSET		0x000001C6
#define DEV_NAME			"/dev/mmcblk0"
#define UBL_NAME			"UBL.bin"
#define UBOOT_NAME			"u-boot.bin"

we don't pass a UBL filename so  so

uboot_start_block = UBL_START_BLOCK

we pass OMAPL138 and we don't pass a load address or entry point so 

uboot_load_address = DM3XX_UBOOT_LOAD_ADDRESS

uboot_entry_point = DM3XX_UBOOT_LOAD_ADDRESS

then a little later we have 

/* Get UBL file size and round it to upper 512 byte boundary */
	if (!strcmp(platform, "DM3XX")) {
		ubl_size = get_file_size(ubl_name);
		if (ubl_size < 0) {
			close(devfd);
			return -1;
		}

		ubl_size = (ubl_size + BLOCK_SIZE - 1) & ~BLOCK_SIZE;
		verbose_printf("UBL Size %d\n", ubl_size);
	}

I'm going through the code but there's a bunch of reverse logic which makes my head hurt as well as trying to keep UBL is a -u switch and u-boot is a -u switch.

OK, that patch that I talked about is actually a patch for uflash, not uboot. "The released U-boot package requires a patch to be integrated" while technically correct since uflash is bundled with uboot in the SDK I find this very misleading.

Anyway, I downloaded the patch and tried to apply but of course the patch fails

logic@logic-desktop:~/AM1808_OMAP-L138/U-Boot/uboot-03.21.00.04/tools/uflash$ patch -p1 < 0001-uflash-Add-support-to-write-ubl-to-MMC-SD-in-OMAPL13.patch 
patching file tools/uflash/uflash.c
Hunk #1 FAILED at 168.
Hunk #2 FAILED at 178.
Hunk #3 FAILED at 196.
Hunk #4 FAILED at 243.
4 out of 4 hunks FAILED -- saving rejects to file tools/uflash/uflash.c.rej
logic@logic-desktop:~/AM1808_OMAP-L138/U-Boot/uboot-03.21.00.04/tools/uflash$

as well as on the version of uflash downloaded with the MCSDK:

logic@logic-desktop:~/ti/mcsdk_1_01_00_02/board-support/u-boot-2012.04.01-psp03.22.00.06.sdk/tools/uflash$ patch -p1 < 0001-uflash-Add-support-to-write-ubl-to-MMC-SD-in-OMAPL13.patchpatching file tools/uflash/uflash.c
Hunk #1 FAILED at 168.
Hunk #2 FAILED at 178.
Hunk #3 FAILED at 196.
Hunk #4 FAILED at 243.
4 out of 4 hunks FAILED -- saving rejects to file tools/uflash/uflash.c.rej

So I guess I'll open the patch and see changes it was trying to make...

I manually applied the patch changes to uflash.c and recompiled. I don't get that error as before yet I still don't get the board to boot. Here's the output of the uflash now:

logic@logic-desktop:~/ti/mcsdk_1_01_00_02/board-support/u-boot-2012.04.01-psp03.22.00.06.sdk/tools/uflash$ sudo ./uflashgi -d /dev/sdf -u uboot-socius-sd-ais.bin -p OMAPL138 -vv
OMAPL138
UBL Size 184575
U-Boot Size 511
First partition starts at 305235(156280320)
Required Blocks 488, Available Blocks 305234
UBL Magic Number     : a1aced00
UBL Entry Point      : 00000100
UBL Number of Blocks : 00000168
UBL Starting Block   : 00000075
UBL Load Address     : 00000000
Writing UBL Signature
Writing UBL

I'm still thinking that the card is not properly created or the AIS generated uboot is not good. I don't think it;s a uboot problem because I don't see much traffic on the SD pins. I see a 6MHz clock (AISGen on the peripheral tab is set at 5MHz though). I see a small burst of traffic on the CMD pin as well as the DAT0 pin when the board first boots but no other traffic and I've yet to see any traffic on the UART1 or UART2 pins (other than in CCS).

We should be able to identify the problem by running this diagnostic gel script:

http://processors.wiki.ti.com/index.php/OMAP-L1x_Debug_Gel_Files

Use the "Run All" script, paste the output into a file output.txt and then attach to this post (under "Options").  That should hopefully give some further insight into the issue.

OK, I had done this before in the other thread but for completeness I just ran the script again. I removed the other GEL file and just loaded the debug gel file to be on the safe side.

Here is the uSD connections on our board. Note that R1 is not populated so there is no pull up on the clock line. Also note that on the EVM they use SD_WP but uSD cards do not have this pin so it is a NC on my board. For completeness here is a review of the connection comparison between all 3 boards. The EVM and my board use 100k pull ups but the LCDC uses 10k. Perhaps 100k is too weak? If that's true I would think that I would still see some sort of signal on the scope though. Also, on the EVM the signals go through a level translator but that should only be needed when you are using 1.8V

I currently have 2 boards that I working with. I have one board that has the boot pins configured for debug and that board is connected to JTAG. That is the board I have done all the CCS work with. I have a 2nd board which has the boot pins configured for SD boot (I measure the pads going into the processor to confirm the configuration) and that is the board I am currently trying to boot from the SD card.

You don't need to select the "emulation" boot mode in order to actually use emulation.  I need you to connect your JTAG  to the board that's setup for SD boot and run that script after the board has powered up.  The ROM will report failure errors which get decoded and output by the script.  That's the key thing I'm looking for.

Oh, I didn't know that you could use JTAG when the boot mode pins were set for something else. I could have sworn I was instructed to do that on the other thread.

I unfortunately have 2 different headers on these boards for the JTAG so it's not quite as easy as just plugging and unplugging so I'll change the boot resistor on the board I've got connected to JTAG and start using that for testing the SD Card boot. Fortunately it's only 1 boot resistor to change to go from debug to sd boot (BOOT[1]).

Attached is a picture of my setup so you can feel my pain. BTW, CAT6 cable wires make great jumper wires since they are 24AWG solid wire.

OK, I haven't reviewed it but attached is the full debug script after setting the DDR frequency with the other script.

Looks like you need to remove your other gel file.  That's not causing an issue (for now) though.  I can see it's having an error finding an image in the SDMMC.  According to the bootloader app note the magic word the ROM is searching for is 0x41504954.  I was confused/surprised that this number didn't show up in the uflash snippets you pasted before.  I'm trying to find some other TIers with experience with this utility to pitch in...  Hang in there!  I hope to have some reinforcements soon!

OK, thanks, I was a little confused by that but I think the magic key that is written is for uboot and the AISGen is responsible to embed the 0x41504954 which uflash writes to the card.

I was playing with hex editors last night and trying to make sense of this but couldn't find a user friendly hex editor in linux that will search for me. I could have sworn I saw the 41504954 last night but I'm not seeing it now but I have to manually search for it.

Oh yes, of course that comes from AISgen. Can you zip and post your binary for inspection? I expect there's nothing proprietary in that. 

I think you meant to attach the AISGen file, which I have. I'm not sure where I left off last night as I tried a couple of different settings with AISGen to see if they could work.

I found a hex editor that works a little better than the other ones I've tried. Searching for the 1st occurrence of 0xA1ACED00 (actual search is ^s \00\ED\AC\A1) finds this:

Searching for 0x41504954 finds this:

I'm not sure about the u-boot magic number but in the bootloader spec I read the following:

The AIS boot image is expected to be in the user data area of the memory device, written to address 0 of that
region. The bootloader detects the AIS image by checking for the magic word (0x41504954). If the magic
word is not found, the bootloader increments the starting address by 0x200 and tries again. The
bootloader fails if the magic word is not found within the first 2 MB of the memory card.
Typically, the ROM boot loader will first try to detect an SD card. If that fails (i.e., a timeout occurs), the
boot loader will then attempt to find an MMC or eMMC device.

The magic word is at location EA00 on the card which I assume is in the "user data area", falls on a 0x200 address, and is located within the first 2 MB of the memory card. 

I've had a good look at the uflash code from the MCSDK.  First, you are correct that the patch is still needed.  Though as you discovered it didn't apply cleanly since the patch was written to apply to an older version of the MCSDK.  (Perhaps we can get someone to get an updated version of the patch to make this easier.)

The AIS image you zipped and attached previously looks like a valid image, i.e. I see the expected magic word at the beginning.  That said, I think the uflash should simply be taking your image and writing it straight into memory...  So can you try the following:

1. Comment out the chunk of code that performs "Write UBL Signature".
2. Comment out the "lseek" line under "Write UBL Binary", i.e. we want to write it to the very beginning of the card.

It looks to me like uflash is adding on an EXTRA header (using magic number 0xA1ACED00) which is messing things up.  I think this is another remnant from when we used to boot from SPI flash and then read code from SD/MMC.  The "magic number" that UBL looked for is 0xA1ACED00.  So I think uflash stuck that header onto the front of your image, but that's not the header we want!!!  We want magic number 0x41504954 which is already part of the binary.  So hopefully that all makes sense.  Please try out this change and I suspect it will fix the issue.

Sorry for your pain!!!

Good Morning!

Hopefully today will be the day! I've attached the uflash code that I used before the changes you just mentioned. Just so we're on the same page and don't have another unknown would you mind making the changes you're thinking of and I'll compile and try ti again.

Thanks,

George

Looks fine.  There's a printf related to u-boot size that I would move up into the conditional, i.e. no need to print it out if uboot_name doesn't exist.  Specifically I'm talking about lines 200-201 of your file.  I would put them in the "if (uboot_name)" conditional just above so we don't see extraneous printouts.  Crossing my fingers!

OK, I think we are getting close. I see more traffic on the SD command and DAT0 line but the SD clock is not 75MHz! 

So it seems as though perhaps my AISgen settings are incorrect. I've attached what I think is the last configuration I sued so would you mind taking a look at it and seeing if you can find what's wrong. On the Peripheral Tab there is a setting for the MMC/SD Clock and it is set at 5MHz so how could that be interpreted as 75MHz?

BTW, the version of AISgen I am using says "AISgen for D800K008 Bootloader, Version 1.13. Most of the settings should be straight from the OMAPL138_LCDK_AISGen_Config.cfg and I might have even just used it as my last test but I'm not sure.

I would hazard a guess that the generated configuration does not have things in the correct order and that it's configuring PLL0 before adjusting the MMC clock divider.  Because the MMC peripheral is fed by PLL0.SYSCLK2 the result of configuring PLL0 is that the MMC input clock will shoot way up.  For now, can you uncheck the box for "Configure PLL0" so that we don't cause this issue.  That should at least allow the bootloader to finish loading the file!!!  I think we may need to leave that one for another thread!!!

PS.  You can have your application configure PLL0 at run-time to get around this issue.  The most critical PLL is PLL1 since that's the one that goes to the DDR interface.  It's critical that we get PLL1 and the DDR interface configured correctly prior to loading our application since we'll be running from external memory!

Sorry, I got pulled away for a while. Getting closer. SD clock is at 6MHz (why not 5MHz?) but I do see a lot of traffic on the CMD and DAT0 lines but nothing on UART1 Tx or UART2 Tx

Try connecting with CCS again.  You should have the "debug gel" but not the gel that you modified to configure clocks.  Note, there is a line at the top of the debug gel file where you need to adjust the input clock speed to match your system in order for it to correctly reflect the PLL settings.

The output will tell you if there was an error reported by the ROM code.  It will also show you the program counter value.  Check to see if it "made it" all the way to u-boot.  If you're not seeing anything it might be due to the fact that you didn't fill out the PSC tab, i.e. not sure if u-boot just expects the UART to be enabled at the PSC level or if it does it explicitly.  Could also be that the clocks or DDR are not configured right.  If either of those things is messed up then it will likely crash immediately.

I'm about to get on the road for some travel so my responses are going to slow down.  I'm glad you're close!!!

Attached is the latest debug GEL output. Took a quick look and didn't see any errors so I guess I need to confirm that the registers are configured like AISgen was supposed to do.

• I confirmed that the pinmux settings that I entered into AISgen are configured on the processor after it boots. Specifically PINMUX10 is correctly set to 0x82222222
• The DDR rgisters are also correctly set and I'm able to modify the DDR contents at address 0xC0000000
• AISgen has "13;" in the PSC1 Enable LPSC setting which according to the TRM (p145) means that UART2 is always on.
• I couldn't find what registers to look at (searched for MDSTAT, PSC1)  so I peeked into the memory location to see what was there. It doesn't appear to be set if I'm understanding this correctly. MDSTAT13 is located at 0x01E27834 but I'll admit I'm a little confused by how this is controlled.

Bit 9 appears to be set (0x1E03 = 0001 1110 0000 0011) which doesn't make sense since according to Table 5-10 (p69) of the AM1802 datasheet (and p145 of the TRM) that LPSC Number isn't used.

I'm questioning whether AISgen is really configuring everything properly since I still see a 6MHz clock for the SD. My main crystal input is 24MHz and measured with the scope for confirmation.

I guess the good news is that if UART2 really isn't being enabled then that would explain why I'm not seeing any traffic on it but I don't know how to have it enabled other using AISgen so I can see the initial boot up

The debug gel script decodes all the power states for you. UART2 is definitely enabled. I've not used the LCDK before. Does it use UART2 as the console output?  If not you would need to modify that. 

This is is probably a good time to use a simpler program than u-boot as I suggested earlier just to verify that you can correctly load a program and execute it.

OK, I see that now in the Debug GEL Output:

Module 13: UART 2             STATE = 3

So I guess I don't understand the address space correctly since looking at the address it didn't look like it was enabled.

When you say to take a step back with a simpler program how about the UART test that I'm able to load and run successfully in CCS? Do I just take the .out file load that into AISgen instead of uboot.bin?

Right. You can take any out file and run it through AISgen to make it bootable. 

OK crap, that worked. Cap because that means that UART2 is enabled and should work. Or maybe the UART code configures the system, I'll have to look at the code as I'm not sure.

So if I am able to boot with the AISgen setting and have it run this UART test then something else is wrong, but what? the u-boot.bin file I've been using? Been to so many pages I can't tell you where I got it from now.

You may want to re-run your u-boot test but with all the PSC modules except SATA enabled.  (Don't enable SATA!  It needs the "force" bit to be set when enabling it and the ROM doesn't do that.)  It could be something simple like a peripheral (e.g. a Timer, etc.) not being enabled that is hosing u-boot.

If that doesn't work you will need to debug u-boot with CCS to understand where it's going wrong.

OK, I certainly hope that I don't have to get to the point where I need to use CCS to debug u-boot!

Are you thinking both PSC0 and PSC1? I don't see SATA listed as one of the modules, I'm looking at Table 8-1 and 8-2 of TRM

I'll go ahead and enable everything but the unused ones

PSC0:  0;1;2;3;4;5;6;7;9;10;11;12;14;

PSC1:  0;1;3;5;6;7;10;12;13;21;24;25;27;28;29;31;

Yes, both PSCs.  Your variant must not have SATA.  I have not double-checked your numbers, but "looks reasonable".

The UART gods are not with me yet again. Still no traffic on either UART1 or UART2.

I'm beginning to think this must be some bug in the AISgen tool...