Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
I have made my first couple of runs of chkbutton under strace. One thing I have found, is that it uses the existance of the files /tmp/shutdown, /tmp/ledgreen, /tmp/idegreen, /tmp/ledred, /tmp/idered, /tmp/ledoff, /tmp/ledrmd, /tmp/ledgblk, /tmp/ledalloff, /tmp/unloaddrv, /tmp/emailupdate as input. For instance if you " touch /tmp/idered" the HDD led changes color (more yellow than red), though idegreen seems to have no effet.
I also see it writing messages or commands out to ttyS1, I have read some references that memtion a support processor that controls power and such that is connected to the main processor via the serial port.
That is about as far as I have gotten.
Offline
I have found that power and leds are controlled by sending strings to /dev/ttyS1, the ones I have identified so far by looking at the strings in chkbutton and trial and error:
SYN Power led flash, HDD, HDD-Full, USB, WLAN leds off ZWC Turn Power off ZWO Power led solid ZBO Power led flash WLO WLAN led green WLC WLAN led off WBO WLAN flash green then off HDE HDD led yellow HDC HDD-Full led off HBO HDD-Full led flash yellow HDO HDD-Full led yellow * HDN HDD led off MMK USB led green MMF USB led yellow MMC USB led off MMI USB led blink green MUI USB led blink yellow * MMN USB led off AKO TSO Power, HDD, USB, WLAN leds green, HDD-Full yellow TSR Power, HDD-Full, WLAN leds off, HDD, USB leds yellow TSC Power, HDD, HDD-Full, USB, WLAN leds off * not used in chkbutton
I know I have seen mention of this external processor, but can't remember where, if anybody has any information on it, I'd really like to hear.
What I still have not figured out is how the button press is detected.
Last edited by beattie (2007-01-23 03:45:24)
Offline
Just a quick note while I remember it. I've run chkbutton in gdb and I've got as far as catching it when printf is called to print "power off", and managed to go back a bit from that. Unfortunately, the stack trace at that point is not entirely reliable, because if I set a breakpoint at the address before that shown at the top-level in main() itself, the breakpoint is never hit.
I don't know how far anyone else has got with this, but currently, I've only got as far as working out that the address 0x10001010 is definitely hit after the power button is held for 8-10 seconds. I still don't know what has caused it to go down that path.
Other information that might be useful to anyone interested in working out what's going on is as follows.
I got gdb from following the guidelines on this forum to install Gentoo. I can provide the executable, together with libncurses.so.5.4 that it needs, if required, but I'm away from the router, so that will have to wait until later.
PPC tips:
Function calls are made with the "bl" instruction.
Parameters to functions are passed in as $r3, $r4 and so on.
Functions return with the "blr" instruction.
Function return values are passed back in $r0.
Offline
Right now I'm working on the assumption that the switches are connected to input pins on one of the chips. The CPU does not have any GPIOs. It does have some exterbal interrupts. Physical inspection show traces from two of the buttons going near the NEC USB chip. I have not found a reference manual but I'm guessing that it has some input pins. I've tried to register on the NEC website so I can download it, but it's not working for me.
Offline
Bingo!
It's an ioctl on /dev/ttyS1
More to follow.
Offline
Right, I've got it. Most of the information you need should be in the D-Link kernel source code.
Have a look in drivers/char/serial.c in the receive_chars1() function.
It's basically a ioctl(<ttyS1 fd>, GET_BUTTON, &val);
where GET_BUTTON is 0x54E0
and val is a 4 byte integer that is supplied but seemingly unused.
If the power button is pressed, then the return value ANDed with 0x100 will be true.
The source for receive_chars1 should give you a clue as to what the others mean.
Last edited by StevieP (2007-02-10 13:33:36)
Offline
StevieP wrote:
Right, I've got it. Most of the information you need should be in the D-Link kernel source code.
Have a look in drivers/char/serial.c in the receive_chars1() function.
It's basically a ioctl(<ttyS1 fd>, GET_BUTTON, &val);
where GET_BUTTON is 0x54E0
and val is a 4 byte integer that is supplied but seemingly unused.
If the power button is pressed, then the return value ANDed with 0x100 will be true.
The source for receive_chars1 should give you a clue as to what the others mean.
Hey super cool, I was ignoreing that because it looking like there was only a a two wire connection to the mcu that controlles the LEDs. Now I'd guess that the buttons are connected to the Modem control pins of the serial port.
Anyway now I think we can control all the hardware. we can replace all the software.
Looked at the Kernel, nope they are handeling the serial input in the kernel, Have I mentioned how much contempt I have for these guys...that is the worst hack I've seen in a while.
Anyway Thanks StevieP for finding that.
Last edited by beattie (2007-02-10 21:22:12)
Offline
Any updates on this? I tend to kill off the standard daemons in favor of my own when the unit starts up but that leaves the power led in a permanently blinking state. Anyone know how to return it to a solid blue state? Maybe something that can be sent to ttyS1 or /sys/devices/system/leds/leds0/event?
Offline
radiusweb wrote:
Anyone know how to return it to a solid blue state?
echo ZWO > /dev/ttyS1
Try that twice.
But as I understand you got DNS-323 device, in this case none of this might work.
Offline
sala wrote:
But as I understand you got DNS-323 device, in this case none of this might work.
The DNS-323 uses an ioctl on a socket. There's a small program on my site (in old/DNS323-utils, I think) that can do the ioctl.
Offline
sala wrote:
radiusweb wrote:
Anyone know how to return it to a solid blue state?
Code:
echo ZWO > /dev/ttyS1Try that twice.
But as I understand you got DNS-323 device, in this case none of this might work.
For some reason I keep failing to notice which forum I'm posting to. Sort of like hitting "send" before spell check...
Offline
fonz wrote:
sala wrote:
But as I understand you got DNS-323 device, in this case none of this might work.
The DNS-323 uses an ioctl on a socket. There's a small program on my site (in old/DNS323-utils, I think) that can do the ioctl.
This is awesome Fonz. Thank you. What is your site URL?
Offline
radiusweb wrote:
This is awesome Fonz. Thank you. What is your site URL?
www.inreto.de/dns323
PS: Here's the DNS323-leds program: http://www.inreto.de/dns323/old/DNS323-utils/
Let me know if it worked.
Last edited by fonz (2007-04-11 11:33:00)
Offline
Sitting here smiling with an ear to ear grin. Compiles easily, works like a charm!
I have a few questions about "reloaded" which are probably off topic. Shall I email you (at your address on your web server)? Or start a new topic?
Offline
radiusweb wrote:
I have a few questions about "reloaded" which are probably off topic. Shall I email you (at your address on your web server)? Or start a new topic?
There are two related threads in the DNS323 Custom Firmware forum (http://dns323.kood.org/forum/f6-DNS323- … mware.html):
http://dns323.kood.org/forum/t347-Loader-DNS323.html
http://dns323.kood.org/forum/t405-FunPl … ratch.html
I don't mind private email, but since there were a few downloads, others might be interested, too.
Offline
Looks good. I'll check it out.
Offline
fonz wrote:
radiusweb wrote:
This is awesome Fonz. Thank you. What is your site URL?
www.inreto.de/dns323
PS: Here's the DNS323-leds program: http://www.inreto.de/dns323/old/DNS323-utils/
Let me know if it worked.
This LED util still avail - old directory no longer exists....
Thanks
Myk
Offline
mykroft wrote:
This LED util still avail - old directory no longer exists....
Sources are in "utils" directory now. I don't have binaries handy now. If you can't compile yourself, let me know, but it may take a few days until I have time...
Offline
fonz wrote:
mykroft wrote:
This LED util still avail - old directory no longer exists....
Sources are in "utils" directory now. I don't have binaries handy now. If you can't compile yourself, let me know, but it may take a few days until I have time...
If you would not mind - I have not been able to get setup a environment yet on my linux box here at home to be able to compile for this device - but I am still working on it...
Thanks
Offline
mykroft wrote:
I have not been able to get setup a environment yet on my linux box here at home to be able to compile for this device - but I am still working on it...
You may want to have a look at my source directory. The fw103-scripts package contains the scripts I'm using to create the fun-plug toolchain. They work flawlessly on Slackware-current (haven't tested other distros).
Offline
fonz wrote:
sala wrote:
But as I understand you got DNS-323 device, in this case none of this might work.
The DNS-323 uses an ioctl on a socket. There's a small program on my site (in old/DNS323-utils, I think) that can do the ioctl.
Hey, I'm curious about the main power button on the front of the DNS-323. I've got a DNS-323 with debian installed (native not chroot) and i'd like to have a small program similar to the rest of your utilities (which are awesome by the way!) that would poll the power button and run shutdown when it is pressed so i don't have to ssh in to shut it down.
As such i have a few questions:
1. Where is the button(s) connected?
2. Are they accessed via an ioctl() as well?
3. I notice in the kernel source code for the ioctl() (arch/arm/mach-mv88fxx81/SLP/egiga/mv_e_main.c) has a read register function although i can't seem to access the data. Is the button connected to this GPIO register or am I on the wrong track?
Any info would be appreciated. Thanks in advance,
Offline
orbitaudio wrote:
1. Where is the button(s) connected?
2. Are they accessed via an ioctl() as well?
3. I notice in the kernel source code for the ioctl() (arch/arm/mach-mv88fxx81/SLP/egiga/mv_e_main.c) has a read register function although i can't seem to access the data. Is the button connected to this GPIO register or am I on the wrong track?
Depends on your kernel. If you're using 2.6.12.6, I suppose it's accessable via ioctl, too. I don't know the details, though - I think the chkbutton process periodically polls some value to detect button presses. It's connected via GPIO (you may want to check http://git.kernel.org/?p=linux/kernel/g … .c;hb=HEAD - search for "Power Button")
Offline
fonz wrote:
Depends on your kernel. If you're using 2.6.12.6, I suppose it's accessable via ioctl, too.
Yes i am running the stock 2.6.12.6 kernel.
I don't know the details, though - I think the chkbutton process periodically polls some value to detect button presses.
Did you find this out from an strace?
It's connected via GPIO (you may want to check http://git.kernel.org/?p=linux/kernel/g … .c;hb=HEAD - search for "Power Button")
So whats the go with the Orion stuff? I can't seem to find much documentation for any marvell chips which is slightly frustrating.
Also are you running an updated kernel? Is there much to gain from changing kernels?
Offline
orbitaudio wrote:
I don't know the details, though - I think the chkbutton process periodically polls some value to detect button presses.
Did you find this out from an strace?
It's connected via GPIO (you may want to check http://git.kernel.org/?p=linux/kernel/g … .c;hb=HEAD - search for "Power Button")
So whats the go with the Orion stuff? I can't seem to find much documentation for any marvell chips which is slightly frustrating.
Also are you running an updated kernel? Is there much to gain from changing kernels?
I've read kernel code, disassembled chkbutton, and ran it in a debugger. That way, I got the information for the dns323 utils I've written.
You can't find documentation, because it's proprietary stuff. The orion git tree is maintained by marvel engineers, afaik. It's running fine, though I haven't tested (and don't recommend to do so) with dlink firmware. The ioctl interface is gone, the network interfaces becomes eth0 (instead of egiga0), etc. Lots of differences.
Offline
Ok cool.
I'm still keen to get a program running that will check the state of the power button running 2.6.12.6 kernel. Kinda for my own interest. I've been reading the kernel code but seem to be going around in circles.
What do you know about the ioctl() interface? I'm kind of confused as to how everything is connected. From what i understand, a program calls ioctl() with the right parameters via a socket to egiga0. I'm confused as to what happens after that. I know the buttons and leds are connected to GPIO somewhere, but which chip's GPIO are the connected to? The ethernet chips GPIO?
I've disassembled chkbutton but that didn't really get me far as there are too many assembly subroutines going on for functions that i'm not really interested in. My ARM assembly is also not very good. I tried to run strace on it but chkbutton doesn't seem to run with my new debian install
Offline