New Custom AM1802 Board Boot from SD Card

The strategy here is to get something working and then take incremental steps. The subject of the thread is SD boot. Please stop switching everything around. It is off topic and confusing. I cannot help you that way. 

You have a simple test that runs from CCS as well as SD card. We need to build on that.  So we are on the same page, can we go back to the following: AISgen, SD boot, uarttest. Can you please setup AISgen such that it is configuring PLL0 again?  Then get me TWO output logs from the debug gel. I want to diff them so one file is not as good. 

I switched to NAND after we found that I was able to boot from the SD card with the UARTTEST but not with u-boot on the card. We then loaded u-boot in CCS and found that it did run. At that point we were out of ideas other than there must be a bug in the tools. Rather than do nothing I decided to test NAND in hopes that additional information would be helpful in debugging what was failing.

Attached are the files you wanted to see. I'm not 100% sure the 2nd SD card has u-boot one it but I'm almost positive it does as I used a different card for the UARTTEST. I don't recall what AISgen settings were used on these cards

Just to eliminate any uncertainty I reran AISgen and used uflash to add u-boot to the SD card. I do not see any messages on the terminal from uboot. I've attached the following:

• AISgen config file
• config file in C format to show the hex code format of the AISgen
• The generated AISu-boot file
• Debug Gel output

Looking at the AISgen file created I see the following:

Here is the first AIS command in the file:

• 5853590d <- Function Execute Command
• 00030006 <- Num_Args=3, Fxn_ID=6 (PLL and Clock Configuration)
• 00180001 <- PLL0CFG0, which multiplies input clock x25 and then /2.
• 0000040b <- PLL0CFG1
• 00000001 <- PERIPHCLKCFG

and looking at the debug gel results I see that the clock is at 24MHz, not 300MHz. This wiki page has a note to "Make sure Peripheral->MMC/SD clock is 35" so that is why it is 35 and before I think I had been using 5.

Did you see the clock frequency for the SD card change to 35 MHz?  I think that would actually result in a frequency of 37.5 MHz (if PLL0 was set properly).

After the (failed?) boot can you connect with CCS, load symbols for the corresponding executable, and see where the PC is pointing?  I'm wondering if you're still in a "good state" after the boot or if you're off in an error vector somewhere.

Sorry, I've never loaded symbols so you'll have to help with that. Looking at the debug output after booting this card shows this:

Program Counter (PC) = 0xFFFD8C7C

and PLL0_SYSCLK1 = 24MHz

The SD clock is really odd, very slow and it looks like it changes frequency, it's much less than 1MHz but since we're not at 300MHz that might make sense.

Actually I set different triggers on the SD clock and I see it is switching between 300kHz and 6MHz.

George Ioakimedes said:

Sorry, I've never loaded symbols so you'll have to help with that.

Run -> Load -> Load Symbols

If nothing else, please look in a disassembly window to see where it's at.  If you do View->Registers you should be able to find the PLLs and MMC registers.  I'd love to see those values to try to make some kind of connection of what's going on here...  So weird!

George Ioakimedes said:

The SD clock is really odd, very slow and it looks like it changes frequency, it's much less than 1MHz but since we're not at 300MHz that might make sense.

I don't understand that one either either...  It's derived from PLL0_SYSCLK2 which would be 12 MHz in your case.  If you get an exact measurement I might be able to correlate that to something else.  I still don't see what's happening here.  (Sorry, seems like we should be further by now!!!)  One thing that I found interesting was your post related to HexAIS stating you needed to add the following:

PERIPHCLKCFG = 0x00010064

Now initially I just attributed that to the fact that having no argument at all was not legal.  But perhaps there's more to it...  How did you choose that value anyway?  Bit 16 is supposed to be reserved so I was surprised to see that as 1.  Also, 0x64 is a huge divider.  If we can't get anywhere with AISgen I may need you to switch back to that.  My assumptions on AISgen so far have not panned out.

