New Custom AM1802 Board Boot from SD Card

Are you able to load u-boot with CCS and successfully run it?  I would recommend:

1. Remove your SD card so the boot ROM doesn't try to boot from it.
2. Go back to your "known good gel file" that sets up PLLs and DDR.
3. Load u-boot with CCS and hit "run".  (There should be an ELF file simply called "u-boot" that is built from u-boot.  That's the one to load/run.)

You are not allowed to blame AISgen until you have the above configuration working!  ;-)  Now that PLL0 is not being configured that might be screwing up the UART timings, etc...  Once you can run properly from CCS that will help us understand what's wrong.

Hey, whatever happened to the customer is always right?!!

I'm with you except for the "load u-boot with CCS". I haven't built u-boot. I've been using a u-boot.bin from god only knows where.

There is a u-boot source in the mcsdk_1_01_00_02/board-support/u-boot-2012.04.01-psp03.22.00.06.sdk/ folder.

I haven't built it because my VM is configured for the LogicPD AM1808 but I guess the build should still work? Actually there is a u-boot.bin file as well as a u-boot so maybe I'll just grab the u-boot file and try that with CCS as the directory names are the same between this SDK and the MCSDK

You could try the binaries from the SDK.  At least then you know where it came from!  Most likely you'll need to build it though because when it inevitably fails to work you'll need the ability to make changes.

I get an error in the console when I run that u-boot file which says 

Target not run as the symbol "main" is not defined as well as it's looking for a source file

Which file did you load?  Can you click "Locate File" and point to the file it's looking for?

I loaded the u-boot file, not the u-boot.bin file. The source file it's looking for is pointing back to the Host Development PC where the source files are

The entire source code is included in the SDK. CCS sees the path in the binary which came from the computer of the person who originally built the file. The base path may be different but the file should be there. i suggest using a Linux version of CCS so that you can easily access all the files. 

Well, OK, I guess, but really, how many hoops do I need to jump through to get this working? There really isn't anyone that has booted u-boot from an SD card on one of these processors?

CCS is such a hog, over 1GB for an IDE. I'm running the development PC in a VM. I'll hope that the emulator will play nice in a VM.

George -- We have u-boot working on our eval boards.  If you make your hardware different than ours then you also need to take responsibility for the corresponding software changes.  I'm trying to lead you through a process to debug u-boot to figure out why it's not working.  You can debug it however you want.  In my opinion being able to build u-boot from Linux and then debug it from Linux is the most effective route. 

Hi Brad:

Sorry for the frustration but it's been a long road so far. I guess I just don't get why AISgen isn't producing a bootable card. The only difference that I'm aware of at this point is that I've got an AM1802 instead of a OMAP-L138 processor. Right now we should only be worried about DDR2, UART2, the 24MHz crystal, and the SD Card socket.

I've only got 25GB of free space left on the workbench computer so I'm going to see if I can install VirtualBox and have it point to the VM that's on the other computer. It should work. If not I'll have to grab an old laptop that boots Linux and start over installing the SDK and CCS.

OK, I think a major breakthrough just happened. I had a terminal window open but it was behind CCS so I didn't see this before. When I run u-boot in CCS even though CCS throws those errors u-boot does start to load:

MMC: davinci: 0
SF: Unsupported manufacturer ff
*** Warning - spi_flash_probe() failed, using default environment

