Booting x-loader from SDHC card

While I cannot say exactly why yours is not working, I can say that 3530 vs 3503 should have no impact on if a board can boot from the SD card slot, if there is a difference in hardware it will be at the PCB level. I don't know of any errata for SDHC booting but all the SD cards I use for booting are 2GB, if your 4GB works in the Beagle but not your own board you may want to check on the hardware differences if any, in particular I would look at the bootmode pins on the Beagle vs your own board, the different boot modes bring up peripherals in different orders and that may be impacting your particular case.

Thanks Bernie.  The confirmation that 3530 and 3503 are identical in this area is useful, as is the lack of errata regarding SDHC booting.

If different boot mode between our board and Beagle were the problem (or at least part of the problem), then why can we boot 2G non-SDHC cards without difficulty?  If the peripherals come up in different order based on boot mode, then any problem related to the order of peripherals coming up should occur for the 2G non-SDHC as well as the 4G SDHC, should it not?

Interestingly, we got a small batch of proto boards in today, and one of them *does* boot the 4Gb card.  The rest do not.  We can't find any obvious difference with the one that boots.  I may have to get a bunch of 4Gb cards and try the same sw on different cards.  But this is smelling like a marginal timing kind of issue...

Ken Brown said:

If different boot mode between our board and Beagle were the problem (or at least part of the problem), then why can we boot 2G non-SDHC cards without difficulty?  If the peripherals come up in different order based on boot mode, then any problem related to the order of peripherals coming up should occur for the 2G non-SDHC as well as the 4G SDHC, should it not?

Most likely it would impact both cards, though that is also somewhat dependent on the boot loader, I have had cards for different OSes that will boot under some SD card boot mode settings and not others (namely a Windows CE SD card) which is what brought this to my mind.

Ken Brown said:

We can't find any obvious difference with the one that boots.  I may have to get a bunch of 4Gb cards and try the same sw on different cards.  But this is smelling like a marginal timing kind of issue...

That does sound like some kind of marginal issue, perhaps your larger cards are negotiating to run at a higher speed that is pushing them over the edge, you might try alternative 4GB and 2GB cards if you have them around to see if otehr types of cards work.

I have also run into various card types that just dont like to work at all, most of my cards now are generic Micro Center brand cards, though in general the cards I have had not work, never work, as opposed to this on some boards over others.  

Bernie Thompson said:

Most likely it would impact both cards, though that is also somewhat dependent on the boot loader, I have had cards for different OSes that will boot under some SD card boot mode settings and not others (namely a Windows CE SD card) which is what brought this to my mind.

Agreed.  The boot loader in question is the internal boot rom of the OMAP 3503, so since the source for that isn't public (to my knowledge anyway, I'd love a pointer if it is out there somewhere), it's kinda hard to dig any further on that point.

Bernie Thompson said:

That does sound like some kind of marginal issue, perhaps your larger cards are negotiating to run at a higher speed that is pushing them over the edge, you might try alternative 4GB and 2GB cards if you have them around to see if otehr types of cards work.

I have also run into various card types that just dont like to work at all, most of my cards now are generic Micro Center brand cards, though in general the cards I have had not work, never work, as opposed to this on some boards over others.  

These are SanDisk cards, FWIW.  Might have to make a trip to Frys to pick up a broader selection...

Ken Brown said:

Agreed.  The boot loader in question is the internal boot rom of the OMAP 3503, so since the source for that isn't public (to my knowledge anyway, I'd love a pointer if it is out there somewhere), it's kinda hard to dig any further on that point.

I was thinking more along the lines of x-loader, it might expect some other hardware block to be initialized by the RBL and hang if it is not which is why ordering could matter. Unfortunately the source is not out there for the RBL, the closest you could get is the TRM documentation but it probably will not help all that much for this sort of debugging.

Ken Brown said:

These are SanDisk cards, FWIW.

I have heard people using SanDisk for other benchmarking before successfully, I have also heard of problems with the Fry's brand/Patriot cards but that is really just a rumor as I have only worked with the Micro Center cards.

Bernie Thompson said:

I was thinking more along the lines of x-loader, it might expect some other hardware block to be initialized by the RBL and hang if it is not which is why ordering could matter. Unfortunately the source is not out there for the RBL, the closest you could get is the TRM documentation but it probably will not help all that much for this sort of debugging.

So you're speculating that the RBL sets up hardware blocks one way if it finds an SDHC card, but another way if it finds a standard SD card?  That seems rather unlikely to me, though there's no way to really know without RBL source.

Interestingly, I just got a Frys/Patriot 4G SDHC, and it boots on a board where a SanDisk 4G SDHC does not.  More evidence for a timing issue - the Frys is class 4, whereas the Sandisk is class 2.  My money is on the timing problem theory.

Thanks for your thoughts Bernie!

All I know about the boot ROM is that it will read a number of blocks and look for the MLO directory entry.  If the directory entry is after the number of blocks read, then the ROM code gives up and won't boot.  The geometry of the card plays into this.  I can't remember how exactly, but it is possible to have the FAT file system such that the directory entries could be outside the range of what the ROM code reads.

