I was getting a bit fed up with my JTAG experiments (2 weeks and
hardly any progress), so I decided to try something a bit easier
starting from this morning.
So I've added GPIO sysfs support to 2.6.30.5, however I need testers,
not only for the basic GPIO functionality, but also to see if the i2c
modules can be layered on top of this to solve the issues people were
previously seeing. I suspect that this will also allow MMC support,
albeit with somewhat slow data rates. If nothing else, it will allow
folk to get/set pins without having to write kernel modules or dicky
little programs like biff-gpio.
If all goes well, I'll try to submit this to LKML.
Google sites has been jerking me around today, but seems
intermittently available. I've added the patch and description of how
to use the functionality here:
> I was getting a bit fed up with my JTAG experiments (2 weeks and
> hardly any progress), so I decided to try something a bit easier
> starting from this morning.
> So I've added GPIO sysfs support to 2.6.30.5, however I need testers,
> not only for the basic GPIO functionality, but also to see if the i2c
> modules can be layered on top of this to solve the issues people were
> previously seeing. I suspect that this will also allow MMC support,
> albeit with somewhat slow data rates. If nothing else, it will allow
> folk to get/set pins without having to write kernel modules or dicky
> little programs like biff-gpio.
> If all goes well, I'll try to submit this to LKML.
> Google sites has been jerking me around today, but seems
> intermittently available. I've added the patch and description of how
> to use the functionality here:
> I was getting a bit fed up with my JTAG experiments (2 weeks and
> hardly any progress), so I decided to try something a bit easier
> starting from this morning.
> So I've added GPIO sysfs support to 2.6.30.5, however I need testers,
> not only for the basic GPIO functionality, but also to see if the i2c
> modules can be layered on top of this to solve the issues people were
> previously seeing. I suspect that this will also allow MMC support,
> albeit with somewhat slow data rates. If nothing else, it will allow
> folk to get/set pins without having to write kernel modules or dicky
> little programs like biff-gpio.
> If all goes well, I'll try to submit this to LKML.
> Google sites has been jerking me around today, but seems
> intermittently available. I've added the patch and description of how
> to use the functionality here:
> On Sat, Aug 29, 2009 at 6:50 PM, biffe...@yahoo.co.uk <
> biffe...@yahoo.co.uk> wrote:
>> I was getting a bit fed up with my JTAG experiments (2 weeks and
>> hardly any progress), so I decided to try something a bit easier
>> starting from this morning.
>> So I've added GPIO sysfs support to 2.6.30.5, however I need testers,
>> not only for the basic GPIO functionality, but also to see if the i2c
>> modules can be layered on top of this to solve the issues people were
>> previously seeing. I suspect that this will also allow MMC support,
>> albeit with somewhat slow data rates. If nothing else, it will allow
>> folk to get/set pins without having to write kernel modules or dicky
>> little programs like biff-gpio.
>> If all goes well, I'll try to submit this to LKML.
>> Google sites has been jerking me around today, but seems
>> intermittently available. I've added the patch and description of how
>> to use the functionality here:
My question, I have the Bifferboard OnFlashSystem up and running with kernel
version 2.6.30.2, will the available patch work or do I really need the
2.6.30.5 ???
Regards,
Nelson.
ps: will test this tonight, will only have access to hardware later (back
from vacations)!
On Mon, Aug 31, 2009 at 2:54 PM, Razvan Dragomirescu <
razvan.dragomire...@gmail.com> wrote:
> Hello again Biff,
> It doesn't appear to work for me, I've applied the patch to 2.6.30.1
> though, not to 2.6.30.5. Everything looks fine, compilation works, then I
> do:
> echo 16 > /sys/class/gpio/export (works fine)
> echo out > /sys/class/gpio/gpio16/direction (also works fine)
>> On Sat, Aug 29, 2009 at 6:50 PM, biffe...@yahoo.co.uk <
>> biffe...@yahoo.co.uk> wrote:
>>> I was getting a bit fed up with my JTAG experiments (2 weeks and
>>> hardly any progress), so I decided to try something a bit easier
>>> starting from this morning.
>>> So I've added GPIO sysfs support to 2.6.30.5, however I need testers,
>>> not only for the basic GPIO functionality, but also to see if the i2c
>>> modules can be layered on top of this to solve the issues people were
>>> previously seeing. I suspect that this will also allow MMC support,
>>> albeit with somewhat slow data rates. If nothing else, it will allow
>>> folk to get/set pins without having to write kernel modules or dicky
>>> little programs like biff-gpio.
>>> If all goes well, I'll try to submit this to LKML.
>>> Google sites has been jerking me around today, but seems
>>> intermittently available. I've added the patch and description of how
>>> to use the functionality here:
I've just uploaded a new version of the patch (v2) today. This
shouldn't make much difference, but you can try that.
In my case, setting the direction to 'out' immediately turns on the
LED.
Is your kernel a clean kernel, could it be you have another driver
accessing GPIO pins?
> > On Sat, Aug 29, 2009 at 6:50 PM, biffe...@yahoo.co.uk <
> > biffe...@yahoo.co.uk> wrote:
> >> I was getting a bit fed up with my JTAG experiments (2 weeks and
> >> hardly any progress), so I decided to try something a bit easier
> >> starting from this morning.
> >> So I've added GPIO sysfs support to 2.6.30.5, however I need testers,
> >> not only for the basic GPIO functionality, but also to see if the i2c
> >> modules can be layered on top of this to solve the issues people were
> >> previously seeing. I suspect that this will also allow MMC support,
> >> albeit with somewhat slow data rates. If nothing else, it will allow
> >> folk to get/set pins without having to write kernel modules or dicky
> >> little programs like biff-gpio.
> >> If all goes well, I'll try to submit this to LKML.
> >> Google sites has been jerking me around today, but seems
> >> intermittently available. I've added the patch and description of how
> >> to use the functionality here:
It seems the patch applies to 2.6.30.1, however using 2.6.30.5 is also
very easy. Simply copy exactly the same initramfs.cpio that you used
with the old kernel and you should get a boot.
On Aug 31, 2:59 pm, Nelson Neves <nelson.s.ne...@gmail.com> wrote:
> My question, I have the Bifferboard OnFlashSystem up and running with kernel
> version 2.6.30.2, will the available patch work or do I really need the
> 2.6.30.5 ???
> Regards,
> Nelson.
> ps: will test this tonight, will only have access to hardware later (back
> from vacations)!
> On Mon, Aug 31, 2009 at 2:54 PM, Razvan Dragomirescu <
> razvan.dragomire...@gmail.com> wrote:
> > Hello again Biff,
> > It doesn't appear to work for me, I've applied the patch to 2.6.30.1
> > though, not to 2.6.30.5. Everything looks fine, compilation works, then I
> > do:
> > echo 16 > /sys/class/gpio/export (works fine)
> > echo out > /sys/class/gpio/gpio16/direction (also works fine)
> >> On Sat, Aug 29, 2009 at 6:50 PM, biffe...@yahoo.co.uk <
> >> biffe...@yahoo.co.uk> wrote:
> >>> I was getting a bit fed up with my JTAG experiments (2 weeks and
> >>> hardly any progress), so I decided to try something a bit easier
> >>> starting from this morning.
> >>> So I've added GPIO sysfs support to 2.6.30.5, however I need testers,
> >>> not only for the basic GPIO functionality, but also to see if the i2c
> >>> modules can be layered on top of this to solve the issues people were
> >>> previously seeing. I suspect that this will also allow MMC support,
> >>> albeit with somewhat slow data rates. If nothing else, it will allow
> >>> folk to get/set pins without having to write kernel modules or dicky
> >>> little programs like biff-gpio.
> >>> If all goes well, I'll try to submit this to LKML.
> >>> Google sites has been jerking me around today, but seems
> >>> intermittently available. I've added the patch and description of how
> >>> to use the functionality here:
My apologies, it works fine, I was just looking at the blue LED instead :(.
BTW, is there any way to control that LED with GPIO? The red LED is not
visible on the outside of the plastic enclosure and it's hard to see of a
user that is just looking at a close enclosure? Can we control the green or
blue LEDs that have holes in the plastic case for them?
> On Aug 31, 2:59 pm, Nelson Neves <nelson.s.ne...@gmail.com> wrote:
> > My question, I have the Bifferboard OnFlashSystem up and running with
> kernel
> > version 2.6.30.2, will the available patch work or do I really need the
> > 2.6.30.5 ???
> > Regards,
> > Nelson.
> > ps: will test this tonight, will only have access to hardware later (back
> > from vacations)!
> > On Mon, Aug 31, 2009 at 2:54 PM, Razvan Dragomirescu <
> > razvan.dragomire...@gmail.com> wrote:
> > > Hello again Biff,
> > > It doesn't appear to work for me, I've applied the patch to 2.6.30.1
> > > though, not to 2.6.30.5. Everything looks fine, compilation works, then
> I
> > > do:
> > > echo 16 > /sys/class/gpio/export (works fine)
> > > echo out > /sys/class/gpio/gpio16/direction (also works fine)
> > >> On Sat, Aug 29, 2009 at 6:50 PM, biffe...@yahoo.co.uk <
> > >> biffe...@yahoo.co.uk> wrote:
> > >>> I was getting a bit fed up with my JTAG experiments (2 weeks and
> > >>> hardly any progress), so I decided to try something a bit easier
> > >>> starting from this morning.
> > >>> So I've added GPIO sysfs support to 2.6.30.5, however I need testers,
> > >>> not only for the basic GPIO functionality, but also to see if the i2c
> > >>> modules can be layered on top of this to solve the issues people were
> > >>> previously seeing. I suspect that this will also allow MMC support,
> > >>> albeit with somewhat slow data rates. If nothing else, it will allow
> > >>> folk to get/set pins without having to write kernel modules or dicky
> > >>> little programs like biff-gpio.
> > >>> If all goes well, I'll try to submit this to LKML.
> > >>> Google sites has been jerking me around today, but seems
> > >>> intermittently available. I've added the patch and description of
> how
> > >>> to use the functionality here:
<razvan.dragomire...@gmail.com> wrote:
> My apologies, it works fine, I was just looking at the blue LED instead :(.
> BTW, is there any way to control that LED with GPIO? The red LED is not
> visible on the outside of the plastic enclosure and it's hard to see of a
> user that is just looking at a close enclosure? Can we control the green or
> blue LEDs that have holes in the plastic case for them?
> Thanks,
> Razvan
> > On Aug 31, 2:59 pm, Nelson Neves <nelson.s.ne...@gmail.com> wrote:
> > > My question, I have the Bifferboard OnFlashSystem up and running with
> > kernel
> > > version 2.6.30.2, will the available patch work or do I really need the
> > > 2.6.30.5 ???
> > > Regards,
> > > Nelson.
> > > ps: will test this tonight, will only have access to hardware later (back
> > > from vacations)!
> > > On Mon, Aug 31, 2009 at 2:54 PM, Razvan Dragomirescu <
> > > > It doesn't appear to work for me, I've applied the patch to 2.6.30.1
> > > > though, not to 2.6.30.5. Everything looks fine, compilation works, then
> > I
> > > > do:
> > > >> On Sat, Aug 29, 2009 at 6:50 PM, biffe...@yahoo.co.uk <
> > > >> biffe...@yahoo.co.uk> wrote:
> > > >>> I was getting a bit fed up with my JTAG experiments (2 weeks and
> > > >>> hardly any progress), so I decided to try something a bit easier
> > > >>> starting from this morning.
> > > >>> So I've added GPIO sysfs support to 2.6.30.5, however I need testers,
> > > >>> not only for the basic GPIO functionality, but also to see if the i2c
> > > >>> modules can be layered on top of this to solve the issues people were
> > > >>> previously seeing. I suspect that this will also allow MMC support,
> > > >>> albeit with somewhat slow data rates. If nothing else, it will allow
> > > >>> folk to get/set pins without having to write kernel modules or dicky
> > > >>> little programs like biff-gpio.
> > > >>> If all goes well, I'll try to submit this to LKML.
> > > >>> Google sites has been jerking me around today, but seems
> > > >>> intermittently available. I've added the patch and description of
> > how
> > > >>> to use the functionality here:
That's ok, it was just an experiment :). BTW, what pin number do we use to
get the "reset button" status? With all this mapping and remapping I'm
getting a little confused :).
On Mon, Aug 31, 2009 at 10:31 PM, bifferos <biffe...@yahoo.co.uk> wrote:
> Easy mistake to make :-).
> I'm afraid the blue is connected to the switcher, and the green to the
> ethernet media, so unless you want to send lots of packets, no.
> Biff.
> On Aug 31, 7:29 pm, Razvan Dragomirescu
> <razvan.dragomire...@gmail.com> wrote:
> > My apologies, it works fine, I was just looking at the blue LED instead
> :(.
> > BTW, is there any way to control that LED with GPIO? The red LED is not
> > visible on the outside of the plastic enclosure and it's hard to see of a
> > user that is just looking at a close enclosure? Can we control the green
> or
> > blue LEDs that have holes in the plastic case for them?
> > Thanks,
> > Razvan
> > > On Aug 31, 2:59 pm, Nelson Neves <nelson.s.ne...@gmail.com> wrote:
> > > > My question, I have the Bifferboard OnFlashSystem up and running with
> > > kernel
> > > > version 2.6.30.2, will the available patch work or do I really need
> the
> > > > 2.6.30.5 ???
> > > > Regards,
> > > > Nelson.
> > > > ps: will test this tonight, will only have access to hardware later
> (back
> > > > from vacations)!
> > > > On Mon, Aug 31, 2009 at 2:54 PM, Razvan Dragomirescu <
> > > > > It doesn't appear to work for me, I've applied the patch to
> 2.6.30.1
> > > > > though, not to 2.6.30.5. Everything looks fine, compilation works,
> then
> > > I
> > > > > do:
> > > > >> On Sat, Aug 29, 2009 at 6:50 PM, biffe...@yahoo.co.uk <
> > > > >> biffe...@yahoo.co.uk> wrote:
> > > > >>> I was getting a bit fed up with my JTAG experiments (2 weeks and
> > > > >>> hardly any progress), so I decided to try something a bit easier
> > > > >>> starting from this morning.
> > > > >>> So I've added GPIO sysfs support to 2.6.30.5, however I need
> testers,
> > > > >>> not only for the basic GPIO functionality, but also to see if the
> i2c
> > > > >>> modules can be layered on top of this to solve the issues people
> were
> > > > >>> previously seeing. I suspect that this will also allow MMC
> support,
> > > > >>> albeit with somewhat slow data rates. If nothing else, it will
> allow
> > > > >>> folk to get/set pins without having to write kernel modules or
> dicky
> > > > >>> little programs like biff-gpio.
> > > > >>> If all goes well, I'll try to submit this to LKML.
> > > > >>> Google sites has been jerking me around today, but seems
> > > > >>> intermittently available. I've added the patch and description
> of
> > > how
> > > > >>> to use the functionality here:
razvan.dragomire...@gmail.com> wrote:
> That's ok, it was just an experiment :). BTW, what pin number do we use to
> get the "reset button" status? With all this mapping and remapping I'm
> getting a little confused :).
> On Mon, Aug 31, 2009 at 10:31 PM, bifferos <biffe...@yahoo.co.uk> wrote:
>> Easy mistake to make :-).
>> I'm afraid the blue is connected to the switcher, and the green to the
>> ethernet media, so unless you want to send lots of packets, no.
>> Biff.
>> On Aug 31, 7:29 pm, Razvan Dragomirescu
>> <razvan.dragomire...@gmail.com> wrote:
>> > My apologies, it works fine, I was just looking at the blue LED instead
>> :(.
>> > BTW, is there any way to control that LED with GPIO? The red LED is not
>> > visible on the outside of the plastic enclosure and it's hard to see of
>> a
>> > user that is just looking at a close enclosure? Can we control the green
>> or
>> > blue LEDs that have holes in the plastic case for them?
>> > Thanks,
>> > Razvan
>> > > On Aug 31, 2:59 pm, Nelson Neves <nelson.s.ne...@gmail.com> wrote:
>> > > > My question, I have the Bifferboard OnFlashSystem up and running
>> with
>> > > kernel
>> > > > version 2.6.30.2, will the available patch work or do I really need
>> the
>> > > > 2.6.30.5 ???
>> > > > Regards,
>> > > > Nelson.
>> > > > ps: will test this tonight, will only have access to hardware later
>> (back
>> > > > from vacations)!
>> > > > On Mon, Aug 31, 2009 at 2:54 PM, Razvan Dragomirescu <
>> > > > > It doesn't appear to work for me, I've applied the patch to
>> 2.6.30.1
>> > > > > though, not to 2.6.30.5. Everything looks fine, compilation works,
>> then
>> > > I
>> > > > > do:
>> > > > >> On Sat, Aug 29, 2009 at 6:50 PM, biffe...@yahoo.co.uk <
>> > > > >> biffe...@yahoo.co.uk> wrote:
>> > > > >>> I was getting a bit fed up with my JTAG experiments (2 weeks and
>> > > > >>> hardly any progress), so I decided to try something a bit easier
>> > > > >>> starting from this morning.
>> > > > >>> So I've added GPIO sysfs support to 2.6.30.5, however I need
>> testers,
>> > > > >>> not only for the basic GPIO functionality, but also to see if
>> the i2c
>> > > > >>> modules can be layered on top of this to solve the issues people
>> were
>> > > > >>> previously seeing. I suspect that this will also allow MMC
>> support,
>> > > > >>> albeit with somewhat slow data rates. If nothing else, it will
>> allow
>> > > > >>> folk to get/set pins without having to write kernel modules or
>> dicky
>> > > > >>> little programs like biff-gpio.
>> > > > >>> If all goes well, I'll try to submit this to LKML.
>> > > > >>> Google sites has been jerking me around today, but seems
>> > > > >>> intermittently available. I've added the patch and description
>> of
>> > > how
>> > > > >>> to use the functionality here:
This patch is completely generic, and can theoretically be used with
any RDC chip. It's supposed to be of a sufficiently high standard to
be included in Linux (cough), and I'll submit it if no problems are
found. GPIO pin numbers follow those found in the RDC datasheets for
R8610, R3282, R3210 (GPIOs 0-59).
By coincidence GPIO numbers here: http://bifferos.bizhat.com/pinouts/ still map to the GPIO numbers in the patch, because the GPIO bank used
by Bifferboard is the first bank (phew!).
Previous patches were Bifferboard specific, and made use of the fact
that only one GPIO bank is ever of interest to Bifferboard users, and
more specifically that only 6 lines on that bank can be used. This is
obviously the wrong approach if we ever want to see RDC GPIO support
in the mainline kernel, so we will now stick to the world according to
RDC when it comes to pin numbers.
<razvan.dragomire...@gmail.com> wrote:
> That's ok, it was just an experiment :). BTW, what pin number do we use to
> get the "reset button" status? With all this mapping and remapping I'm
> getting a little confused :).
> On Mon, Aug 31, 2009 at 10:31 PM, bifferos <biffe...@yahoo.co.uk> wrote:
> > Easy mistake to make :-).
> > I'm afraid the blue is connected to the switcher, and the green to the
> > ethernet media, so unless you want to send lots of packets, no.
> > Biff.
> > On Aug 31, 7:29 pm, Razvan Dragomirescu
> > <razvan.dragomire...@gmail.com> wrote:
> > > My apologies, it works fine, I was just looking at the blue LED instead
> > :(.
> > > BTW, is there any way to control that LED with GPIO? The red LED is not
> > > visible on the outside of the plastic enclosure and it's hard to see of a
> > > user that is just looking at a close enclosure? Can we control the green
> > or
> > > blue LEDs that have holes in the plastic case for them?
> > > Thanks,
> > > Razvan
> > > > On Aug 31, 2:59 pm, Nelson Neves <nelson.s.ne...@gmail.com> wrote:
> > > > > My question, I have the Bifferboard OnFlashSystem up and running with
> > > > kernel
> > > > > version 2.6.30.2, will the available patch work or do I really need
> > the
> > > > > 2.6.30.5 ???
> > > > > Regards,
> > > > > Nelson.
> > > > > ps: will test this tonight, will only have access to hardware later
> > (back
> > > > > from vacations)!
> > > > > On Mon, Aug 31, 2009 at 2:54 PM, Razvan Dragomirescu <
> > > > > >> On Sat, Aug 29, 2009 at 6:50 PM, biffe...@yahoo.co.uk <
> > > > > >> biffe...@yahoo.co.uk> wrote:
> > > > > >>> I was getting a bit fed up with my JTAG experiments (2 weeks and
> > > > > >>> hardly any progress), so I decided to try something a bit easier
> > > > > >>> starting from this morning.
> > > > > >>> So I've added GPIO sysfs support to 2.6.30.5, however I need
> > testers,
> > > > > >>> not only for the basic GPIO functionality, but also to see if the
> > i2c
> > > > > >>> modules can be layered on top of this to solve the issues people
> > were
> > > > > >>> previously seeing. I suspect that this will also allow MMC
> > support,
> > > > > >>> albeit with somewhat slow data rates. If nothing else, it will
> > allow
> > > > > >>> folk to get/set pins without having to write kernel modules or
> > dicky
> > > > > >>> little programs like biff-gpio.
> > > > > >>> If all goes well, I'll try to submit this to LKML.
> > > > > >>> Google sites has been jerking me around today, but seems
> > > > > >>> intermittently available. I've added the patch and description
> > of
> > > > how
> > > > > >>> to use the functionality here:
This seems to be working (I only tested the basic stuff, don't know if I have all the necessary patches applied correctly). But I'm having some difficulty applying the gpio patches from here: http://sites.google.com/site/bifferboard/Home/gpio
I got this: ./7-applypatches patching file drivers/gpio/Kconfig Hunk #2 succeeded at 189 (offset -12 lines). patching file drivers/gpio/Makefile Hunk #1 FAILED at 14. 1 out of 1 hunk FAILED -- saving rejects to file drivers/gpio/Makefile.rej patching file drivers/gpio/rdc321x_gpio.c patching file drivers/gpio/Kconfig Hunk #1 succeeded at 75 with fuzz 2 (offset 12 lines). Hunk #2 FAILED at 215. 1 out of 2 hunks FAILED -- saving rejects to file drivers/gpio/Kconfig.rej patching file drivers/gpio/Makefile Hunk #1 FAILED at 14. 1 out of 1 hunk FAILED -- saving rejects to file drivers/gpio/Makefile.rej The next patch would create the file drivers/gpio/rdc321x_gpio.c, which already exists! Assume -R? [n] n Apply anyway? [n] n Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file drivers/gpio/rdc321x_gpio.c.rej
*from Kconfig.rej* *************** config GPIO_MCP23S08 *** 201,203 **** a GPIO interface supporting inputs and outputs.
endif --- 215,220 ---- a GPIO interface supporting inputs and outputs.
Please note that I don't have experience with this, only followed the wiki and tried to put the pieces together, please apologize for any dumb mistake!
Also tried with kernel 2.6.30.5 making small adjustments into my scripts but It also fails whem applying the gpio patches.
> This seems to be working (I only tested the basic stuff, don't know if I
> have all the necessary patches applied correctly). But I'm having some
> difficulty applying the gpio patches from here:http://sites.google.com/site/bifferboard/Home/gpio
> I got this:
> ./7-applypatches
> patching file drivers/gpio/Kconfig
> Hunk #2 succeeded at 189 (offset -12 lines).
> patching file drivers/gpio/Makefile
> Hunk #1 FAILED at 14.
> 1 out of 1 hunk FAILED -- saving rejects to file drivers/gpio/Makefile.rej
> patching file drivers/gpio/rdc321x_gpio.c
> patching file drivers/gpio/Kconfig
> Hunk #1 succeeded at 75 with fuzz 2 (offset 12 lines).
> Hunk #2 FAILED at 215.
> 1 out of 2 hunks FAILED -- saving rejects to file drivers/gpio/Kconfig.rej
> patching file drivers/gpio/Makefile
> Hunk #1 FAILED at 14.
> 1 out of 1 hunk FAILED -- saving rejects to file drivers/gpio/Makefile.rej
> The next patch would create the file drivers/gpio/rdc321x_gpio.c,
> which already exists! Assume -R? [n] n
> Apply anyway? [n] n
> Skipping patch.
> 1 out of 1 hunk ignored -- saving rejects to file
> drivers/gpio/rdc321x_gpio.c.rej
> *from Kconfig.rej*
> *************** config GPIO_MCP23S08
> *** 201,203 ****
> a GPIO interface supporting inputs and outputs.
> endif
> --- 215,220 ----
> a GPIO interface supporting inputs and outputs.
> Please note that I don't have experience with this, only followed the wiki
> and tried to put the pieces together, please apologize for any dumb mistake!
> Also tried with kernel 2.6.30.5 making small adjustments into my scripts but
> It also fails whem applying the gpio patches.
Do you know if the pins marked NS on the expansion board connectors
are wired up on the main board or not (I've not been able to trace
them yet)?
I'm wondering, based upon a suspicion that other models from the OEM
support additional switches, whether one could use a variation of the
GPIO driver to see if any of these lines are connected to the CPU GPIO
pins (suspect this may need to run as a debug boot process before any
RDC configuration occurs that may dedicate the RDC pins to a specific
process).
Regards
Jason
On Aug 31, 10:06 pm, bifferos <biffe...@yahoo.co.uk> wrote:
> This patch is completely generic, and can theoretically be used with
> any RDC chip. It's supposed to be of a sufficiently high standard to
> be included in Linux (cough), and I'll submit it if no problems are
> found. GPIO pin numbers follow those found in the RDC datasheets for
> R8610, R3282, R3210 (GPIOs 0-59).
> By coincidence GPIO numbers here:http://bifferos.bizhat.com/pinouts/ > still map to the GPIO numbers in the patch, because the GPIO bank used
> by Bifferboard is the first bank (phew!).
> Previous patches were Bifferboard specific, and made use of the fact
> that only one GPIO bank is ever of interest to Bifferboard users, and
> more specifically that only 6 lines on that bank can be used. This is
> obviously the wrong approach if we ever want to see RDC GPIO support
> in the mainline kernel, so we will now stick to the world according to
> RDC when it comes to pin numbers.
> thanks,
> Biff.
> On Aug 31, 8:45 pm, Razvan Dragomirescu
> <razvan.dragomire...@gmail.com> wrote:
> > That's ok, it was just an experiment :). BTW, what pin number do we use to
> > get the "reset button" status? With all this mapping and remapping I'm
> > getting a little confused :).
> > On Mon, Aug 31, 2009 at 10:31 PM, bifferos <biffe...@yahoo.co.uk> wrote:
> > > Easy mistake to make :-).
> > > I'm afraid the blue is connected to the switcher, and the green to the
> > > ethernet media, so unless you want to send lots of packets, no.
> > > Biff.
> > > On Aug 31, 7:29 pm, Razvan Dragomirescu
> > > <razvan.dragomire...@gmail.com> wrote:
> > > > My apologies, it works fine, I was just looking at the blue LED instead
> > > :(.
> > > > BTW, is there any way to control that LED with GPIO? The red LED is not
> > > > visible on the outside of the plastic enclosure and it's hard to see of a
> > > > user that is just looking at a close enclosure? Can we control the green
> > > or
> > > > blue LEDs that have holes in the plastic case for them?
> > > > Thanks,
> > > > Razvan
> > > > > On Aug 31, 2:59 pm, Nelson Neves <nelson.s.ne...@gmail.com> wrote:
> > > > > > My question, I have the Bifferboard OnFlashSystem up and running with
> > > > > kernel
> > > > > > version 2.6.30.2, will the available patch work or do I really need
> > > the
> > > > > > 2.6.30.5 ???
> > > > > > Regards,
> > > > > > Nelson.
> > > > > > ps: will test this tonight, will only have access to hardware later
> > > (back
> > > > > > from vacations)!
> > > > > > On Mon, Aug 31, 2009 at 2:54 PM, Razvan Dragomirescu <
> > > > > > >> On Sat, Aug 29, 2009 at 6:50 PM, biffe...@yahoo.co.uk <
> > > > > > >> biffe...@yahoo.co.uk> wrote:
> > > > > > >>> I was getting a bit fed up with my JTAG experiments (2 weeks and
> > > > > > >>> hardly any progress), so I decided to try something a bit easier
> > > > > > >>> starting from this morning.
> > > > > > >>> So I've added GPIO sysfs support to 2.6.30.5, however I need
> > > testers,
> > > > > > >>> not only for the basic GPIO functionality, but also to see if the
> > > i2c
> > > > > > >>> modules can be layered on top of this to solve the issues people
> > > were
> > > > > > >>> previously seeing. I suspect that this will also allow MMC
> > > support,
> > > > > > >>> albeit with somewhat slow data rates. If nothing else, it will
> > > allow
> > > > > > >>> folk to get/set pins without having to write kernel modules or
> > > dicky
> > > > > > >>> little programs like biff-gpio.
> > > > > > >>> If all goes well, I'll try to submit this to LKML.
> > > > > > >>> Google sites has been jerking me around today, but seems
> > > > > > >>> intermittently available. I've added the patch and description
> > > of
> > > > > how
> > > > > > >>> to use the functionality here:
> Do you know if the pins marked NS on the expansion board connectors
> are wired up on the main board or not (I've not been able to trace
> them yet)?
> I'm wondering, based upon a suspicion that other models from the OEM
> support additional switches, whether one could use a variation of the
> GPIO driver to see if any of these lines are connected to the CPU GPIO
> pins (suspect this may need to run as a debug boot process before any
> RDC configuration occurs that may dedicate the RDC pins to a specific
> process).
> Regards
> Jason
> On Aug 31, 10:06 pm, bifferos <biffe...@yahoo.co.uk> wrote:
> > This patch is completely generic, and can theoretically be used with
> > any RDC chip. It's supposed to be of a sufficiently high standard to
> > be included in Linux (cough), and I'll submit it if no problems are
> > found. GPIO pin numbers follow those found in the RDC datasheets for
> > R8610, R3282, R3210 (GPIOs 0-59).
> > By coincidence GPIO numbers here:http://bifferos.bizhat.com/pinouts/ > > still map to the GPIO numbers in the patch, because the GPIO bank used
> > by Bifferboard is the first bank (phew!).
> > Previous patches were Bifferboard specific, and made use of the fact
> > that only one GPIO bank is ever of interest to Bifferboard users, and
> > more specifically that only 6 lines on that bank can be used. This is
> > obviously the wrong approach if we ever want to see RDC GPIO support
> > in the mainline kernel, so we will now stick to the world according to
> > RDC when it comes to pin numbers.
> > thanks,
> > Biff.
> > On Aug 31, 8:45 pm, Razvan Dragomirescu
> > <razvan.dragomire...@gmail.com> wrote:
> > > That's ok, it was just an experiment :). BTW, what pin number do we use to
> > > get the "reset button" status? With all this mapping and remapping I'm
> > > getting a little confused :).
> > > On Mon, Aug 31, 2009 at 10:31 PM, bifferos <biffe...@yahoo.co.uk> wrote:
> > > > Easy mistake to make :-).
> > > > I'm afraid the blue is connected to the switcher, and the green to the
> > > > ethernet media, so unless you want to send lots of packets, no.
> > > > Biff.
> > > > On Aug 31, 7:29 pm, Razvan Dragomirescu
> > > > <razvan.dragomire...@gmail.com> wrote:
> > > > > My apologies, it works fine, I was just looking at the blue LED instead
> > > > :(.
> > > > > BTW, is there any way to control that LED with GPIO? The red LED is not
> > > > > visible on the outside of the plastic enclosure and it's hard to see of a
> > > > > user that is just looking at a close enclosure? Can we control the green
> > > > or
> > > > > blue LEDs that have holes in the plastic case for them?
> > > > > Thanks,
> > > > > Razvan
> > > > > > On Aug 31, 2:59 pm, Nelson Neves <nelson.s.ne...@gmail.com> wrote:
> > > > > > > My question, I have the Bifferboard OnFlashSystem up and running with
> > > > > > kernel
> > > > > > > version 2.6.30.2, will the available patch work or do I really need
> > > > the
> > > > > > > 2.6.30.5 ???
> > > > > > > Regards,
> > > > > > > Nelson.
> > > > > > > ps: will test this tonight, will only have access to hardware later
> > > > (back
> > > > > > > from vacations)!
> > > > > > > On Mon, Aug 31, 2009 at 2:54 PM, Razvan Dragomirescu <
> > > > > > > > On Mon, Aug 31, 2009 at 1:48 AM, Razvan Dragomirescu <
> > > > > > > > razvan.dragomire...@gmail.com> wrote:
> > > > > > > >> Hey Biff, I'll give it a try too, I've always meant to try to
> > > > figure
> > > > > > out a
> > > > > > > >> way to do this. Good work!
> > > > > > > >> On Sat, Aug 29, 2009 at 6:50 PM, biffe...@yahoo.co.uk <
> > > > > > > >> biffe...@yahoo.co.uk> wrote:
> > > > > > > >>> I was getting a bit fed up with my JTAG experiments (2 weeks and
> > > > > > > >>> hardly any progress), so I decided to try something a bit easier
> > > > > > > >>> starting from this morning.
> > > > > > > >>> So I've added GPIO sysfs support to 2.6.30.5, however I need
> > > > testers,
> > > > > > > >>> not only for the basic GPIO functionality, but also to see if the
> > > > i2c
> > > > > > > >>> modules can be layered on top of this to solve the issues people
> > > > were
> > > > > > > >>> previously seeing. I suspect that this will also allow MMC
> > > > support,
> > > > > > > >>> albeit with somewhat slow data rates. If nothing else, it will
> > > > allow
> > > > > > > >>> folk to get/set pins without having to write kernel modules or
> > > > dicky
> > > > > > > >>> little programs like biff-gpio.
> > > > > > > >>> If all goes well, I'll try to submit this to LKML.
> > > > > > > >>> Google sites has been jerking me around today, but seems
> > > > > > > >>> intermittently available. I've added the patch and description
> > > > of
> > > > > > how
> > > > > > > >>> to use the functionality here:
> > This seems to be working (I only tested the basic stuff, don't know if I
> > have all the necessary patches applied correctly). But I'm having some
> > difficulty applying the gpio patches from here:
> http://sites.google.com/site/bifferboard/Home/gpio
> > I got this:
> > ./7-applypatches
> > patching file drivers/gpio/Kconfig
> > Hunk #2 succeeded at 189 (offset -12 lines).
> > patching file drivers/gpio/Makefile
> > Hunk #1 FAILED at 14.
> > 1 out of 1 hunk FAILED -- saving rejects to file
> drivers/gpio/Makefile.rej
> > patching file drivers/gpio/rdc321x_gpio.c
> > patching file drivers/gpio/Kconfig
> > Hunk #1 succeeded at 75 with fuzz 2 (offset 12 lines).
> > Hunk #2 FAILED at 215.
> > 1 out of 2 hunks FAILED -- saving rejects to file
> drivers/gpio/Kconfig.rej
> > patching file drivers/gpio/Makefile
> > Hunk #1 FAILED at 14.
> > 1 out of 1 hunk FAILED -- saving rejects to file
> drivers/gpio/Makefile.rej
> > The next patch would create the file drivers/gpio/rdc321x_gpio.c,
> > which already exists! Assume -R? [n] n
> > Apply anyway? [n] n
> > Skipping patch.
> > 1 out of 1 hunk ignored -- saving rejects to file
> > drivers/gpio/rdc321x_gpio.c.rej
> > *from rdc321x_gpio.c.rej*
> > ... very long text
> > Please note that I don't have experience with this, only followed the
> wiki
> > and tried to put the pieces together, please apologize for any dumb
> mistake!
> > Also tried with kernel 2.6.30.5 making small adjustments into my scripts
> but
> > It also fails whem applying the gpio patches.
>> > This seems to be working (I only tested the basic stuff, don't know if I
>> > have all the necessary patches applied correctly). But I'm having some
>> > difficulty applying the gpio patches from here:
>> http://sites.google.com/site/bifferboard/Home/gpio
>> > I got this:
>> > ./7-applypatches
>> > patching file drivers/gpio/Kconfig
>> > Hunk #2 succeeded at 189 (offset -12 lines).
>> > patching file drivers/gpio/Makefile
>> > Hunk #1 FAILED at 14.
>> > 1 out of 1 hunk FAILED -- saving rejects to file
>> drivers/gpio/Makefile.rej
>> > patching file drivers/gpio/rdc321x_gpio.c
>> > patching file drivers/gpio/Kconfig
>> > Hunk #1 succeeded at 75 with fuzz 2 (offset 12 lines).
>> > Hunk #2 FAILED at 215.
>> > 1 out of 2 hunks FAILED -- saving rejects to file
>> drivers/gpio/Kconfig.rej
>> > patching file drivers/gpio/Makefile
>> > Hunk #1 FAILED at 14.
>> > 1 out of 1 hunk FAILED -- saving rejects to file
>> drivers/gpio/Makefile.rej
>> > The next patch would create the file drivers/gpio/rdc321x_gpio.c,
>> > which already exists! Assume -R? [n] n
>> > Apply anyway? [n] n
>> > Skipping patch.
>> > 1 out of 1 hunk ignored -- saving rejects to file
>> > drivers/gpio/rdc321x_gpio.c.rej
>> > *from rdc321x_gpio.c.rej*
>> > ... very long text
>> > Please note that I don't have experience with this, only followed the
>> wiki
>> > and tried to put the pieces together, please apologize for any dumb
>> mistake!
>> > Also tried with kernel 2.6.30.5 making small adjustments into my scripts
>> but
>> > It also fails whem applying the gpio patches.
razvan.dragomire...@gmail.com> wrote:
> Can you check your .config to see if CONFIG_GPIO_SYSFS is set? That's the
> option that makes the /sys/class/gpio appear (as far as I can tell).
>>> > This seems to be working (I only tested the basic stuff, don't know if
>>> I
>>> > have all the necessary patches applied correctly). But I'm having some
>>> > difficulty applying the gpio patches from here:
>>> http://sites.google.com/site/bifferboard/Home/gpio
>>> > I got this:
>>> > ./7-applypatches
>>> > patching file drivers/gpio/Kconfig
>>> > Hunk #2 succeeded at 189 (offset -12 lines).
>>> > patching file drivers/gpio/Makefile
>>> > Hunk #1 FAILED at 14.
>>> > 1 out of 1 hunk FAILED -- saving rejects to file
>>> drivers/gpio/Makefile.rej
>>> > patching file drivers/gpio/rdc321x_gpio.c
>>> > patching file drivers/gpio/Kconfig
>>> > Hunk #1 succeeded at 75 with fuzz 2 (offset 12 lines).
>>> > Hunk #2 FAILED at 215.
>>> > 1 out of 2 hunks FAILED -- saving rejects to file
>>> drivers/gpio/Kconfig.rej
>>> > patching file drivers/gpio/Makefile
>>> > Hunk #1 FAILED at 14.
>>> > 1 out of 1 hunk FAILED -- saving rejects to file
>>> drivers/gpio/Makefile.rej
>>> > The next patch would create the file drivers/gpio/rdc321x_gpio.c,
>>> > which already exists! Assume -R? [n] n
>>> > Apply anyway? [n] n
>>> > Skipping patch.
>>> > 1 out of 1 hunk ignored -- saving rejects to file
>>> > drivers/gpio/rdc321x_gpio.c.rej
>>> > *from rdc321x_gpio.c.rej*
>>> > ... very long text
>>> > Please note that I don't have experience with this, only followed the
>>> wiki
>>> > and tried to put the pieces together, please apologize for any dumb
>>> mistake!
>>> > Also tried with kernel 2.6.30.5 making small adjustments into my
>>> scripts but
>>> > It also fails whem applying the gpio patches.
>>> On Tue, Sep 1, 2009 at 12:08 PM, bifferos <biffe...@yahoo.co.uk> wrote:
>>>> I've just uploaded version 3 - try that instead (with 2.6.30.5).
>>>> cheers,
>>>> Biff.
>>>> On Sep 1, 1:13 am, Nelson Neves <nelson.s.ne...@gmail.com> wrote:
>>>> > Hi,
>>>> > I've been having some hard time trying to get this to work on my
>>>> > OnFlashSystem with kernel 2.6.30.2, some tips would be very welcome. I
>>>> > followed the instructions from here:
>>>> http://sites.google.com/site/bifferboard/Home/howto/faster-route-to-k.
>>>> ..
>>>> > This seems to be working (I only tested the basic stuff, don't know if
>>>> I
>>>> > have all the necessary patches applied correctly). But I'm having some
>>>> > difficulty applying the gpio patches from here:
>>>> http://sites.google.com/site/bifferboard/Home/gpio
>>>> > I got this:
>>>> > ./7-applypatches
>>>> > patching file drivers/gpio/Kconfig
>>>> > Hunk #2 succeeded at 189 (offset -12 lines).
>>>> > patching file drivers/gpio/Makefile
>>>> > Hunk #1 FAILED at 14.
>>>> > 1 out of 1 hunk FAILED -- saving rejects to file
>>>> drivers/gpio/Makefile.rej
>>>> > patching file drivers/gpio/rdc321x_gpio.c
>>>> > patching file drivers/gpio/Kconfig
>>>> > Hunk #1 succeeded at 75 with fuzz 2 (offset 12 lines).
>>>> > Hunk #2 FAILED at 215.
>>>> > 1 out of 2 hunks FAILED -- saving rejects to file
>>>> drivers/gpio/Kconfig.rej
>>>> > patching file drivers/gpio/Makefile
>>>> > Hunk #1 FAILED at 14.
>>>> > 1 out of 1 hunk FAILED -- saving rejects to file
>>>> drivers/gpio/Makefile.rej
>>>> > The next patch would create the file drivers/gpio/rdc321x_gpio.c,
>>>> > which already exists! Assume -R? [n] n
>>>> > Apply anyway? [n] n
>>>> > Skipping patch.
>>>> > 1 out of 1 hunk ignored -- saving rejects to file
>>>> > drivers/gpio/rdc321x_gpio.c.rej
>>>> > *from rdc321x_gpio.c.rej*
>>>> > ... very long text
>>>> > Please note that I don't have experience with this, only followed the
>>>> wiki
>>>> > and tried to put the pieces together, please apologize for any dumb
>>>> mistake!
>>>> > Also tried with kernel 2.6.30.5 making small adjustments into my
>>>> scripts but
>>>> > It also fails whem applying the gpio patches.
I seem to have GPIO working for the output (turning the _red_ LED on and
off), but I can't seem to be able to read that d**n reset button. Here's
what I do:
echo 15 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio15/direction (this is probably not needed
since the pins are set to input as the default anyway)
Every time I do "cat /sys/class/gpio/gpio15/value" it always comes out as
"1", regardless of the status of the button (pressed or not pressed). I've
also tried to read all the values from gpio1 to gpio15 and all of them are
"stuck" to 1, so unless the GPIO for the reset button is >16 there's
something wrong with the driver.
Biff, did you check input too? Am I doing anything wrong?
>>>> On Tue, Sep 1, 2009 at 12:08 PM, bifferos <biffe...@yahoo.co.uk> wrote:
>>>>> I've just uploaded version 3 - try that instead (with 2.6.30.5).
>>>>> cheers,
>>>>> Biff.
>>>>> On Sep 1, 1:13 am, Nelson Neves <nelson.s.ne...@gmail.com> wrote:
>>>>> > Hi,
>>>>> > I've been having some hard time trying to get this to work on my
>>>>> > OnFlashSystem with kernel 2.6.30.2, some tips would be very welcome.
>>>>> I
>>>>> > followed the instructions from here:
>>>>> http://sites.google.com/site/bifferboard/Home/howto/faster-route-to-k.
>>>>> ..
>>>>> > This seems to be working (I only tested the basic stuff, don't know
>>>>> if I
>>>>> > have all the necessary patches applied correctly). But I'm having
>>>>> some
>>>>> > difficulty applying the gpio patches from here:
>>>>> http://sites.google.com/site/bifferboard/Home/gpio
>>>>> > I got this:
>>>>> > ./7-applypatches
>>>>> > patching file drivers/gpio/Kconfig
>>>>> > Hunk #2 succeeded at 189 (offset -12 lines).
>>>>> > patching file drivers/gpio/Makefile
>>>>> > Hunk #1 FAILED at 14.
>>>>> > 1 out of 1 hunk FAILED -- saving rejects to file
>>>>> drivers/gpio/Makefile.rej
>>>>> > patching file drivers/gpio/rdc321x_gpio.c
>>>>> > patching file drivers/gpio/Kconfig
>>>>> > Hunk #1 succeeded at 75 with fuzz 2 (offset 12 lines).
>>>>> > Hunk #2 FAILED at 215.
>>>>> > 1 out of 2 hunks FAILED -- saving rejects to file
>>>>> drivers/gpio/Kconfig.rej
>>>>> > patching file drivers/gpio/Makefile
>>>>> > Hunk #1 FAILED at 14.
>>>>> > 1 out of 1 hunk FAILED -- saving rejects to file
>>>>> drivers/gpio/Makefile.rej
>>>>> > The next patch would create the file drivers/gpio/rdc321x_gpio.c,
>>>>> > which already exists! Assume -R? [n] n
>>>>> > Apply anyway? [n] n
>>>>> > Skipping patch.
>>>>> > 1 out of 1 hunk ignored -- saving rejects to file
>>>>> > drivers/gpio/rdc321x_gpio.c.rej
>>>>> > *from rdc321x_gpio.c.rej*
>>>>> > ... very long text
>>>>> > Please note that I don't have experience with this, only followed the
>>>>> wiki
>>>>> > and tried to put the pieces together, please apologize for any dumb
>>>>> mistake!
>>>>> > Also tried with kernel 2.6.30.5 making small adjustments into my
>>>>> scripts but
>>>>> > It also fails whem applying the gpio patches.
No, you're not doing anything wrong. I thought I had this working,
but it seems not, because I managed to get the same behaviour as you
with one of my patches. I also managed to have this working another
time, so I'm not quite sure what is going on.
On Sep 2, 6:28 pm, Razvan Dragomirescu <razvan.dragomire...@gmail.com>
wrote:
> I seem to have GPIO working for the output (turning the _red_ LED on and
> off), but I can't seem to be able to read that d**n reset button. Here's
> what I do:
> echo 15 > /sys/class/gpio/export
> echo in > /sys/class/gpio/gpio15/direction (this is probably not needed
> since the pins are set to input as the default anyway)
> Every time I do "cat /sys/class/gpio/gpio15/value" it always comes out as
> "1", regardless of the status of the button (pressed or not pressed). I've
> also tried to read all the values from gpio1 to gpio15 and all of them are
> "stuck" to 1, so unless the GPIO for the reset button is >16 there's
> something wrong with the driver.
> Biff, did you check input too? Am I doing anything wrong?
> >> I'm just waiting for the compilation, will post results soon!
> >> Thanks Razvan!
> >> On Tue, Sep 1, 2009 at 10:59 PM, Razvan Dragomirescu <
> >> razvan.dragomire...@gmail.com> wrote:
> >>> Can you check your .config to see if CONFIG_GPIO_SYSFS is set? That's
> >>> the option that makes the /sys/class/gpio appear (as far as I can tell).
> >>>> On Tue, Sep 1, 2009 at 12:08 PM, bifferos <biffe...@yahoo.co.uk> wrote:
> >>>>> I've just uploaded version 3 - try that instead (with 2.6.30.5).
> >>>>> cheers,
> >>>>> Biff.
> >>>>> On Sep 1, 1:13 am, Nelson Neves <nelson.s.ne...@gmail.com> wrote:
> >>>>> > Hi,
> >>>>> > I've been having some hard time trying to get this to work on my
> >>>>> > OnFlashSystem with kernel 2.6.30.2, some tips would be very welcome.
> >>>>> I
> >>>>> > followed the instructions from here:
> >>>>>http://sites.google.com/site/bifferboard/Home/howto/faster-route-to-k.
> >>>>> ..
> >>>>> > Being a bit dumb I have create this set of custom script to automate
> >>>>> the
> >>>>> > creation of the OnFlashSystem (just need to run the script on the
> >>>>> numeric
> >>>>> > order):
> >>>>>http://botdream.com/bifferboard/onflashsystem/bifferboardflash.tar.gz
> >>>>> > This seems to be working (I only tested the basic stuff, don't know
> >>>>> if I
> >>>>> > have all the necessary patches applied correctly). But I'm having
> >>>>> some
> >>>>> > difficulty applying the gpio patches from here:
> >>>>>http://sites.google.com/site/bifferboard/Home/gpio
> >>>>> > I got this:
> >>>>> > ./7-applypatches
> >>>>> > patching file drivers/gpio/Kconfig
> >>>>> > Hunk #2 succeeded at 189 (offset -12 lines).
> >>>>> > patching file drivers/gpio/Makefile
> >>>>> > Hunk #1 FAILED at 14.
> >>>>> > 1 out of 1 hunk FAILED -- saving rejects to file
> >>>>> drivers/gpio/Makefile.rej
> >>>>> > patching file drivers/gpio/rdc321x_gpio.c
> >>>>> > patching file drivers/gpio/Kconfig
> >>>>> > Hunk #1 succeeded at 75 with fuzz 2 (offset 12 lines).
> >>>>> > Hunk #2 FAILED at 215.
> >>>>> > 1 out of 2 hunks FAILED -- saving rejects to file
> >>>>> drivers/gpio/Kconfig.rej
> >>>>> > patching file drivers/gpio/Makefile
> >>>>> > Hunk #1 FAILED at 14.
> >>>>> > 1 out of 1 hunk FAILED -- saving rejects to file
> >>>>> drivers/gpio/Makefile.rej
> >>>>> > The next patch would create the file drivers/gpio/rdc321x_gpio.c,
> >>>>> > which already exists! Assume -R? [n] n
> >>>>> > Apply anyway? [n] n
> >>>>> > Skipping patch.
> >>>>> > 1 out of 1 hunk ignored -- saving rejects to file
> >>>>> > drivers/gpio/rdc321x_gpio.c.rej
> >>>>> > *from rdc321x_gpio.c.rej*
> >>>>> > ... very long text
> >>>>> > Please note that I don't have experience with this, only followed the
> >>>>> wiki
> >>>>> > and tried to put the pieces together, please apologize for any dumb
> >>>>> mistake!
> >>>>> > Also tried with kernel 2.6.30.5 making small adjustments into my
> >>>>> scripts but
> >>>>> > It also fails whem applying the gpio patches.
On Wed, Sep 2, 2009 at 9:02 PM, bifferos <biffe...@yahoo.co.uk> wrote:
> No, you're not doing anything wrong. I thought I had this working,
> but it seems not, because I managed to get the same behaviour as you
> with one of my patches. I also managed to have this working another
> time, so I'm not quite sure what is going on.
> On Sep 2, 6:28 pm, Razvan Dragomirescu <razvan.dragomire...@gmail.com>
> wrote:
> > Hi guys,
> > I seem to have GPIO working for the output (turning the _red_ LED on and
> > off), but I can't seem to be able to read that d**n reset button. Here's
> > what I do:
> > echo 15 > /sys/class/gpio/export
> > echo in > /sys/class/gpio/gpio15/direction (this is probably not needed
> > since the pins are set to input as the default anyway)
> > Every time I do "cat /sys/class/gpio/gpio15/value" it always comes out as
> > "1", regardless of the status of the button (pressed or not pressed).
> I've
> > also tried to read all the values from gpio1 to gpio15 and all of them
> are
> > "stuck" to 1, so unless the GPIO for the reset button is >16 there's
> > something wrong with the driver.
> > Biff, did you check input too? Am I doing anything wrong?
> > >> I'm just waiting for the compilation, will post results soon!
> > >> Thanks Razvan!
> > >> On Tue, Sep 1, 2009 at 10:59 PM, Razvan Dragomirescu <
> > >> razvan.dragomire...@gmail.com> wrote:
> > >>> Can you check your .config to see if CONFIG_GPIO_SYSFS is set? That's
> > >>> the option that makes the /sys/class/gpio appear (as far as I can
> tell).
> > >>>> On Tue, Sep 1, 2009 at 12:08 PM, bifferos <biffe...@yahoo.co.uk>
> wrote:
> > >>>>> I've just uploaded version 3 - try that instead (with 2.6.30.5).
> > >>>>> cheers,
> > >>>>> Biff.
> > >>>>> On Sep 1, 1:13 am, Nelson Neves <nelson.s.ne...@gmail.com> wrote:
> > >>>>> > Hi,
> > >>>>> > I've been having some hard time trying to get this to work on my
> > >>>>> > OnFlashSystem with kernel 2.6.30.2, some tips would be very
> welcome.
> > >>>>> I
> > >>>>> > followed the instructions from here:
> > >>>>> > Being a bit dumb I have create this set of custom script to
> automate
> > >>>>> the
> > >>>>> > creation of the OnFlashSystem (just need to run the script on the
> > >>>>> numeric
> > >>>>> > order):
> > >>>>> > This seems to be working (I only tested the basic stuff, don't
> know
> > >>>>> if I
> > >>>>> > have all the necessary patches applied correctly). But I'm having
> > >>>>> some
> > >>>>> > difficulty applying the gpio patches from here:
> > >>>>>http://sites.google.com/site/bifferboard/Home/gpio
> > >>>>> > I got this:
> > >>>>> > ./7-applypatches
> > >>>>> > patching file drivers/gpio/Kconfig
> > >>>>> > Hunk #2 succeeded at 189 (offset -12 lines).
> > >>>>> > patching file drivers/gpio/Makefile
> > >>>>> > Hunk #1 FAILED at 14.
> > >>>>> > 1 out of 1 hunk FAILED -- saving rejects to file
> > >>>>> drivers/gpio/Makefile.rej
> > >>>>> > patching file drivers/gpio/rdc321x_gpio.c
> > >>>>> > patching file drivers/gpio/Kconfig
> > >>>>> > Hunk #1 succeeded at 75 with fuzz 2 (offset 12 lines).
> > >>>>> > Hunk #2 FAILED at 215.
> > >>>>> > 1 out of 2 hunks FAILED -- saving rejects to file
> > >>>>> drivers/gpio/Kconfig.rej
> > >>>>> > patching file drivers/gpio/Makefile
> > >>>>> > Hunk #1 FAILED at 14.
> > >>>>> > 1 out of 1 hunk FAILED -- saving rejects to file
> > >>>>> drivers/gpio/Makefile.rej
> > >>>>> > The next patch would create the file drivers/gpio/rdc321x_gpio.c,
> > >>>>> > which already exists! Assume -R? [n] n
> > >>>>> > Apply anyway? [n] n
> > >>>>> > Skipping patch.
> > >>>>> > 1 out of 1 hunk ignored -- saving rejects to file
> > >>>>> > drivers/gpio/rdc321x_gpio.c.rej
> > >>>>> > *from rdc321x_gpio.c.rej*
> > >>>>> > ... very long text
> > >>>>> > Please note that I don't have experience with this, only followed
> the
> > >>>>> wiki
> > >>>>> > and tried to put the pieces together, please apologize for any
> dumb
> > >>>>> mistake!
> > >>>>> > Also tried with kernel 2.6.30.5 making small adjustments into my
> > >>>>> scripts but
> > >>>>> > It also fails whem applying the gpio patches.
I've updated my semi-automated scripts to get OnFlashSystem up and running a bit more easily, sort of a helper for beginners, thought that may be useful to someone in the robotics/electronic hobbyist/etc. Just need to follow the numbers! It's a bit hard-coded, so I advise to run through it just to get the idea. Included Biff's python script to flash the board, hope that you don't mind (I can always remove your scripts and fetch them from SVN if you prefer!). If you are going to flash board from the scripts please change the MAC address from 93-... script.
One can always pick a prepared flash image from the wiki, but this is nice to get your hands and start playing with it! No need to wget later from image, you can prepare it yourself with your extra binaries on it!
Once again, thanks for your help,
Regards,
Nelson.
ps: also have some of this numbered scripts stuff over OpenWrt, if anyone needs it I can share it!
Sorry it took so long. I fixed a problem, re-tested and now it looks
good.
I have combined all required 2.6.30.5 patches into a single, large
patch. All details are here:
> On Wed, Sep 2, 2009 at 9:02 PM, bifferos <biffe...@yahoo.co.uk> wrote:
> > No, you're not doing anything wrong. I thought I had this working,
> > but it seems not, because I managed to get the same behaviour as you
> > with one of my patches. I also managed to have this working another
> > time, so I'm not quite sure what is going on.
> > On Sep 2, 6:28 pm, Razvan Dragomirescu <razvan.dragomire...@gmail.com>
> > wrote:
> > > Hi guys,
> > > I seem to have GPIO working for the output (turning the _red_ LED on and
> > > off), but I can't seem to be able to read that d**n reset button. Here's
> > > what I do:
> > > echo 15 > /sys/class/gpio/export
> > > echo in > /sys/class/gpio/gpio15/direction (this is probably not needed
> > > since the pins are set to input as the default anyway)
> > > Every time I do "cat /sys/class/gpio/gpio15/value" it always comes out as
> > > "1", regardless of the status of the button (pressed or not pressed).
> > I've
> > > also tried to read all the values from gpio1 to gpio15 and all of them
> > are
> > > "stuck" to 1, so unless the GPIO for the reset button is >16 there's
> > > something wrong with the driver.
> > > Biff, did you check input too? Am I doing anything wrong?
> > > >>> Can you check your .config to see if CONFIG_GPIO_SYSFS is set? That's
> > > >>> the option that makes the /sys/class/gpio appear (as far as I can
> > tell).
> > > >>>> On Tue, Sep 1, 2009 at 12:08 PM, bifferos <biffe...@yahoo.co.uk>
> > wrote:
> > > >>>>> I've just uploaded version 3 - try that instead (with 2.6.30.5).
> > > >>>>> cheers,
> > > >>>>> Biff.
> > > >>>>> On Sep 1, 1:13 am, Nelson Neves <nelson.s.ne...@gmail.com> wrote:
> > > >>>>> > Hi,
> > > >>>>> > I've been having some hard time trying to get this to work on my
> > > >>>>> > OnFlashSystem with kernel 2.6.30.2, some tips would be very
> > welcome.
> > > >>>>> I
> > > >>>>> > followed the instructions from here:
> > > >>>>> > Being a bit dumb I have create this set of custom script to
> > automate
> > > >>>>> the
> > > >>>>> > creation of the OnFlashSystem (just need to run the script on the
> > > >>>>> numeric
> > > >>>>> > order):
> > > >>>>> > This seems to be working (I only tested the basic stuff, don't
> > know
> > > >>>>> if I
> > > >>>>> > have all the necessary patches applied correctly). But I'm having
> > > >>>>> some
> > > >>>>> > difficulty applying the gpio patches from here:
> > > >>>>>http://sites.google.com/site/bifferboard/Home/gpio
> > > >>>>> > I got this:
> > > >>>>> > ./7-applypatches
> > > >>>>> > patching file drivers/gpio/Kconfig
> > > >>>>> > Hunk #2 succeeded at 189 (offset -12 lines).
> > > >>>>> > patching file drivers/gpio/Makefile
> > > >>>>> > Hunk #1 FAILED at 14.
> > > >>>>> > 1 out of 1 hunk FAILED -- saving rejects to file
> > > >>>>> drivers/gpio/Makefile.rej
> > > >>>>> > patching file drivers/gpio/rdc321x_gpio.c
> > > >>>>> > patching file drivers/gpio/Kconfig
> > > >>>>> > Hunk #1 succeeded at 75 with fuzz 2 (offset 12 lines).
> > > >>>>> > Hunk #2 FAILED at 215.
> > > >>>>> > 1 out of 2 hunks FAILED -- saving rejects to file
> > > >>>>> drivers/gpio/Kconfig.rej
> > > >>>>> > patching file drivers/gpio/Makefile
> > > >>>>> > Hunk #1 FAILED at 14.
> > > >>>>> > 1 out of 1 hunk FAILED -- saving rejects to file
> > > >>>>> drivers/gpio/Makefile.rej
> > > >>>>> > The next patch would create the file drivers/gpio/rdc321x_gpio.c,
> > > >>>>> > which already exists! Assume -R? [n] n
> > > >>>>> > Apply anyway? [n] n
> > > >>>>> > Skipping patch.
> > > >>>>> > 1 out of 1 hunk ignored -- saving rejects to file
> > > >>>>> > drivers/gpio/rdc321x_gpio.c.rej
> > > >>>>> > *from rdc321x_gpio.c.rej*
> > > >>>>> > ... very long text
> > > >>>>> > Please note that I don't have experience with this, only followed
> > the
> > > >>>>> wiki
> > > >>>>> > and tried to put the pieces together, please apologize for any
> > dumb
> > > >>>>> mistake!
> > > >>>>> > Also tried with kernel 2.6.30.5 making small adjustments into my
> > > >>>>> scripts but
> > > >>>>> > It also fails whem applying the gpio patches.
