From: Adam R. <w00...@um...> - 2012-01-19 08:12:11
|
Good afternoon, Well, after a great deal of fun, I discovered that there is nothing wrong with the Sakoman script (no surprises there, really, it always had to be a problem right here in this seat!). Instead, I was rather intrigued to find that it was a problem related to the SDCard slot on my old laptop. Note the "old" part - I am now running Linux on my newer laptop (roughly 12 months old) and I was able to make the SDCard work correctly. Of course, I did buy another SDCard for confirmatory purposes, to ensure I hadn't killed my original card (I hadn't). I still have to replace my power supply, and the Overo still gets pretty warm, but I'm running it with the old power supply atm with no problems and I've got the Overo sitting right above the 20cm exhaust fan of my main (Windoze) machine, so keeping it cool is now less of a problem. Thanks to Blaine and Arlen for their suggestions. Adam. On 12/01/2012 7:03 AM, Arlen Raasch wrote: > Your sd card may have a partial filesystem on it that is stopping the > great Sakoman script from properly creating what it needs to. > > To solve this, use the linux dd utility to zero out the first part of > the sd card. > > You will need to know the linux device name for the entire sd card to do this. > > If you are at all unsure of yourself in this regard, don't continue as > you can be left with an unbootable desktop linux box if you mess this > up. > > To determine what your device name is, type dmesg without the sd card > inserted to familiarize yourself with the section at the end of what > dmesg outputs, then insert the sd card. > > Wait a few seconds for the system to attempt to mount the sd card and > issue another dmesg. > > You will see something refering to sdb or sdc etc. at the end of the > output that dmeg gave you the second time. > > You can also type mount before and after and look for new device names. > > Be aware that mount will show /dev/sdb1 meaning the first partition on > device /dev/sdb for instance. > > You would want to use /dev/sdb to dd to in this case. > > Do this very carefully, as dd must be ran as root and you can just as > easily remove your filesystem on your linux box. > > The command to wipe the first part of your sd card is: > > sudo dd if=/dev/zero of=/dev/whatever_your_sd_card_device_name_is > bs=1024 count=1048576 > > This will erase the first one gig of your sd card, totally wiping the > partition table and any remnants of partially formed filesystems that > may be on the first part of the sd card. > > *DO GET THE DEVICE NAME RIGHT, THOUGH*, or you will be sorry. > > Then, use the Sakoman script to make the new image on the sd card. > > Don't be in a big hurry to remove the sd card from the machine when > the script says it has finished, however. > > In a perfect world, you could, but this is not a perfect world. > > Linux is a buffering system, it is possible that information is still > being sent by the host pc to the sd card, so give it some extra time > to be safe. > > You can safely issue these commands to indicate to the linux box you > want to eject the device safely: > > sudu sync > sudu eject /dev/whatever_your_sd_card_device_name_is > > But, even after the system indicates that it has completed these > tasks, still don't get in a hurry to remove the sd card from the > system. > > There is a tiny microcontroller inside the sd card as well as the sd > card writer that can do a limited amount of buffering, give them some > time to finish writing. (It can't hurt to wait a bit). > > These steps have made the difference in working bootable sd cards and > ones that won't boot for me. > > > > Note: The sustained write speed of sd cards is a lot slower than one > would expect given the speed ratings as shown on the sd card package. > (marketing at its best) > > To see what speed your sd card is capable of being written to, and to > give yourself something to do when it is zeroing out the first gig of > your sd card, you can tell dd to indicate its progress to you by > sending it a USR1 signal. > > In another terminal window on your linux pc type: > > ps ax | grep d[d] > > The number on the left of the line is the dd process id. > > To tell dd you want a progress update, type the following in the same > window you did the ps command in: > kill -USR1 dd_process_id > > Look in the window that dd is running in for an update of its prgress > and the speed it is able to write to the sd card. > > > Also, do remember to erase the overo NAND area as indicated in the wiki. > > Good luck. > -Arlen > > > On Tue, Jan 10, 2012 at 6:23 PM, Blaine<fr...@gm...> wrote: >> Did you ever actually flash the overo? Booting from the card does not flash >> it, it's only a temporary boot unless you did other measures >> to permanently flash the software into the overo. >> >> Without the SD card plugged in, does it boot correctly? >> >> Blaine >> >> >> >> On Tue, Jan 10, 2012 at 6:30 AM, Adam Read<w00...@um...> >> wrote: >>> Good evening all, >>> >>> Well, I've been beating my head against this wall for a while now, and >>> concede that it now hurts quite a lot. Before we go any further, I'm a >>> complete muppet/newbie when it comes to Linux and Overo, and I'm trying >>> to learn Linux in a hurry so no doubt I'll come unstuck. That aside, >>> however..... >>> >>> I purchased an Overo Water and Tobi board about a month ago, but hadn't >>> done all that much to it, beyond connecting to it via the USB console >>> port, and trying to get a bootable micro SDCARD working (it still >>> doesn't). I had not attempted to connect it to a monitor until >>> yesterday, as I was just checking to see what the console looked like. >>> The monitor remains blank even though the Overo has power applied to it, >>> so I don't know if this is a new thing from my playing or not. >>> >>> I have tried, multiple times, to build the bootable SDcard from the >>> sakoman website, but it hasn't worked yet. Having downloaded the 429Mb >>> (roughly) file some dozen times, I must admit I'm getting pretty weary >>> of it all, and I don't have the knowledge or experience to tell it to >>> use previously downloaded copies. >>> >>> Anyways, I now have two problems, and I'm really hoping someone can >>> point me in the right direction. >>> >>> First, the Overo gives me an error over the console when it reaches the >>> overo login part - "JFFS2 notice: (965) check_node_data: wrong data CRC >>> in data node at 0x19a7e4c4: read 0x9ae87ba3, calculated 0x72b03a51." >>> This is a new development on the board, and has only been occuring the >>> last hour or so. As far as I know, the bootable sdcard hasn't actually >>> been working correctly, could this have hosed the overo? >>> >>> Second, I keep getting an "improper partitioning on /dev/mmcblk0" >>> message when I try to run Steve Sakoman's mksdcard.sh script. I'm >>> guessing I need a new sdcard, that or I've done something wrong. >>> >>> Any help would be appreciated, and if anyone needs further information >>> then please let me know what commands to plug into the console (remember >>> that I have absolutely no idea). >>> >>> Cheers, >>> Adam. >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Write once. Port to many. >>> Get the SDK and tools to simplify cross-platform app development. Create >>> new or port existing apps to sell to consumers worldwide. Explore the >>> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join >>> http://p.sf.net/sfu/intel-appdev >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> >> ------------------------------------------------------------------------------ >> Write once. Port to many. >> Get the SDK and tools to simplify cross-platform app development. Create >> new or port existing apps to sell to consumers worldwide. Explore the >> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join >> http://p.sf.net/sfu/intel-appdev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |