- 12 10月, 2015 1 次提交
-
-
由 Ryan Harkin 提交于
Create an additional FVP configuration to boot images pre-loaded into DRAM. Sometimes it's preferential to boot the model by loading the files directly into DRAM via model parameters, rather than using SemiHosting. An example of model parmaters that are used to pre-load the files into DRAM: --data cluster0.cpu0=Image@0x80080000 \ --data cluster0.cpu0=fvp-base-gicv2-psci.dtb@0x83000000 \ --data cluster0.cpu0=uInitrd@0x84000000 Signed-off-by: NRyan Harkin <ryan.harkin@linaro.org> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> [trini: Update board/armltd/vexpress64/Kconfig logic] Signed-off-by: NTom Rini <trini@konsulko.com>
-
- 11 10月, 2015 9 次提交
-
-
由 Ryan Harkin 提交于
vexpress64 kernels are usually over 8 MBytes in length, so setting the max uImage length to 64 Mbytes should give us plenty of scope for expansion. I mostly chose this length to match other board configs that use "(64 << 20)". Signed-off-by: NRyan Harkin <ryan.harkin@linaro.org> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Ryan Harkin 提交于
The FVP and Juno settings were identical, but duplicated, so I removed the duplication with this patch. Signed-off-by: NRyan Harkin <ryan.harkin@linaro.org> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> [trini: Adjust logic to keep if/endif in the file] Signed-off-by: NTom Rini <trini@konsulko.com>
-
由 Ryan Harkin 提交于
This patch fixes a couple of checkpatch warnings on the vexpress64 config. Signed-off-by: NRyan Harkin <ryan.harkin@linaro.org> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Yao Yuan 提交于
DSPI2 can be verified when boot from QSPI now. Signed-off-by: NYuan Yao <yao.yuan@freescale.com> Reviewed-by: NJagan Teki <jteki@openedev.com>
-
由 Yao Yuan 提交于
AT26DF081A is the spi flash type of TWR-MEM(SCH-26248) card. We can access the flash through DSPI2 on LS1021ATWR board. Signed-off-by: NYuan Yao <yao.yuan@freescale.com> Reviewed-by: NJagan Teki <jteki@openedev.com>
-
由 Yuan Yao 提交于
Erratum A-008022 has been fixed on LS1021A Rev2.0. So we can use DSPI2 now, this patch enable DSPI2 in dts for LS1021ATWR. Signed-off-by: NYuan Yao <yao.yuan@freescale.com> Reviewed-by: NJagan Teki <jteki@openedev.com>
-
由 Mirza Krak 提交于
Respect the mode passed in set_mode ops. Signed-off-by: NMirza Krak <mirza.krak@hostmobility.com> Reviewed-by: NJagan Teki <jteki@openedev.com>
-
由 Jagan Teki 提交于
priv->mode is initialized when .set_speed triggers with mode value, so checking mode for configuring CPOL, CPHA using priv->mode is invalid hence use mode from .set_speed argument, and at the end priv->mode will initialized with mode. This patch also replaces formatting string to use speed instead of mode in .set_speed ops. Signed-off-by: NJagan Teki <jteki@openedev.com>
-
由 Jagan Teki 提交于
priv->mode is initialized when .set_speed triggers with mode value, so checking mode for configuring CPOL, CPHA using priv->mode is invalid hence use mode from .set_speed argument, and at the end priv->mode will initialized with mode. This patch also replaces formatting string to use speed instead of mode in .set_speed ops. Signed-off-by: NJagan Teki <jteki@openedev.com>
-
- 10 10月, 2015 2 次提交
-
-
由 Siarhei Siamashka 提交于
The pcDuino1 board unconditionally provides 5V to USB host receptacles. The pcDuino2 board has a voltage regulator, controlled by the PD2 pin which is pulled-up by default (so that the USB power is also enabled by default). Not specifying pins for enabling USB power in the defconfig means that the PH3 and PH6 pins are driven high by default. The PH6 pin is available on the Arduino-compatible expansion header and touching it is not nice (this may be even dangerous, depending on what kind of role is assigned to this particular pin by various Arduino shields). This patch explicitly configures the USB VBUS pins to "", which means that no pins should be touched. The patch has been tested on a pcDuino2 board and USB still works. Signed-off-by: NSiarhei Siamashka <siarhei.siamashka@gmail.com> Reviewed-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
由 Siarhei Siamashka 提交于
Linksprite_pcDuino_defconfig is a generic config for pcDuino1 and pcDuino2 boards. The pcDuino2 board exists at least in two variants (with DDR3 chips from HYNIX or NANYA). At least one pcDuino2 board with HYNIX DDR3 fails the lima-memtester reliability test unless the DRAM clock speed is reduced to 360MHz. A detailed analysis report, generated by the a10-tpr3-scan tool with the explanations why the DRAM is failing at 408MHz, is available at: http://linux-sunxi.org/index.php?title=User:Ssvb/pcDuino2_with_HYNIX_DDR3_reliability_test&oldid=15152 http://web.archive.org/web/20151008190210/http://linux-sunxi.org/User:Ssvb/pcDuino2_with_HYNIX_DDR3_reliability_testSigned-off-by: NSiarhei Siamashka <siarhei.siamashka@gmail.com> Reviewed-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com>
-
- 09 10月, 2015 2 次提交
-
-
-
由 Bin Meng 提交于
PCI_HEADER_TYPE register (offset 0x0e) bit 7 is an indicator for multi-function devices. We should mask it off before using it as the header type. Signed-off-by: NBin Meng <bmeng.cn@gmail.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
- 08 10月, 2015 2 次提交
-
-
- 07 10月, 2015 1 次提交
-
-
由 Alexey Brodkin 提交于
It turned out with some boards (FPGA firmwares?) and cards combos current clock settings doesn't work as expected leading to strange card freezes or corrupted data being read from the card. Especially this was seen with Transcend 2Gb cards shipped as a part of ARC SDP: ----------------->8--------------- AXS# mmcinfo Device: Synopsys Mobile storage Manufacturer ID: 74 OEM: 4a60 Name: SDC Tran Speed: 50000000 Rd Block Len: 512 SD version 3.0 High Capacity: No Capacity: 1.8 GiB Bus Width: 4-bit Erase Group Size: 512 Bytes AXS# fatload mmc 0 ** Unrecognized filesystem type ** ----------------->8--------------- With this change that problem is fixed. Note "Tran Speed" above doesn't match clock value set in DW MMC. It is max value for card's speed class. Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
-
- 05 10月, 2015 3 次提交
-
-
由 Simon Glass 提交于
Currently 'reset' only works with the test device tree. When run without a device tree, or with the normal device tree, the following error is displayed: Reset not supported on this platform Fix the driver and the standard device tree to avoid this. Signed-off-by: NSimon Glass <sjg@chromium.org> Reported-by: NStephen Warren <swarren@nvidia.com> Tested-by: NStephen Warren <swarren@wwwdotorg.org>
-
由 Simon Glass 提交于
Adjust the memory leak tests to show the amount of memory leaked. This can be a useful signal as to what is wrong. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Currently when driver model starts up it finds the root uclass and the pinctrl uclass. This is because even the root node handles pinctrl processing. But this is not useful. The root node is not a real hardware device so cannot require any particular pinmux settings. Also it means that the memory leak tests fails, since they end up freeing more memory than they allocate: the marker it set after the root device and pinctrl uclass are allocated, and later once the pinctrl uclass is freed the memory used by driver model is less than when the marker was set. If a platform needs 'core' pin mulitplex settings it can do this with a driver that is probed on start-up. It would be an abuse of the root node to use this for pinctrl. To avoid this problem, only process pinctrl settings for non-root nodes. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
- 04 10月, 2015 2 次提交
-
-
由 Sjoerd Simons 提交于
When malloc_base initially gets setup in the SPL it is based on the current (early) stack pointer, which for rockchip is pointing into SRAM. This means simple memory allocations happen in SRAM space, which is somewhat unfortunate. Specifically a bounce buffer for the mmc allocated in SRAM space seems to cause the mmc engine to stall/fail causing timeouts and a failure to load the main u-boot image. To resolve this, reconfigure the malloc_base to start at the relocated stack pointer after DRAM has been setup. For reference, things did work fine on rockchip before 596380db was merged to fix memalign_simple due to a combination of rockchip SDRAM starting at address 0 and the dw_mmc driver not checking errors from bounce_buffer_start. As a result, when a bounce buffer needed to be allocated mem_align simple would fail and return NULL. The mmc driver ignored the error and happily continued with the bounce buffer address being set to 0, which just happened to work fine.. Signed-off-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk> Reviewed-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Masahiro Yamada 提交于
It looks like this line was copy-pasted, but not modified. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
- 03 10月, 2015 15 次提交
-
-
-
由 Przemyslaw Marczak 提交于
This device uses SDHCI driver, for eMMC and SD cards. Trying bind the DW MMC driver with fdt node without all required properties, causes printing an error. This commit disables the DW MMC node. Tested-on: Trats Signed-off-by: NPrzemyslaw Marczak <p.marczak@samsung.com> Cc: Łukasz Majewski <l.majewski@samsung.com> Cc: Minkyu Kang <mk7.kang@samsung.com>
-
由 Przemyslaw Marczak 提交于
After rework of code by: commit: d9527968 Exynos5: Use clock_get_periph_rate generic API function get_mmc_clk() always returns -1 for Exynos 4. This was caused by omitting, that SDHCI driver for Exynos 4, calls get_mmc_clk(), with mmc device number as argument, instead of pinmux peripheral id, like DW MMC driver for Exynos 5. By this commit, the code directly calls a proper function to get mmc clock for Exynos 4, without checking the peripheral id. Tested on: Odroid U3/X2, Trats, Trats2, Odroid XU3, Snow (by Simon). Signed-off-by: NPrzemyslaw Marczak <p.marczak@samsung.com> Acked-by: NJaehoon Chung <jh80.chung@samsung.com> Acked-by: NSimon Glass <sjg@chromium.org> Tested-by: NSimon Glass <sjg@chromium.org>
-
由 Przemyslaw Marczak 提交于
After rework in lib/fdtdec.c, the function fdtdec_get_addr() doesn't work for nodes with #size-cells property set to 0. To get GPIO's 'reg' property, the code should use one of: fdtdec_get_addr_size_auto_no/parent() function. Fortunately dm core provides a function to get the property. This commit reworks function gpio_exynos_bind(), to properly use dev_get_addr() for GPIO device. This prevents setting a wrong base register for Exynos GPIOs. Tested on: Odroid U3/X2, Trats, Trats2, Odroid XU3, Snow (by Simon). Signed-off-by: NPrzemyslaw Marczak <p.marczak@samsung.com> Acked-by: NStephen Warren <swarren@nvidia.com> Acked-by: NSimon Glass <sjg@chromium.org> Tested-by: NSimon Glass <sjg@chromium.org>
-
由 Przemyslaw Marczak 提交于
After rework of lib/fdtdec.c by: commit: 02464e38 fdt: add new fdt address parsing functions the function fdtdec_get_addr() doesn't work as previous, because the implementation assumes that properties '#address-cells' and '#size-cells' are equal to 1, which can be not true sometimes. The new API introduced fdtdec_get_addr_size_auto_parent() for the 'reg' property parsing, but the implementation assumes, that #size-cells can't be less than 1. This causes that the following children's 'reg' property can't be reached: parent@0x0 { #address-cells = <1>; #size-cells = <0>; children@0x100 { reg = < 0x100 >; }; }; Change the condition value from '1' to '0', which allows parsing property with at least zero #size-cells, fixes the issue. Now, fdtdec_get_addr_size_auto_parent() works properly. Tested on: Odroid U3/X2, Trats, Trats2, Odroid XU3, Snow (by Simon). Signed-off-by: NPrzemyslaw Marczak <p.marczak@samsung.com> Acked-by: NStephen Warren <swarren@nvidia.com> Acked-by: NSimon Glass <sjg@chromium.org> Tested-by: NSimon Glass <sjg@chromium.org>
-
由 Stephen Warren 提交于
fdtdec_get_addr_size() may be used in two cases: a) With sizep supplied, in which case both an address and a size are parsed from DT. In this case, the DT property must be large enough to contain both values. b) With sizep NULL, in which case only an address is parsed from DT. In this case, the DT property only need be large enough to contain this address value. Commit 02464e38 "fdt: add new fdt address parsing functions" broke this relaxed checking, and required the DT property to contain both an address and a size value in all cases. Fix fdtdec_get_addr_size() to vary ns based on whether the size value is being parsed from the DT or not. This is safe since the function only parses the first entry in the property, so the overall value of (na + ns) need not be accurate, since it is never used to step through the property data to find other entries. Besides, this fixed behaviour essentially matches the original behaviour before the patch this patch fixes. (The original code validated that the property was exactly the length of either na or (na + ns), whereas the current code only validates that the property is at least that long. For non-failure cases, the two behaviours are identical). Cc: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Simon Glass <sjg@chromium.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Bin Meng <bmeng.cn@gmail.com> Cc: Michal Suchanek <hramrach@gmail.com> Fixes: 02464e38 ("fdt: add new fdt address parsing functions") Reported-by: NPrzemyslaw Marczak <p.marczak@samsung.com> Signed-off-by: NStephen Warren <swarren@nvidia.com> Tested-by: NPrzemyslaw Marczak <p.marczak@samsung.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
This comment from README.fdt-control did not end up in the Kconfig, which is what most people will see. Add it with a few tweaks. Signed-off-by: NSimon Glass <sjg@chromium.org> Acked-by: NMichal Simek <michal.simek@xilinx.com>
-
由 Hans de Goede 提交于
The 7" Q8 tablet enclosure is used for a ton of slightly different cheap chinese tablets. There are some differences in which accelerometer / wifi is used, but other then that these are all the same from a u-boot / kernel pov. When we get to adding accelerometer support the plan is to add some kind of autodetection and mangle the dt accordingly (likely using the new quirks mechanism). For now this is a non issue as we do not yet have accelerometer support, and in the future, some sort of auto-detect is the way to go as we cannot expect users to exactly know what is inside their tablet. The dts files this commit adds are identical to the ones submitted to the upstream kernel. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NIan Campbell <ijc@hellion.org.uk>
-
-
由 Stephen Warren 提交于
In order to make it clear what the parameters to set_config() and set_direction() mean, and similarly for the return values from the respective get_*(), define named constants for these values. Disassembly shows no diff in the generated code, except that the order of the code in the branches of tegra_gpio_get_function() gets modified without affecting behaviour. Suggested-by: NTom Warren <twarren@nvidia.com> Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
These enum values aren't used anywhere. Remove them. Signed-off-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
The size allocation for SPL is increased in all cases to match the already-expanded value used on Tegra124. This is both for general consistency, and because the seaboard build trips over the limit already when using one of the ARM compilers packaged with 14.04. For the record, when building Seaboard: arm-linux-gnueabi- SPL is too big by 0x36 bytes arm-linux-gnueabihf- SPL fits by 0x2a bytes arm-none-eabi- SPL fits by 0xa bytes (Those figures are from builds with the expanded SPL size allocation, relative to the non-expanded SPL size limit; they're better by about 6 bytes in the more constrained build.) Fixes: ba521994 ("tegra124: Expand SPL space by 8KB") Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
Tegra's GPIO driver currently enables pins as GPIO as soon as they're requested. This is not safe, since the desired direction and output value are not yet known. This could cause a glitch on the output pins between gpio_request() and gpio_direction_*(), depending on what values happen to be in the GPIO controller's in/out and out-value registers vs. the final desired configuration. To solve this, defer enabling pins as GPIOs until some gpio_direction_*() is invoked, and the desired configuration is explicitly programmed. In theory this change could cause regressions, if code exists that claims a GPIO, never explicitly sets a direction, and then gets/sets the GPIO value based on that assumption. However, I've read through all the Tegra- related board files and device drivers that touch GPIOs and I do not see such buggy code anywhere. Signed-off-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
Tegra's gpio_config_table() currently uses common GPIO APIs. These used to work without requesting the GPIO, but since commit 2fccd2d9 "tegra: Convert tegra GPIO driver to use driver model" no longer do so. This prevents any of the GPIO initialization table from being applied to HW. Fix gpio_config_table() to directly program the HW to solve this. Fixes: 2fccd2d9 ("tegra: Convert tegra GPIO driver to use driver model") Signed-off-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
由 Stephen Warren 提交于
In order to avoid any assumptions about any device connected to P2371-2180's expansion connector, the latest pinmux spreadsheet configures all muxable pins on that connector to be GPIO inputs, with on-chip pulls where appropriate. Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NTom Warren <twarren@nvidia.com>
-
- 02 10月, 2015 3 次提交
-
-
-
由 Fabio Estevam 提交于
Add DFU support. Tested by flashing SPL and u-boot.img into SPI NOR flash with the following commands: => setenv dfu_alt_info ${dfu_alt_info_spl} => run dfuspi On the host PC: $ sudo dfu-util -D SPL -a spl On the target: CTRL+C => setenv dfu_alt_info ${dfu_alt_info_img} => run dfuspi On the host PC: $ sudo dfu-util -D u-boot.img -a u-boot Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
-
由 Albert ARIBAUD \(3ADEV\) 提交于
Devices supported are: - NFC (NAND FLASH) - MMC - QSPI (SPI NOR FLASH) - I2C (only bus 2) - I2C RTC - I2C EEPROM - FEC Patch-series: 2 - remove useless CONFIG_SYS_SPD_BUS_NUM from config - remove include of config_cmd_default.h - remove duplicate CONFIG_CMD_NET Signed-off-by: NAlbert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>
-