- 21 Sep, 2018 1 commit
-
-
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-EVMSigned-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
-
- 21 Jul, 2018 7 commits
-
-
Josua Mayer authored
Because nandargs is run earlier, if bootargs.scr doesn't overwrite the bootargs, root and rootfstype will be polluted with nand values. Signed-off-by:
Josua Mayer <josua.mayer97@gmail.com>
-
Josua Mayer authored
Most modern distros want to boot with an initramfs, so setting a default load address for it seems reasonable. Signed-off-by:
Josua Mayer <josua.mayer97@gmail.com>
-
Josua Mayer authored
U-Boot Distro-Boot has defined standard names for load addresses across all devices. Mass-replace all occurences of the old names. Signed-off-by:
Josua Mayer <josua.mayer97@gmail.com>
-
Josua Mayer authored
distro-boot would set a few variables explaining what device was selected to boot from. This is a bare minimum, just enough to boot Debian. devtype: boot device, e.g. mmc devnum: number of boot device, e.g. 0,1,2,... distro_bootpart: selected partition number prefix: base path where bootable files were found Signed-off-by:
Josua Mayer <josua.mayer97@gmail.com>
-
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>
-
H. Nikolaus Schaller authored
Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com>
-
- 01 Jul, 2018 3 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>
-
H. Nikolaus Schaller authored
Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com>
-
- 27 Jun, 2018 1 commit
-
-
H. Nikolaus Schaller authored
Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com>
-
- 29 May, 2018 2 commits
-
-
Tony Lindgren authored
With u-boot related memory errors out of the way fixed with patch "LC15: Fix flakey ddr3 detection with ref_ctrl and ref_ctrl_final", we can now narrow down the kernel related errors easily. Playing with timing changes I narrowed down the kernel hangs to register sdram_tim3 where we need to increase the time for T_RFC. This is for "Minimum number of DDR clock cycles from Refresh or Load Mode to Refresh or Activate, minus one" according to omap5432 TRM. Maxing out the value for bits 12:4 made the new 4GB pyra's C02 and C03 boot reliably. And then looking at the timings again, the T_RFC value should be 187 - 1 (0xBA) and not 139 - 1 (0x8A). Note the Upper case B vs 8 :) Value 187 - 1 (0xBA) matches Samsung K4B8G1646D-MYK0 datasheet "[ Table 34 ] Timing used for IDD and IDDQ Measured - Loop Patterns" for DDR3-1066 8Gb memory. We are currently using 4Gb value 139 - 1 (0x8A). It is possible that this was caused by B vs 8 typo initially and then was not noticed because of the u-boot memory errors and getting confused with the memory datasheet for 4Gb vs 4GB while we have four 8Gb memory chips. However I also noticed that value 187 - 1 (0xBA) still won't work reliably with new board C05. And new C21 and my older revision board C50 still did not work at all. However, using value of 191 - 1 (0xBE) makes all of them boot reliably for me. So let's use value 191 - 1 (0xBE) for now, and adjust it if needed based on testing with more pyras. Note that we still can have pyra hang running two instances of memtester 1500M for about 10 minutes on bare CPU boards with no heat sink connected. The boards now boot reliably after that though, so presumably the pyra heat sink will solve this issue. Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
Tony Lindgren authored
Since commit 802bb57a ("ARM: DRA7: EMIF: Update SDRAM_REF_CTRL register value") we now do this in two phases. We are not currently configuring ref_ctrl and this seems to cause bogus memory errors early in u-boot that often happen if the board has been powered off for a while: SDRAM: identified size not same as expected size identified: 0 expected: 40000000 ... WARNING: DDR RAM is not working! (12000000) ... ### ERROR ### Please RESET the board ### Note that this does not solve the kernel related memory issues, but gets us to the point where u-boot starts reliably. Signed-off-by:
Tony Lindgren <tony@atomide.com>
-
- 28 May, 2018 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>
-
- 22 Feb, 2018 1 commit
-
-
H. Nikolaus Schaller authored
bootscr: beagleboneblack: switch mmc and kernelmmc definitions by experimentational result - deeper reason is not understood; this makes boot from µSD work again Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com>
-
- 21 Feb, 2018 2 commits
-
-
H. Nikolaus Schaller authored
kernel assumes to include "gta04" Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com>
-
H. Nikolaus Schaller authored
we have to do the same as for gta04, override the beaglerev variable or the findfdt command would overwrite the fdtfile variable by its own rules. Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com>
-
- 11 Jan, 2018 1 commit
-
-
Andreas Kemnade authored
To be able to use upstream pusb (which is now fixed) and not our fork, use the product id option to pusb. Currently it is set to the dm3730 one. Signed-off-by:
Andreas Kemnade <andreas@kemnade.info>
-
- 22 Dec, 2017 1 commit
-
-
Andreas Kemnade authored
since charge auto is now fixed, lets start it also in uboot when booted via spl-dfu Signed-off-by:
Andreas Kemnade <andreas@kemnade.info>
-
- 19 Dec, 2017 13 commits
-
-
Andreas Kemnade authored
For onenand, the MLO has to be written to the first half parts of the 4k sectors, so there has to be some padding in for them. There is a tool to add the padding, but it can also be done directly in here Signed-off-by:
Andreas Kemnade <andreas@kemnade.info>
-
Andreas Kemnade authored
Signed-off-by:
Andreas Kemnade <andreas@kemnade.info>
-
Andreas Kemnade authored
Signed-off-by:
Andreas Kemnade <andreas@kemnade.info>
-
Andreas Kemnade authored
Signed-off-by:
Andreas Kemnade <andreas@kemnade.info>
-
Andreas Kemnade authored
Signed-off-by:
Andreas Kemnade <andreas@kemnade.info>
-
Andreas Kemnade authored
Signed-off-by:
Andreas Kemnade <andreas@kemnade.info>
-
Andreas Kemnade authored
redefine environment for that case because environment cannot come from nand/mmc in that case. add variables required by dfu set CONFIG_SPL_TEXT_BASE accordingly Signed-off-by:
Andreas Kemnade <andreas@kemnade.info>
-
Andreas Kemnade authored
to be able to process fit images and ordinary images and images with different loading address, the image has to be copied, since the dfu layer loads the full image at once, so it will be misplaced. it expects CONFIG_SPL_LOAD_FIT_ADDRESS to set to a good temporary space for every image. Signed-off-by:
Andreas Kemnade <andreas@kemnade.info>
-
Andreas Kemnade authored
musb needs to be initialized before dfu can be called, Since misc_init is not called in spl mode, add a special initialization function for that task. Define also a default weak implementation Signed-off-by:
Andreas Kemnade <andreas@kemnade.info>
-
Andreas Kemnade authored
in make menuconfig you explicitly select ram target for spl dfu, c so do not use CONFIG_DFU_* in spl builds. There are separate defines for dfu in spl in Kconfig, so lets use them consequently, also main uboot might have more dfu options than spl. Use CONFIG_SPL_DFU_RAM for spl related dfu. Signed-off-by:
Andreas Kemnade <andreas@kemnade.info>
-
Andreas Kemnade authored
there was no error checking in the call to spl_dfu_cmd. Signed-off-by:
Andreas Kemnade <andreas@kemnade.info>
-
Andreas Kemnade authored
f_dfu was missing for CONFIG_SPL_DFU_SUPPORT Signed-off-by:
Andreas Kemnade <andreas@kemnade.info>
-
Andreas Kemnade authored
Signed-off-by:
Andreas Kemnade <andreas@kemnade.info>
-