summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'mips-pull-2019-05-03' of git://git.denx.de/u-boot-mipsTom Rini2019-05-0444-586/+2043
|\ | | | | | | | | | | - mscc: small fixes, enhance network support for Serval, Luton and Ocelot - mt7620: rename arch to more generic name mtmips - mips: pass initrd addresses via DT as physical addresses
| * net: mscc: ocelot: Update DTS for Luton pcb90Horatiu Vultur2019-05-034-196/+307
| | | | | | | | | | | | | | | | Update device tree for luton to add support for luton pcb90. This pcb has 24 ports from which 12 ports are connected to SerDes6G. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
| * board: mscc: luton: Update MSCC Luton boardHoratiu Vultur2019-05-031-2/+11
| | | | | | | | | | | | | | Implement method board_phy_config to configure the external phys on the pcb90. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
| * net: mscc: luton: Update network driver for pcb90Horatiu Vultur2019-05-032-159/+258
| | | | | | | | | | | | | | Update Luton network driver to have support also for pcb90. The pcb90 has 24 ports from which 12 ports are connected to SerDes6G. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
| * mips: rename mach-mt7620 to mach-mtmipsWeijie Gao2019-05-0317-20/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently mach-mt7620 contains only support for mt7628. To avoid confusion, rename mach-mt7620 to mach-mtmips, which means MediaTek MIPS platforms. MT7620 and MT7628 should be distinguished by SOC_MT7620 and SOC_MT7628 because they do not share the same lowlevel codes. Dependencies of four drivers are changed to SOC_MT7628 as these drivers are only used by MT7628. Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
| * net: mscc: ocelot: Update DTS for Ocelot pcb120.Horatiu Vultur2019-05-035-81/+167
| | | | | | | | | | | | Update device tree for ocelot to add support for ocelot pcb120. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
| * board: mscc: ocelot: Update MSCC Ocelot board.Horatiu Vultur2019-05-031-0/+15
| | | | | | | | | | | | Implement method board_phy_config to configure the phy for pcb120. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
| * net: mscc: ocelot: Update network driver for pcb120Horatiu Vultur2019-05-033-99/+338
| | | | | | | | | | | | Update Ocelot network driver to have support also for pcb120. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
| * arch: mips: Update initrd_start and initrd_endHoratiu Vultur2019-05-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Microsemi SoC defines CONFIG_SYS_SDRAM_BASE to be 0x80000000, which represents the start of kseg0 and represents a virtual address. Meaning that the initrd_start and initrd_end point somewhere kseg0. When these parameters are passed to linux kernel through DT they are pointing somewhere in kseg0 which is a virtual address but linux kernel expects the addresses to be physical addresses(in kuseg) because it is converting the physical address to a virtual one. Therefore update the uboot to pass the physical address of initrd_start and initrd_end by converting them using the function virt_to_phys before setting up the DT. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
| * MSCC: delete obsolete reference to MSCC_BITBANG_SPI_GPIORobert P. J. Day2019-05-031-1/+0
| | | | | | | | | | | | | | | | | | | | | | Remove "select MSCC_BITBANG_SPI_GPIO" since Kbuild option was deleted back in commit ace9c103df2875d2b435dbd7b36618020edfd1c0: commit ace9c103df2875d2b435dbd7b36618020edfd1c0 Author: Lars Povlsen <lars.povlsen@microchip.com> Date: Tue Jan 8 10:38:35 2019 +0100 mips: gpio: mscc: Obsoleted gpio-mscc-bitbang-spi.c
| * configs: mscc_serval: Add network supportHoratiu Vultur2019-05-031-1/+5
| | | | | | | | | | | | Update default config to use network driver for Serval SoCs. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
| * net: mscc: serval: Add ethernet nodes for ServalHoratiu Vultur2019-05-034-0/+165
| | | | | | | | | | | | | | Add ethernet nodes for Serval SoCs family. There are 2 pcb in this family: pcb105 and pcb106. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
| * board: mscc: serval: Update MSCC Serval boardsHoratiu Vultur2019-05-031-0/+12
| | | | | | | | | | | | | | | | In Serval SoC family there are 2 different pcb, both of them have the same phy, but with different version. Therefore implement board_phy_config and set all the phys in the same way. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
| * net: Add MSCC Serval network driver.Horatiu Vultur2019-05-033-0/+711
| | | | | | | | | | | | | | | | Add network driver for Microsemi Ethernet switch. It is present on Serval SoCs. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
| * board: mscc: serval: Fix board detectHoratiu Vultur2019-05-031-1/+1
| | | | | | | | | | | | | | | | When detecting the board, it was reading a register in the GPIO page of the phy and based on that value it was making a decision. The bug was that after the GPIO page for the first phy was set it was not reseted back. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
| * mips: mscc: serval: Fix resetHoratiu Vultur2019-05-032-26/+31
| | | | | | | | | | | | | | | | | | In case the ddr training was failing, it couldn't reset, it was just hanging. Therefore reimplement it, so when ddr training is failing it would call _machine_restart, which power downs the DDR and does a force reset. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
* | Merge tag 'mmc-2019-5-3' of https://github.com/MrVan/u-bootTom Rini2019-05-044-54/+233
|\ \
| * | mmc: sdhci: Add Support for ADMA2Faiz Abbas2019-05-033-23/+170
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Standard Host Controller Interface (SDHCI) specification version 3.00 adds support for Advanced DMA (ADMA) for both 64 and 32 bit widths of DMA. ADMA2 uses a table of descriptors for aggregating DMA requests. This significantly improves read and write throughput. Add Support for the same. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
| * | mmc: sdhci: Move DMA handling to prepare_dma() functionFaiz Abbas2019-05-032-42/+53
| | | | | | | | | | | | | | | | | | | | | | | | In preparation for addition of ADMA2 support, cleanup SDMA handling by moving it to a new sdhci_prepare_dma() function. Also add a flags field in sdhci_host to indicate if DMA is enabled. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
| * | mmc: fsl_esdhc: Fix wp_enable issueYe Li2019-05-031-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The wp-gpios property is used for gpio, if this is set, the WP pin is muxed to gpio function, can't be used as internal WP checking. However the codes remain to use internal WP checking. This patch changes to examine the "fsl,wp-controller" for enabling internal WP checking, and "wp-gpios" for muxing to gpio. Signed-off-by: Ye Li <ye.li@nxp.com>
| * | mmc: fsl_esdhc: fix sd/mmc ddr mode clock setting issueYe Li2019-05-031-5/+18
| |/ | | | | | | | | | | | | | | | | | | | | | | When sd/mmc work at DDR mode, like HS400/HS400ES/DDR52/DDR50 mode, the output clock rate is half of the internal clock rate. This patch set the DDR_EN bit first for DDR mode, hardware divide the usdhc clock automatically, then follow the original sdr clock setting method. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Signed-off-by: Ye Li <ye.li@nxp.com>
* | Merge branch '2019-05-04-master-imports'Tom Rini2019-05-04137-1665/+84
|\ \ | | | | | | | | | | | | - Remove dead code from davinci - Migrate CONFIG_SUPPORT_EMMC_BOOT
| * | delete Kbuild "select" of long-dead SPL_DISABLE_OF_CONTROLRobert P. J. Day2019-05-041-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | >From way back in 2015: commit dffb86e468c8e02ba77283989aefef214d904dc5 Author: Masahiro Yamada <yamada.masahiro@socionext.com> Date: Wed Aug 12 07:31:54 2015 +0900 of: flip CONFIG_SPL_DISABLE_OF_CONTROL into CONFIG_SPL_OF_CONTROL As we discussed a couple of times, negative CONFIG options make our life difficult; CONFIG_SYS_NO_FLASH, CONFIG_SYS_DCACHE_OFF, ... and here is another one. Now, there are three boards enabling OF_CONTROL on SPL: - socfpga_arria5_defconfig - socfpga_cyclone5_defconfig - socfpga_socrates_defconfig This commit adds CONFIG_SPL_OF_CONTROL for them and deletes CONFIG_SPL_DISABLE_OF_CONTROL from the other boards to invert the logic. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
| * | Convert CONFIG_SUPPORT_EMMC_BOOT to KconfigAlex Kiernan2019-05-04113-82/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This converts the following to Kconfig: CONFIG_SUPPORT_EMMC_BOOT As requested by Michal Simek <michal.simek@xilinx.com>, these boards have no eMMC so CONFIG_SUPPORT_EMMC_BOOT has not been migrated: xilinx_zynqmp_zc1275_revB xilinx_zynqmp_zc1751_xm018_dc4 xilinx_zynqmp_zc1751_xm019_dc5 xilinx_zynqmp_zcu100_revC xilinx_zynqmp_zcu102_rev1_0 xilinx_zynqmp_zcu102_revA xilinx_zynqmp_zcu102_revB xilinx_zynqmp_zcu104_revA xilinx_zynqmp_zcu104_revC xilinx_zynqmp_zcu106_revA xilinx_zynqmp_zcu111_revA Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com> Acked-by: Lukasz Majewski <lukma@denx.de> Acked-by: Patrick Delaunay <patrick.delaunay@st.com> Acked-by: Ramon Fried <ramon.fried@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
| * | arm: davinci: remove leftover code for dm* SoCsBartosz Golaszewski2019-05-0415-1133/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The support for DaVinci DM* SoCs has been dropped a while ago. There's still a lot of leftover code in mach-davinci though. Entirely remove certain files and modify the common code to no longer reference unsupported chips. Note: all DaVinci platforms supported in u-boot now define SOC_DA8XX but not all define SOC_DA850 (e.g. omapl138). We can safely remove all ifdefs for the former, but let's leave the ones for the latter. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
| * | usb: musb_hcd: remove unnecessary ifdefs for dm* SoCsBartosz Golaszewski2019-05-041-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | The support for DaVinci DM* SoCs has been dropped. The ifdefs in the musb_hcd driver are no longer needed. Remove them. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Acked-by: Marek Vasut <marex@denx.de>
| * | nand: davinci: remove dead code for dm644xBartosz Golaszewski2019-05-041-39/+0
| | | | | | | | | | | | | | | | | | | | | The support for DaVinci DM* SoCs has been dropped. The code that used to be relevant to dm644x is no longer needed. Remove it. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
| * | arm: davinci: remove dead code for PHYs used by DaVinci DM* boardsBartosz Golaszewski2019-05-046-354/+0
| | | | | | | | | | | | | | | | | | | | | | | | The support for DaVinci DM* boards has been dropped a while ago. The code for all those PHYs is no longer used and they have their own proper PHY drivers in drivers/net/phy anyway. Remove all dead code. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
| * | net: davinci_emac: drop support for unused PHYsBartosz Golaszewski2019-05-041-49/+6
|/ / | | | | | | | | | | | | | | | | | | The boards with SoCs from the DaVinci DM* family used to come with different PHYs that needed special support implemented in mach-davinci. Since the support for these chips has long been removed, we can now drop this unnused code from the emac driver. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
* | Merge git://git.denx.de/u-boot-socfpgaTom Rini2019-05-0310-55/+85
|\ \ | | | | | | | | | - Misc MMC, FPGA bridge, general SoCFPGA fixes
| * | dts: arm: socfpga: fix socfpga_de10_nano consoleSimon Goldschmidt2019-04-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Booting this board failed as the initial console isn't found since commit c402e8170245 ("dts: arm: socfpga: merge gen5 devicetrees from linux") The uart0 devicetree entry was missing "clock-frequency = <100000000>:" since that commit Fixes: c402e8170245 ("dts: arm: socfpga: merge gen5 devicetrees from linux") Reported-by: rafael mello <rafaelmello_3@hotmail.com> Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
| * | ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()Marek Vasut2019-04-291-31/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The usage of socfpga_sdram_apply_static_cfg() seems rather dubious and is confirmed to lead to a rare system hang when enabling bridges. This patch removes the socfpga_sdram_apply_static_cfg() altogether, because it's use seems unjustified and problematic. The socfpga_sdram_apply_static_cfg() triggers write to SDRAM staticcfg register to set the applycfg bit, which according to old vendor U-Boot sources can only be written when there is no traffic between the SDRAM controller and the rest of the system. Empirical measurements confirm this, setting the applycfg bit when there is traffic between the SDRAM controller and CPU leads to the SDRAM controller accesses being blocked shortly after. Altera originally solved this by moving the entire code which sets the staticcfg register to OCRAM [1]. The commit message claims that the applycfg bit needs to be set after write to fpgaportrst register. This is however inverted by Altera shortly after in [2], where the order becomes the exact opposite of what commit message [1] claims to be the required order. The explanation points to a possible problem in AMP use-case, where the FPGA might be sending transactions through the F2S bridge. However, the AMP is only the tip of the iceberg here. Any of the other L2, L3 or L4 masters can trigger transactions to the SDRAM. It becomes rather non-trivial to guarantee there are no transactions to the SDRAM controller. The SoCFPGA SDRAM driver always writes the applycfg bit in SPL. Thus, writing the applycfg again in bridge enable code seems redundant and can presumably be dropped. [1] https://github.com/altera-opensource/u-boot-socfpga/commit/75905816ec95b0ccd515700b922628d7aa9036f8 [2] https://github.com/altera-opensource/u-boot-socfpga/commit/8ba6986b04a91d23c7adf529186b34c8d2967ad5 Signed-off-by: Marek Vasut <marex@denx.de> Cc: Chin Liang See <chin.liang.see@intel.com> Cc: Dinh Nguyen <dinguyen@kernel.org> Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Cc: Tien Fong Chee <tien.fong.chee@intel.com>
| * | mmc: dw_mmc: Round up descriptor end to nearest multiple of cacheline sizeMarek Vasut2019-04-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The driver currently calculates the end address of cache flush operation for the DMA descriptors by adding cacheline size to the start address of the last DMA descriptor. This is not safe, as the cacheline size may be, in some unlikely cases, smaller than the DMA descriptor size. Replace the addition with roundup() applied on the end address of the last DMA descriptor to round it up to the nearest cacheline size multiple. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Jaehoon Chung <jh80.chung@samsung.com> Cc: Simon Glass <sjg@chromium.org>
| * | mmc: dw_mmc: Handle return value from bounce_buffer_start()Marek Vasut2019-04-291-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bounce_buffer_start() can return -ENOMEM in case memory allocation failed. However, in that case, the bounce buffer address is the same as the possibly unaligned input address, and the cache maintenance operations were not applied to this address. This could cause subtle problems. Add handling for the bounce_buffer_start() return value to prevent such a problem from happening. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Jaehoon Chung <jh80.chung@samsung.com> Cc: Simon Glass <sjg@chromium.org>
| * | mmc: dw_mmc: Calculate timeout from transfer lengthMarek Vasut2019-04-291-3/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current 4-minute data transfer timeout is misleading and broken. Instead of such a long wait, calculate the timeout duration based on the length of the data transfer. The current formula is the transfer length in bits, divided by a multiplication of bus frequency in Hz, bus width, DDR mode and converted the mSec. The value is bounded from the bottom to 1000 mSec. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Jaehoon Chung <jh80.chung@samsung.com> Cc: Simon Glass <sjg@chromium.org>
| * | ARM: socfpga: Add support for selecting bridges in bridge commandMarek Vasut2019-04-295-10/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add optional "mask" argument to the SoCFPGA bridge command, to select which bridges should be enabled/disabled. This allows the user to avoid enabling bridges which are not connected into the FPGA fabric. Default behavior is to enable/disable all bridges. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Chin Liang See <chin.liang.see@intel.com> Cc: Dinh Nguyen <dinguyen@kernel.org> Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Cc: Tien Fong Chee <tien.fong.chee@intel.com>
| * | ARM: socfpga: Fully unmap the FPGA bridges from L3 spaceMarek Vasut2019-04-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of just putting the bridges into reset, fully remove the bridges from the L3 main bridge space when disabling them by clearing bits in NIC-301 remap register. Moreover, only touch the 3 LSbits in brgmodrst register as the rest of the bits are undefined. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Chin Liang See <chin.liang.see@intel.com> Cc: Dinh Nguyen <dinguyen@kernel.org> Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Cc: Tien Fong Chee <tien.fong.chee@intel.com>
| * | ARM: socfpga: Disable bridges in SPL unless booting from FPGAMarek Vasut2019-04-291-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Disable bridges between L3 Main switch and FPGA unless booting from FPGA and keep them disabled to prevent glitches and possible hangs of the L3 Main switch. The current version of the code could have enabled the bridges between the L3 Main switch and FPGA for a short period of time in board_init_f() in case the FPGA was programmed and then again disable them at the end of board_init_f(). Replace this with a code which only sets up the handoff registers and let the user enable the bridges later on. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Chin Liang See <chin.liang.see@intel.com> Cc: Dinh Nguyen <dinguyen@kernel.org> Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Cc: Tien Fong Chee <tien.fong.chee@intel.com>
| * | ARM: socfpga: Factor out handoff register configurationMarek Vasut2019-04-292-2/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Factor out the code for programming preloader handoff register values, the ISWGRP Handoff 0 and 1. These registers later control which bridges are enabled by the "bridge" command on Gen5 devices. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Chin Liang See <chin.liang.see@intel.com> Cc: Dinh Nguyen <dinguyen@kernel.org> Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Cc: Tien Fong Chee <tien.fong.chee@intel.com>
* | | Merge git://git.denx.de/u-boot-usbTom Rini2019-05-032-5/+0
|\ \ \ | | | | | | | | | | | | - DaVinci updates
| * | | ARM: davinci: Remove unused functions from headerAdam Ford2019-05-031-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are a few functions defined in the header file, but they are not referenced by any Davinci code. In order to make a general function in the future with static function declarations, this patch will remove the references all together. Signed-off-by: Adam Ford <aford173@gmail.com>
| * | | usb: ohci: Re-enable commented out delayAdam Ford2019-05-031-2/+0
| | |/ | |/| | | | | | | | | | | | | | | | There is a delay function that was commented out. This patch re-enables it, because it will be needed for da850 ohci support. Signed-off-by: Adam Ford <aford173@gmail.com>
* | | Merge git://git.denx.de/u-boot-marvellTom Rini2019-05-037-195/+228
|\ \ \ | | | | | | | | | | | | | | | | - Fix in kwbimage (return code checking) (Young Xiao) - Misc updates to Turris Omnia (Marek)
| * | | arm: mvebu: turris_omnia: enable defconfig options needed by vendorMarek Behún2019-05-031-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This options will be enabled by default by CZ.NIC shipped U-Boot. Enable them in defconfig. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Stefan Roese <sr@denx.de>
| * | | arm: mvebu: turris_omnia: add GPIO support to defconfigMarek Behún2019-05-031-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for the gpio command and driver for the I2C connected pca9538 controller, to be able to determine if SFP module is present in the Turris Omnia router. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Stefan Roese <sr@denx.de>
| * | | i2c: mvtwsi: fix reading status register after interruptMarek Behún2019-05-031-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The twsi_wait function reads the control register for interrupt flag, and if interrupt flag is present, it immediately reads status register. On our device this sometimes causes bad value being read from status register, as if the value was not yet updated. My theory is that the controller does approximately this: 1. sets interrupt flag in control register, 2. sets the value of status register, 3. causes an interrupt In U-Boot we do not use interrupts, so I think that it is possible that sometimes the status register in the twsi_wait function is read between points 1 and 2. The bug does not appear if I add a small delay before reading status register. Wait 100ns (which in U-Boot currently means 1 us, because ndelay(i) function calls udelay(DIV_ROUND_UP(i, 1000))) before reading the status register. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Heiko Schocher <hs@denx.de> Reviewed-by: Stefan Roese <sr@denx.de> Cc: Mario Six <mario.six@gdsys.cc> Cc: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Stefan Roese <sr@denx.de>
| * | | arm: mvebu: turris_omnia: add RESET button handlingMarek Behún2019-05-032-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a Factory RESET button on the back side of the Turris Omnia router. When user presses this button before powering the device up and keeps it pressed, the microcontroller prevents the main CPU from booting and counts how long the RESET button is being pressed (and indicates this by lighting up front LEDs). The idea behind this is that the user can boot the device into several Factory RESET modes. This patch adds support for U-Boot to read into which Factory RESET mode the user booted the device. The value is an integer stored into the omnia_reset environment variable. It is 0 if the button was not pressed at all during power up, otherwise it is the number identifying the Factory RESET mode. This patch also changes bootcmd to a special hardcoded value if Factory RESET button was pressed during device powerup. This special bootcmd value sets the colors of all the LEDs on the front panel to green and then tries to load the rescue image from the SPI flash memory and boot it. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Stefan Roese <sr@denx.de>
| * | | arm: mvebu: turris_omnia: fix regdomain env var settingMarek Behún2019-05-031-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The regdomain environment variable is set according to value read from EEPROM. This has to be done in board_late_init, after the environment variables are read from SPI. Select CONFIG_BOARD_LATE_INIT in Kconfig for the Turris Omnia target. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Stefan Roese <sr@denx.de>
| * | | arm: mvebu: turris_*: remove watchdog includeMarek Behún2019-05-032-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since board watchdog is now unified and not handled in board files, remove the unnecessary includes. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Stefan Roese <sr@denx.de>
| * | | arm: mvebu: turris_omnia: print board info as Turris MoxMarek Behún2019-05-031-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unify the way how Omnia and Mox print board information (RAM size and serial number). Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> Signed-off-by: Stefan Roese <sr@denx.de>
generated by cgit (git 2.34.1) at 2024-11-19 17:42:48 +0000