- 01 Sep, 2020 5 commits
-
-
Nick Elsmore authored
-
Nick Elsmore authored
-
Nick Elsmore authored
-
Nick Elsmore authored
-
Nick Elsmore authored
-
- 25 Aug, 2020 2 commits
-
-
Nick Elsmore authored
-
Nick Elsmore authored
The OMAP5 runs rather slowly in the SPL. Only reset bq2429x and set input current limit in SPL. Do the rest in full uboot.
-
- 21 Aug, 2020 2 commits
-
-
Nick Elsmore authored
-
Nick Elsmore authored
-
- 25 Jul, 2020 1 commit
-
-
David Shah authored
Signed-off-by:
David Shah <dave@ds0.me>
-
- 23 Jan, 2020 2 commits
-
-
Nick Elsmore authored
-
Nick Elsmore authored
-
- 16 Nov, 2019 3 commits
-
-
Nick Elsmore authored
-
Nick Elsmore authored
-
Nick Elsmore authored
-
- 09 Nov, 2019 2 commits
-
-
Nick Elsmore authored
-
Nick Elsmore authored
-
- 29 Sep, 2019 1 commit
-
-
Nick Elsmore authored
-
- 26 Sep, 2019 5 commits
-
-
notaz: split from Matthijs' "XXX more emif debugging"
-
You can get really weird errors with that
-
-
Nick Elsmore authored
-
-
- 23 Sep, 2019 1 commit
-
-
Nick Elsmore authored
-
- 21 Sep, 2019 2 commits
-
-
Nick Elsmore authored
-
Nick Elsmore authored
-
- 16 Feb, 2019 2 commits
-
-
H. Nikolaus Schaller authored
Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com>
-
H. Nikolaus Schaller authored
Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com>
-
- 17 Jan, 2019 1 commit
-
-
H. Nikolaus Schaller authored
LC15: adjust to new version encoding scheme which uses gpio2_33 for RAM size and will use gpio2_32 and gpio2_34 for board hardware revision in the future Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com>
-
- 10 Oct, 2018 2 commits
-
-
H. Nikolaus Schaller authored
.emif_ddr_phy_ctlr_1_init is 0x0024400B in the EMIF Tool, but we are using 0x0030400A. And emif_ddr_phy_ctlr_1_init needs to be configured in addition to emif_ddr_phy_ctlr_1 with PHY_INVERT_CLKOUT cleared for emif_ddr_phy_ctlr_1_init. So this would translate to values: .emif_ddr_phy_ctlr_1_init = 0x0020400B, .emif_ddr_phy_ctlr_1 = 0x0024400B, They too work just the same and could be used. Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com>
-
H. Nikolaus Schaller authored
Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com>
-
- 06 Oct, 2018 1 commit
-
-
Tony Lindgren authored
Well for the idle freezing issue, curiously the old "disable internal dll" trick seems to work. At least for me the system keeps running just fine idling for several hours. Also, looks like we have SDRAM_CONFIG ROWSIZE bits [9:7] set to 15 while it should be 16 for 8Gb memory. But I think that is just cosmetic, not sure if that is actually used. Anyways, care to test with the following hack with internal dll disabled and ROWSIZE fixed? If that works for the idle system problem, then we probably have some DLL timing related value misconfigured. Regards, Tony
-
- 21 Sep, 2018 2 commits
-
-
H. Nikolaus Schaller authored
Revert "Pyra: debug print tca6424 registers before and after initialization (can be reverted later)" This reverts commit ddd73df8. tca6424 initialization seems to be sane. So we can remove debug printf.
-
H. Nikolaus Schaller authored
lc15: detect total ram_size and define "kernelsuffix" to ".lpae" so that a boot script could load either uImage or uImage.lpae depending on RAM size Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com>
-
- 08 Aug, 2018 2 commits
-
-
Keerthy authored
The array indices used currently are dispalaced by 1 for SMPS6 through SMPS10 in the respective places of voltage and ctrl arrays hence fix the same as to assign the right voltage and ctrl registers. Signed-off-by:
Keerthy <j-keerthy@ti.com>
-
H. Nikolaus Schaller authored
Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com>
-
- 22 Jul, 2018 4 commits
-
-
Nishanth Menon authored
OMAP5432 did go into production with AVS class0 registers which were mutually exclusive from AVS Class 1.5 registers. Most OMAP5-uEVM boards use the pre-production Class1.5 which has production efuse registers set to 0. However on production devices, these are set to valid data. scale_vcore logic is already smart enough to detect this and use the "Nominal voltage" on devices that do not have efuse registers populated. On a test production device populated as follows: MPU OPP_NOM: => md.l 0x04A0021C4 1 4a0021c4: 03a003e9 .... (0x3e9 = 1.01v) vs nom voltage of 1.06v MPU OPP_HIGH: => md.l 0x04A0021C8 1 4a0021c8: 03400485 ..@. MM OPP_NOM: => md.l 0x04A0021A4 1 4a0021a4: 038003d4 .... (0x3d4 = 980mV) vs nom voltage of 1.025v MM OPP_OD: => md.l 0x04A0021A8 1 4a0021a8: 03600403 ..`. CORE OPP_NOM: => md.l 0x04A0021D8 1 4a0021d8: 000003cf .... (0x3cf = 975mV) vs nom voltage of 1.040v Since the efuse values are'nt currently used, we do not regress on existing pre-production samples (they continue to use nominal voltage). But on boards that do have production samples populated, we can leverage the optimal voltages necessary for proper operation. Tested on: a) 720-2644-001 OMAP5UEVM with production sample. b) 750-2628-222(A) UEVM5432G-02 with pre-production sample. Data based on OMAP5432 Technical reference Manual SWPU282AF (May 2012-Revised Aug 2016) NOTE: All collaterals on OMAP5432 silicon itself seems to have been removed from ti.com, though EVM details are still available: http://www.ti.com/tool/OMAP5432-EVM Signed-off-by:
Nishanth Menon <nm@ti.com>
-
Nishanth Menon authored
ES2.0 descopes OPP_LOW definition. So remove it from macros defined. Signed-off-by:
Nishanth Menon <nm@ti.com> Reviewed-by:
Lokesh Vutla <lokeshvutla@ti.com>
-
Matthijs van Duin authored
Some initialization was unintentionally being skipped on omap5. Fixes: f5af0827 ("arm: omap-common: Guard some parts of the code with CONFIG_OMAP44XX/OMAP54XX") Signed-off-by:
Matthijs van Duin <matthijsvanduin@gmail.com> Reviewed-by:
Tom Rini <trini@konsulko.com>
-
H. Nikolaus Schaller authored
-