Unoffical empeg BBS

Quick Links: Empeg FAQ | RioCar.Org | Hijack | BigDisk Builder | jEmplode | emphatic
Repairs: Repairs

Topic Options
#263036 - 21/08/2005 01:44 Fun with empeg_power
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
According to the comments in arch/arm/special/empeg_power.c, and a couple
of old BBS posts, the empeg's power PIC can wake up the empeg at more or
less user-definable intervals. I've tried to play with this functionality, but
so far I'm not seeing what I expect. Here's what I'm doing:

Code:

int fd = open("/dev/empeg_power", O_RDONLY);
int time = 1;
if (fd < 1)
{
printf("couldn't open empeg_power\n");
exit(-1);
}
int rc = ioctl(fd, EMPEG_POWER_WAKETIME, &time);
sleep(1);
printf("goodbye, cruel world...\n");
rc = ioctl(fd, EMPEG_POWER_TURNOFF, NULL);




So, if I'm understanding the comments in empeg_power.c correctly, the above
code should be setting the power PIC's wakeup timer to wake up the empeg in
roughly 15 seconds, and then powering the empeg off. What I see is the empeg
does indeed power off, but doesn't wake up, or, rather, doesn't boot up.

Now, this part of the empeg_power.c comments is where I'm thinking I might
be losing:

Code:

* If there are no events pending when the system wakes up, it just powers
* itself off again. Generally, this brief flash of power lasts no more than
* 300ms (using 200mA - an average hourly drain of 16uAH).



What I don't understand is "if there are no events pending when the system wakes
up." What's a pending event in this context? Is my code fragment above actually
waking the empeg up, but it's going right back to sleep again? How can I get it to
actually wake itself up and boot into the player, for instance?
_________________________
- Tony C
my empeg stuff

Top
#263037 - 22/08/2005 20:01 Re: Fun with empeg_power [Re: tonyc]
tman
carpal tunnel

Registered: 24/12/2001
Posts: 5528
Appears it won't won't work by default.

Top
#263038 - 23/08/2005 13:52 Re: Fun with empeg_power [Re: tman]
altman
carpal tunnel

Registered: 19/05/1999
Posts: 3457
Loc: Palo Alto, CA
You could try to copy what's in 0xe000 to 0xc000 (though I can't remember if there is any non-relocatable code in there) - this way, it *should* boot if the PIC wakes the unit.

The code at 0xc000 should really check (before booting linux & spinning up the drives) whether the alarm time has been reached.

I've attached the state that the 0xc000 code got to... ie, it just powers down! (complies with gas). If you get something working, please post it - the debug print routines are in the attached code so you can print stuff to help debug it.

Hugo


Attachments
263095-c000.s (326 downloads)


Top
#263039 - 24/08/2005 02:15 Re: Fun with empeg_power [Re: altman]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
Success! Copying e000 to c000 does the trick.

Now, in terms of perfecting it by checking the RTC, I'm afraid my slightly-above-zero knowledge of ARM assembly prevents me from doing that. I guess I'll just be happy with full wakeups "about every hour" for now, unless someone else comes along who's better equipped to do it.
_________________________
- Tony C
my empeg stuff

Top
#263040 - 24/08/2005 03:29 Re: Fun with empeg_power [Re: tonyc]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31600
Loc: Seattle, WA
Quote:
Success! Copying e000 to c000 does the trick.


Off the wall thought, with no actual knowledge of what you're doing: Are those flash addresses? Remember that flash is a limited resource that can handle only so many "burns" before petering out. I don't know what your code is doing, but if it's copying into flash addresses repeatedly, you might consider how many writes it'll take.
_________________________
Tony Fabris

Top
#263041 - 24/08/2005 07:09 Re: Fun with empeg_power [Re: tfabris]
tman
carpal tunnel

Registered: 24/12/2001
Posts: 5528
Quote:
Off the wall thought, with no actual knowledge of what you're doing: Are those flash addresses? Remember that flash is a limited resource that can handle only so many "burns" before petering out. I don't know what your code is doing, but if it's copying into flash addresses repeatedly, you might consider how many writes it'll take.

It's a one off process which Tony did manually. The flash has two short chunks of assembler which do some initialisation and then load the kernel. One gets called when you powerup normally and the other gets called when the empeg wakes up from the power PIC timer. The stock code for the timer wake up just automatically turns the empeg back off again, what Tony has done is copy the code from the normal bootup over the timer one.

Top
#263042 - 24/08/2005 07:12 Re: Fun with empeg_power [Re: tfabris]
matthew_k
pooh-bah

Registered: 12/02/2002
Posts: 2298
Loc: Berkeley, California
No need to worry. When a computer starts up, it jumps to a certain memory address and begins executing the machine code located there. When the empeg does it wake up, it does the same thing, but jumps to machine code located at a different address. What he's doing it replacing the code that says "nope, go back to sleep" with code that says "wake up". Once the wake up code is there, there isn't any need to write over it, much like installing hijack doesn't increase the wear on the flash memory.

That being said, I'm looking forward to seeing how this all ends. Wireless syncing sure sounds like fun.

Matthew

Top
#263043 - 24/08/2005 13:03 Re: Fun with empeg_power [Re: tfabris]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
Yeah, what they said. It's a one-shot deal. But thanks for your concern.
_________________________
- Tony C
my empeg stuff

Top
#263044 - 24/08/2005 13:24 Re: Fun with empeg_power [Re: matthew_k]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
Quote:
That being said, I'm looking forward to seeing how this all ends. Wireless syncing sure sounds like fun.


Yeah. I will probably be releasing the results of my work as some kind of software package, tentatively named "empsyncd." Right now it just sits in the background and waits for accessory to go low, then wakes the empeg up, phones home, runs rsync if it gets an answer, sets the wakeup timer, powers down, lathers, rinses, and repeats. It still needs lots of work but it's "working" at this point.
_________________________
- Tony C
my empeg stuff

Top