As documented in this thread, many people have had difficulties getting apps other than the player to display local time properly. Regardless of the TZ setting, "date" always returns UTC. I tried copying a bunch of files from /usr/share/zoneinfo on another system, but this didn't help the situation (although the files I copied into there became available in the player app's Timezone menu, strangely.) I also tried creating a symlink /etc/localtime which links to my timezone, but still, 'date' returns UTC. It seems that there's some piece of configuration that nobody's found yet that needs to be in place for localtime() to perform time zone correction. Anyone have any ideas?

Also, from what I understand, the player uses UTC internally, but for display purposes, offers the "Timezone" setting. I don't know where that setting is saved, but my initial peeking in the flash savearea tells me it doesn't live there, so I'm guessing it's somewhere on hda3. Can any of the empeg gods enlighten us on exactly where it lives, or at least on what sector? If I can go find that, I won't need to worry about the TZ variable or anything else.

Mmm.. It appears to be stored in bytes 0x51 - 0x53 of the flash savearea. Not sure what the value there actually means yet..

I'm not exactly sure what you mean by ``the TZ setting''. I don't know if you mean within the OS or the player option. Under most, if not all, Unices, the OS's timezone setting is an environment variable set by init before it spawns any other processes, which inherit the variable. The empeg's init does not do this. You should see a difference if you set the environment variable within a shell and then run date. (Remember to export it!) I assume that the variable is TZ, but I could be wrong. There's also the possibility that the empeg's libc doesn't support timezone distinctions, but I doubt it. It's also possible that while you've obviously found the correct directory in which to place the config files for the player that the correct directory for the OS might be elsewhere.

Okay, there are four bytes for timezone info, in the flash savearea at offsets 0x51 0x52 0x53 0x54. These hold subdirectory indexes (alphabetic order assumed) for the timezone info under /usr/share/zoneinfo/

I have mine set to Canada -> Eastern, so the flash savearea shows 1C-04-00-00, which means "the 28th entry" (Canada), and then "the 4th entry" (Eastern). No more subentries for me, but in other parts of the world there may be.

Cheers

Futher to this, /usr/share/localtime is a symlink which normally should point at the appropriate zone file from one of the subdirectories. On the empeg, it points at /etc/localtime.

In this case, /etc/localtime *should* be a symlink pointing back to a file under /usr/share/zoneinfo/..., but instead it simply does not exist. All of the "TZ" operations depend upon this existing, but since it does not exist, no timezone processing is done by the C-library.

I think that perhaps I should have Hijack detect accesses to /etc/localtime, and automatically redirect those back to the correct zoneinfo file, based on the path traversal info from the 4 bytes of the flash savearea. Once this is working, timezone info should be automatic for programs that use the standard time functions, outside of the kernel.

Mmm.. I wonder if I can also get the UTC offset somehow from within the kernel, for the Hijack "clock" function? Dunno how to parse the (largish) zoneinfo files, so I'd rather not do it that way.

???

You da man, Mark. Nice sleuthing.

I think that perhaps I should have Hijack detect accesses to /etc/localtime, and automatically redirect those back to the correct zoneinfo file, based on the path traversal info from the 4 bytes of the flash savearea. Once this is working, timezone info should be automatic for programs that use the standard time functions, outside of the kernel.

That would be a *really* sweet hack.

BTW, I figured out why I wasn't seeing the flash savearea change when I looked at it earlier... I didn't have a /usr/share/zoneinfo directory, because I use my own /usr partition and don't let the player overwrite it. So if you don't have anything there, the player has a default list of time zones, but when you select one, there are no subdirectory entries to point to, hence no change in the flash.

Okay, the libc on the player does indeed look for /etc/localtime, or at least that string exists in the libc file. But I don't seem to have much luck getting it used.

One can do this in bash: export PS1="\@> "
which sets the command prompt to be the 24-hour timeofday, but on my player it just gives me UTC, even when I create /etc/localtime appropriately.
Ditto for the "ls -l" command.

