From: Connie C <cci...@um...> - 2010-02-26 19:58:43
|
Hi all, I'm attempting an install of the 2.6.31 kernel Ash posted a few threads below. I'm not the greatest at gumstix/bitbake and am having a few issues. I've been using the usual gumstix-oe version in the past and have that set up on my machine. First I installed all the files in the new directory verdex-oe. First the bitbake complained that it could not find user collection in verdex-oe, so I copied user.collection and com.gumstix.collection over into the directory. After that, I got the error ERROR: Openembedded's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: /proc/sys/vm/mmap_min_addr is not 0. This will cause problems with qemu so please fix the value (as root). To fix this in later reboots, set vm.mmap_min_addr = 0 in /etc/sysctl.conf. so I used sudo -i echo 0 > /proc/sys/vm/mmap_min_addr to fix. Now bitbake cant find verdex-console-image. When I do: bitbake -b verdex-oe/org.openembedded.dev/recipes/images/verdex-console-image.bb I get a long list of errors, the important ones seem to be: ERROR: function do_rootfs failed and the error file path, most of which point to things in my gumstix/gumstix-oe folder The other errors look like: Configuring libasound2 | (offline root mode: not running libasound2.postinst) | Configuring libgcc1 | (offline root mode: not running libgcc1.postinst) and Cannot find package procps. | Check the spelling or perhaps run 'ipkg update' | Cannot find package socat. | Check the spelling or perhaps run 'ipkg update' | Cannot find package strace. | Check the spelling or perhaps run 'ipkg update' | Cannot find package sudo. | Check the spelling or perhaps run 'ipkg update' I have a feeling I did something wrong when I was setting this up. I didn't want to change my bash profile so I used options b/c in the setup instructions ($ source ~/verdex-oe/build/profile) http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html and did the $ git checkout --track -b verdex origin/verdex instead of the overo Can anyone tell me where I went wrong? Thanks. -Connie -- View this message in context: http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27722745.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Joseph K. <jp...@ro...> - 2010-02-27 02:12:44
|
Hi Connie Most of what Ash checked in for verdex-oe came originally from myself and a few others so I can help you. It builds clean for me. So, lets' review .... What OS distribution are you building with? If it's Ubuntu, please confirm that you did the instruction to not reconfigure bash as dash. >>First I installed all the files in the new directory >>verdex-oe. These should be the steps to follow: $ mkdir -p ~/verdex-oe $ cd ~/verdex-oe $ git clone git://gitorious.org/gumstix-oe/mainline.git org.openembedded.dev $ cd org.openembedded.dev $ git checkout --track -b verdex origin/verdex $ cd ~/verdex-oe $ git clone git://git.openembedded.net/bitbake bitbake $ cd bitbake $ git checkout 1.8.18 $ cd ~/overo-oe $ cp -r org.openembedded.dev/contrib/gumstix/build . >>sudo -i >>echo 0 > /proc/sys/vm/mmap_min_addr Yes, that should work. Alternatively, you could edit /etc/sysctl.conf (For example sudo gedit /etc.sysctl.conf&) and add the line vm.mmap_min_addr = 0 (Save and then reboot). >> First the bitbake complained that it could not find user >>collection in verdex-oe, so I copied user.collection and >>com.gumstix.collection over into the directory. There is no requirement to copy over user.collection from th older gumstix-oe build environment path. The purpose of user.collection is to override the search path for bitbake recipes. If any bitbake recipes in the user.collection path have the same base name as the ones used in org.openembedded.dev then they would be used in place of the official ones. Unless the developer has a specific reason for adding an override or customization or new bitbake recipe, and understands what he/she is doing with it (and the consequences) I suggest not putting anything in user.collection folder (or don't use the folder at all). Any old user.collection recipes that were used in the old gumstix-oe SVN based projects will not necessarily be compatible with the newer verdex-oe stuff since we are using a newer Angstrom distribution, newer Kernel, newer bitbake, etc. Developers that have such recipes would need to revisit them to port them to the new code base. The warning about not finding user.collection can therefore simply be ignored since you are (presumably) not going to be wanting to override any of the standard bitbake recipes or add any of your own customized ones yet. The old "com.gumstix.collection" and any files in that folder should not be added to this path and is not supported anymore in the Git based OE architecture. Any of the relevant patches or recipes (previously called packages) from the previous com.gumstix.collection are now already integrated into the git based verdex branch org.openembedded.dev recipes. (There are some exceptions such as support for audio, and robostix which are currently not ported to the new verdex-oe branch. Still working on it ....). Here is how to fix your build environment: First, you need to clean out the incorrect files that were added to the build path .... cd ~/verdex-oe sudo rm -rf com.gumstix.collection sudo rm -rf user.collection In this case, since the build cache is probably messed up, we need to start with a clean build sudo rm -rf tmp bitbake verdex-console-image Note: Please don't add ".bb" to the end of the bitbake recipe names in the bitbake command. Also, you can omit the -b option. BTW, please make sure that you have plenty of space in your /home partition. I use a 300GB partition albeit building for several projects for OpenEmbedded and I still find that my space gets eaten up really fast ... I recommend at least 40-60GB is needed to build verdex-oe (both verdex-console-image and verdex-palmtop-image). Let me know your results ... Regards Joseph PS: Tip for building faster on dual or quad core cpu .... In ~/verdex-oe/build/conf/site.conf # Uncomment these lines to enable parallel make. # This allows make to spawn mutliple processes to take advantage of multiple # processors. Useful on SMP machines PARALLEL_MAKE = "-j 4" BB_NUMBER_THREADS = "4" ________________________________ From: Connie C <cci...@um...> To: gum...@li... Sent: Fri, February 26, 2010 2:58:36 PM Subject: [Gumstix-users] Bitbaking New Kernel 2.6.31 for Verdex Hi all, I'm attempting an install of the 2.6.31 kernel Ash posted a few threads below. I'm not the greatest at gumstix/bitbake and am having a few issues. I've been using the usual gumstix-oe version in the past and have that set up on my machine. First I installed all the files in the new directory verdex-oe. First the bitbake complained that it could not find user collection in verdex-oe, so I copied user.collection and com.gumstix.collection over into the directory. After that, I got the error ERROR: Openembedded's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: /proc/sys/vm/mmap_min_addr is not 0. This will cause problems with qemu so please fix the value (as root). To fix this in later reboots, set vm.mmap_min_addr = 0 in /etc/sysctl.conf. so I used sudo -i echo 0 > /proc/sys/vm/mmap_min_addr to fix. Now bitbake cant find verdex-console-image. When I do: bitbake -b verdex-oe/org.openembedded.dev/recipes/images/verdex-console-image.bb I get a long list of errors, the important ones seem to be: ERROR: function do_rootfs failed and the error file path, most of which point to things in my gumstix/gumstix-oe folder The other errors look like: Configuring libasound2 | (offline root mode: not running libasound2.postinst) | Configuring libgcc1 | (offline root mode: not running libgcc1.postinst) and Cannot find package procps. | Check the spelling or perhaps run 'ipkg update' | Cannot find package socat. | Check the spelling or perhaps run 'ipkg update' | Cannot find package strace. | Check the spelling or perhaps run 'ipkg update' | Cannot find package sudo. | Check the spelling or perhaps run 'ipkg update' I have a feeling I did something wrong when I was setting this up. I didn't want to change my bash profile so I used options b/c in the setup instructions ($ source ~/verdex-oe/build/profile) http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html and did the $ git checkout --track -b verdex origin/verdex instead of the overo Can anyone tell me where I went wrong? Thanks. -Connie -- View this message in context: http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27722745.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: Joseph K. <jp...@ro...> - 2010-02-27 02:15:54
|
Hi, I corrected one critical line below ... ________________________________ From: Joseph Kortje <jp...@ro...> To: General mailing list for gumstix users. <gum...@li...> Sent: Fri, February 26, 2010 9:12:35 PM Subject: Re: [Gumstix-users] Bitbaking New Kernel 2.6.31 for Verdex Hi Connie Most of what Ash checked in for verdex-oe came originally from myself and a few others so I can help you. It builds clean for me. So, lets' review .... What OS distribution are you building with? If it's Ubuntu, please confirm that you did the instruction to not reconfigure bash as dash. >>First I installed all the files in the new directory >>verdex-oe. These should be the steps to follow: $ mkdir -p ~/verdex-oe $ cd ~/verdex-oe $ git clone git://gitorious.org/gumstix-oe/mainline.git org.openembedded.dev $ cd org.openembedded.dev $ git checkout --track -b verdex origin/verdex $ cd ~/verdex-oe $ git clone git://git.openembedded.net/bitbake bitbake $ cd bitbake $ git checkout 1.8.18 $ cd ~/verdex-oe $ cp -r org.openembedded.dev/contrib/gumstix/build . >>sudo -i >>echo 0 > /proc/sys/vm/mmap_min_addr Yes, that should work. Alternatively, you could edit /etc/sysctl.conf (For example sudo gedit /etc.sysctl.conf&) and add the line vm.mmap_min_addr = 0 (Save and then reboot). >> First the bitbake complained that it could not find user >>collection in verdex-oe, so I copied user.collection and >>com.gumstix.collection over into the directory. There is no requirement to copy over user.collection from th older gumstix-oe build environment path. The purpose of user.collection is to override the search path for bitbake recipes. If any bitbake recipes in the user.collection path have the same base name as the ones used in org.openembedded.dev then they would be used in place of the official ones. Unless the developer has a specific reason for adding an override or customization or new bitbake recipe, and understands what he/she is doing with it (and the consequences) I suggest not putting anything in user.collection folder (or don't use the folder at all). Any old user.collection recipes that were used in the old gumstix-oe SVN based projects will not necessarily be compatible with the newer verdex-oe stuff since we are using a newer Angstrom distribution, newer Kernel, newer bitbake, etc. Developers that have such recipes would need to revisit them to port them to the new code base. The warning about not finding user.collection can therefore simply be ignored since you are (presumably) not going to be wanting to override any of the standard bitbake recipes or add any of your own customized ones yet. The old "com.gumstix.collection" and any files in that folder should not be added to this path and is not supported anymore in the Git based OE architecture. Any of the relevant patches or recipes (previously called packages) from the previous com.gumstix.collection are now already integrated into the git based verdex branch org.openembedded.dev recipes. (There are some exceptions such as support for audio, and robostix which are currently not ported to the new verdex-oe branch. Still working on it ....). Here is how to fix your build environment: First, you need to clean out the incorrect files that were added to the build path .... cd ~/verdex-oe sudo rm -rf com.gumstix.collection sudo rm -rf user.collection In this case, since the build cache is probably messed up, we need to start with a clean build sudo rm -rf tmp bitbake verdex-console-image Note: Please don't add ".bb" to the end of the bitbake recipe names in the bitbake command. Also, you can omit the -b option. BTW, please make sure that you have plenty of space in your /home partition. I use a 300GB partition albeit building for several projects for OpenEmbedded and I still find that my space gets eaten up really fast ... I recommend at least 40-60GB is needed to build verdex-oe (both verdex-console-image and verdex-palmtop-image). Let me know your results ... Regards Joseph PS: Tip for building faster on dual or quad core cpu .... In ~/verdex-oe/build/conf/site.conf # Uncomment these lines to enable parallel make. # This allows make to spawn mutliple processes to take advantage of multiple # processors. Useful on SMP machines PARALLEL_MAKE = "-j 4" BB_NUMBER_THREADS = "4" ________________________________ From: Connie C <cci...@um...> To: gum...@li... Sent: Fri, February 26, 2010 2:58:36 PM Subject: [Gumstix-users] Bitbaking New Kernel 2.6.31 for Verdex Hi all, I'm attempting an install of the 2.6.31 kernel Ash posted a few threads below. I'm not the greatest at gumstix/bitbake and am having a few issues. I've been using the usual gumstix-oe version in the past and have that set up on my machine. First I installed all the files in the new directory verdex-oe. First the bitbake complained that it could not find user collection in verdex-oe, so I copied user.collection and com.gumstix.collection over into the directory. After that, I got the error ERROR: Openembedded's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: /proc/sys/vm/mmap_min_addr is not 0. This will cause problems with qemu so please fix the value (as root). To fix this in later reboots, set vm.mmap_min_addr = 0 in /etc/sysctl.conf. so I used sudo -i echo 0 > /proc/sys/vm/mmap_min_addr to fix. Now bitbake cant find verdex-console-image. When I do: bitbake -b verdex-oe/org.openembedded.dev/recipes/images/verdex-console-image.bb I get a long list of errors, the important ones seem to be: ERROR: function do_rootfs failed and the error file path, most of which point to things in my gumstix/gumstix-oe folder The other errors look like: Configuring libasound2 | (offline root mode: not running libasound2.postinst) | Configuring libgcc1 | (offline root mode: not running libgcc1.postinst) and Cannot find package procps. | Check the spelling or perhaps run 'ipkg update' | Cannot find package socat. | Check the spelling or perhaps run 'ipkg update' | Cannot find package strace. | Check the spelling or perhaps run 'ipkg update' | Cannot find package sudo. | Check the spelling or perhaps run 'ipkg update' I have a feeling I did something wrong when I was setting this up. I didn't want to change my bash profile so I used options b/c in the setup instructions ($ source ~/verdex-oe/build/profile) http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Setting-up-a-build-environment/111.html and did the $ git checkout --track -b verdex origin/verdex instead of the overo Can anyone tell me where I went wrong? Thanks. -Connie -- View this message in context: http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27722745.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: Connie C <cci...@um...> - 2010-02-27 02:52:51
|
Hi Joseph, Thanks for the help. I'm definitely using the bash profile. Followed all those steps. I also followed the second sequence of code to make the verdex-oe directory and I have the bitbake,build, and org.openembedded.dev directories inside. I think everything looks okay up to there with what you posted. After removing my user.collection and com.gumstix.collection from the verdex-oe directory, I removed the extraneous tmp directory and ran bitbake verdex-console-image and got: ERROR: Nothing PROVIDES 'verdex-console-image' (but '[]' DEPENDS on or otherwise requires it) I had gotten this originally after I changed >>echo 0 > /proc/sys/vm/mmap_min_addr and was trying to access the .bb file directly as a result. Something with how my bitbake is set up? Thanks, Connie bionicjoe wrote: > > Hi, I corrected one critical line below ... > > > > > ________________________________ > From: Joseph Kortje <jp...@ro...> > To: General mailing list for gumstix users. > <gum...@li...> > Sent: Fri, February 26, 2010 9:12:35 PM > Subject: Re: [Gumstix-users] Bitbaking New Kernel 2.6.31 for Verdex > > > Hi Connie > > Most of what Ash checked in for verdex-oe came originally from myself and > a few others > so I can help you. > > It builds clean for me. > > So, lets' review .... > > What OS distribution are you building with? > If it's Ubuntu, please confirm that you did the instruction to not > reconfigure bash as dash. > > >>>First I installed all the files in the new directory >>>verdex-oe. > > These should be the steps to follow: > > $ mkdir -p ~/verdex-oe > $ cd ~/verdex-oe > $ git clone git://gitorious.org/gumstix-oe/mainline.git > org.openembedded.dev > $ cd org.openembedded.dev > $ git checkout --track -b verdex origin/verdex > $ cd ~/verdex-oe > $ git clone git://git.openembedded.net/bitbake bitbake > $ cd bitbake > $ git checkout 1.8.18 > $ cd ~/verdex-oe > $ cp -r org.openembedded.dev/contrib/gumstix/build . > >>>sudo -i >>>echo 0 > /proc/sys/vm/mmap_min_addr > > Yes, that should work. > > Alternatively, you could edit /etc/sysctl.conf (For example sudo gedit > /etc.sysctl.conf&) > and add the line > > vm.mmap_min_addr = 0 > > (Save and then reboot). > >>> First the bitbake complained that it could not find user >>>collection in verdex-oe, so I copied user.collection and >>>com.gumstix.collection over into the directory. > > There is no requirement to copy over user.collection from th older > gumstix-oe build environment path. > The purpose of user.collection is to override the search path for bitbake > recipes. If any bitbake recipes > in the user.collection path have the same base name as the ones used in > org.openembedded.dev then they would be used > in place of the official ones. Unless the developer has a specific reason > for adding an override or customization > or new bitbake recipe, and understands what he/she is doing with it (and > the consequences) > I suggest not putting anything in user.collection folder (or don't use the > folder at all). > > Any old user.collection recipes that were used in the old gumstix-oe SVN > based projects will not necessarily be compatible > with the newer verdex-oe stuff since we are using a newer Angstrom > distribution, newer Kernel, newer bitbake, > etc. Developers that have such recipes would need to revisit them to port > them to the new code base. > > The warning about not finding user.collection can therefore simply be > ignored since you are (presumably) > not going to be wanting to override any of the standard bitbake recipes or > add any of your own > customized ones yet. > > The old "com.gumstix.collection" and any files in that folder should not > be added to this path and > is not supported anymore in the Git based OE architecture. Any of the > relevant patches or recipes (previously called packages) > from the previous com.gumstix.collection are now already integrated into > the git based verdex branch org.openembedded.dev recipes. > > (There are some exceptions such as support for audio, and robostix which > are currently not ported to the new verdex-oe branch. Still working > on it ....). > > Here is how to fix your build environment: > > First, you need to clean out the incorrect files that were added to the > build path .... > > cd ~/verdex-oe > sudo rm -rf com.gumstix.collection > sudo rm -rf user.collection > > In this case, since the build cache is probably messed up, we need to > start with a clean build > > sudo rm -rf tmp > bitbake verdex-console-image > > > Note: Please don't add ".bb" to the end of the bitbake recipe names in the > bitbake command. > Also, you can omit the -b option. > > > BTW, please make sure that you have plenty of space in your /home > partition. > I use a 300GB partition albeit building for several projects for > OpenEmbedded and I still find that > my space gets eaten up really fast ... > > I recommend at least 40-60GB is needed to build verdex-oe (both > verdex-console-image and verdex-palmtop-image). > > > Let me know your results ... > > > Regards > Joseph > > > PS: Tip for building faster on dual or quad core cpu .... > > In > ~/verdex-oe/build/conf/site.conf > > # Uncomment these lines to enable parallel make. > # This allows make to spawn mutliple processes to take advantage of > multiple > # processors. Useful on SMP machines > PARALLEL_MAKE = "-j 4" > BB_NUMBER_THREADS = "4" > -- View this message in context: http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27725553.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Connie C <cci...@um...> - 2010-03-04 00:20:03
|
Hey Ash, I went back through the setup very carefully and I think I found the source of the problem. Everything untarred correctly after that, however, all the links in the directories on the rootfs appear to be broken. I'm actually now at the same point as mlq above. I've let the verdex sit for 15+ minutes without any change in status, just hangs at i2c /dev entries driver the error seems to be in a different place in the boot though than his, and on the two times ive booted it up, seems to occur at a different spot. The second time it hung after trying to turn off echo on /dev/ttyS1. Thanks, Connie Ash Charles-2 wrote: > > Hi Connie, > > I don't recognize these particular errors. Google suggested that this > is caused by a bad partition. In a previous e-mail you mentioned you > formatted using FAT16 and Ext2 rather than FAT32 and Ext3: what was > your motivation for this change? > Perhaps trying a reformat of your Ext2 partition to Ext3 or a new card > if you have one handy would help track down the issue? > -Ash > > > On Wed, Mar 3, 2010 at 7:58 AM, Connie C <cci...@um...> wrote: >> >> Hi Ash, >> >> Thanks for the help. I tried the command $sudo tar -xzf >> /home/oeuser/verdex-oe/tmp/deploy/glibc/images/gumstix-verdex/Angstrom-verdex-console-image-glibc-ipk-2009.X-test-20100227-gumstix-verdex.rootfs.tar.gz >> -C /media/card >> >> and got the bunch of errors I seem to keep getting. A sample of what >> they >> all look like: >> >> tar: ./boot: Cannot mkdir: Input/output error >> tar: ./boot/uImage: Cannot create symlink to `uImage-2.6.31': No such >> file >> or directory >> tar: ./lib: Cannot mkdir: Input/output error >> tar: ./lib/ld-linux.so.3: Cannot create symlink to `ld-2.9.so': No such >> file >> or directory >> tar: ./lib/libproc-3.2.7.so: Cannot open: No such file or directory >> tar: ./lib/libc-2.9.so: Cannot open: No such file or directory >> tar: ./lib/libanl.so.1: Cannot create symlink to `libanl-2.9.so': No such >> file or directory >> tar: ./lib/librt-2.9.so: Cannot open: No such file or directory >> tar: ./lib/libnss_files-2.9.so: Cannot open: No such file or directory >> tar: ./lib/librt.so.1: Cannot create symlink to `librt-2.9.so': No such >> file >> or directory >> >> same with ./sbin, ./lib, ./etc, ./tmp, and ./mnt >> after the tar, I have >> oeuser@SG1:/media/card$ ls >> bin boot dev home linuxrc lost+found media proc sys usr var >> with linuxrc a broken link. >> >> Thanks, >> >> Connie >> >> Ash Charles-2 wrote: >>> >>> Hi Connie, >>> >>> Do you have superuser access when extracting the root file system? >>> Say Ext2|Ext3 partition is at /media/card_ext and your root filesystem >>> named 'verdex-console-image-verdex.tar.gz' is in the current >>> directory. >>> Does this command fail? >>> $ sudo tar -xzf verdex-console-image-verdex.tar.gz -C /media/card_ext/ >>> >>> The reason the documentation notes the step to be dangerous is because >>> you are extracting a root filesystem. If you neglect the -C option or >>> accidentally extract to '/', you could overwrite important sections of >>> your own machine! >>> >>> -Ash >>> >>> On Tue, Mar 2, 2010 at 2:41 PM, Connie C <cci...@um...> wrote: >>>> >>>> Hi all, (again) >>>> >>>> So very happy about successfully bitbaking the 2.6.31 kernel. However, >>>> I >>>> seem to having issues extracting the rootfs from the tarball. I >>>> partitioned >>>> my 2Gb microsd card yesterday according to >>>> http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html >>>> >>>> Except with a FAT16 partition and .ext2 partition >>>> and I put gumstix-factory.script and uImage in the FAT partition and >>>> tried >>>> to unpack the .tar.gz in the .ext2 partition. Trying to upack to >>>> tarball >>>> fails. I've also tried to extract single files/folders from the >>>> tarball >>>> into other locations on my desktop and card. Some of the folders work >>>> succesfully and can be extracted. However, some, like mnt, will not >>>> extract. (this is to both the sd card and to a random folder on my >>>> desktop)(I did also read : The final step is to untar your desired >>>> rootfs >>>> onto the ext3 partition that you created above. >>>> Note that this step can be dangerous. You do not want to untar your >>>> Overo >>>> rootfs onto your development machine - be careful! and so am only >>>> doing >>>> individual files and then deleting them) >>>> >>>> I used fdsk for the partitioning. I thought it might be how I >>>> partitioned >>>> the card at first and ran dmsg and got a few types of errors: >>>> [687450.710992] attempt to access beyond end of device >>>> [687450.710996] sdc: rw=0, want=4012501, limit=3842048 >>>> [687451.119556] EXT2-fs error (device sdc2): read_inode_bitmap: Cannot >>>> read >>>> inode bitmap - block_group = 15, inode_bitmap = 491521 >>>> >>>> [686293.686071] sdc: rw=1, want=3848813, limit=3842048 >>>> [686293.686074] attempt to access beyond end of device >>>> >>>> [686312.717664] EXT2-fs error (device sdc2): ext2_readdir: bad page in >>>> #109313 >>>> >>>> I have gone back through the partitioning instructions several times >>>> and >>>> I >>>> think my card has been done successfully. (I can upload the transcript >>>> for >>>> the session) especially since I cant remove some of the files from the >>>> tarball at all. >>>> >>>> Thanks! >>>> >>>> Connie C. >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27762177.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 >>>> >>> > > > -- View this message in context: http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27773753.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2010-03-04 00:41:52
|
Hi Connie, On Wed, Mar 3, 2010 at 4:19 PM, Connie C <cci...@um...> wrote: > > Hey Ash, > > I went back through the setup very carefully and I think I found the source > of the problem. Everything untarred correctly after that, however, all the > links in the directories on the rootfs appear to be broken. This might happen if the symlinks are absolute. When the card boots up, / will be in a different place than it is when the card is mounted by the verdex/overo. For example, when the card is mounted, /mnt/media/card/linuxrc will be a symlink to /bin/busybox which is on the host machine, so while the card is on the host machine it will be a broken symlink. When the card is booted from by the verdex, though, the symlink will be correct. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: mlq <mar...@lm...> - 2010-02-27 19:10:46
|
I am also trying to build the verdex image and have sucessfully built the minimal-image and kernel; however when I build the console image i.e. bitbake console-image it dies on building the task-base. Basically it is looking in the task base folder but is missing the extensions for the particular tasks (task-base-x, missing x; sorry I dont have the output in front of me). I have 2 questions; What is the correct recipe to bitbake for the verdex? (i cant seem to find any verdex-specific recipes in the repo) What procedure should we follow to flash the mmc? (I was able to boot using the FAT16 partition and gumstix-factory.script from the old svn repo but I am not sure if we should be using a similar setup to the overo with xload?) Another related question which is not critical is when I add recipes to user.collection/recipes bitbake does not see them - is there typical reason for this? Thanks, mlq Connie C wrote: > > Hi Joseph, > > Thanks for the help. I'm definitely using the bash profile. Followed all > those steps. I also followed the second sequence of code to make the > verdex-oe directory and I have the bitbake,build, and org.openembedded.dev > directories inside. I think everything looks okay up to there with what > you posted. > > After removing my user.collection and com.gumstix.collection from the > verdex-oe directory, I removed the extraneous tmp directory and ran > bitbake verdex-console-image and got: > ERROR: Nothing PROVIDES 'verdex-console-image' (but '[]' DEPENDS on or > otherwise requires it) > > I had gotten this originally after I changed >>echo 0 > > /proc/sys/vm/mmap_min_addr > and was trying to access the .bb file directly as a result. > > Something with how my bitbake is set up? > > Thanks, > > Connie > > > > > bionicjoe wrote: >> >> Hi, I corrected one critical line below ... >> >> >> >> >> ________________________________ >> From: Joseph Kortje <jp...@ro...> >> To: General mailing list for gumstix users. >> <gum...@li...> >> Sent: Fri, February 26, 2010 9:12:35 PM >> Subject: Re: [Gumstix-users] Bitbaking New Kernel 2.6.31 for Verdex >> >> >> Hi Connie >> >> Most of what Ash checked in for verdex-oe came originally from myself and >> a few others >> so I can help you. >> >> It builds clean for me. >> >> So, lets' review .... >> >> What OS distribution are you building with? >> If it's Ubuntu, please confirm that you did the instruction to not >> reconfigure bash as dash. >> >> >>>>First I installed all the files in the new directory >>>>verdex-oe. >> >> These should be the steps to follow: >> >> $ mkdir -p ~/verdex-oe >> $ cd ~/verdex-oe >> $ git clone git://gitorious.org/gumstix-oe/mainline.git >> org.openembedded.dev >> $ cd org.openembedded.dev >> $ git checkout --track -b verdex origin/verdex >> $ cd ~/verdex-oe >> $ git clone git://git.openembedded.net/bitbake bitbake >> $ cd bitbake >> $ git checkout 1.8.18 >> $ cd ~/verdex-oe >> $ cp -r org.openembedded.dev/contrib/gumstix/build . >> >>>>sudo -i >>>>echo 0 > /proc/sys/vm/mmap_min_addr >> >> Yes, that should work. >> >> Alternatively, you could edit /etc/sysctl.conf (For example sudo gedit >> /etc.sysctl.conf&) >> and add the line >> >> vm.mmap_min_addr = 0 >> >> (Save and then reboot). >> >>>> First the bitbake complained that it could not find user >>>>collection in verdex-oe, so I copied user.collection and >>>>com.gumstix.collection over into the directory. >> >> There is no requirement to copy over user.collection from th older >> gumstix-oe build environment path. >> The purpose of user.collection is to override the search path for bitbake >> recipes. If any bitbake recipes >> in the user.collection path have the same base name as the ones used in >> org.openembedded.dev then they would be used >> in place of the official ones. Unless the developer has a specific >> reason for adding an override or customization >> or new bitbake recipe, and understands what he/she is doing with it (and >> the consequences) >> I suggest not putting anything in user.collection folder (or don't use >> the folder at all). >> >> Any old user.collection recipes that were used in the old gumstix-oe SVN >> based projects will not necessarily be compatible >> with the newer verdex-oe stuff since we are using a newer Angstrom >> distribution, newer Kernel, newer bitbake, >> etc. Developers that have such recipes would need to revisit them to >> port them to the new code base. >> >> The warning about not finding user.collection can therefore simply be >> ignored since you are (presumably) >> not going to be wanting to override any of the standard bitbake recipes >> or add any of your own >> customized ones yet. >> >> The old "com.gumstix.collection" and any files in that folder should not >> be added to this path and >> is not supported anymore in the Git based OE architecture. Any of the >> relevant patches or recipes (previously called packages) >> from the previous com.gumstix.collection are now already integrated into >> the git based verdex branch org.openembedded.dev recipes. >> >> (There are some exceptions such as support for audio, and robostix which >> are currently not ported to the new verdex-oe branch. Still working >> on it ....). >> >> Here is how to fix your build environment: >> >> First, you need to clean out the incorrect files that were added to the >> build path .... >> >> cd ~/verdex-oe >> sudo rm -rf com.gumstix.collection >> sudo rm -rf user.collection >> >> In this case, since the build cache is probably messed up, we need to >> start with a clean build >> >> sudo rm -rf tmp >> bitbake verdex-console-image >> >> >> Note: Please don't add ".bb" to the end of the bitbake recipe names in >> the bitbake command. >> Also, you can omit the -b option. >> >> >> BTW, please make sure that you have plenty of space in your /home >> partition. >> I use a 300GB partition albeit building for several projects for >> OpenEmbedded and I still find that >> my space gets eaten up really fast ... >> >> I recommend at least 40-60GB is needed to build verdex-oe (both >> verdex-console-image and verdex-palmtop-image). >> >> >> Let me know your results ... >> >> >> Regards >> Joseph >> >> >> PS: Tip for building faster on dual or quad core cpu .... >> >> In >> ~/verdex-oe/build/conf/site.conf >> >> # Uncomment these lines to enable parallel make. >> # This allows make to spawn mutliple processes to take advantage of >> multiple >> # processors. Useful on SMP machines >> PARALLEL_MAKE = "-j 4" >> BB_NUMBER_THREADS = "4" >> > > > > -- View this message in context: http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27730217.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Ash C. <ash...@gm...> - 2010-03-05 01:47:35
|
Hi, I can duplicate these hangs---what was booting for me the other day is not working now. I've updated my code and I've been working through some of the errors listed in the provided boot logs. Mostly, these seem to be errors in the kernel configuration and udev. Currently, I'm stumbling up against errors loading the proc_gpio module and properly detecting the network interface chip. The init sequence gets to the last entry S99... but isn't giving me a login prompt. I'll update the repository as soon as I get something going. @Joseph: Thanks for your hard work and please let me know what patches I missed. For your reference, I thought I'd pulled most of the changes from an e-mail from Steve around the time of this thread: http://old.nabble.com/verdex-svn-staleness-td22632802.html#a26203601 Thanks again for the feedback. -Ash On Wed, Mar 3, 2010 at 11:32 AM, mlq <mar...@lm...> wrote: > > Hey Ash, > > I re-flashed u-boot and the latest version and still got the same errors as > I did on the first boot; here is the output from the second boot: > > U-Boot 1.2.0 (May 10 2008 - 21:17:19) - PXA270@400 MHz - 1604 > > *** Welcome to Gumstix *** > > DRAM: 64 MB > Flash: 16 MB > Using default environment > > 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> setenv bootargs console=ttyS0,115200n8 rootdelay=1 root=/dev/mmcblk0p2 > GUM> fatload mmc 0 a2000000 uimage > reading uimage > > 1291348 bytes read > GUM> bootm a2000000 > ## Booting image at a2000000 ... > Image Name: Angstrom/2.6.31/gumstix-verdex > Image Type: ARM Linux Kernel Image (uncompressed) > Data Size: 1291284 Bytes = 1.2 MB > Load Address: a0008000 > Entry Point: a0008000 > OK > > Starting kernel ... > > Uncompressing > Linux.................................................................................. > done, booting the kernel. > Linux version 2.6.31 (gcc version 4.3.3 (GCC) ) #1 Fri Feb 26 15:45:41 PST > 2010 > CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE), cr=0000397f > CPU: VIVT data cache, VIVT instruction cache > Machine: Gumstix verdex > Memory policy: ECC disabled, Data cache writeback > Run Mode clock: 208.00MHz (*16) > Turbo Mode clock: 416.00MHz (*2.0, active) > Memory clock: 104.00MHz (/2) > System bus clock: 104.00MHz > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 > Kernel command line: console=ttyS0,115200n8 rootdelay=1 root=/dev/mmcblk0p2 > PID hash table entries: 256 (order: 8, 1024 bytes) > Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) > Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) > Memory: 64MB = 64MB total > Memory: 62248KB available (2212K code, 252K data, 88K init, 0K highmem) > NR_IRQS:192 > Console: colour dummy device 80x30 > Calibrating delay loop... 415.33 BogoMIPS (lpj=2076672) > Mount-cache hash table entries: 512 > CPU: Testing write buffer coherency: ok > NET: Registered protocol family 16 > Gumstix verdex udc is disabled > Initializing Gumstix verdex i2c > Initializing Gumstix verdex smsc911x > Initializing Gumstix verdex pcmcia > Not netCF-vx board: pcmcia using newer GPIO configuration > CPLD responded with: ff > found 1 CF slots > Initializing Gumstix verdex FB info > Initializing Gumstix platform_add_devices > bio: create slab <bio-0> at 0 > NET: Registered protocol family 2 > IP route cache hash table entries: 1024 (order: 0, 4096 bytes) > TCP established hash table entries: 2048 (order: 2, 16384 bytes) > TCP bind hash table entries: 2048 (order: 1, 8192 bytes) > TCP: Hash tables configured (established 2048 bind 2048) > TCP reno registered > NET: Registered protocol family 1 > msgmni has been set to 121 > alg: No test for stdrng (krng) > Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) > io scheduler noop registered > io scheduler cfq registered (default) > Console: switching to colour frame buffer device 80x24 > pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 22) is a FFUART > console [ttyS0] enabled > pxa2xx-uart.1: ttyS1 at MMIO 0x40200000 (irq = 21) is a BTUART > pxa2xx-uart.2: ttyS2 at MMIO 0x40700000 (irq = 20) is a STUART > Probing Gumstix Flash ROM at physical address 0x00000000 (16-bit bankwidth) > Gumstix Flash ROM: Found 1 x16 devices at 0x0 in 16-bit bank > Intel/Sharp Extended Query Table at 0x010A > Intel/Sharp Extended Query Table at 0x010A > Intel/Sharp Extended Query Table at 0x010A > Intel/Sharp Extended Query Table at 0x010A > Intel/Sharp Extended Query Table at 0x010A > Using buffer write method > Using auto-unlock on power-up/resume > cfi_cmdset_0001: Erase suspend on write enabled > Using static partitions on Gumstix Flash ROM > Creating 3 MTD partitions on "Gumstix Flash ROM": > 0x000000000000-0x000000040000 : "Bootloader" > 0x000000040000-0x000000f00000 : "RootFS" > 0x000000f00000-0x000001000000 : "Kernel" > pxa-rtc pxa-rtc: rtc core: registered pxa-rtc as rtc0 > TCP cubic registered > NET: Registered protocol family 17 > XScale iWMMXt coprocessor detected. > pxa-rtc pxa-rtc: setting system clock to 2000-01-01 00:00:51 UTC (946684851) > Waiting 1sec before mounting root device... > mmc0: host does not support reading read-only switch. assuming write-enable. > mmc0: new SD card at address 1234 > mmcblk0: mmc0:1234 SA02G 1.83 GiB > mmcblk0: p1 p2 > kjournald starting. Commit interval 5 seconds > EXT3 FS on mmcblk0p2, internal journal > EXT3-fs: recovery complete. > EXT3-fs: mounted filesystem with writeback data mode. > VFS: Mounted root (ext3 filesystem) on device 179:2. > Freeing init memory: 88K > INIT: version 2.86 booting > Please wait: booting... > Starting udev > udevd[47]: SYSFS{}= will be removed in a future udev version, please use > ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in > /etc/udev/rules.d/local.rules:34 > > udevd[47]: SYSFS{}= will be removed in a future udev version, please use > ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in > /etc/udev/rules.d/local.rules:35 > > udevd[47]: NAME="%k" is superfluous and breaudev: starting version 151 > ks kernel supplied names, please remove it from > /etc/udev/rules.d/udev.rules:18 > > udevd[47]: NAME="%k" is superfluous and breaks kernel supplied names, please > remove it from /etc/udev/rules.d/udev.rules:106 > > Remounting root file system... > > udevadm settle - timeout of 3 seconds reached, the event queue contains: > /sys/devices/platform/pxa2xx-mci.0/mmc_host/mmc0/mmc0:1234/block/mmcblk0 > (193) > > /sys/devices/platform/pxa2xx-mci.0/mmc_host/mmc0/mmc0:1234/block/mmcblk0/mmcblk0p1 > (194) > > /sys/devices/platform/pxa2xx-mci.0/mmc_host/mmc0/mmc0:1234/block/mmcblk0/mmcblk0p2 > (195) > Caching udev devnodes > Populating dev cachemv: cannot stat `/tmp/uname': No such file or directory > Bluetooth: Core ver 2.15 > FAT: codepage cp437 not found > NET: Registered protocol family 31 > Bluetooth: HCI device and connection manager initialized > Bluetooth: HCI socket layer initialized > Bluetooth: L2CAP ver 2.13 > Bluetooth: L2CAP socket layer initialized > Bluetooth: HIDP (Human Interface Emulation) ver 1.2 > usbcore: registered new interface driver usbfs > usbcore: registered new interface driver hub > usbcore: registered new device driver usb > ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver > pxa27x-ohci pxa27x-ohci: PXA27x OHCI > pxa27x-ohci pxa27x-ohci: new USB bus registered, assigned bus number 1 > pxa27x-ohci pxa27x-ohci: irq 3, io mem 0x4c000000 > usb usb1: configuration #1 chosen from 1 choice > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 3 ports detected > Registering gumstix PCMCIA interface. > Bluetooth: RFCOMM TTY layer initialized > Bluetooth: RFCOMM socket layer initialized > Bluetooth: RFCOMM ver 1.11 > smsc911x: Driver version 2008-10-21. > eth%d: smsc911x_init: Driver Parameters: > eth%d: smsc911x_init: LAN base: 0xC4A00000 > eth%d: smsc911x_init: IRQ: 163 > eth%d: smsc911x_init: PHY will be autodetected. > eth%d: smsc911x_init: BYTE_TEST: 0x87654321 > eth%d: smsc911x_init: LAN911x identified, idrev: 0x01170002, generation: 2 > eth0: smsc911x_drv_probe: Network interface: "eth0" > eth0: smsc911x_phy_initialise_external: HW_CFG EXT_PHY_DET clear, using > internal PHY > smsc911x-mdio: probed > eth0: smsc911x_mii_probe: PHY 1: addr 1, phy_id 0x0007C0D1 > eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=ffffffff:01, > irq=-1) > eth0: smsc911x_phy_check_loopbackpkt: Successfully verified loopback packet > eth0: smsc911x_mii_probe: Passed Loop Back Test > eth0: smsc911x_mii_probe: phy initialised succesfully > eth0: smsc911x_drv_probe: MAC Address is derived from system serial number > net eth0: MAC Address: 02:4c:b7:81:b2:d0 > Unknown HZ value! (47) Assume 100. > logger: mount: mount point /dev/pts does not exist > logger: mount: mount point /dev/shm does not exist > Starting Marvell Wifi CF8385... > Configuring network interfaces... eth0: smsc911x_open: irq polarity: active > low > eth0: smsc911x_open: irq type: push-pull > eth0: smsc911x_open: Testing irq handler using IRQ 163 > eth0: smsc911x_open: IRQ handler passed test using IRQ 163 > net eth0: SMSC911x/921x identified at 0xc4a00000, IRQ: 163 > eth0: smsc911x_rx_multicast_update: maccr 0x1000000C, HASHH 0x00000000, > HASHL 0x00000000 > eth0: smsc911x_rx_multicast_update: maccr 0x1000200C, HASHH 0x00000000, > HASHL 0x80000000 > eth0: smsc911x_rx_multicast_update: maccr 0x1000200C, HASHH 0x00000000, > HASHL 0x80000000 > eth0 no wireless extensions. > > eth0: smsc911x_rx_multicast_update: maccr 0x1000200C, HASHH 0x00000000, > HASHL 0x80000000 > udhcpc (v1.13.2) started > run-parts: /etc/udhcpc.d/00avahi-autoipd exited with code 1 > eth0: smsc911x_rx_multicast_update: maccr 0x1000200C, HASHH 0x00000000, > HASHL 0x80000000 > Sending discover... > eth0: smsc911x_phy_adjust_link: duplex state has changed > eth0: smsc911x_phy_adjust_link: configuring for half duplex mode > eth0: smsc911x_phy_update_flowcontrol: half duplex > eth0: smsc911x_phy_adjust_link: carrier state has changed > eth0: smsc911x_phy_adjust_link: configuring for no carrier > Sending discover... > Sending discover... > eth0: smsc911x_rx_multicast_update: maccr 0x1000200C, HASHH 0x00000000, > HASHL 0x80000000 > No lease, failing > done. > Starting portmap daemon: portmapportmap: fork: No such device. > Unknown HZ value! (69) Assume 100. > net.ipv4.conf.default.rp_filter = 1 > net.ipv4.conf.all.rp_filter = 1 > hwclock: can't open '/dev/misc/rtc': No such file or directory > Mon Mar 1 11:18:00 UTC 2010 > hwclock: can't open '/dev/misc/rtc': No such file or directory > Turning echo off on /dev/ttyS1 > /etc/rcS.d/S97blueprobe: line 5: can't open /dev/ttyS1: no such file > eth0: smsc911x_rx_multicast_update: maccr 0x1000200C, HASHH 0x00000000, > HASHL 0x80008000 > tsc2003_probe > tsc2003 i2c touch screen controller > Bill Gatliff <bgat at billgatliff.com > Nicholas Chen <nchen at cs.umd.edu> > tsc2003_probe: checking i2c > tsc2003_probe: calling kzalloc > tsc2003_probe: probing address 0x48 > i2c: error: exhausted retries > i2c: msg_num: 0 msg_idx: -2000 msg_ptr: 0 > i2c: ICR: 000087e0 ISR: 00000002 > tsc2003: probe of 0-0048 failed with error -121 > I2C: i2c-0: PXA I2C adapter > I2C: i2c-1: PXA I2C adapter > i2c /dev entries driver > > Ash Charles wrote: >> >> Hi mlq, >> >> I don't see the same behaviour where setenv needs to be called before >> fatload. As these commands do completely different things, it would >> seem like a bug to me. Have you tried using the more recent 1604 >> version of uboot? >> >> The U-Boot files are available here: http://www.gumstix.net/feeds/u-boot/ >> The instructions for *carefully* reflashing U-Boot via serial >> connection are given here: >> http://www.gumstix.net/User-How-To-s/view/Developer-how-to-s/Reflashing-using-a-serial-connection/110.html >> >> I'll have to look through the messages you are seeing in detail. Some >> seem to be configuration/installation issues: does it work any better >> the second time you try to boot? Other ones seem to be problems with >> how I've set up udev. >> >> Thanks for your feedback, >> >> Ash >> On Wed, Mar 3, 2010 at 10:03 AM, mlq <mar...@lm...> wrote: >>> >>> Ok so I finally got it to boot; looks like the setenv has to be called >>> before >>> fatload. However the boot locks up; below is the output. Here is the >>> fdisk >>> output on how my sd card is formated. Note that the FAT partition only >>> has >>> the uimage on it and the ext3 has the un-tarred rootfs. >>> >>> Disk /dev/sdb: 1973 MB, 1973420032 bytes >>> 255 heads, 63 sectors/track, 239 cylinders >>> Units = cylinders of 16065 * 512 = 8225280 bytes >>> Disk identifier: 0x00000000 >>> >>> Device Boot Start End Blocks Id System >>> /dev/sdb1 * 1 5 40131 c W95 FAT32 (LBA) >>> /dev/sdb2 6 239 1879605 83 Linux >>> >>> U-Boot 1.2.0 (Dec 21 2007 - 13:34:50) - PXA270@400 MHz - 1578M >>> >>> *** Welcome to Gumstix *** >>> >>> DRAM: 64 MB >>> Flash: 16 MB >>> Using default environment >>> >>> Hit any key to stop autoboot: 0 >>> 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> setenv bootargs console=ttyS0,115200n8 rootdelay=1 >>> root=/dev/mmcblk0p2 >>> GUM> fatload mmc 0 a2000000 uimage >>> reading uimage >>> >>> 1291348 bytes read >>> GUM> bootm a2000000 >>> ## Booting image at a2000000 ... >>> Image Name: Angstrom/2.6.31/gumstix-verdex >>> Image Type: ARM Linux Kernel Image (uncompressed) >>> Data Size: 1291284 Bytes = 1.2 MB >>> Load Address: a0008000 >>> Entry Point: a0008000 >>> OK >>> >>> Starting kernel ... >>> >>> Uncompressing >>> Linux.................................................................................. >>> done, booting the kernel. >>> Linux version 2.6.31 (gcc version 4.3.3 (GCC) ) #1 Fri Feb 26 15:45:41 >>> PST >>> 2010 >>> CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE), cr=0000397f >>> CPU: VIVT data cache, VIVT instruction cache >>> Machine: Gumstix verdex >>> Memory policy: ECC disabled, Data cache writeback >>> Run Mode clock: 208.00MHz (*16) >>> Turbo Mode clock: 416.00MHz (*2.0, active) >>> Memory clock: 104.00MHz (/2) >>> System bus clock: 104.00MHz >>> Built 1 zonelists in Zone order, mobility grouping on. Total pages: >>> 16256 >>> Kernel command line: console=ttyS0,115200n8 rootdelay=1 >>> root=/dev/mmcblk0p2 >>> PID hash table entries: 256 (order: 8, 1024 bytes) >>> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) >>> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) >>> Memory: 64MB = 64MB total >>> Memory: 62248KB available (2212K code, 252K data, 88K init, 0K highmem) >>> NR_IRQS:192 >>> Console: colour dummy device 80x30 >>> Calibrating delay loop... 415.33 BogoMIPS (lpj=2076672) >>> Mount-cache hash table entries: 512 >>> CPU: Testing write buffer coherency: ok >>> NET: Registered protocol family 16 >>> Gumstix verdex udc is disabled >>> Initializing Gumstix verdex i2c >>> Initializing Gumstix verdex smsc911x >>> Initializing Gumstix verdex pcmcia >>> Not netCF-vx board: pcmcia using newer GPIO configuration >>> CPLD responded with: ff >>> found 1 CF slots >>> Initializing Gumstix verdex FB info >>> Initializing Gumstix platform_add_devices >>> bio: create slab <bio-0> at 0 >>> NET: Registered protocol family 2 >>> IP route cache hash table entries: 1024 (order: 0, 4096 bytes) >>> TCP established hash table entries: 2048 (order: 2, 16384 bytes) >>> TCP bind hash table entries: 2048 (order: 1, 8192 bytes) >>> TCP: Hash tables configured (established 2048 bind 2048) >>> TCP reno registered >>> NET: Registered protocol family 1 >>> msgmni has been set to 121 >>> alg: No test for stdrng (krng) >>> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) >>> io scheduler noop registered >>> io scheduler cfq registered (default) >>> Console: switching to colour frame buffer device 80x24 >>> pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 22) is a FFUART >>> console [ttyS0] enabled >>> pxa2xx-uart.1: ttyS1 at MMIO 0x40200000 (irq = 21) is a BTUART >>> pxa2xx-uart.2: ttyS2 at MMIO 0x40700000 (irq = 20) is a STUART >>> Probing Gumstix Flash ROM at physical address 0x00000000 (16-bit >>> bankwidth) >>> Gumstix Flash ROM: Found 1 x16 devices at 0x0 in 16-bit bank >>> Intel/Sharp Extended Query Table at 0x010A >>> Intel/Sharp Extended Query Table at 0x010A >>> Intel/Sharp Extended Query Table at 0x010A >>> Intel/Sharp Extended Query Table at 0x010A >>> Intel/Sharp Extended Query Table at 0x010A >>> Using buffer write method >>> Using auto-unlock on power-up/resume >>> cfi_cmdset_0001: Erase suspend on write enabled >>> Using static partitions on Gumstix Flash ROM >>> Creating 3 MTD partitions on "Gumstix Flash ROM": >>> 0x000000000000-0x000000040000 : "Bootloader" >>> 0x000000040000-0x000000f00000 : "RootFS" >>> 0x000000f00000-0x000001000000 : "Kernel" >>> pxa-rtc pxa-rtc: rtc core: registered pxa-rtc as rtc0 >>> TCP cubic registered >>> NET: Registered protocol family 17 >>> XScale iWMMXt coprocessor detected. >>> pxa-rtc pxa-rtc: setting system clock to 2000-01-01 00:00:40 UTC >>> (946684840) >>> Waiting 1sec before mounting root device... >>> mmc0: host does not support reading read-only switch. assuming >>> write-enable. >>> mmc0: new SD card at address 1234 >>> mmcblk0: mmc0:1234 SA02G 1.83 GiB >>> mmcblk0: p1 p2 >>> kjournald starting. Commit interval 5 seconds >>> EXT3 FS on mmcblk0p2, internal journal >>> EXT3-fs: mounted filesystem with writeback data mode. >>> VFS: Mounted root (ext3 filesystem) on device 179:2. >>> Freeing init memory: 88K >>> INIT: version 2.86 booting >>> Please wait: booting... >>> Starting udev >>> I2C: i2c-0: PXA I2C adapter >>> I2C: i2c-1: PXA I2C adapter >>> tsc2003_probe >>> tsc2003 i2c touch screen controller >>> Bill Gatliff <bgat at billgatliff.com >>> Nicholas Chen <nchen at cs.umd.edu> >>> tsc2003_probe: checking i2c >>> tsc2003_probe: calling kzalloc >>> tsc2003_probe: probing address 0x48 >>> i2c: error: exhausted retries >>> i2c: msg_num: 0 msg_idx: -2000 msg_ptr: 0 >>> i2c: ICR: 000087e0 ISR: 00000002 >>> tsc2003: probe of 0-0048 failed with error -121 >>> usbcore: registered new interface driver usbfs >>> usbcore: registered new interface driver hub >>> usbcore: registered new device driver usb >>> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver >>> pxa27x-ohci pxa27x-ohci: PXA27x OHCI >>> pxa27x-ohci pxa27x-ohci: new USB bus registered, assigned bus number 1 >>> pxa27x-ohci pxa27x-ohci: irq 3, io mem 0x4c000000 >>> usb usb1: configuration #1 chosen from 1 choice >>> hub 1-0:1.0: USB hub found >>> hub 1-0:1.0: 3 ports detected >>> FAT: codepage cp437 not found >>> Remounting root file system... >>> Caching udev devnodes >>> Populating dev cache >>> logger: mount: mount point /dev/pts does not exist >>> logger: mount: mount point /dev/shm does not exist >>> Undefined users: >>>> pulse >>> Skipping /etc/default/volatiles/04_pulse >>> Undefined users: >>>> haldaemon >>> Skipping /etc/default/volatiles/99_hal >>> Starting Marvell Wifi CF8385... >>> Configuring network interfaces... eth0: unknown interface: No such device >>> eth0: unknown interface: No such device >>> eth0 No such device >>> >>> eth0: unknown interface: No such device >>> done. >>> Starting portmap daemon: portmapportmap: fork: No such device. >>> Unknown HZ value! (68) Assume 100. >>> net.ipv4.conf.default.rp_filter = 1 >>> net.ipv4.conf.all.rp_filter = 1 >>> hwclock: can't open '/dev/misc/rtc': No such file or directory >>> Mon Mar 1 11:18:00 UTC 2010 >>> hwclock: can't open '/dev/misc/rtc': No such file or directory >>> Checking for built-in Bluetooth: /etc/rcS.d/S97blueprobe: line 158: can't >>> open /dev/ttyS1: no such file >>> yes >>> Configuring ppp-dialin >>> Configuring pulseaudio-server >>> addgroup: pulse: group already in use >>> >>> Undefined users: >>>> haldaemon >>> Skipping /etc/default/volatiles/99_hal >>> postinst script returned status 1 >>> Configuring policykit >>> chmod: cannot access `/var/run/PolicyKit': No such file or directory >>> Configuring dbus >>> System startup links for /etc/init.d/dbus-1 already exist. >>> Configuring hicolor-icon-theme >>> //usr/lib/opkg/info/hicolor-icon-theme.postinst: line 7: can't create >>> /etc/gtk-2.0/gdk-pixbuf.loaders: nonexistent directory >>> //usr/lib/opkg/info/hicolor-icon-theme.postinst: line 7: >>> gdk-pixbuf-query-loaders: not found >>> //usr/lib/opkg/info/hicolor-icon-theme.postinst: line 13: >>> gtk-update-icon-cache: not found >>> postinst script returned status 127 >>> Configuring sudo >>> Configuring angstrom-zeroconf-audio >>> Configuring ppp >>> Configuring hal >>> Configuring avahi-autoipd >>> Configuring angstrom-libc-fixup-hack >>> Configuring avahi-daemon >>> System startup links for /etc/init.d/avahi-daemon already exist. >>> Configuring ntpdate >>> adding crontab >>> Configuring update-modules >>> Configuring libnss-mdns >>> Bluetooth: Core ver 2.15 >>> NET: Registered protocol family 31 >>> Bluetooth: HCI device and connection manager initialized >>> Bluetooth: HCI socket layer initialized >>> Bluetooth: L2CAP ver 2.13 >>> Bluetooth: L2CAP socket layer initialized >>> Bluetooth: HIDP (Human Interface Emulation) ver 1.2 >>> Registering gumstix PCMCIA interface. >>> Bluetooth: RFCOMM TTY layer initialized >>> Bluetooth: RFCOMM socket layer initialized >>> Bluetooth: RFCOMM ver 1.11 >>> smsc911x: Driver version 2008-10-21. >>> eth%d: smsc911x_init: Driver Parameters: >>> eth%d: smsc911x_init: LAN base: 0xC4A00000 >>> eth%d: smsc911x_init: IRQ: 163 >>> eth%d: smsc911x_init: PHY will be autodetected. >>> eth%d: smsc911x_init: BYTE_TEST: 0x87654321 >>> eth%d: smsc911x_init: LAN911x identified, idrev: 0x01170002, generation: >>> 2 >>> eth0: smsc911x_drv_probe: Network interface: "eth0" >>> eth0: smsc911x_phy_initialise_external: HW_CFG EXT_PHY_DET clear, using >>> internal PHY >>> smsc911x-mdio: probed >>> eth0: smsc911x_mii_probe: PHY 1: addr 1, phy_id 0x0007C0D1 >>> eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=ffffffff:01, >>> irq=-1) >>> eth0: smsc911x_phy_check_loopbackpkt: Successfully verified loopback >>> packet >>> eth0: smsc911x_mii_probe: Passed Loop Back Test >>> eth0: smsc911x_mii_probe: phy initialised succesfully >>> eth0: smsc911x_drv_probe: MAC Address is derived from system serial >>> number >>> net eth0: MAC Address: ae:f7:51:56:49:d0 >>> Collected errors: >>> * ERROR: pulseaudio-server.postinst returned 1 >>> * ERROR: hicolor-icon-theme.postinst returned 127 >>> i2c /dev entries driver >>> >>> >>> >>> >>> Ash Charles-2 wrote: >>>> >>>> Hi mlq, >>>> >>>> Good catch...I've changed it to address a2000000 (feel free to correct >>>> my idiocy directly in the future ;-) ). >>>> >>>> There is no reason it shouldn't work on an old XM4--I believe the >>>> processor is the same between these boards. >>>> >>>> Perhaps you can try the kernel found here >>>> (http://dl.dropbox.com/u/211887/uimage) to see if that works for you? >>>> >>>> -Ash >>>> P.S. Sorry if this is a double-posting. >>>> On Tue, Mar 2, 2010 at 4:09 PM, mlq <mar...@lm...> wrote: >>>>> >>>>> Sigh... >>>>> >>>>> I followed your instructions exactly and the boot sequnce freezes after >>>>> uncompressing linux ........ It does load to correct kernel though. >>>>> >>>>> I think the step in the wiki "fatload mmc 0 a20000000 uimage" should be >>>>> "fatload mmc 0 a2000000 uimage" (one less 0). >>>>> >>>>> Anyhow I have no idea why it is locking up, could it be because I have >>>>> an >>>>> old XM4 on not a verdex-pro? I was really hoping that it would work on >>>>> the >>>>> XM4. >>>>> >>>>> mlq >>>>> >>>>> >>>>> Ash Charles-2 wrote: >>>>>> >>>>>> Hi mlq, >>>>>> >>>>>> I have put together a documentation page on the user wiki: >>>>>> http://www.gumstix.net/wiki/index.php?title=Verdex_Git_Repository >>>>>> >>>>>> Note: MLO is an OMAP3 specific bootstrap loader. It is not necessary >>>>>> for Verdex. >>>>>> >>>>>> Let me know if you have have any problems. >>>>>> >>>>>> -Ash >>>>>> >>>>>> On Mon, Mar 1, 2010 at 1:23 PM, mlq <mar...@lm...> wrote: >>>>>>> >>>>>>> Hi Ash, >>>>>>> >>>>>>> I got everything built, thanks! I am struggling getting the verdex >>>>>>> image >>>>>>> to >>>>>>> boot. I tried using the MLO and u-boot that I use with the overo; >>>>>>> tried >>>>>>> to >>>>>>> rebuild them for the verdex (build failed); and I tried using the old >>>>>>> gumstix-factory.script - nothing seems to work. Should the >>>>>>> formatting >>>>>>> be >>>>>>> exactly the same as the overo? >>>>>>> >>>>>>> Could someone explain the steps I need to take to load the verdex >>>>>>> image >>>>>>> and >>>>>>> kernel on the microSD card and boot it? >>>>>>> >>>>>>> Thanks, >>>>>>> mlq >>>>>>> >>>>>>> >>>>>>> Ash Charles-2 wrote: >>>>>>>> >>>>>>>> Hey mlq, >>>>>>>> >>>>>>>> A 'bitbake virtual/kernel' should build the 2.6.31 kernel for >>>>>>>> verdex. >>>>>>>> Otherwise, the repository uses a 'task-base-gumstix' recipe to do >>>>>>>> most >>>>>>>> of the work for various other recipes in keeping with the old svn >>>>>>>> style. Note this does not match the current OE style of just adding >>>>>>>> machine-specific stuff conditionally to the task-base recipe---I >>>>>>>> tried >>>>>>>> and couldn't get this to work properly so if anyone has a fix for >>>>>>>> this >>>>>>>> I'd love to see it :). >>>>>>>> The git repository currently provides four Verdex images (thanks >>>>>>>> Joseph): >>>>>>>> - verdex-console-image >>>>>>>> - verdex-palmtop-image >>>>>>>> - verdex-desktop-image >>>>>>>> - verdex-gnome-image >>>>>>>> I had some problems building the last two because of the problems >>>>>>>> reported on the branch with news & gnumeric etc. but I'm confident >>>>>>>> these will go away as bugs get fixed upstream. I'd try the >>>>>>>> verdex-console-image for a start. >>>>>>>> >>>>>>>> For loading the code, essentially follow the instructions for Overo >>>>>>>> for booting from a microSD card. >>>>>>>> >>>>>>>> HTH, >>>>>>>> >>>>>>>> Ash >>>>>>>> >>>>>>>> P.S. If you do get those errors related to task-base, please post >>>>>>>> them >>>>>>>> so I can look through them. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Feb 27, 2010 at 11:10 AM, mlq <mar...@lm...> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I am also trying to build the verdex image and have sucessfully >>>>>>>>> built >>>>>>>>> the >>>>>>>>> minimal-image and kernel; however when I build the console image >>>>>>>>> i.e. >>>>>>>>> bitbake console-image it dies on building the task-base. Basically >>>>>>>>> it >>>>>>>>> is >>>>>>>>> looking in the task base folder but is missing the extensions for >>>>>>>>> the >>>>>>>>> particular tasks (task-base-x, missing x; sorry I dont have the >>>>>>>>> output >>>>>>>>> in >>>>>>>>> front of me). I have 2 questions; >>>>>>>>> >>>>>>>>> What is the correct recipe to bitbake for the verdex? (i cant seem >>>>>>>>> to >>>>>>>>> find >>>>>>>>> any verdex-specific recipes in the repo) >>>>>>>>> >>>>>>>>> What procedure should we follow to flash the mmc? (I was able to >>>>>>>>> boot >>>>>>>>> using >>>>>>>>> the FAT16 partition and gumstix-factory.script from the old svn >>>>>>>>> repo >>>>>>>>> but >>>>>>>>> I >>>>>>>>> am not sure if we should be using a similar setup to the overo with >>>>>>>>> xload?) >>>>>>>>> >>>>>>>>> Another related question which is not critical is when I add >>>>>>>>> recipes >>>>>>>>> to >>>>>>>>> user.collection/recipes bitbake does not see them - is there >>>>>>>>> typical >>>>>>>>> reason >>>>>>>>> for this? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> mlq >>>>>>>>> >>>>>>>>> >>>>>>>>> Connie C wrote: >>>>>>>>>> >>>>>>>>>> Hi Joseph, >>>>>>>>>> >>>>>>>>>> Thanks for the help. I'm definitely using the bash profile. >>>>>>>>>> Followed >>>>>>>>>> all >>>>>>>>>> those steps. I also followed the second sequence of code to make >>>>>>>>>> the >>>>>>>>>> verdex-oe directory and I have the bitbake,build, and >>>>>>>>>> org.openembedded.dev >>>>>>>>>> directories inside. I think everything looks okay up to there >>>>>>>>>> with >>>>>>>>>> what >>>>>>>>>> you posted. >>>>>>>>>> >>>>>>>>>> After removing my user.collection and com.gumstix.collection from >>>>>>>>>> the >>>>>>>>>> verdex-oe directory, I removed the extraneous tmp directory and >>>>>>>>>> ran >>>>>>>>>> bitbake verdex-console-image and got: >>>>>>>>>> ERROR: Nothing PROVIDES 'verdex-console-image' (but '[]' DEPENDS >>>>>>>>>> on >>>>>>>>>> or >>>>>>>>>> otherwise requires it) >>>>>>>>>> >>>>>>>>>> I had gotten this originally after I changed >>echo 0 > >>>>>>>>>> /proc/sys/vm/mmap_min_addr >>>>>>>>>> and was trying to access the .bb file directly as a result. >>>>>>>>>> >>>>>>>>>> Something with how my bitbake is set up? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Connie >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> bionicjoe wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, I corrected one critical line below ... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ________________________________ >>>>>>>>>>> From: Joseph Kortje <jp...@ro...> >>>>>>>>>>> To: General mailing list for gumstix users. >>>>>>>>>>> <gum...@li...> >>>>>>>>>>> Sent: Fri, February 26, 2010 9:12:35 PM >>>>>>>>>>> Subject: Re: [Gumstix-users] Bitbaking New Kernel 2.6.31 for >>>>>>>>>>> Verdex >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Connie >>>>>>>>>>> >>>>>>>>>>> Most of what Ash checked in for verdex-oe came originally from >>>>>>>>>>> myself >>>>>>>>>>> and >>>>>>>>>>> a few others >>>>>>>>>>> so I can help you. >>>>>>>>>>> >>>>>>>>>>> It builds clean for me. >>>>>>>>>>> >>>>>>>>>>> So, lets' review .... >>>>>>>>>>> >>>>>>>>>>> What OS distribution are you building with? >>>>>>>>>>> If it's Ubuntu, please confirm that you did the instruction to >>>>>>>>>>> not >>>>>>>>>>> reconfigure bash as dash. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>First I installed all the files in the new directory >>>>>>>>>>>>>verdex-oe. >>>>>>>>>>> >>>>>>>>>>> These should be the steps to follow: >>>>>>>>>>> >>>>>>>>>>> $ mkdir -p ~/verdex-oe >>>>>>>>>>> $ cd ~/verdex-oe >>>>>>>>>>> $ git clone git://gitorious.org/gumstix-oe/mainline.git >>>>>>>>>>> org.openembedded.dev >>>>>>>>>>> $ cd org.openembedded.dev >>>>>>>>>>> $ git checkout --track -b verdex origin/verdex >>>>>>>>>>> $ cd ~/verdex-oe >>>>>>>>>>> $ git clone git://git.openembedded.net/bitbake bitbake >>>>>>>>>>> $ cd bitbake >>>>>>>>>>> $ git checkout 1.8.18 >>>>>>>>>>> $ cd ~/verdex-oe >>>>>>>>>>> $ cp -r org.openembedded.dev/contrib/gumstix/build . >>>>>>>>>>> >>>>>>>>>>>>>sudo -i >>>>>>>>>>>>>echo 0 > /proc/sys/vm/mmap_min_addr >>>>>>>>>>> >>>>>>>>>>> Yes, that should work. >>>>>>>>>>> >>>>>>>>>>> Alternatively, you could edit /etc/sysctl.conf (For example sudo >>>>>>>>>>> gedit >>>>>>>>>>> /etc.sysctl.conf&) >>>>>>>>>>> and add the line >>>>>>>>>>> >>>>>>>>>>> vm.mmap_min_addr = 0 >>>>>>>>>>> >>>>>>>>>>> (Save and then reboot). >>>>>>>>>>> >>>>>>>>>>>>> First the bitbake complained that it could not find user >>>>>>>>>>>>>collection in verdex-oe, so I copied user.collection and >>>>>>>>>>>>>com.gumstix.collection over into the directory. >>>>>>>>>>> >>>>>>>>>>> There is no requirement to copy over user.collection from th >>>>>>>>>>> older >>>>>>>>>>> gumstix-oe build environment path. >>>>>>>>>>> The purpose of user.collection is to override the search path for >>>>>>>>>>> bitbake >>>>>>>>>>> recipes. If any bitbake recipes >>>>>>>>>>> in the user.collection path have the same base name as the ones >>>>>>>>>>> used >>>>>>>>>>> in >>>>>>>>>>> org.openembedded.dev then they would be used >>>>>>>>>>> in place of the official ones. Unless the developer has a >>>>>>>>>>> specific >>>>>>>>>>> reason for adding an override or customization >>>>>>>>>>> or new bitbake recipe, and understands what he/she is doing with >>>>>>>>>>> it >>>>>>>>>>> (and >>>>>>>>>>> the consequences) >>>>>>>>>>> I suggest not putting anything in user.collection folder (or >>>>>>>>>>> don't >>>>>>>>>>> use >>>>>>>>>>> the folder at all). >>>>>>>>>>> >>>>>>>>>>> Any old user.collection recipes that were used in the old >>>>>>>>>>> gumstix-oe >>>>>>>>>>> SVN >>>>>>>>>>> based projects will not necessarily be compatible >>>>>>>>>>> with the newer verdex-oe stuff since we are using a newer >>>>>>>>>>> Angstrom >>>>>>>>>>> distribution, newer Kernel, newer bitbake, >>>>>>>>>>> etc. Developers that have such recipes would need to revisit >>>>>>>>>>> them >>>>>>>>>>> to >>>>>>>>>>> port them to the new code base. >>>>>>>>>>> >>>>>>>>>>> The warning about not finding user.collection can therefore >>>>>>>>>>> simply >>>>>>>>>>> be >>>>>>>>>>> ignored since you are (presumably) >>>>>>>>>>> not going to be wanting to override any of the standard bitbake >>>>>>>>>>> recipes >>>>>>>>>>> or add any of your own >>>>>>>>>>> customized ones yet. >>>>>>>>>>> >>>>>>>>>>> The old "com.gumstix.collection" and any files in that folder >>>>>>>>>>> should >>>>>>>>>>> not >>>>>>>>>>> be added to this path and >>>>>>>>>>> is not supported anymore in the Git based OE architecture. Any >>>>>>>>>>> of >>>>>>>>>>> the >>>>>>>>>>> relevant patches or recipes (previously called packages) >>>>>>>>>>> from the previous com.gumstix.collection are now already >>>>>>>>>>> integrated >>>>>>>>>>> into >>>>>>>>>>> the git based verdex branch org.openembedded.dev recipes. >>>>>>>>>>> >>>>>>>>>>> (There are some exceptions such as support for audio, and >>>>>>>>>>> robostix >>>>>>>>>>> which >>>>>>>>>>> are currently not ported to the new verdex-oe branch. Still >>>>>>>>>>> working >>>>>>>>>>> on it ....). >>>>>>>>>>> >>>>>>>>>>> Here is how to fix your build environment: >>>>>>>>>>> >>>>>>>>>>> First, you need to clean out the incorrect files that were added >>>>>>>>>>> to >>>>>>>>>>> the >>>>>>>>>>> build path .... >>>>>>>>>>> >>>>>>>>>>> cd ~/verdex-oe >>>>>>>>>>> sudo rm -rf com.gumstix.collection >>>>>>>>>>> sudo rm -rf user.collection >>>>>>>>>>> >>>>>>>>>>> In this case, since the build cache is probably messed up, we >>>>>>>>>>> need >>>>>>>>>>> to >>>>>>>>>>> start with a clean build >>>>>>>>>>> >>>>>>>>>>> sudo rm -rf tmp >>>>>>>>>>> bitbake verdex-console-image >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Note: Please don't add ".bb" to the end of the bitbake recipe >>>>>>>>>>> names >>>>>>>>>>> in >>>>>>>>>>> the bitbake command. >>>>>>>>>>> Also, you can omit the -b option. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> BTW, please make sure that you have plenty of space in your /home >>>>>>>>>>> partition. >>>>>>>>>>> I use a 300GB partition albeit building for several projects for >>>>>>>>>>> OpenEmbedded and I still find that >>>>>>>>>>> my space gets eaten up really fast ... >>>>>>>>>>> >>>>>>>>>>> I recommend at least 40-60GB is needed to build verdex-oe (both >>>>>>>>>>> verdex-console-image and verdex-palmtop-image). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Let me know your results ... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Joseph >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> PS: Tip for building faster on dual or quad core cpu .... >>>>>>>>>>> >>>>>>>>>>> In >>>>>>>>>>> ~/verdex-oe/build/conf/site.conf >>>>>>>>>>> >>>>>>>>>>> # Uncomment these lines to enable parallel make. >>>>>>>>>>> # This allows make to spawn mutliple processes to take advantage >>>>>>>>>>> of >>>>>>>>>>> multiple >>>>>>>>>>> # processors. Useful on SMP machines >>>>>>>>>>> PARALLEL_MAKE = "-j 4" >>>>>>>>>>> BB_NUMBER_THREADS = "4" >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> View this message in context: >>>>>>>>> http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27730217.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27749237.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27762956.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27771565.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27772645.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: Joseph K. <jp...@ro...> - 2010-02-27 21:45:51
|
Hi Connie, I recommend edit /etc/sysctl.conf (For example sudo gedit /etc.sysctl.conf&) and add the line vm.mmap_min_addr = 0 (Save and then reboot). rather than the local echo method. (If you prefer, you can use vi or nano (sudo apt-get install nano). I personally like to use gedit in ubuntu (sudo apt-get install gedit) ). Re: >> ERROR: Nothing PROVIDES 'verdex-console-image' (but '[]' DEPENDS on or otherwise requires it) I can think of three ways that this can happen: 1. If the environment variables which control bitbake search paths were not set up correctly (that is, if somehow the build path environment is still searching in your old ~/gumstix-oe folder) 2. If the verdex branch for Git OpenEmbedded was not checked out correctly then the extra recipes for verdex-console-image.bb and verdex-palmtop-image and the correct build/conf files won't exist. For example, maybe you inadvertently checked out the overo branch from Git instead of the new verdex branch. 3. If the ~/verdex-oe/org.openembedded.dev/recipes/images/verdex-console-image.bb file was accidentally deleted. Remember that before you bitbake, it is required to type ... $ cd ~/verdex $ source build/profile for each time you open a new terminal session window in which to build. If you previously had changed your .bashrc file with the old build environment settings via the echo method then, depending on what was there, that can mess up the new ones. So you may need to clean up the ~/.bashrc file (remove or comment out any old build environment variables) and then always remember to use the "source build/profile" command sequence before bitbaking either from your old ~/gumstix-oe or new ~/verdex-oe path. Reboot please after changing any files like .bashrc which globally affect all of your bash terminal sessions. To verify this ..... After doing source build/profile., Could you please send an email of the environment variables of your session and of your current .bashrc .... Type this .... and copy/paste the results into your email please ... $printenv $cat /~.bashrc So that we can know if you are running on the correct Git branch, please also send this result: $cd ~/verdex-oe/org.openembedded.dev $git branch Regards, Joseph ________________________________ |
From: Connie C <cci...@um...> - 2010-02-28 17:58:42
|
Hi Joseph, Well, going back and doing one of the things you mentioned seems to have worked. Yipee! I now have the following in my images directory: Angstrom-verdex-console-image-glibc-ipk-2009.X-test-20100227-gumstix-verdex.rootfs.jffs2 Angstrom-verdex-console-image-glibc-ipk-2009.X-test-20100227-gumstix-verdex.rootfs.tar.gz Angstrom-verdex-console-image-glibc-ipk-2009.X-test-20100227-gumstix-verdex-testlab modules-2.6.31-r0-gumstix-verdex.tgz uImage-2.6.31-r0-gumstix-verdex.bin uImage-gumstix-verdex.bin verdex-console-image-gumstix-verdex.jffs2 verdex-console-image-gumstix-verdex.tar.gz Now to see if I can follow the directions for installing the kernel and making my own packages! Thanks for the help! I've been trying to make an updated kernel for a long time. Connie p.s. For curiosities sake, oeuser@SG1:~/verdex-oe$ printenv SHELL=/bin/bash TERM=xterm OEBRANCH=/home/oeuser/verdex-oe/org.openembedded.dev OLDPWD=/home/oeuser USER=oeuser LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.svgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36: GUMSTIXBRANCH=/home/oeuser/gumstix/gumstix-oe/com.gumstix.collection SUDO_USER=root SUDO_UID=0 USERNAME=oeuser USERBRANCH=/home/oeuser/verdex-oe/user.collection PATH=/home/oeuser/verdex-oe/bitbake/bin:/home/oeuser/gumstix/gumstix-oe/bitbake/bin:/usr/lib/kde4/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin PWD=/home/oeuser/verdex-oe LANG=en_US.UTF-8 TITOOLSDIR=/home/oeuser/verdex-oe/ti BBPATH=/home/oeuser/verdex-oe/build:/home/oeuser/verdex-oe/user.collection:/home/oeuser/verdex-oe/org.openembedded.dev HISTCONTROL=ignoreboth SHLVL=1 SUDO_COMMAND=/bin/bash HOME=/home/oeuser GUMSTIXTOP=/home/oeuser/gumstix/gumstix-oe VERDEXTOP=/home/oeuser/verdex-oe LOGNAME=oeuser LESSOPEN=| /usr/bin/lesspipe %s SUDO_GID=0 DISPLAY=:0.0 LESSCLOSE=/usr/bin/lesspipe %s %s BB_ENV_EXTRAWHITE=MACHINE DISTRO ANGSTROM_MODE VERDEXTOP OEBRANCH USERBRANCH TITOOLSDIR COLORTERM=gnome-terminal XAUTHORITY=/home/oeuser/.Xauthority _=/usr/bin/printenv and cat /~.bashrc cat: /~.bashrc: No such file or directory (weird) and oeuser@SG1:~/verdex-oe/org.openembedded.dev$ git branch org.openembedded.dev * verdex bionicjoe wrote: > > Hi Connie, > > > I recommend edit /etc/sysctl.conf (For example sudo gedit > /etc.sysctl.conf&) > and add the line > > vm.mmap_min_addr = 0 > > (Save and then reboot). > > rather than the local echo method. > > (If you prefer, you can use vi or nano (sudo apt-get install nano). > I personally like to use gedit in ubuntu (sudo apt-get install gedit) ). > > > Re: >>> ERROR: Nothing PROVIDES 'verdex-console-image' (but '[]' DEPENDS on or > otherwise requires it) > > I can think of three ways that this can happen: > > 1. If the environment variables which control bitbake search paths were > not set up correctly (that is, if > somehow the build path environment is still searching in your old > ~/gumstix-oe folder) > > 2. If the verdex branch for Git OpenEmbedded was not checked out correctly > then the extra > recipes for verdex-console-image.bb and verdex-palmtop-image and the > correct build/conf files won't exist. > For example, maybe you inadvertently checked out the overo branch from Git > instead of the new verdex branch. > > 3. If the > ~/verdex-oe/org.openembedded.dev/recipes/images/verdex-console-image.bb > file was accidentally deleted. > > Remember that before you bitbake, it is required to type ... > > $ cd ~/verdex > $ source build/profile > > for each time you open a new terminal session window in which to build. > > If you previously had changed your .bashrc file with the old build > environment > settings via the echo method then, depending on what was there, that can > mess up the new ones. > > So you may need to clean up the ~/.bashrc file (remove or comment out any > old build environment variables) > and then always remember to use the "source build/profile" command > sequence before bitbaking either from your old > ~/gumstix-oe or new ~/verdex-oe path. Reboot please after changing any > files like .bashrc which > globally affect all of your bash terminal sessions. > > To verify this ..... > > After doing source build/profile., > Could you please send an email of the environment variables of your > session and of your current .bashrc .... > > Type this .... and copy/paste the results into your email please ... > > $printenv > $cat /~.bashrc > > > So that we can know if you are running on the correct Git branch, please > also send this result: > > $cd ~/verdex-oe/org.openembedded.dev > $git branch > > > > Regards, > Joseph > > > > > ________________________________ > ------------------------------------------------------------------------------ > 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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27736788.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Ash C. <as...@gu...> - 2010-02-28 06:35:22
|
Hey mlq, A 'bitbake virtual/kernel' should build the 2.6.31 kernel for verdex. Otherwise, the repository uses a 'task-base-gumstix' recipe to do most of the work for various other recipes in keeping with the old svn style. Note this does not match the current OE style of just adding machine-specific stuff conditionally to the task-base recipe---I tried and couldn't get this to work properly so if anyone has a fix for this I'd love to see it :). The git repository currently provides four Verdex images (thanks Joseph): - verdex-console-image - verdex-palmtop-image - verdex-desktop-image - verdex-gnome-image I had some problems building the last two because of the problems reported on the branch with news & gnumeric etc. but I'm confident these will go away as bugs get fixed upstream. I'd try the verdex-console-image for a start. For loading the code, essentially follow the instructions for Overo for booting from a microSD card. HTH, Ash P.S. If you do get those errors related to task-base, please post them so I can look through them. On Sat, Feb 27, 2010 at 11:10 AM, mlq <mar...@lm...> wrote: > > I am also trying to build the verdex image and have sucessfully built the > minimal-image and kernel; however when I build the console image i.e. > bitbake console-image it dies on building the task-base. Basically it is > looking in the task base folder but is missing the extensions for the > particular tasks (task-base-x, missing x; sorry I dont have the output in > front of me). I have 2 questions; > > What is the correct recipe to bitbake for the verdex? (i cant seem to find > any verdex-specific recipes in the repo) > > What procedure should we follow to flash the mmc? (I was able to boot using > the FAT16 partition and gumstix-factory.script from the old svn repo but I > am not sure if we should be using a similar setup to the overo with xload?) > > Another related question which is not critical is when I add recipes to > user.collection/recipes bitbake does not see them - is there typical reason > for this? > > Thanks, > mlq > > > Connie C wrote: >> >> Hi Joseph, >> >> Thanks for the help. I'm definitely using the bash profile. Followed all >> those steps. I also followed the second sequence of code to make the >> verdex-oe directory and I have the bitbake,build, and org.openembedded.dev >> directories inside. I think everything looks okay up to there with what >> you posted. >> >> After removing my user.collection and com.gumstix.collection from the >> verdex-oe directory, I removed the extraneous tmp directory and ran >> bitbake verdex-console-image and got: >> ERROR: Nothing PROVIDES 'verdex-console-image' (but '[]' DEPENDS on or >> otherwise requires it) >> >> I had gotten this originally after I changed >>echo 0 > >> /proc/sys/vm/mmap_min_addr >> and was trying to access the .bb file directly as a result. >> >> Something with how my bitbake is set up? >> >> Thanks, >> >> Connie >> >> >> >> >> bionicjoe wrote: >>> >>> Hi, I corrected one critical line below ... >>> >>> >>> >>> >>> ________________________________ >>> From: Joseph Kortje <jp...@ro...> >>> To: General mailing list for gumstix users. >>> <gum...@li...> >>> Sent: Fri, February 26, 2010 9:12:35 PM >>> Subject: Re: [Gumstix-users] Bitbaking New Kernel 2.6.31 for Verdex >>> >>> >>> Hi Connie >>> >>> Most of what Ash checked in for verdex-oe came originally from myself and >>> a few others >>> so I can help you. >>> >>> It builds clean for me. >>> >>> So, lets' review .... >>> >>> What OS distribution are you building with? >>> If it's Ubuntu, please confirm that you did the instruction to not >>> reconfigure bash as dash. >>> >>> >>>>>First I installed all the files in the new directory >>>>>verdex-oe. >>> >>> These should be the steps to follow: >>> >>> $ mkdir -p ~/verdex-oe >>> $ cd ~/verdex-oe >>> $ git clone git://gitorious.org/gumstix-oe/mainline.git >>> org.openembedded.dev >>> $ cd org.openembedded.dev >>> $ git checkout --track -b verdex origin/verdex >>> $ cd ~/verdex-oe >>> $ git clone git://git.openembedded.net/bitbake bitbake >>> $ cd bitbake >>> $ git checkout 1.8.18 >>> $ cd ~/verdex-oe >>> $ cp -r org.openembedded.dev/contrib/gumstix/build . >>> >>>>>sudo -i >>>>>echo 0 > /proc/sys/vm/mmap_min_addr >>> >>> Yes, that should work. >>> >>> Alternatively, you could edit /etc/sysctl.conf (For example sudo gedit >>> /etc.sysctl.conf&) >>> and add the line >>> >>> vm.mmap_min_addr = 0 >>> >>> (Save and then reboot). >>> >>>>> First the bitbake complained that it could not find user >>>>>collection in verdex-oe, so I copied user.collection and >>>>>com.gumstix.collection over into the directory. >>> >>> There is no requirement to copy over user.collection from th older >>> gumstix-oe build environment path. >>> The purpose of user.collection is to override the search path for bitbake >>> recipes. If any bitbake recipes >>> in the user.collection path have the same base name as the ones used in >>> org.openembedded.dev then they would be used >>> in place of the official ones. Unless the developer has a specific >>> reason for adding an override or customization >>> or new bitbake recipe, and understands what he/she is doing with it (and >>> the consequences) >>> I suggest not putting anything in user.collection folder (or don't use >>> the folder at all). >>> >>> Any old user.collection recipes that were used in the old gumstix-oe SVN >>> based projects will not necessarily be compatible >>> with the newer verdex-oe stuff since we are using a newer Angstrom >>> distribution, newer Kernel, newer bitbake, >>> etc. Developers that have such recipes would need to revisit them to >>> port them to the new code base. >>> >>> The warning about not finding user.collection can therefore simply be >>> ignored since you are (presumably) >>> not going to be wanting to override any of the standard bitbake recipes >>> or add any of your own >>> customized ones yet. >>> >>> The old "com.gumstix.collection" and any files in that folder should not >>> be added to this path and >>> is not supported anymore in the Git based OE architecture. Any of the >>> relevant patches or recipes (previously called packages) >>> from the previous com.gumstix.collection are now already integrated into >>> the git based verdex branch org.openembedded.dev recipes. >>> >>> (There are some exceptions such as support for audio, and robostix which >>> are currently not ported to the new verdex-oe branch. Still working >>> on it ....). >>> >>> Here is how to fix your build environment: >>> >>> First, you need to clean out the incorrect files that were added to the >>> build path .... >>> >>> cd ~/verdex-oe >>> sudo rm -rf com.gumstix.collection >>> sudo rm -rf user.collection >>> >>> In this case, since the build cache is probably messed up, we need to >>> start with a clean build >>> >>> sudo rm -rf tmp >>> bitbake verdex-console-image >>> >>> >>> Note: Please don't add ".bb" to the end of the bitbake recipe names in >>> the bitbake command. >>> Also, you can omit the -b option. >>> >>> >>> BTW, please make sure that you have plenty of space in your /home >>> partition. >>> I use a 300GB partition albeit building for several projects for >>> OpenEmbedded and I still find that >>> my space gets eaten up really fast ... >>> >>> I recommend at least 40-60GB is needed to build verdex-oe (both >>> verdex-console-image and verdex-palmtop-image). >>> >>> >>> Let me know your results ... >>> >>> >>> Regards >>> Joseph >>> >>> >>> PS: Tip for building faster on dual or quad core cpu .... >>> >>> In >>> ~/verdex-oe/build/conf/site.conf >>> >>> # Uncomment these lines to enable parallel make. >>> # This allows make to spawn mutliple processes to take advantage of >>> multiple >>> # processors. Useful on SMP machines >>> PARALLEL_MAKE = "-j 4" >>> BB_NUMBER_THREADS = "4" >>> >> >> >> >> > > -- > View this message in context: http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27730217.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-01 21:23:30
|
Hi Ash, I got everything built, thanks! I am struggling getting the verdex image to boot. I tried using the MLO and u-boot that I use with the overo; tried to rebuild them for the verdex (build failed); and I tried using the old gumstix-factory.script - nothing seems to work. Should the formatting be exactly the same as the overo? Could someone explain the steps I need to take to load the verdex image and kernel on the microSD card and boot it? Thanks, mlq Ash Charles-2 wrote: > > Hey mlq, > > A 'bitbake virtual/kernel' should build the 2.6.31 kernel for verdex. > Otherwise, the repository uses a 'task-base-gumstix' recipe to do most > of the work for various other recipes in keeping with the old svn > style. Note this does not match the current OE style of just adding > machine-specific stuff conditionally to the task-base recipe---I tried > and couldn't get this to work properly so if anyone has a fix for this > I'd love to see it :). > The git repository currently provides four Verdex images (thanks Joseph): > - verdex-console-image > - verdex-palmtop-image > - verdex-desktop-image > - verdex-gnome-image > I had some problems building the last two because of the problems > reported on the branch with news & gnumeric etc. but I'm confident > these will go away as bugs get fixed upstream. I'd try the > verdex-console-image for a start. > > For loading the code, essentially follow the instructions for Overo > for booting from a microSD card. > > HTH, > > Ash > > P.S. If you do get those errors related to task-base, please post them > so I can look through them. > > > > On Sat, Feb 27, 2010 at 11:10 AM, mlq <mar...@lm...> wrote: >> >> I am also trying to build the verdex image and have sucessfully built the >> minimal-image and kernel; however when I build the console image i.e. >> bitbake console-image it dies on building the task-base. Basically it is >> looking in the task base folder but is missing the extensions for the >> particular tasks (task-base-x, missing x; sorry I dont have the output in >> front of me). I have 2 questions; >> >> What is the correct recipe to bitbake for the verdex? (i cant seem to >> find >> any verdex-specific recipes in the repo) >> >> What procedure should we follow to flash the mmc? (I was able to boot >> using >> the FAT16 partition and gumstix-factory.script from the old svn repo but >> I >> am not sure if we should be using a similar setup to the overo with >> xload?) >> >> Another related question which is not critical is when I add recipes to >> user.collection/recipes bitbake does not see them - is there typical >> reason >> for this? >> >> Thanks, >> mlq >> >> >> Connie C wrote: >>> >>> Hi Joseph, >>> >>> Thanks for the help. I'm definitely using the bash profile. Followed >>> all >>> those steps. I also followed the second sequence of code to make the >>> verdex-oe directory and I have the bitbake,build, and >>> org.openembedded.dev >>> directories inside. I think everything looks okay up to there with what >>> you posted. >>> >>> After removing my user.collection and com.gumstix.collection from the >>> verdex-oe directory, I removed the extraneous tmp directory and ran >>> bitbake verdex-console-image and got: >>> ERROR: Nothing PROVIDES 'verdex-console-image' (but '[]' DEPENDS on or >>> otherwise requires it) >>> >>> I had gotten this originally after I changed >>echo 0 > >>> /proc/sys/vm/mmap_min_addr >>> and was trying to access the .bb file directly as a result. >>> >>> Something with how my bitbake is set up? >>> >>> Thanks, >>> >>> Connie >>> >>> >>> >>> >>> bionicjoe wrote: >>>> >>>> Hi, I corrected one critical line below ... >>>> >>>> >>>> >>>> >>>> ________________________________ >>>> From: Joseph Kortje <jp...@ro...> >>>> To: General mailing list for gumstix users. >>>> <gum...@li...> >>>> Sent: Fri, February 26, 2010 9:12:35 PM >>>> Subject: Re: [Gumstix-users] Bitbaking New Kernel 2.6.31 for Verdex >>>> >>>> >>>> Hi Connie >>>> >>>> Most of what Ash checked in for verdex-oe came originally from myself >>>> and >>>> a few others >>>> so I can help you. >>>> >>>> It builds clean for me. >>>> >>>> So, lets' review .... >>>> >>>> What OS distribution are you building with? >>>> If it's Ubuntu, please confirm that you did the instruction to not >>>> reconfigure bash as dash. >>>> >>>> >>>>>>First I installed all the files in the new directory >>>>>>verdex-oe. >>>> >>>> These should be the steps to follow: >>>> >>>> $ mkdir -p ~/verdex-oe >>>> $ cd ~/verdex-oe >>>> $ git clone git://gitorious.org/gumstix-oe/mainline.git >>>> org.openembedded.dev >>>> $ cd org.openembedded.dev >>>> $ git checkout --track -b verdex origin/verdex >>>> $ cd ~/verdex-oe >>>> $ git clone git://git.openembedded.net/bitbake bitbake >>>> $ cd bitbake >>>> $ git checkout 1.8.18 >>>> $ cd ~/verdex-oe >>>> $ cp -r org.openembedded.dev/contrib/gumstix/build . >>>> >>>>>>sudo -i >>>>>>echo 0 > /proc/sys/vm/mmap_min_addr >>>> >>>> Yes, that should work. >>>> >>>> Alternatively, you could edit /etc/sysctl.conf (For example sudo gedit >>>> /etc.sysctl.conf&) >>>> and add the line >>>> >>>> vm.mmap_min_addr = 0 >>>> >>>> (Save and then reboot). >>>> >>>>>> First the bitbake complained that it could not find user >>>>>>collection in verdex-oe, so I copied user.collection and >>>>>>com.gumstix.collection over into the directory. >>>> >>>> There is no requirement to copy over user.collection from th older >>>> gumstix-oe build environment path. >>>> The purpose of user.collection is to override the search path for >>>> bitbake >>>> recipes. If any bitbake recipes >>>> in the user.collection path have the same base name as the ones used in >>>> org.openembedded.dev then they would be used >>>> in place of the official ones. Unless the developer has a specific >>>> reason for adding an override or customization >>>> or new bitbake recipe, and understands what he/she is doing with it >>>> (and >>>> the consequences) >>>> I suggest not putting anything in user.collection folder (or don't use >>>> the folder at all). >>>> >>>> Any old user.collection recipes that were used in the old gumstix-oe >>>> SVN >>>> based projects will not necessarily be compatible >>>> with the newer verdex-oe stuff since we are using a newer Angstrom >>>> distribution, newer Kernel, newer bitbake, >>>> etc. Developers that have such recipes would need to revisit them to >>>> port them to the new code base. >>>> >>>> The warning about not finding user.collection can therefore simply be >>>> ignored since you are (presumably) >>>> not going to be wanting to override any of the standard bitbake recipes >>>> or add any of your own >>>> customized ones yet. >>>> >>>> The old "com.gumstix.collection" and any files in that folder should >>>> not >>>> be added to this path and >>>> is not supported anymore in the Git based OE architecture. Any of the >>>> relevant patches or recipes (previously called packages) >>>> from the previous com.gumstix.collection are now already integrated >>>> into >>>> the git based verdex branch org.openembedded.dev recipes. >>>> >>>> (There are some exceptions such as support for audio, and robostix >>>> which >>>> are currently not ported to the new verdex-oe branch. Still working >>>> on it ....). >>>> >>>> Here is how to fix your build environment: >>>> >>>> First, you need to clean out the incorrect files that were added to the >>>> build path .... >>>> >>>> cd ~/verdex-oe >>>> sudo rm -rf com.gumstix.collection >>>> sudo rm -rf user.collection >>>> >>>> In this case, since the build cache is probably messed up, we need to >>>> start with a clean build >>>> >>>> sudo rm -rf tmp >>>> bitbake verdex-console-image >>>> >>>> >>>> Note: Please don't add ".bb" to the end of the bitbake recipe names in >>>> the bitbake command. >>>> Also, you can omit the -b option. >>>> >>>> >>>> BTW, please make sure that you have plenty of space in your /home >>>> partition. >>>> I use a 300GB partition albeit building for several projects for >>>> OpenEmbedded and I still find that >>>> my space gets eaten up really fast ... >>>> >>>> I recommend at least 40-60GB is needed to build verdex-oe (both >>>> verdex-console-image and verdex-palmtop-image). >>>> >>>> >>>> Let me know your results ... >>>> >>>> >>>> Regards >>>> Joseph >>>> >>>> >>>> PS: Tip for building faster on dual or quad core cpu .... >>>> >>>> In >>>> ~/verdex-oe/build/conf/site.conf >>>> >>>> # Uncomment these lines to enable parallel make. >>>> # This allows make to spawn mutliple processes to take advantage of >>>> multiple >>>> # processors. Useful on SMP machines >>>> PARALLEL_MAKE = "-j 4" >>>> BB_NUMBER_THREADS = "4" >>>> >>> >>> >>> >>> >> >> -- >> View this message in context: >> http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27730217.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27749237.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Connie C <cci...@um...> - 2010-03-02 22:42:03
|
Hi all, (again) So very happy about successfully bitbaking the 2.6.31 kernel. However, I seem to having issues extracting the rootfs from the tarball. I partitioned my 2Gb microsd card yesterday according to http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html Except with a FAT16 partition and .ext2 partition and I put gumstix-factory.script and uImage in the FAT partition and tried to unpack the .tar.gz in the .ext2 partition. Trying to upack to tarball fails. I've also tried to extract single files/folders from the tarball into other locations on my desktop and card. Some of the folders work succesfully and can be extracted. However, some, like mnt, will not extract. (this is to both the sd card and to a random folder on my desktop)(I did also read : The final step is to untar your desired rootfs onto the ext3 partition that you created above. Note that this step can be dangerous. You do not want to untar your Overo rootfs onto your development machine - be careful! and so am only doing individual files and then deleting them) I used fdsk for the partitioning. I thought it might be how I partitioned the card at first and ran dmsg and got a few types of errors: [687450.710992] attempt to access beyond end of device [687450.710996] sdc: rw=0, want=4012501, limit=3842048 [687451.119556] EXT2-fs error (device sdc2): read_inode_bitmap: Cannot read inode bitmap - block_group = 15, inode_bitmap = 491521 [686293.686071] sdc: rw=1, want=3848813, limit=3842048 [686293.686074] attempt to access beyond end of device [686312.717664] EXT2-fs error (device sdc2): ext2_readdir: bad page in #109313 I have gone back through the partitioning instructions several times and I think my card has been done successfully. (I can upload the transcript for the session) especially since I cant remove some of the files from the tarball at all. Thanks! Connie C. -- View this message in context: http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27762177.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Ash C. <as...@gu...> - 2010-03-02 22:59:57
|
Hi mlq, I have put together a documentation page on the user wiki: http://www.gumstix.net/wiki/index.php?title=Verdex_Git_Repository Note: MLO is an OMAP3 specific bootstrap loader. It is not necessary for Verdex. Let me know if you have have any problems. -Ash On Mon, Mar 1, 2010 at 1:23 PM, mlq <mar...@lm...> wrote: > > Hi Ash, > > I got everything built, thanks! I am struggling getting the verdex image to > boot. I tried using the MLO and u-boot that I use with the overo; tried to > rebuild them for the verdex (build failed); and I tried using the old > gumstix-factory.script - nothing seems to work. Should the formatting be > exactly the same as the overo? > > Could someone explain the steps I need to take to load the verdex image and > kernel on the microSD card and boot it? > > Thanks, > mlq > > > Ash Charles-2 wrote: >> >> Hey mlq, >> >> A 'bitbake virtual/kernel' should build the 2.6.31 kernel for verdex. >> Otherwise, the repository uses a 'task-base-gumstix' recipe to do most >> of the work for various other recipes in keeping with the old svn >> style. Note this does not match the current OE style of just adding >> machine-specific stuff conditionally to the task-base recipe---I tried >> and couldn't get this to work properly so if anyone has a fix for this >> I'd love to see it :). >> The git repository currently provides four Verdex images (thanks Joseph): >> - verdex-console-image >> - verdex-palmtop-image >> - verdex-desktop-image >> - verdex-gnome-image >> I had some problems building the last two because of the problems >> reported on the branch with news & gnumeric etc. but I'm confident >> these will go away as bugs get fixed upstream. I'd try the >> verdex-console-image for a start. >> >> For loading the code, essentially follow the instructions for Overo >> for booting from a microSD card. >> >> HTH, >> >> Ash >> >> P.S. If you do get those errors related to task-base, please post them >> so I can look through them. >> >> >> >> On Sat, Feb 27, 2010 at 11:10 AM, mlq <mar...@lm...> wrote: >>> >>> I am also trying to build the verdex image and have sucessfully built the >>> minimal-image and kernel; however when I build the console image i.e. >>> bitbake console-image it dies on building the task-base. Basically it is >>> looking in the task base folder but is missing the extensions for the >>> particular tasks (task-base-x, missing x; sorry I dont have the output in >>> front of me). I have 2 questions; >>> >>> What is the correct recipe to bitbake for the verdex? (i cant seem to >>> find >>> any verdex-specific recipes in the repo) >>> >>> What procedure should we follow to flash the mmc? (I was able to boot >>> using >>> the FAT16 partition and gumstix-factory.script from the old svn repo but >>> I >>> am not sure if we should be using a similar setup to the overo with >>> xload?) >>> >>> Another related question which is not critical is when I add recipes to >>> user.collection/recipes bitbake does not see them - is there typical >>> reason >>> for this? >>> >>> Thanks, >>> mlq >>> >>> >>> Connie C wrote: >>>> >>>> Hi Joseph, >>>> >>>> Thanks for the help. I'm definitely using the bash profile. Followed >>>> all >>>> those steps. I also followed the second sequence of code to make the >>>> verdex-oe directory and I have the bitbake,build, and >>>> org.openembedded.dev >>>> directories inside. I think everything looks okay up to there with what >>>> you posted. >>>> >>>> After removing my user.collection and com.gumstix.collection from the >>>> verdex-oe directory, I removed the extraneous tmp directory and ran >>>> bitbake verdex-console-image and got: >>>> ERROR: Nothing PROVIDES 'verdex-console-image' (but '[]' DEPENDS on or >>>> otherwise requires it) >>>> >>>> I had gotten this originally after I changed >>echo 0 > >>>> /proc/sys/vm/mmap_min_addr >>>> and was trying to access the .bb file directly as a result. >>>> >>>> Something with how my bitbake is set up? >>>> >>>> Thanks, >>>> >>>> Connie >>>> >>>> >>>> >>>> >>>> bionicjoe wrote: >>>>> >>>>> Hi, I corrected one critical line below ... >>>>> >>>>> >>>>> >>>>> >>>>> ________________________________ >>>>> From: Joseph Kortje <jp...@ro...> >>>>> To: General mailing list for gumstix users. >>>>> <gum...@li...> >>>>> Sent: Fri, February 26, 2010 9:12:35 PM >>>>> Subject: Re: [Gumstix-users] Bitbaking New Kernel 2.6.31 for Verdex >>>>> >>>>> >>>>> Hi Connie >>>>> >>>>> Most of what Ash checked in for verdex-oe came originally from myself >>>>> and >>>>> a few others >>>>> so I can help you. >>>>> >>>>> It builds clean for me. >>>>> >>>>> So, lets' review .... >>>>> >>>>> What OS distribution are you building with? >>>>> If it's Ubuntu, please confirm that you did the instruction to not >>>>> reconfigure bash as dash. >>>>> >>>>> >>>>>>>First I installed all the files in the new directory >>>>>>>verdex-oe. >>>>> >>>>> These should be the steps to follow: >>>>> >>>>> $ mkdir -p ~/verdex-oe >>>>> $ cd ~/verdex-oe >>>>> $ git clone git://gitorious.org/gumstix-oe/mainline.git >>>>> org.openembedded.dev >>>>> $ cd org.openembedded.dev >>>>> $ git checkout --track -b verdex origin/verdex >>>>> $ cd ~/verdex-oe >>>>> $ git clone git://git.openembedded.net/bitbake bitbake >>>>> $ cd bitbake >>>>> $ git checkout 1.8.18 >>>>> $ cd ~/verdex-oe >>>>> $ cp -r org.openembedded.dev/contrib/gumstix/build . >>>>> >>>>>>>sudo -i >>>>>>>echo 0 > /proc/sys/vm/mmap_min_addr >>>>> >>>>> Yes, that should work. >>>>> >>>>> Alternatively, you could edit /etc/sysctl.conf (For example sudo gedit >>>>> /etc.sysctl.conf&) >>>>> and add the line >>>>> >>>>> vm.mmap_min_addr = 0 >>>>> >>>>> (Save and then reboot). >>>>> >>>>>>> First the bitbake complained that it could not find user >>>>>>>collection in verdex-oe, so I copied user.collection and >>>>>>>com.gumstix.collection over into the directory. >>>>> >>>>> There is no requirement to copy over user.collection from th older >>>>> gumstix-oe build environment path. >>>>> The purpose of user.collection is to override the search path for >>>>> bitbake >>>>> recipes. If any bitbake recipes >>>>> in the user.collection path have the same base name as the ones used in >>>>> org.openembedded.dev then they would be used >>>>> in place of the official ones. Unless the developer has a specific >>>>> reason for adding an override or customization >>>>> or new bitbake recipe, and understands what he/she is doing with it >>>>> (and >>>>> the consequences) >>>>> I suggest not putting anything in user.collection folder (or don't use >>>>> the folder at all). >>>>> >>>>> Any old user.collection recipes that were used in the old gumstix-oe >>>>> SVN >>>>> based projects will not necessarily be compatible >>>>> with the newer verdex-oe stuff since we are using a newer Angstrom >>>>> distribution, newer Kernel, newer bitbake, >>>>> etc. Developers that have such recipes would need to revisit them to >>>>> port them to the new code base. >>>>> >>>>> The warning about not finding user.collection can therefore simply be >>>>> ignored since you are (presumably) >>>>> not going to be wanting to override any of the standard bitbake recipes >>>>> or add any of your own >>>>> customized ones yet. >>>>> >>>>> The old "com.gumstix.collection" and any files in that folder should >>>>> not >>>>> be added to this path and >>>>> is not supported anymore in the Git based OE architecture. Any of the >>>>> relevant patches or recipes (previously called packages) >>>>> from the previous com.gumstix.collection are now already integrated >>>>> into >>>>> the git based verdex branch org.openembedded.dev recipes. >>>>> >>>>> (There are some exceptions such as support for audio, and robostix >>>>> which >>>>> are currently not ported to the new verdex-oe branch. Still working >>>>> on it ....). >>>>> >>>>> Here is how to fix your build environment: >>>>> >>>>> First, you need to clean out the incorrect files that were added to the >>>>> build path .... >>>>> >>>>> cd ~/verdex-oe >>>>> sudo rm -rf com.gumstix.collection >>>>> sudo rm -rf user.collection >>>>> >>>>> In this case, since the build cache is probably messed up, we need to >>>>> start with a clean build >>>>> >>>>> sudo rm -rf tmp >>>>> bitbake verdex-console-image >>>>> >>>>> >>>>> Note: Please don't add ".bb" to the end of the bitbake recipe names in >>>>> the bitbake command. >>>>> Also, you can omit the -b option. >>>>> >>>>> >>>>> BTW, please make sure that you have plenty of space in your /home >>>>> partition. >>>>> I use a 300GB partition albeit building for several projects for >>>>> OpenEmbedded and I still find that >>>>> my space gets eaten up really fast ... >>>>> >>>>> I recommend at least 40-60GB is needed to build verdex-oe (both >>>>> verdex-console-image and verdex-palmtop-image). >>>>> >>>>> >>>>> Let me know your results ... >>>>> >>>>> >>>>> Regards >>>>> Joseph >>>>> >>>>> >>>>> PS: Tip for building faster on dual or quad core cpu .... >>>>> >>>>> In >>>>> ~/verdex-oe/build/conf/site.conf >>>>> >>>>> # Uncomment these lines to enable parallel make. >>>>> # This allows make to spawn mutliple processes to take advantage of >>>>> multiple >>>>> # processors. Useful on SMP machines >>>>> PARALLEL_MAKE = "-j 4" >>>>> BB_NUMBER_THREADS = "4" >>>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27730217.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27749237.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-02 23:08:10
|
Hi Connie, Do you have superuser access when extracting the root file system? Say Ext2|Ext3 partition is at /media/card_ext and your root filesystem named 'verdex-console-image-verdex.tar.gz' is in the current directory. Does this command fail? $ sudo tar -xzf verdex-console-image-verdex.tar.gz -C /media/card_ext/ The reason the documentation notes the step to be dangerous is because you are extracting a root filesystem. If you neglect the -C option or accidentally extract to '/', you could overwrite important sections of your own machine! -Ash On Tue, Mar 2, 2010 at 2:41 PM, Connie C <cci...@um...> wrote: > > Hi all, (again) > > So very happy about successfully bitbaking the 2.6.31 kernel. However, I > seem to having issues extracting the rootfs from the tarball. I partitioned > my 2Gb microsd card yesterday according to > http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html > > Except with a FAT16 partition and .ext2 partition > and I put gumstix-factory.script and uImage in the FAT partition and tried > to unpack the .tar.gz in the .ext2 partition. Trying to upack to tarball > fails. I've also tried to extract single files/folders from the tarball > into other locations on my desktop and card. Some of the folders work > succesfully and can be extracted. However, some, like mnt, will not > extract. (this is to both the sd card and to a random folder on my > desktop)(I did also read : The final step is to untar your desired rootfs > onto the ext3 partition that you created above. > Note that this step can be dangerous. You do not want to untar your Overo > rootfs onto your development machine - be careful! and so am only doing > individual files and then deleting them) > > I used fdsk for the partitioning. I thought it might be how I partitioned > the card at first and ran dmsg and got a few types of errors: > [687450.710992] attempt to access beyond end of device > [687450.710996] sdc: rw=0, want=4012501, limit=3842048 > [687451.119556] EXT2-fs error (device sdc2): read_inode_bitmap: Cannot read > inode bitmap - block_group = 15, inode_bitmap = 491521 > > [686293.686071] sdc: rw=1, want=3848813, limit=3842048 > [686293.686074] attempt to access beyond end of device > > [686312.717664] EXT2-fs error (device sdc2): ext2_readdir: bad page in > #109313 > > I have gone back through the partitioning instructions several times and I > think my card has been done successfully. (I can upload the transcript for > the session) especially since I cant remove some of the files from the > tarball at all. > > Thanks! > > Connie C. > > > -- > View this message in context: http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27762177.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-03 00:09:31
|
Sigh... I followed your instructions exactly and the boot sequnce freezes after uncompressing linux ........ It does load to correct kernel though. I think the step in the wiki "fatload mmc 0 a20000000 uimage" should be "fatload mmc 0 a2000000 uimage" (one less 0). Anyhow I have no idea why it is locking up, could it be because I have an old XM4 on not a verdex-pro? I was really hoping that it would work on the XM4. mlq Ash Charles-2 wrote: > > Hi mlq, > > I have put together a documentation page on the user wiki: > http://www.gumstix.net/wiki/index.php?title=Verdex_Git_Repository > > Note: MLO is an OMAP3 specific bootstrap loader. It is not necessary > for Verdex. > > Let me know if you have have any problems. > > -Ash > > On Mon, Mar 1, 2010 at 1:23 PM, mlq <mar...@lm...> wrote: >> >> Hi Ash, >> >> I got everything built, thanks! I am struggling getting the verdex image >> to >> boot. I tried using the MLO and u-boot that I use with the overo; tried >> to >> rebuild them for the verdex (build failed); and I tried using the old >> gumstix-factory.script - nothing seems to work. Should the formatting be >> exactly the same as the overo? >> >> Could someone explain the steps I need to take to load the verdex image >> and >> kernel on the microSD card and boot it? >> >> Thanks, >> mlq >> >> >> Ash Charles-2 wrote: >>> >>> Hey mlq, >>> >>> A 'bitbake virtual/kernel' should build the 2.6.31 kernel for verdex. >>> Otherwise, the repository uses a 'task-base-gumstix' recipe to do most >>> of the work for various other recipes in keeping with the old svn >>> style. Note this does not match the current OE style of just adding >>> machine-specific stuff conditionally to the task-base recipe---I tried >>> and couldn't get this to work properly so if anyone has a fix for this >>> I'd love to see it :). >>> The git repository currently provides four Verdex images (thanks >>> Joseph): >>> - verdex-console-image >>> - verdex-palmtop-image >>> - verdex-desktop-image >>> - verdex-gnome-image >>> I had some problems building the last two because of the problems >>> reported on the branch with news & gnumeric etc. but I'm confident >>> these will go away as bugs get fixed upstream. I'd try the >>> verdex-console-image for a start. >>> >>> For loading the code, essentially follow the instructions for Overo >>> for booting from a microSD card. >>> >>> HTH, >>> >>> Ash >>> >>> P.S. If you do get those errors related to task-base, please post them >>> so I can look through them. >>> >>> >>> >>> On Sat, Feb 27, 2010 at 11:10 AM, mlq <mar...@lm...> wrote: >>>> >>>> I am also trying to build the verdex image and have sucessfully built >>>> the >>>> minimal-image and kernel; however when I build the console image i.e. >>>> bitbake console-image it dies on building the task-base. Basically it >>>> is >>>> looking in the task base folder but is missing the extensions for the >>>> particular tasks (task-base-x, missing x; sorry I dont have the output >>>> in >>>> front of me). I have 2 questions; >>>> >>>> What is the correct recipe to bitbake for the verdex? (i cant seem to >>>> find >>>> any verdex-specific recipes in the repo) >>>> >>>> What procedure should we follow to flash the mmc? (I was able to boot >>>> using >>>> the FAT16 partition and gumstix-factory.script from the old svn repo >>>> but >>>> I >>>> am not sure if we should be using a similar setup to the overo with >>>> xload?) >>>> >>>> Another related question which is not critical is when I add recipes to >>>> user.collection/recipes bitbake does not see them - is there typical >>>> reason >>>> for this? >>>> >>>> Thanks, >>>> mlq >>>> >>>> >>>> Connie C wrote: >>>>> >>>>> Hi Joseph, >>>>> >>>>> Thanks for the help. I'm definitely using the bash profile. Followed >>>>> all >>>>> those steps. I also followed the second sequence of code to make the >>>>> verdex-oe directory and I have the bitbake,build, and >>>>> org.openembedded.dev >>>>> directories inside. I think everything looks okay up to there with >>>>> what >>>>> you posted. >>>>> >>>>> After removing my user.collection and com.gumstix.collection from the >>>>> verdex-oe directory, I removed the extraneous tmp directory and ran >>>>> bitbake verdex-console-image and got: >>>>> ERROR: Nothing PROVIDES 'verdex-console-image' (but '[]' DEPENDS on or >>>>> otherwise requires it) >>>>> >>>>> I had gotten this originally after I changed >>echo 0 > >>>>> /proc/sys/vm/mmap_min_addr >>>>> and was trying to access the .bb file directly as a result. >>>>> >>>>> Something with how my bitbake is set up? >>>>> >>>>> Thanks, >>>>> >>>>> Connie >>>>> >>>>> >>>>> >>>>> >>>>> bionicjoe wrote: >>>>>> >>>>>> Hi, I corrected one critical line below ... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ________________________________ >>>>>> From: Joseph Kortje <jp...@ro...> >>>>>> To: General mailing list for gumstix users. >>>>>> <gum...@li...> >>>>>> Sent: Fri, February 26, 2010 9:12:35 PM >>>>>> Subject: Re: [Gumstix-users] Bitbaking New Kernel 2.6.31 for Verdex >>>>>> >>>>>> >>>>>> Hi Connie >>>>>> >>>>>> Most of what Ash checked in for verdex-oe came originally from myself >>>>>> and >>>>>> a few others >>>>>> so I can help you. >>>>>> >>>>>> It builds clean for me. >>>>>> >>>>>> So, lets' review .... >>>>>> >>>>>> What OS distribution are you building with? >>>>>> If it's Ubuntu, please confirm that you did the instruction to not >>>>>> reconfigure bash as dash. >>>>>> >>>>>> >>>>>>>>First I installed all the files in the new directory >>>>>>>>verdex-oe. >>>>>> >>>>>> These should be the steps to follow: >>>>>> >>>>>> $ mkdir -p ~/verdex-oe >>>>>> $ cd ~/verdex-oe >>>>>> $ git clone git://gitorious.org/gumstix-oe/mainline.git >>>>>> org.openembedded.dev >>>>>> $ cd org.openembedded.dev >>>>>> $ git checkout --track -b verdex origin/verdex >>>>>> $ cd ~/verdex-oe >>>>>> $ git clone git://git.openembedded.net/bitbake bitbake >>>>>> $ cd bitbake >>>>>> $ git checkout 1.8.18 >>>>>> $ cd ~/verdex-oe >>>>>> $ cp -r org.openembedded.dev/contrib/gumstix/build . >>>>>> >>>>>>>>sudo -i >>>>>>>>echo 0 > /proc/sys/vm/mmap_min_addr >>>>>> >>>>>> Yes, that should work. >>>>>> >>>>>> Alternatively, you could edit /etc/sysctl.conf (For example sudo >>>>>> gedit >>>>>> /etc.sysctl.conf&) >>>>>> and add the line >>>>>> >>>>>> vm.mmap_min_addr = 0 >>>>>> >>>>>> (Save and then reboot). >>>>>> >>>>>>>> First the bitbake complained that it could not find user >>>>>>>>collection in verdex-oe, so I copied user.collection and >>>>>>>>com.gumstix.collection over into the directory. >>>>>> >>>>>> There is no requirement to copy over user.collection from th older >>>>>> gumstix-oe build environment path. >>>>>> The purpose of user.collection is to override the search path for >>>>>> bitbake >>>>>> recipes. If any bitbake recipes >>>>>> in the user.collection path have the same base name as the ones used >>>>>> in >>>>>> org.openembedded.dev then they would be used >>>>>> in place of the official ones. Unless the developer has a specific >>>>>> reason for adding an override or customization >>>>>> or new bitbake recipe, and understands what he/she is doing with it >>>>>> (and >>>>>> the consequences) >>>>>> I suggest not putting anything in user.collection folder (or don't >>>>>> use >>>>>> the folder at all). >>>>>> >>>>>> Any old user.collection recipes that were used in the old gumstix-oe >>>>>> SVN >>>>>> based projects will not necessarily be compatible >>>>>> with the newer verdex-oe stuff since we are using a newer Angstrom >>>>>> distribution, newer Kernel, newer bitbake, >>>>>> etc. Developers that have such recipes would need to revisit them to >>>>>> port them to the new code base. >>>>>> >>>>>> The warning about not finding user.collection can therefore simply be >>>>>> ignored since you are (presumably) >>>>>> not going to be wanting to override any of the standard bitbake >>>>>> recipes >>>>>> or add any of your own >>>>>> customized ones yet. >>>>>> >>>>>> The old "com.gumstix.collection" and any files in that folder should >>>>>> not >>>>>> be added to this path and >>>>>> is not supported anymore in the Git based OE architecture. Any of >>>>>> the >>>>>> relevant patches or recipes (previously called packages) >>>>>> from the previous com.gumstix.collection are now already integrated >>>>>> into >>>>>> the git based verdex branch org.openembedded.dev recipes. >>>>>> >>>>>> (There are some exceptions such as support for audio, and robostix >>>>>> which >>>>>> are currently not ported to the new verdex-oe branch. Still working >>>>>> on it ....). >>>>>> >>>>>> Here is how to fix your build environment: >>>>>> >>>>>> First, you need to clean out the incorrect files that were added to >>>>>> the >>>>>> build path .... >>>>>> >>>>>> cd ~/verdex-oe >>>>>> sudo rm -rf com.gumstix.collection >>>>>> sudo rm -rf user.collection >>>>>> >>>>>> In this case, since the build cache is probably messed up, we need to >>>>>> start with a clean build >>>>>> >>>>>> sudo rm -rf tmp >>>>>> bitbake verdex-console-image >>>>>> >>>>>> >>>>>> Note: Please don't add ".bb" to the end of the bitbake recipe names >>>>>> in >>>>>> the bitbake command. >>>>>> Also, you can omit the -b option. >>>>>> >>>>>> >>>>>> BTW, please make sure that you have plenty of space in your /home >>>>>> partition. >>>>>> I use a 300GB partition albeit building for several projects for >>>>>> OpenEmbedded and I still find that >>>>>> my space gets eaten up really fast ... >>>>>> >>>>>> I recommend at least 40-60GB is needed to build verdex-oe (both >>>>>> verdex-console-image and verdex-palmtop-image). >>>>>> >>>>>> >>>>>> Let me know your results ... >>>>>> >>>>>> >>>>>> Regards >>>>>> Joseph >>>>>> >>>>>> >>>>>> PS: Tip for building faster on dual or quad core cpu .... >>>>>> >>>>>> In >>>>>> ~/verdex-oe/build/conf/site.conf >>>>>> >>>>>> # Uncomment these lines to enable parallel make. >>>>>> # This allows make to spawn mutliple processes to take advantage of >>>>>> multiple >>>>>> # processors. Useful on SMP machines >>>>>> PARALLEL_MAKE = "-j 4" >>>>>> BB_NUMBER_THREADS = "4" >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> View this message in context: >>>> http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27730217.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27749237.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27762956.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Ash C. <as...@gu...> - 2010-03-03 00:29:53
|
Hi mlq, Good catch...I've changed it to address a2000000 (feel free to correct my idiocy directly in the future ;-) ). There is no reason it shouldn't work on an old XM4--I believe the processor is the same between these boards. Perhaps you can try the kernel found here (http://dl.dropbox.com/u/211887/uimage) to see if that works for you? -Ash P.S. Sorry if this is a double-posting. On Tue, Mar 2, 2010 at 4:09 PM, mlq <mar...@lm...> wrote: > > Sigh... > > I followed your instructions exactly and the boot sequnce freezes after > uncompressing linux ........ It does load to correct kernel though. > > I think the step in the wiki "fatload mmc 0 a20000000 uimage" should be > "fatload mmc 0 a2000000 uimage" (one less 0). > > Anyhow I have no idea why it is locking up, could it be because I have an > old XM4 on not a verdex-pro? I was really hoping that it would work on the > XM4. > > mlq > > > Ash Charles-2 wrote: >> >> Hi mlq, >> >> I have put together a documentation page on the user wiki: >> http://www.gumstix.net/wiki/index.php?title=Verdex_Git_Repository >> >> Note: MLO is an OMAP3 specific bootstrap loader. It is not necessary >> for Verdex. >> >> Let me know if you have have any problems. >> >> -Ash >> >> On Mon, Mar 1, 2010 at 1:23 PM, mlq <mar...@lm...> wrote: >>> >>> Hi Ash, >>> >>> I got everything built, thanks! I am struggling getting the verdex image >>> to >>> boot. I tried using the MLO and u-boot that I use with the overo; tried >>> to >>> rebuild them for the verdex (build failed); and I tried using the old >>> gumstix-factory.script - nothing seems to work. Should the formatting be >>> exactly the same as the overo? >>> >>> Could someone explain the steps I need to take to load the verdex image >>> and >>> kernel on the microSD card and boot it? >>> >>> Thanks, >>> mlq >>> >>> >>> Ash Charles-2 wrote: >>>> >>>> Hey mlq, >>>> >>>> A 'bitbake virtual/kernel' should build the 2.6.31 kernel for verdex. >>>> Otherwise, the repository uses a 'task-base-gumstix' recipe to do most >>>> of the work for various other recipes in keeping with the old svn >>>> style. Note this does not match the current OE style of just adding >>>> machine-specific stuff conditionally to the task-base recipe---I tried >>>> and couldn't get this to work properly so if anyone has a fix for this >>>> I'd love to see it :). >>>> The git repository currently provides four Verdex images (thanks >>>> Joseph): >>>> - verdex-console-image >>>> - verdex-palmtop-image >>>> - verdex-desktop-image >>>> - verdex-gnome-image >>>> I had some problems building the last two because of the problems >>>> reported on the branch with news & gnumeric etc. but I'm confident >>>> these will go away as bugs get fixed upstream. I'd try the >>>> verdex-console-image for a start. >>>> >>>> For loading the code, essentially follow the instructions for Overo >>>> for booting from a microSD card. >>>> >>>> HTH, >>>> >>>> Ash >>>> >>>> P.S. If you do get those errors related to task-base, please post them >>>> so I can look through them. >>>> >>>> >>>> >>>> On Sat, Feb 27, 2010 at 11:10 AM, mlq <mar...@lm...> wrote: >>>>> >>>>> I am also trying to build the verdex image and have sucessfully built >>>>> the >>>>> minimal-image and kernel; however when I build the console image i.e. >>>>> bitbake console-image it dies on building the task-base. Basically it >>>>> is >>>>> looking in the task base folder but is missing the extensions for the >>>>> particular tasks (task-base-x, missing x; sorry I dont have the output >>>>> in >>>>> front of me). I have 2 questions; >>>>> >>>>> What is the correct recipe to bitbake for the verdex? (i cant seem to >>>>> find >>>>> any verdex-specific recipes in the repo) >>>>> >>>>> What procedure should we follow to flash the mmc? (I was able to boot >>>>> using >>>>> the FAT16 partition and gumstix-factory.script from the old svn repo >>>>> but >>>>> I >>>>> am not sure if we should be using a similar setup to the overo with >>>>> xload?) >>>>> >>>>> Another related question which is not critical is when I add recipes to >>>>> user.collection/recipes bitbake does not see them - is there typical >>>>> reason >>>>> for this? >>>>> >>>>> Thanks, >>>>> mlq >>>>> >>>>> >>>>> Connie C wrote: >>>>>> >>>>>> Hi Joseph, >>>>>> >>>>>> Thanks for the help. I'm definitely using the bash profile. Followed >>>>>> all >>>>>> those steps. I also followed the second sequence of code to make the >>>>>> verdex-oe directory and I have the bitbake,build, and >>>>>> org.openembedded.dev >>>>>> directories inside. I think everything looks okay up to there with >>>>>> what >>>>>> you posted. >>>>>> >>>>>> After removing my user.collection and com.gumstix.collection from the >>>>>> verdex-oe directory, I removed the extraneous tmp directory and ran >>>>>> bitbake verdex-console-image and got: >>>>>> ERROR: Nothing PROVIDES 'verdex-console-image' (but '[]' DEPENDS on or >>>>>> otherwise requires it) >>>>>> >>>>>> I had gotten this originally after I changed >>echo 0 > >>>>>> /proc/sys/vm/mmap_min_addr >>>>>> and was trying to access the .bb file directly as a result. >>>>>> >>>>>> Something with how my bitbake is set up? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Connie >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> bionicjoe wrote: >>>>>>> >>>>>>> Hi, I corrected one critical line below ... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________ >>>>>>> From: Joseph Kortje <jp...@ro...> >>>>>>> To: General mailing list for gumstix users. >>>>>>> <gum...@li...> >>>>>>> Sent: Fri, February 26, 2010 9:12:35 PM >>>>>>> Subject: Re: [Gumstix-users] Bitbaking New Kernel 2.6.31 for Verdex >>>>>>> >>>>>>> >>>>>>> Hi Connie >>>>>>> >>>>>>> Most of what Ash checked in for verdex-oe came originally from myself >>>>>>> and >>>>>>> a few others >>>>>>> so I can help you. >>>>>>> >>>>>>> It builds clean for me. >>>>>>> >>>>>>> So, lets' review .... >>>>>>> >>>>>>> What OS distribution are you building with? >>>>>>> If it's Ubuntu, please confirm that you did the instruction to not >>>>>>> reconfigure bash as dash. >>>>>>> >>>>>>> >>>>>>>>>First I installed all the files in the new directory >>>>>>>>>verdex-oe. >>>>>>> >>>>>>> These should be the steps to follow: >>>>>>> >>>>>>> $ mkdir -p ~/verdex-oe >>>>>>> $ cd ~/verdex-oe >>>>>>> $ git clone git://gitorious.org/gumstix-oe/mainline.git >>>>>>> org.openembedded.dev >>>>>>> $ cd org.openembedded.dev >>>>>>> $ git checkout --track -b verdex origin/verdex >>>>>>> $ cd ~/verdex-oe >>>>>>> $ git clone git://git.openembedded.net/bitbake bitbake >>>>>>> $ cd bitbake >>>>>>> $ git checkout 1.8.18 >>>>>>> $ cd ~/verdex-oe >>>>>>> $ cp -r org.openembedded.dev/contrib/gumstix/build . >>>>>>> >>>>>>>>>sudo -i >>>>>>>>>echo 0 > /proc/sys/vm/mmap_min_addr >>>>>>> >>>>>>> Yes, that should work. >>>>>>> >>>>>>> Alternatively, you could edit /etc/sysctl.conf (For example sudo >>>>>>> gedit >>>>>>> /etc.sysctl.conf&) >>>>>>> and add the line >>>>>>> >>>>>>> vm.mmap_min_addr = 0 >>>>>>> >>>>>>> (Save and then reboot). >>>>>>> >>>>>>>>> First the bitbake complained that it could not find user >>>>>>>>>collection in verdex-oe, so I copied user.collection and >>>>>>>>>com.gumstix.collection over into the directory. >>>>>>> >>>>>>> There is no requirement to copy over user.collection from th older >>>>>>> gumstix-oe build environment path. >>>>>>> The purpose of user.collection is to override the search path for >>>>>>> bitbake >>>>>>> recipes. If any bitbake recipes >>>>>>> in the user.collection path have the same base name as the ones used >>>>>>> in >>>>>>> org.openembedded.dev then they would be used >>>>>>> in place of the official ones. Unless the developer has a specific >>>>>>> reason for adding an override or customization >>>>>>> or new bitbake recipe, and understands what he/she is doing with it >>>>>>> (and >>>>>>> the consequences) >>>>>>> I suggest not putting anything in user.collection folder (or don't >>>>>>> use >>>>>>> the folder at all). >>>>>>> >>>>>>> Any old user.collection recipes that were used in the old gumstix-oe >>>>>>> SVN >>>>>>> based projects will not necessarily be compatible >>>>>>> with the newer verdex-oe stuff since we are using a newer Angstrom >>>>>>> distribution, newer Kernel, newer bitbake, >>>>>>> etc. Developers that have such recipes would need to revisit them to >>>>>>> port them to the new code base. >>>>>>> >>>>>>> The warning about not finding user.collection can therefore simply be >>>>>>> ignored since you are (presumably) >>>>>>> not going to be wanting to override any of the standard bitbake >>>>>>> recipes >>>>>>> or add any of your own >>>>>>> customized ones yet. >>>>>>> >>>>>>> The old "com.gumstix.collection" and any files in that folder should >>>>>>> not >>>>>>> be added to this path and >>>>>>> is not supported anymore in the Git based OE architecture. Any of >>>>>>> the >>>>>>> relevant patches or recipes (previously called packages) >>>>>>> from the previous com.gumstix.collection are now already integrated >>>>>>> into >>>>>>> the git based verdex branch org.openembedded.dev recipes. >>>>>>> >>>>>>> (There are some exceptions such as support for audio, and robostix >>>>>>> which >>>>>>> are currently not ported to the new verdex-oe branch. Still working >>>>>>> on it ....). >>>>>>> >>>>>>> Here is how to fix your build environment: >>>>>>> >>>>>>> First, you need to clean out the incorrect files that were added to >>>>>>> the >>>>>>> build path .... >>>>>>> >>>>>>> cd ~/verdex-oe >>>>>>> sudo rm -rf com.gumstix.collection >>>>>>> sudo rm -rf user.collection >>>>>>> >>>>>>> In this case, since the build cache is probably messed up, we need to >>>>>>> start with a clean build >>>>>>> >>>>>>> sudo rm -rf tmp >>>>>>> bitbake verdex-console-image >>>>>>> >>>>>>> >>>>>>> Note: Please don't add ".bb" to the end of the bitbake recipe names >>>>>>> in >>>>>>> the bitbake command. >>>>>>> Also, you can omit the -b option. >>>>>>> >>>>>>> >>>>>>> BTW, please make sure that you have plenty of space in your /home >>>>>>> partition. >>>>>>> I use a 300GB partition albeit building for several projects for >>>>>>> OpenEmbedded and I still find that >>>>>>> my space gets eaten up really fast ... >>>>>>> >>>>>>> I recommend at least 40-60GB is needed to build verdex-oe (both >>>>>>> verdex-console-image and verdex-palmtop-image). >>>>>>> >>>>>>> >>>>>>> Let me know your results ... >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> Joseph >>>>>>> >>>>>>> >>>>>>> PS: Tip for building faster on dual or quad core cpu .... >>>>>>> >>>>>>> In >>>>>>> ~/verdex-oe/build/conf/site.conf >>>>>>> >>>>>>> # Uncomment these lines to enable parallel make. >>>>>>> # This allows make to spawn mutliple processes to take advantage of >>>>>>> multiple >>>>>>> # processors. Useful on SMP machines >>>>>>> PARALLEL_MAKE = "-j 4" >>>>>>> BB_NUMBER_THREADS = "4" >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27730217.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27749237.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27762956.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: Connie C <cci...@um...> - 2010-03-03 15:58:18
|
Hi Ash, Thanks for the help. I tried the command $sudo tar -xzf /home/oeuser/verdex-oe/tmp/deploy/glibc/images/gumstix-verdex/Angstrom-verdex-console-image-glibc-ipk-2009.X-test-20100227-gumstix-verdex.rootfs.tar.gz -C /media/card and got the bunch of errors I seem to keep getting. A sample of what they all look like: tar: ./boot: Cannot mkdir: Input/output error tar: ./boot/uImage: Cannot create symlink to `uImage-2.6.31': No such file or directory tar: ./lib: Cannot mkdir: Input/output error tar: ./lib/ld-linux.so.3: Cannot create symlink to `ld-2.9.so': No such file or directory tar: ./lib/libproc-3.2.7.so: Cannot open: No such file or directory tar: ./lib/libc-2.9.so: Cannot open: No such file or directory tar: ./lib/libanl.so.1: Cannot create symlink to `libanl-2.9.so': No such file or directory tar: ./lib/librt-2.9.so: Cannot open: No such file or directory tar: ./lib/libnss_files-2.9.so: Cannot open: No such file or directory tar: ./lib/librt.so.1: Cannot create symlink to `librt-2.9.so': No such file or directory same with ./sbin, ./lib, ./etc, ./tmp, and ./mnt after the tar, I have oeuser@SG1:/media/card$ ls bin boot dev home linuxrc lost+found media proc sys usr var with linuxrc a broken link. Thanks, Connie Ash Charles-2 wrote: > > Hi Connie, > > Do you have superuser access when extracting the root file system? > Say Ext2|Ext3 partition is at /media/card_ext and your root filesystem > named 'verdex-console-image-verdex.tar.gz' is in the current > directory. > Does this command fail? > $ sudo tar -xzf verdex-console-image-verdex.tar.gz -C /media/card_ext/ > > The reason the documentation notes the step to be dangerous is because > you are extracting a root filesystem. If you neglect the -C option or > accidentally extract to '/', you could overwrite important sections of > your own machine! > > -Ash > > On Tue, Mar 2, 2010 at 2:41 PM, Connie C <cci...@um...> wrote: >> >> Hi all, (again) >> >> So very happy about successfully bitbaking the 2.6.31 kernel. However, I >> seem to having issues extracting the rootfs from the tarball. I >> partitioned >> my 2Gb microsd card yesterday according to >> http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html >> >> Except with a FAT16 partition and .ext2 partition >> and I put gumstix-factory.script and uImage in the FAT partition and >> tried >> to unpack the .tar.gz in the .ext2 partition. Trying to upack to tarball >> fails. I've also tried to extract single files/folders from the tarball >> into other locations on my desktop and card. Some of the folders work >> succesfully and can be extracted. However, some, like mnt, will not >> extract. (this is to both the sd card and to a random folder on my >> desktop)(I did also read : The final step is to untar your desired rootfs >> onto the ext3 partition that you created above. >> Note that this step can be dangerous. You do not want to untar your Overo >> rootfs onto your development machine - be careful! and so am only doing >> individual files and then deleting them) >> >> I used fdsk for the partitioning. I thought it might be how I >> partitioned >> the card at first and ran dmsg and got a few types of errors: >> [687450.710992] attempt to access beyond end of device >> [687450.710996] sdc: rw=0, want=4012501, limit=3842048 >> [687451.119556] EXT2-fs error (device sdc2): read_inode_bitmap: Cannot >> read >> inode bitmap - block_group = 15, inode_bitmap = 491521 >> >> [686293.686071] sdc: rw=1, want=3848813, limit=3842048 >> [686293.686074] attempt to access beyond end of device >> >> [686312.717664] EXT2-fs error (device sdc2): ext2_readdir: bad page in >> #109313 >> >> I have gone back through the partitioning instructions several times and >> I >> think my card has been done successfully. (I can upload the transcript >> for >> the session) especially since I cant remove some of the files from the >> tarball at all. >> >> Thanks! >> >> Connie C. >> >> >> -- >> View this message in context: >> http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27762177.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27769993.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: mlq <mar...@lm...> - 2010-03-03 18:04:02
|
Ok so I finally got it to boot; looks like the setenv has to be called before fatload. However the boot locks up; below is the output. Here is the fdisk output on how my sd card is formated. Note that the FAT partition only has the uimage on it and the ext3 has the un-tarred rootfs. Disk /dev/sdb: 1973 MB, 1973420032 bytes 255 heads, 63 sectors/track, 239 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdb1 * 1 5 40131 c W95 FAT32 (LBA) /dev/sdb2 6 239 1879605 83 Linux U-Boot 1.2.0 (Dec 21 2007 - 13:34:50) - PXA270@400 MHz - 1578M *** Welcome to Gumstix *** DRAM: 64 MB Flash: 16 MB Using default environment Hit any key to stop autoboot: 0 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> setenv bootargs console=ttyS0,115200n8 rootdelay=1 root=/dev/mmcblk0p2 GUM> fatload mmc 0 a2000000 uimage reading uimage 1291348 bytes read GUM> bootm a2000000 ## Booting image at a2000000 ... Image Name: Angstrom/2.6.31/gumstix-verdex Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1291284 Bytes = 1.2 MB Load Address: a0008000 Entry Point: a0008000 OK Starting kernel ... Uncompressing Linux.................................................................................. done, booting the kernel. Linux version 2.6.31 (gcc version 4.3.3 (GCC) ) #1 Fri Feb 26 15:45:41 PST 2010 CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE), cr=0000397f CPU: VIVT data cache, VIVT instruction cache Machine: Gumstix verdex Memory policy: ECC disabled, Data cache writeback Run Mode clock: 208.00MHz (*16) Turbo Mode clock: 416.00MHz (*2.0, active) Memory clock: 104.00MHz (/2) System bus clock: 104.00MHz Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: console=ttyS0,115200n8 rootdelay=1 root=/dev/mmcblk0p2 PID hash table entries: 256 (order: 8, 1024 bytes) Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 64MB = 64MB total Memory: 62248KB available (2212K code, 252K data, 88K init, 0K highmem) NR_IRQS:192 Console: colour dummy device 80x30 Calibrating delay loop... 415.33 BogoMIPS (lpj=2076672) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 Gumstix verdex udc is disabled Initializing Gumstix verdex i2c Initializing Gumstix verdex smsc911x Initializing Gumstix verdex pcmcia Not netCF-vx board: pcmcia using newer GPIO configuration CPLD responded with: ff found 1 CF slots Initializing Gumstix verdex FB info Initializing Gumstix platform_add_devices bio: create slab <bio-0> at 0 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered NET: Registered protocol family 1 msgmni has been set to 121 alg: No test for stdrng (krng) Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered io scheduler cfq registered (default) Console: switching to colour frame buffer device 80x24 pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 22) is a FFUART console [ttyS0] enabled pxa2xx-uart.1: ttyS1 at MMIO 0x40200000 (irq = 21) is a BTUART pxa2xx-uart.2: ttyS2 at MMIO 0x40700000 (irq = 20) is a STUART Probing Gumstix Flash ROM at physical address 0x00000000 (16-bit bankwidth) Gumstix Flash ROM: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Using buffer write method Using auto-unlock on power-up/resume cfi_cmdset_0001: Erase suspend on write enabled Using static partitions on Gumstix Flash ROM Creating 3 MTD partitions on "Gumstix Flash ROM": 0x000000000000-0x000000040000 : "Bootloader" 0x000000040000-0x000000f00000 : "RootFS" 0x000000f00000-0x000001000000 : "Kernel" pxa-rtc pxa-rtc: rtc core: registered pxa-rtc as rtc0 TCP cubic registered NET: Registered protocol family 17 XScale iWMMXt coprocessor detected. pxa-rtc pxa-rtc: setting system clock to 2000-01-01 00:00:40 UTC (946684840) Waiting 1sec before mounting root device... mmc0: host does not support reading read-only switch. assuming write-enable. mmc0: new SD card at address 1234 mmcblk0: mmc0:1234 SA02G 1.83 GiB mmcblk0: p1 p2 kjournald starting. Commit interval 5 seconds EXT3 FS on mmcblk0p2, internal journal EXT3-fs: mounted filesystem with writeback data mode. VFS: Mounted root (ext3 filesystem) on device 179:2. Freeing init memory: 88K INIT: version 2.86 booting Please wait: booting... Starting udev I2C: i2c-0: PXA I2C adapter I2C: i2c-1: PXA I2C adapter tsc2003_probe tsc2003 i2c touch screen controller Bill Gatliff <bgat at billgatliff.com Nicholas Chen <nchen at cs.umd.edu> tsc2003_probe: checking i2c tsc2003_probe: calling kzalloc tsc2003_probe: probing address 0x48 i2c: error: exhausted retries i2c: msg_num: 0 msg_idx: -2000 msg_ptr: 0 i2c: ICR: 000087e0 ISR: 00000002 tsc2003: probe of 0-0048 failed with error -121 usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver pxa27x-ohci pxa27x-ohci: PXA27x OHCI pxa27x-ohci pxa27x-ohci: new USB bus registered, assigned bus number 1 pxa27x-ohci pxa27x-ohci: irq 3, io mem 0x4c000000 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected FAT: codepage cp437 not found Remounting root file system... Caching udev devnodes Populating dev cache logger: mount: mount point /dev/pts does not exist logger: mount: mount point /dev/shm does not exist Undefined users: > pulse Skipping /etc/default/volatiles/04_pulse Undefined users: > haldaemon Skipping /etc/default/volatiles/99_hal Starting Marvell Wifi CF8385... Configuring network interfaces... eth0: unknown interface: No such device eth0: unknown interface: No such device eth0 No such device eth0: unknown interface: No such device done. Starting portmap daemon: portmapportmap: fork: No such device. Unknown HZ value! (68) Assume 100. net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.all.rp_filter = 1 hwclock: can't open '/dev/misc/rtc': No such file or directory Mon Mar 1 11:18:00 UTC 2010 hwclock: can't open '/dev/misc/rtc': No such file or directory Checking for built-in Bluetooth: /etc/rcS.d/S97blueprobe: line 158: can't open /dev/ttyS1: no such file yes Configuring ppp-dialin Configuring pulseaudio-server addgroup: pulse: group already in use Undefined users: > haldaemon Skipping /etc/default/volatiles/99_hal postinst script returned status 1 Configuring policykit chmod: cannot access `/var/run/PolicyKit': No such file or directory Configuring dbus System startup links for /etc/init.d/dbus-1 already exist. Configuring hicolor-icon-theme //usr/lib/opkg/info/hicolor-icon-theme.postinst: line 7: can't create /etc/gtk-2.0/gdk-pixbuf.loaders: nonexistent directory //usr/lib/opkg/info/hicolor-icon-theme.postinst: line 7: gdk-pixbuf-query-loaders: not found //usr/lib/opkg/info/hicolor-icon-theme.postinst: line 13: gtk-update-icon-cache: not found postinst script returned status 127 Configuring sudo Configuring angstrom-zeroconf-audio Configuring ppp Configuring hal Configuring avahi-autoipd Configuring angstrom-libc-fixup-hack Configuring avahi-daemon System startup links for /etc/init.d/avahi-daemon already exist. Configuring ntpdate adding crontab Configuring update-modules Configuring libnss-mdns Bluetooth: Core ver 2.15 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP ver 2.13 Bluetooth: L2CAP socket layer initialized Bluetooth: HIDP (Human Interface Emulation) ver 1.2 Registering gumstix PCMCIA interface. Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM ver 1.11 smsc911x: Driver version 2008-10-21. eth%d: smsc911x_init: Driver Parameters: eth%d: smsc911x_init: LAN base: 0xC4A00000 eth%d: smsc911x_init: IRQ: 163 eth%d: smsc911x_init: PHY will be autodetected. eth%d: smsc911x_init: BYTE_TEST: 0x87654321 eth%d: smsc911x_init: LAN911x identified, idrev: 0x01170002, generation: 2 eth0: smsc911x_drv_probe: Network interface: "eth0" eth0: smsc911x_phy_initialise_external: HW_CFG EXT_PHY_DET clear, using internal PHY smsc911x-mdio: probed eth0: smsc911x_mii_probe: PHY 1: addr 1, phy_id 0x0007C0D1 eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=ffffffff:01, irq=-1) eth0: smsc911x_phy_check_loopbackpkt: Successfully verified loopback packet eth0: smsc911x_mii_probe: Passed Loop Back Test eth0: smsc911x_mii_probe: phy initialised succesfully eth0: smsc911x_drv_probe: MAC Address is derived from system serial number net eth0: MAC Address: ae:f7:51:56:49:d0 Collected errors: * ERROR: pulseaudio-server.postinst returned 1 * ERROR: hicolor-icon-theme.postinst returned 127 i2c /dev entries driver Ash Charles-2 wrote: > > Hi mlq, > > Good catch...I've changed it to address a2000000 (feel free to correct > my idiocy directly in the future ;-) ). > > There is no reason it shouldn't work on an old XM4--I believe the > processor is the same between these boards. > > Perhaps you can try the kernel found here > (http://dl.dropbox.com/u/211887/uimage) to see if that works for you? > > -Ash > P.S. Sorry if this is a double-posting. > On Tue, Mar 2, 2010 at 4:09 PM, mlq <mar...@lm...> wrote: >> >> Sigh... >> >> I followed your instructions exactly and the boot sequnce freezes after >> uncompressing linux ........ It does load to correct kernel though. >> >> I think the step in the wiki "fatload mmc 0 a20000000 uimage" should be >> "fatload mmc 0 a2000000 uimage" (one less 0). >> >> Anyhow I have no idea why it is locking up, could it be because I have an >> old XM4 on not a verdex-pro? I was really hoping that it would work on >> the >> XM4. >> >> mlq >> >> >> Ash Charles-2 wrote: >>> >>> Hi mlq, >>> >>> I have put together a documentation page on the user wiki: >>> http://www.gumstix.net/wiki/index.php?title=Verdex_Git_Repository >>> >>> Note: MLO is an OMAP3 specific bootstrap loader. It is not necessary >>> for Verdex. >>> >>> Let me know if you have have any problems. >>> >>> -Ash >>> >>> On Mon, Mar 1, 2010 at 1:23 PM, mlq <mar...@lm...> wrote: >>>> >>>> Hi Ash, >>>> >>>> I got everything built, thanks! I am struggling getting the verdex >>>> image >>>> to >>>> boot. I tried using the MLO and u-boot that I use with the overo; >>>> tried >>>> to >>>> rebuild them for the verdex (build failed); and I tried using the old >>>> gumstix-factory.script - nothing seems to work. Should the formatting >>>> be >>>> exactly the same as the overo? >>>> >>>> Could someone explain the steps I need to take to load the verdex image >>>> and >>>> kernel on the microSD card and boot it? >>>> >>>> Thanks, >>>> mlq >>>> >>>> >>>> Ash Charles-2 wrote: >>>>> >>>>> Hey mlq, >>>>> >>>>> A 'bitbake virtual/kernel' should build the 2.6.31 kernel for verdex. >>>>> Otherwise, the repository uses a 'task-base-gumstix' recipe to do most >>>>> of the work for various other recipes in keeping with the old svn >>>>> style. Note this does not match the current OE style of just adding >>>>> machine-specific stuff conditionally to the task-base recipe---I tried >>>>> and couldn't get this to work properly so if anyone has a fix for this >>>>> I'd love to see it :). >>>>> The git repository currently provides four Verdex images (thanks >>>>> Joseph): >>>>> - verdex-console-image >>>>> - verdex-palmtop-image >>>>> - verdex-desktop-image >>>>> - verdex-gnome-image >>>>> I had some problems building the last two because of the problems >>>>> reported on the branch with news & gnumeric etc. but I'm confident >>>>> these will go away as bugs get fixed upstream. I'd try the >>>>> verdex-console-image for a start. >>>>> >>>>> For loading the code, essentially follow the instructions for Overo >>>>> for booting from a microSD card. >>>>> >>>>> HTH, >>>>> >>>>> Ash >>>>> >>>>> P.S. If you do get those errors related to task-base, please post them >>>>> so I can look through them. >>>>> >>>>> >>>>> >>>>> On Sat, Feb 27, 2010 at 11:10 AM, mlq <mar...@lm...> >>>>> wrote: >>>>>> >>>>>> I am also trying to build the verdex image and have sucessfully built >>>>>> the >>>>>> minimal-image and kernel; however when I build the console image i.e. >>>>>> bitbake console-image it dies on building the task-base. Basically >>>>>> it >>>>>> is >>>>>> looking in the task base folder but is missing the extensions for the >>>>>> particular tasks (task-base-x, missing x; sorry I dont have the >>>>>> output >>>>>> in >>>>>> front of me). I have 2 questions; >>>>>> >>>>>> What is the correct recipe to bitbake for the verdex? (i cant seem to >>>>>> find >>>>>> any verdex-specific recipes in the repo) >>>>>> >>>>>> What procedure should we follow to flash the mmc? (I was able to boot >>>>>> using >>>>>> the FAT16 partition and gumstix-factory.script from the old svn repo >>>>>> but >>>>>> I >>>>>> am not sure if we should be using a similar setup to the overo with >>>>>> xload?) >>>>>> >>>>>> Another related question which is not critical is when I add recipes >>>>>> to >>>>>> user.collection/recipes bitbake does not see them - is there typical >>>>>> reason >>>>>> for this? >>>>>> >>>>>> Thanks, >>>>>> mlq >>>>>> >>>>>> >>>>>> Connie C wrote: >>>>>>> >>>>>>> Hi Joseph, >>>>>>> >>>>>>> Thanks for the help. I'm definitely using the bash profile. >>>>>>> Followed >>>>>>> all >>>>>>> those steps. I also followed the second sequence of code to make >>>>>>> the >>>>>>> verdex-oe directory and I have the bitbake,build, and >>>>>>> org.openembedded.dev >>>>>>> directories inside. I think everything looks okay up to there with >>>>>>> what >>>>>>> you posted. >>>>>>> >>>>>>> After removing my user.collection and com.gumstix.collection from >>>>>>> the >>>>>>> verdex-oe directory, I removed the extraneous tmp directory and ran >>>>>>> bitbake verdex-console-image and got: >>>>>>> ERROR: Nothing PROVIDES 'verdex-console-image' (but '[]' DEPENDS on >>>>>>> or >>>>>>> otherwise requires it) >>>>>>> >>>>>>> I had gotten this originally after I changed >>echo 0 > >>>>>>> /proc/sys/vm/mmap_min_addr >>>>>>> and was trying to access the .bb file directly as a result. >>>>>>> >>>>>>> Something with how my bitbake is set up? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Connie >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> bionicjoe wrote: >>>>>>>> >>>>>>>> Hi, I corrected one critical line below ... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ________________________________ >>>>>>>> From: Joseph Kortje <jp...@ro...> >>>>>>>> To: General mailing list for gumstix users. >>>>>>>> <gum...@li...> >>>>>>>> Sent: Fri, February 26, 2010 9:12:35 PM >>>>>>>> Subject: Re: [Gumstix-users] Bitbaking New Kernel 2.6.31 for >>>>>>>> Verdex >>>>>>>> >>>>>>>> >>>>>>>> Hi Connie >>>>>>>> >>>>>>>> Most of what Ash checked in for verdex-oe came originally from >>>>>>>> myself >>>>>>>> and >>>>>>>> a few others >>>>>>>> so I can help you. >>>>>>>> >>>>>>>> It builds clean for me. >>>>>>>> >>>>>>>> So, lets' review .... >>>>>>>> >>>>>>>> What OS distribution are you building with? >>>>>>>> If it's Ubuntu, please confirm that you did the instruction to not >>>>>>>> reconfigure bash as dash. >>>>>>>> >>>>>>>> >>>>>>>>>>First I installed all the files in the new directory >>>>>>>>>>verdex-oe. >>>>>>>> >>>>>>>> These should be the steps to follow: >>>>>>>> >>>>>>>> $ mkdir -p ~/verdex-oe >>>>>>>> $ cd ~/verdex-oe >>>>>>>> $ git clone git://gitorious.org/gumstix-oe/mainline.git >>>>>>>> org.openembedded.dev >>>>>>>> $ cd org.openembedded.dev >>>>>>>> $ git checkout --track -b verdex origin/verdex >>>>>>>> $ cd ~/verdex-oe >>>>>>>> $ git clone git://git.openembedded.net/bitbake bitbake >>>>>>>> $ cd bitbake >>>>>>>> $ git checkout 1.8.18 >>>>>>>> $ cd ~/verdex-oe >>>>>>>> $ cp -r org.openembedded.dev/contrib/gumstix/build . >>>>>>>> >>>>>>>>>>sudo -i >>>>>>>>>>echo 0 > /proc/sys/vm/mmap_min_addr >>>>>>>> >>>>>>>> Yes, that should work. >>>>>>>> >>>>>>>> Alternatively, you could edit /etc/sysctl.conf (For example sudo >>>>>>>> gedit >>>>>>>> /etc.sysctl.conf&) >>>>>>>> and add the line >>>>>>>> >>>>>>>> vm.mmap_min_addr = 0 >>>>>>>> >>>>>>>> (Save and then reboot). >>>>>>>> >>>>>>>>>> First the bitbake complained that it could not find user >>>>>>>>>>collection in verdex-oe, so I copied user.collection and >>>>>>>>>>com.gumstix.collection over into the directory. >>>>>>>> >>>>>>>> There is no requirement to copy over user.collection from th older >>>>>>>> gumstix-oe build environment path. >>>>>>>> The purpose of user.collection is to override the search path for >>>>>>>> bitbake >>>>>>>> recipes. If any bitbake recipes >>>>>>>> in the user.collection path have the same base name as the ones >>>>>>>> used >>>>>>>> in >>>>>>>> org.openembedded.dev then they would be used >>>>>>>> in place of the official ones. Unless the developer has a specific >>>>>>>> reason for adding an override or customization >>>>>>>> or new bitbake recipe, and understands what he/she is doing with it >>>>>>>> (and >>>>>>>> the consequences) >>>>>>>> I suggest not putting anything in user.collection folder (or don't >>>>>>>> use >>>>>>>> the folder at all). >>>>>>>> >>>>>>>> Any old user.collection recipes that were used in the old >>>>>>>> gumstix-oe >>>>>>>> SVN >>>>>>>> based projects will not necessarily be compatible >>>>>>>> with the newer verdex-oe stuff since we are using a newer Angstrom >>>>>>>> distribution, newer Kernel, newer bitbake, >>>>>>>> etc. Developers that have such recipes would need to revisit them >>>>>>>> to >>>>>>>> port them to the new code base. >>>>>>>> >>>>>>>> The warning about not finding user.collection can therefore simply >>>>>>>> be >>>>>>>> ignored since you are (presumably) >>>>>>>> not going to be wanting to override any of the standard bitbake >>>>>>>> recipes >>>>>>>> or add any of your own >>>>>>>> customized ones yet. >>>>>>>> >>>>>>>> The old "com.gumstix.collection" and any files in that folder >>>>>>>> should >>>>>>>> not >>>>>>>> be added to this path and >>>>>>>> is not supported anymore in the Git based OE architecture. Any of >>>>>>>> the >>>>>>>> relevant patches or recipes (previously called packages) >>>>>>>> from the previous com.gumstix.collection are now already integrated >>>>>>>> into >>>>>>>> the git based verdex branch org.openembedded.dev recipes. >>>>>>>> >>>>>>>> (There are some exceptions such as support for audio, and robostix >>>>>>>> which >>>>>>>> are currently not ported to the new verdex-oe branch. Still >>>>>>>> working >>>>>>>> on it ....). >>>>>>>> >>>>>>>> Here is how to fix your build environment: >>>>>>>> >>>>>>>> First, you need to clean out the incorrect files that were added to >>>>>>>> the >>>>>>>> build path .... >>>>>>>> >>>>>>>> cd ~/verdex-oe >>>>>>>> sudo rm -rf com.gumstix.collection >>>>>>>> sudo rm -rf user.collection >>>>>>>> >>>>>>>> In this case, since the build cache is probably messed up, we need >>>>>>>> to >>>>>>>> start with a clean build >>>>>>>> >>>>>>>> sudo rm -rf tmp >>>>>>>> bitbake verdex-console-image >>>>>>>> >>>>>>>> >>>>>>>> Note: Please don't add ".bb" to the end of the bitbake recipe names >>>>>>>> in >>>>>>>> the bitbake command. >>>>>>>> Also, you can omit the -b option. >>>>>>>> >>>>>>>> >>>>>>>> BTW, please make sure that you have plenty of space in your /home >>>>>>>> partition. >>>>>>>> I use a 300GB partition albeit building for several projects for >>>>>>>> OpenEmbedded and I still find that >>>>>>>> my space gets eaten up really fast ... >>>>>>>> >>>>>>>> I recommend at least 40-60GB is needed to build verdex-oe (both >>>>>>>> verdex-console-image and verdex-palmtop-image). >>>>>>>> >>>>>>>> >>>>>>>> Let me know your results ... >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> Joseph >>>>>>>> >>>>>>>> >>>>>>>> PS: Tip for building faster on dual or quad core cpu .... >>>>>>>> >>>>>>>> In >>>>>>>> ~/verdex-oe/build/conf/site.conf >>>>>>>> >>>>>>>> # Uncomment these lines to enable parallel make. >>>>>>>> # This allows make to spawn mutliple processes to take advantage of >>>>>>>> multiple >>>>>>>> # processors. Useful on SMP machines >>>>>>>> PARALLEL_MAKE = "-j 4" >>>>>>>> BB_NUMBER_THREADS = "4" >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27730217.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27749237.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27762956.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27771565.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Ash C. <ash...@gm...> - 2010-03-03 18:46:59
|
Hi mlq, I don't see the same behaviour where setenv needs to be called before fatload. As these commands do completely different things, it would seem like a bug to me. Have you tried using the more recent 1604 version of uboot? The U-Boot files are available here: http://www.gumstix.net/feeds/u-boot/ The instructions for *carefully* reflashing U-Boot via serial connection are given here: http://www.gumstix.net/User-How-To-s/view/Developer-how-to-s/Reflashing-using-a-serial-connection/110.html I'll have to look through the messages you are seeing in detail. Some seem to be configuration/installation issues: does it work any better the second time you try to boot? Other ones seem to be problems with how I've set up udev. Thanks for your feedback, Ash On Wed, Mar 3, 2010 at 10:03 AM, mlq <mar...@lm...> wrote: > > Ok so I finally got it to boot; looks like the setenv has to be called before > fatload. However the boot locks up; below is the output. Here is the fdisk > output on how my sd card is formated. Note that the FAT partition only has > the uimage on it and the ext3 has the un-tarred rootfs. > > Disk /dev/sdb: 1973 MB, 1973420032 bytes > 255 heads, 63 sectors/track, 239 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > Disk identifier: 0x00000000 > > Device Boot Start End Blocks Id System > /dev/sdb1 * 1 5 40131 c W95 FAT32 (LBA) > /dev/sdb2 6 239 1879605 83 Linux > > U-Boot 1.2.0 (Dec 21 2007 - 13:34:50) - PXA270@400 MHz - 1578M > > *** Welcome to Gumstix *** > > DRAM: 64 MB > Flash: 16 MB > Using default environment > > Hit any key to stop autoboot: 0 > 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> setenv bootargs console=ttyS0,115200n8 rootdelay=1 root=/dev/mmcblk0p2 > GUM> fatload mmc 0 a2000000 uimage > reading uimage > > 1291348 bytes read > GUM> bootm a2000000 > ## Booting image at a2000000 ... > Image Name: Angstrom/2.6.31/gumstix-verdex > Image Type: ARM Linux Kernel Image (uncompressed) > Data Size: 1291284 Bytes = 1.2 MB > Load Address: a0008000 > Entry Point: a0008000 > OK > > Starting kernel ... > > Uncompressing > Linux.................................................................................. > done, booting the kernel. > Linux version 2.6.31 (gcc version 4.3.3 (GCC) ) #1 Fri Feb 26 15:45:41 PST > 2010 > CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE), cr=0000397f > CPU: VIVT data cache, VIVT instruction cache > Machine: Gumstix verdex > Memory policy: ECC disabled, Data cache writeback > Run Mode clock: 208.00MHz (*16) > Turbo Mode clock: 416.00MHz (*2.0, active) > Memory clock: 104.00MHz (/2) > System bus clock: 104.00MHz > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 > Kernel command line: console=ttyS0,115200n8 rootdelay=1 root=/dev/mmcblk0p2 > PID hash table entries: 256 (order: 8, 1024 bytes) > Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) > Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) > Memory: 64MB = 64MB total > Memory: 62248KB available (2212K code, 252K data, 88K init, 0K highmem) > NR_IRQS:192 > Console: colour dummy device 80x30 > Calibrating delay loop... 415.33 BogoMIPS (lpj=2076672) > Mount-cache hash table entries: 512 > CPU: Testing write buffer coherency: ok > NET: Registered protocol family 16 > Gumstix verdex udc is disabled > Initializing Gumstix verdex i2c > Initializing Gumstix verdex smsc911x > Initializing Gumstix verdex pcmcia > Not netCF-vx board: pcmcia using newer GPIO configuration > CPLD responded with: ff > found 1 CF slots > Initializing Gumstix verdex FB info > Initializing Gumstix platform_add_devices > bio: create slab <bio-0> at 0 > NET: Registered protocol family 2 > IP route cache hash table entries: 1024 (order: 0, 4096 bytes) > TCP established hash table entries: 2048 (order: 2, 16384 bytes) > TCP bind hash table entries: 2048 (order: 1, 8192 bytes) > TCP: Hash tables configured (established 2048 bind 2048) > TCP reno registered > NET: Registered protocol family 1 > msgmni has been set to 121 > alg: No test for stdrng (krng) > Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) > io scheduler noop registered > io scheduler cfq registered (default) > Console: switching to colour frame buffer device 80x24 > pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 22) is a FFUART > console [ttyS0] enabled > pxa2xx-uart.1: ttyS1 at MMIO 0x40200000 (irq = 21) is a BTUART > pxa2xx-uart.2: ttyS2 at MMIO 0x40700000 (irq = 20) is a STUART > Probing Gumstix Flash ROM at physical address 0x00000000 (16-bit bankwidth) > Gumstix Flash ROM: Found 1 x16 devices at 0x0 in 16-bit bank > Intel/Sharp Extended Query Table at 0x010A > Intel/Sharp Extended Query Table at 0x010A > Intel/Sharp Extended Query Table at 0x010A > Intel/Sharp Extended Query Table at 0x010A > Intel/Sharp Extended Query Table at 0x010A > Using buffer write method > Using auto-unlock on power-up/resume > cfi_cmdset_0001: Erase suspend on write enabled > Using static partitions on Gumstix Flash ROM > Creating 3 MTD partitions on "Gumstix Flash ROM": > 0x000000000000-0x000000040000 : "Bootloader" > 0x000000040000-0x000000f00000 : "RootFS" > 0x000000f00000-0x000001000000 : "Kernel" > pxa-rtc pxa-rtc: rtc core: registered pxa-rtc as rtc0 > TCP cubic registered > NET: Registered protocol family 17 > XScale iWMMXt coprocessor detected. > pxa-rtc pxa-rtc: setting system clock to 2000-01-01 00:00:40 UTC (946684840) > Waiting 1sec before mounting root device... > mmc0: host does not support reading read-only switch. assuming write-enable. > mmc0: new SD card at address 1234 > mmcblk0: mmc0:1234 SA02G 1.83 GiB > mmcblk0: p1 p2 > kjournald starting. Commit interval 5 seconds > EXT3 FS on mmcblk0p2, internal journal > EXT3-fs: mounted filesystem with writeback data mode. > VFS: Mounted root (ext3 filesystem) on device 179:2. > Freeing init memory: 88K > INIT: version 2.86 booting > Please wait: booting... > Starting udev > I2C: i2c-0: PXA I2C adapter > I2C: i2c-1: PXA I2C adapter > tsc2003_probe > tsc2003 i2c touch screen controller > Bill Gatliff <bgat at billgatliff.com > Nicholas Chen <nchen at cs.umd.edu> > tsc2003_probe: checking i2c > tsc2003_probe: calling kzalloc > tsc2003_probe: probing address 0x48 > i2c: error: exhausted retries > i2c: msg_num: 0 msg_idx: -2000 msg_ptr: 0 > i2c: ICR: 000087e0 ISR: 00000002 > tsc2003: probe of 0-0048 failed with error -121 > usbcore: registered new interface driver usbfs > usbcore: registered new interface driver hub > usbcore: registered new device driver usb > ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver > pxa27x-ohci pxa27x-ohci: PXA27x OHCI > pxa27x-ohci pxa27x-ohci: new USB bus registered, assigned bus number 1 > pxa27x-ohci pxa27x-ohci: irq 3, io mem 0x4c000000 > usb usb1: configuration #1 chosen from 1 choice > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 3 ports detected > FAT: codepage cp437 not found > Remounting root file system... > Caching udev devnodes > Populating dev cache > logger: mount: mount point /dev/pts does not exist > logger: mount: mount point /dev/shm does not exist > Undefined users: >> pulse > Skipping /etc/default/volatiles/04_pulse > Undefined users: >> haldaemon > Skipping /etc/default/volatiles/99_hal > Starting Marvell Wifi CF8385... > Configuring network interfaces... eth0: unknown interface: No such device > eth0: unknown interface: No such device > eth0 No such device > > eth0: unknown interface: No such device > done. > Starting portmap daemon: portmapportmap: fork: No such device. > Unknown HZ value! (68) Assume 100. > net.ipv4.conf.default.rp_filter = 1 > net.ipv4.conf.all.rp_filter = 1 > hwclock: can't open '/dev/misc/rtc': No such file or directory > Mon Mar 1 11:18:00 UTC 2010 > hwclock: can't open '/dev/misc/rtc': No such file or directory > Checking for built-in Bluetooth: /etc/rcS.d/S97blueprobe: line 158: can't > open /dev/ttyS1: no such file > yes > Configuring ppp-dialin > Configuring pulseaudio-server > addgroup: pulse: group already in use > > Undefined users: >> haldaemon > Skipping /etc/default/volatiles/99_hal > postinst script returned status 1 > Configuring policykit > chmod: cannot access `/var/run/PolicyKit': No such file or directory > Configuring dbus > System startup links for /etc/init.d/dbus-1 already exist. > Configuring hicolor-icon-theme > //usr/lib/opkg/info/hicolor-icon-theme.postinst: line 7: can't create > /etc/gtk-2.0/gdk-pixbuf.loaders: nonexistent directory > //usr/lib/opkg/info/hicolor-icon-theme.postinst: line 7: > gdk-pixbuf-query-loaders: not found > //usr/lib/opkg/info/hicolor-icon-theme.postinst: line 13: > gtk-update-icon-cache: not found > postinst script returned status 127 > Configuring sudo > Configuring angstrom-zeroconf-audio > Configuring ppp > Configuring hal > Configuring avahi-autoipd > Configuring angstrom-libc-fixup-hack > Configuring avahi-daemon > System startup links for /etc/init.d/avahi-daemon already exist. > Configuring ntpdate > adding crontab > Configuring update-modules > Configuring libnss-mdns > Bluetooth: Core ver 2.15 > NET: Registered protocol family 31 > Bluetooth: HCI device and connection manager initialized > Bluetooth: HCI socket layer initialized > Bluetooth: L2CAP ver 2.13 > Bluetooth: L2CAP socket layer initialized > Bluetooth: HIDP (Human Interface Emulation) ver 1.2 > Registering gumstix PCMCIA interface. > Bluetooth: RFCOMM TTY layer initialized > Bluetooth: RFCOMM socket layer initialized > Bluetooth: RFCOMM ver 1.11 > smsc911x: Driver version 2008-10-21. > eth%d: smsc911x_init: Driver Parameters: > eth%d: smsc911x_init: LAN base: 0xC4A00000 > eth%d: smsc911x_init: IRQ: 163 > eth%d: smsc911x_init: PHY will be autodetected. > eth%d: smsc911x_init: BYTE_TEST: 0x87654321 > eth%d: smsc911x_init: LAN911x identified, idrev: 0x01170002, generation: 2 > eth0: smsc911x_drv_probe: Network interface: "eth0" > eth0: smsc911x_phy_initialise_external: HW_CFG EXT_PHY_DET clear, using > internal PHY > smsc911x-mdio: probed > eth0: smsc911x_mii_probe: PHY 1: addr 1, phy_id 0x0007C0D1 > eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=ffffffff:01, > irq=-1) > eth0: smsc911x_phy_check_loopbackpkt: Successfully verified loopback packet > eth0: smsc911x_mii_probe: Passed Loop Back Test > eth0: smsc911x_mii_probe: phy initialised succesfully > eth0: smsc911x_drv_probe: MAC Address is derived from system serial number > net eth0: MAC Address: ae:f7:51:56:49:d0 > Collected errors: > * ERROR: pulseaudio-server.postinst returned 1 > * ERROR: hicolor-icon-theme.postinst returned 127 > i2c /dev entries driver > > > > > Ash Charles-2 wrote: >> >> Hi mlq, >> >> Good catch...I've changed it to address a2000000 (feel free to correct >> my idiocy directly in the future ;-) ). >> >> There is no reason it shouldn't work on an old XM4--I believe the >> processor is the same between these boards. >> >> Perhaps you can try the kernel found here >> (http://dl.dropbox.com/u/211887/uimage) to see if that works for you? >> >> -Ash >> P.S. Sorry if this is a double-posting. >> On Tue, Mar 2, 2010 at 4:09 PM, mlq <mar...@lm...> wrote: >>> >>> Sigh... >>> >>> I followed your instructions exactly and the boot sequnce freezes after >>> uncompressing linux ........ It does load to correct kernel though. >>> >>> I think the step in the wiki "fatload mmc 0 a20000000 uimage" should be >>> "fatload mmc 0 a2000000 uimage" (one less 0). >>> >>> Anyhow I have no idea why it is locking up, could it be because I have an >>> old XM4 on not a verdex-pro? I was really hoping that it would work on >>> the >>> XM4. >>> >>> mlq >>> >>> >>> Ash Charles-2 wrote: >>>> >>>> Hi mlq, >>>> >>>> I have put together a documentation page on the user wiki: >>>> http://www.gumstix.net/wiki/index.php?title=Verdex_Git_Repository >>>> >>>> Note: MLO is an OMAP3 specific bootstrap loader. It is not necessary >>>> for Verdex. >>>> >>>> Let me know if you have have any problems. >>>> >>>> -Ash >>>> >>>> On Mon, Mar 1, 2010 at 1:23 PM, mlq <mar...@lm...> wrote: >>>>> >>>>> Hi Ash, >>>>> >>>>> I got everything built, thanks! I am struggling getting the verdex >>>>> image >>>>> to >>>>> boot. I tried using the MLO and u-boot that I use with the overo; >>>>> tried >>>>> to >>>>> rebuild them for the verdex (build failed); and I tried using the old >>>>> gumstix-factory.script - nothing seems to work. Should the formatting >>>>> be >>>>> exactly the same as the overo? >>>>> >>>>> Could someone explain the steps I need to take to load the verdex image >>>>> and >>>>> kernel on the microSD card and boot it? >>>>> >>>>> Thanks, >>>>> mlq >>>>> >>>>> >>>>> Ash Charles-2 wrote: >>>>>> >>>>>> Hey mlq, >>>>>> >>>>>> A 'bitbake virtual/kernel' should build the 2.6.31 kernel for verdex. >>>>>> Otherwise, the repository uses a 'task-base-gumstix' recipe to do most >>>>>> of the work for various other recipes in keeping with the old svn >>>>>> style. Note this does not match the current OE style of just adding >>>>>> machine-specific stuff conditionally to the task-base recipe---I tried >>>>>> and couldn't get this to work properly so if anyone has a fix for this >>>>>> I'd love to see it :). >>>>>> The git repository currently provides four Verdex images (thanks >>>>>> Joseph): >>>>>> - verdex-console-image >>>>>> - verdex-palmtop-image >>>>>> - verdex-desktop-image >>>>>> - verdex-gnome-image >>>>>> I had some problems building the last two because of the problems >>>>>> reported on the branch with news & gnumeric etc. but I'm confident >>>>>> these will go away as bugs get fixed upstream. I'd try the >>>>>> verdex-console-image for a start. >>>>>> >>>>>> For loading the code, essentially follow the instructions for Overo >>>>>> for booting from a microSD card. >>>>>> >>>>>> HTH, >>>>>> >>>>>> Ash >>>>>> >>>>>> P.S. If you do get those errors related to task-base, please post them >>>>>> so I can look through them. >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Feb 27, 2010 at 11:10 AM, mlq <mar...@lm...> >>>>>> wrote: >>>>>>> >>>>>>> I am also trying to build the verdex image and have sucessfully built >>>>>>> the >>>>>>> minimal-image and kernel; however when I build the console image i.e. >>>>>>> bitbake console-image it dies on building the task-base. Basically >>>>>>> it >>>>>>> is >>>>>>> looking in the task base folder but is missing the extensions for the >>>>>>> particular tasks (task-base-x, missing x; sorry I dont have the >>>>>>> output >>>>>>> in >>>>>>> front of me). I have 2 questions; >>>>>>> >>>>>>> What is the correct recipe to bitbake for the verdex? (i cant seem to >>>>>>> find >>>>>>> any verdex-specific recipes in the repo) >>>>>>> >>>>>>> What procedure should we follow to flash the mmc? (I was able to boot >>>>>>> using >>>>>>> the FAT16 partition and gumstix-factory.script from the old svn repo >>>>>>> but >>>>>>> I >>>>>>> am not sure if we should be using a similar setup to the overo with >>>>>>> xload?) >>>>>>> >>>>>>> Another related question which is not critical is when I add recipes >>>>>>> to >>>>>>> user.collection/recipes bitbake does not see them - is there typical >>>>>>> reason >>>>>>> for this? >>>>>>> >>>>>>> Thanks, >>>>>>> mlq >>>>>>> >>>>>>> >>>>>>> Connie C wrote: >>>>>>>> >>>>>>>> Hi Joseph, >>>>>>>> >>>>>>>> Thanks for the help. I'm definitely using the bash profile. >>>>>>>> Followed >>>>>>>> all >>>>>>>> those steps. I also followed the second sequence of code to make >>>>>>>> the >>>>>>>> verdex-oe directory and I have the bitbake,build, and >>>>>>>> org.openembedded.dev >>>>>>>> directories inside. I think everything looks okay up to there with >>>>>>>> what >>>>>>>> you posted. >>>>>>>> >>>>>>>> After removing my user.collection and com.gumstix.collection from >>>>>>>> the >>>>>>>> verdex-oe directory, I removed the extraneous tmp directory and ran >>>>>>>> bitbake verdex-console-image and got: >>>>>>>> ERROR: Nothing PROVIDES 'verdex-console-image' (but '[]' DEPENDS on >>>>>>>> or >>>>>>>> otherwise requires it) >>>>>>>> >>>>>>>> I had gotten this originally after I changed >>echo 0 > >>>>>>>> /proc/sys/vm/mmap_min_addr >>>>>>>> and was trying to access the .bb file directly as a result. >>>>>>>> >>>>>>>> Something with how my bitbake is set up? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Connie >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> bionicjoe wrote: >>>>>>>>> >>>>>>>>> Hi, I corrected one critical line below ... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ________________________________ >>>>>>>>> From: Joseph Kortje <jp...@ro...> >>>>>>>>> To: General mailing list for gumstix users. >>>>>>>>> <gum...@li...> >>>>>>>>> Sent: Fri, February 26, 2010 9:12:35 PM >>>>>>>>> Subject: Re: [Gumstix-users] Bitbaking New Kernel 2.6.31 for >>>>>>>>> Verdex >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Connie >>>>>>>>> >>>>>>>>> Most of what Ash checked in for verdex-oe came originally from >>>>>>>>> myself >>>>>>>>> and >>>>>>>>> a few others >>>>>>>>> so I can help you. >>>>>>>>> >>>>>>>>> It builds clean for me. >>>>>>>>> >>>>>>>>> So, lets' review .... >>>>>>>>> >>>>>>>>> What OS distribution are you building with? >>>>>>>>> If it's Ubuntu, please confirm that you did the instruction to not >>>>>>>>> reconfigure bash as dash. >>>>>>>>> >>>>>>>>> >>>>>>>>>>>First I installed all the files in the new directory >>>>>>>>>>>verdex-oe. >>>>>>>>> >>>>>>>>> These should be the steps to follow: >>>>>>>>> >>>>>>>>> $ mkdir -p ~/verdex-oe >>>>>>>>> $ cd ~/verdex-oe >>>>>>>>> $ git clone git://gitorious.org/gumstix-oe/mainline.git >>>>>>>>> org.openembedded.dev >>>>>>>>> $ cd org.openembedded.dev >>>>>>>>> $ git checkout --track -b verdex origin/verdex >>>>>>>>> $ cd ~/verdex-oe >>>>>>>>> $ git clone git://git.openembedded.net/bitbake bitbake >>>>>>>>> $ cd bitbake >>>>>>>>> $ git checkout 1.8.18 >>>>>>>>> $ cd ~/verdex-oe >>>>>>>>> $ cp -r org.openembedded.dev/contrib/gumstix/build . >>>>>>>>> >>>>>>>>>>>sudo -i >>>>>>>>>>>echo 0 > /proc/sys/vm/mmap_min_addr >>>>>>>>> >>>>>>>>> Yes, that should work. >>>>>>>>> >>>>>>>>> Alternatively, you could edit /etc/sysctl.conf (For example sudo >>>>>>>>> gedit >>>>>>>>> /etc.sysctl.conf&) >>>>>>>>> and add the line >>>>>>>>> >>>>>>>>> vm.mmap_min_addr = 0 >>>>>>>>> >>>>>>>>> (Save and then reboot). >>>>>>>>> >>>>>>>>>>> First the bitbake complained that it could not find user >>>>>>>>>>>collection in verdex-oe, so I copied user.collection and >>>>>>>>>>>com.gumstix.collection over into the directory. >>>>>>>>> >>>>>>>>> There is no requirement to copy over user.collection from th older >>>>>>>>> gumstix-oe build environment path. >>>>>>>>> The purpose of user.collection is to override the search path for >>>>>>>>> bitbake >>>>>>>>> recipes. If any bitbake recipes >>>>>>>>> in the user.collection path have the same base name as the ones >>>>>>>>> used >>>>>>>>> in >>>>>>>>> org.openembedded.dev then they would be used >>>>>>>>> in place of the official ones. Unless the developer has a specific >>>>>>>>> reason for adding an override or customization >>>>>>>>> or new bitbake recipe, and understands what he/she is doing with it >>>>>>>>> (and >>>>>>>>> the consequences) >>>>>>>>> I suggest not putting anything in user.collection folder (or don't >>>>>>>>> use >>>>>>>>> the folder at all). >>>>>>>>> >>>>>>>>> Any old user.collection recipes that were used in the old >>>>>>>>> gumstix-oe >>>>>>>>> SVN >>>>>>>>> based projects will not necessarily be compatible >>>>>>>>> with the newer verdex-oe stuff since we are using a newer Angstrom >>>>>>>>> distribution, newer Kernel, newer bitbake, >>>>>>>>> etc. Developers that have such recipes would need to revisit them >>>>>>>>> to >>>>>>>>> port them to the new code base. >>>>>>>>> >>>>>>>>> The warning about not finding user.collection can therefore simply >>>>>>>>> be >>>>>>>>> ignored since you are (presumably) >>>>>>>>> not going to be wanting to override any of the standard bitbake >>>>>>>>> recipes >>>>>>>>> or add any of your own >>>>>>>>> customized ones yet. >>>>>>>>> >>>>>>>>> The old "com.gumstix.collection" and any files in that folder >>>>>>>>> should >>>>>>>>> not >>>>>>>>> be added to this path and >>>>>>>>> is not supported anymore in the Git based OE architecture. Any of >>>>>>>>> the >>>>>>>>> relevant patches or recipes (previously called packages) >>>>>>>>> from the previous com.gumstix.collection are now already integrated >>>>>>>>> into >>>>>>>>> the git based verdex branch org.openembedded.dev recipes. >>>>>>>>> >>>>>>>>> (There are some exceptions such as support for audio, and robostix >>>>>>>>> which >>>>>>>>> are currently not ported to the new verdex-oe branch. Still >>>>>>>>> working >>>>>>>>> on it ....). >>>>>>>>> >>>>>>>>> Here is how to fix your build environment: >>>>>>>>> >>>>>>>>> First, you need to clean out the incorrect files that were added to >>>>>>>>> the >>>>>>>>> build path .... >>>>>>>>> >>>>>>>>> cd ~/verdex-oe >>>>>>>>> sudo rm -rf com.gumstix.collection >>>>>>>>> sudo rm -rf user.collection >>>>>>>>> >>>>>>>>> In this case, since the build cache is probably messed up, we need >>>>>>>>> to >>>>>>>>> start with a clean build >>>>>>>>> >>>>>>>>> sudo rm -rf tmp >>>>>>>>> bitbake verdex-console-image >>>>>>>>> >>>>>>>>> >>>>>>>>> Note: Please don't add ".bb" to the end of the bitbake recipe names >>>>>>>>> in >>>>>>>>> the bitbake command. >>>>>>>>> Also, you can omit the -b option. >>>>>>>>> >>>>>>>>> >>>>>>>>> BTW, please make sure that you have plenty of space in your /home >>>>>>>>> partition. >>>>>>>>> I use a 300GB partition albeit building for several projects for >>>>>>>>> OpenEmbedded and I still find that >>>>>>>>> my space gets eaten up really fast ... >>>>>>>>> >>>>>>>>> I recommend at least 40-60GB is needed to build verdex-oe (both >>>>>>>>> verdex-console-image and verdex-palmtop-image). >>>>>>>>> >>>>>>>>> >>>>>>>>> Let me know your results ... >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Joseph >>>>>>>>> >>>>>>>>> >>>>>>>>> PS: Tip for building faster on dual or quad core cpu .... >>>>>>>>> >>>>>>>>> In >>>>>>>>> ~/verdex-oe/build/conf/site.conf >>>>>>>>> >>>>>>>>> # Uncomment these lines to enable parallel make. >>>>>>>>> # This allows make to spawn mutliple processes to take advantage of >>>>>>>>> multiple >>>>>>>>> # processors. Useful on SMP machines >>>>>>>>> PARALLEL_MAKE = "-j 4" >>>>>>>>> BB_NUMBER_THREADS = "4" >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> View this message in context: >>>>>>> http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27730217.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27749237.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27762956.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27771565.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-03 19:33:00
|
Hey Ash, I re-flashed u-boot and the latest version and still got the same errors as I did on the first boot; here is the output from the second boot: U-Boot 1.2.0 (May 10 2008 - 21:17:19) - PXA270@400 MHz - 1604 *** Welcome to Gumstix *** DRAM: 64 MB Flash: 16 MB Using default environment 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> setenv bootargs console=ttyS0,115200n8 rootdelay=1 root=/dev/mmcblk0p2 GUM> fatload mmc 0 a2000000 uimage reading uimage 1291348 bytes read GUM> bootm a2000000 ## Booting image at a2000000 ... Image Name: Angstrom/2.6.31/gumstix-verdex Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1291284 Bytes = 1.2 MB Load Address: a0008000 Entry Point: a0008000 OK Starting kernel ... Uncompressing Linux.................................................................................. done, booting the kernel. Linux version 2.6.31 (gcc version 4.3.3 (GCC) ) #1 Fri Feb 26 15:45:41 PST 2010 CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE), cr=0000397f CPU: VIVT data cache, VIVT instruction cache Machine: Gumstix verdex Memory policy: ECC disabled, Data cache writeback Run Mode clock: 208.00MHz (*16) Turbo Mode clock: 416.00MHz (*2.0, active) Memory clock: 104.00MHz (/2) System bus clock: 104.00MHz Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: console=ttyS0,115200n8 rootdelay=1 root=/dev/mmcblk0p2 PID hash table entries: 256 (order: 8, 1024 bytes) Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 64MB = 64MB total Memory: 62248KB available (2212K code, 252K data, 88K init, 0K highmem) NR_IRQS:192 Console: colour dummy device 80x30 Calibrating delay loop... 415.33 BogoMIPS (lpj=2076672) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 Gumstix verdex udc is disabled Initializing Gumstix verdex i2c Initializing Gumstix verdex smsc911x Initializing Gumstix verdex pcmcia Not netCF-vx board: pcmcia using newer GPIO configuration CPLD responded with: ff found 1 CF slots Initializing Gumstix verdex FB info Initializing Gumstix platform_add_devices bio: create slab <bio-0> at 0 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered NET: Registered protocol family 1 msgmni has been set to 121 alg: No test for stdrng (krng) Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered io scheduler cfq registered (default) Console: switching to colour frame buffer device 80x24 pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 22) is a FFUART console [ttyS0] enabled pxa2xx-uart.1: ttyS1 at MMIO 0x40200000 (irq = 21) is a BTUART pxa2xx-uart.2: ttyS2 at MMIO 0x40700000 (irq = 20) is a STUART Probing Gumstix Flash ROM at physical address 0x00000000 (16-bit bankwidth) Gumstix Flash ROM: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Intel/Sharp Extended Query Table at 0x010A Using buffer write method Using auto-unlock on power-up/resume cfi_cmdset_0001: Erase suspend on write enabled Using static partitions on Gumstix Flash ROM Creating 3 MTD partitions on "Gumstix Flash ROM": 0x000000000000-0x000000040000 : "Bootloader" 0x000000040000-0x000000f00000 : "RootFS" 0x000000f00000-0x000001000000 : "Kernel" pxa-rtc pxa-rtc: rtc core: registered pxa-rtc as rtc0 TCP cubic registered NET: Registered protocol family 17 XScale iWMMXt coprocessor detected. pxa-rtc pxa-rtc: setting system clock to 2000-01-01 00:00:51 UTC (946684851) Waiting 1sec before mounting root device... mmc0: host does not support reading read-only switch. assuming write-enable. mmc0: new SD card at address 1234 mmcblk0: mmc0:1234 SA02G 1.83 GiB mmcblk0: p1 p2 kjournald starting. Commit interval 5 seconds EXT3 FS on mmcblk0p2, internal journal EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with writeback data mode. VFS: Mounted root (ext3 filesystem) on device 179:2. Freeing init memory: 88K INIT: version 2.86 booting Please wait: booting... Starting udev udevd[47]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/local.rules:34 udevd[47]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/local.rules:35 udevd[47]: NAME="%k" is superfluous and breaudev: starting version 151 ks kernel supplied names, please remove it from /etc/udev/rules.d/udev.rules:18 udevd[47]: NAME="%k" is superfluous and breaks kernel supplied names, please remove it from /etc/udev/rules.d/udev.rules:106 Remounting root file system... udevadm settle - timeout of 3 seconds reached, the event queue contains: /sys/devices/platform/pxa2xx-mci.0/mmc_host/mmc0/mmc0:1234/block/mmcblk0 (193) /sys/devices/platform/pxa2xx-mci.0/mmc_host/mmc0/mmc0:1234/block/mmcblk0/mmcblk0p1 (194) /sys/devices/platform/pxa2xx-mci.0/mmc_host/mmc0/mmc0:1234/block/mmcblk0/mmcblk0p2 (195) Caching udev devnodes Populating dev cachemv: cannot stat `/tmp/uname': No such file or directory Bluetooth: Core ver 2.15 FAT: codepage cp437 not found NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP ver 2.13 Bluetooth: L2CAP socket layer initialized Bluetooth: HIDP (Human Interface Emulation) ver 1.2 usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver pxa27x-ohci pxa27x-ohci: PXA27x OHCI pxa27x-ohci pxa27x-ohci: new USB bus registered, assigned bus number 1 pxa27x-ohci pxa27x-ohci: irq 3, io mem 0x4c000000 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected Registering gumstix PCMCIA interface. Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM ver 1.11 smsc911x: Driver version 2008-10-21. eth%d: smsc911x_init: Driver Parameters: eth%d: smsc911x_init: LAN base: 0xC4A00000 eth%d: smsc911x_init: IRQ: 163 eth%d: smsc911x_init: PHY will be autodetected. eth%d: smsc911x_init: BYTE_TEST: 0x87654321 eth%d: smsc911x_init: LAN911x identified, idrev: 0x01170002, generation: 2 eth0: smsc911x_drv_probe: Network interface: "eth0" eth0: smsc911x_phy_initialise_external: HW_CFG EXT_PHY_DET clear, using internal PHY smsc911x-mdio: probed eth0: smsc911x_mii_probe: PHY 1: addr 1, phy_id 0x0007C0D1 eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=ffffffff:01, irq=-1) eth0: smsc911x_phy_check_loopbackpkt: Successfully verified loopback packet eth0: smsc911x_mii_probe: Passed Loop Back Test eth0: smsc911x_mii_probe: phy initialised succesfully eth0: smsc911x_drv_probe: MAC Address is derived from system serial number net eth0: MAC Address: 02:4c:b7:81:b2:d0 Unknown HZ value! (47) Assume 100. logger: mount: mount point /dev/pts does not exist logger: mount: mount point /dev/shm does not exist Starting Marvell Wifi CF8385... Configuring network interfaces... eth0: smsc911x_open: irq polarity: active low eth0: smsc911x_open: irq type: push-pull eth0: smsc911x_open: Testing irq handler using IRQ 163 eth0: smsc911x_open: IRQ handler passed test using IRQ 163 net eth0: SMSC911x/921x identified at 0xc4a00000, IRQ: 163 eth0: smsc911x_rx_multicast_update: maccr 0x1000000C, HASHH 0x00000000, HASHL 0x00000000 eth0: smsc911x_rx_multicast_update: maccr 0x1000200C, HASHH 0x00000000, HASHL 0x80000000 eth0: smsc911x_rx_multicast_update: maccr 0x1000200C, HASHH 0x00000000, HASHL 0x80000000 eth0 no wireless extensions. eth0: smsc911x_rx_multicast_update: maccr 0x1000200C, HASHH 0x00000000, HASHL 0x80000000 udhcpc (v1.13.2) started run-parts: /etc/udhcpc.d/00avahi-autoipd exited with code 1 eth0: smsc911x_rx_multicast_update: maccr 0x1000200C, HASHH 0x00000000, HASHL 0x80000000 Sending discover... eth0: smsc911x_phy_adjust_link: duplex state has changed eth0: smsc911x_phy_adjust_link: configuring for half duplex mode eth0: smsc911x_phy_update_flowcontrol: half duplex eth0: smsc911x_phy_adjust_link: carrier state has changed eth0: smsc911x_phy_adjust_link: configuring for no carrier Sending discover... Sending discover... eth0: smsc911x_rx_multicast_update: maccr 0x1000200C, HASHH 0x00000000, HASHL 0x80000000 No lease, failing done. Starting portmap daemon: portmapportmap: fork: No such device. Unknown HZ value! (69) Assume 100. net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.all.rp_filter = 1 hwclock: can't open '/dev/misc/rtc': No such file or directory Mon Mar 1 11:18:00 UTC 2010 hwclock: can't open '/dev/misc/rtc': No such file or directory Turning echo off on /dev/ttyS1 /etc/rcS.d/S97blueprobe: line 5: can't open /dev/ttyS1: no such file eth0: smsc911x_rx_multicast_update: maccr 0x1000200C, HASHH 0x00000000, HASHL 0x80008000 tsc2003_probe tsc2003 i2c touch screen controller Bill Gatliff <bgat at billgatliff.com Nicholas Chen <nchen at cs.umd.edu> tsc2003_probe: checking i2c tsc2003_probe: calling kzalloc tsc2003_probe: probing address 0x48 i2c: error: exhausted retries i2c: msg_num: 0 msg_idx: -2000 msg_ptr: 0 i2c: ICR: 000087e0 ISR: 00000002 tsc2003: probe of 0-0048 failed with error -121 I2C: i2c-0: PXA I2C adapter I2C: i2c-1: PXA I2C adapter i2c /dev entries driver Ash Charles wrote: > > Hi mlq, > > I don't see the same behaviour where setenv needs to be called before > fatload. As these commands do completely different things, it would > seem like a bug to me. Have you tried using the more recent 1604 > version of uboot? > > The U-Boot files are available here: http://www.gumstix.net/feeds/u-boot/ > The instructions for *carefully* reflashing U-Boot via serial > connection are given here: > http://www.gumstix.net/User-How-To-s/view/Developer-how-to-s/Reflashing-using-a-serial-connection/110.html > > I'll have to look through the messages you are seeing in detail. Some > seem to be configuration/installation issues: does it work any better > the second time you try to boot? Other ones seem to be problems with > how I've set up udev. > > Thanks for your feedback, > > Ash > On Wed, Mar 3, 2010 at 10:03 AM, mlq <mar...@lm...> wrote: >> >> Ok so I finally got it to boot; looks like the setenv has to be called >> before >> fatload. However the boot locks up; below is the output. Here is the >> fdisk >> output on how my sd card is formated. Note that the FAT partition only >> has >> the uimage on it and the ext3 has the un-tarred rootfs. >> >> Disk /dev/sdb: 1973 MB, 1973420032 bytes >> 255 heads, 63 sectors/track, 239 cylinders >> Units = cylinders of 16065 * 512 = 8225280 bytes >> Disk identifier: 0x00000000 >> >> Device Boot Start End Blocks Id System >> /dev/sdb1 * 1 5 40131 c W95 FAT32 (LBA) >> /dev/sdb2 6 239 1879605 83 Linux >> >> U-Boot 1.2.0 (Dec 21 2007 - 13:34:50) - PXA270@400 MHz - 1578M >> >> *** Welcome to Gumstix *** >> >> DRAM: 64 MB >> Flash: 16 MB >> Using default environment >> >> Hit any key to stop autoboot: 0 >> 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> setenv bootargs console=ttyS0,115200n8 rootdelay=1 >> root=/dev/mmcblk0p2 >> GUM> fatload mmc 0 a2000000 uimage >> reading uimage >> >> 1291348 bytes read >> GUM> bootm a2000000 >> ## Booting image at a2000000 ... >> Image Name: Angstrom/2.6.31/gumstix-verdex >> Image Type: ARM Linux Kernel Image (uncompressed) >> Data Size: 1291284 Bytes = 1.2 MB >> Load Address: a0008000 >> Entry Point: a0008000 >> OK >> >> Starting kernel ... >> >> Uncompressing >> Linux.................................................................................. >> done, booting the kernel. >> Linux version 2.6.31 (gcc version 4.3.3 (GCC) ) #1 Fri Feb 26 15:45:41 >> PST >> 2010 >> CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE), cr=0000397f >> CPU: VIVT data cache, VIVT instruction cache >> Machine: Gumstix verdex >> Memory policy: ECC disabled, Data cache writeback >> Run Mode clock: 208.00MHz (*16) >> Turbo Mode clock: 416.00MHz (*2.0, active) >> Memory clock: 104.00MHz (/2) >> System bus clock: 104.00MHz >> Built 1 zonelists in Zone order, mobility grouping on. Total pages: >> 16256 >> Kernel command line: console=ttyS0,115200n8 rootdelay=1 >> root=/dev/mmcblk0p2 >> PID hash table entries: 256 (order: 8, 1024 bytes) >> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) >> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) >> Memory: 64MB = 64MB total >> Memory: 62248KB available (2212K code, 252K data, 88K init, 0K highmem) >> NR_IRQS:192 >> Console: colour dummy device 80x30 >> Calibrating delay loop... 415.33 BogoMIPS (lpj=2076672) >> Mount-cache hash table entries: 512 >> CPU: Testing write buffer coherency: ok >> NET: Registered protocol family 16 >> Gumstix verdex udc is disabled >> Initializing Gumstix verdex i2c >> Initializing Gumstix verdex smsc911x >> Initializing Gumstix verdex pcmcia >> Not netCF-vx board: pcmcia using newer GPIO configuration >> CPLD responded with: ff >> found 1 CF slots >> Initializing Gumstix verdex FB info >> Initializing Gumstix platform_add_devices >> bio: create slab <bio-0> at 0 >> NET: Registered protocol family 2 >> IP route cache hash table entries: 1024 (order: 0, 4096 bytes) >> TCP established hash table entries: 2048 (order: 2, 16384 bytes) >> TCP bind hash table entries: 2048 (order: 1, 8192 bytes) >> TCP: Hash tables configured (established 2048 bind 2048) >> TCP reno registered >> NET: Registered protocol family 1 >> msgmni has been set to 121 >> alg: No test for stdrng (krng) >> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) >> io scheduler noop registered >> io scheduler cfq registered (default) >> Console: switching to colour frame buffer device 80x24 >> pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 22) is a FFUART >> console [ttyS0] enabled >> pxa2xx-uart.1: ttyS1 at MMIO 0x40200000 (irq = 21) is a BTUART >> pxa2xx-uart.2: ttyS2 at MMIO 0x40700000 (irq = 20) is a STUART >> Probing Gumstix Flash ROM at physical address 0x00000000 (16-bit >> bankwidth) >> Gumstix Flash ROM: Found 1 x16 devices at 0x0 in 16-bit bank >> Intel/Sharp Extended Query Table at 0x010A >> Intel/Sharp Extended Query Table at 0x010A >> Intel/Sharp Extended Query Table at 0x010A >> Intel/Sharp Extended Query Table at 0x010A >> Intel/Sharp Extended Query Table at 0x010A >> Using buffer write method >> Using auto-unlock on power-up/resume >> cfi_cmdset_0001: Erase suspend on write enabled >> Using static partitions on Gumstix Flash ROM >> Creating 3 MTD partitions on "Gumstix Flash ROM": >> 0x000000000000-0x000000040000 : "Bootloader" >> 0x000000040000-0x000000f00000 : "RootFS" >> 0x000000f00000-0x000001000000 : "Kernel" >> pxa-rtc pxa-rtc: rtc core: registered pxa-rtc as rtc0 >> TCP cubic registered >> NET: Registered protocol family 17 >> XScale iWMMXt coprocessor detected. >> pxa-rtc pxa-rtc: setting system clock to 2000-01-01 00:00:40 UTC >> (946684840) >> Waiting 1sec before mounting root device... >> mmc0: host does not support reading read-only switch. assuming >> write-enable. >> mmc0: new SD card at address 1234 >> mmcblk0: mmc0:1234 SA02G 1.83 GiB >> mmcblk0: p1 p2 >> kjournald starting. Commit interval 5 seconds >> EXT3 FS on mmcblk0p2, internal journal >> EXT3-fs: mounted filesystem with writeback data mode. >> VFS: Mounted root (ext3 filesystem) on device 179:2. >> Freeing init memory: 88K >> INIT: version 2.86 booting >> Please wait: booting... >> Starting udev >> I2C: i2c-0: PXA I2C adapter >> I2C: i2c-1: PXA I2C adapter >> tsc2003_probe >> tsc2003 i2c touch screen controller >> Bill Gatliff <bgat at billgatliff.com >> Nicholas Chen <nchen at cs.umd.edu> >> tsc2003_probe: checking i2c >> tsc2003_probe: calling kzalloc >> tsc2003_probe: probing address 0x48 >> i2c: error: exhausted retries >> i2c: msg_num: 0 msg_idx: -2000 msg_ptr: 0 >> i2c: ICR: 000087e0 ISR: 00000002 >> tsc2003: probe of 0-0048 failed with error -121 >> usbcore: registered new interface driver usbfs >> usbcore: registered new interface driver hub >> usbcore: registered new device driver usb >> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver >> pxa27x-ohci pxa27x-ohci: PXA27x OHCI >> pxa27x-ohci pxa27x-ohci: new USB bus registered, assigned bus number 1 >> pxa27x-ohci pxa27x-ohci: irq 3, io mem 0x4c000000 >> usb usb1: configuration #1 chosen from 1 choice >> hub 1-0:1.0: USB hub found >> hub 1-0:1.0: 3 ports detected >> FAT: codepage cp437 not found >> Remounting root file system... >> Caching udev devnodes >> Populating dev cache >> logger: mount: mount point /dev/pts does not exist >> logger: mount: mount point /dev/shm does not exist >> Undefined users: >>> pulse >> Skipping /etc/default/volatiles/04_pulse >> Undefined users: >>> haldaemon >> Skipping /etc/default/volatiles/99_hal >> Starting Marvell Wifi CF8385... >> Configuring network interfaces... eth0: unknown interface: No such device >> eth0: unknown interface: No such device >> eth0 No such device >> >> eth0: unknown interface: No such device >> done. >> Starting portmap daemon: portmapportmap: fork: No such device. >> Unknown HZ value! (68) Assume 100. >> net.ipv4.conf.default.rp_filter = 1 >> net.ipv4.conf.all.rp_filter = 1 >> hwclock: can't open '/dev/misc/rtc': No such file or directory >> Mon Mar 1 11:18:00 UTC 2010 >> hwclock: can't open '/dev/misc/rtc': No such file or directory >> Checking for built-in Bluetooth: /etc/rcS.d/S97blueprobe: line 158: can't >> open /dev/ttyS1: no such file >> yes >> Configuring ppp-dialin >> Configuring pulseaudio-server >> addgroup: pulse: group already in use >> >> Undefined users: >>> haldaemon >> Skipping /etc/default/volatiles/99_hal >> postinst script returned status 1 >> Configuring policykit >> chmod: cannot access `/var/run/PolicyKit': No such file or directory >> Configuring dbus >> System startup links for /etc/init.d/dbus-1 already exist. >> Configuring hicolor-icon-theme >> //usr/lib/opkg/info/hicolor-icon-theme.postinst: line 7: can't create >> /etc/gtk-2.0/gdk-pixbuf.loaders: nonexistent directory >> //usr/lib/opkg/info/hicolor-icon-theme.postinst: line 7: >> gdk-pixbuf-query-loaders: not found >> //usr/lib/opkg/info/hicolor-icon-theme.postinst: line 13: >> gtk-update-icon-cache: not found >> postinst script returned status 127 >> Configuring sudo >> Configuring angstrom-zeroconf-audio >> Configuring ppp >> Configuring hal >> Configuring avahi-autoipd >> Configuring angstrom-libc-fixup-hack >> Configuring avahi-daemon >> System startup links for /etc/init.d/avahi-daemon already exist. >> Configuring ntpdate >> adding crontab >> Configuring update-modules >> Configuring libnss-mdns >> Bluetooth: Core ver 2.15 >> NET: Registered protocol family 31 >> Bluetooth: HCI device and connection manager initialized >> Bluetooth: HCI socket layer initialized >> Bluetooth: L2CAP ver 2.13 >> Bluetooth: L2CAP socket layer initialized >> Bluetooth: HIDP (Human Interface Emulation) ver 1.2 >> Registering gumstix PCMCIA interface. >> Bluetooth: RFCOMM TTY layer initialized >> Bluetooth: RFCOMM socket layer initialized >> Bluetooth: RFCOMM ver 1.11 >> smsc911x: Driver version 2008-10-21. >> eth%d: smsc911x_init: Driver Parameters: >> eth%d: smsc911x_init: LAN base: 0xC4A00000 >> eth%d: smsc911x_init: IRQ: 163 >> eth%d: smsc911x_init: PHY will be autodetected. >> eth%d: smsc911x_init: BYTE_TEST: 0x87654321 >> eth%d: smsc911x_init: LAN911x identified, idrev: 0x01170002, generation: >> 2 >> eth0: smsc911x_drv_probe: Network interface: "eth0" >> eth0: smsc911x_phy_initialise_external: HW_CFG EXT_PHY_DET clear, using >> internal PHY >> smsc911x-mdio: probed >> eth0: smsc911x_mii_probe: PHY 1: addr 1, phy_id 0x0007C0D1 >> eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=ffffffff:01, >> irq=-1) >> eth0: smsc911x_phy_check_loopbackpkt: Successfully verified loopback >> packet >> eth0: smsc911x_mii_probe: Passed Loop Back Test >> eth0: smsc911x_mii_probe: phy initialised succesfully >> eth0: smsc911x_drv_probe: MAC Address is derived from system serial >> number >> net eth0: MAC Address: ae:f7:51:56:49:d0 >> Collected errors: >> * ERROR: pulseaudio-server.postinst returned 1 >> * ERROR: hicolor-icon-theme.postinst returned 127 >> i2c /dev entries driver >> >> >> >> >> Ash Charles-2 wrote: >>> >>> Hi mlq, >>> >>> Good catch...I've changed it to address a2000000 (feel free to correct >>> my idiocy directly in the future ;-) ). >>> >>> There is no reason it shouldn't work on an old XM4--I believe the >>> processor is the same between these boards. >>> >>> Perhaps you can try the kernel found here >>> (http://dl.dropbox.com/u/211887/uimage) to see if that works for you? >>> >>> -Ash >>> P.S. Sorry if this is a double-posting. >>> On Tue, Mar 2, 2010 at 4:09 PM, mlq <mar...@lm...> wrote: >>>> >>>> Sigh... >>>> >>>> I followed your instructions exactly and the boot sequnce freezes after >>>> uncompressing linux ........ It does load to correct kernel though. >>>> >>>> I think the step in the wiki "fatload mmc 0 a20000000 uimage" should be >>>> "fatload mmc 0 a2000000 uimage" (one less 0). >>>> >>>> Anyhow I have no idea why it is locking up, could it be because I have >>>> an >>>> old XM4 on not a verdex-pro? I was really hoping that it would work on >>>> the >>>> XM4. >>>> >>>> mlq >>>> >>>> >>>> Ash Charles-2 wrote: >>>>> >>>>> Hi mlq, >>>>> >>>>> I have put together a documentation page on the user wiki: >>>>> http://www.gumstix.net/wiki/index.php?title=Verdex_Git_Repository >>>>> >>>>> Note: MLO is an OMAP3 specific bootstrap loader. It is not necessary >>>>> for Verdex. >>>>> >>>>> Let me know if you have have any problems. >>>>> >>>>> -Ash >>>>> >>>>> On Mon, Mar 1, 2010 at 1:23 PM, mlq <mar...@lm...> wrote: >>>>>> >>>>>> Hi Ash, >>>>>> >>>>>> I got everything built, thanks! I am struggling getting the verdex >>>>>> image >>>>>> to >>>>>> boot. I tried using the MLO and u-boot that I use with the overo; >>>>>> tried >>>>>> to >>>>>> rebuild them for the verdex (build failed); and I tried using the old >>>>>> gumstix-factory.script - nothing seems to work. Should the >>>>>> formatting >>>>>> be >>>>>> exactly the same as the overo? >>>>>> >>>>>> Could someone explain the steps I need to take to load the verdex >>>>>> image >>>>>> and >>>>>> kernel on the microSD card and boot it? >>>>>> >>>>>> Thanks, >>>>>> mlq >>>>>> >>>>>> >>>>>> Ash Charles-2 wrote: >>>>>>> >>>>>>> Hey mlq, >>>>>>> >>>>>>> A 'bitbake virtual/kernel' should build the 2.6.31 kernel for >>>>>>> verdex. >>>>>>> Otherwise, the repository uses a 'task-base-gumstix' recipe to do >>>>>>> most >>>>>>> of the work for various other recipes in keeping with the old svn >>>>>>> style. Note this does not match the current OE style of just adding >>>>>>> machine-specific stuff conditionally to the task-base recipe---I >>>>>>> tried >>>>>>> and couldn't get this to work properly so if anyone has a fix for >>>>>>> this >>>>>>> I'd love to see it :). >>>>>>> The git repository currently provides four Verdex images (thanks >>>>>>> Joseph): >>>>>>> - verdex-console-image >>>>>>> - verdex-palmtop-image >>>>>>> - verdex-desktop-image >>>>>>> - verdex-gnome-image >>>>>>> I had some problems building the last two because of the problems >>>>>>> reported on the branch with news & gnumeric etc. but I'm confident >>>>>>> these will go away as bugs get fixed upstream. I'd try the >>>>>>> verdex-console-image for a start. >>>>>>> >>>>>>> For loading the code, essentially follow the instructions for Overo >>>>>>> for booting from a microSD card. >>>>>>> >>>>>>> HTH, >>>>>>> >>>>>>> Ash >>>>>>> >>>>>>> P.S. If you do get those errors related to task-base, please post >>>>>>> them >>>>>>> so I can look through them. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Feb 27, 2010 at 11:10 AM, mlq <mar...@lm...> >>>>>>> wrote: >>>>>>>> >>>>>>>> I am also trying to build the verdex image and have sucessfully >>>>>>>> built >>>>>>>> the >>>>>>>> minimal-image and kernel; however when I build the console image >>>>>>>> i.e. >>>>>>>> bitbake console-image it dies on building the task-base. Basically >>>>>>>> it >>>>>>>> is >>>>>>>> looking in the task base folder but is missing the extensions for >>>>>>>> the >>>>>>>> particular tasks (task-base-x, missing x; sorry I dont have the >>>>>>>> output >>>>>>>> in >>>>>>>> front of me). I have 2 questions; >>>>>>>> >>>>>>>> What is the correct recipe to bitbake for the verdex? (i cant seem >>>>>>>> to >>>>>>>> find >>>>>>>> any verdex-specific recipes in the repo) >>>>>>>> >>>>>>>> What procedure should we follow to flash the mmc? (I was able to >>>>>>>> boot >>>>>>>> using >>>>>>>> the FAT16 partition and gumstix-factory.script from the old svn >>>>>>>> repo >>>>>>>> but >>>>>>>> I >>>>>>>> am not sure if we should be using a similar setup to the overo with >>>>>>>> xload?) >>>>>>>> >>>>>>>> Another related question which is not critical is when I add >>>>>>>> recipes >>>>>>>> to >>>>>>>> user.collection/recipes bitbake does not see them - is there >>>>>>>> typical >>>>>>>> reason >>>>>>>> for this? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> mlq >>>>>>>> >>>>>>>> >>>>>>>> Connie C wrote: >>>>>>>>> >>>>>>>>> Hi Joseph, >>>>>>>>> >>>>>>>>> Thanks for the help. I'm definitely using the bash profile. >>>>>>>>> Followed >>>>>>>>> all >>>>>>>>> those steps. I also followed the second sequence of code to make >>>>>>>>> the >>>>>>>>> verdex-oe directory and I have the bitbake,build, and >>>>>>>>> org.openembedded.dev >>>>>>>>> directories inside. I think everything looks okay up to there >>>>>>>>> with >>>>>>>>> what >>>>>>>>> you posted. >>>>>>>>> >>>>>>>>> After removing my user.collection and com.gumstix.collection from >>>>>>>>> the >>>>>>>>> verdex-oe directory, I removed the extraneous tmp directory and >>>>>>>>> ran >>>>>>>>> bitbake verdex-console-image and got: >>>>>>>>> ERROR: Nothing PROVIDES 'verdex-console-image' (but '[]' DEPENDS >>>>>>>>> on >>>>>>>>> or >>>>>>>>> otherwise requires it) >>>>>>>>> >>>>>>>>> I had gotten this originally after I changed >>echo 0 > >>>>>>>>> /proc/sys/vm/mmap_min_addr >>>>>>>>> and was trying to access the .bb file directly as a result. >>>>>>>>> >>>>>>>>> Something with how my bitbake is set up? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Connie >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> bionicjoe wrote: >>>>>>>>>> >>>>>>>>>> Hi, I corrected one critical line below ... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ________________________________ >>>>>>>>>> From: Joseph Kortje <jp...@ro...> >>>>>>>>>> To: General mailing list for gumstix users. >>>>>>>>>> <gum...@li...> >>>>>>>>>> Sent: Fri, February 26, 2010 9:12:35 PM >>>>>>>>>> Subject: Re: [Gumstix-users] Bitbaking New Kernel 2.6.31 for >>>>>>>>>> Verdex >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Connie >>>>>>>>>> >>>>>>>>>> Most of what Ash checked in for verdex-oe came originally from >>>>>>>>>> myself >>>>>>>>>> and >>>>>>>>>> a few others >>>>>>>>>> so I can help you. >>>>>>>>>> >>>>>>>>>> It builds clean for me. >>>>>>>>>> >>>>>>>>>> So, lets' review .... >>>>>>>>>> >>>>>>>>>> What OS distribution are you building with? >>>>>>>>>> If it's Ubuntu, please confirm that you did the instruction to >>>>>>>>>> not >>>>>>>>>> reconfigure bash as dash. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>First I installed all the files in the new directory >>>>>>>>>>>>verdex-oe. >>>>>>>>>> >>>>>>>>>> These should be the steps to follow: >>>>>>>>>> >>>>>>>>>> $ mkdir -p ~/verdex-oe >>>>>>>>>> $ cd ~/verdex-oe >>>>>>>>>> $ git clone git://gitorious.org/gumstix-oe/mainline.git >>>>>>>>>> org.openembedded.dev >>>>>>>>>> $ cd org.openembedded.dev >>>>>>>>>> $ git checkout --track -b verdex origin/verdex >>>>>>>>>> $ cd ~/verdex-oe >>>>>>>>>> $ git clone git://git.openembedded.net/bitbake bitbake >>>>>>>>>> $ cd bitbake >>>>>>>>>> $ git checkout 1.8.18 >>>>>>>>>> $ cd ~/verdex-oe >>>>>>>>>> $ cp -r org.openembedded.dev/contrib/gumstix/build . >>>>>>>>>> >>>>>>>>>>>>sudo -i >>>>>>>>>>>>echo 0 > /proc/sys/vm/mmap_min_addr >>>>>>>>>> >>>>>>>>>> Yes, that should work. >>>>>>>>>> >>>>>>>>>> Alternatively, you could edit /etc/sysctl.conf (For example sudo >>>>>>>>>> gedit >>>>>>>>>> /etc.sysctl.conf&) >>>>>>>>>> and add the line >>>>>>>>>> >>>>>>>>>> vm.mmap_min_addr = 0 >>>>>>>>>> >>>>>>>>>> (Save and then reboot). >>>>>>>>>> >>>>>>>>>>>> First the bitbake complained that it could not find user >>>>>>>>>>>>collection in verdex-oe, so I copied user.collection and >>>>>>>>>>>>com.gumstix.collection over into the directory. >>>>>>>>>> >>>>>>>>>> There is no requirement to copy over user.collection from th >>>>>>>>>> older >>>>>>>>>> gumstix-oe build environment path. >>>>>>>>>> The purpose of user.collection is to override the search path for >>>>>>>>>> bitbake >>>>>>>>>> recipes. If any bitbake recipes >>>>>>>>>> in the user.collection path have the same base name as the ones >>>>>>>>>> used >>>>>>>>>> in >>>>>>>>>> org.openembedded.dev then they would be used >>>>>>>>>> in place of the official ones. Unless the developer has a >>>>>>>>>> specific >>>>>>>>>> reason for adding an override or customization >>>>>>>>>> or new bitbake recipe, and understands what he/she is doing with >>>>>>>>>> it >>>>>>>>>> (and >>>>>>>>>> the consequences) >>>>>>>>>> I suggest not putting anything in user.collection folder (or >>>>>>>>>> don't >>>>>>>>>> use >>>>>>>>>> the folder at all). >>>>>>>>>> >>>>>>>>>> Any old user.collection recipes that were used in the old >>>>>>>>>> gumstix-oe >>>>>>>>>> SVN >>>>>>>>>> based projects will not necessarily be compatible >>>>>>>>>> with the newer verdex-oe stuff since we are using a newer >>>>>>>>>> Angstrom >>>>>>>>>> distribution, newer Kernel, newer bitbake, >>>>>>>>>> etc. Developers that have such recipes would need to revisit >>>>>>>>>> them >>>>>>>>>> to >>>>>>>>>> port them to the new code base. >>>>>>>>>> >>>>>>>>>> The warning about not finding user.collection can therefore >>>>>>>>>> simply >>>>>>>>>> be >>>>>>>>>> ignored since you are (presumably) >>>>>>>>>> not going to be wanting to override any of the standard bitbake >>>>>>>>>> recipes >>>>>>>>>> or add any of your own >>>>>>>>>> customized ones yet. >>>>>>>>>> >>>>>>>>>> The old "com.gumstix.collection" and any files in that folder >>>>>>>>>> should >>>>>>>>>> not >>>>>>>>>> be added to this path and >>>>>>>>>> is not supported anymore in the Git based OE architecture. Any >>>>>>>>>> of >>>>>>>>>> the >>>>>>>>>> relevant patches or recipes (previously called packages) >>>>>>>>>> from the previous com.gumstix.collection are now already >>>>>>>>>> integrated >>>>>>>>>> into >>>>>>>>>> the git based verdex branch org.openembedded.dev recipes. >>>>>>>>>> >>>>>>>>>> (There are some exceptions such as support for audio, and >>>>>>>>>> robostix >>>>>>>>>> which >>>>>>>>>> are currently not ported to the new verdex-oe branch. Still >>>>>>>>>> working >>>>>>>>>> on it ....). >>>>>>>>>> >>>>>>>>>> Here is how to fix your build environment: >>>>>>>>>> >>>>>>>>>> First, you need to clean out the incorrect files that were added >>>>>>>>>> to >>>>>>>>>> the >>>>>>>>>> build path .... >>>>>>>>>> >>>>>>>>>> cd ~/verdex-oe >>>>>>>>>> sudo rm -rf com.gumstix.collection >>>>>>>>>> sudo rm -rf user.collection >>>>>>>>>> >>>>>>>>>> In this case, since the build cache is probably messed up, we >>>>>>>>>> need >>>>>>>>>> to >>>>>>>>>> start with a clean build >>>>>>>>>> >>>>>>>>>> sudo rm -rf tmp >>>>>>>>>> bitbake verdex-console-image >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Note: Please don't add ".bb" to the end of the bitbake recipe >>>>>>>>>> names >>>>>>>>>> in >>>>>>>>>> the bitbake command. >>>>>>>>>> Also, you can omit the -b option. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> BTW, please make sure that you have plenty of space in your /home >>>>>>>>>> partition. >>>>>>>>>> I use a 300GB partition albeit building for several projects for >>>>>>>>>> OpenEmbedded and I still find that >>>>>>>>>> my space gets eaten up really fast ... >>>>>>>>>> >>>>>>>>>> I recommend at least 40-60GB is needed to build verdex-oe (both >>>>>>>>>> verdex-console-image and verdex-palmtop-image). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Let me know your results ... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Joseph >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> PS: Tip for building faster on dual or quad core cpu .... >>>>>>>>>> >>>>>>>>>> In >>>>>>>>>> ~/verdex-oe/build/conf/site.conf >>>>>>>>>> >>>>>>>>>> # Uncomment these lines to enable parallel make. >>>>>>>>>> # This allows make to spawn mutliple processes to take advantage >>>>>>>>>> of >>>>>>>>>> multiple >>>>>>>>>> # processors. Useful on SMP machines >>>>>>>>>> PARALLEL_MAKE = "-j 4" >>>>>>>>>> BB_NUMBER_THREADS = "4" >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> View this message in context: >>>>>>>> http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27730217.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27749237.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27762956.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27771565.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27772645.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2010-03-03 19:41:23
|
Hi Connie, On Wed, Mar 3, 2010 at 11:32 AM, mlq <mar...@lm...> wrote: > > Hey Ash, > > I re-flashed u-boot and the latest version and still got the same errors as > I did on the first boot; here is the output from the second boot: Make sure that you leave it for at least a few minutes. I seem to recall that the very first boot takes considerably longer while it figures out the ssh key or something. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: Jim D. <jd...@wh...> - 2010-03-17 18:52:15
|
I have an older Verdex XL6P with an additional piggyback board containing ethernet and microSD. 1) Can one boot off a microSD card with this configuration (or only with the newer Verdex which has the microSD on the main board?) 2) Are the newer images for the Verdex compatible with this XL6P board? Ash Charles wrote: > Hi Grahame, > > The new kernel is larger than 1MB so attempting to write it into Flash > memory (as you did with the katinstall 100000) command will fail. I > haven't published an updated version of U-Boot with corrected flash > partitions. If you need this immediately, let me know and I'll push > out what I have. > > For now, the recommended way to try the kernel is to load it from a > MMC/microSD card as the kernel never needs to be written to flash but > can instead be loaded directly into RAM. I think loading off a memory > card is setup as the default action in our U-Boot so it'll > automatically boot into the new kernel if you have the card installed > at boot. > > HTH, > > Ash > > On Mon, Mar 15, 2010 at 10:28 PM, Grahame Jordan <gb...@th...> wrote: > >> Hi, >> >> I have followed the instructions on >> http://www.gumstix.net/wiki/index.php?title=Verdex_Git_Repository accept >> I am putting it on flash. >> Below is the output I get. Am I missing a driver in the kernel? >> >> Thanks >> >> Grahame Jordan >> >> >> GUM> copy_kernel_flash(): katinstall 100000 - >> OK >> >> katload >> 100000 >> >> Copying kernel to 0xa2000000 from 0x00f00000 (length >> 0x00100000)...done >> >> GUM> copy_kernel_flash(): katload 100000 - >> OK >> >> set_environment_variables(): >> >> boot_new_image() >> >> bootm >> >> ## Booting image at a2000000 >> ... >> >> Image Name: >> Angstrom/2.6.31/gumstix-verdex >> >> Image Type: ARM Linux Kernel Image >> (uncompressed) >> >> Data Size: 1290368 Bytes = 1.2 >> MB >> >> Load Address: >> a0008000 >> >> Entry Point: >> a0008000 >> >> OK >> >> >> >> Starting kernel >> ... >> >> >> >> Uncompressing >> Linux.................................................................................. >> done, booting the >> kernel. >> >> Linux version 2.6.31 (gjordan@bwing) (gcc version 4.3.3 (GCC) ) #1 Tue >> Mar 16 14:46:24 EST >> 2010 >> >> CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE), >> cr=0000397f >> >> CPU: VIVT data cache, VIVT instruction >> cache >> >> Machine: Gumstix >> verdex >> >> Memory policy: ECC disabled, Data cache >> writeback >> >> Run Mode clock: 208.00MHz >> (*16) >> >> Turbo Mode clock: 416.00MHz (*2.0, >> active) >> >> Memory clock: 104.00MHz >> (/2) >> >> System bus clock: >> 104.00MHz >> >> Built 1 zonelists in Zone order, mobility grouping on. Total pages: >> 16256 >> >> Kernel command line: console=ttyS0,115200n8 root=1f01 rootfstype=jffs2 >> reboot=cold,hard,geserial=1345987 >> >> PID hash table entries: 256 (order: 8, 1024 >> bytes) >> >> Dentry cache hash table entries: 8192 (order: 3, 32768 >> bytes) >> >> Inode-cache hash table entries: 4096 (order: 2, 16384 >> bytes) >> >> Memory: 64MB = 64MB >> total >> >> Memory: 62248KB available (2212K code, 252K data, 88K init, 0K >> highmem) >> >> NR_IRQS:192 >> >> Console: colour dummy device >> 80x30 >> >> Calibrating delay loop... 415.33 BogoMIPS >> (lpj=2076672) >> >> Mount-cache hash table entries: >> 512 >> >> CPU: Testing write buffer coherency: >> ok >> >> NET: Registered protocol family >> 16 >> >> Gumstix verdex udc is >> disabled >> >> Initializing Gumstix verdex >> i2c >> >> Initializing Gumstix verdex >> smsc911x >> >> Initializing Gumstix verdex >> pcmcia >> >> Not netCF-vx board: pcmcia using newer GPIO >> configuration >> >> CPLD responded with: >> ff >> >> found 1 CF slots >> Initializing Gumstix verdex FB info >> Initializing Gumstix platform_add_devices >> bio: create slab <bio-0> at 0 >> NET: Registered protocol family 2 >> IP route cache hash table entries: 1024 (order: 0, 4096 bytes) >> TCP established hash table entries: 2048 (order: 2, 16384 bytes) >> TCP bind hash table entries: 2048 (order: 1, 8192 bytes) >> TCP: Hash tables configured (established 2048 bind 2048) >> TCP reno registered >> NET: Registered protocol family 1 >> msgmni has been set to 121 >> alg: No test for stdrng (krng) >> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) >> io scheduler noop registered >> io scheduler cfq registered (default) >> Console: switching to colour frame buffer device 80x24 >> pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 22) is a FFUART >> console [ttyS0] enabled >> pxa2xx-uart.1: ttyS1 at MMIO 0x40200000 (irq = 21) is a BTUART >> pxa2xx-uart.2: ttyS2 at MMIO 0x40700000 (irq = 20) is a STUART >> Probing Gumstix Flash ROM at physical address 0x00000000 (16-bit bankwidth) >> Gumstix Flash ROM: Found 1 x16 devices at 0x0 in 16-bit bank >> Intel/Sharp Extended Query Table at 0x010A >> Intel/Sharp Extended Query Table at 0x010A >> Intel/Sharp Extended Query Table at 0x010A >> Intel/Sharp Extended Query Table at 0x010A >> Intel/Sharp Extended Query Table at 0x010A >> Using buffer write method >> Using auto-unlock on power-up/resume >> cfi_cmdset_0001: Erase suspend on write enabled >> Using static partitions on Gumstix Flash ROM >> Creating 3 MTD partitions on "Gumstix Flash ROM": >> 0x000000000000-0x000000040000 : "Bootloader" >> 0x000000040000-0x000000f00000 : "RootFS" >> 0x000000f00000-0x000001000000 : "Kernel" >> pxa-rtc pxa-rtc: rtc core: registered pxa-rtc as rtc0 >> TCP cubic registered >> NET: Registered protocol family 17 >> XScale iWMMXt coprocessor detected. >> pxa-rtc pxa-rtc: setting system clock to 2000-01-01 00:14:49 UTC (946685689) >> VFS: Cannot open root device "1f01" or unknown-block(31,1) >> Please append a correct "root=" boot option; here are the available >> partitions: >> 1f00 256 mtdblock0 (driver?) >> 1f01 15104 mtdblock1 (driver?) >> 1f02 1024 mtdblock2 (driver?) >> Kernel panic - not syncing: VFS: Unable to mount root fs on >> unknown-block(31,1) >> [<c00235e8>] (unwind_backtrace+0x0/0xdc) from [<c01c78a4>] >> (panic+0x34/0x120) >> [<c01c78a4>] (panic+0x34/0x120) from [<c0008dd4>] >> (mount_block_root+0x25c/0x2b4) >> [<c0008dd4>] (mount_block_root+0x25c/0x2b4) from [<c0008fc4>] >> (prepare_namespace+0x12c/0x18c) >> [<c0008fc4>] (prepare_namespace+0x12c/0x18c) from [<c0008424>] >> (kernel_init+0xd4/0x10c) >> [<c0008424>] (kernel_init+0xd4/0x10c) from [<c001f85c>] >> (kernel_thread_exit+0x0/0x8) >> >> >> >> ------------------------------------------------------------------------------ >> 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 > |
From: Ash C. <as...@gu...> - 2010-03-17 19:07:36
|
Hi Jim, The new kernel should theoretically work on an old Verdex board--the processor is the same as that used on the VerdexPRO boards. No guarantees though ;-) I see no reason why the microSD wouldn't work but, as a quick test, boot into U-Boot and see if you can successfully do a 'mmcinit' with an appropriately formatted microSD card inserted. I'd be curious to know how the new kernel works for you if you do try it so please post back. -Ash On Wed, Mar 17, 2010 at 11:51 AM, Jim Doutt <jd...@wh...> wrote: > > > I have an older Verdex XL6P with an additional piggyback board containing > ethernet and microSD. > > 1) Can one boot off a microSD card with this configuration (or only with > the newer Verdex which has the microSD on the main board?) > > > 2) Are the newer images for the Verdex compatible with this XL6P board? > > > > > > > Ash Charles wrote: > > Hi Grahame, > > The new kernel is larger than 1MB so attempting to write it into Flash > memory (as you did with the katinstall 100000) command will fail. I > haven't published an updated version of U-Boot with corrected flash > partitions. If you need this immediately, let me know and I'll push > out what I have. > > For now, the recommended way to try the kernel is to load it from a > MMC/microSD card as the kernel never needs to be written to flash but > can instead be loaded directly into RAM. I think loading off a memory > card is setup as the default action in our U-Boot so it'll > automatically boot into the new kernel if you have the card installed > at boot. > > HTH, > > Ash > > On Mon, Mar 15, 2010 at 10:28 PM, Grahame Jordan <gb...@th...> > wrote: > > > Hi, > > I have followed the instructions on > http://www.gumstix.net/wiki/index.php?title=Verdex_Git_Repository accept > I am putting it on flash. > Below is the output I get. Am I missing a driver in the kernel? > > Thanks > > Grahame Jordan > > > GUM> copy_kernel_flash(): katinstall 100000 - > OK > > katload > 100000 > > Copying kernel to 0xa2000000 from 0x00f00000 (length > 0x00100000)...done > > GUM> copy_kernel_flash(): katload 100000 - > OK > > set_environment_variables(): > > boot_new_image() > > bootm > > ## Booting image at a2000000 > ... > > Image Name: > Angstrom/2.6.31/gumstix-verdex > > Image Type: ARM Linux Kernel Image > (uncompressed) > > Data Size: 1290368 Bytes = 1.2 > MB > > Load Address: > a0008000 > > Entry Point: > a0008000 > > OK > > > > Starting kernel > ... > > > > Uncompressing > Linux.................................................................................. > done, booting the > kernel. > > Linux version 2.6.31 (gjordan@bwing) (gcc version 4.3.3 (GCC) ) #1 Tue > Mar 16 14:46:24 EST > 2010 > > CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE), > cr=0000397f > > CPU: VIVT data cache, VIVT instruction > cache > > Machine: Gumstix > verdex > > Memory policy: ECC disabled, Data cache > writeback > > Run Mode clock: 208.00MHz > (*16) > > Turbo Mode clock: 416.00MHz (*2.0, > active) > > Memory clock: 104.00MHz > (/2) > > System bus clock: > 104.00MHz > > Built 1 zonelists in Zone order, mobility grouping on. Total pages: > 16256 > > Kernel command line: console=ttyS0,115200n8 root=1f01 rootfstype=jffs2 > reboot=cold,hard,geserial=1345987 > > PID hash table entries: 256 (order: 8, 1024 > bytes) > > Dentry cache hash table entries: 8192 (order: 3, 32768 > bytes) > > Inode-cache hash table entries: 4096 (order: 2, 16384 > bytes) > > Memory: 64MB = 64MB > total > > Memory: 62248KB available (2212K code, 252K data, 88K init, 0K > highmem) > > NR_IRQS:192 > > Console: colour dummy device > 80x30 > > Calibrating delay loop... 415.33 BogoMIPS > (lpj=2076672) > > Mount-cache hash table entries: > 512 > > CPU: Testing write buffer coherency: > ok > > NET: Registered protocol family > 16 > > Gumstix verdex udc is > disabled > > Initializing Gumstix verdex > i2c > > Initializing Gumstix verdex > smsc911x > > Initializing Gumstix verdex > pcmcia > > Not netCF-vx board: pcmcia using newer GPIO > configuration > > CPLD responded with: > ff > > found 1 CF slots > Initializing Gumstix verdex FB info > Initializing Gumstix platform_add_devices > bio: create slab <bio-0> at 0 > NET: Registered protocol family 2 > IP route cache hash table entries: 1024 (order: 0, 4096 bytes) > TCP established hash table entries: 2048 (order: 2, 16384 bytes) > TCP bind hash table entries: 2048 (order: 1, 8192 bytes) > TCP: Hash tables configured (established 2048 bind 2048) > TCP reno registered > NET: Registered protocol family 1 > msgmni has been set to 121 > alg: No test for stdrng (krng) > Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) > io scheduler noop registered > io scheduler cfq registered (default) > Console: switching to colour frame buffer device 80x24 > pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 22) is a FFUART > console [ttyS0] enabled > pxa2xx-uart.1: ttyS1 at MMIO 0x40200000 (irq = 21) is a BTUART > pxa2xx-uart.2: ttyS2 at MMIO 0x40700000 (irq = 20) is a STUART > Probing Gumstix Flash ROM at physical address 0x00000000 (16-bit bankwidth) > Gumstix Flash ROM: Found 1 x16 devices at 0x0 in 16-bit bank > Intel/Sharp Extended Query Table at 0x010A > Intel/Sharp Extended Query Table at 0x010A > Intel/Sharp Extended Query Table at 0x010A > Intel/Sharp Extended Query Table at 0x010A > Intel/Sharp Extended Query Table at 0x010A > Using buffer write method > Using auto-unlock on power-up/resume > cfi_cmdset_0001: Erase suspend on write enabled > Using static partitions on Gumstix Flash ROM > Creating 3 MTD partitions on "Gumstix Flash ROM": > 0x000000000000-0x000000040000 : "Bootloader" > 0x000000040000-0x000000f00000 : "RootFS" > 0x000000f00000-0x000001000000 : "Kernel" > pxa-rtc pxa-rtc: rtc core: registered pxa-rtc as rtc0 > TCP cubic registered > NET: Registered protocol family 17 > XScale iWMMXt coprocessor detected. > pxa-rtc pxa-rtc: setting system clock to 2000-01-01 00:14:49 UTC (946685689) > VFS: Cannot open root device "1f01" or unknown-block(31,1) > Please append a correct "root=" boot option; here are the available > partitions: > 1f00 256 mtdblock0 (driver?) > 1f01 15104 mtdblock1 (driver?) > 1f02 1024 mtdblock2 (driver?) > Kernel panic - not syncing: VFS: Unable to mount root fs on > unknown-block(31,1) > [<c00235e8>] (unwind_backtrace+0x0/0xdc) from [<c01c78a4>] > (panic+0x34/0x120) > [<c01c78a4>] (panic+0x34/0x120) from [<c0008dd4>] > (mount_block_root+0x25c/0x2b4) > [<c0008dd4>] (mount_block_root+0x25c/0x2b4) from [<c0008fc4>] > (prepare_namespace+0x12c/0x18c) > [<c0008fc4>] (prepare_namespace+0x12c/0x18c) from [<c0008424>] > (kernel_init+0xd4/0x10c) > [<c0008424>] (kernel_init+0xd4/0x10c) from [<c001f85c>] > (kernel_thread_exit+0x0/0x8) > > > > ------------------------------------------------------------------------------ > 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 > > > ------------------------------------------------------------------------------ > 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-03 20:06:35
|
Hi Connie, I don't recognize these particular errors. Google suggested that this is caused by a bad partition. In a previous e-mail you mentioned you formatted using FAT16 and Ext2 rather than FAT32 and Ext3: what was your motivation for this change? Perhaps trying a reformat of your Ext2 partition to Ext3 or a new card if you have one handy would help track down the issue? -Ash On Wed, Mar 3, 2010 at 7:58 AM, Connie C <cci...@um...> wrote: > > Hi Ash, > > Thanks for the help. I tried the command $sudo tar -xzf > /home/oeuser/verdex-oe/tmp/deploy/glibc/images/gumstix-verdex/Angstrom-verdex-console-image-glibc-ipk-2009.X-test-20100227-gumstix-verdex.rootfs.tar.gz > -C /media/card > > and got the bunch of errors I seem to keep getting. A sample of what they > all look like: > > tar: ./boot: Cannot mkdir: Input/output error > tar: ./boot/uImage: Cannot create symlink to `uImage-2.6.31': No such file > or directory > tar: ./lib: Cannot mkdir: Input/output error > tar: ./lib/ld-linux.so.3: Cannot create symlink to `ld-2.9.so': No such file > or directory > tar: ./lib/libproc-3.2.7.so: Cannot open: No such file or directory > tar: ./lib/libc-2.9.so: Cannot open: No such file or directory > tar: ./lib/libanl.so.1: Cannot create symlink to `libanl-2.9.so': No such > file or directory > tar: ./lib/librt-2.9.so: Cannot open: No such file or directory > tar: ./lib/libnss_files-2.9.so: Cannot open: No such file or directory > tar: ./lib/librt.so.1: Cannot create symlink to `librt-2.9.so': No such file > or directory > > same with ./sbin, ./lib, ./etc, ./tmp, and ./mnt > after the tar, I have > oeuser@SG1:/media/card$ ls > bin boot dev home linuxrc lost+found media proc sys usr var > with linuxrc a broken link. > > Thanks, > > Connie > > Ash Charles-2 wrote: >> >> Hi Connie, >> >> Do you have superuser access when extracting the root file system? >> Say Ext2|Ext3 partition is at /media/card_ext and your root filesystem >> named 'verdex-console-image-verdex.tar.gz' is in the current >> directory. >> Does this command fail? >> $ sudo tar -xzf verdex-console-image-verdex.tar.gz -C /media/card_ext/ >> >> The reason the documentation notes the step to be dangerous is because >> you are extracting a root filesystem. If you neglect the -C option or >> accidentally extract to '/', you could overwrite important sections of >> your own machine! >> >> -Ash >> >> On Tue, Mar 2, 2010 at 2:41 PM, Connie C <cci...@um...> wrote: >>> >>> Hi all, (again) >>> >>> So very happy about successfully bitbaking the 2.6.31 kernel. However, I >>> seem to having issues extracting the rootfs from the tarball. I >>> partitioned >>> my 2Gb microsd card yesterday according to >>> http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Creating-a-bootable-microSD-card/111.html >>> >>> Except with a FAT16 partition and .ext2 partition >>> and I put gumstix-factory.script and uImage in the FAT partition and >>> tried >>> to unpack the .tar.gz in the .ext2 partition. Trying to upack to tarball >>> fails. I've also tried to extract single files/folders from the tarball >>> into other locations on my desktop and card. Some of the folders work >>> succesfully and can be extracted. However, some, like mnt, will not >>> extract. (this is to both the sd card and to a random folder on my >>> desktop)(I did also read : The final step is to untar your desired rootfs >>> onto the ext3 partition that you created above. >>> Note that this step can be dangerous. You do not want to untar your Overo >>> rootfs onto your development machine - be careful! and so am only doing >>> individual files and then deleting them) >>> >>> I used fdsk for the partitioning. I thought it might be how I >>> partitioned >>> the card at first and ran dmsg and got a few types of errors: >>> [687450.710992] attempt to access beyond end of device >>> [687450.710996] sdc: rw=0, want=4012501, limit=3842048 >>> [687451.119556] EXT2-fs error (device sdc2): read_inode_bitmap: Cannot >>> read >>> inode bitmap - block_group = 15, inode_bitmap = 491521 >>> >>> [686293.686071] sdc: rw=1, want=3848813, limit=3842048 >>> [686293.686074] attempt to access beyond end of device >>> >>> [686312.717664] EXT2-fs error (device sdc2): ext2_readdir: bad page in >>> #109313 >>> >>> I have gone back through the partitioning instructions several times and >>> I >>> think my card has been done successfully. (I can upload the transcript >>> for >>> the session) especially since I cant remove some of the files from the >>> tarball at all. >>> >>> Thanks! >>> >>> Connie C. >>> >>> >>> -- >>> View this message in context: >>> http://old.nabble.com/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27762177.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/Bitbaking-New-Kernel-2.6.31-for-Verdex-tp27722745p27769993.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 > |