From: Harry J M. <hj...@ec...> - 2008-01-29 12:10:22
|
A few problems I've found since switching to OpenEmbedded: My old ROK Bluetooth module (on Basix 400) doesn't work out of the box. To make it work it needs a start speed of 57600 and GPIO7 must be set high in /etc/init.d/bluetooth . /proc/gpio is somehow overwritten by the UCB1400 GPIO entries during boot, removing the original ones. ls /proc shows *two* gpio directories. The udev init script fails if the root filesystem is initramfs, which I'm using to get round the 4MB flash limit. Bind mounts don't work with initramfs. I am getting around this by letting /dev stay on / instead of mounting a tmpfs there, by hacking fstab and the udev script. -- | Harry Mason | .------------. | .___, |"Whatever you do will be | | University of | | hjm200 @ | | ___('v')___ | insignificant. However, | | Southampton | | zepler.net | | `"-\._./-"' | it is vitally important | | England | '------------' | hjm ^ ^ | that you do it." Gandhi | |
From: Steve S. <sa...@gm...> - 2008-01-29 14:21:41
|
Thanks for the feedback! I'll put some comments in the bluetooth init on how to modify it for old ROK modules. I'll look into the GPIO issue. What revision of OE are you currently using? Steve On Jan 29, 2008 4:10 AM, Harry J Mason <hj...@ec...> wrote: > A few problems I've found since switching to OpenEmbedded: > > My old ROK Bluetooth module (on Basix 400) doesn't work out of the box. > To make it work it needs a start speed of 57600 and GPIO7 must be set high > in /etc/init.d/bluetooth . > > /proc/gpio is somehow overwritten by the UCB1400 GPIO entries during boot, > removing the original ones. ls /proc shows *two* gpio directories. > > The udev init script fails if the root filesystem is initramfs, which I'm > using to get round the 4MB flash limit. Bind mounts don't work with initramfs. > I am getting around this by letting /dev stay on / instead of mounting a > tmpfs there, by hacking fstab and the udev script. > > -- > | Harry Mason | .------------. | .___, |"Whatever you do will be | > | University of | | hjm200 @ | | ___('v')___ | insignificant. However, | > | Southampton | | zepler.net | | `"-\._./-"' | it is vitally important | > | England | '------------' | hjm ^ ^ | that you do it." Gandhi | > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Harry J M. <hj...@ec...> - 2008-01-29 15:13:05
|
On Tue, 29 Jan 2008, Steve Sakoman wrote: > On Jan 29, 2008 4:10 AM, Harry J Mason <hj...@ec...> wrote: > >> /proc/gpio is somehow overwritten by the UCB1400 GPIO entries during boot, >> removing the original ones. ls /proc shows *two* gpio directories. > > I'll look into the GPIO issue. What revision of OE are you currently using? Revision 172 of https://gumstix.svn.sourceforge.net/svnroot/gumstix/trunk Now I'm having trouble getting the image to include the appropriate modules. I've edited user.collection/conf/machine/gumstix-custom-connex.conf and changed MACHINE_FEATURES to mmc instead of pcmcia, but the image still only includes pcmcia. Do I need to explicitly rebuild something? Cheers for your help. -- | Harry Mason | .------------. | .___, |"Whatever you do will be | | University of | | hjm200 @ | | ___('v')___ | insignificant. However, | | Southampton | | zepler.net | | `"-\._./-"' | it is vitally important | | England | '------------' | hjm ^ ^ | that you do it." Gandhi | |
From: Steve S. <sa...@gm...> - 2008-01-29 15:24:13
|
Harry, > Do I need to explicitly rebuild something? Any time you change MACHINE_FEATURES you should: bitbake -c rebuild task-base-gumstix bitbake -c rebuild gumstix-basic-image Steve On Jan 29, 2008 7:12 AM, Harry J Mason <hj...@ec...> wrote: > On Tue, 29 Jan 2008, Steve Sakoman wrote: > > > On Jan 29, 2008 4:10 AM, Harry J Mason <hj...@ec...> wrote: > > > >> /proc/gpio is somehow overwritten by the UCB1400 GPIO entries during boot, > >> removing the original ones. ls /proc shows *two* gpio directories. > > > > I'll look into the GPIO issue. What revision of OE are you currently using? > > Revision 172 of https://gumstix.svn.sourceforge.net/svnroot/gumstix/trunk > > Now I'm having trouble getting the image to include the appropriate modules. > I've edited user.collection/conf/machine/gumstix-custom-connex.conf and > changed MACHINE_FEATURES to mmc instead of pcmcia, but the image still only > includes pcmcia. Do I need to explicitly rebuild something? > > Cheers for your help. > > -- > > | Harry Mason | .------------. | .___, |"Whatever you do will be | > | University of | | hjm200 @ | | ___('v')___ | insignificant. However, | > | Southampton | | zepler.net | | `"-\._./-"' | it is vitally important | > | England | '------------' | hjm ^ ^ | that you do it." Gandhi | > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Michael A. N. <ma...@ho...> - 2008-01-29 15:41:51
|
I noticed that Harry mentioned that the initramfs strategy was being used to circumvent the problems of a 4MB flash. While my strategy was initially to reduce the file system to below the 3MB (uboot 1.2.0) restriction, the more elegant solution would be to implement the initramfs build with the MACHINE_FEATURES detects the 4MB Flash. Is this a reasonable strategy or is the incidence of the 4MB flash gumstix so small that it pursuing an obsolete path? Mike -----Original Message----- From: gum...@li... [mailto:gum...@li...] On Behalf Of Steve Sakoman Sent: Tuesday, January 29, 2008 9:24 AM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] OE: ROK Bluetooth module, /proc/gpio, udev Harry, > Do I need to explicitly rebuild something? Any time you change MACHINE_FEATURES you should: bitbake -c rebuild task-base-gumstix bitbake -c rebuild gumstix-basic-image Steve On Jan 29, 2008 7:12 AM, Harry J Mason <hj...@ec...> wrote: > On Tue, 29 Jan 2008, Steve Sakoman wrote: > > > On Jan 29, 2008 4:10 AM, Harry J Mason <hj...@ec...> wrote: > > > >> /proc/gpio is somehow overwritten by the UCB1400 GPIO entries during boot, > >> removing the original ones. ls /proc shows *two* gpio directories. > > > > I'll look into the GPIO issue. What revision of OE are you currently using? > > Revision 172 of https://gumstix.svn.sourceforge.net/svnroot/gumstix/trunk > > Now I'm having trouble getting the image to include the appropriate modules. > I've edited user.collection/conf/machine/gumstix-custom-connex.conf and > changed MACHINE_FEATURES to mmc instead of pcmcia, but the image still only > includes pcmcia. Do I need to explicitly rebuild something? > > Cheers for your help. > > -- > > | Harry Mason | .------------. | .___, |"Whatever you do will be | > | University of | | hjm200 @ | | ___('v')___ | insignificant. However, | > | Southampton | | zepler.net | | `"-\._./-"' | it is vitally important | > | England | '------------' | hjm ^ ^ | that you do it." Gandhi | > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Harry J M. <hj...@ec...> - 2008-01-30 09:39:26
|
On Tue, 29 Jan 2008, Michael A. Nixon wrote: > I noticed that Harry mentioned that the initramfs strategy was being used to > circumvent the problems of a 4MB flash. While my strategy was initially to > reduce the file system to below the 3MB (uboot 1.2.0) restriction, the more > elegant solution would be to implement the initramfs build with the > MACHINE_FEATURES detects the 4MB Flash. > > Is this a reasonable strategy or is the incidence of the 4MB flash gumstix > so small that it pursuing an obsolete path? What I'm currently doing is building a cpio.gz image instead of jffs2, and passing it to U-boot on the MMC card. The entire / is therefore in RAM. While this does avoid the 4MB limit and repeated reflashing, it is pretty wasteful of RAM. I'm currently looking at making a minimal initramfs and mounting a full / from MMC instead. This is more complicated but saves RAM, boots quicker, makes / persistent, cooperates better with the udev init script from OE, and lets / grow beyond the size of RAM. The one advantage of initramfs over loopback is that you can remove the MMC after boot if you need to. -- | Harry Mason | .------------. | .___, |"Whatever you do will be | | University of | | hjm200 @ | | ___('v')___ | insignificant. However, | | Southampton | | zepler.net | | `"-\._./-"' | it is vitally important | | England | '------------' | hjm ^ ^ | that you do it." Gandhi | |
From: Koen K. <ko...@do...> - 2008-01-30 11:27:05
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Harry J Mason schreef: | On Tue, 29 Jan 2008, Michael A. Nixon wrote: | |> I noticed that Harry mentioned that the initramfs strategy was being used to |> circumvent the problems of a 4MB flash. While my strategy was initially to |> reduce the file system to below the 3MB (uboot 1.2.0) restriction, the more |> elegant solution would be to implement the initramfs build with the |> MACHINE_FEATURES detects the 4MB Flash. |> |> Is this a reasonable strategy or is the incidence of the 4MB flash gumstix |> so small that it pursuing an obsolete path? | | What I'm currently doing is building a cpio.gz image instead of jffs2, and | passing it to U-boot on the MMC card. The entire / is therefore in RAM. | While this does avoid the 4MB limit and repeated reflashing, it is pretty | wasteful of RAM. I'm currently looking at making a minimal initramfs and | mounting a full / from MMC instead. What's stopping you from booting directly from SD with uboot? I'm doing that on various uboot based boards, and it works great. regards, Koen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHoF7/MkyGM64RGpERAvWaAJ9LZwCQVsctPjoshnxvjIduEH8+WACgjjF2 6a6UXaJRSNi82x6u9ioR3aU= =5gDg -----END PGP SIGNATURE----- |
From: Harry J M. <hj...@ec...> - 2008-01-30 11:42:39
|
On Wed, 30 Jan 2008, Koen Kooi wrote: > Harry J Mason schreef: > | What I'm currently doing is building a cpio.gz image instead of jffs2, and > | passing it to U-boot on the MMC card. The entire / is therefore in RAM. > | While this does avoid the 4MB limit and repeated reflashing, it is pretty > | wasteful of RAM. I'm currently looking at making a minimal initramfs and > | mounting a full / from MMC instead. > > What's stopping you from booting directly from SD with uboot? I'm doing > that on various uboot based boards, and it works great. I want the root filesystem to be mounted loopback from a file on the MMC, because it's more convenient to copy a file than a whole filesystem and doesn't need root. Also it means the rest of the space on the MMC is free for use. You can't tell the kernel that its root filesystem is on loopback without some kind of ramdisk. -- | Harry Mason | .------------. | .___, |"Whatever you do will be | | University of | | hjm200 @ | | ___('v')___ | insignificant. However, | | Southampton | | zepler.net | | `"-\._./-"' | it is vitally important | | England | '------------' | hjm ^ ^ | that you do it." Gandhi | |
From: Dave H. <dhy...@gm...> - 2008-01-29 14:57:32
|
HI guys, > I'll look into the GPIO issue. What revision of OE are you currently using? This is actually a known issue, caused by loading both proc_gpio and the sound driver. I had suggested a patch for Craig a long time ago, but it looks like it never made it in. <http://thread.gmane.org/gmane.linux.distributions.gumstix.general/14821/focus=14854> Actually looking through the archives, I see Andre Gava also proposed a patch here: <http://thread.gmane.org/gmane.linux.distributions.gumstix.general/14593/focus=14640> Andre's patch causes /proc/gpio-ac97 to be used instead of /proc/gpio. My suggestion allows /proc/gpio to be used for both. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Steve S. <sa...@gm...> - 2008-01-29 15:25:24
|
Dave, Thanks for pointing this out. I appreciate it a lot. I'll incorporate your patch this morning. Steve On Jan 29, 2008 6:57 AM, Dave Hylands <dhy...@gm...> wrote: > HI guys, > > > I'll look into the GPIO issue. What revision of OE are you currently using? > > This is actually a known issue, caused by loading both proc_gpio and > the sound driver. I had suggested a patch for Craig a long time ago, > but it looks like it never made it in. > <http://thread.gmane.org/gmane.linux.distributions.gumstix.general/14821/focus=14854> > > Actually looking through the archives, I see Andre Gava also proposed > a patch here: > <http://thread.gmane.org/gmane.linux.distributions.gumstix.general/14593/focus=14640> > > Andre's patch causes /proc/gpio-ac97 to be used instead of /proc/gpio. > > My suggestion allows /proc/gpio to be used for both. > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Dave H. <dhy...@gm...> - 2008-01-29 15:32:35
|
Hi Steve, On Jan 29, 2008 7:25 AM, Steve Sakoman <sa...@gm...> wrote: > Dave, > > Thanks for pointing this out. I appreciate it a lot. > > I'll incorporate your patch this morning. I think that for my proposed patch to work properly, it has to be done to both the proc_gpio module and the sound driver module. This would allow them to be loaded/unloaded in an arbitrary order. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Steve S. <sa...@gm...> - 2008-01-29 15:54:20
|
Dave, I'm looking at the code in ac97_patch.c and it seems to be different that that you discuss in your patch proposal: I see: proc_gpio_parent = proc_mkdir("gpio", NULL); if(!proc_gpio_parent) return 0; for(i=0; i < NUM_GPIO_LINES; i++) { proc_gpios[i] = create_proc_entry(gpio_summaries[i].name, 0644, proc_gpio_parent); instead of: proc_gpio_parent = create_proc_entry("gpio", S_IFDIR | S_IRUGO | S_IXUGO, NULL); Just want to check and make sure we are talking about the same file before I spend too much time on this :-) Steve On Jan 29, 2008 7:32 AM, Dave Hylands <dhy...@gm...> wrote: > Hi Steve, > > On Jan 29, 2008 7:25 AM, Steve Sakoman <sa...@gm...> wrote: > > Dave, > > > > Thanks for pointing this out. I appreciate it a lot. > > > > I'll incorporate your patch this morning. > > I think that for my proposed patch to work properly, it has to be done > to both the proc_gpio module and the sound driver module. This would > allow them to be loaded/unloaded in an arbitrary order. > > -- > > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Dave H. <dhy...@gm...> - 2008-01-29 16:03:09
|
HI Steve, > I'm looking at the code in ac97_patch.c and it seems to be different > that that you discuss in your patch proposal: Let me take a look at proc_mkdir and see how/if my proposal might integrate. I think that proc_mkdir may not have existed when I made the proposal. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Steve S. <sa...@gm...> - 2008-01-29 17:38:23
|
Harry, Just to make sure I get it right, could you send me the exact changes you made to your bluetooth init? Thanks, Steve On Jan 29, 2008 4:10 AM, Harry J Mason <hj...@ec...> wrote: > A few problems I've found since switching to OpenEmbedded: > > My old ROK Bluetooth module (on Basix 400) doesn't work out of the box. > To make it work it needs a start speed of 57600 and GPIO7 must be set high > in /etc/init.d/bluetooth . > > /proc/gpio is somehow overwritten by the UCB1400 GPIO entries during boot, > removing the original ones. ls /proc shows *two* gpio directories. > > The udev init script fails if the root filesystem is initramfs, which I'm > using to get round the 4MB flash limit. Bind mounts don't work with initramfs. > I am getting around this by letting /dev stay on / instead of mounting a > tmpfs there, by hacking fstab and the udev script. > > -- > | Harry Mason | .------------. | .___, |"Whatever you do will be | > | University of | | hjm200 @ | | ___('v')___ | insignificant. However, | > | Southampton | | zepler.net | | `"-\._./-"' | it is vitally important | > | England | '------------' | hjm ^ ^ | that you do it." Gandhi | > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Harry J M. <hj...@ec...> - 2008-01-30 09:34:45
|
On Tue, 29 Jan 2008, Steve Sakoman wrote: > On Jan 29, 2008 4:10 AM, Harry J Mason <hj...@ec...> wrote: > >> My old ROK Bluetooth module (on Basix 400) doesn't work out of the box. >> To make it work it needs a start speed of 57600 and GPIO7 must be set high >> in /etc/init.d/bluetooth . > > Just to make sure I get it right, could you send me the exact changes > you made to your bluetooth init? Change HCIATTACH_START_SPEED to 57600 Before this line: echo "AF3 out" > /proc/gpio/GPIO9 add echo "GPIO out set" >/proc/gpio/GPIO7 -- | Harry Mason | .------------. | .___, |"Whatever you do will be | | University of | | hjm200 @ | | ___('v')___ | insignificant. However, | | Southampton | | zepler.net | | `"-\._./-"' | it is vitally important | | England | '------------' | hjm ^ ^ | that you do it." Gandhi | |
From: Steve S. <sa...@gm...> - 2008-01-31 21:03:04
|
Dave, Did you have a chance to look at this any further? Just want to make sure I don't duplicate any work you are doing. Steve On Jan 29, 2008 8:03 AM, Dave Hylands <dhy...@gm...> wrote: > HI Steve, > > > I'm looking at the code in ac97_patch.c and it seems to be different > > that that you discuss in your patch proposal: > > Let me take a look at proc_mkdir and see how/if my proposal might > integrate. I think that proc_mkdir may not have existed when I made > the proposal. > > -- > > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Dave H. <dhy...@gm...> - 2008-01-31 21:15:16
|
Hi Steve, > Did you have a chance to look at this any further? > > Just want to make sure I don't duplicate any work you are doing. As best I can tell, the proc_mkdir is basically just a shortcut for the create_proc_entry. So I'd keep the proc_mkdir and otherwise use the patch. I couldn't find any functions for querying if a particular proc entry actually exists or not (which is what the for loop in the patch is essentially doing). I still haven't had a chance to try the patch to see if it even compiles, but from my perusal of the code, it still looks reasonable. If it does in fact work, it needs to be applied to both the proc_gpio and sound card. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Steve S. <sa...@gm...> - 2008-02-01 17:29:33
|
Dave, > I still haven't had a chance to try the patch to see if it even > compiles, but from my perusal of the code, it still looks reasonable. I get an error when compiling: | sound/pci/ac97/ac97_patch.c: In function 'patch_ucb1400': | sound/pci/ac97/ac97_patch.c:590: error: invalid type argument of '->' | sound/pci/ac97/ac97_patch.c:591: warning: implicit declaration of function 'proc_match' The lines in question (line 590 is the one beginning with "for"): proc_gpio_parent = NULL; for (proc_gpio_parent = proc_root->subdir; proc_gpio_parent; proc_gpio_parent = proc_gpio_parent->next) { if (proc_match(4, "gpio", proc_gpio_parent)) break; } I haven't used the proc stuff before, so I'll go research & try to fix this. Steve On Jan 31, 2008 1:15 PM, Dave Hylands <dhy...@gm...> wrote: > Hi Steve, > > > Did you have a chance to look at this any further? > > > > Just want to make sure I don't duplicate any work you are doing. > > As best I can tell, the proc_mkdir is basically just a shortcut for > the create_proc_entry. So I'd keep the proc_mkdir and otherwise use > the patch. I couldn't find any functions for querying if a particular > proc entry actually exists or not (which is what the for loop in the > patch is essentially doing). > > I still haven't had a chance to try the patch to see if it even > compiles, but from my perusal of the code, it still looks reasonable. > If it does in fact work, it needs to be applied to both the proc_gpio > and sound card. > > -- > > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Dave H. <dhy...@gm...> - 2008-02-01 18:01:02
|
Hi Steve, > > I still haven't had a chance to try the patch to see if it even > > compiles, but from my perusal of the code, it still looks reasonable. > > I get an error when compiling: > > | sound/pci/ac97/ac97_patch.c: In function 'patch_ucb1400': > | sound/pci/ac97/ac97_patch.c:590: error: invalid type argument of '->' > | sound/pci/ac97/ac97_patch.c:591: warning: implicit declaration of > function 'proc_match' > > The lines in question (line 590 is the one beginning with "for"): > > proc_gpio_parent = NULL; > for (proc_gpio_parent = proc_root->subdir; proc_gpio_parent; > proc_gpio_parent = proc_gpio_parent->next) { > if (proc_match(4, "gpio", proc_gpio_parent)) > break; > } > > I haven't used the proc stuff before, so I'll go research & try to fix this. It looks like proc_root is a structure rather than a pointer. So, it needs to be proc_root.subdir rather than proc_root->subdir and proc_match seems to be a static function, so I think it needs to become if (( proc_gpio_parent->namelen == 4 ) && ( memcmp( proc_gpio_parent->name, "gpio", 4 ) == 0 )) -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Steve S. <sa...@gm...> - 2008-02-01 18:29:55
|
Dave, I had just figured that out after looking at proc_fs.h:-) I'm building an image now to test. Thanks for your help! Steve On Feb 1, 2008 10:01 AM, Dave Hylands <dhy...@gm...> wrote: > Hi Steve, > > > > I still haven't had a chance to try the patch to see if it even > > > compiles, but from my perusal of the code, it still looks reasonable. > > > > I get an error when compiling: > > > > | sound/pci/ac97/ac97_patch.c: In function 'patch_ucb1400': > > | sound/pci/ac97/ac97_patch.c:590: error: invalid type argument of '->' > > | sound/pci/ac97/ac97_patch.c:591: warning: implicit declaration of > > function 'proc_match' > > > > The lines in question (line 590 is the one beginning with "for"): > > > > proc_gpio_parent = NULL; > > for (proc_gpio_parent = proc_root->subdir; proc_gpio_parent; > > proc_gpio_parent = proc_gpio_parent->next) { > > if (proc_match(4, "gpio", proc_gpio_parent)) > > break; > > } > > > > I haven't used the proc stuff before, so I'll go research & try to fix this. > > It looks like proc_root is a structure rather than a pointer. > > So, it needs to be proc_root.subdir rather than proc_root->subdir > > and proc_match seems to be a static function, so I think it needs to become > > if (( proc_gpio_parent->namelen == 4 ) && ( memcmp( > proc_gpio_parent->name, "gpio", 4 ) == 0 )) > > -- > > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |