The DFU protocol implementation in U-Boot is much faster than the
FEL protocol implementation in the boot ROM on Allwinner devices.
Using DFU instead of FEL improves the USB transfer speed from
500-900 KB/s to 3.2-3.7 MB/s. This is particularly useful for
reducing the time needed for booting systems with large initrd
images.
FEL is still useful for loading the U-Boot bootloader and a boot
script, which may then activate DFU in the following way:
setenv dfu_alt_info ${dfu_alt_info_ram}
dfu 0 ram 0
bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}
The rest of the files can be transferred to the device using the
"dfu-util" tool.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add a README with a brief guide to porting serial drivers over to use
driver model.
Add a timeline also. All serial drivers should be converted by the end
of January 2016.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a test that verifies that USB keyboards work correctly on sandbox.
This verifies some additional parts of the USB stack.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a simple USB keyboard driver for sandbox. It provides a function to
'load' it with input data, which it will then stream through to the normal
U-Boot input subsystem. When the input data is exhausted, the keyboard stops
providing data.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add tests that this command produces the right output, even when a rescan
results in a device disappearing from the bus.
Signed-off-by: Simon Glass <sjg@chromium.org>
Each scan of the USB bus may return different results. Existing driver-model
devices are reused when found, but if a device no longer exists it will stay
around, de-activated, but bound.
Detect these devices and remove them after the scan completes.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function should not be used with driver model. While there are users
of USB Ethernet that use driver model for USB but not Ethernet, we have
to keep it around. Add a comment to that effect.
Signed-off-by: Simon Glass <sjg@chromium.org>
Each USB device has an emulator. Currently this can only be found by
supplying the 'pipe' value, which contains the device number. Add a way
to find it directly from the emulated device.
Signed-off-by: Simon Glass <sjg@chromium.org>
We would like the serial number to come from the device tree node name of
the emulated device. This avoids them all having the same name. Adjust the
code to support this.
Signed-off-by: Simon Glass <sjg@chromium.org>
When running sandbox tests, silence the console to avoid unwanted output.
Also, record the console in case tests want to check it.
The -v option can be used to enable stdout during tests.
Signed-off-by: Simon Glass <sjg@chromium.org>
Allow console recording so that tests can use it. Also allow the console
output to be suppressed, to reduce test output 'noise'.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to record console output and provide console input
via a buffer. This provides sandbox with the ability to run a command and
check its output. If the console is set to silent then no visible output
is generated.
This also provides a means to fix the problem where tests produce unwanted
output, such as errors or warnings. This can be confusing. We can instead
set the console to silent and record this output. It can be checked later
in the test if required.
It is possible that this may prove useful for non-test situations. For
example the console output may be suppressed for normal operations, but
recorded and stored for access by the OS. That feature is not implemented
at present.
Signed-off-by: Simon Glass <sjg@chromium.org>
This will be used to support console recording. It provides for a circular
buffer which can be written at the head and read from the tail. It supports
avoiding data copying by providing raw access to the data.
Signed-off-by: Simon Glass <sjg@chromium.org>
The console includes a global variable and several functions that are only
used by a small subset of U-Boot files. Before adding more functions, move
the definitions into their own header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Currently the USB tests take around two seconds to run. Remove these
unnecessary time delays so that the tests run quickly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some tests are slow due to delays which are unnecessary on sandbox. The
worst offender is USB where we lose two seconds. Add a way to disable time
delays.
Signed-off-by: Simon Glass <sjg@chromium.org>
Building with gcc-5.2 raises this warning:
drivers/misc/cros_ec_sandbox.c: In function cros_ec_sandbox_packet:
drivers/misc/cros_ec_sandbox.c:483:5: warning: len may be used uninitialized in this function [-Wmaybe-uninitialized]
if (len < 0)
^
If the function process_cmd() is called with
req_hdr->command == EC_CMD_ENTERING_MODE, the value of len will be
returned uninitialized.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
When 'Num Lock' is not on, we should not send these digit numbers
(0-9 and dot) to the output buffer.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
When sending LED update command to an i8042 compatible keyboard,
bit1 is 'Num Lock' and bit2 is 'Caps Lock' in the data byte. But
input library defines bit1 as 'Caps Lock' and bit2 as 'Num Lock'.
This causes a wrong LED to be set on an i8042 compatible keyboard.
Change the LED state bits to be i8042 compatible, and change the
keyboard flags as well.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
We should request keyboard to turn on/off its LED when detecting
any changes on the LEDs.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Minor changes to allow this to build without CONFIG_DM_KEYBOARD:
Signed-off-by: Simon Glass <sjg@chromium.org>
Currently keyboard's LED state is wrongly saved to config->leds in
process_modifier(). It should really be config->flags.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
This has duplicated scan code tables and logic. We can use the input
library to implement most of the features here.
This needs testing. The only supported board appears to be TQM5200.
Unfortunately no maintainer is listed for this board.
Signed-off-by: Simon Glass <sjg@chromium.org>
Now that i8042 uses driver model, adjust other mentions of it and remove old
code that is no-longer used. Update the README and unify the keyboard text
into one place.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Sometimes we seem to get 0xaa twice which causes the config read to fail.
This causes chromebook_link to fail to set up the keyboard.
Add a check for this and read the config again when detected.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Adjust this driver to support driver model. The only users are x86 boards
so this should be safe.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Some boards have an i8042 device. Enable the driver for all x86 boards, and
add a device tree node for those which may have this keyboard.
Also adjust the configuration so that i8042 is always separate from the VGA,
and rename the stdin driver accordingly. With this commit the keyboard will
not work, but it is fixed in the next commit.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a new option CONFIG_I8042_KEYB which will replace the current
CONFIG_I8042_KBD. This new name fits better with existing drivers.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present the i8042 driver has its own logic and keymaps. In an effort to
unify the code, move it over to use the input library. This changes most of
the keycode-processing logic since it is now in that library. The main
responsibilities of the driver are now to handle the LEDs, deal with the
PS/2 extended keycodes and initialise the the keyboard.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Add a function which returns a new keyboard LED value when the LEDs need
updating.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
When caps lock is enabled we should convert lower case to upper case. Add
this to the input key processing so that caps lock works correctly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Move all the '!release' code into one block so that it is clear that it only
applies on key release.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add support for the German keymap, taken from i8042.c. This can be selected
when the input library it initialised.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Add a sandbox timer which get time from host os and a basic
test.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Simon Glass <sjg@chromium.org>
As mark_bootstage() uses timer, it should go after driver model
is initialized.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Generally the input library handles processing of a list of scanned keys.
Repeated keys need to be generated based on a timer in this case, since all
that is provided is a list of keys current depressed.
Keyboards which do their own scanning will resend codes when they want to
inject a repeating key. Provide a function which tells the input library to
accept repeating keys and not to try to second-guess the caller.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>