Hardware Button Customization

In document Openrg Programmer Guide 5.5 LATEST (Page 97-100)

Board Tailoring

6.5 Hardware Button Customization

Note that the next sector will start at offset 0x000A0000, which is the sum of the previous offset and the previous size.

Notes:

1. The size of the Flash sector should be multiplications of the Flash writing block.

2. It is preferable not to place the boot sector directly before or after the image sector, in case of a writing error.

6.4.2 Dynamic Flash Layout

The dynamic Flash layout feature enables you to modify the Flash layout throughout the production. We recommend using the dynamic Flash layout ONLY if the Flash size will be changed after deployment. There is usually no need for using this feature. The Flash has a designated sector to which you can burn the Flash layout. RGLoader and the OpenRG image search for the Flash layout section at boot time. If it exists, the Flash layout section is loaded and used as the layout. If it does not exist, the RGLoader and the OpenRG image will use the layout with which they were compiled. OpenRG searches for the Flash layout section in the following places:

If you wish to use the dynamic Flash layout, compile your image with the following command:

make config DIST=UML LIC=/rg/jpkg_uml.lic CONFIG_RG_DYN_FLASH_LAYOUT=y && make

The token_set_y("CONFIG_RG_DYN_FLASH_LAYOUT") flag creates the LAYOUT.sec file, which can be used to load to the board using:

OpenRG> flash load -u tftp://<IP>/<LAYOUT> -s <section_number>

6.5 Hardware Button Customization

Hardware buttons can provide an additional, software-independent way in which to implement useful OpenRG features. For example, a user can return to the default factory settings using the Web-based management. By implementing the "restore defaults and reset" button, we provide the user with a way to perform this same function, even if he cannot access the WBM.

6.5.1 Overview

A hardware button is a hardware unit that generates interrupts when pressed, and sometimes when released. Hence, the code that handles the button signals is in the kernel. The code that actually performs the desired action, however, is in the user mode—in Main Task. The standard driver API and the select() system call are used for communicating between these two blocks of code.

Figure 6.2 Hardware Button Logic

Following is a run-through of the interaction between the kernel and user modes when a hardware button is pressed:

1. Kernel mode The hw_button driver consists of two parts—architecture-independent code (module_init(), module_close(), dev_open(), dev_poll(), dev_read()) and dependent code (the button handler). The architecture-dependent code implements the defined API to work with the inarchitecture-dependent code.

2. Kernel mode The driver registers its file operation within rg_major device (minor HW_BUTTON, node name "/dev/openrg.hw_button").

3. User mode To access button information, the user mode code opens the hw_button device and calls select() for the received file descriptor on read operations.

4. Kernel mode The hw_button driver's poll() function calls poll_wait(), to wait for information from any existing button handler.

5. Kernel mode On button interrupt, the button handler calls the btn_action_notify() function (which calls wake_up_interruptible). btn_action_notify() is

implemented for multi-OS compatibility. btn_action_notify() parameters are the button ID and state (BTN_PRESSED, BTN_RELEASED).

6. Kernel mode The btn_action_notify() function adds the event to the hw_button 's driver events queue. Along with the button ID and state, the OS timer value (jiffies) is saved.

7. Kernel mode After poll_wait() has returned, the poll() function sets the

file_operations structure mask field to POLLIN, to inform user mode that the read operation is permitted.

8. User mode The user mode code reads a btn_action_t variable from the driver's file descriptor, to get the button status. It acts according to the role of the button (reset, restore defaults, etc.).

9. Kernel mode The driver's read() function removes the read event from the driver's events queue.

The kernel mode is implemented in the hw_buttons.c and hw_buttons.h files, while the user mode is implemented in uievents.

6.5.2 VxWorks Considerations

In VxWorks, a callback for the select() call is implemented in a quite similar way. The same actions are taken—a driver's function waits on a queue, and an ISR informs about the event by releasing the queue lock. Instead of poll() callback, VxWorks implements select() code in iocl() callback. The logic for releasing the lock is hidden from the ISR by the btn_action_notify() function.

6.5.3 Restore Default Settings Design

The idea behind the 'Restore Defaults' feature is to provide a user with a software-independent way to return to the factory settings values. It is used, for example, when a user has forgotten his password to the system. Restoring the default settings gives him access to OpenRG again.

To restore defaults, the user presses the 'Restore Defaults' button. The button is defined for each platform independently. Some platforms may not have this feature. The BTN_ID_1 button events, defined as BTN_ROLE_RESET, are used for this feature. According to a state of the button, OpenRG implements the following actions:

If the button is pressed, the sys_time value is saved.

• If the button is released, the saved value is compared to the current time. If the time

interval exceeds the predefined value, the default settings are restored. In any case, a restart command is issued.

To restore the defaults, the user should press the button for at least 3 secs.

#define BTN_ROLE_RESET BTN_ID_1

#define RESTORE_DFL_TIMEOUT 250 /* 2.5 secs when compared with jiffies */

In document Openrg Programmer Guide 5.5 LATEST (Page 97-100)

Related documents