summaryrefslogtreecommitdiff
path: root/arch
Commit message (Collapse)AuthorAgeLines
* ARM: OMAP5 / DRA7: Setup L2 Aux Control Register with recommended configurationNishanth Menon2015-03-13-0/+16
| | | | | | | | | | | Update to existing recommendation for L2ACTLR configuration to prevent system instability and optimize performance. These apply to both OMAP5 and DRA7. Reported-by: Vivek Chengalvala <vchengalvala@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* ARM: DRA7 / OMAP5: Add workaround for ARM errata 798870Praveen Rao2015-03-13-0/+10
| | | | | | | | | | | | | | | | | | | This patch enables the workaround for ARM errata 798870 for OMAP5 / DRA7 which says "If back-to-back speculative cache line fills (fill A and fill B) are issued from the L1 data cache of a CPU to the L2 cache, the second request (fill B) is then cancelled, and the second request would have detected a hazard against a recent write or eviction (write B) to the same cache line as fill B then the L2 logic might deadlock." An l2auxctlr accessor implementation for OMAP5 and DRA7 is introduced here as well. Signed-off-by: Praveen Rao <prao@ti.com> Signed-off-by: Angela Stegmaier <angelabaker@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Matt Porter <mporter@konsulko.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* ARM: OMAP3: Get rid of omap3_gp_romcode_call and replace with omap_smc1Nishanth Menon2015-03-13-17/+5
| | | | | | | | | | | | omap_smc1 is now generic enough to remove duplicate omap3_gp_romcode_call logic that omap3 introduced. As part of this change, move to using the generic lowlevel_init.S for omap3 as well. Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Matt Porter <mporter@konsulko.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* ARM: OMAP3: Rename omap3.h to omap.h to be generic as all SoCsNishanth Menon2015-03-13-0/+0
| | | | | | | | This is in preperation of using generic cross OMAP code. Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Matt Porter <mporter@konsulko.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* ARM: OMAP: Change set_pl310_ctrl_reg to be genericNishanth Menon2015-03-13-10/+18
| | | | | | | | | | | | | | | | | | | set_pl310_ctrl_reg does use the Secure Monitor Call (SMC) to setup PL310 control register, however, that is something that is generic enough to be used for OMAP5 generation of processors as well. The only difference being the service being invoked for the function. So, convert the service to a macro and use a generic name (same as that used in Linux for some consistency). While at that, also add a data barrier which is necessary as per recommendation. While at this, smc #0 is maintained as handcoded assembly thanks to various gcc version eccentricities, discussion thread: http://marc.info/?t=142542166800001&r=1&w=2 Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Matt Porter <mporter@konsulko.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* ARM: Introduce erratum workaround for 621766Nishanth Menon2015-03-13-0/+13
| | | | | | | | | | | | | 621766: Under a specific set of conditions, executing a sequence of NEON or vfp load instructions can cause processor deadlock Impacts: Every Cortex-A8 processors with revision lower than r2p1 Work around: Set L1NEON to 1 Based on ARM errata Document revision 20.0 (13 Nov 2010) Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Matt Porter <mporter@konsulko.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* ARM: Introduce erratum workaround for 430973Nishanth Menon2015-03-13-0/+13
| | | | | | | | | | | | | 430973: Stale prediction on replaced inter working branch causes Cortex-A8 to execute in the wrong ARM/Thumb state Impacts: Every Cortex-A8 processors with revision lower than r2p1 Work around: Set IBE to 1 Based on ARM errata Document revision 20.0 (13 Nov 2010) Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Matt Porter <mporter@konsulko.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* ARM: Introduce erratum workaround for 454179Nishanth Menon2015-03-13-0/+21
| | | | | | | | | | | | | | | 454179: Stale prediction may inhibit target address misprediction on next predicted taken branch Impacts: Every Cortex-A8 processors with revision lower than r2p1 Work around: Set IBE and disable branch size mispredict to 1 Also provide a hook for SoC specific handling to take place if needed. Based on ARM errata Document revision 20.0 (13 Nov 2010) Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Matt Porter <mporter@konsulko.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* ARM: Introduce erratum workaround for 798870Nishanth Menon2015-03-13-2/+51
| | | | | | | | | | | | | | | | | | | | | | | Add workaround for Cortex-A15 ARM erratum 798870 which says "If back-to-back speculative cache line fills (fill A and fill B) are issued from the L1 data cache of a CPU to the L2 cache, the second request (fill B) is then cancelled, and the second request would have detected a hazard against a recent write or eviction (write B) to the same cache line as fill B then the L2 logic might deadlock." Implementations for SoC families such as Exynos, OMAP5/DRA7 etc will be widely different. Every SoC has slightly different manner of setting up access to L2ACLR and similar registers since the Secure Monitor handling of Secure Monitor Call(smc) is diverse. Hence an weak function is introduced which may be overriden to implement SoC specific accessor implementation. Based on ARM errata Document revision 18.0 (22 Nov 2013) Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Matt Porter <mporter@konsulko.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* Merge branch 'master' of git://git.denx.de/u-boot-tegraTom Rini2015-03-10-88/+1158
|\ | | | | | | | | | | | | Conflicts: README Signed-off-by: Tom Rini <trini@konsulko.com>
| * apalis/colibri_t30: fix MMC/SD card detect GPIOsMarcel Ziswiler2015-03-04-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes the MMC/SD card detect GPIOs for Apalis T30 which got broken by the following commit: 2b2b50bc8748 "dm: tegra: dts: Use TEGRA_GPIO() macro for all GPIOs" While at it also re-add the comments describing which particular Apalis/Colibri pins those GPIOs are on. Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Stefan Agner <stefan.agner@toradex.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * dm: tegra: dts: add aliases for spi on apalis_t30Marcel Ziswiler2015-03-04-0/+4
| | | | | | | | | | | | | | | | | | | | | | All boards with a SPI interface have a suitable spi alias except Apalis T30. Add these missing aliases just as the following commit did for the others: d2f60f93325a "dm: tegra: dts: Add aliases for spi on tegra30 boards" Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: pinmux: add Tegra210 supportStephen Warren2015-03-04-0/+611
| | | | | | | | | | | | | | This patch incorporates a few fixes from Tom Warren <twarren@nvidia.com>. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: pinmux: support Tegra210's e_io_hv pin optionStephen Warren2015-03-04-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tegra210 has a per-pin option named e_io_hv, which indicates that the pin's input path should be configured to be 3.3v-tolerant. Add support for this. Note that this is very similar to previous chip's rcv_sel option. However, since the Tegra TRM names this option differently for the different chips, we support the new name so that the code exactly matches the naming in the TRM, to avoid confusion. This patch incorporates a few fixes from Tom Warren <twarren@nvidia.com>. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: pinmux: account for different drivegroup base registersStephen Warren2015-03-04-1/+5
| | | | | | | | | | | | | | | | Tegra210 starts its drive group registers at a different offset from the APB MISC register block that other SoCs. Update the code to handle this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: pinmux: support hsm/schmitt on pinsStephen Warren2015-03-04-4/+72
| | | | | | | | | | | | | | | | | | T210 support HSM and Schmitt options in the pinmux register (previous chips placed these options in the drive group register). Update the code to handle this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: pinmux: partially handle varying register layoutsStephen Warren2015-03-04-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | Tegra210 moves some bits around in the pinmux registers. Update the code to handle this. This doesn't attempt to address the issues with the group-to-group varying drive group register layout mentioned earlier. This patch handles the SoC-to-SoC differences in the mux register layout. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: pinmux: move some type definitionsStephen Warren2015-03-04-44/+44
| | | | | | | | | | | | | | | | | | On some future SoCs, some per-drive-group features became per-pin features. Move all type definitions early in the header so they can be enabled irrespective of the setting of TEGRA_PMX_SOC_HAS_DRVGRPS. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: pinmux: handle feature removal on newer SoCsStephen Warren2015-03-04-0/+45
| | | | | | | | | | | | | | | | On some future SoCs, some of the per-drive-group features no longer exist. Add some ifdefs to support this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: pinmux: simplify some definesStephen Warren2015-03-04-32/+73
| | | | | | | | | | | | | | | | | | | | Future SoCs have a slightly different combination of pinmux options per pin. This will be simpler to handle if we simply have one define per option, rather than grouping various options together, in combinations that don't align with future chips. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: pinmux: add note re: drive group field definesStephen Warren2015-03-04-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tegra's drive group registers have a remarkably inconsistent layout. The current U-Boot driver doesn't take this into account at all. Add a comment to describe the issue, so at least anyone debugging the driver will be aware of this. To solve this, we'd need to add a per-drive-group data structure describing the layout for the individual register. Since we don't set up too many drive groups in U-Boot at present, this hopefully isn't causing too much practical issue. Still, we probably need to fix this sometime. Wth Tegra210, the register layout becomes almost entirely consistent, so this problem partially solves itself over time. Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: add function to clear pinmux CLAMPING bitStephen Warren2015-03-04-5/+10
| | | | | | | | | | | | | | | | This is needed to correctly apply the new Jetson TK1 pinmux config. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: support running in non-secure modeStephen Warren2015-03-04-1/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the CPU is in non-secure (NS) mode (when running U-Boot under a secure monitor), certain actions cannot be taken, since they would need to write to secure-only registers. One example is configuring the ARM architectural timer's CNTFRQ register. We could support this in one of two ways: 1) Compile twice, once for secure mode (in which case anything goes) and once for non-secure mode (in which case certain actions are disabled). This complicates things, since everyone needs to keep track of different U-Boot binaries for different situations. 2) Detect NS mode at run-time, and optionally skip any impossible actions. This has the advantage of a single U-Boot binary working in all cases. (2) is not possible on ARM in general, since there's no architectural way to detect secure-vs-non-secure. However, there is a Tegra-specific way to detect this. This patches uses that feature to detect secure vs. NS mode on Tegra, and uses that to: * Skip the ARM arch timer initialization. * Set/clear an environment variable so that boot scripts can take different action depending on which mode the CPU is in. This might be something like: if CPU is secure: load secure monitor code into RAM. boot secure monitor. secure monitor will restart (a new copy of) U-Boot in NS mode. else: execute normal boot process Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: support large RAM sizesStephen Warren2015-03-04-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some systems have so much RAM that the end of RAM is beyond 4GB. An example would be a Tegra124 system (where RAM starts at 2GB physical) that has more than 2GB of RAM. In this case, we want gd->ram_size to represent the actual RAM size, so that the actual RAM size is passed to the OS. This is useful if the OS implements LPAE, and can actually use the "extra" RAM. However, we can't use get_ram_size() to verify the actual amount of RAM present on such systems, since some of the RAM can't be accesses, which confuses that function. Avoid calling get_ram_size() when the RAM size is too large for it to work correctly. It's never actually needed anyway, since there's no reason for the BCT to report the wrong RAM size. In systems with >=4GB RAM, we still need to clip the reported RAM size since U-Boot uses a 32-bit variable to represent the RAM size in bytes. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: tegra: fix variable naming in query_sdram_size()Stephen Warren2015-03-04-8/+9
| | | | | | | | | | | | | | | | | | | | size_mb is used to hold a value that's sometimes KB, sometimes MB, and sometimes bytes. Use separate correctly named variables to avoid confusion here. Also fix indentation of a conditional statement. Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Warren <twarren@nvidia.com>
| * ARM: HYP/non-sec: relocation before enable secondary coresPeng Fan2015-03-01-1/+8
| | | | | | | | | | | | | | | | | | | | If CONFIG_ARMV7_PSCI is not defined and CONFIG_ARMV7_SECURE_BASE is defined, smp_kicl_all_cpus may enable secondary cores and runs into secure_ram_addr( _smp_pen), before code is relocated to secure ram. So need relocation to secure ram before enable secondary cores. Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
| * edminiv2: switch to SPLAlbert ARIBAUD2015-02-25-2/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ED Mini V2 is based on Orion 5x which boots at fixed address 0xFFFF0000 in NOR Flash. Place SPL there, and switch U-Boot from .bin to .img format, stored in NOR Flash at 0xFFF90000. Note: this patch was tested on HW and works, i.e. it boots U-Boot properly, but SPL console output currently does not appear, due to GD being trashed by arch/arm/lib/spl.c. This trashing is soon to be removed, and then ED Mini V2 SPL console output will become visible. Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
| * edminiv2: fix PCIE IO base address typoAlbert ARIBAUD2015-02-25-1/+1
| | | | | | | | Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
| * Merge remote-tracking branch 'u-boot/master' into 'u-boot-arm/master'Albert ARIBAUD2015-02-24-3339/+18395
| |\
| * | arm: Show relocated PC/LR in the register dumpSimon Glass2015-02-03-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | If we don't know the relocation address, the raw values are not very useful. Show the pre-relocation values as well as these can be looked up in System.map, etc. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
| * | Errata/ARM57: Add basic constructs to handle and apply A57 specific erratasBhupesh Sharma2015-01-31-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds basic constructs in the ARMv8 u-boot code to handle and apply Cortex-A57 specific erratas. As and example, the framework showcases how erratas 833069, 826974 and 828024 can be handled and applied. Later on this framework can be extended to include other erratas. Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
* | | armv8/vexpress64: make multientry conditionalLinus Walleij2015-03-09-4/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While the Freescale ARMv8 board LS2085A will enter U-Boot both on a master and a secondary (slave) CPU, this is not the common behaviour on ARMv8 platforms. The norm is that U-Boot is entered from the master CPU only, while the other CPUs are kept in WFI (wait for interrupt) state. The code determining which CPU we are running on is using the MPIDR register, but the definition of that register varies with platform to some extent, and handling multi-cluster platforms (such as the Juno) will become cumbersome. It is better to only enable the multiple entry code on machines that actually need it and disable it by default. Make the single entry default and add a special ARMV8_MULTIENTRY KConfig option to be used by the platforms that need multientry and set it for the LS2085A. Delete all use of the CPU_RELEASE_ADDR from the Vexpress64 boards as it is just totally unused and misleading, and make it conditional in the generic start.S code. This makes the Juno platform start U-Boot properly. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* | | ARM: PSCI: Rework the DT handler slightlyTom Rini2015-03-09-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way the PSCI DT update happens currently means we pull in <asm/armv7.h> everywhere, including on ARMv8 and that in turn brings in <asm/io.h> for some non-PSCI related things that header needs to deal with. To fix this, we rework the hook slightly. A good portion of arch/arm/cpu/armv7/virt-dt.c is common looking and I hope that when PSCI is needed on ARMv8 we can re-use this by and large. So rename the current hook to psci_update_dt(), move the prototype to <asm/psci.h> and add an #ifdef that will make re-use later easier. Reported-by: York Sun <yorksun@freescale.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: York Sun <yorksun@freescale.com> Cc: Ian Campbell <ijc@hellion.org.uk> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Signed-off-by: Tom Rini <trini@konsulko.com> Acked-by: York Sun <yorksun@freescale.com>
* | | arm: relocation: clear .bss section with arch memset if definedPrzemyslaw Marczak2015-03-09-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For ARM architecture, enable the CONFIG_USE_ARCH_MEMSET/MEMCPY, will highly increase the memset/memcpy performance. This is able thanks to the ARM multiple register instructions. Unfortunatelly the relocation is done without the cache enabled, so it takes some time, but zeroing the BSS memory takes much more longer, especially for the configs with big static buffers. A quick test confirms, that the boot time improvement after using the arch memcpy for relocation has no significant meaning. The same test confirms that enable the memset for zeroing BSS, reduces the boot time. So this patch enables the arch memset for zeroing the BSS after the relocation process. For ARM boards, this can be enabled in board configs by defining: 'CONFIG_USE_ARCH_MEMSET'. This was tested on Trats2. A quick test with trace. Boot time from start to main_loop() entry: - ~1384ms - before this change - ~888ms - after this change Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Albert Aribaud <albert.u.boot@aribaud.net> Cc: Tom Rini <trini@konsulko.com>
* | | Merge git://git.denx.de/u-boot-socfpgaTom Rini2015-03-05-1/+196
|\ \ \
| * | | dt: socfpga: Import and enable Arria V DK DTSMarek Vasut2015-03-04-0/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Import DTS for Arria V development kit and enable support for DT. The DT is imported from Linux 3.19-rc1 as of commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672 . Signed-off-by: Marek Vasut <marex@denx.de> Cc: Chin Liang See <clsee@opensource.altera.com> Cc: Dinh Nguyen <dinguyen@opensource.altera.com> Acked-by: Pavel Machek <pavel@denx.de> Reviewed-by: Stefan Roese <sr@denx.de> Cc: Vince Bridgers <vbridger@opensource.altera.com>
| * | | dt: socfpga: Import and enable Cyclone V DK DTSMarek Vasut2015-03-04-1/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Import DTS for Cyclone V development kit and enable support for DT. The DT is imported from Linux 3.19-rc1 as of commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672 . Signed-off-by: Marek Vasut <marex@denx.de> Cc: Chin Liang See <clsee@opensource.altera.com> Cc: Dinh Nguyen <dinguyen@opensource.altera.com> Acked-by: Pavel Machek <pavel@denx.de> Reviewed-by: Stefan Roese <sr@denx.de> Cc: Vince Bridgers <vbridger@opensource.altera.com>
| * | | arm: socfpga: Add Altera Arria V DK supportMarek Vasut2015-03-04-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for the Altera Arria V development kit. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Chin Liang See <clsee@opensource.altera.com> Cc: Dinh Nguyen <dinguyen@opensource.altera.com> Cc: Pavel Machek <pavel@denx.de> Cc: Stefan Roese <sr@denx.de> Cc: Vince Bridgers <vbridger@opensource.altera.com>
* | | | Merge branch 'master' of git://git.denx.de/u-boot-mpc85xxTom Rini2015-03-05-21/+340
|\ \ \ \
| * | | | SECURE_BOOT : enable esbc_validate command for powerpc and arm platforms.gaurav rana2015-03-05-1/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | esbc_validate command uses various IP Blocks: Security Monitor, CAAM block and SFP registers. Hence the respective CONFIG's are enabled. Apart from these CONFIG_SHA_PROG_HW_ACCEL and CONFIG_RSA are also enabled. Signed-off-by: Gaurav Rana <gaurav.rana@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
| * | | | fsl_sfp : Move ccsr_sfp_regs definition to common includegaurav rana2015-03-05-15/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Freescale sfp has been used for mpc8xxx. It will be used for ARM-based SoC as well. This patch moves the CCSR defintion of sfp_regs to common include. This patch also defines ccsr_sfp_regs definition for newer versions of SFP. Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com> Signed-off-by: Gaurav Rana <gaurav.rana@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
| * | | | powerpc: 85xx: Modify CONFIG_USB_MAX_CONTROLLER_COUNT for P1022DSYing Zhang2015-03-04-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Modify CONFIG_USB_MAX_CONTROLLER_COUNT value to 1 on P1022DS. As ETSEC2 and USB2 are muxed; thus if ETSEC2 is enabled, the system bus hangs on USB2 if ETSEC2 is enabled but "usb start" command is issued. Hence making default controller count to 1 to avoid system hang. Signed-off-by: Nikhil Badola <nikhil.badola@freescale.com> Reviewed-by: Yusong Sun <yorksun@freescale.com>
| * | | | powerpc/mpc85xx: Add DSP side awareness for Freescale Heterogeneous SoCsShaveta Leekha2015-03-04-3/+275
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code provides framework for heterogeneous multicore chips based on StarCore and Power Architecture which are chasis-2 compliant, like B4860 and B4420 It will make u-boot recognize all non-ppc cores and peripherals like SC3900/DSP CPUs, MAPLE, CPRI and print their configuration in u-boot logs. Example boot logs of B4860QDS: U-Boot 2015.01-00232-geef6e36-dirty (Jan 19 2015 - 11:58:45) CPU0: B4860E, Version: 2.2, (0x86880022) Core: e6500, Version: 2.0, (0x80400120) Clock Configuration: CPU0:1600 MHz, CPU1:1600 MHz, CPU2:1600 MHz, CPU3:1600 MHz, DSP CPU0:1200 MHz, DSP CPU1:1200 MHz, DSP CPU2:1200 MHz, DSP CPU3:1200 MHz, DSP CPU4:1200 MHz, DSP CPU5:1200 MHz, CCB:666.667 MHz, DDR:933.333 MHz (1866.667 MT/s data rate) (Asynchronous), IFC:166.667 MHz CPRI:600 MHz MAPLE:600 MHz, MAPLE-ULB:800 MHz, MAPLE-eTVPE:1000 MHz FMAN1: 666.667 MHz QMAN: 333.333 MHz Top level changes include: (1) Top level CONFIG to identify HETEROGENUOUS clusters (2) CONFIGS for SC3900/DSP components (3) Global structures like "cpu_type" and "MPC85xx_SYS_INFO" updated for dsp cores and other components (3) APIs to get DSP num cores and their Mask like: cpu_dsp_mask, cpu_num_dspcores etc same as that of PowerPC (5) Code to fetch and print SC cores and other heterogenous device's frequencies (6) README added for the same Signed-off-by: Shaveta Leekha <shaveta@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
* | | | use ASM_NL instead of '; ' for assembler new line character in the macroChen Gang2015-03-05-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For some assemblers, they use another character as newline in a macro (e.g. arc uses '`'), so for generic assembly code, need use ASM_NL (a macro) instead of ';' for it. Basically this is the same patch as applied to Linux kernel - http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/include/linux/linkage.h?id=9df62f054406992ce41ec4558fca6a0fa56fffeb but modified a bit to fit in U-Boot. Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@ti.com>
* | | | omap: gpmc: 'nandecc sw' can use HAM1 or BCH8Ash Charles2015-03-05-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The 'nandecc sw' command selects a software-based error correction algorithm. By default, this is OMAP_ECC_HAM1_CODE_SW but some platforms use OMAP_ECC_BCH8_CODE_HW_DETECTION_SW as their software-based correction algorithm. Allow a user to be specific e.g. # nandecc sw <hamming|bch8> where 'hamming' is still the default. Note: we don't just use CONFIG_NAND_OMAP_ECCSCHEME as it might be set to a hardware-based ECC scheme---a little strange when the user has requested 'sw' ECC. Signed-off-by: Ash Charles <ashcharles@gmail.com>
* | | | m68k: add generic-board supportangelo@sysam.it2015-03-05-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | Add generic-board support for the m68k architecture. Signed-off-by: Angelo Dureghello <angelo@sysam.it>
* | | | m68k: add mcf5307 cpu supportangelo@sysam.it2015-03-05-2/+742
| | | | | | | | | | | | | | | | | | | | | | | | Add Freescale MCF5307 cpu support. Signed-off-by: Angelo Dureghello <angelo@sysam.it>
* | | | m68k: add amcore board supportangelo@sysam.it2015-03-05-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | Add Sysam Amcore m68k-based board support. Signed-off-by: Angelo Dureghello <angelo@sysam.it>
* | | | Adding Support for BAV335x boardsGilles Gameiro2015-03-05-0/+14
| | | |
* | | | omap3: add support for QUIPOS Cairo board.Albert ARIBAUD \(3ADEV\)2015-03-05-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch extends OMAP3 support for AM/DM37xx and introduces the AM3703-based Quipos Cairo board. Signed-off-by: Albert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr> Reviewed-by: Simon Glass <sjg@chromium.org>
generated by cgit v1.1 at 2024-11-09 09:07:14 +0000