From: mlq <mar...@lm...> - 2010-03-19 14:21:08
|
Hi, I have the 2.6.31 OE kernel up and running on the verdex board (thanks to all who made this hapen!!!). I have a gumstix-factory script in the partition with the uimage. When I power up sometimes the verdex boots from the flash and others it boots from the microSD. I am using the latest u-boot for the verdex. Is there a way to ensure the microSD is always booted? It seems like the microSD isnt mounting fast enough and/or the mmcinit is failing (although I think its the later becuase i dont see the u-boot message stating that it found the script). Thanks, mlq -- View this message in context: http://old.nabble.com/Booting-from-microSD-on-the-verdex-tp27950970p27950970.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: <cod...@gm...> - 2010-03-19 16:56:52
|
I believe there needs to be a space between mmc and init. I'm running Gumstix Overo, and I've found if my bootargs variable does not have a space, the SD card fails to boot. For example: Before: ------------------ overo# printenv bootargs = if mmcinit;.... <other environment variables> . . . overo# Add a space: overo# setenv bootargs="if mmc init;..." overo# printenv <other environment variables> bootargs = if mmc init;...... . . . overo# boot This should then boot from the SD card if it's inserted, at least in my experience. Note: I put "..." at the end of bootargs since there is much more text, but don't have my Gumstix available at the moment to capture that text. Just get that from 'printenv' On Fri, Mar 19, 2010 at 10:21 AM, mlq <mar...@lm...> wrote: > > Hi, > > I have the 2.6.31 OE kernel up and running on the verdex board (thanks to > all who made this hapen!!!). I have a gumstix-factory script in the > partition with the uimage. When I power up sometimes the verdex boots from > the flash and others it boots from the microSD. I am using the latest > u-boot for the verdex. Is there a way to ensure the microSD is always > booted? It seems like the microSD isnt mounting fast enough and/or the > mmcinit is failing (although I think its the later becuase i dont see the > u-boot message stating that it found the script). > > Thanks, > mlq > -- > View this message in context: > http://old.nabble.com/Booting-from-microSD-on-the-verdex-tp27950970p27950970.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Ash C. <as...@gu...> - 2010-03-20 09:51:19
|
Hi mlq, Coderone suggestion about 'mmc init' versus 'mmcinit' is true for newer version of u-boot (i.e. what you might have on the Overo boards) but 'mmcinit' is still the right command for u-boot version 1.2.0--the latest for the Verdex line. Can you try to isolate when exactly this happening as it seems a little strange? Perhaps stopping the boot sequence and ensuring that these commands cause the new kernel to boot would be useful: $ mmcinit $ fatload mmc 0 a2000000 uimage $ setenv bootargs console=/dev/ttyS0,115200n8 root=/dev/mmcblk0p2 rw rootdelay=1 $ bootm a2000000 I can't remember offhand if gumstix-factory.script adds a 'rootdelay' to the kernel command line or not; this is potentially an issue. -Ash On Fri, Mar 19, 2010 at 7:21 AM, mlq <mar...@lm...> wrote: > > Hi, > > I have the 2.6.31 OE kernel up and running on the verdex board (thanks to > all who made this hapen!!!). I have a gumstix-factory script in the > partition with the uimage. When I power up sometimes the verdex boots from > the flash and others it boots from the microSD. I am using the latest > u-boot for the verdex. Is there a way to ensure the microSD is always > booted? It seems like the microSD isnt mounting fast enough and/or the > mmcinit is failing (although I think its the later becuase i dont see the > u-boot message stating that it found the script). > > Thanks, > mlq > -- > View this message in context: http://old.nabble.com/Booting-from-microSD-on-the-verdex-tp27950970p27950970.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: mlq <mar...@lm...> - 2010-03-25 21:43:20
|
Hi Ash, Here is what happens when I execute the below commands: *** Welcome to Gumstix *** DRAM: 64 MB Flash: 16 MB Hit any key to stop autoboot: 0 GUM> mmcinit No MMC card found GUM> mmcinit Detected: 1927168 blocks of 1024 bytes (1882MB) SD card. Vendor: Man 02 OEM TM "SA02G" Date 10/2009 Product: 2628934609 Revision: 0.3 GUM> fatload mmc 0 a2000000 uimage reading uimage 1319096 bytes read GUM> setenv bootargs console=/dev/ttyS0,115200n8 root=/dev/mmcblk0p2 rw rootdelay=1 GUM> bootm a2000000 ## Booting image at a2000000 ... Image Name: Angstrom/2.6.31/gumstix-verdex Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1319032 Bytes = 1.3 MB Load Address: a0008000 Entry Point: a0008000 OK Starting kernel ... Uncompressing Linux.................................................................................... done, booting the kernel. .-------. | | .-. | | |-----.-----.-----.| | .----..-----.-----. | | | __ | ---'| '--.| .-'| | | | | | | | |--- || --'| | | ' | | | | '---'---'--'--'--. |-----''----''--' '-----'-'-'-' -' | '---' The Angstrom Distribution gumstix-verdex ttyS0 Angstrom 2009.X-test-20100317 gumstix-verdex ttyS0 gumstix-verdex login: root Password: root@gumstix-verdex:~# I think some people get thrown off that it nothing is printed out after the decompression step. As you can see the first call to mmcinit did not find the mmc card. I tried to modify the gumstix-factory-script but I got a "bag magic number" error. What is the correct way to do this? I just want to always boot from the mmc, any other ways to ensure this always happens? Thanks! mlq Ash Charles-2 wrote: > > Hi mlq, > > Coderone suggestion about 'mmc init' versus 'mmcinit' is true for > newer version of u-boot (i.e. what you might have on the Overo boards) > but 'mmcinit' is still the right command for u-boot version 1.2.0--the > latest for the Verdex line. > > Can you try to isolate when exactly this happening as it seems a > little strange? Perhaps stopping the boot sequence and ensuring that > these commands cause the new kernel to boot would be useful: > $ mmcinit > $ fatload mmc 0 a2000000 uimage > $ setenv bootargs console=/dev/ttyS0,115200n8 root=/dev/mmcblk0p2 rw > rootdelay=1 > $ bootm a2000000 > > I can't remember offhand if gumstix-factory.script adds a 'rootdelay' > to the kernel command line or not; this is potentially an issue. > > -Ash > > On Fri, Mar 19, 2010 at 7:21 AM, mlq <mar...@lm...> wrote: >> >> Hi, >> >> I have the 2.6.31 OE kernel up and running on the verdex board (thanks to >> all who made this hapen!!!). I have a gumstix-factory script in the >> partition with the uimage. When I power up sometimes the verdex boots >> from >> the flash and others it boots from the microSD. I am using the latest >> u-boot for the verdex. Is there a way to ensure the microSD is always >> booted? It seems like the microSD isnt mounting fast enough and/or the >> mmcinit is failing (although I think its the later becuase i dont see the >> u-boot message stating that it found the script). >> >> Thanks, >> mlq >> -- >> View this message in context: >> http://old.nabble.com/Booting-from-microSD-on-the-verdex-tp27950970p27950970.html >> Sent from the Gumstix mailing list archive at Nabble.com. >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Booting-from-microSD-on-the-verdex-tp27950970p28035295.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Ash C. <as...@gu...> - 2010-03-26 01:00:44
|
Hi mlq, U-Boot scripts require a special header that includes a CRC (or something) over the contents of the script...modified code->bad magic number. I've put some instructions on the wiki here about how to make your own magic boot scripts. http://www.gumstix.net/wiki/index.php?title=U-Boot In retrospect, the 'boot.scr' is overo-focussed however this line is pretty generic: $ mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "myscript" -d myscript.cmd boot.scr I'm surprised you get no output after the decompression step---that would be very disconcerting! On my setup, I get lots of kernel chatter....I wonder what is different. Thanks for the feedback. Cheers, Ash On Thu, Mar 25, 2010 at 2:43 PM, mlq <mar...@lm...> wrote: > > Hi Ash, > > Here is what happens when I execute the below commands: > > *** Welcome to Gumstix *** > > DRAM: 64 MB > Flash: 16 MB > Hit any key to stop autoboot: 0 > GUM> mmcinit > No MMC card found > GUM> mmcinit > Detected: 1927168 blocks of 1024 bytes (1882MB) SD card. > Vendor: Man 02 OEM TM "SA02G" Date 10/2009 > Product: 2628934609 > Revision: 0.3 > GUM> fatload mmc 0 a2000000 uimage > reading uimage > > 1319096 bytes read > GUM> setenv bootargs console=/dev/ttyS0,115200n8 root=/dev/mmcblk0p2 rw > rootdelay=1 > GUM> bootm a2000000 > ## Booting image at a2000000 ... > Image Name: Angstrom/2.6.31/gumstix-verdex > Image Type: ARM Linux Kernel Image (uncompressed) > Data Size: 1319032 Bytes = 1.3 MB > Load Address: a0008000 > Entry Point: a0008000 > OK > > Starting kernel ... > > Uncompressing > Linux.................................................................................... > done, booting the kernel. > > .-------. > | | .-. > | | |-----.-----.-----.| | .----..-----.-----. > | | | __ | ---'| '--.| .-'| | | > | | | | | |--- || --'| | | ' | | | | > '---'---'--'--'--. |-----''----''--' '-----'-'-'-' > -' | > '---' > > The Angstrom Distribution gumstix-verdex ttyS0 > > Angstrom 2009.X-test-20100317 gumstix-verdex ttyS0 > > gumstix-verdex login: root > Password: > root@gumstix-verdex:~# > > I think some people get thrown off that it nothing is printed out after the > decompression step. As you can see the first call to mmcinit did not find > the mmc card. I tried to modify the gumstix-factory-script but I got a "bag > magic number" error. What is the correct way to do this? I just want to > always boot from the mmc, any other ways to ensure this always happens? > > Thanks! > mlq > > > Ash Charles-2 wrote: >> >> Hi mlq, >> >> Coderone suggestion about 'mmc init' versus 'mmcinit' is true for >> newer version of u-boot (i.e. what you might have on the Overo boards) >> but 'mmcinit' is still the right command for u-boot version 1.2.0--the >> latest for the Verdex line. >> >> Can you try to isolate when exactly this happening as it seems a >> little strange? Perhaps stopping the boot sequence and ensuring that >> these commands cause the new kernel to boot would be useful: >> $ mmcinit >> $ fatload mmc 0 a2000000 uimage >> $ setenv bootargs console=/dev/ttyS0,115200n8 root=/dev/mmcblk0p2 rw >> rootdelay=1 >> $ bootm a2000000 >> >> I can't remember offhand if gumstix-factory.script adds a 'rootdelay' >> to the kernel command line or not; this is potentially an issue. >> >> -Ash >> >> On Fri, Mar 19, 2010 at 7:21 AM, mlq <mar...@lm...> wrote: >>> >>> Hi, >>> >>> I have the 2.6.31 OE kernel up and running on the verdex board (thanks to >>> all who made this hapen!!!). I have a gumstix-factory script in the >>> partition with the uimage. When I power up sometimes the verdex boots >>> from >>> the flash and others it boots from the microSD. I am using the latest >>> u-boot for the verdex. Is there a way to ensure the microSD is always >>> booted? It seems like the microSD isnt mounting fast enough and/or the >>> mmcinit is failing (although I think its the later becuase i dont see the >>> u-boot message stating that it found the script). >>> >>> Thanks, >>> mlq >>> -- >>> View this message in context: >>> http://old.nabble.com/Booting-from-microSD-on-the-verdex-tp27950970p27950970.html >>> Sent from the Gumstix mailing list archive at Nabble.com. >>> >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > -- > View this message in context: http://old.nabble.com/Booting-from-microSD-on-the-verdex-tp27950970p28035295.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: mlq <mar...@lm...> - 2010-03-26 15:11:17
|
cool, I'll try making a new script later today and see if that works. I'm curious how u-boot actually interacts with these scripts? Is it a naming convention? Does the crc header load it to a special place in memory that u-boot checks? I am wondering how to debug whether the script is actally not found upon boot or If it is, and something within the script is failing. I don't always see the messge saying u-boot found the script... What I have been doing is powering on/off until the script actually takes; at this point I do see all the kernel chatter before the log in prompt I.e when the u-boot scripts gets run I always see kernel output - it's when I execute the commands manually that I don't. Perhaps Daves suggestion of using ttys0 will fix this. Ash Charles-2 wrote: > > Hi mlq, > > > U-Boot scripts require a special header that includes a CRC (or > something) over the contents of the script...modified code->bad magic > number. I've put some instructions on the wiki here about how to make > your own magic boot scripts. > > http://www.gumstix.net/wiki/index.php?title=U-Boot > > In retrospect, the 'boot.scr' is overo-focussed however this line is > pretty generic: > $ mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "myscript" -d > myscript.cmd boot.scr > > I'm surprised you get no output after the decompression step---that > would be very disconcerting! On my setup, I get lots of kernel > chatter....I wonder what is different. > > Thanks for the feedback. > > Cheers, > Ash > On Thu, Mar 25, 2010 at 2:43 PM, mlq <mar...@lm...> wrote: >> >> Hi Ash, >> >> Here is what happens when I execute the below commands: >> >> *** Welcome to Gumstix *** >> >> DRAM: 64 MB >> Flash: 16 MB >> Hit any key to stop autoboot: 0 >> GUM> mmcinit >> No MMC card found >> GUM> mmcinit >> Detected: 1927168 blocks of 1024 bytes (1882MB) SD card. >> Vendor: Man 02 OEM TM "SA02G" Date 10/2009 >> Product: 2628934609 >> Revision: 0.3 >> GUM> fatload mmc 0 a2000000 uimage >> reading uimage >> >> 1319096 bytes read >> GUM> setenv bootargs console=/dev/ttyS0,115200n8 root=/dev/mmcblk0p2 rw >> rootdelay=1 >> GUM> bootm a2000000 >> ## Booting image at a2000000 ... >> Image Name: Angstrom/2.6.31/gumstix-verdex >> Image Type: ARM Linux Kernel Image (uncompressed) >> Data Size: 1319032 Bytes = 1.3 MB >> Load Address: a0008000 >> Entry Point: a0008000 >> OK >> >> Starting kernel ... >> >> Uncompressing >> Linux.................................................................................... >> done, booting the kernel. >> >> .-------. >> | | .-. >> | | |-----.-----.-----.| | .----..-----.-----. >> | | | __ | ---'| '--.| .-'| | | >> | | | | | |--- || --'| | | ' | | | | >> '---'---'--'--'--. |-----''----''--' '-----'-'-'-' >> -' | >> '---' >> >> The Angstrom Distribution gumstix-verdex ttyS0 >> >> Angstrom 2009.X-test-20100317 gumstix-verdex ttyS0 >> >> gumstix-verdex login: root >> Password: >> root@gumstix-verdex:~# >> >> I think some people get thrown off that it nothing is printed out after >> the >> decompression step. As you can see the first call to mmcinit did not >> find >> the mmc card. I tried to modify the gumstix-factory-script but I got a >> "bag >> magic number" error. What is the correct way to do this? I just want to >> always boot from the mmc, any other ways to ensure this always happens? >> >> Thanks! >> mlq >> >> >> Ash Charles-2 wrote: >>> >>> Hi mlq, >>> >>> Coderone suggestion about 'mmc init' versus 'mmcinit' is true for >>> newer version of u-boot (i.e. what you might have on the Overo boards) >>> but 'mmcinit' is still the right command for u-boot version 1.2.0--the >>> latest for the Verdex line. >>> >>> Can you try to isolate when exactly this happening as it seems a >>> little strange? Perhaps stopping the boot sequence and ensuring that >>> these commands cause the new kernel to boot would be useful: >>> $ mmcinit >>> $ fatload mmc 0 a2000000 uimage >>> $ setenv bootargs console=/dev/ttyS0,115200n8 root=/dev/mmcblk0p2 rw >>> rootdelay=1 >>> $ bootm a2000000 >>> >>> I can't remember offhand if gumstix-factory.script adds a 'rootdelay' >>> to the kernel command line or not; this is potentially an issue. >>> >>> -Ash >>> >>> On Fri, Mar 19, 2010 at 7:21 AM, mlq <mar...@lm...> wrote: >>>> >>>> Hi, >>>> >>>> I have the 2.6.31 OE kernel up and running on the verdex board (thanks >>>> to >>>> all who made this hapen!!!). I have a gumstix-factory script in the >>>> partition with the uimage. When I power up sometimes the verdex boots >>>> from >>>> the flash and others it boots from the microSD. I am using the latest >>>> u-boot for the verdex. Is there a way to ensure the microSD is always >>>> booted? It seems like the microSD isnt mounting fast enough and/or the >>>> mmcinit is failing (although I think its the later becuase i dont see >>>> the >>>> u-boot message stating that it found the script). >>>> >>>> Thanks, >>>> mlq >>>> -- >>>> View this message in context: >>>> http://old.nabble.com/Booting-from-microSD-on-the-verdex-tp27950970p27950970.html >>>> Sent from the Gumstix mailing list archive at Nabble.com. >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Download Intel® Parallel Studio Eval >>>> Try the new software tools for yourself. Speed compiling, find bugs >>>> proactively, and fine-tune applications for parallel performance. >>>> See why Intel Parallel Studio got high marks during beta. >>>> http://p.sf.net/sfu/intel-sw-dev >>>> _______________________________________________ >>>> gumstix-users mailing list >>>> gum...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>> >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >> >> -- >> View this message in context: >> http://old.nabble.com/Booting-from-microSD-on-the-verdex-tp27950970p28035295.html >> Sent from the Gumstix mailing list archive at Nabble.com. >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Booting-from-microSD-on-the-verdex-tp27950970p28043860.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2010-03-26 16:40:55
|
Hi Mark, On Fri, Mar 26, 2010 at 8:11 AM, mlq <mar...@lm...> wrote: > > cool, I'll try making a new script later today and see if that works. I'm > curious how u-boot actually interacts with these scripts? Is it a naming > convention? Does the crc header load it to a special place in memory that > u-boot checks? I am wondering how to debug whether the script is actally > not found upon boot or If it is, and something within the script is failing. > I don't always see the messge saying u-boot found the script... > > What I have been doing is powering on/off until the script actually takes; > at this point I do see all the kernel chatter before the log in prompt I.e > when the u-boot scripts gets run I always see kernel output - it's when I > execute the commands manually that I don't. Perhaps Daves suggestion of > using ttys0 will fix this. Make sure you use ttyS0 (small letters for tty, capital S, zero). -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: Ash C. <as...@gu...> - 2010-03-26 17:07:50
|
Hi mlq, I think you are asking 'what makes this script special that U-Boot automagically runs it on boot?' so I'll answer this question for Verdex. In short, the script is not special at all---it is just a regular U-Boot script---the boot command ${bootcmd} set up as an environment variable automatically sources a script named gumstix-factory.script if available on boot. Of course, you can change the U-Boot environment variables around to whatever you like including changing what ${bootcmd} does. HTH, Ash On Fri, Mar 26, 2010 at 8:11 AM, mlq <mar...@lm...> wrote: > > cool, I'll try making a new script later today and see if that works. I'm > curious how u-boot actually interacts with these scripts? Is it a naming > convention? Does the crc header load it to a special place in memory that > u-boot checks? I am wondering how to debug whether the script is actally > not found upon boot or If it is, and something within the script is failing. > I don't always see the messge saying u-boot found the script... > > What I have been doing is powering on/off until the script actually takes; > at this point I do see all the kernel chatter before the log in prompt I.e > when the u-boot scripts gets run I always see kernel output - it's when I > execute the commands manually that I don't. Perhaps Daves suggestion of > using ttys0 will fix this. > > > > Ash Charles-2 wrote: >> >> Hi mlq, >> >> >> U-Boot scripts require a special header that includes a CRC (or >> something) over the contents of the script...modified code->bad magic >> number. I've put some instructions on the wiki here about how to make >> your own magic boot scripts. >> >> http://www.gumstix.net/wiki/index.php?title=U-Boot >> >> In retrospect, the 'boot.scr' is overo-focussed however this line is >> pretty generic: >> $ mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "myscript" -d >> myscript.cmd boot.scr >> >> I'm surprised you get no output after the decompression step---that >> would be very disconcerting! On my setup, I get lots of kernel >> chatter....I wonder what is different. >> >> Thanks for the feedback. >> >> Cheers, >> Ash >> On Thu, Mar 25, 2010 at 2:43 PM, mlq <mar...@lm...> wrote: >>> >>> Hi Ash, >>> >>> Here is what happens when I execute the below commands: >>> >>> *** Welcome to Gumstix *** >>> >>> DRAM: 64 MB >>> Flash: 16 MB >>> Hit any key to stop autoboot: 0 >>> GUM> mmcinit >>> No MMC card found >>> GUM> mmcinit >>> Detected: 1927168 blocks of 1024 bytes (1882MB) SD card. >>> Vendor: Man 02 OEM TM "SA02G" Date 10/2009 >>> Product: 2628934609 >>> Revision: 0.3 >>> GUM> fatload mmc 0 a2000000 uimage >>> reading uimage >>> >>> 1319096 bytes read >>> GUM> setenv bootargs console=/dev/ttyS0,115200n8 root=/dev/mmcblk0p2 rw >>> rootdelay=1 >>> GUM> bootm a2000000 >>> ## Booting image at a2000000 ... >>> Image Name: Angstrom/2.6.31/gumstix-verdex >>> Image Type: ARM Linux Kernel Image (uncompressed) >>> Data Size: 1319032 Bytes = 1.3 MB >>> Load Address: a0008000 >>> Entry Point: a0008000 >>> OK >>> >>> Starting kernel ... >>> >>> Uncompressing >>> Linux.................................................................................... >>> done, booting the kernel. >>> >>> .-------. >>> | | .-. >>> | | |-----.-----.-----.| | .----..-----.-----. >>> | | | __ | ---'| '--.| .-'| | | >>> | | | | | |--- || --'| | | ' | | | | >>> '---'---'--'--'--. |-----''----''--' '-----'-'-'-' >>> -' | >>> '---' >>> >>> The Angstrom Distribution gumstix-verdex ttyS0 >>> >>> Angstrom 2009.X-test-20100317 gumstix-verdex ttyS0 >>> >>> gumstix-verdex login: root >>> Password: >>> root@gumstix-verdex:~# >>> >>> I think some people get thrown off that it nothing is printed out after >>> the >>> decompression step. As you can see the first call to mmcinit did not >>> find >>> the mmc card. I tried to modify the gumstix-factory-script but I got a >>> "bag >>> magic number" error. What is the correct way to do this? I just want to >>> always boot from the mmc, any other ways to ensure this always happens? >>> >>> Thanks! >>> mlq >>> >>> >>> Ash Charles-2 wrote: >>>> >>>> Hi mlq, >>>> >>>> Coderone suggestion about 'mmc init' versus 'mmcinit' is true for >>>> newer version of u-boot (i.e. what you might have on the Overo boards) >>>> but 'mmcinit' is still the right command for u-boot version 1.2.0--the >>>> latest for the Verdex line. >>>> >>>> Can you try to isolate when exactly this happening as it seems a >>>> little strange? Perhaps stopping the boot sequence and ensuring that >>>> these commands cause the new kernel to boot would be useful: >>>> $ mmcinit >>>> $ fatload mmc 0 a2000000 uimage >>>> $ setenv bootargs console=/dev/ttyS0,115200n8 root=/dev/mmcblk0p2 rw >>>> rootdelay=1 >>>> $ bootm a2000000 >>>> >>>> I can't remember offhand if gumstix-factory.script adds a 'rootdelay' >>>> to the kernel command line or not; this is potentially an issue. >>>> >>>> -Ash >>>> >>>> On Fri, Mar 19, 2010 at 7:21 AM, mlq <mar...@lm...> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I have the 2.6.31 OE kernel up and running on the verdex board (thanks >>>>> to >>>>> all who made this hapen!!!). I have a gumstix-factory script in the >>>>> partition with the uimage. When I power up sometimes the verdex boots >>>>> from >>>>> the flash and others it boots from the microSD. I am using the latest >>>>> u-boot for the verdex. Is there a way to ensure the microSD is always >>>>> booted? It seems like the microSD isnt mounting fast enough and/or the >>>>> mmcinit is failing (although I think its the later becuase i dont see >>>>> the >>>>> u-boot message stating that it found the script). >>>>> >>>>> Thanks, >>>>> mlq >>>>> -- >>>>> View this message in context: >>>>> http://old.nabble.com/Booting-from-microSD-on-the-verdex-tp27950970p27950970.html >>>>> Sent from the Gumstix mailing list archive at Nabble.com. >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Download Intel® Parallel Studio Eval >>>>> Try the new software tools for yourself. Speed compiling, find bugs >>>>> proactively, and fine-tune applications for parallel performance. >>>>> See why Intel Parallel Studio got high marks during beta. >>>>> http://p.sf.net/sfu/intel-sw-dev >>>>> _______________________________________________ >>>>> gumstix-users mailing list >>>>> gum...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Download Intel® Parallel Studio Eval >>>> Try the new software tools for yourself. Speed compiling, find bugs >>>> proactively, and fine-tune applications for parallel performance. >>>> See why Intel Parallel Studio got high marks during beta. >>>> http://p.sf.net/sfu/intel-sw-dev >>>> _______________________________________________ >>>> gumstix-users mailing list >>>> gum...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://old.nabble.com/Booting-from-microSD-on-the-verdex-tp27950970p28035295.html >>> Sent from the Gumstix mailing list archive at Nabble.com. >>> >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > -- > View this message in context: http://old.nabble.com/Booting-from-microSD-on-the-verdex-tp27950970p28043860.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: mlq <mar...@lm...> - 2010-03-29 18:22:41
|
It looks like the mmc is not being mounted properly on certain boots. I get a error message from the 2.6.21 kernel which is in flash saying its unable to mount the mcc file system. This only happens occasionally on the first boot. If I reboot from the command line it picks up the mmc the second time around - which is weird. Any ideas what would cause this? Anyhow I added a line to one of the low level init.d scripts which simply reboots the board if it ever gets to that point; this essentially makes the flash un-bootable (I know, I know, big hack). This will always eventually boot from the mmc. Ash Charles-2 wrote: > > Hi mlq, > > I think you are asking 'what makes this script special that U-Boot > automagically runs it on boot?' so I'll answer this question for > Verdex. In short, the script is not special at all---it is just a > regular U-Boot script---the boot command ${bootcmd} set up as an > environment variable automatically sources a script named > gumstix-factory.script if available on boot. Of course, you can > change the U-Boot environment variables around to whatever you like > including changing what ${bootcmd} does. > > HTH, > > Ash > > On Fri, Mar 26, 2010 at 8:11 AM, mlq <mar...@lm...> wrote: >> >> cool, I'll try making a new script later today and see if that works. >> I'm >> curious how u-boot actually interacts with these scripts? Is it a naming >> convention? Does the crc header load it to a special place in memory >> that >> u-boot checks? I am wondering how to debug whether the script is actally >> not found upon boot or If it is, and something within the script is >> failing. >> I don't always see the messge saying u-boot found the script... >> >> What I have been doing is powering on/off until the script actually >> takes; >> at this point I do see all the kernel chatter before the log in prompt >> I.e >> when the u-boot scripts gets run I always see kernel output - it's when I >> execute the commands manually that I don't. Perhaps Daves suggestion of >> using ttys0 will fix this. >> >> >> >> Ash Charles-2 wrote: >>> >>> Hi mlq, >>> >>> >>> U-Boot scripts require a special header that includes a CRC (or >>> something) over the contents of the script...modified code->bad magic >>> number. I've put some instructions on the wiki here about how to make >>> your own magic boot scripts. >>> >>> http://www.gumstix.net/wiki/index.php?title=U-Boot >>> >>> In retrospect, the 'boot.scr' is overo-focussed however this line is >>> pretty generic: >>> $ mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "myscript" -d >>> myscript.cmd boot.scr >>> >>> I'm surprised you get no output after the decompression step---that >>> would be very disconcerting! On my setup, I get lots of kernel >>> chatter....I wonder what is different. >>> >>> Thanks for the feedback. >>> >>> Cheers, >>> Ash >>> On Thu, Mar 25, 2010 at 2:43 PM, mlq <mar...@lm...> wrote: >>>> >>>> Hi Ash, >>>> >>>> Here is what happens when I execute the below commands: >>>> >>>> *** Welcome to Gumstix *** >>>> >>>> DRAM: 64 MB >>>> Flash: 16 MB >>>> Hit any key to stop autoboot: 0 >>>> GUM> mmcinit >>>> No MMC card found >>>> GUM> mmcinit >>>> Detected: 1927168 blocks of 1024 bytes (1882MB) SD card. >>>> Vendor: Man 02 OEM TM "SA02G" Date 10/2009 >>>> Product: 2628934609 >>>> Revision: 0.3 >>>> GUM> fatload mmc 0 a2000000 uimage >>>> reading uimage >>>> >>>> 1319096 bytes read >>>> GUM> setenv bootargs console=/dev/ttyS0,115200n8 root=/dev/mmcblk0p2 rw >>>> rootdelay=1 >>>> GUM> bootm a2000000 >>>> ## Booting image at a2000000 ... >>>> Image Name: Angstrom/2.6.31/gumstix-verdex >>>> Image Type: ARM Linux Kernel Image (uncompressed) >>>> Data Size: 1319032 Bytes = 1.3 MB >>>> Load Address: a0008000 >>>> Entry Point: a0008000 >>>> OK >>>> >>>> Starting kernel ... >>>> >>>> Uncompressing >>>> Linux.................................................................................... >>>> done, booting the kernel. >>>> >>>> .-------. >>>> | | .-. >>>> | | |-----.-----.-----.| | .----..-----.-----. >>>> | | | __ | ---'| '--.| .-'| | | >>>> | | | | | |--- || --'| | | ' | | | | >>>> '---'---'--'--'--. |-----''----''--' '-----'-'-'-' >>>> -' | >>>> '---' >>>> >>>> The Angstrom Distribution gumstix-verdex ttyS0 >>>> >>>> Angstrom 2009.X-test-20100317 gumstix-verdex ttyS0 >>>> >>>> gumstix-verdex login: root >>>> Password: >>>> root@gumstix-verdex:~# >>>> >>>> I think some people get thrown off that it nothing is printed out after >>>> the >>>> decompression step. As you can see the first call to mmcinit did not >>>> find >>>> the mmc card. I tried to modify the gumstix-factory-script but I got a >>>> "bag >>>> magic number" error. What is the correct way to do this? I just want >>>> to >>>> always boot from the mmc, any other ways to ensure this always happens? >>>> >>>> Thanks! >>>> mlq >>>> >>>> >>>> Ash Charles-2 wrote: >>>>> >>>>> Hi mlq, >>>>> >>>>> Coderone suggestion about 'mmc init' versus 'mmcinit' is true for >>>>> newer version of u-boot (i.e. what you might have on the Overo boards) >>>>> but 'mmcinit' is still the right command for u-boot version 1.2.0--the >>>>> latest for the Verdex line. >>>>> >>>>> Can you try to isolate when exactly this happening as it seems a >>>>> little strange? Perhaps stopping the boot sequence and ensuring that >>>>> these commands cause the new kernel to boot would be useful: >>>>> $ mmcinit >>>>> $ fatload mmc 0 a2000000 uimage >>>>> $ setenv bootargs console=/dev/ttyS0,115200n8 root=/dev/mmcblk0p2 rw >>>>> rootdelay=1 >>>>> $ bootm a2000000 >>>>> >>>>> I can't remember offhand if gumstix-factory.script adds a 'rootdelay' >>>>> to the kernel command line or not; this is potentially an issue. >>>>> >>>>> -Ash >>>>> >>>>> On Fri, Mar 19, 2010 at 7:21 AM, mlq <mar...@lm...> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I have the 2.6.31 OE kernel up and running on the verdex board >>>>>> (thanks >>>>>> to >>>>>> all who made this hapen!!!). I have a gumstix-factory script in the >>>>>> partition with the uimage. When I power up sometimes the verdex >>>>>> boots >>>>>> from >>>>>> the flash and others it boots from the microSD. I am using the >>>>>> latest >>>>>> u-boot for the verdex. Is there a way to ensure the microSD is >>>>>> always >>>>>> booted? It seems like the microSD isnt mounting fast enough and/or >>>>>> the >>>>>> mmcinit is failing (although I think its the later becuase i dont see >>>>>> the >>>>>> u-boot message stating that it found the script). >>>>>> >>>>>> Thanks, >>>>>> mlq >>>>>> -- >>>>>> View this message in context: >>>>>> http://old.nabble.com/Booting-from-microSD-on-the-verdex-tp27950970p27950970.html >>>>>> Sent from the Gumstix mailing list archive at Nabble.com. >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Download Intel® Parallel Studio Eval >>>>>> Try the new software tools for yourself. Speed compiling, find bugs >>>>>> proactively, and fine-tune applications for parallel performance. >>>>>> See why Intel Parallel Studio got high marks during beta. >>>>>> http://p.sf.net/sfu/intel-sw-dev >>>>>> _______________________________________________ >>>>>> gumstix-users mailing list >>>>>> gum...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Download Intel® Parallel Studio Eval >>>>> Try the new software tools for yourself. Speed compiling, find bugs >>>>> proactively, and fine-tune applications for parallel performance. >>>>> See why Intel Parallel Studio got high marks during beta. >>>>> http://p.sf.net/sfu/intel-sw-dev >>>>> _______________________________________________ >>>>> gumstix-users mailing list >>>>> gum...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>>> >>>>> >>>> >>>> -- >>>> View this message in context: >>>> http://old.nabble.com/Booting-from-microSD-on-the-verdex-tp27950970p28035295.html >>>> Sent from the Gumstix mailing list archive at Nabble.com. >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Download Intel® Parallel Studio Eval >>>> Try the new software tools for yourself. Speed compiling, find bugs >>>> proactively, and fine-tune applications for parallel performance. >>>> See why Intel Parallel Studio got high marks during beta. >>>> http://p.sf.net/sfu/intel-sw-dev >>>> _______________________________________________ >>>> gumstix-users mailing list >>>> gum...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>> >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >> >> -- >> View this message in context: >> http://old.nabble.com/Booting-from-microSD-on-the-verdex-tp27950970p28043860.html >> Sent from the Gumstix mailing list archive at Nabble.com. >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Booting-from-microSD-on-the-verdex-tp27950970p28073164.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2010-03-26 04:16:10
|
Hi Mark, On Thu, Mar 25, 2010 at 2:43 PM, mlq <mar...@lm...> wrote: > > Hi Ash, > > Here is what happens when I execute the below commands: > > *** Welcome to Gumstix *** > > DRAM: 64 MB > Flash: 16 MB > Hit any key to stop autoboot: 0 > GUM> mmcinit > No MMC card found > GUM> mmcinit > Detected: 1927168 blocks of 1024 bytes (1882MB) SD card. > Vendor: Man 02 OEM TM "SA02G" Date 10/2009 > Product: 2628934609 > Revision: 0.3 > GUM> fatload mmc 0 a2000000 uimage > reading uimage > > 1319096 bytes read > GUM> setenv bootargs console=/dev/ttyS0,115200n8 root=/dev/mmcblk0p2 rw > rootdelay=1 Try changing your console= setting from /dev/ttyS0 to just be ttyS0. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: Ash C. <ash...@gm...> - 2010-04-01 19:43:06
|
Hi Frank and mlq, I've had issues if I press Backspace before issuing a command but I don't recall having had this issue otherwise. Could you tell me what board rev.s you are using and which version of U-Boot you are using? Thanks, -Ash On Thu, Apr 1, 2010 at 5:54 AM, Frank Agius <ft...@ya...> wrote: > mlq wrote: >> It looks like the mmc is not being mounted properly on certain boots. I get >> a error message from the 2.6.21 kernel which is in flash saying its unable >> to mount the mcc file system. This only happens occasionally on the first >> boot. If I reboot from the command line it picks up the mmc the second time >> around - which is weird. >> >> Any ideas what would cause this? >> > Through trial and error I have found that on a verdex cold boot, a delay > of at least 30 seconds is needed prior to issuing the mmcinit to > guarantee 100% reliability of the mmcinit. After a successful mmcinit, > power must be turned off at least 3 minutes to replicate the cold boot > mmcinit problem. Those two time delays sure sound like the > charge/discharge times for a capacitor. > > frank > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Frank A. <ft...@ya...> - 2010-04-02 17:39:28
|
Ash Charles wrote: > Hi Frank and mlq, > > I've had issues if I press Backspace before issuing a command but I > don't recall having had this issue otherwise. Could you tell me what > board rev.s you are using and which version of U-Boot you are using? > > Thanks, > > -Ash > Ash I haven't been actively using the Verdex board for 18 months and the board itself was purchased almost 2 years ago. The Verdex board revision is R1848 and the U-boot version is 1.2.0. frank |
From: Frank A. <ft...@ya...> - 2010-04-01 12:54:43
|
mlq wrote: > It looks like the mmc is not being mounted properly on certain boots. I get > a error message from the 2.6.21 kernel which is in flash saying its unable > to mount the mcc file system. This only happens occasionally on the first > boot. If I reboot from the command line it picks up the mmc the second time > around - which is weird. > > Any ideas what would cause this? > Through trial and error I have found that on a verdex cold boot, a delay of at least 30 seconds is needed prior to issuing the mmcinit to guarantee 100% reliability of the mmcinit. After a successful mmcinit, power must be turned off at least 3 minutes to replicate the cold boot mmcinit problem. Those two time delays sure sound like the charge/discharge times for a capacitor. frank |