Mmm.. I wonder why it's not working?

-ml

Mmm.. I wonder why it's not working?

Geez, if you're stumped.... What you're doing is pretty much what I did before I posted about this... Including the /etc/localtime symlink. Very strange.

Okay, I just uploaded strace to watch what the code is actually doing when getting the date/time.

Instead of /etc/localtime, the "ls -l" command is trying to access /home/empeg/arm-empeg-linux-new/etc/localtime

So, I created that directory, and symlink'd the file to /etc/localtime (which I've already created previously), and now.. voila! Correct local time is now displayed!

So, I could have Hijack just translate accesses for /home/empeg/arm-empeg-linux-new/etc/localtime into the correct path under /usr/share/zoneinfo, I suppose.

Tricky that, because Hijack would have to sort the directories (the flash savearea values appear to depend upon alphabetic directory order, which is not the REAL directory order..). That gets a little bit ugly to figure out, but perhaps not too bad.

Anyone want to write some code, which given the four indexes (from savearea), traverses the directory tree to find the correct zone file?

Cheers

Hm, from userland it's just:

#include <dirent.h>



int main()

{

	struct dirent **namelist;

	int i, n;



	n = scandir(".", &namelist, 0, alphasort);

	if ( n < 0 )

		perror("scandir");

	else

		for (i=0; i < n; i++ )	printf("%s\n", namelist[i]->d_name);

}

.
Not sure if that helps you, though.

No help there, thanks.

I already do directory parsing in khttpd, but it has ocurred to me that there's another way to do this.. I'll just observe which zonefile the player software accesses, and remap to that!

Should be ready shortly.

-ml

Should be ready shortly.

Awesome.

Hijack get more truly evil every day. I like it.

-brendan

Okay, it's building now, and should be uploaded within 10 minutes or so.

Hijack v375:

-- automatically set up userspace timezone stuff. If you change the timezone in the player, Hijack will not "see" the change until after the next player restart.

-- the timezone information is NOT available until after the first startup of the player after boot.

Cheers

the timezone information is NOT available until after the first startup of the player after boot.

So no help for the TTSclock people (oh well ), but scads of help for what Tony is doing.

Three things..

1. Looks to me like the index.html for Hijack's web page is missing a couple of the relative patches. The patches still exist but I think you probably just clobbered the HTML or something.
2. Just gave it a shot and it works flawlessly.
3. I think it's absolutely sick that you can do something like this in 20 lines. I sincerely hope you don't get paid by the SLOC for your kernel work!

Mark, could we also initialize zoneinfo from config.ini if there's an appropriate entry there? This would allow us to get the right timezone for TTSClock. Or are you saying that we have it by that stage (I'm not sure exactly what stage you mean by "not until after the first startup of the player after boot").

I ought to get around to installing strace myself - I set TZ for TTSclock, but that seems only to affect the DST selection and not the offset; I don't understand why.

/home/empeg/arm-empeg-linux-new/etc/localtime

*tut* Spot the mis-crosscompiled glibc

There's something else affected by this problem as well: locale maybe?

Peter

Mark - the Hijack page is missing diffs for v372-374. I want to try 375, but I'm scared of what might be in it

I've just re-uploaded the index.html for the Hijack site -- last weekend I had to rebuild my local server from backups, and seem to have somehow reverted to an earlier copy of that file.

The relative diffs are all intact, so no worries there.

We could do the timezone fix much earlier -- at config.ini parsing or even before. But this will require adding kernel code to parse the /usr/share/zoneinfo/ subdirectories as described above. A better fix, for sure, but I just don't have the time to do it right now. Patches accepted, though.

Longer term, I thing we should just replace the Linux distron on the Empeg with a newer one, with correct libc (or binary-patched to fix that bug!), and a BusyBox plethora of utilities, including a telnetd (native to BusyBox-1.00pre).

