From: Vikram K. <vk...@re...> - 2007-08-22 16:59:50
|
Folks Today, I loaded the gumstix with a new rootfs image after having added some kernel modules as well as other packages. I used Kermit, and the transfer to the gumstix, the protect on the boot sectors, erasing of the old filesystem, and commit of the new filesystem went on without a hitch. After that, I performed a "boot" at the GUM> prompt Nothing abnormal occured, except the following message: ==== Starting Rendezvous: Gumstix Flash ROM: buffer write error (status 0xd0) Write clean marker to block at 0x00780000 failed: -22 ==== The /var/log/messages terms the buffer write error as a "user.err" amd the failure of the write clean marker as a "user.warn" After that, the connex proceeded to boot normally. All modules and packages I had added are there (and hopefully will work fine). I had performed two other complete loads yesterday, and this never happened. Should I be concerned ? Will repeated boots worsen this situation ? I have not performed a power off reset as yet. Are there some diagnostics I can run to see why this occured and whether it will occur again ? Any pointers will be welcome Vikram |
From: Vikram K. <vk...@re...> - 2007-08-22 19:53:04
|
Apart from the Flash ROM: buffer write error (or because of it), I also see that all the modules are not loaded onto the gumstix when I load a new image The extra modules I want (iptable_filter.ko, iptable_mangle.ko, and others), appear in /lib/modules/2.6.18gum/kernel/net/ipv4/filter but the cfio.ko in /lib/modules/2.6.18gum/kernel/drivers/pcmcia and the mcf25.ko in /lib/modules/2.6.18gum/kernel/drivers/net/wireless are missing !!! Is there a limit on how many modules can be in the rootfs image ? The /dev/mtdblock1 is 3.9M used (25%) with the new image and about 23% with the vanilla image. The rootfs file itself is 3.1M for the vanilla case and 3.3M for the custom case The Flash ROM error occurs on each boot. But when I replace the new image with the vanilla image, there is no Flash ROM error. FYI, my customization is very very simple. I just added the NETFILTER (y) and NETFILTER_NETLINK (m) and NETFILTER_XT_..(m) and CONFIG_IP_NF_.. (m) in the kernel customization I see a reference to cfio and mcf25 in the package/wifistix directory. But the BR2_PACKAGE_CF8385 is set to 'y' in my .config file. Please help !!! Is there a way to check whether the rootfs file has all the packages one desires ? The make is completing properly without any errors regards.. Vikram On Wed, 22 Aug 2007, Vikram KAUL wrote: vkaul>Date: Wed, 22 Aug 2007 12:59:44 -0400 (Eastern Daylight Time) vkaul>From: Vikram KAUL <vk...@re...> vkaul>Reply-To: General mailing list for gumstix users. vkaul> <gum...@li...> vkaul>To: gum...@li... vkaul>Subject: [Gumstix-users] Flash ROM: buffer write error (0xd0) vkaul> vkaul> vkaul>Folks vkaul> vkaul>Today, I loaded the gumstix with a new rootfs image after having added vkaul>some kernel modules as well as other packages. vkaul> vkaul>I used Kermit, and the transfer to the gumstix, the protect on the boot vkaul>sectors, erasing of the old filesystem, and commit of the new filesystem vkaul>went on without a hitch. After that, I performed a "boot" at the GUM> vkaul>prompt vkaul> vkaul>Nothing abnormal occured, except the following message: vkaul> vkaul>==== vkaul>Starting Rendezvous: Gumstix Flash ROM: buffer write error (status 0xd0) vkaul>Write clean marker to block at 0x00780000 failed: -22 vkaul>==== vkaul>The /var/log/messages terms the buffer write error as a "user.err" amd the vkaul>failure of the write clean marker as a "user.warn" vkaul> vkaul> vkaul>After that, the connex proceeded to boot normally. vkaul>All modules and packages I had added are there (and hopefully will work vkaul>fine). I had performed two other complete loads yesterday, and this never vkaul>happened. vkaul> vkaul>Should I be concerned ? Will repeated boots worsen this situation ? vkaul> vkaul>I have not performed a power off reset as yet. Are there some diagnostics vkaul>I can run to see why this occured and whether it will occur again ? vkaul> vkaul>Any pointers will be welcome vkaul> vkaul>Vikram vkaul> vkaul> vkaul>------------------------------------------------------------------------- vkaul>This SF.net email is sponsored by: Splunk Inc. vkaul>Still grepping through log files to find problems? Stop. vkaul>Now Search log events and configuration files using AJAX and a browser. vkaul>Download your FREE copy of Splunk now >> http://get.splunk.com/ vkaul>_______________________________________________ vkaul>gumstix-users mailing list vkaul>gum...@li... vkaul>https://lists.sourceforge.net/lists/listinfo/gumstix-users vkaul> |
From: Chris D. <chr...@gm...> - 2007-08-22 20:21:58
|
Hi Vikram, > Apart from the Flash ROM: buffer write error (or because of it), I also > see that all the modules are not loaded onto the gumstix when I load a new > image > > The extra modules I want (iptable_filter.ko, iptable_mangle.ko, and > others), appear in /lib/modules/2.6.18gum/kernel/net/ipv4/filter > > but the cfio.ko in /lib/modules/2.6.18gum/kernel/drivers/pcmcia > and the mcf25.ko in /lib/modules/2.6.18gum/kernel/drivers/net/wireless > > are missing !! I'm not sure about your buffer write error, but I'm pretty sure that the error you're seeing with the wireless modules not being installed is due to a bug in older versions of the buildroot (I think it is fixed now?). When the marvel wireless modules are installed the makefile creates build_arm_nofpu/.cf8385 . Later on if you "rm -fr build_arm_nofpu/root" and then re-run make to build a new image the marvel makefile would see the .cf8385 file, think it had already installed itself, and not install the modules to the new image (it also doesn't then modify the network init script too). So the workaround is when you issue a "rm -fr build_arm_nofpu/root" follow it with a "rm build_arm_nofpu/.cf8385" before you run make. Of course if you didn't ever get rid of the build_arm_nofpu/root directory, then this probably wouldn't apply > Is there a limit on how many modules can be in the rootfs image ? Only limit is storage size on the gumstix itself > I see a reference to cfio and mcf25 in the package/wifistix directory. > > But the BR2_PACKAGE_CF8385 is set to 'y' in my .config file. See above > Is there a way to check whether the rootfs file has all the packages one > desires ? The make is completing properly without any errors Yep. After you run make have a look in the <gumstix-buildroot>/build_arm_nofpu/root directory - that is exactly what your jffs2 image is. Placing files inside of that directory and then re-running "make" on the buildroot will make a new jffs2 filesystem image that includes those new files. Chris |
From: Vikram K. <vk...@re...> - 2007-08-22 23:43:41
|
Hi Chris and others, My comments interspersed.. chris.>I'm not sure about your buffer write error, but I'm pretty sure that chris.>the error you're seeing with the wireless modules not being installed chris.>is due to a bug in older versions of the buildroot (I think it is chris.>fixed now?). When the marvel wireless modules are installed the chris.>makefile creates build_arm_nofpu/.cf8385 . Later on if you "rm -fr chris.>build_arm_nofpu/root" and then re-run make to build a new image the chris.>marvel makefile would see the .cf8385 file, think it had already chris.>installed itself, and not install the modules to the new image (it chris.>also doesn't then modify the network init script too). So the chris.>workaround is when you issue a "rm -fr build_arm_nofpu/root" follow it chris.>with a "rm build_arm_nofpu/.cf8385" before you run make. The .cf8385 is in <gumstix-buildroot>/build_arm_nofpu/root/lib/modules alongside the kernel directory. I confirmed that in the vanilla image that boots properly. But I understand your point about how the compilation occurs According to the http://docwiki.gumstix.org/Buildroot which also refers to what you have suggested; that is to be done only when removing one or more packages. But I am merely adding two packages. Not removing anything. BTW, If the location is indeed in root/lib/modules, then the wiki should be changed ? A diff between the <gumstix-buildroot>/.config for the vanilla and my custom image is only: < # BR2_PACKAGE_IPTABLES is not set > BR2_PACKAGE_IPTABLES=y < # BR2_PACKAGE_LIBPCAP is not set > BR2_PACKAGE_LIBPCAP=y The differences between the <gumstix-buildroot>/build_arm_nofpu/linux-2.6.18gum/.config for the vanilla and my custom image are more extensive; but just additions of the NETFILTER stuff. And no deletions. For the kernel forced recompile, I followed the wiki's directions and removed <gumstix-buildroot>/build_arm_nofpu/linux-2.6.18gum/arch/arm/boot/compressed/vmlinux chris.>Of course if you didn't ever get rid of the build_arm_nofpu/root chris.>directory, then this probably wouldn't apply I never did. I merely added two packages. And they appear alright on the gumstix. However, the marvell stuff disappears chris.>> Is there a way to check whether the rootfs file has all the packages one chris.>> desires ? The make is completing properly without any errors chris.>Yep. After you run make have a look in the chris.><gumstix-buildroot>/build_arm_nofpu/root directory - that is exactly chris.>what your jffs2 image is. Placing files inside of that directory and chris.>then re-running "make" on the buildroot will make a new jffs2co chris.>filesystem image that includes those new files. I can't issue a 'ls' on <gumstix-buildroot>/build_arm_nofpu/root/lib In there, in the modules/2.6.18gum/kernel would be the modules When I issue a 'find . -print', it does _NOT_ show the cfio.ko which is supposed to be in lib/modules/2.6.18gum/kernel/drivers/pcmcia Nor does it show mcf25.ko in /lib/modules/2.6.18gum/kernel/drivers/net/wireless Despite not having removed any module, (see the differences in the .config), I will do the following: 1. Remove the vmlinux as stated in the wiki 2. Remove <gumstix-buildroot>/build_arm_nofpu/root This automatically removes root/lib/modules/.cf8385 Of course, this will take ages to recompile ? Because everything probably will be built from scratch, including the kernel. But if it works, I will be happy. I will report my findings Thanks for the help Vikram |