GP2X Gp2x Entropy On Startup.

[Daid]

I've build an MP3 player application which autoruns on my GP2x, to use it as a MP3 player.
It starts playing directly when it starts, so it's just a 'switch on' and 30 seconds later I have music.

However, the shuffle function always generates the same songs, this because the startup sequence is always the same, which makes my "srand(time(NULL))" call useless.

Is there any hardware register or something I could read for some entropy?
Or am I better off with putting my seed on the SD card for the next run?

 

[Vimacs]

You could probably get some entropy from the (battery)adc pin, maybe some other sources as well.
I remember that other people had the same problem, there are solutions.

In your case it may be enough if you store a random seed when quitting the app and reread it on the next startup? should be "good enough".

 

[ledow]

time() only gives you second resolution.
gettimeofday() should give you up to microsecond resolution, which might be enough to pick up on some amount of inherent entropy in certain subsystems, but it's not such a nice structure to play with.

 

[Exophase]

GP2X's real time clock isn't powered, so it starts at the same value every time you power it on (the common seed you're seeing). The system may not be indeterministic enough such that there's any noticeable variation in time of events. I'd go with vimacs idea to store a file persistently retaining the seed.

 

[Daid]

the tv_usec of gettimeofday seems to be a bit random at least. Combining that with the adc jitter and I think I have a reasonable seed:
CODE
struct timeval tv;
gettimeofday(&tv, NULL);
int seed = tv.tv_usec;
for(int i=0;i2;i+=2)
{
seed ^= (batterycharge() & 0x03) << i;
}
srand(seed);


Thanks all

 

[ledow]

GP2X's real time clock isn't powered, so it starts at the same value every time you power it on (the common seed you're seeing). The system may not be indeterministic enough such that there's any noticeable variation in time of events. I'd go with vimacs idea to store a file persistently retaining the seed.

Yeah, I know. But there's a lot to "settle" in the first few seconds of boot up that can give you a few bits, at least, of entropy - SD card read times, boot times, battery charge, clock stablisation, etc. It doesn't need *much* but even a microsecond here or there is enough to provide a bit of entropy enough for something like this - with time() you won't pick up on that, with gettimeofday() you will. I'm not saying I'd use it to generate my SSH keys, but it should be enough to pick a random song in a menu or similar.

If all else failed, /dev/random would probably have a few bits of entropy by the time the programs loaded too and you could use that as a seed value. The Linux kernel pulls in entropy from surprising sources and even when you don't press any buttons at all, there's always some slight mis-timings in interrupts and external devices that can be used - especially in any machine where there is more than one chip at work.

Seed-preservation is probably the best solution for "real" randomness, e.g. SSH keys etc. but if you can pull anything out of a fairly-random source (battery life, the number of interrupts to have fired in /proc/interrupts, etc.), that should be fine for other such purposes. The GP2X's problem is not so much the lack of an RTC, but a very-deterministic boot time, solid-state storage, lack of built-in networking etc. which are the normal sources of early-boot entropy.

I have tried to use a number of seeds in games on the GP2X in the past, including the time since boot up and the time since SDL initialisation in as high res as I can get and, to be honest, they aren't much better than just using /dev/random even when you are auto-running on boot.

 

[quasist]

you mean SDL_GetTick()?

 

[slaanesh]

Is there a hack to get the GP2X's RTC powered up?
I guess the Wiz won't have a power RTC either?

You know, it's not that I need another clock, but it's very handy to have a clock for uses such as dating file mod times, etc.