| Age | Commit message (Collapse) | Author |
|---|
|
Drop all duplicate newlines. No functional change.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Maxim Uvarov <[email protected]> says:
Add small net fixes prior lwip patches.
|
|
Use device specific naming for functions so as to not overlap
with common function names.
Signed-off-by: Maxim Uvarov <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Prepare v2024.01-rc3
|
|
Replace instances of http://www.ti.com with https://www.ti.com
Signed-off-by: Nishanth Menon <[email protected]>
|
|
The include <asm/arch/cpu.h> references values in <asm/arch/omap3.h> and
so include it directly here rather than rely on indirect inclusion.
Signed-off-by: Tom Rini <[email protected]>
|
|
As part of various code clean-ups we have on occasion missed removing
unused header files. None of these files are referenced anywhere else
at this point.
Signed-off-by: Tom Rini <[email protected]>
|
|
There are a few memory functions for both the emif4 (AM3517)
and sdrc (OMAP35/DM37) code that can be defined as static,
because those functions are not used externally. Make them
static and clean up some of the corresponding headers.
Signed-off-by: Adam Ford <[email protected]>
|
|
With LTO enabled, some functions appear to be optimized in a
way that causes hanging on some OMAP3 boards after some
unrelated patches were applied. The solution appears to make
several functions __used. There also appears be to be some
dead code, so remove it while cleaning this up.
This has been tested on a general purpose OMAP3530, DM3730,
and AM3517.
Signed-off-by: Adam Ford <[email protected]>
|
|
secureworld_exit() is only used in one file, so make it static
to that file and remove it from sys_proto.h. This
may help with some further optimization in the future.
Signed-off-by: Adam Ford <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
try_unlock_memory() is only used in one file, so make it static
in that file,remove it from the sys_proto header file, and relocate
it into the #ifdef section that call it. This will make it only built
under the conditions when it is called, and it may help with some
further optimization in the future.
Signed-off-by: Adam Ford <[email protected]>
Signed-off-by: Lokesh Vutla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Move away from SoC specific headers to handle different register layout.
Instead use driver data to get appropriate register layouts like in the
kernel. While at it, perform some mostly cosmetic alignment/cleanup in
the functions being updated.
Signed-off-by: Vignesh R <[email protected]>
Signed-off-by: Andreas Dannenberg <[email protected]>
Signed-off-by: Jean-Jacques Hiblot <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
The MMC card detect pin is connected to gpio127 on omap3_logic.
When setting up the pbias register for MMC, let's also enable
gpio_127 for the card detect. As part of the package deal,
gpio_126 and gpio_129 are also enabled.
Signed-off-by: Adam Ford <[email protected]>
|
|
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <[email protected]>
|
|
This converts the following to Kconfig:
CONFIG_SYS_I2C_BUS_MAX
Signed-off-by: Adam Ford <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
[trini: Fix AM43XX drop AM44XX]
Signed-off-by: Tom Rini <[email protected]>
|
|
For consistency with other platforms and in preparation of Kconfig
migration, let's change Several TI platforms that use I2C_BUS_MAX
to CONFIG_SYS_I2C_BUS_MAX
Signed-off-by: Adam Ford <[email protected]>
|
|
Refactor OMAP3/4/5 code so that we have only one get_device_type()
function for all platforms.
Details:
- Add ctrl variable for AM33xx and OMAP3 platforms (like it's done for
OMAP4/5), so we can obtain status register in common way
- For now ctrl structure for AM33xx/OMAP3 contains only status register
address
- Run hw_data_init() in order to assign ctrl to proper structure
- Remove DEVICE_MASK and DEVICE_GP definitions as they are not used
(DEVICE_TYPE_MASK and GP_DEVICE are used instead)
- Guard structs in omap_common.h with #ifdefs, because otherwise
including omap_common.h on non-omap4/5 board files breaks compilation
Buildman script was run for all OMAP boards. Result output:
arm: (for 38/616 boards)
all +352.5
bss -1.4
data +3.5
rodata +300.0
spl/u-boot-spl:all +284.7
spl/u-boot-spl:data +2.2
spl/u-boot-spl:rodata +252.0
spl/u-boot-spl:text +30.5
text +50.4
(no errors to report)
Tested on AM57x EVM and BeagleBoard xM.
Signed-off-by: Sam Protsenko <[email protected]>
Reviewed-by: Lokesh Vutla <[email protected]>
[trini: Rework the guards as to not break TI81xx]
Signed-off-by: Tom Rini <[email protected]>
|
|
The register names and offset were not correct as per the TRM for OMAP3530
and OMAP3630. Correct the naing and offsets per the documentation
Signed-off-by: Adam Ford <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
The workaround for ARM errata 725233 had been lost since
commit 45bf05854bc94e (armv7: adapt omap3 to the new cache
maintenance framework). Bring it back in order to avoid
very difficult to reproduce, but actually encountered in
the wild CPU deadlocks when running software rendered
X11 desktop on OMAP3530 hardware.
Signed-off-by: Siarhei Siamashka <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
[trini: Migrate to Kconfig]
Signed-off-by: Tom Rini <[email protected]>
|
|
Currently nandecc returns zero even if underlaying
omap_nand_switch_ecc function fails. Fix that by
propagating error returned to command return value.
Signed-off-by: Ladislav Michl <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
The check for OMAP3630/3730 only checks for 800MHz 3630/3730, but
anything else is lumped into 36XX/37XX with an assumed 1GHz speed.
Based on the DM3730 TRM bit 9 shows the MPU Frequency (800MHz/1GHZ).
This also adds the ability to distinguish between the DM3730, DM3725,
AM3715, and AM3703 and correctly display their maximum speed.
Signed-off-by: Adam Ford <[email protected]>
Tested-by: Ladislav Michl <[email protected]>
|
|
Currently all backend driver ops uses hard coded physical
address, so to adopt the driver to DM, add device pointer to ops
call backs so that drivers can get physical addresses from the
usb driver priv/plat data.
Signed-off-by: Mugunthan V N <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
On all TI platforms the ROM defines a "downloaded image" area at or near
the start of SRAM which is followed by a reserved area. As it is at
best bad form and at worst possibly harmful in corner cases to write in
this reserved area, we stop doing that by adding in the define
NON_SECURE_SRAM_IMG_END to say where the end of the downloaded image
area is and make SRAM_SCRATCH_SPACE_ADDR be one kilobyte before this.
At current we define the end of scratch space at 0x228 bytes past the
start of scratch space this this gives us a lot of room to grow. As
these scratch uses are non-optional today, all targets are modified to
respect this boundary.
Tested on OMAP4 Pandaboard, OMAP3 Beagle xM
Cc: Albert Aribaud <[email protected]>
Cc: Nagendra T S <[email protected]>
Cc: Vaibhav Hiremath <[email protected]>
Cc: Lokesh Vutla <[email protected]>
Cc: Felipe Balbi <[email protected]>
Cc: Igor Grinberg <[email protected]>
Cc: Nikita Kiryanov <[email protected]>
Cc: Paul Kocialkowski <[email protected]>
Cc: Enric Balletbo i Serra <[email protected]>
Cc: Adam Ford <[email protected]>
Cc: Steve Sakoman <[email protected]>
Cc: Stefan Roese <[email protected]>
Cc: Thomas Weber <[email protected]>
Cc: Hannes Schmelzer <[email protected]>
Cc: Thomas Chou <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Joe Hershberger <[email protected]>
Cc: Sam Protsenko <[email protected]>
Cc: Heiko Schocher <[email protected]>
Cc: Samuel Egli <[email protected]>
Cc: Michal Simek <[email protected]>
Cc: Wolfgang Denk <[email protected]>
Cc: Mateusz Kulikowski <[email protected]>
Cc: Ben Whitten <[email protected]>
Cc: Stefano Babic <[email protected]>
Cc: Bin Meng <[email protected]>
Cc: Sekhar Nori <[email protected]>
Cc: Mugunthan V N <[email protected]>
Cc: "B, Ravi" <[email protected]>
Cc: "Matwey V. Kornilov" <[email protected]>
Cc: Ladislav Michl <[email protected]>
Cc: Ash Charles <[email protected]>
Cc: "Kipisz, Steven" <[email protected]>
Cc: Daniel Allred <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
Tested-by: Lokesh Vutla <[email protected]>
Acked-by: Lokesh Vutla <[email protected]>
Tested-by: Ladislav Michl <[email protected]>
|
|
Allow boards to runtime detect flash type.
Signed-off-by: Ladislav Michl <[email protected]>
|
|
Signed-off-by: Ladislav Michl <[email protected]>
[trini: Adapt am33xx, duovero, omap_zoom1]
Signed-off-by: Tom Rini <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
identify_nand_chip hangs forever in loop when NAND is not present.
As IGEPv2 comes either with NAND or OneNAND flash, add reset timeout
to let function fail gracefully allowing caller to know NAND is
not present. On NAND equipped board, reset succeeds on first read,
so 1000 loops seems to be safe timeout.
Signed-off-by: Ladislav Michl <[email protected]>
|
|
Update the CPU string output so that the device
type is now included as part of the CPU string that
is printed as the SPL or u-boot comes up. This update
adds a suffix of the form "-GP" or "-HS" for production
devices, so that general purpose (GP) and high security
(HS) can be distiguished. Applies to all OMAP5 variants.
Signed-off-by: Daniel Allred <[email protected]>
Signed-off-by: Madan Srinivas <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
This introduces a define for the offset to the reboot reason, rather than
hardcoding it.
Signed-off-by: Paul Kocialkowski <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
This switches reboot mode handling to a string-based interface, that allows more
flexibility to set a common interface with the next generations of OMAP devices.
Signed-off-by: Paul Kocialkowski <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
This introduces omap_die_id_display to display the full die id.
There is no need to store it in an environment variable, that no boot script
is using anyway.
Signed-off-by: Paul Kocialkowski <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
This replaces the previous get_dieid definition with omap_die_id, that matches
the common omap_die_id definition.
Signed-off-by: Paul Kocialkowski <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Reboot mode is written in scratchpad memory before reboot in the form of a
single char, that is the first letter of the reboot mode string as passed to the
reboot function.
This mechanism is supported on OMAP3 both my the upstream kernel and by various
TI kernels.
It is up to each board to make use of this mechanism or not.
Signed-off-by: Paul Kocialkowski <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
This introduces code to read the value of the SYS_BOOT pins on the OMAP3, as
well as the memory-preferred scheme for the interpretation of each value.
Signed-off-by: Paul Kocialkowski <[email protected]>
|
|
This cleans up the SPL boot devices for omap platforms and introduces support
for missing boot devices.
Signed-off-by: Paul Kocialkowski <[email protected]>
|
|
This introduces OMAP3 support for the common omap boot code, as well as a
major cleanup of the common omap boot code.
First, the omap_boot_parameters structure becomes platform-specific, since its
definition differs a bit across omap platforms. The offsets are removed as well
since it is U-Boot's coding style to use structures for mapping such kind of
data (in the sense that it is similar to registers). It is correct to assume
that romcode structure encoding is the same as U-Boot, given the description
of these structures in the TRMs.
The original address provided by the bootrom is passed to the U-Boot binary
instead of a duplicate of the structure stored in global data. This allows to
have only the relevant (boot device and mode) information stored in global data.
It is also expected that the address where the bootrom stores that information
is not overridden by the U-Boot SPL or U-Boot.
The save_omap_boot_params is expected to handle all special cases where the data
provided by the bootrom cannot be used as-is, so that spl_boot_device and
spl_boot_mode only return the data from global data.
All of this is only relevant when the U-Boot SPL is used. In cases it is not,
save_boot_params should fallback to its weak (or board-specific) definition.
save_omap_boot_params should not be called in that context either.
Signed-off-by: Paul Kocialkowski <[email protected]>
|
|
RX51 has a secure logic which uses different parameters compared to
traditional implementation. So, make the generic secure acr write
over-ride-able by board file and refactor rx51 code to use this.
While at it, enable the OMAP3 specific errata code for 454179, 430973,
621766.
Signed-off-by: Nishanth Menon <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
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 <[email protected]>
Tested-by: Matt Porter <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
This is in preperation of using generic cross OMAP code.
Signed-off-by: Nishanth Menon <[email protected]>
Tested-by: Matt Porter <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Signed-off-by: Albert ARIBAUD (3ADEV) <[email protected]>
|
|
Signed-off-by: Albert ARIBAUD (3ADEV) <[email protected]>
|
|
Signed-off-by: Albert ARIBAUD (3ADEV) <[email protected]>
|
|
Signed-off-by: Albert ARIBAUD (3ADEV) <[email protected]>
|
|
|
|
Signed-off-by: Jeroen Hofstee <[email protected]>
|
|
Fix the following checkpatch issues:
CHECK: No space is necessary after a cast
\#39: FILE: arch/arm/include/asm/arch-am33xx/mux.h:39:
+#define PAD_CTRL_BASE 0x800
+#define OFFSET(x) (unsigned int) (&((struct pad_signals *) \
CHECK: Avoid CamelCase: <CONTROL_PADCONF_JTAG_nTRST>
\#284: FILE: arch/arm/include/asm/arch-omap3/mux.h:284:
+#define CONTROL_PADCONF_JTAG_nTRST 0x0A1C
ERROR: space required after that ',' (ctx:VxV)
\#446: FILE: arch/arm/include/asm/arch-omap3/mux.h:446:
+#define MUX_VAL(OFFSET,VALUE)\
^
Cc: Raphael Assenat <[email protected]>
Cc: Ilya Yanok <[email protected]>
Cc: Vaibhav Hiremath <[email protected]>
Cc: Peter Barada <[email protected]>
Cc: Grazvydas Ignotas <[email protected]>
Cc: Stefan Roese <[email protected]>
Cc: Stefano Babic <[email protected]>
Cc: Nagendra T S <[email protected]>
Cc: Nishanth Menon <[email protected]>
Cc: Tom Rini <[email protected]>
Signed-off-by: Igor Grinberg <[email protected]>
Acked-by: Stefan Roese <[email protected]>
|
|
PISMO_xx macros were used to define 'Platform Independent Storage MOdule'
related GPMC configurations. This patch
- Replaces these OMAP3 specific macros with generic CONFIG_xx macros as provided
by current u-boot infrastructure.
- Removes unused redundant macros, which are no longer required after
merging of common platform code in following commit
commit a0a37183bd75e74608bc78c8d0e2a34454f95a91
ARM: omap: merge GPMC initialization code for all platform
+-----------------+-----------------------------------------------------------+
| Macro | Reason for removal |
+-----------------+-----------------------------------------------------------+
| PISMO1_NOR_BASE | duplicate of CONFIG_SYS_FLASH_BASE |
+-----------------+-----------------------------------------------------------+
| PISMO1_NAND_BASE| duplicate of CONFIG_SYS_NAND_BASE |
+-----------------+-----------------------------------------------------------+
| PISMO1_ONEN_BASE| duplicate of CONFIG_SYS_ONENAND_BASE |
+-----------------+-----------------------------------------------------------+
| PISMO1_NAND_SIZE| GPMC accesses NAND device via I/O mapped registers so |
| | configuring GPMC chip-select for smallest allowable |
| | segment (GPMC_SIZE_16M) is enough. |
+-----------------+-----------------------------------------------------------+
| PISMO1_ONEN_SIZE| OneNAND uses a fixed GPMC chip-select address-space of |
| | 128MB (GPMC_SIZE_128M) |
+-----------------+-----------------------------------------------------------+
+-----------------+-----------------------------------------------------------+
| PISMO1_NOR | Unused Macros |
| PISMO1_NAND | |
| PISMO2_CS0 | |
| PISMO2_CS1 | |
| PISMO1_ONENAND | |
| PISMO2_NAND_CS0 | |
| PISMO2_NAND_CS1 | |
| PISMO1_NOR_BASE | |
| PISMO1_NAND_BASE| |
| PISMO2_CS0_BASE | |
+-----------------+-----------------------------------------------------------+
Signed-off-by: Pekon Gupta <[email protected]>
|
|
GPMC_NAND_ECC_LP_x16_LAYOUT
OMAP3 used GPMC_NAND_ECC_LP_x8_LAYOUT and GPMC_NAND_ECC_LP_x16_LAYOUT macros
to configure GPMC controller for x7 or x8 bit device connected to its interface.
Now this information is encoded in CONFIG_SYS_NAND_DEVICE_WIDTH macro, so above
macros can be completely removed.
Signed-off-by: Pekon Gupta <[email protected]>
|
|
GPMC controller on TI's OMAP SoC is general purpose controller to interface
with different types of external devices like;
- parallel NOR flash
- parallel NAND flash
- OneNand flash
- SDR RAM
- Ethernet Devices like LAN9220
Though GPMC configurations may be different for each platform depending on
clock-frequency and external device interfacing with controller. But
initialization sequence remains common across all platfoms.
Thus this patch merges gpmc_init() scattered in different arch-xx/mem.c
files into single omap-common/mem-common.c
However, actual platforms specific register config values are still sourced
from corresponding platform specific headers like;
AM33xx: arch/arm/include/asm/arch-am33xx/mem.h
OMAP3: arch/arm/include/asm/arch-omap3/mem.h
OMAP4: arch/arm/include/asm/arch-omap4/mem.h
OMAP4: arch/arm/include/asm/arch-omap5/mem.h
Also, CONFIG_xx passed by board-profile decide config for which set of macros
need to be used for initialization
CONFIG_NAND: initialize GPMC for NAND device
CONFIG_NOR: initialize GPMC for NOR device
CONFIG_ONENAND: initialize GPMC for ONENAND device
Signed-off-by: Pekon Gupta <[email protected]>
[trini: define GPMC_SIZE_256M for omap3]
Signed-off-by: Tom Rini <[email protected]>
|
|
Similar to OMAP5uEVM, PandaBoard, BeagleBoard-XM has a USB based
ethernet without MAC address embedded. So fake a MAC address following
the similar strategy used on OMAP5 and PandaBoard family.
Signed-off-by: Nishanth Menon <[email protected]>
|
|
introduce get_die_id() function which allows generation of
information such as fake MAC address from the processor ID code.
Signed-off-by: Nishanth Menon <[email protected]>
|