I would suggest that if the card doesn't boot, then try changing the geometry.  There is an HP formatting utility mentioned on beagleboard.org.  Download that and use it to format the card.  It will change the geometry of it, too.  I used to have a link to a site that had another way of changing the geometry, but it involved advanced features of fdisk.  Using the HP utility on Windows is a lot easier.

I have had cards of various sizes and speeds that would not boot right out of the package. Changing the geometry fixed the problem.

Steve K.

Steve Kipisz said:

All I know about the boot ROM is that it will read a number of blocks and look for the MLO directory entry.  If the directory entry is after the number of blocks read, then the ROM code gives up and won't boot.  The geometry of the card plays into this.  I can't remember how exactly, but it is possible to have the FAT file system such that the directory entries could be outside the range of what the ROM code reads.

Thanks for the suggestion.   Because the exact same card will boot in the Beagle, and on some (but not all) of our boards,  I think I can pretty much eliminate the card geometry as a factor.

Steve Kipisz said:

I would suggest that if the card doesn't boot, then try changing the geometry.  There is an HP formatting utility mentioned on beagleboard.org.  Download that and use it to format the card.  It will change the geometry of it, too.  I used to have a link to a site that had another way of changing the geometry, but it involved advanced features of fdisk.  Using the HP utility on Windows is a lot easier.

Yeah, I have the HP utility.  That's how I formatted this card.  :-)

Ken,

I have personally used Sandisk 4Gb SDHC card (borrowed from a camera) on Beagle and OMAP3 few months ago. Don't have it with me know to quote more details :(

Can you tell me the uboot and xloader versions you are using?

Best regards,
Sanjeev

xloader and uboot are derived from PSP-SDK-02.01.01.08.  Being the engineer that I am, I've been unable to resist modifying them.  :-)

But, the issue is whether the xloader on the SDHC card will be found by the boot rom.  So I don't think my changes to xloader are responsible.

As I said in earlier posts, the fact that a) a class 4 SDHC card boots where a class 2 does not (admittedly, from different manufacturers) and b) even the class 2 card boots on a few of our boards (but not all) suggests that there is some sort of marginal timing issue on our board.  At least, if I were a betting man (and I am!) that's where I'd be placing my bets.

Hi Ken,

In order to check for a marginal timing issue, I would recommend you to try to cool/heat the card and/or the OMAP and see if it changes anything. I have previously had SD cards laying just on the edge of the SD spec. This together with a bad PCB layout for one of the nets made a situation where the OMAP (Didn't check with ROM code SW though) couldn't understand what the card did send because of a wrongly received CRC-value.

Cooling the cards made them work all the time - Give it a try - I shouldn't take many seconds and might reveal important information [:)]
  Søren

Ken Brown said:

So you're speculating that the RBL sets up hardware blocks one way if it finds an SDHC card, but another way if it finds a standard SD card?  That seems rather unlikely to me, though there's no way to really know without RBL source.

Not really, my thought was more geared toward if you had a situation where one board boots SD cards and another never boots the same SD cards, as I have had certain cards that require certain boot modes to boot and since boot mode can vary from board to board that could be one potential area to verify for SD card booting in general, in your case this is not qute there since you do have cards that will boot with the same software so I should have been a bit more clear on what I was trying to say, you are correct that the RBL should configure hardware blocks the same regardless of the size of the SD card (apart from the SD controller itself). I agree that everything you have seen points toward some marginal timing issue, I like the idea of heating/cooling the card Søren suggested to verify this if you happen to have some freeze spray handy.

Søren Steen Christensen said:

Hi Ken,

In order to check for a marginal timing issue, I would recommend you to try to cool/heat the card and/or the OMAP and see if it changes anything. I have previously had SD cards laying just on the edge of the SD spec. This together with a bad PCB layout for one of the nets made a situation where the OMAP (Didn't check with ROM code SW though) couldn't understand what the card did send because of a wrongly received CRC-value.

Cooling the cards made them work all the time - Give it a try - I shouldn't take many seconds and might reveal important information
  Søren

Well, my hardware engineer just got back to me, and for us it's the heat gun that makes things happier, not the freeze spray.

But definitely, varying the temperature changes the results, again pointing to some sort of marginal timing.

We have some rework in that area of the board, so the timing problem could be related to that rework.  The rework will go away in the next rev of the board, so I guess we'll just reexamine the problem when we get the next rev back.

Thanks to everyone for your ideas!

Ken

First of all, glad that my idea helped [:)]

Secondly:  Dependent on the type of rework you have in the board area, I wouldn't be too sure the problem just disappears by itself. And "wasting" a PCB spin just hoping isn't recommendable (at least not in my way of thinking.)

Unless your HW guys are pretty sure it's because of the rework I would spend a little more time trying to figure out that actually changes when heating up and if this is somehow related to the rework or the part of the PCB layout you think is OK. This might in the end save you a PCB spin (and thereby time and costs). My experience tell, that hoping SI-related problems disappear by themselves from one PCB spin to the next is normally a bad rule of thumb. [:)]

Good luck
  Søren