aboutsummaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2015-11-21ns16550: unify serial_omapThomas Chou8-13/+14
Unify serial_omap, and use the generic binding. Signed-off-by: Thomas Chou <thomas@wytron.com.tw> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-11-21ns16550: unify serial_tegraThomas Chou1-1/+2
Unify serial_tegra, and use the generic binding. Signed-off-by: Thomas Chou <thomas@wytron.com.tw> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-11-21ns16550: unify serial_dwThomas Chou3-3/+3
Unify serial_dw, and use the generic binding. Signed-off-by: Thomas Chou <thomas@wytron.com.tw> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-11-21ns16550: unify serial_keystoneThomas Chou1-1/+1
Unify serial_keystone, and use the generic binding. Signed-off-by: Thomas Chou <thomas@wytron.com.tw> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-11-19sandbox: Enable USB keyboardSimon Glass1-1/+1
Enable the USB keyboard on sandbox, now that we have a suitable emulation driver. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-11-19usb: sandbox: Add a USB emulation driverSimon Glass1-0/+20
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>
2015-11-19usb: sandbox: Add support for interrupt operationsSimon Glass1-0/+11
Allow USB device emulation to support interrupt URBs so that we can use USB keyboards with sandbox. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-11-19Revert "dm: Export device_remove_children / device_unbind_children"Simon Glass1-26/+0
This reverts commit bb52b367f6ca4a3a918e77737f4ff6a1089912d9. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-11-19sandbox: usb: Allow finding a USB emulator for a deviceSimon Glass1-0/+10
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>
2015-11-19dm: core: Add safe device iteration macrosSimon Glass2-0/+27
Add iteration macros which support unbinding a device within the loop. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-11-19usb: Refactor USB tree output code for testingSimon Glass1-0/+8
Allow the 'usb tree' command to be used from test code, so that we can verify that it works correctly. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-11-19sandbox: Enable console recording and silent consoleSimon Glass1-0/+1
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>
2015-11-19console: Add a console bufferSimon Glass2-0/+28
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>
2015-11-19Add a circular memory buffer implementationSimon Glass1-0/+246
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>
2015-11-19Move console definitions into a new console.h fileSimon Glass2-17/+30
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>
2015-11-19x86: qemu: Convert to use driver model keyboardBin Meng1-1/+1
Convert to use driver model keyboard on QEMU. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-11-19x86: crownbay: Convert to use driver model keyboardBin Meng1-1/+1
Convert to use driver model keyboard on Intel Crown Bay. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
2015-11-19input: Change LED state bits to conform i8042 compatible keyboardBin Meng1-2/+2
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>
2015-11-19input: Convert 'keyboard' driver to use input librarySimon Glass1-0/+5
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>
2015-11-19input: Convert i8042 to driver modelSimon Glass1-6/+0
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>
2015-11-19Drop CONFIG_ISA_KEYBOARDSimon Glass2-10/+0
This option is mentioned but does not do anything. Drop it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-19x86: Add an i8042 device for boards that have itSimon Glass5-8/+2
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>
2015-11-19input: Allow updating of keyboard LEDsSimon Glass1-1/+13
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>
2015-11-19input: Support the German keymapSimon Glass1-1/+2
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>
2015-11-19sandbox: add a sandbox timer and basic testThomas Chou1-0/+2
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>
2015-11-19input: Allow repeat filtering to be disabledSimon Glass1-0/+19
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>
2015-11-19input: Add a function to add a keycode to the existing setSimon Glass1-0/+20
Most keyboards can be scanned to produce a list of the keycodes which are depressed. With the i8042 keyboard this scanning is done internally and only the processed results are returned. In this case, when a key is pressed, a 'make' code is sent. When the key is released a 'break' code is sent. This means that the driver needs to keep track of which keys are pressed. It also means that any protocol error can lead to stuck keys. In order to support this type of keyboard, add a function when can be used to provide a single keycode and either add it to the list of what is pressed or remove it from the list. Then the normal input_send_keycodes() function can be used to actually do the decoding work. Add debugging to display the ASCII characters written to the input queue also. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-19video: Drop unused console functionsSimon Glass4-4/+0
CONFIG_CONSOLE_CURSOR, CONFIG_SYS_CONSOLE_BLINK_COUNT and CONFIG_CONSOLE_TIME are not used by any board. The implementation is not great and stands in the way of a refactor of i8042. Drop these for now. They can be re-introduced quite easily later, perhaps with driver-model real-time-clock (RTC) support. When reintroducing, it might be useful to make a few changes: - Blink time would be more useful than blink count - The confusing #ifdefs should be avoided - The time functions should support driver model - It would be best keyed off console_tstc() or some similar idle loop rather than a particular input driver (i8042 in this case) Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-19dm: tegra: Convert keyboard driver to driver modelSimon Glass1-1/+0
Adjust the tegra keyboard driver to support driver model, using the new uclass. Make this the default for all Tegra boards so that those that use a keyboard will build correctly with this driver. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-11-19cros_ec: Use udevice instead of cros_ec_dev for keyboard functionsSimon Glass1-2/+2
In preparation for converting the cros_ec keyboard driver to driver model, adjust the cros_ec functions it will use to use a normal struct udevice. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-11-19input: Add the keycode translation tables separatelySimon Glass1-0/+10
Require the caller to add the keycode translation tables separately so that it can select which ones to use. In a later patch we will add the option to add German tables. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-19input: Add a device pointer to the input configSimon Glass1-0/+1
The read_keys() method in input is passed a struct input_config. Add a device pointer there so that we can find out the device that is referred to with driver model. Once all drivers are converted we can update the input structure to use driver model instead. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-19dm: input: Create a keyboard uclassSimon Glass1-0/+79
Add a uclass for keyboard input, mirroring the existing stdio methods. This is enabled by a new CONFIG_DM_KEYBOARD option. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2015-11-19dm: usb: Add support for USB keyboards with driver modelSimon Glass1-0/+1
Switch USB keyboards over to use driver model instead of scanning with the horrible usb_get_dev_index() function. This involves creating a new uclass for keyboards, although so far there is no API. Signed-off-by: Simon Glass <sjg@chromium.org>
2015-11-19Merge branch 'master' of git://git.denx.de/u-boot-spiTom Rini1-0/+2
2015-11-19zynq: sdhci: Define max clock by macroMichal Simek3-0/+5
zc1571 with silicon can operate on 200MHz maximum frequency. Setup this frequency by default and fix setting for ep108. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2015-11-19tools: zynqimage: Add Xilinx Zynq boot header generation to mkimageNathan Rossi1-1/+2
As with other platforms vendors love to create their own boot header formats. Xilinx is no different and for the Zynq platform/SoC there exists the "boot.bin" which is read by the platforms bootrom. This format is described to a useful extent within the Xilinx Zynq TRM. This implementation adds support for the 'zynqimage' to mkimage. The implementation only considers the most common boot header which is un-encrypted and packed directly after the boot header itself (no XIP, etc.). However this implementation does take into consideration the other fields of the header for image dumping use cases (vector table and register initialization). Signed-off-by: Nathan Rossi <nathan@nathanrossi.com> Cc: Michal Simek <michal.simek@xilinx.com> Cc: Tom Rini <trini@konsulko.com> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2015-11-19ARM64: zynqmp: Enable TI phy by defaultMichal Simek1-0/+1
Enable TI phy for Xilinx ZynqMP platform. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2015-11-19net: phy: Add support for Texas Instruments DP83867Edgar E. Iglesias1-0/+1
Code is taken from Linux kernel driver (v4.2). Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Tom Rini <trini@konsulko.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
2015-11-19ARM: zynq: Choose boot image based on OF_SEPARATE macroMichal Simek1-1/+1
OF_CONTROL is enabled by default for all Zynq boards. The difference between two boot images is done by OF_SEPARATE or OF_EMBED macros. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2015-11-18powerpc/83xx: add support for kmtegr1 boardValentin Longchamp1-4/+61
This board uses the same CPU (8309) as VECT1. The memory however is different since it has NAND Flash, the NOR Flash partitioning is different and of course the FPGAs as well. Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com> Signed-off-by: Christoph Dietrich <christoph.dietrich@keymile.com>
2015-11-18km8309: change the default QE_FW addressValentin Longchamp1-2/+4
It should be after the u-boot reserved sectors and before the env sectors, since the solution used for kmvect1 (tell the linker to put the firmware into the u-boot produced binary, at the end of the area) should be the exception. The #define is only "conditional" so that we can still support kmvect1. Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
2015-11-18km83xx: use CONFIG_ENV_ADDR for the newenv env commandValentin Longchamp1-2/+6
The hardcoded value are bad, since the address could change between different boards. Furthermore, the relevant #defines are set only if #undefined here, so that they can be changed by some boards if required. Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
2015-11-18powerpc/km8360: fix the ODT parameters for CS0Valentin Longchamp1-2/+2
The ODT parameters for km8360 set the ODT_WR_ACS bit in u-boot KM-2011.09 that is used in the release bootpackage for kmcoge5ne. During the transition from the kmeter1 to km8360 this was changed to ODT_RD_ONLY_CURRENT, which is uncorrect and causes faulty RAM accesses at low temperatures. This is now changed to ODT_WR_ONLY_CURRENT which is the equivalent of ODT_WR_ACS. Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
2015-11-18powerpc/km8309: define CONFIG_SYS_DDRCDRValentin Longchamp1-0/+6
For consistency with all the other km83xx plaforms, this should also be defined for km8309. The same settings as for km8321 are taken. Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
2015-11-18powerpc/km8321: define CONFIG_SYS_DDRCDRValentin Longchamp1-0/+6
On the km8321 boards is CONFIG_SYS_DDRCDR not defined, which leads to the DDRCDR not being configured at startup and still containing the reset value. The required settings for our km8321 hardware designs are different than the reset value and must be set with CONFIG_SYS_DDRCDR, that is used by mpc83xx's cpu_init_f function at early CPU initialization. The important settings are the DDR2 internal voltage level and the half-strength "drivers". In our case where the DRAM chips are soldered on board and the routing for these signals under control, half-strength is sufficient as a few measurements done in the lasts have shown. Since all the hardware qualification tests have been performed with half strength, the nominal strength settings are removed in favor of the default reset half strength settings. Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
2015-11-18km/powerpc: move open firmware defines to km-powerpc.hHolger Brunck3-6/+4
We use the same settings for open firmware defines on all our powerpc targets, so move them from the CPU specific headers to the common powerpc header. Signed-off-by: Holger Brunck <holger.brunck@keymile.com> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
2015-11-18km/powerpc: increase space for kernel imange and FDT blobHolger Brunck1-3/+3
128kByte and 3,986MB may be in the future too little for kernel the fdt blob respectively the kernel image. So increase the reserved areas here, we have the space for this. Signed-off-by: Holger Brunck <holger.brunck@keymile.com> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
2015-11-18powerpc/83xx: add support for kmtepr2 boardChristoph Dietrich1-7/+36
This board is similar to TUXX1, but it has differend FPGAs. Signed-off-by: Christoph Dietrich <christoph.dietrich@keymile.com> Signed-off-by: Andreas Huber <andreas.huber@keymile.com> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
2015-11-18km: update the boot script to check for a DTBValentin Longchamp4-2/+11
If a DTB is found with cramfsls, the bootscript continues as expected. If none is found, the cramfsloadfdt and boot subbootcmds are updated to not load the DTB from cramfs and not pass it to the kernel. The kernel thus must have an appended DTB otherwise the boot will fail. This is required for the km_kirkwood boards that must support .esw where the DTB sometimes is appended (for backwards compatibility) and sometimes is passed correctly (as we do now for all newer boards). Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com> Reviewed-by: Heiko Schocher <hs@denx.de>