booting OMAP35x EVM from SD card

You are correct you have to make a SW4 switch modification, I believe 00011001 [8:1] on SW4 should do it. As to formatting the card this can be a bit of a long process, there is actually an article in the Beagle collateral that explains how to generate the card at http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat

It is also true that the ROM boot loader does not boot directly from a USB memory device, the USB boot mode is for using the USB port in a slave fashion, where a master processor (like a PC) is used to boot the device.

EDIT: Also note that with the default U-Boot you will still have your U-Boot arguments stored in the on board NAND as opposed to the SD card, you would have to modify U-Boot to load arguments off of the SD card if you wanted to be entirely independent of the NAND, I have seen this done but I do not know how distributable the version of U-Boot that does it is.

Thanks, that's useful info.  A few follow up questions:

1.  Regarding the special formatting of the card.  The process looks fairly straightforward (I found similar instructions on a TI link... http://wiki.davincidsp.com/index.php?title=MMC_Boot_Format).  However, are you aware of whether there is any issue with changing the geometry of the SD card?  Does this have any impact on the life of the card, or impact on the controller that is typically built-in to an SD card?

2.  In the case of booting from MMC/SD, I assume that x-loader is not needed.  The TI documentation states that when booting from MMC/SD the booting file or image must not exceed 128kBytes - so if the u-boot image is kept below this maximum then I figure the OMAP ROM code can load and start u-boot directly from MMC/SD and not need x-loader.  Is this correct?

3.  Regarding u-boot's environment variables, I'll look into u-boot to see what this would take.  In the meantime, could you pursue making the code you've seen available in some way?

Thanks.

1. I do not know if changing the geometry would cause any life time issues with the card, I would guess that they would not because I believe the controller inside the SD card handles wear leveling independent of what is being accessed. I think that the geometry is just a hold back from when you would only be formatting magnetic disks, and that it does not really apply to a solid state memory, based on that I imagine that as long as the geometry numbers correspond to the size of the partition that you should be ok.

2. The x-loader is still needed, it takes the form of a file called MLO that you put into the primary partition of the SD card. The MLO file is just a renamed x-load.bin.ift file which is created using the signGP tool within the SDK.

3. Unfortunately this is not something that is going to be easily distributed due to the source, and since it is not a planned U-Boot feature it is not something TI can support (for example it would probably break if you needed to change U-Boot versions). I am told that it was not that major of a modification and should not be too difficult to implement. As the code is not available I question if I should have made mention of it, but I did want you to know that it is possible.

Thanks.  See my responses...

1.  That makes sense.  I'll assume it's no problem.

2(a).  I just found on the omapzoom wiki that x-loader can be built to load the second stage boot loader (u-boot) from nand OR SD card.  Is that how the x-load.bin.ift included in the SDK was built?  So I should be able to use that binary (renamed to MLO) and not have to rebuild x-loader specifically for our application?

2(b).  Still, based on the TI documentation, it seems as though the ROM could load u-boot.bin directly from the primary partition of the SD card.  Is it possible as long as u-boot.bin is signed properly?  or are there other reasons that prevent skipping x-loader and loading u-boot directly from SD card as the first stage boot loader.

3.  I understand.  I'm pretty familiar with u-boot and can easily make the changes - can you point me in the general direction?  Does it revolve around executing "mmcinit" early enough in the u-boot startup code such that when u-boot gets to the point of reading env vars - they're accessible via the SD card?  (And u-boot would have to be told where on the SD card to maintain the environment.)

burchmere said:

2(a).  I just found on the omapzoom wiki that x-loader can be built to load the second stage boot loader (u-boot) from nand OR SD card.  Is that how the x-load.bin.ift included in the SDK was built?  So I should be able to use that binary (renamed to MLO) and not have to rebuild x-loader specifically for our application?

I believe you are correct, I have always used existing MLO files myself.

burchmere said:

2(b).  Still, based on the TI documentation, it seems as though the ROM could load u-boot.bin directly from the primary partition of the SD card.  Is it possible as long as u-boot.bin is signed properly?  or are there other reasons that prevent skipping x-loader and loading u-boot directly from SD card as the first stage boot loader.

You are probably right, but the problem (and I believe the reason why x-loader/MLO is used) is that the U-Boot binary is too large to fit in the internal RAM space that the ROM boot loader loads to. So if you could strip down U-Boot to fit in the 64k internal RAM than you would be good to go, I believe that X-loader is sort of a stripped down U-Boot that serves this purpose before loading the fully functional U-Boot.

burchmere said:

3.  I understand.  I'm pretty familiar with u-boot and can easily make the changes - can you point me in the general direction?  Does it revolve around executing "mmcinit" early enough in the u-boot startup code such that when u-boot gets to the point of reading env vars - they're accessible via the SD card?  (And u-boot would have to be told where on the SD card to maintain the environment.)

I believe you mainly have to modify a board file, if you wanted to do a real quick and hard hack you could force a specific set of boot arguments and ignore the NAND, but that would mean you would have to rebuild and reflash U-Boot to change your boot arguments. The solution I saw had a text file on the SD card where the environment variables were kept, for this type of solution you would have to make sure that U-Boot could talk to the SD card (mmcinit) before it tried to access the environment.

Thanks.  You've been very helpful with these answers.  But, of course, I have another question.  The OMAP documentation on "Device Initialization by ROM Code" states that the ROM code supports booting from MMC/SD cards with some limiatations.  It then states that the ROM code supports FAT 12/16/32 formatted memory cards, with or without a master boot record (MBR).  However, the link to the OMAP wiki (http://wiki.davincidsp.com/index.php?title=MMC_Boot_Format) and the link to the beagleboard wiki you provided both include a step to make the appropriate partition "bootable."  I believe this means creating an MBR on the MMC/SD card.  So is the MBR required or not?  (Shortly, I'll be to the point of being able to test this but I'd prefer word directly from TI on what is required.)

Also, on a slightly different topic, I'm not completely familiar with all the GPIO mux'ing options, but can you tell me if using MMC3 (in addition to MMC1 and MMC2) precludes any other 3525 functionality?

I have generated a lot of cards but I have never tried it without making the first partition bootable, I guess it is possible that it would work without it, but since it is a small step in the process I see no harm in just leaving it there. It is possible that there is more to making the partition bootable than having a MBR (I was guessing there is some flag in the partition to indicate bootable), unfortunately I am not that familiar with these file system structures.

As to MMC3 and the Pin Muxing this is a bit complicated due to the amount of multiplexing on the device, the short answer is yes, assuming CBB package it looks like it would potentially interfere with the HSUSB1 and HUSB2 interfacs as well as potentially McBSP5, McSPI3, and McSPI1 CS lines and the ETK bus (trace). For a more detailed answer you will have to take a look at table 2-4 of the datasheet.

I went through the SD card re-partitioning and tried to boot, and I get nothing out of the console.  I tried setting the sys_boot[] signals to boot in UART3/MMC1 order, and tried in MMC1/UART3 order - neither worked.  Any suggestions for how I can debug this?

Also, one thing I noticed is that in copying x-load.bin.ift to the SD card as MLO, an "ls" on the SD card shows the file "mlo" lowercase.  Is OMAP ROM code concerned with case of MLO filename?

At the moment, I only have mlo and u-boot.bin on the SD card.  I wanted to see x-loader start, then u-boot start - then the idea was I'd move on to adding the kernel and getting linux to boot.

By the way the SW4 settings I tried were:

SW4[8..1] = 11111000 (OFF, OFF, OFF, OFF, OFF, ON, ON, ON) = UART3 (first), MMC1 (second)

SW4[8..1] = 11011000 (OFF, OFF,  ON, OFF, OFF, ON, ON, ON) = MMC1 (first), UART3 (second)

The OMAP35x EVM MMC/SD connector is tied to MMC1, correct?  One last point of info, on power up, the MMC LED does come on (and it doesn't when booting as normal via oneNand).

The MLO being lowercase mlo is fine, that is how mine is.

I just got out one of my bootable SD cards and verified the settings again, just so we are clear I have attached a picture of my switch settings. Of course after taking the picture I realized that mine is a Samsung board, if you have a Micron board (and you probably do) the switch settings you describe sound correct, the first one with UART3 first is what is suggested in the GSG.

The SD/MMC slot is MMC1, it is definately bootable. The MMC LED coming on is a good sign, I believe that is due to the SW4 switch settings being correct, if the SW4 settings boot the device in a way that it never tries to get to the SD slot than the LED will not light.

To debug I would take a look at the fdisk information for your SD card and verify it against the documentation posted previously, getting a SD card formatted to boot on the OMAP is very tedious, all it takes is one typo during the fdisk sequence and it will fail, probably silently like this.

I do have a Samsung board, and I have tried the switch settings shown in the picture.  But to confirm, these aren't the same settings you sgguested earlier in the thread, correct?  The settings in the picture are SW4[8:1] = 11100110 = peripheral booting, USB>MMC1 correct?

Also, I include the fdisk info and a file listing from my SD card.  Would you look it over and confirm that it appears OK?  Last, I had read some info on web about MLO having to be in the first sector of the partition - and the suggestion was to ensure that immediately after partitioning, copy MLO to the SD card before any other files are copied.  Do you have any sugguestions on how to guarantee MLO is in first partition, or how to verify that is actually is in the first partition?  Thanks.

Disk /dev/mmcblk0: 8017 MB, 8017412096 bytes
255 heads, 63 sectors/track, 974 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xb77fac34

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1   *           1         974     7823654+   c  W95 FAT32 (LBA)

Expert command (m for help): p

Disk /dev/mmcblk0: 255 heads, 63 sectors, 974 cylinders

Nr AF  Hd Sec  Cyl  Hd Sec  Cyl     Start      Size ID
 1 80   0   2    0 254  63  973          1   15647309 0c
 2 00   0   0    0   0   0    0          0          0 00
 3 00   0   0    0   0   0    0          0          0 00
 4 00   0   0    0   0   0    0          0          0 00

jb@jb:~$ ls -l /media/KODAKomap3/
total 180
-rwxr-xr-x 1 jb root  16908 2008-12-05 17:20 mlo
-rwxr-xr-x 1 jb root 160608 2008-12-05 17:20 u-boot.bin
jb@jb:~$

burchmere said:

But to confirm, these aren't the same settings you sgguested earlier in the thread, correct?  The settings in the picture are SW4[8:1] = 11100110 = peripheral booting, USB>MMC1 correct?

This is true, there are actually multiple combinations that can lead to booting from SD/MMC, I took the first settings from a Wiki site, the settings in the picture are what I had been using myself to boot from SD, unfortunately with the two board versions (Samsung/Micron) there are additional switch differences making it overlycomplex.

burchmere said:

Would you look it over and confirm that it appears OK? 

The main thing that pops out to me in regards to your setup is that your card is significantly larger than any I have used and your primary booting partition is also huge, there may be some issue there but I am not sure, I only have used 2G or smaller cards with a booting partition that is even smaller, something around 256MB. It also has your Id as c whereas mine is b, though I am not sure what that means.

burchmere said:

Last, I had read some info on web about MLO having to be in the first sector of the partition - and the suggestion was to ensure that immediately after partitioning, copy MLO to the SD card before any other files are copied.  Do you have any sugguestions on how to guarantee MLO is in first partition, or how to verify that is actually is in the first partition? 

I have not run into this issue yet, since I use two partitions the only stuff on the booting partition is the MLO, the U-Boot image, and the kernel so it is relatively small. Not copying in the MLO first may explain some of the odd failures in getting this to work.

I actually end up partitioning the card in Linux and formatting the EXT3 partition and than putting the card in a Windows machine to format the FAT partition, I found that the Linux formatted FAT would not always work for me. I can also mention that I use Micro Center brand 2GB cards, I have heard of issues getting some other brands to work. Below is the output from my fdisk, this one boots just fine.

root@xxx.xxx.xxx.xxx:/mnt# fdisk /dev/mmcblk0

Command (m for help): p

Disk /dev/mmcblk0: 2013 MB, 2013265920 bytes
255 heads, 63 sectors/track, 244 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1   *           1          32      257008+   b  W95 FAT32
/dev/mmcblk0p2              33         244     1702890   83  Linux

Command (m for help): x

Expert command (m for help): p

Disk /dev/mmcblk0: 255 heads, 63 sectors, 244 cylinders

Nr AF  Hd Sec  Cyl  Hd Sec  Cyl     Start      Size ID
 1 80   1   1    0 254  63   31         63     514017 0b
 2 00   0   1   32 254  63  243     514080    3405780 83
 3 00   0   0    0   0   0    0          0          0 00
 4 00   0   0    0   0   0    0          0          0 00

Expert command (m for help):

I tried your suggestion of a smaller partition and it worked - thanks!  However, I'm very confused because it only seems to work in 2 variations of sys_boot settings:

sys_boot[5:0] = 100110

sys_boot[5:0] = 000110

Any other setting that includes MMC1 (and excludes OneNand) does not work.  It hangs just after either "Texas Instruments X-Loader 1.41" or that same message followed by "X-Loader hangs".  Does this make any sense?  I would have thought, for example, that sys_boot[5:0] = 111000 would have worked.

By the way, from what I've read, the partition type 'b' (W95 FAT32) versus 'c' (W95 FAT32 (LBA)) makes no real functional difference in the partition.  This type field is more an identifier than anything else.

I am glad to hear that the smaller partition worked, it could be some limitation with SDHC as the boot loader doc makes no mention of SDHC support (though it does not say it does not support it either).

I would agree that 111000 should work as well, and the fact that you got messages from X-loader means that the ROM boot loader completed, I suppose X-Loader must have some dependancy on the initial configuration done by the ROM code in the x00110 mode, I have not taken a look at the source myself yet to see what else could cause the 'X-Loader hangs' message.

So do you think this is an X-loader issue or a ROM code issue?  Either way, this is potentially an issue for us.  If we choose to boot via MMC1, it's likely that we'll want to use some other sys_boot option than MMC1/USB or USB/MMC1.  Do you have other resources you could pose this question to?  I can pursue it with our local TI rep and email to TI and Mistral support.  Any other suggestions?

In the meantime, I'll look into x-loader to see if I can add some debug to determine where the boot process is going wrong.

The fact that it is running X-Loader at all tells me that the ROM boot loader is already done and has completed successfully, so I would say this is most likely something you could fix by modifying X-Loader.

Looking at the X-Loader source it seems that you could end up with the 'X-Loader hangs' message from a number of sources, from what I see there is div0.c (unlikely), onenand.c (unlikely), and start.S (possible). The start.S reference looks like they have it for some sort of protection in the case a branch to start went bad, though I am not too terribly familiar with ARM assembly so this is really just conjecture, but since I am not as familair with this and it looks like a more general error source I am suspicious of this. The onenand.c file and the div0.c also can call the hang function but I have doubts that these would happen because a division by 0 would mean a code change for x-loader which is not happening, and the onenand should not even be used since this is a SD card boot.

I can run this past some people internally, the X-Loader hangs message has never come up for me before but I have also not tried many alternative boot modes yet, I will let you know what I find.

Your local rep may be a potential resource, Mistral may not be able to help much as they did not develop the software, and you are already talking to TI support :).

Just another follow up, I think the EVM hardware manual might show the SYS_BOOT pins backwards since it shows SYS_BOOT0 with SW4-1 and SYS_BOOT1 with SW4-2 and so on, but based on my switch settings I believe it is actually the reverse.

What exact SW4 setting is getting you the 'X-Loader hangs' message? I tried a SW4[1:8] of 11100000 and got the 'Texas Instruments X-Loader 1.41' but no hang message, it just did not do anything else, setting SW4[1:8] to 00011100 left nothing printed on the terminal.  

I don't think the EVM HW manual is wrong.  Maybe just confusion between you and me?  Note that the order you and I are showing for the bits is reversed from how it's shown in TI TRM.  So, ignoring SW4[7:8] per the EVM HW UG, here are my results for the following settings:

SW4[1:6] = sys_boot[0:5] = 011001 = OK (in TRM order sys_boot[5:0] = 100110)

SW4[1:6] = sys_boot[0:5] = 011000 = OK (in TRM order sys_boot[5:0] = 000110)

SW4[1:6] = sys_boot[0:5] = 011100 = hangs after "Texas Instruments X-Loader 1.41  X-Loader hangs" (in TRM order sys_boot[5:0] = 001110)

SW4[1:6] = sys_boot[0:5] = 101101 = hangs after "Texas Instruments X-Loader 1.41  X-Loader hangs" (in TRM order sys_boot[5:0] = 101101)

SW4[1:6] = sys_boot[0:5] = 011101 = hangs after "Texas Instruments X-Loader 1.41  X-Loader hangs" (in TRM order sys_boot[5:0] = 101110)

SW4[1:6] = sys_boot[0:5] = 000111 (and most other valid settings) = hangs after "Texas Instruments X-Loader 1.41" (this is what you reported has showing nothing?)

After running through your settings and some contemplation I belive I found my confusion, the dip switches are effectively inverted, i.e. turning on a switch pulls that pin low, not high, so it is not that the pins are marked backwards it is that they are of the opposite value, confirmed by the schematic. I apologize for this confusion, I should have checked the schematic to begin with. Taking this new finding into account I went through the SW4 settings you suggested:

burchmere said:

SW4[1:6] = sys_boot[0:5] = 011001 = OK (in TRM order sys_boot[5:0] = 100110)

Same. Just so we are clear, taking the inversion into account, this setting is what the picture posted in an earlier thread shows.

burchmere said:

SW4[1:6] = sys_boot[0:5] = 011000 = OK (in TRM order sys_boot[5:0] = 000110)

Same

burchmere said:

SW4[1:6] = sys_boot[0:5] = 011100 = hangs after "Texas Instruments X-Loader 1.41  X-Loader hangs" (in TRM order sys_boot[5:0] = 001110)

No response (nothing on terminal), with this setting I have just switches 1, 5, and 6 set to on to be clear.

burchmere said:

SW4[1:6] = sys_boot[0:5] = 101101 = hangs after "Texas Instruments X-Loader 1.41  X-Loader hangs" (in TRM order sys_boot[5:0] = 101101)

Same

burchmere said:

SW4[1:6] = sys_boot[0:5] = 011101 = hangs after "Texas Instruments X-Loader 1.41  X-Loader hangs" (in TRM order sys_boot[5:0] = 101110)

Same

burchmere said:

SW4[1:6] = sys_boot[0:5] = 000111 (and most other valid settings) = hangs after "Texas Instruments X-Loader 1.41" (this is what you reported has showing nothing?)

Same. I get nothing if I use effectively 111000, i.e. switches 4, 5, and 6 only on.

Bernie,

I put some debug into x-loader to help determine what's going on.  I build x-loader no problem, sign it with 'signGP' and put it on the SD card, but the OMAP won't boot with it - nothing is printed on console.  I can put the x-load.bin.ift provided with OMAP35x_SDK_1.0.0 on the SD card and it boots fine.  FYI, the EVM had SDK-0.9.5 code on it when we received it, but I have since updated u-boot, kernel and rootfs with SDK-1.0.0 code - I don't believe I ever updated the x-loader code.  I've checked file sizes between the two images and they're 64 bytes different in size.

Any ideas what might be going wrong?  Have you built the SDK-1.0.0 x-load code and run it successfully?  Help!

Super!

I just tried this out, I rebuilt X-Loader in my SDK 1.0 install and it appears to work on the SD card just fine. I used the following commands:

cd ~/OMAP35x_SDK_1.0.0/board_utilities/x-load
make omap3evm_config
make
cp x-load.bin ~/OMAP35x_SDK_1.0.0/board_utilities/linux_host/
cd ~/OMAP35x_SDK_1.0.0/board_utilities/linux_host/
signGP

Actually I did one more step in there because my signGP prebuilt binary was not working properly for some reason, so I rebuilt it with 'gcc signGP.c' and ran the resulting binary, after this it signed the x-load.bin to make x-load.bin.ift and I took that file and put it on the boot partition of my SD card and renamed it mlo.

This also verifies that the MMC boot is supported in the default x-load build, there is nothing special about the mlo file.

EDIT: another quick thought, if it is not working it may be worth a shot to try 'make clean' before doing the build.

That's pretty much the process I went through, except I had no problems with signGP.  In fact, I even started with 'make distclean'.  I'll repeat again to see if it was operator errror.  If not, could I send you my x-load.bin and let you binary compare it to yours and/or try it on your SD card?  I suppose it's possible that the single 'printf' I put in is causing problems, so I'll remove that and try.

Thanks.

I posted the mlo I built today in my profile here so you can do a comparison to your own if you like. Feel free to post your mlo and I can try it on my board here. Just adding a printf should not cause a failure by my understanding, it already uses printf to display the messages that it is already printing out.

I've got it working now.  I built a new x-loader without the printf and it was OK.  Apparently I'd put the printf in a spot prior to the initialization of UART (so something was unhappy enough that the code hung).  I've now added the debug code in another area and all is well.  Plus, I now see that x-loader (in board/omap3evm/omap3evm.c) only allows MMC booting with sys_boot[4:0] values of 3 and 6.  So as we speculated, the fact that the EVM doesn't boot under all the possible sys_boot settings that include MMC1 is an x-loader code issue, not a ROM code issue.

Thanks for your help.

I am glad to hear it is working, that would explain a printf failure.

I also see the code you mentioned in omap3evm.c which explains why it only works in certain cases, it looks like X-Loader is using the sys_boot value to determine how it executes, so it does not know it was loaded out of MMC unless you use 3 or 6. With this discovery it should be easy to modify the X-Loader to assume it is booting from MMC in other sys_boot settings, have you tried doing a modification and if so was it successful?

I have not tried modifying that code yet; eventually I will but it could be several weeks.  What must be happening is that the ROM code should (and probably is) loading x-loader correctly from MMC1 when sys_boot is set accordingly.  But since x-loader then configures GPIO and various other functionality of the chip based on it's own interpretation of the sys_boot value, it may or may not execute properly, and may or may not be able to load/run the second stage boot loader (u-boot).  I'm not quite sure why x-loader's interpretation of sys_boot values wasn't written to duplicate ROM code's interpretation.

I'll keep you posted.

Sorry for dredging up an old thread.  Does anyone know the background on why x-loader was written the way it was for handling the sys_boot[4:0] value and determining how to boot from there?  As the thread above shows, the code in omap3evm.c/get_mem_type() only allows booting from MMC1 (assuming OneNAND flash) if sys_boot[4:0] = 0x03 or 0x06.  But 0x03 is shown as "reserved" in the TRM, and why not allow 0x0D, 0x0E, 0x0F, 0x10, 0x11, 0x12, and 0x18?  They all include MMC1 as a boot source.

I'm in the midst of modifying the code and feel like I'm missing something about how x-loader works.