Status update as of 11/1/05

 

Completed Tasks

Note: All tasks listed were executed by both Deepa and Tricia

1.      We read through the 405LP manual and other literature referenced in our original proposal in order to acquaint ourselves with the project. Specific areas of the 405LP user manual that we focused on were Chapter 6 Clocking, Chapter 10 Timer Facilities, Chapter 12 Clock and Power Management, Chapter 13 Advanced Power Management, and Chapter 14 Real Time Clock Operations.

2.      We looked through example source code that was given to us including example.c and temp.c. Additionally, We executed example on sys50 and looked at the output. However, the ibm.tgz file that was delivered to us did not have all of the kernel source files. In order to obtain this, we did a search on toss and found a tgz (dated Sept 23) in /home/yzhu2. Therefore, we are not sure we are using the correct version.

3.      We explored Linux kernel files which included at least the following:

§         linuxppc_2_4_devel-pm/drivers/dpm/dpm-syscall.c -> DPM driver

§         (generic) linuxppc_2_4_devel-pm/arch/ppc/platforms/beech.c maybe *.S

§         linuxppc_2_4_devel-pm/arch/ppc/platforms/ibm405lp.h

§         linuxppc_2_4_devel-pm/arch/ppc/platforms/ibm405lp_pm.c

o        suspend_operating_point(enum apm_sleep_type mode) static int

o        suspend_handler(enum apm_sleep_type mode)

§         linuxppc_2_4_devel-pm/Documentation/powerpc/405LP-sleep.txt

4.      We experimented with the proc interface via the command line by issuing the following commands:

§         echo clock-suspend > /proc/sys/sleep/mode (Changes the sleep mode)

§         echo 15:00:00 > /proc/sys/sleep/pm_alarm (Sets the wake-up time)

§         echo 1 > /proc/sys/sleep/suspend (Initiates the suspend)

The one problem we had was in regards to the sleep mode that was set. The two sleep modes we tried were ‘clock-suspend’ and ‘suspend’. The clock-suspend worked as expected.  When we set the mode to ‘suspend’, we were able to suspend the board but when the LCD screen came back on, we were still unable to reestablish a network connection. In order for us to be able to ping the board again, we actually had to press the U2 button to restart the system. After the system restarted a red LED came on and we had to press the U65 button for the system to resume as expected.

5.      We also experimented with the suspend button (U63) on the board. We had the same issue as above. If the mode set in the proc interface was ‘clock-suspend’ the button worked as expected, but if it was set to ‘suspend’ we could not get the board to resume by pressing U63 again.

6.      After getting the proc interface to work via the command line, we worked with the file temp.c. First we modified it in order to get a clean compile and then modified it since it did not work properly due to how it was writing to the proc files.

 

Open Issues

1.      We need to ensure we have the right kernel source before doing any flashes of the kernel.

2.      We need to understand why when we set the mode to suspend it does not work as expected.

3.      We need to understand the granularity provided by the available clocks. From our current understanding the RTC value can only be read with the highest precision of seconds based on what we have read in section 14.4 of the 405LP user manual (p. 308) which shows the registers available for reading the RTC value.

4.      We need to understand which registers and clocks are available to us even in a suspended mode. The Documentation/powerpc/405lp-sleep.txt states "The RTC remains active during sleep, but the timebase does not…". Need to understand the PIT as well to determine if this is available to us during a suspend. If the PIT is available, we could possibly use the RTC to drive the PIT and use that to calculate the time.

 

Milestones/Tasks

1.      Address open issues especially in regards to understanding timers and registers available during suspend modes. Enabling better granularity than 1 second (Nov 7).

2.      Flashing the kernel with the new code and running tests via an application driver to determine overhead (Nov 14).

(The following are stretch goals, dependent on successful completion of previous milestones)

3.      Expanding application driver to test the various sleep modes. Begin incorporation into scheduler (Nov 21).

4.      Incorporation into scheduler (Nov 28).