We could fix the zone link then, too, using a custom init that parses /dev/empeg_state to extract the zone path, and then set up appropriate ram-based symlinks and a TZ variable.

Cheers

Mark, could we also initialize zoneinfo from config.ini if there's an appropriate entry there?

Ahh.. I should really pay more attention. So you're asking for a way to set the zoneinfo from config.ini, so that it can be made available earlier. Okay, I can do that, but this setting would then either:

(1) completely override the player's zoneinfo setting, so the player might end up using a diiferent timezone than the add-on software. OR...

(2) the player's timezone could replace the config.ini timezone once the player continues startup (after config.ini, unfortunately).. But this could also be a bit confusing if config.ini and the player's view disagree.

I don't like either solution, myself. Really, Hijack should just do the directory lookup itself earlier on, but.. see my previous posting for that. Patches accepted.

Cheers

Hey, I'm wrong about the alpha-sorting!

The indexes from the savearea are REAL directory entry indexes, counting from zero. Canada is 28 (the 29th entry), and Eastern is 4 (the 5th entry). This makes parsing in kernel space much much simpler.

Maybe I'll have a go at it.

Cheers

Okay, Hijack v376 now sets the timezone link from within the config.ini parsing, before launching apps etc..

Should be available for download in 10-15 minutes from now.

Cheers

Speaking of embarassing paths.. here's one from an strace I did a while back:

/home/empeg/toolchain_binutils-2.10.1_gcc-2.95.3-arm010218_glibc-2.1.3/arm-empeg-linux/share/zoneinfo/Universal

Dunno if it's still there now. Probably.

Cheers

Yup, still there in v2-final:

/home/empeg/toolchain_binutils-2.10.1_gcc-2.95.3-arm010218_glibc-2.1.3/arm-empeg-linux/share/zoneinfo/Universal

/home/empeg/toolchain_binutils-2.10.1_gcc-2.95.3-arm010218_glibc-2.1.3/arm-empeg-linux/share/zoneinfo/Universal

That is indeed quite embarrassing. Cross-compiling entire Linux userlands is not the black art it once was, but the glibc in car-player images hasn't been updated since before I joined Empeg, if ever. It's still somewhere waay down on my v3 wishlist to cross-compile an entire brand-new userland for car-players, with more modern bash, coreutils, glibc. and so on -- at least, if someone fixes my GCC3 PR from like 2001 or if I can get the Apple no-clone-structors patch working for 3.3.[23] for ARM. (The "real-world example" in the PR is, of course, the car-player software.)

Peter

somewhere waay down on my v3 wishlist

Would donations (in the form of libations at The Wrestlers, of course) have any chance of raising this higher on your list? Or do the problems you mentioned preclude you from being able to do it even if you were so motivated?

Or do the problems you mentioned preclude you from being able to do it even if you were so motivated?

I guess it'd be possible to stick with GCC 2 and just update the rest of userland: you wouldn't get glibc 2.3 but you'd get 2.2, and everything else probably still compiles with GCC 2. With a bit of care this could even be done without breaking all third-party userland software: it doesn't bother me whether the backwards compatibility stuff in glibc is bloaty or not, because the player is statically linked with (potentially) entirely its own build of glibc.

What exactly are you hoping for from a new userland?

Peter

For a new userland, I'd simply use the latest BusyBox (www.busybox.net), with nearly *everything* configured for busybox. This would give us nearly 200 very useful userland commands, all in one executable (with lots of symbolic links to itself) that might weigh in at around 500-700KB total. Or slightly more if statically linked with uclibc (instead of glibc).

Built-in webserver, telnet daemon, networking utilities, shell utilities, SHELL (ash), init, etc..

Practically nothing else required except the stuff under /empeg/ and a few files in /etc/ to have a VERY functional Linux system. In less space than the current bash executable alone!

Cheers