I'll check the symbols but from the debug gel we know that the clocks are not correct even though we set them in PLL0 in AISgen. According to that page we should have a CPU clock of 300MHz and the gel shows us at 24MHz.

The clock rates appear to be pretty stable at 300kHz and 6Mhz. I think I remember reading that on initialization the clock would be slower and then it would increase. Perhaps it's trying to read and failing and dropping back and forth trying to read the card.?

PERIPHCLKCFG = 0x00010064 was stolen from a thread. It didn't make sense to me either but with HEXais it was very clear that with it I got 300MHz and without it I get 24MHz. I didn't bother to try and change the actual value.

I'm off to load symbols.

I loaded symbold (by pointing to the uboot elf file). Not sure if that is what I was supposed to do and I'm not sure what you wanted to see. I've attached a full dump of the registers for reference but here's the PLL registers:

R PLL0ARM_REVID 0x0000000B 0x44813C00
R PLL0ARM_RSTYPE 0x0000000B 0x00000001
R PLL0ARM_RSCTRL 0x0000000B 0x00010003
R PLL0ARM_PLLCTL 0x0000000B 0x00000072
R PLL0ARM_OCSEL 0x0000000B 0x00000014
R PLL0ARM_PLLM 0x0000000B 0x00000013
R PLL0ARM_PREDIV 0x0000000B 0x00008000
R PLL0ARM_PLLDIV1 0x0000000B 0x00008000
R PLL0ARM_PLLDIV2 0x0000000B 0x00008001
R PLL0ARM_PLLDIV3 0x0000000B 0x00008002
R PLL0ARM_OSCDIV 0x0000000B 0x00008000
R PLL0ARM_POSTDIV 0x0000000B 0x00008001
R PLL0ARM_PLLCMD 0x0000000B 0x00000000
R PLL0ARM_PLLSTAT 0x0000000B 0x00000004
R PLL0ARM_ALNCTL 0x0000000B 0x000001FF
R PLL0ARM_DCHANGE 0x0000000B 0x00000000
R PLL0ARM_CKEN 0x0000000B 0x00000003
R PLL0ARM_CKSTAT 0x0000000B 0x00000003
R PLL0ARM_SYSTAT 0x0000000B 0x000001FE
R PLL0ARM_PLLDIV4 0x0000000B 0x00008003
R PLL0ARM_PLLDIV5 0x0000000B 0x00008002
R PLL0ARM_PLLDIV6 0x0000000B 0x00008000
R PLL0ARM_PLLDIV7 0x0000000B 0x00008005
R PLL0ARM_EMUCNT0 0x0000000B 0x00000000
R PLL0ARM_EMUCNT1 0x0000000B 0x00000000
R PLL1ARM_REVID 0x0000000B 0x44814400
R PLL1ARM_RSTYPE 0x0000000B 0x00000000
R PLL1ARM_RSCTRL 0x0000000B 0x00010003
R PLL1ARM_PLLCTL 0x0000000B 0x00000049
R PLL1ARM_OCSEL 0x0000000B 0x00000010
R PLL1ARM_PLLM 0x0000000B 0x00000018
R PLL1ARM_PREDIV 0x0000000B 0x00008000
R PLL1ARM_PLLDIV1 0x0000000B 0x00008000
R PLL1ARM_PLLDIV2 0x0000000B 0x00008001
R PLL1ARM_PLLDIV3 0x0000000B 0x00008002
R PLL1ARM_OSCDIV 0x0000000B 0x00000000
R PLL1ARM_POSTDIV 0x0000000B 0x00008001
R PLL1ARM_PLLCMD 0x0000000B 0x00000001
R PLL1ARM_PLLSTAT 0x0000000B 0x00000006
R PLL1ARM_ALNCTL 0x0000000B 0x00000007
R PLL1ARM_DCHANGE 0x0000000B 0x00000000
R PLL1ARM_CKEN 0x0000000B 0x00000000
R PLL1ARM_CKSTAT 0x0000000B 0x00000008
R PLL1ARM_SYSTAT 0x0000000B 0x00000007
R PLL1ARM_PLLDIV4 0x0000000B 0x00000000
R PLL1ARM_PLLDIV5 0x0000000B 0x00000000
R PLL1ARM_PLLDIV6 0x0000000B 0x00000000
R PLL1ARM_PLLDIV7 0x0000000B 0x00000000
R PLL1ARM_EMUCNT0 0x0000000B 0x00000000
R PLL1ARM_EMUCNT1 0x0000000B 0x00000000


