From: Marc H. <mhu...@lo...> - 2010-01-22 19:32:29
|
Have you tried formating the SD card right on the overo then moving the files from the pc to the SD card. ---------------------------------------- From: "NoelStephens" <no...@ni...> Sent: Friday, January 22, 2010 1:59 PM To: gum...@li... Subject: Re: [Gumstix-users] WinCE Adeneo Demo Over BSP (Booting Issues) Help...? Thanks Joel! Ahh, one of the tech guys at Adeneo (who has been trying to help my odd-ball situation) verified this, but also included that actually the XLDRSD.nb0 file is appended at the end of the xldrtocsd.raw file, and the sum of the two makes the MLO (at least in the case of the TI SDK). The raw file must hold some specific information that clues the OMAP35xx (haven't read all TI Docs on this as of yet) how to handle the XLDRSD or is some form of initialization for the nb0. Either case, I have been reviewing through the SDK and without breaking any NDA specific information I am coming to the conclusion that it might be SD Disk Geometry specific...at least in my situation relative to the Adeneo issues...as I am using a Kingston SD-C02G and it seems that many people are using Sandisks...the folks at Adeneo can just format the SD cards as FAT32 under WinXP, copy the MLO, copy the EBOOT.nb0, and then the NK.bin and take that SD card (Sandisk) and the same Overo-Fire and Tobi expansion board loads it just fine with their MLO. Sooo... since the SD-C02G Kingston "works" and is of the right "kind" of SD Memory card, and after reviewing through the SD Initialization code...it very well could be that someone at Adeneo...a long time ago...hardcoded specific geometry that happened to be a "default" for Sandisk but was different than the Kingston line, and as such I am not able to simply format my Kingston and copy the MLO and EBOOT.nbo over as they are because the disk geometry needs to be identical to their disk geometry (much like that which is required by the Over Linux demo...but seeing as I already tried that geometry configuration it seems theirs is different). It sort of makes sense, as the MLO (first record in the MBR and small enough to possibly "miss" the block size limit) and as such the MLO loads just fine...but then the EBOOT does not because that would require actually scanning past the very first block of the SD. Which is now what I am looking into... :) If you happen to know anything about this or my "guess" is just silly... please do correct me as I would much rather be silly for a moment than dumb for a lifetime! ;) Cheers, Noel Hi Noel, I recently documented using the TI EVM (BSQUARE) BSP on the BeagleBoard. It should directly apply to the Gumstix Overo hardware, short a few minor changes. http://evmonbeagle.codeplex.com/ For your Adeneo demo I would expect XLDR, EBOOT, and NK.bin to be required. Regarding MLO check the associated XLDR makefile.inc. I suspect it only copies XLDRSD.nb0 to MLO when WINCEDEBUG=RETAIL. If you use RETAIL XLDRSD.nb0 -> MLO, then it needs to be first file written to SD card after FAT32 format. Single partition. -- View this message in context: http://old.nabble.com/WinCE-Adeneo-Demo-Over-BSP-%28Booting-Issues%29-Help.. .--tp27263059p27278431.html Sent from the Gumstix mailing list archive at Nabble.com. ---------------------------------------------------------------------------- -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |