summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeLines
* Merge git://git.denx.de/u-boot-dmTom Rini2014-11-24-364/+1048
|\ | | | | | | | | | | | | Conflicts: drivers/serial/serial-uclass.c Signed-off-by: Tom Rini <trini@ti.com>
| * dm: core: remove unnecessary return condition in uclass lookupMasahiro Yamada2014-11-22-3/+0
| | | | | | | | | | | | | | | | | | | | These conditions never happen. - There is no real uclass with UCLASS_INVALID id. - uclass never becomes NULL because ll_entry_start() always returns a valid pointer. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org>
| * dm: core: remove unnecessary return condition in driver lookupMasahiro Yamada2014-11-22-3/+0
| | | | | | | | | | | | | | | | | | | | The variable "drv" never becomes NULL because ll_entry_start() always returns a valid pointer even if there are no entries. The case "n_ents == 0" is covered by the following "for" loop. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org>
| * dm: core: remove meaningless if conditionalMasahiro Yamada2014-11-22-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the variable "ret" is equal to "-ENOENT", it is trapped at [1] and never reaches [2]. At [3], the condition "ret != -ENOENT" is always true. if (ret == -ENOENT) { <------------------ [1] continue; } else if (ret == -ENODEV) { dm_dbg("Device '%s' has no compatible string\n", name); break; } else if (ret) { <------------------ [2] dm_warn("Device tree error at offset %d\n", offset); if (!result || ret != -ENOENT) <------------------ [3] result = ret; break; } Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org>
| * dm: core: a trivial clean upMasahiro Yamada2014-11-22-3/+1
| | | | | | | | | | Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org>
| * cros_ec: Fix uninitialised variable in cros_ec.cSimon Glass2014-11-22-0/+1
| | | | | | | | | | | | | | | | | | This fixes this cppcheck report: [drivers/misc/cros_ec.c:704]: (error) Uninitialized variable: req Signed-off-by: Simon Glass <sjg@chromium.org> Reported-by: Wolfgang Denk <wd@denx.de>
| * dm: spi: Use device_bind_driver() instead of our own functionSimon Glass2014-11-22-37/+2
| | | | | | | | | | | | | | | | | | | | The SPI function does the same thing, so we may as well just use the new generic function. The 'cs' parameter was not actually used, so can be dropped. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com> Acked-by: Heiko Schocher <hs@denx.de>
| * dm: spi: Correct handling of SPI chip selects in sandboxSimon Glass2014-11-22-11/+12
| | | | | | | | | | | | | | | | | | This code was not updated when the chip select handling was adjusted. Fix it to call the correct function. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com> Acked-by: Heiko Schocher <hs@denx.de>
| * dm: Add a function to bind a device by driver nameSimon Glass2014-11-22-0/+34
| | | | | | | | | | | | | | | | | | In some cases we need to manually bind a device to a particular driver. Add a function to do this. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com> Acked-by: Heiko Schocher <hs@denx.de>
| * dm: fdt: Correct handling of aliases with embedded digitsSimon Glass2014-11-22-3/+3
| | | | | | | | | | | | | | | | | | | | Since we scan from left to right looking for the first digit, "i2c0" returns 2 instead of 0 for the alias number. Adjust the code to scan from right to left instead. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de> Reviewed-by: Tom Rini <trini@ti.com>
| * dm: core: Add functions to find parent and OF dataSimon Glass2014-11-22-0/+13
| | | | | | | | | | | | | | | | Add dev_get_parent() as a convenience to obtain the parent of a device. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@ti.com> Acked-by: Heiko Schocher <hs@denx.de>
| * dm: core: Allow access to the device's driver_id dataSimon Glass2014-11-22-6/+30
| | | | | | | | | | | | | | | | | | When the device is created from a device tree node, it matches a compatible string. Allow access to that string and the associated data. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@ti.com> Acked-by: Heiko Schocher <hs@denx.de>
| * dm: i2c: Move error reporting into a common functionSimon Glass2014-11-21-10/+22
| | | | | | | | | | | | | | | | Factor out the common code to make it easier to adjust it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@ti.com> Acked-by: Heiko Schocher <hs@denx.de>
| * dm: Update documentation to include CONFIG_DM... optionsSimon Glass2014-11-21-10/+153
| | | | | | | | | | | | | | Add documentation for the various driver model options that are now available. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: arm: spl: Make driver model linker lists availableSimon Glass2014-11-21-0/+7
| | | | | | | | | | | | | | | | The linker lists feature is useful in SPL as it holds the driver model platform data. So don't throw away the lists. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@ti.com>
| * dm: tegra: Add platform data for the GPIO driverSimon Glass2014-11-21-0/+8
| | | | | | | | | | | | | | | | Add platform data for the GPIO driver. It doesn't need to contain anything since the GPIO driver will actually use information from the CONFIGs for now. This merely serves to ensure that the GPIO driver is bound. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: tegra: Add platform data for the SPL uartSimon Glass2014-11-21-0/+16
| | | | | | | | | | | | | | Since we currently don't have device tree available in SPL, add platform data so the uart works. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: Disable dm_warn() in SPLSimon Glass2014-11-21-0/+7
| | | | | | | | | | | | | | | | Since this function can use up quite a bit of space for its strings, disable it by default in SPL. Use CONFIG_DM_WARN to re-enable it. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@ti.com>
| * dm: Allow stdio registration to be droppedSimon Glass2014-11-21-3/+8
| | | | | | | | | | | | | | | | | | Provide a CONFIG_DM_STDIO option to enable registering a serial device with the stdio library. This is seldom useful in SPL, so disable it by default when building for SPL. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@ti.com>
| * dm: Allow device removal features to be droppedSimon Glass2014-11-21-169/+203
| | | | | | | | | | | | | | | | | | For SPL we don't expect to need to remove a device. Save some code space by dropping this feature. The board config can define CONFIG_DM_DEVICE_REMOVE if this is in fact needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@ti.com>
| * dm: spl: Allow driver model to be usedSimon Glass2014-11-21-0/+6
| | | | | | | | | | | | | | | | When enabled, set up driver model for SPL. This allows SPL to use the same drivers as the main U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Tom Rini <trini@ti.com>
| * dm: spl: Make simple malloc() available when enabledSimon Glass2014-11-21-1/+10
| | | | | | | | | | | | | | Set up the simple malloc() implementation when requested, in preference to the full malloc(). Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: arm: spl: Allow simple malloc() in SPLSimon Glass2014-11-21-1/+1
| | | | | | | | | | | | | | | | For SPL it is sometimes useful to have a simple malloc() just to permit driver model to work, in the cases where the full malloc() is not made available by the board config. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: Split the simple malloc() implementation into its own fileSimon Glass2014-11-21-38/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The simple malloc() implementation is used when memory is tight. It provides a simple buffer with an incrementing pointer. At present the implementation is inside dlmalloc. Move it into its own file so that it is easier to find. Rather than using relocation as a signal that the full malloc() is available, add a special GD_FLG_FULL_MALLOC_INIT flag. This signals that the simple malloc() should no longer be used. In some cases, such as SPL, even the code space used by the full malloc() is wasteful. Add a CONFIG_SYS_MALLOC_SIMPLE option to provide only the simple malloc. In this case the full malloc is not available at all. It saves about 1KB of code space and about 0.5KB of data on Thumb 2. Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: tegra: Avoid using arch-specific memcpy() in SPLSimon Glass2014-11-21-0/+2
| | | | | | | | | | | | | | The faster functions are not actually available in SPL and the code size likely isn't worth it. Use the normal memcpy() in SPL. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: serial: Support changing the baud rateSimon Glass2014-11-21-0/+67
| | | | | | | | | | | | | | Implement this feature in the uclass so that the baudrate can be changed with 'setenv baudrate <rate>'. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: at91: Add myself as maintainer for snapper9260Simon Glass2014-11-21-1/+1
| | | | | | | | | | | | The old maintainer has left, so take this over. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: at91: Convert snapper9260 to use driver modelSimon Glass2014-11-21-3/+24
| | | | | | | | | | | | | | | | | | Convert this at91sam9260-based board to use driver model. This should serve as an example for other similar boards. Serial and GPIO are supported so far. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Andreas Bießmann <andreas.devel@googlemail.com>
| * dm: at91: Add driver model support for the serial driverSimon Glass2014-11-21-0/+99
| | | | | | | | | | | | | | | | Add driver model support while retaining the existing legacy code. This allows the driver to support boards that have converted to driver model as well as those that have not. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: at91: Refactor serial driver slightly for driver modelSimon Glass2014-11-21-9/+23
| | | | | | | | | | | | | | | | Before adding driver model support, split out a few of the functions so that they can be used by the driver model code. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Andreas Bießmann <andreas.devel@googlemail.com>
| * dm: at91: Add platform data for GPIO on at91sam9260-based boardsSimon Glass2014-11-21-1/+17
| | | | | | | | | | | | | | | | These boards all have the same GPIO arrangement, so add some common platform data that can be used by all boards. Remove the configs which are no longer required. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: at91: Add driver model support for atmel GPIO driverSimon Glass2014-11-21-54/+193
| | | | | | | | | | | | | | Modify this driver to support driver model, with platform data required to determine the GPIOs that it controls. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: at91: Move snapper9260 to generic baordSimon Glass2014-11-21-0/+1
| | | | | | | | | | | | This works correctly, so switch it over before the deadline. Signed-off-by: Simon Glass <sjg@chromium.org>
| * dm: at91: Correct text base for snapper9260Simon Glass2014-11-21-1/+1
| | | | | | | | | | | | The value should be 0x21f00000. Fix it. Signed-off-by: Simon Glass <sjg@chromium.org>
* | Merge git://git.denx.de/u-boot-x86Tom Rini2014-11-24-473/+8299
|\ \ | | | | | | | | | | | | | | | | | | Conflicts: arch/x86/cpu/Makefile Signed-off-by: Tom Rini <trini@ti.com>
| * | x86: Rename chromebook-x86 to corebootSimon Glass2014-11-21-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rename this vendor since it is intended to be used on any platform where coreboot runs at reset and then loads U-Boot. So far it is only tested on link. When other boards are supported it is likely that we will need to move to multiple board names, all under the 'coreboot' vendor. So while it would be possible to remove the vendor for now, that would be short-sighted. Suggested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: ivybridge: Implement SDRAM initSimon Glass2014-11-21-6/+1868
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in the board directory and the SDRAM SPD information in the device tree. This also needs the Intel Management Engine (me.bin) to work. Binary blobs everywhere: so far we have MRC, ME and microcode. SDRAM init works by setting up various parameters and calling the MRC. This in turn does some sort of magic to work out how much memory there is and the timing parameters to use. It also sets up the DRAM controllers. When the MRC returns, we use the information it provides to map out the available memory in U-Boot. U-Boot normally moves itself to the top of RAM. On x86 the RAM is not generally contiguous, and anyway some RAM may be above 4GB which doesn't work in 32-bit mode. So we relocate to the top of the largest block of RAM we can find below 4GB. Memory above 4GB is accessible with special functions (see physmem). It would be possible to build U-Boot in 64-bit mode but this wouldn't necessarily provide any more memory, since the largest block is often below 4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit kernels directly so this does not pose a limitation in that area. Also there are probably parts of U-Boot that will not work correctly in 64-bit mode. The MRC is one. There is some work remaining in this area. Since memory init is very slow (over 500ms) it is possible to save the parameters in SPI flash to speed it up next time. Suspend/resume support is not fully implemented, or at least it is not efficient. With this patch, link boots to a prompt. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: ivybridge: Add LAPIC supportSimon Glass2014-11-21-0/+163
| | | | | | | | | | | | | | | | | | | | | | | | The local advanced programmable interrupt controller is not used much in U-Boot but we do need to set it up. Add basic support for this, which will be extended as needed. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: Make show_boot_progress() commonSimon Glass2014-11-21-24/+24
| | | | | | | | | | | | | | | | | | | | | This function can probably be used on all x86 boards, so move it into the common file. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: chromebook_link: Enable GPIO supportSimon Glass2014-11-21-3/+111
| | | | | | | | | | | | | | | | | | | | | Enable GPIO support and provide the required GPIO setup information to the driver. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: ivybridge: Add support for early GPIO initSimon Glass2014-11-21-16/+227
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When not relying on Coreboot for GPIO init the GPIOs must be set up correctly. This is currently done statically through a rather ugly method. As the GPIOs are figured out they can be moved to the device tree and set up as needed rather than all at the start. In this implementation, board files should call ich_gpio_set_gpio_map() before the GPIO driver is used in order to provide the GPIO information. We use the early PCI interface so that this driver can now be used before relocation. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: ivybridge: Add early init for PCH devicesSimon Glass2014-11-21-1/+524
| | | | | | | | | | | | | | | | | | | | | Many PCH devices are hard-coded to a particular PCI address. Set these up early in case they are needed. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: dts: Add microcode updates for ivybridge CPUSimon Glass2014-11-21-0/+1382
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add two microcode updates that are provided for this CPU. The updates have been converted to a device tree form. Note: SPDX submission has been done. If this license is approved I will convert the files to use SPDX. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: ivybridge: Perform Intel microcode update on bootSimon Glass2014-11-21-0/+179
| | | | | | | | | | | | | | | | | | | | | Microcode updates are stored in the device tree. Work through these and apply any that are needed. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: ivybridge: Check BIST value on bootSimon Glass2014-11-21-0/+16
| | | | | | | | | | | | | | | | | | | | | The built-in self test value should be checked before we continue booting. Refuse to continue if there is something wrong. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: ivybridge: Perform initial CPU setupSimon Glass2014-11-21-0/+274
| | | | | | | | | | | | | | | | | | | | | Set up the flex ratio (controls speed versus heat output) and a few other very early things. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: Add msr read/write functions that use a structureSimon Glass2014-11-21-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | It is convenient to be able to adjust MSRs with a structure that splits the two 32-bit halves into separate fields, as they are often dealt with separately. Add a few functions to support this. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: Add clr/setbits functionsSimon Glass2014-11-21-0/+49
| | | | | | | | | | | | | | | | | | These are available on other architectures. Make them available on x86 also. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: Tidy up coreboot header usageSimon Glass2014-11-21-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | There is no need to explicitly write 'arch-coreboot' when including headers, as when the arch directory points to coreboot the correct files will be used. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: ivybridge: Add early LPC init so that serial worksSimon Glass2014-11-21-0/+133
| | | | | | | | | | | | | | | | | | | | | | | | The PCH (Platform Controller Hub) includes an LPC (Low Pin Count) device which provides a serial port. This is accessible on Chromebooks, so enable it early in the boot process. Signed-off-by: Simon Glass <sjg@chromium.org>
generated by cgit v1.1 at 2024-08-23 19:58:14 +0000