and the MMC:

R MMCSD0ARM_MMCCTL 0x0000000B 0x00000004
R MMCSD0ARM_MMCCLK 0x0000000B 0x00000100
R MMCSD0ARM_MMCST0 0x0000000B 0x00000004
R MMCSD0ARM_MMCST1 0x0000000B 0x00000030
R MMCSD0ARM_MMCIM 0x0000000B 0x00000000
R MMCSD0ARM_MMCTOR 0x0000000B 0x0003FFFF
R MMCSD0ARM_MMCTOD 0x0000000B 0x000000FF
R MMCSD0ARM_MMCBLEN 0x0000000B 0x00000200
R MMCSD0ARM_MMCNBLK 0x0000000B 0x00000001
R MMCSD0ARM_MMCNBLC 0x0000000B 0x00000001
R MMCSD0ARM_MMCDRR 0x0000000B 0xE3560000
R MMCSD0ARM_MMCDXR 0x0000000B 0x00000000
R MMCSD0ARM_MMCCMD 0x0000000B 0x00000210
R MMCSD0ARM_MMCARGHL 0x0000000B 0x00000200
R MMCSD0ARM_MMCRSP01 0x0000000B 0x00000000
R MMCSD0ARM_MMCRSP23 0x0000000B 0x00000000
R MMCSD0ARM_MMCRSP45 0x0000000B 0x00000000
R MMCSD0ARM_MMCRSP67 0x0000000B 0x00000900
R MMCSD0ARM_MMCDRSP 0x0000000B 0x00000000
R MMCSD0ARM_MMCCIDX 0x0000000B 0x00000010
R MMCSD0ARM_SDIOCTL 0x0000000B 0x00000000
R MMCSD0ARM_SDIOST0 0x0000000B 0x00000003
R MMCSD0ARM_SDIOIEN 0x0000000B 0x00000000
R MMCSD0ARM_SDIOIST 0x0000000B 0x00000000
R MMCSD0ARM_MMCFIFOCTL 0x0000000B 0x00000004

and here's what you get when you open a disassembly window:

George,

FYI, I made some extensive updates to this part of the wiki article based on this thread:

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

Would you mind sharing your uflash.c file?  I'd like to post it on the wiki page so that people don't have to bother with patches, etc.

I noticed in this article that there is a different method for flashing u-boot-ais.bin.  In fact, it looks much easier since there's no "special" utility needed.  It just uses the dd utility that's baked into your Linux host.

The article discusses that when you are NOT booting Linux and don't have multiple partitions that you can just do the following:

• sudo dd if=ais_file.bin of=/dev/sdx

However, it mentions that if you have partitions you don't want to overwrite the master boot record and so it suggests the following:

• sudo dd in=u-boot.ais of=/dev/sdx seek=10

I'm pretty sure that uflash was simply writing to address zero.  I wonder if that was causing some grief with respect to mounting the file system in Linux.  You might try first following these steps to create a card with two partitions (i.e. make sure you re-do those steps to "fix" your broken MBR) and then try performing that second command above (i.e. with seek=10).

I don't have a board to try this out right now.  If it works better than uflash then I'll go ahead and just remove all the uflash business and suggest dd instead...

FYI, I've made some edits elsewhere to point people to the updated wiki page so hopefully this will be the end of people struggling to boot Linux from an SD card on AM1808!

Brad