In: serial
Out: serial
Err: serial
ARM Clock : 300000000 Hz
DDR Clock : 150000000 Hz
SF: Unsupported manufacturer ff
Error - unable to probe SPI flash.
Net: Error: Ethernet init failed!
Board Net Initialization Failed
DaVinci-EMAC
Hit any key to stop autoboot: 0
Card did not respond to voltage select!
SF: Unsupported manufacturer ff
Failed to initialize SPI flash at 0:0
No SPI flash selected. Please run `sf probe'
Wrong Image Format for bootm command
ERROR: can't get kernel image!
U-Boot >

It appear as though u-boot is really running so the u-boot that I'm using should be good or good enough to at least display these messages and it's back to AISgen or uflash not doing something correct.

G-R-E-A-T!   I'm trying to see if I can get someone from the factory get a new release of AISgen so that you can actually configure PLL0.  I assume that's what's causing us issues since the peripheral clocks are derived from PLL0.

PS.  Since you can run u-boot from CCS, DO THAT.  In other words, your development doesn't need to be held up waiting for the next revision of AISgen...  I'm not certain that the PLL0 settings are the issue, but it's certainly an issue. I'll try to provide a timeline as soon as I hear anything further.

How about trying to shove and boot everything from the NAND I have on board? The only difference is it's a 8-bit and the reference board is a 16-bit. Can CCS program the NAND at this point?

You can of course give it a whirl though I think you'll have better luck from the u-boot command line than you will with the CCS utility. If you do "help nand" from u-boot you'll get a list of the various options.

Already tried that and this version of u-boot doesn't have the nane command. It says the version is 2010.12 so either that was before the nand support or the sdk version doesn't have it.

Could you check if there's another version of u-boot that I can work with?

We are getting off topic. I expect you need to change the build options to include NAND support since nand has been part of u-boot for many years. In terms of this thread, booting from SD card, the key item to close is the ability to configure PLL0 In AISgen. I'm waiting for a reply from other TI employees on that topic. 

OK, understood but please let them know that creating a NAND boot image with AISgen also fails like the SD. I was able to use CCS to write an AIS generated NAND U-Boot file and I can see traffic on the NAND I/O pin but nothing on the UART.

I hope this provides them with an easy fix to AISgen so I can get this board booted up!

So can you successfully boot a "simple" executable from NAND?  Additionally did you have to uncheck the "configure PLL0" box to succeed?

I didn't try to enable PLL0 but I guess I could give it a try, I was just curious if that could allow me to continue testing but it was basically the same result as the SD card.

I assumed that you instructed some intern to work on the new AISgen and to not go home until it was done so I've been sitting in front my computer waiting for the new tool!

I am trying to get an update of AISgen. It won't be today (sorry!). Another option is to use HexAIS from the command line. You have a lot more control using that tool. I'm at a rest stop driving home right now so I cannot provide a lot more details this moment! I'm posting this with my phone!

No luck enabling PLL0. In fact I tool a peek at the PLL0 register and according to CCS PLLDIV7=0xB yet AISgen has DIV7=12 (0xC) . For reference the other register settings are:

521177 2
R UART2ARM_RBR 0x0000000B 0x00000000
R UART2ARM_THR 0x0000000B 0x00000000
R UART2ARM_IER 0x0000000B 0x00000000
R UART2ARM_IIR 0x0000000B 0x00000001
R UART2ARM_FCR 0x0000000B 0x00000001
R UART2ARM_LCR 0x0000000B 0x00000000
R UART2ARM_MCR 0x0000000B 0x00000000
R UART2ARM_LSR 0x0000000B 0x00000060
R UART2ARM_MSR 0x0000000B 0x00000000
R UART2ARM_SCR 0x0000000B 0x00000000
R UART2ARM_DLL 0x0000000B 0x00000000
R UART2ARM_DLH 0x0000000B 0x00000000
R UART2ARM_REVID1 0x0000000B 0x44141102
R UART2ARM_REVID2 0x0000000B 0x00000000
R UART2ARM_PWREMU_MGMT 0x0000000B 0x00000002
R UART2ARM_MDR 0x0000000B 0x00000000
R PLL0ARM_REVID 0x0000000B 0x44813C00
R PLL0ARM_RSTYPE 0x0000000B 0x00000001
R PLL0ARM_RSCTRL 0x0000000B 0x00010003
R PLL0ARM_PLLCTL 0x0000000B 0x00000049
R PLL0ARM_OCSEL 0x0000000B 0x00000014
R PLL0ARM_PLLM 0x0000000B 0x00000018
R PLL0ARM_PREDIV 0x0000000B 0x00008000
R PLL0ARM_PLLDIV1 0x0000000B 0x00008000
R PLL0ARM_PLLDIV2 0x0000000B 0x00008001
R PLL0ARM_PLLDIV3 0x0000000B 0x00008004
R PLL0ARM_OSCDIV 0x0000000B 0x00008000
R PLL0ARM_POSTDIV 0x0000000B 0x00008001
R PLL0ARM_PLLCMD 0x0000000B 0x00000001
R PLL0ARM_PLLSTAT 0x0000000B 0x00000006
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 0x0000800B
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

Maybe the field in AISgen intends to have you enter the divider (i.e. /12) but then it configures the register to 11 in order to implement /12?  Maybe try again with a different value and see if it's always off by one.

I expect the PLL0 capability to work properly.  The issue is that it's done BEFORE the peripheral configuration and so the clock speed on the SD interface goes too high.

I'll try to do some additional tests to see if I can see what AISgen is doing wrong. I did see the HexAIS_OMAP-L138 program but haven't seen any real instructions on how it's used. I saw some ini files but there are located in a Patch_binaries directories so I'm not sure how they would be used.

George,

I don't know if/when we can get a new version of AISgen, so perhaps we're best served using HexAIS.  I dug around to find the details.  First, download from here:

http://sourceforge.net/projects/dvflashutils/files/

You're using AM1802 which is a close relative of OMAP-L138, so grab the OMAP-L138 package from the link above.  The current version for OMAP-L138 right now is v2.40.  Once you've downloaded and extracted the tarball you'll want to go to the following directory:

• OMAP-L138_FlashAndBootUtils_2_40/OMAP-L138/GNU/AISUtils

There's a readme.txt file that documents how to use the tool.  In a nutshell:

1. You'll run HexAIS_OMAP-L138.exe from the command line, though note it requires Microsoft .NET 3.5 Framework or later to run.
2. All the settings that you previously had typed into the GUI will instead be entered into the OMAP-L138.ini file that sits next to HexAIS_OMAP-L138.exe.
3. The OMAP-L138.ini file is processed in order, so for something like PLL0 being initialized in the wrong order compared to the SD interface, we can fix that issue by simply changing the order of the lines in the file!

So in summary your goal should be to have the ability to boot from SD card and end up with the exact same PLL, DDR, PSC, and PinMux settings as what you have in your gel file (i.e. the gel file where you were able to successfully load/run u-boot).  A good tool for comparing your settings is to use the debug gel file I mentioned before. It prints out status info related to the PLLs and PSCs.

I know your motivation must be lacking at this point, but you're nearly there!  Keep up the momentum!  :-) The fact that you were able to make u-boot run from CCS is huge.  Once you get rolling with HexAIS it will likely only take a couple iterations to match all the settings from your successful CCS run.  Then you'll be home free!

Hi Brad:

Thanks for following up. I've downloaded the tools and will begin reviewing the files. I see an OMAP-L138.ini in that AISUtils directory so I'll start with that. I currently have my boot pins configured for NAND so I'll change BootMode=none to BootMode=NAND.

The first hurdle I see is that the GEL files (input and output), AISgen, and now HexAIS all use different formats. HexAIS is easier to read since you enter the entire register as 1 value but the other tools split the registers up (except for pin muxing).

Do you think the safest thing to do is to use CCS to load the gel file that appears to be working and then write down each full register value and use that for this ini file?

BTW, I love that a Windows utility is embedded in a tarball...

The OMAP-L138.ini syntax makes up pseudo-registers.  For example there's no register called PLL0CFG0, but the fields that comprise PLL0CFG0 (CLKMODE, PLLM, PREDIV, POSTDIV) are real fields taken from the registers.  So that said, what you suggested could be helpful.  Along those lines you may want to dump the corresponding memory to a file so you can do the same later and compare gel vs HexAIS.

Here's a stripped down version (I've eliminated the commented sections) of what I'm going to try. I'm not 100% confident in everything but I think it's reasonable.

; General settings that can be overwritten in the host code
; that calls the AISGen library.
[General]

; Can be 8 or 16 - used in emifa
busWidth=8            

; SPIMASTER,I2CMASTER,EMIFA,NAND,EMAC,UART,PCI,HPI,USB,MMC_SD,VLYNQ,RAW
BootMode=NAND

; This section allows setting the PLL0 system clock with a  
; specified multiplier and divider as shown. The clock source
; can also be chosen for internal or external.
;           |------24|------16|-------8|-------0|
; PLL0CFG0: | CLKMODE| PLLM   | PREDIV | POSTDIV|
; PLL0CFG1: | RSVD   | PLLDIV1| PLLDIV3| PLLDIV7|
;[PLL0CONFIG]
PLL0CFG0 = 0x00180001
PLL0CFG1 = 0x00000205

; This section can be used to configure the async chip selects
; of the EMIFA (CS2-CS5).  The fields required to do this
; are given below.
;           |------24|------16|-------8|-------0|
; A1CR:     |                A1CR               |
; A2CR:     |                A2CR               |
; A3CR:     |                A3CR               |
; A4CR:     |                A4CR               |
; NANDFCR:  |              NANDFCR              |
;[EMIF25ASYNC]
;A1CR = 0x00000000
;A2CR = 0x00000000
;A3CR = 0x00000000
;A4CR = 0x00000000
; Use CS3NAND
NANDFCR = 0x00000001

; SDI AM1808 with DDR @150 MHz
[EMIF3DDR]
; GI Changes 140206
PLL1CFG0 = 0x18010001
PLL1CFG1 = 0x00000002
DDRPHYC1R = 0x000000C5
SDCR = 0x00134832
SDTIMR = 0x264A3209
SDTIMR2 = 0x3C14C722
SDRCR = 0x00000492
CLK2XSRC = 0x00000000

; This section allows setting of a single PINMUX register.
; This section can be included multiple times to allow setting
; as many PINMUX registers as needed.
;         |------24|------16|-------8|-------0|
; REGNUM: |              regNum               |
; MASK:   |               mask                |
; VALUE:  |              value                |
;[PINMUX]
;REGNUM = 5
;MASK = 0x00FF0000
;VALUE = 0x00880000

For the command line I'm going to issue:

HexAIS_OMAP-L138 -ini Socius.ini -otype binary u-boot.bin@0xC1080000

Is it 0xC1080000 for the load address or is that only for SD/MMC and NAND needs a different address?

Based on this thread, I have added the following to my ini file:

; This section should be used to setup the power state of modules
; of the two PSCs.  This section can be included multiple times to
; allow the configuration of any or all of the device modules.
;           |------24|------16|-------8|-------0|
; LPSCCFG:  | PSCNUM | MODULE |   PD   | STATE  |
;[PSCCONFIG]
;LPSCCFG=

;UART2 enable
[PSCCONFIG]
LPSCCFG=0x010D0003

and used the following command line:

HexAIS_OMAP-L138 -ini Socius.ini -o boot.ais -entrypoint 0xC1080000 u-boot.bin@0xC1080000

I then use the NANDWriter program and run it in CCS. I tell it to erase the NAND, which is does successfully, and then it asks for the AIS file which I then enter the generated boot.ais file, go run around the block, and when I return I enter "none" for the "Application file name".

I stop the debugging session and power cycle the board but unfortunately I don't get anything in the terminal window.

For the time being forget about the terminal and focus on being able to boot (successfully) and getting everything configured properly:  PLL0, PLL1, PSC, DDR.  In particular I want to see:

1. Power up board (NAND programmed with "simple" AIS image, hello world not u-boot)
2. Connect with JTAG
3. Run debug gel script
4. Capture output to file.

Separately:

1. Power up board (erased NAND)
2. Connect with JTAG
3. Run your configuration gel script that programs all the PLLs, etc.
4. Run debug gel script
5. Capture output to file

Those things should be identical, or nearly so.  Once you get that far then I think we'll be ready to tackle u-boot.

Please unsubcribe me from these posts. I dont need them at all.

I am not finding an option to unsubscribe.

Help.

The attached File is the log of the steps I just performed. I created the ais file using the ARMeXpUARTTest.out file that I have been able to successfully run in CCS.

I did not get any output so something must be wrong with one of the steps I am doing or there's another bug hidding somewhere.

The attached file has some notes between each step so you can see exactly what I am doing.

PLL0 does not get configured. Let's see your OMAP-L138.ini file. Please add .txt to the name so I can open with my phone. :-)

Attached is the file but right at the top is:

; This section allows setting the PLL0 system clock with a  
; specified multiplier and divider as shown. The clock source
; can also be chosen for internal or external.
;           |------24|------16|-------8|-------0|
; PLL0CFG0: | CLKMODE| PLLM   | PREDIV | POSTDIV|
; PLL0CFG1: | RSVD   | PLLDIV1| PLLDIV3| PLLDIV7|
;[PLL0CONFIG]
PLL0CFG0 = 0x00180001
PLL0CFG1 = 0x00000205

The line that says [PLL0CONFIG] is still commented.  Could that be the issue?

Perhaps, but I'm confused why you think it isn't configured because in the gel output I see this:

ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |              PLL0 Information             |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: 
ARM9_0: GEL Output: PLL0_SYSCLK1 = 24 MHz
ARM9_0: GEL Output: PLL0_SYSCLK2 = 12 MHz
ARM9_0: GEL Output: PLL0_SYSCLK3 = 8 MHz
ARM9_0: GEL Output: PLL0_SYSCLK4 = 6 MHz
ARM9_0: GEL Output: PLL0_SYSCLK5 = 8 MHz
ARM9_0: GEL Output: PLL0_SYSCLK6 = 24 MHz
ARM9_0: GEL Output: PLL0_SYSCLK7 = 4 MHz

And if I look at the actual registers the values are correct (i.e. POSTDIV=8001, PREDIV=8000, PLLM=0018, CLKMODE=0000)

PLL0_SYSCLK1 is the ARM clock. It should be 300 MHz (or 375).  If it is 24 MHz then it seems to be in bypass mode and not enabled. 

OK, I see that now. I looked back on some of the other debug gel outputs and I see all of them are this way except for 1 that was captured on 2/2 @ 11:30. I think that is when we decided to not let AISgen configure PLL0.

In that output I see this:

ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |              PLL0 Information             |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: 
ARM9_0: GEL Output: PLL0_SYSCLK1 = 300 MHz
ARM9_0: GEL Output: PLL0_SYSCLK2 = 150 MHz
ARM9_0: GEL Output: PLL0_SYSCLK3 = 25 MHz
ARM9_0: GEL Output: PLL0_SYSCLK4 = 75 MHz
ARM9_0: GEL Output: PLL0_SYSCLK5 = 100 MHz
ARM9_0: GEL Output: PLL0_SYSCLK6 = 300 MHz
ARM9_0: GEL Output: PLL0_SYSCLK7 = 50 MHz

It is hard to know whether that is happening from AIS or u-boot. That's a reason to use something simple for starters. Does uncommenting that line from the ini fix the issue? 

I found another ini file and it had PLL0 configured differently so I changed my ini to match:

; This section allows setting the PLL0 system clock with a  
; specified multiplier and divider as shown. The clock source
; can also be chosen for internal or external.
;           |------24|------16|-------8|-------0|
; PLL0CFG0: | CLKMODE| PLLM   | PREDIV | POSTDIV|
; PLL0CFG1: | RSVD   | PLLDIV1| PLLDIV3| PLLDIV7|
;[PLL0CONFIG]
;PLL0CFG0 = 0x00180001
;PLL0CFG1 = 0x00000205

[PLLANDCLOCKCONFIG]
PLL0CFG0 = 0x00180001
PLL0CFG1 = 0x00000B05
PERIPHCLKCFG = 0x00010064

and with this ini I now see the PLL0 correctly configured like my last post. Unfortunately I do not see any output in the terminal window. I've been testing with some other changes to the ini file so I've added my latest ini to this post

So how's that comparison of the working and nonworking simple program coming along? Can you send the debug gel output for both?  Clearly everything is not the same. You need to verify PLLs, DDR, PSC, and pinmux. 

I have found that when you add

PERIPHCLKCFG = 0x00010064

you get the correct clocks. As soon as you comment out that line the clocks drop to 24MHz based. What doesn't make sense is that the read me for this tool shows that this line is to "configure the peripheral interface of the current booting peripheral" yet only I2C, SPI, or UART are listed as options.

• So how does a peripheral clock change the main clock?
• Why doesn't just setting PLL)CFG0/1 work?
• I've noticed that trying to configure the pinmux registers is ignored

I am at a complete loss as to what to do next. It seems as though these tools are not doing what the documentation says that they will do. I can take this same uarttest.out file that I pipe into HEXAIS and it runs fine in CCS after the board boots.

I also have not been getting email updates when you post this this thread otherwise I would have responded earlier.

I was actually just looking through the ROM code, and that particular function actually applies to SD/MMC in addition to I2C, SPI, and UART.

Just so we're on the same page, here's a snippet from the readme.txt:

  ; This section should be used in place of PLL0CONFIG when
  ; the I2C, SPI, or UART modes are being used.  This ensures that
  ; the system PLL and the peripheral's clocks are changed together.
  ; See PLL0CONFIG section for the format of the PLL0CFG fields.
  ; See PERIPHCLKCFG section for the format of the CLKCFG field.
  ;               |------24|------16|-------8|-------0|
  ; PLL0CFG0:     |              PLL0CFG              |
  ; PLL0CFG1:     |              PLL0CFG              |
  ; PERIPHCLKCFG: |              CLKCFG               |
  [PLLANDCLOCKCONFIG]
  PLL0CFG0=
  PLL0CFG1=
  PERIPHCLKCFG=

The "PLLANDCLOCKCONFIG" function above is a single function executed by the ROM code that configures both PLL0 and the boot peripheral (either I2C, SPI, UART, or SD/MMC).  Because the peripheral clocks are derived from PLL0, we need both the PLL and peripheral clock to get modified at the same time.  The "PLLANDCLOCKCONFIG" command requires 3 arguments, with PERIPHCLKCFG being one of them.  So it seems to me that the behavior you describe is correct.

Moving forward we need to see where you're at with respect to the items I've mentioned: PLL0, PLL1, DDR, PSC, PinMux.  Please attach a zip file containing the following to your next post:

1. Your OMAP-L138.ini file.
2. Your corresponding AIS binary output file.
3. The output from the debug gel file captured after connecting to the board (power up using your image from #2).
4. The output from the debug gel file captured after a "CCS only" run where you configure all the PLLs and DDR with the gel file.

George Ioakimedes said:

I've noticed that trying to configure the pinmux registers is ignored

I saw the following in your ini:

[PINMUX]
REGNUM = 0
MASK = 0xFFFFFFFF
VALUE = 0x44111811
REGNUM = 1
MASK = 0xFFFFFFFF
VALUE = 0x00011001

I believe you need a "PINMUX" for each instantiation.  For example:

[PINMUX]
REGNUM = 0
MASK = 0xFFFFFFFF
VALUE = 0x44111811
[PINMUX]
REGNUM = 1
MASK = 0xFFFFFFFF
VALUE = 0x00011001

I'll change that and try but I would think that PINMUX0 would still be configured and it hasn't been

Attached is the zip which contains the following:

• HexAIS_OMAP-L138.exe is the tool I'm using to create the AIS wrapped file which is run using this:

HexAIS_OMAP-L13
8.exe -ini Socius.ini -o uarttest.ais -entrypoint 0xC1080000 ARMeXpUARTTest.out@0xC1080000

• Socius.ini is the input file for HexAIS
• ARMeXpUARTTEST.out is the program that I can successfully run in CCS and generate output on UART2
• OMAPL1x-debug.gel is the debug gell I have been running
• OMAP-L138_LCDK.gel is the gel file that allows me to read and write DDR2 memory, run UARTTSET, and toggle some LEDs on the board.

George,

FYI, I've been working with our factory team looking to see if there's something in AISgen that needs to be fixed.  After closely analyzing the AISgen code, it appeared that it was properly utilizing the "PLLANDCLOCKCONFIG" function call that we discussed a couple posts ago in the context of HexAIS.  So my initial theory that AISgen was NOT using PLLANDCLOCKCONFIG and was instead doing independent function calls for "[PLL0CONFIG]" and "[PERIPHCLKCFG]" was not correct.

Furthermore, I looked at the AIS binary that you attached to the following post:

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/314721/1108802.aspx#1108802

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
• 0000000e <- PERIPHCLKCFG

So based off PLL0CFG0/1 you should end up with PLL_SYSCLK1 = PLL_SYSCLK6 = 24 MHz input clock x 25 / 2 = 300 MHz.  The MMC is clocked off SYSCLK2 (150 MHz).  It gets divided by 2*(PERIPHCLKCFG+1).  So that said I would have expected this configuration to result in a SD clock of 5 MHz, which I believe is what you were aiming for!

So all that said, it seems to me like perhaps AISgen was working correctly in the first place.  Did you ever try a "simple" file when booting from the SD card?  I wonder if perhaps it actually booted ok from SD card and then perhaps u-boot messed up the SD card frequency.  ???

It's up to you whether you prefer to stay with HexAIS or go back to AISgen.  Personally I'm kind of interested to go back to AISgen.  I have been doing a lot of this support from my phone as I've been traveling.  My apologies that I didn't have a good hex editor on my iPhone!  Perhaps I would have discovered this sooner...

George Ioakimedes said:

• OMAPL1x-debug.gel is the debug gell I have been running
• OMAP-L138_LCDK.gel is the gel file that allows me to read and write DDR2 memory, run UARTTSET, and toggle some LEDs on the board.

You misunderstood me on these.  I want the output from the OMAPL1x-debug.gel.  I'm looking for two files that look exactly like this one you posted earlier:

http://e2e.ti.com/cfs-file.ashx/__key/telligent-evolution-components-attachments/00-42-01-00-01-10-96-74/Debug_5F00_Gel_5F00_Success4.txt

That just gives me a "pretty view" of the chip configuration.  I want to see one file corresponding to a failed boot, i.e. where the AIS bootloader has configured everything.  I want to see the other one corresponding to your "good" run.  In that case you'll have TWO gel files loaded, one being OMAP-L138_LCDK.gel which will first configure everything as well as OMAPL1x-debug.gel to then dump the corresponding configuration.

I'll have to read this again to let it sink in but I wanted to reply.

When we couldn't get AISgen to work with u-boot we did run a test using I believe this same UARTTEST program. I'll have to read back through the posts but I'm pretty sure we did boot that card and the program ran successfully. At that point we thought AISgen was broken so we switched to HexAIS.

I may have complicated things by switching to NAND boot but we weren't getting anywhere getting u-boot to boot from the SD card so I thought I would do some testing with NAND. Currently I have not been able to get either u-boot or UARTTEST to boot from NAND but we have tried many things over the past week.

Why doesn't somebody have a SD Card that boots u-boot for the LCDK board? Of course I need to figure all of this out and determine why nothing is working for me but if I could at least boot u-boot and Linux I could continue confirming the rest of the board works (ethernet, USB, and audio). Right now I've been dead for weeks.

Sorry, I did what you wanted but forgot to attach the file. I hope you don't mind but I made one file with all the outputs just so you could follow the process I'm doing.