Localtime not supported in clock command

[tyama501]

I have been working on porting ELKS to PC-9801 architecture in fork repository and got some trouble setting time zone in elkscmd clock.

There is the following part where getting timezone by gettimeofday but there is no chance to settimeofday before this part. It seems sys_gettimeofday() is needed to obtain tz.tz_minuteswest.

Is this an issue or am I doing something wrong? (My RTC has localtime in it.)

elkscmd/sys_utiles/clock.c /*

• utc_mktime() assumes we're in Greenwich, England. If the CMOS
• clock isn't in GMT, we need to adjust. We'll just use the

• time zone information returned in gettimeofday(). */ systime = utc_mktime(&tm); if (!universal) { struct timezone tz;

    gettimeofday(NULL, &tz);
    systime += tz.tz_minuteswest * 60L;

[ghaerr]

Hello @tyama501,

Thank you for your work on getting ELKS ported to PC-9801 architecture.

I am looking at the clock source at elkscmd/sys_utils/clock.c and it seems it is a bit of a mess, and also complicated.

Right now, ELKS works using UTC in CMOS RTC, and then corrects for localtime by using a handset TZ= environment variable in /etc/profile.

It looks like the clock.c code for dealing with local time in CMOS RTC is commented out, as ELKS checks the timezone offset in the C library tzset() routine. And settimeofday is called after gettimeofday so the tz_minuteswest field is not valid.

The shell may have already set the TZ= environment variable read from /etc/profile, before running the /etc/rc.d/rc.sys script. If this is the case, your problem could possibly be solved by calling the C library routine tzset() instead of gettimeofday in the above code, and referencing an "extern long timezone" to get the timezone from the TZ variable.

Since the C library routines will still use the TZ= environment variable, this will have to be tested further, to see whether using localtime in CMOS RTC with the early TZ= offset works, when the TZ offset is later added back by C library routines.

It appears that the kernel tz_minuteswest field is never set properly by any routine. We also need a way to indicate whether the CMOS RTC is in localtime vs UTC (I think clock -u). If the kernel tz_minuteswest field is set properly, then the default TZ= timezone in /etc/profile could be removed. However, this would also mean changing clock -s to possibly clock -s -u startup /etc/rc.d/rc.sys script on a per-machine basis, which isn't easily done in binary distributions.

I think all this could be avoided by using UTC in RTC. Is that possible? If not, then this issue should probably be relabeled "Localtime in RTC not supported", and further changes made.

I hope this helps, and that I have correctly understood your problem.

Thank you!

[tyama501]

Hello @ghaerr Thank you for reply. I think your understanding is correct.

For me, it is ok to using RTC with UTC, but I am not sure for other user who uses with other OS. (Maybe nobody besides me are using my repository but...)

I will try to use tzset() just for my repository.

I understood it is not bug so it can be relabeled anyway.

[ghaerr]

Hello @tyama501,

For me, it is ok to using RTC with UTC,

Ok, let me know if that solves your problem.

I will try to use tzset() just for my repository.

I would be interested to know whether using tzset solves the problem of using localtime RTC. However, as noted above, the C library time routines automatically call tzset once, which will increment the timezone again, after having already been set (properly?) by clock using settimeofday.

Nonetheless, I'm interested in hearing about your solution.

but I am not sure for other user who uses with other OS. (Maybe nobody besides me are using my repository but...)

I don't know what most PC (or PC-9801) users use for CMOS RTC. @Mellvik, do you have any comments on this?

Thank you!

[tyama501]

Hello @ghaerr,

I modified clock to use tzset() instead of gettimeofday and I also moved clock and date from rc.sys to etc/profile since I couldn't get environment variable in rc.sys. This worked fine for my case.

clock.c //gettimeofday(NULL, &tz); tzset(); //systime += tz.tz_minuteswest * 60L; systime += timezone;

etc/profile export PATH=/bin

• change for localtime export TZ=JST-9
• use clock -u -s if RTC is UTC
• use clock -s if RTC is localtime clock -s date

Here is the result. RTC is local time JST. Dec 07 02:11. clock-r and date shows the local time. l created the new file and ls command also shows the local time.

I also checked the file date in FAT filesystem by opening the image in Windows. The file is recorded with date Dec 06 17:11 which is UTC(JST-9).

[ghaerr]

Hello @tyama501,

Thank you for your work on this!

I will look into making modification over here to use tzset() in clock.c. I think you should be able to get the TZ environment variable in rc.sys by using source /etc/profile; then date and clock can remain in rc.sys, using clock -s -u for RTC in UTC. I will also make note in rc.sys that clock -s can be used if running RTC in localtime.

I will make that modification, test and let you know the results.

Thank you!

[ghaerr]

Hello @tyama501,

I've added your contribution to PR #1041, thank you.

Also, I have looked at your ELKS fork, very nice work! It seems I could further organize ELKS to assist in getting many of your changes upstream into a CONFIG_ARCH_PC98. At this time, I would prefer to keep the CONFIG_ARCH_PC98 ifdefs to a minimum, but could start by reorganizing some header files to make this easier and more organized. Would it help you if that were done? Afterwards, we could discuss how the more complex changes might be integrated through PRs of your own.

Do you have any interest in that?

Thank you!

[tyama501]

Hello @ghaerr ,

Thank you for your support!

Wow that would be nice.

PC-9801 is much different architecture like 1024Bytes per sector for floppy disk, no ide hard disk for older model(SCSI only), a lots of BIOS calls, so may be only particular configuration can be supported, but that would be helpful and interesting.

[ghaerr]

Hello @tyama501,

PC-9801 is much different architecture like 1024Bytes per sector for floppy disk, no ide hard disk for older model(SCSI only), a lots of BIOS calls, so may be only particular configuration can be supported, but that would be helpful and interesting.

I have diff'd our two source trees, I can now see most differences. Thank you for keeping upstream tree merged, that helps. I will categorize changes into those that are mostly different I/O addresses and defines, and those others that are more complicated. Some may involve both of us moving some routines into separate files, instead of having lots of ifdefs. I would like to try to keep the ifdefs to a minimum. I will probably start with making basic structural changes first, and then have you submit PRs into this tree for those that are trickier, since it will be easier for you to emulate and/or test PC-98.

I will open another issue here shortly to track the plans for adding PC98 support into ELKS.

Thank you!

[tyama501]

Hello @ghaerr ,

〉I would like to try to keep the ifdefs to a minimum.

Yes, I agree. Thank you!

[tyama501]

I added an screenshot of PC-9801UV21 booting with the latest image to my repository. It's V30 but indicated as V20. Not sure why now. (RX21 is indicated as 286 that is correct)

[ghaerr]

Hello @tyama501,

You have done a wonderful job porting ELKS to the PC-98. I can see from the screenshot you're booting from 1232K floppy which use 1K sectors, correct? Nice job porting the boot code and getting 1K sectors to work with ELKS. It seems the FAT filesystem driver may still be assuming 512 byte sectors when it reports 616K disk in fat12 format.

Do all PC-98 systems support 4 floppies? I notice that you've added FD2 and FD3 support, but don't see them in the picture.

With regards to the CPU being identified as V20, actually I do not trust the current CPU detection code, that may be removed or updated in the future, since it is incorrect in more than just your case.

I look forward to getting your enhancements and machine support merged into master.

Thank you!

[tyama501]

Hello @ghaerr ,

Thank you for creating #1047 !

I will answer to the questions above at #1047.