summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeLines
* arm, am335x: siemens boards add FIT supportHeiko Schocher2014-12-04-19/+83
| | | | | | | | add FIT support and set "boardid" from factoryset records "DEV/id" and "COMP/ver". "boardid" is used for selecting which fit configuration gets booted on the board. Signed-off-by: Heiko Schocher <hs@denx.de>
* arm, am335x, siemens: read COMP/ver from factorysetHeiko Schocher2014-12-04-0/+11
| | | | Signed-off-by: Heiko Schocher <hs@denx.de>
* arm, am335x, siemens: fix factoryset interpretationHeiko Schocher2014-12-04-8/+18
| | | | | | | | a record could contain other records, so after an ">" (begin mark) there not always come an end mark "<", instead a ">" is possible. Take care of this. Signed-off-by: Heiko Schocher <hs@denx.de>
* mtd: nand: omap_gpmc: Always use ready/busy pinStefan Roese2014-12-04-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The functions to detect the state of the ready / busy signal is already available but only used in the SPL case. Lets use it always, also for the main U-Boot. As all boards should have this HW connection. Testing on Siemens Draco (am335x) showed a small perfomance gain by using this ready pin to detect the NAND chip state. Here the values tested on Draco with Hynix 4GBit NAND: Without NAND ready pin: U-Boot# time nand read 80400000 0 400000 NAND read: device 0 offset 0x0, size 0x400000 4194304 bytes read: OK time: 2.947 seconds, 2947 ticks With NAND ready pin: U-Boot# time nand read 80400000 0 400000 NAND read: device 0 offset 0x0, size 0x400000 4194304 bytes read: OK time: 2.795 seconds, 2795 ticks So an increase of approx. 5%. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Scott Wood <scottwood@freescale.com> Cc: Roger Meier <r.meier@siemens.com> Cc: Samuel Egli <samuel.egli@siemens.com>
* arm: am33xx: Handle NAND+I2C boot-device the same way as NANDStefan Roese2014-12-04-2/+14
| | | | | | | | | | | | | | Re-map NAND&I2C boot-device to the "normal" NAND boot-device. Otherwise the SPL boot IF can't handle this device correctly. Somehow booting with Hynix 4GBit NAND H27U4G8 on Siemens Draco leads to this boot-device passed to SPL from the BootROM. With this change, Draco boots just fine into main U-Boot. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Roger Meier <r.meier@siemens.com> Cc: Samuel Egli <samuel.egli@siemens.com>
* ARM: OMAP5: DRA7xx: Fix misleading comments in mux_data.hLubomir Popov2014-12-04-2/+2
| | | | | | | | | | The comments on the QSPI pad assignments erronously swapped the qspi1_d0 and qspi1_d1 functionality and could cause confusion. QSPI1_D[0] is in fact muxed on pad U1 (gpmc_a16), and QSPI1_D[1] - on pad P3 (gpmc_a17). Fixing comments. Signed-off-by: Lubomir Popov <l-popov@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* ARM: OMAP5: DRA7xx: Enable 8-bit eMMC access on the dra7xx_evmLubomir Popov2014-12-04-0/+1
| | | | | | | Tested on a Vayu EVM Rev.E2 with DRA752 ES1.1 Signed-off-by: Lubomir Popov <l-popov@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* omap_hsmmc: Board-specific TWL4030 MMC power initializationsPaul Kocialkowski2014-12-04-6/+97
| | | | | | | | | | | | Boards using the TWL4030 regulator may not all use the LDOs the same way (e.g. MMC2 power can be controlled by another LDO than VMMC2). This delegates TWL4030 MMC power initializations to board-specific functions, that may still call twl4030_power_mmc_init for the default behavior. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@ti.com> [trini: Fix omap3_evm warning, add twl4030.h] Signed-off-by: Tom Rini <trini@ti.com>
* twl4030: device-index-specific MMC power initializations, common ramp-up delayPaul Kocialkowski2014-12-04-14/+20
| | | | | | | | | Not every device has multiple MMC slots available, so it makes sense to enable only the required LDOs for the available slots. Generic code in omap_hsmmc will enable both VMMC1 and VMMC2, in doubt. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@ti.com>
* mmc: Board-specific MMC power initializationsPaul Kocialkowski2014-12-04-0/+8
| | | | | | | | | Some devices may use non-standard combinations of regulators to power MMC: this allows these devices to provide a board-specific MMC power init function to set everything up in their own way. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@ti.com>
* beagle_x15: add board support for Beagle x15Felipe Balbi2014-12-04-0/+569
| | | | | | | | | | | | | | | | | BeagleBoard-X15 is the next generation Open Source Hardware BeagleBoard based on TI's AM5728 SoC featuring dual core 1.5GHZ A15 processor. The platform features 2GB DDR3L (w/dual 32bit busses), eSATA, 3 USB3.0 ports, integrated HDMI (1920x108@60), separate LCD port, video In port, 4GB eMMC, uSD, Analog audio in/out, dual 1G Ethernet. For more information, refer to: http://www.elinux.org/Beagleboard:BeagleBoard-X15 Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* arm: omap: add support for am57xx devicesFelipe Balbi2014-12-04-11/+16
| | | | | | | | just add a few ifdefs around because this device is very similar to dra7xxx. Signed-off-by: Felipe Balbi <balbi@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* arm: omap_common: expose tps659038 and dra7xx_dpllsFelipe Balbi2014-12-04-0/+3
| | | | | | | | | expose those two definitions so they can be used by another board which we're adding in upcoming patches. Signed-off-by: Felipe Balbi <balbi@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* arm: omap5: sdram: mark emif_get_ext_phy_ctrl_const_regs __weakFelipe Balbi2014-12-04-1/+1
| | | | | | | | this will allow for boards to overwrite those in case memory setup is different. Signed-off-by: Felipe Balbi <balbi@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* arm: omap5: make hw_init_data weakFelipe Balbi2014-12-04-1/+1
| | | | | | | | this way we can let boards overwrite based on what they need. Signed-off-by: Felipe Balbi <balbi@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* configs: omap5_common : Boot rootfs from sd card by defaultFranklin S Cooper Jr2014-12-04-1/+1
| | | | | | | | | | | | | | | | | | | | * Since the emmc isn't always programed trying to load the fs from the emmc causes boot failures/kernel panic. * The current bootcmd is set to: bootcmd=run findfdt; run mmcboot;setenv mmcdev 1; setenv bootpart 1:2; \ setenv mmcroot /dev/mmcblk0p2 rw; run mmcboot; My guess is the env variables should be set so that sd card boot (dt,kernel,fs) is the default and then fallback to emmc if it fails (no sd card detected) The current bootcmd attempts to set mmcroot to the sd card rootfs but that code doesn't run due to mmcboot being ran early on. Signed-off-by: Franklin Cooper Jr. <fcooper@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* arm: omap-common: emif: allow to map memory without interleavingFelipe Balbi2014-12-04-4/+5
| | | | | | | | | If we want to have two sections, one on each EMIF, without interleaving, current code wouldn't enable emif2. Fix that problem. Signed-off-by: Felipe Balbi <balbi@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* usb: phy: omap_usb_phy: fix build breakageFelipe Balbi2014-12-04-2/+0
| | | | | | | | | | there's no such function usb3_phy_power(), it's likely that author meant to call, usb_phy_power() instead, but that's already called properly from xhci-omap.c. Signed-off-by: Felipe Balbi <balbi@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* arm: dra7xx: prcm: add missing registersFelipe Balbi2014-12-04-0/+3
| | | | | | | | | some boards might want to use USB1 for host, without fiddling those registers it'll be impossible. Signed-off-by: Felipe Balbi <balbi@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* arm: omap5: tps659038: rename regulator definesFelipe Balbi2014-12-04-10/+10
| | | | | | | | | Those regulators don't have any coupling with what they supply, so remove the suffixes in order to not confuse anybody. Signed-off-by: Felipe Balbi <balbi@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* arm: omap5: don't enable misc_init_r by defaultFelipe Balbi2014-12-04-14/+1
| | | | | | | | | | Out of all OMAP5-like boards, only one of them needs CONFIG_MISC_INIT_R, so it's best to enable that for that particular board only, instead of enabling for all boards unconditionally. Signed-off-by: Felipe Balbi <balbi@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* Revert "image-fdt: boot_get_fdt() return value when no DTB exists"Tom Rini2014-12-03-2/+2
| | | | | | | | | | | | | It has been found that this change breaks the case of an appended device tree file, so for the problem in question some other solution must be found. This reverts commit c6150aaf2f2745141a7c2ceded58d7efbfeace7d. Reported-by: Bill Pringlemeir <bpringlemeir@nbsps.com> Reported-by: Pantelis Antoniou <panto@antoniou-consulting.com> Confirmed-by: Bill Pringlemeir <bpringlemeir@nbsps.com> Signed-off-by: Tom Rini <trini@ti.com>
* Merge git://git.denx.de/u-boot-fdtTom Rini2014-12-01-33/+7
|\
| * fdt: Fix regression in fdt_pack_reg()Hans de Goede2014-12-01-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After commit 933cdbb479: "fdt: Try to use fdt_address_cells()/fdt_size_cells()" I noticed that allwinner boards would no longer boot. Switching to fdt_address_cells / fdt_size_cells changes the result from bytes to 32 bit words, so when we increment pointers into the blob, we must do so by 32 bit words now. This commit makes allwinner boards boot again. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Stefan Roese <sr@denx.de> Tested-by: Vince Hsu <vinceh@nvidia.com>
| * fdt: remove fdtdec_get_alias_node() functionMasahiro Yamada2014-11-27-27/+1
| | | | | | | | | | | | | | | | | | | | The fdt_path_offset() checks an alias too. fdtdec_get_alias_node(blob, "foo") is equivalent to fdt_path_offset(blob, "foo"). Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org>
* | Merge git://git.denx.de/u-boot-x86Tom Rini2014-12-01-363/+5872
|\ \
| * | tools: Add ifdtool to .gitignoreBin Meng2014-11-25-0/+1
| | | | | | | | | | | | | | | Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
| * | x86: chromebook_link: Enable the Chrome OS ECSimon Glass2014-11-25-0/+9
| | | | | | | | | | | | | | | | | | Enable the Chrome OS EC so that it can be used from U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: chromebook_link: Enable the x86 emulatorSimon Glass2014-11-25-0/+4
| | | | | | | | | | | | | | | | | | Enable this so that it can be used instead of native execution if desired. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | bios_emulator: Always print errors when opcode decode failsSimon Glass2014-11-25-18/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | This is a rare event and should not happen. When it does it is confusing to work out why. At least we should print a message. Adjust the emulator to always print decode errors to the console. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | bios_emulator: Add an option to enable debuggingSimon Glass2014-11-25-54/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At present there are DEBUG options spread around the place. If you enable one and not another you can end up with an emulator that does not work, since each file can have a different view of what the registers look like. To fix this, create a global CONFIG_X86EMU_DEBUG option that keeps everything consistent. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | bios_emulator: Allow a custom interrupt handler to be installedSimon Glass2014-11-25-0/+6
| | | | | | | | | | | | | | | | | | | | | Sometime we want to provide an interrupt handler for the ROM, Add a function to allow this. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | bios_emulator: Add vesa support and allow ROMs to be passed in as dataSimon Glass2014-11-25-58/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | As well as locating the ROM on the PCI bus, allow the ROM to be supplied to the emulator. Split the init up a little so that callers can supply their own interrupt routines. Also allow a vesa mode to be provided, to be selected once the BIOS run is complete. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | bios_emulator: Allow x86 to use the emulatorSimon Glass2014-11-25-23/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is an implicit assumption that x86 machines want to use raw I/O in the BIOS emulator, but this should be selectable. Add an CONFIG_X86EMU_RAW_IO option to control it instead. Also fix a few bugs which cause warnings on x86 and adjust the Makefile to remove the assumption that only PowerPC uses the emulator. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: config: Enable video support for chromebook_linkSimon Glass2014-11-25-7/+3
| | | | | | | | | | | | | | | | | | | | | Now that we have the required drivers, enable video support with a suitable option ROM. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: dts: Add video information to the device treeSimon Glass2014-11-25-0/+13
| | | | | | | | | | | | | | | | | | This provides panel timing information needed by the video driver. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: Add initial video device init for Intel GMASimon Glass2014-11-25-1/+969
| | | | | | | | | | | | | | | | | | | | | | | | | | | Intel's Graphics Media Accelerator (GMA) is a generic name for a wide range of video devices. Add code to set up the hardware on ivybridge. Part of the init happens in native code, part of it happens in a 16-bit option ROM for those nostalgic for the 1970s. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: Allow an option ROM to be built into U-BootSimon Glass2014-11-25-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Some x86 machines require a binary blob containing 16-bit initialisation code for their video hardware. Allow this to be built into the x86 ROM so that it is accessible during boot. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: video: Add video driver for bare x86 boardsSimon Glass2014-11-25-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | Add a very simple driver which uses vesa to discover the video mode and then provides a frame buffer for use by U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Anatolij Gustschin <agust@denx.de>
| * | pci: Add general support for execution of video ROMsSimon Glass2014-11-25-2/+353
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some platforms don't have native code for dealing with their video hardware. In some cases they use a binary blob to set it up and perform required actions like setting the video mode. This approach is a hangover from the old PC days where a ROM was provided and executed during startup. Even now, these ROMs are supplied as a way to set up video. It avoids the code for every video chip needing to be provided in the boot loader. But it makes the video much less flexible - e.g. it is not possible to do anything else while the video init is happening (including waiting hundreds of milliseconds for display panels to start up). In any case, to deal with this sad state of affairs, provide an API for execution of x86 video ROMs, either natively or through emulation. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: Add support for running option ROMs nativelySimon Glass2014-11-25-0/+946
| | | | | | | | | | | | | | | | | | | | | | | | On x86 machines we can use an emulator to run option ROMS as with other architectures. But with some additional effort (mostly due to the 16-bit nature of option ROMs) we can run them natively. Add support for this. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | Add support for Vesa BIOS extensionsSimon Glass2014-11-25-0/+103
| | | | | | | | | | | | | | | | | | | | | For option ROMs we can use these extensions to request a particular video mode. Add a header file which defines the binary interface. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: Add vesa mode configuration optionsSimon Glass2014-11-25-0/+149
| | | | | | | | | | | | | | | | | | Add Kconfig options to allow selection of a vesa mode on x86 machines. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: Add GDT descriptors for option ROMsSimon Glass2014-11-25-22/+18
| | | | | | | | | | | | | | | | | | | | | Option ROMs require a few additional descriptors. Add these, and remove the enum since we now have to access several descriptors from assembler. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | Introduce a header file for the BIOS emulatorSimon Glass2014-11-25-52/+46
| | | | | | | | | | | | | | | | | | | | | We should have a public header so that users can avoid defining functions themselves. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: Add a definition of asmlinkageSimon Glass2014-11-25-0/+3
| | | | | | | | | | | | | | | | | | | | | This is needed to permit calling C from assembler without too much pain. Add a definition for x86. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: config: Enable SPI for chromebook_linkSimon Glass2014-11-25-4/+0
| | | | | | | | | | | | | | | | | | Enable SPI so that the SPI flash can be used. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: ivybridge: Add northbridge init functionsSimon Glass2014-11-25-1/+207
| | | | | | | | | | | | | | | | | | Add init for the northbridge, another part of the platform controller hub. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: Drop some msr functions that we don't supportSimon Glass2014-11-25-11/+0
| | | | | | | | | | | | | | | | | | These are not available in U-Boot as yet, so drop them. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | x86: Add init for model 206AX CPUSimon Glass2014-11-25-0/+528
| | | | | | | | | | | | | | | | | | Add the setup code for the CPU so that it can be used at full speed. Signed-off-by: Simon Glass <sjg@chromium.org>
generated by cgit v1.1 at 2024-12-29 14:57:54 +0000