Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-16 01:38:22 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/arch/arm/mach-uniphier/dram_init.c

301 lines
6 KiB
C
Raw Normal View History

ARM: UniPhier: add UniPhier SoC support code These are used by Panasonic UniPhier SoC family. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-10-03 10:21:06 +00:00
/*
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
* Copyright (C) 2012-2015 Panasonic Corporation
* Copyright (C) 2015-2017 Socionext Inc.
* Author: Masahiro Yamada <yamada.masahiro@socionext.com>
ARM: UniPhier: add UniPhier SoC support code These are used by Panasonic UniPhier SoC family. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-10-03 10:21:06 +00:00
*
* SPDX-License-Identifier: GPL-2.0+
*/
#include <common.h>
ARM: uniphier: fix various sparse warnings Fix warnings reported by sparse: - ... was not declared. Should it be static?" - cast to restricted __be32 While fixing those, the type conflict of cci500_init() was found. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-06-22 07:42:04 +00:00
#include <fdt_support.h>
ARM: uniphier: avoid unaligned access to DT on 64bit SoC Because DT properties are 4-byte aligned, the pointer access *(fdt64_t *) in this code causes unaligned access. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-04-21 05:43:12 +00:00
#include <fdtdec.h>
ARM: uniphier: replace <linux/err.h> with <linux/errno.h> These files only need error number macros. Actually, IS_ERR(), PTR_ERR(), ERR_PTR(), etc. are not useful for U-Boot. Avoid unnecessary header includes. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-21 09:05:24 +00:00
#include <linux/errno.h>
ARM: uniphier: use pr_() instead of printf() where appropriate Replace printf() with pr_() to specify proper loglevel. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-13 10:21:55 +00:00
#include <linux/kernel.h>
#include <linux/printk.h>
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
#include <linux/sizes.h>
ARM: uniphier: use pr_() instead of printf() where appropriate Replace printf() with pr_() to specify proper loglevel. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-13 10:21:55 +00:00
#include <asm/global_data.h>
ARM: uniphier: parse device tree to determine DRAM base and size Device tree specifies the available memory ranges in its "/memory" node. Use it to simplify the CONFIG defines. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-09-11 11:17:49 +00:00
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
#include "sg-regs.h"
ARM: uniphier: reserve memory for DRAM PHY training on PH1-LD20 The DRAM PHY layer on PH1-LD20 is able to calibrate PHY parameters periodically. This compensates for the voltage and temperature deviation and improves the PHY parameter adjustment. Instead, it requires 64 byte scratch memory in each DRAM channel for the dynamic training. The memory regions must be reserved in DT before jumping to the kernel. The scratch area can be anywhere in each DRAM channel, but the DRAM init code in SPL currently assigns it at the end of each channel. So, it makes sense to reserve the regions on run-time by U-Boot instead of statically embedding it in the DT in Linux. Anyway, a boot-loader should know much more about memory initialization than the kernel. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-06-17 10:24:29 +00:00
#include "soc-info.h"
ARM: uniphier: parse device tree to determine DRAM base and size Device tree specifies the available memory ranges in its "/memory" node. Use it to simplify the CONFIG defines. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-09-11 11:17:49 +00:00
DECLARE_GLOBAL_DATA_PTR;
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
struct uniphier_memif_data {
unsigned int soc_id;
unsigned long sparse_ch1_base;
int have_ch2;
};
static const struct uniphier_memif_data uniphier_memif_data[] = {
{
.soc_id = UNIPHIER_LD4_ID,
.sparse_ch1_base = 0xc0000000,
},
{
.soc_id = UNIPHIER_PRO4_ID,
.sparse_ch1_base = 0xa0000000,
},
{
.soc_id = UNIPHIER_SLD8_ID,
.sparse_ch1_base = 0xc0000000,
},
{
.soc_id = UNIPHIER_PRO5_ID,
.sparse_ch1_base = 0xc0000000,
},
{
.soc_id = UNIPHIER_PXS2_ID,
.sparse_ch1_base = 0xc0000000,
.have_ch2 = 1,
},
{
.soc_id = UNIPHIER_LD6B_ID,
.sparse_ch1_base = 0xc0000000,
.have_ch2 = 1,
},
{
.soc_id = UNIPHIER_LD11_ID,
.sparse_ch1_base = 0xc0000000,
},
{
.soc_id = UNIPHIER_LD20_ID,
.sparse_ch1_base = 0xc0000000,
.have_ch2 = 1,
},
{
.soc_id = UNIPHIER_PXS3_ID,
.sparse_ch1_base = 0xc0000000,
.have_ch2 = 1,
},
};
UNIPHIER_DEFINE_SOCDATA_FUNC(uniphier_get_memif_data, uniphier_memif_data)
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
struct uniphier_dram_map {
unsigned long base;
unsigned long size;
};
static int uniphier_memconf_decode(struct uniphier_dram_map *dram_map)
ARM: uniphier: parse device tree to determine DRAM base and size Device tree specifies the available memory ranges in its "/memory" node. Use it to simplify the CONFIG defines. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-09-11 11:17:49 +00:00
{
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
const struct uniphier_memif_data *data;
unsigned long size;
u32 val;
ARM: uniphier: parse device tree to determine DRAM base and size Device tree specifies the available memory ranges in its "/memory" node. Use it to simplify the CONFIG defines. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-09-11 11:17:49 +00:00
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
data = uniphier_get_memif_data();
if (!data) {
pr_err("unsupported SoC\n");
return -EINVAL;
}
ARM: uniphier: parse device tree to determine DRAM base and size Device tree specifies the available memory ranges in its "/memory" node. Use it to simplify the CONFIG defines. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-09-11 11:17:49 +00:00
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
val = readl(SG_MEMCONF);
ARM: UniPhier: add UniPhier SoC support code These are used by Panasonic UniPhier SoC family. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-10-03 10:21:06 +00:00
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
/* set up ch0 */
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
dram_map[0].base = CONFIG_SYS_SDRAM_BASE;
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
switch (val & SG_MEMCONF_CH0_SZ_MASK) {
case SG_MEMCONF_CH0_SZ_64M:
size = SZ_64M;
break;
case SG_MEMCONF_CH0_SZ_128M:
size = SZ_128M;
break;
case SG_MEMCONF_CH0_SZ_256M:
size = SZ_256M;
break;
case SG_MEMCONF_CH0_SZ_512M:
size = SZ_512M;
break;
case SG_MEMCONF_CH0_SZ_1G:
size = SZ_1G;
break;
default:
ARM: uniphier: correct spelling of "invalid" Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-20 03:09:00 +00:00
pr_err("error: invalid value is set to MEMCONF ch0 size\n");
ARM: uniphier: parse device tree to determine DRAM base and size Device tree specifies the available memory ranges in its "/memory" node. Use it to simplify the CONFIG defines. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-09-11 11:17:49 +00:00
return -EINVAL;
ARM: uniphier: adjust dram_init() and dram_init_banksize() for ARM64 Currently, these functions assume #address-cells and #size-cells are both one. Fix them to support 64bit DTB. Also, I am fixing a buffer overrun bug while I am here. The array size of gd->bd->bd_dram is CONFIG_NR_DRAM_BANKS. The number of iteration in the loop should be limited by that CONFIG. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-03-29 11:18:45 +00:00
}
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
if ((val & SG_MEMCONF_CH0_NUM_MASK) == SG_MEMCONF_CH0_NUM_2)
size *= 2;
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
dram_map[0].size = size;
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
/* set up ch1 */
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
dram_map[1].base = dram_map[0].base + size;
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
if (val & SG_MEMCONF_SPARSEMEM) {
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
if (dram_map[1].base > data->sparse_ch1_base) {
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
pr_warn("Sparse mem is enabled, but ch0 and ch1 overlap\n");
pr_warn("Only ch0 is available\n");
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
dram_map[1].base = 0;
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
return 0;
}
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
dram_map[1].base = data->sparse_ch1_base;
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
}
switch (val & SG_MEMCONF_CH1_SZ_MASK) {
case SG_MEMCONF_CH1_SZ_64M:
size = SZ_64M;
break;
case SG_MEMCONF_CH1_SZ_128M:
size = SZ_128M;
break;
case SG_MEMCONF_CH1_SZ_256M:
size = SZ_256M;
break;
case SG_MEMCONF_CH1_SZ_512M:
size = SZ_512M;
break;
case SG_MEMCONF_CH1_SZ_1G:
size = SZ_1G;
break;
default:
ARM: uniphier: correct spelling of "invalid" Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-20 03:09:00 +00:00
pr_err("error: invalid value is set to MEMCONF ch1 size\n");
ARM: uniphier: adjust dram_init() and dram_init_banksize() for ARM64 Currently, these functions assume #address-cells and #size-cells are both one. Fix them to support 64bit DTB. Also, I am fixing a buffer overrun bug while I am here. The array size of gd->bd->bd_dram is CONFIG_NR_DRAM_BANKS. The number of iteration in the loop should be limited by that CONFIG. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-03-29 11:18:45 +00:00
return -EINVAL;
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
}
if ((val & SG_MEMCONF_CH1_NUM_MASK) == SG_MEMCONF_CH1_NUM_2)
size *= 2;
ARM: uniphier: adjust dram_init() and dram_init_banksize() for ARM64 Currently, these functions assume #address-cells and #size-cells are both one. Fix them to support 64bit DTB. Also, I am fixing a buffer overrun bug while I am here. The array size of gd->bd->bd_dram is CONFIG_NR_DRAM_BANKS. The number of iteration in the loop should be limited by that CONFIG. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-03-29 11:18:45 +00:00
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
dram_map[1].size = size;
ARM: uniphier: parse device tree to determine DRAM base and size Device tree specifies the available memory ranges in its "/memory" node. Use it to simplify the CONFIG defines. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-09-11 11:17:49 +00:00
ARM: uniphier: skip MEMCONF ch2 parsing if CH2_DISABLE bit is set If SG_MEMCONF_CH2_DISABLE bit is set, the DRAM channel 2 is unused. The register settings for the ch2 should be ignored. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-20 03:10:05 +00:00
if (!data->have_ch2 || val & SG_MEMCONF_CH2_DISABLE)
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
return 0;
ARM: uniphier: parse device tree to determine DRAM base and size Device tree specifies the available memory ranges in its "/memory" node. Use it to simplify the CONFIG defines. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-09-11 11:17:49 +00:00
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
/* set up ch2 */
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
dram_map[2].base = dram_map[1].base + size;
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
switch (val & SG_MEMCONF_CH2_SZ_MASK) {
case SG_MEMCONF_CH2_SZ_64M:
size = SZ_64M;
break;
case SG_MEMCONF_CH2_SZ_128M:
size = SZ_128M;
break;
case SG_MEMCONF_CH2_SZ_256M:
size = SZ_256M;
break;
case SG_MEMCONF_CH2_SZ_512M:
size = SZ_512M;
break;
case SG_MEMCONF_CH2_SZ_1G:
size = SZ_1G;
break;
default:
ARM: uniphier: correct spelling of "invalid" Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-20 03:09:00 +00:00
pr_err("error: invalid value is set to MEMCONF ch2 size\n");
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
return -EINVAL;
}
if ((val & SG_MEMCONF_CH2_NUM_MASK) == SG_MEMCONF_CH2_NUM_2)
size *= 2;
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
dram_map[2].size = size;
ARM: UniPhier: add UniPhier SoC support code These are used by Panasonic UniPhier SoC family. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
2014-10-03 10:21:06 +00:00
return 0;
}
ARM: uniphier: parse device tree to determine DRAM base and size Device tree specifies the available memory ranges in its "/memory" node. Use it to simplify the CONFIG defines. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-09-11 11:17:49 +00:00
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
int dram_init(void)
ARM: uniphier: parse device tree to determine DRAM base and size Device tree specifies the available memory ranges in its "/memory" node. Use it to simplify the CONFIG defines. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-09-11 11:17:49 +00:00
{
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
struct uniphier_dram_map dram_map[3] = {};
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
int ret, i;
gd->ram_size = 0;
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
ret = uniphier_memconf_decode(dram_map);
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
if (ret)
return ret;
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
for (i = 0; i < ARRAY_SIZE(dram_map); i++) {
ARM: uniphier: do not use RAM that exceeds 32 bit address range LD20 / PXs3 boards are equipped with a large amount of memory beyond the 32 bit address range. U-Boot relocates itself to the end of the available RAM. This is a problem for DMA engines that only support 32 bit physical address, like the SDMA of SDHCI controllers. In fact, U-Boot does not need to run at the very end of RAM. It is rather troublesome for drivers with DMA engines because U-Boot does not have API like dma_set_mask(), so DMA silently fails, making the driver debugging difficult. Hide the memory region that exceeds the 32 bit address range. It can be done by simply carving out gd->ram_size. It would also possible to override get_effective_memsize() or to define CONFIG_MAX_MEM_MAPPED, but dram_init() is a good enough place to do this job. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-06 13:59:24 +00:00
unsigned long max_size;
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
if (!dram_map[i].size)
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
break;
/*
* U-Boot relocates itself to the tail of the memory region,
* but it does not expect sparse memory. We use the first
* contiguous chunk here.
*/
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
if (i > 0 && dram_map[i - 1].base + dram_map[i - 1].size <
dram_map[i].base)
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
break;
ARM: uniphier: do not use RAM that exceeds 32 bit address range LD20 / PXs3 boards are equipped with a large amount of memory beyond the 32 bit address range. U-Boot relocates itself to the end of the available RAM. This is a problem for DMA engines that only support 32 bit physical address, like the SDMA of SDHCI controllers. In fact, U-Boot does not need to run at the very end of RAM. It is rather troublesome for drivers with DMA engines because U-Boot does not have API like dma_set_mask(), so DMA silently fails, making the driver debugging difficult. Hide the memory region that exceeds the 32 bit address range. It can be done by simply carving out gd->ram_size. It would also possible to override get_effective_memsize() or to define CONFIG_MAX_MEM_MAPPED, but dram_init() is a good enough place to do this job. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-06 13:59:24 +00:00
/*
* Do not use memory that exceeds 32bit address range. U-Boot
* relocates itself to the end of the effectively available RAM.
* This could be a problem for DMA engines that do not support
* 64bit address (SDMA of SDHCI, UniPhier AV-ether, etc.)
*/
if (dram_map[i].base >= 1ULL << 32)
break;
max_size = (1ULL << 32) - dram_map[i].base;
if (dram_map[i].size > max_size) {
gd->ram_size += max_size;
break;
}
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
gd->ram_size += dram_map[i].size;
ARM: uniphier: adjust dram_init() and dram_init_banksize() for ARM64 Currently, these functions assume #address-cells and #size-cells are both one. Fix them to support 64bit DTB. Also, I am fixing a buffer overrun bug while I am here. The array size of gd->bd->bd_dram is CONFIG_NR_DRAM_BANKS. The number of iteration in the loop should be limited by that CONFIG. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-03-29 11:18:45 +00:00
}
ARM: uniphier: hide memory top by platform hook instead of CONFIG I do not see a good reason to do this by a CONFIG option that affects all SoCs. The ram_size can be adjusted by dram_init() at run-time. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-06 13:59:26 +00:00
/*
* LD20 uses the last 64 byte for each channel for dynamic
* DDR PHY training
*/
if (uniphier_get_soc_id() == UNIPHIER_LD20_ID)
gd->ram_size -= 64;
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
return 0;
}
board_f: Drop setup_dram_config() wrapper By making dram_init_banksize() return an error code we can drop the wrapper. Adjust this and clean up all implementations. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefan Roese <sr@denx.de>
2017-03-31 14:40:32 +00:00
int dram_init_banksize(void)
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
{
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
struct uniphier_dram_map dram_map[3] = {};
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
int i;
ARM: uniphier: adjust dram_init() and dram_init_banksize() for ARM64 Currently, these functions assume #address-cells and #size-cells are both one. Fix them to support 64bit DTB. Also, I am fixing a buffer overrun bug while I am here. The array size of gd->bd->bd_dram is CONFIG_NR_DRAM_BANKS. The number of iteration in the loop should be limited by that CONFIG. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-03-29 11:18:45 +00:00
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
uniphier_memconf_decode(dram_map);
ARM: uniphier: parse device tree to determine DRAM base and size Device tree specifies the available memory ranges in its "/memory" node. Use it to simplify the CONFIG defines. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-09-11 11:17:49 +00:00
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
for (i = 0; i < ARRAY_SIZE(dram_map); i++) {
ARM: uniphier: detect RAM size by decoding HW register instead of DT U-Boot needs to set up available memory area(s) in dram_init() and dram_init_banksize(). It is platform-dependent how to detect the memory banks. Currently, UniPhier adopts the memory banks _alleged_ by DT. This is based on the assumption that users bind a correct DT in their build process. Come to think of it, the DRAM controller has already been set up before U-Boot is entered (because U-Boot runs on DRAM). So, the DRAM controller setup register seems a more reliable source of any information about DRAM stuff. The DRAM banks are initialized by preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever), so this means the source of the reliability is shifted from Device Tree to such early-stage firmware. However, if the DRAM controller is wrongly configured, the system will crash. If your system is running, the DRAM setup register is very likely to provide the correct DRAM mapping. Decode the SG_MEMCONF register to get the available DRAM banks. The dram_init() and dram_init_banksize() need similar decoding. It would be nice if dram_init_banksize() could reuse the outcome of dram_init(), but global variables are unavailable at this stage because the .bss section is available only after the relocation. As a result, SG_MEMCONF must be checked twice, but a new helper uniphier_memconf_decode() will help to avoid code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:43 +00:00
if (i >= ARRAY_SIZE(gd->bd->bi_dram))
break;
ARM: uniphier: parse device tree to determine DRAM base and size Device tree specifies the available memory ranges in its "/memory" node. Use it to simplify the CONFIG defines. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-09-11 11:17:49 +00:00
ARM: uniphier: remove DRAM base address from board parameters The base address of each DRAM channel can be calculated from other parameters, so does not need hard-coding. What we need is the size of each DRAM channel and DRAM_SPARSE flag to decide the start address of DRAM channel 1. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-05 01:52:12 +00:00
gd->bd->bi_dram[i].start = dram_map[i].base;
gd->bd->bi_dram[i].size = dram_map[i].size;
ARM: uniphier: parse device tree to determine DRAM base and size Device tree specifies the available memory ranges in its "/memory" node. Use it to simplify the CONFIG defines. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-09-11 11:17:49 +00:00
}
board_f: Drop setup_dram_config() wrapper By making dram_init_banksize() return an error code we can drop the wrapper. Adjust this and clean up all implementations. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefan Roese <sr@denx.de>
2017-03-31 14:40:32 +00:00
return 0;
ARM: uniphier: parse device tree to determine DRAM base and size Device tree specifies the available memory ranges in its "/memory" node. Use it to simplify the CONFIG defines. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-09-11 11:17:49 +00:00
}
ARM: uniphier: reserve memory for DRAM PHY training on PH1-LD20 The DRAM PHY layer on PH1-LD20 is able to calibrate PHY parameters periodically. This compensates for the voltage and temperature deviation and improves the PHY parameter adjustment. Instead, it requires 64 byte scratch memory in each DRAM channel for the dynamic training. The memory regions must be reserved in DT before jumping to the kernel. The scratch area can be anywhere in each DRAM channel, but the DRAM init code in SPL currently assigns it at the end of each channel. So, it makes sense to reserve the regions on run-time by U-Boot instead of statically embedding it in the DT in Linux. Anyway, a boot-loader should know much more about memory initialization than the kernel. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-06-17 10:24:29 +00:00
#ifdef CONFIG_OF_BOARD_SETUP
/*
* The DRAM PHY requires 64 byte scratch area in each DRAM channel
* for its dynamic PHY training feature.
*/
int ft_board_setup(void *fdt, bd_t *bd)
{
unsigned long rsv_addr;
const unsigned long rsv_size = 64;
ARM: uniphier: use gd->bd->bi_dram for memory reserve on LD20 SoC For LD20 SoC, the last 64 byte of each DRAM bank is used for the dynamic training of DRAM PHY. The regions must be reserved in DT to prevent the kernel from using them. Now gd->bd->bi_dram reflects the actual memory banks. Just use it instead of getting access to the board parameters. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:44 +00:00
int i, ret;
ARM: uniphier: reserve memory for DRAM PHY training on PH1-LD20 The DRAM PHY layer on PH1-LD20 is able to calibrate PHY parameters periodically. This compensates for the voltage and temperature deviation and improves the PHY parameter adjustment. Instead, it requires 64 byte scratch memory in each DRAM channel for the dynamic training. The memory regions must be reserved in DT before jumping to the kernel. The scratch area can be anywhere in each DRAM channel, but the DRAM init code in SPL currently assigns it at the end of each channel. So, it makes sense to reserve the regions on run-time by U-Boot instead of statically embedding it in the DT in Linux. Anyway, a boot-loader should know much more about memory initialization than the kernel. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-06-17 10:24:29 +00:00
ARM: uniphier: simplify SoC ID get function Currently, uniphier_get_soc_type() converts the SoC ID (this is read from the revision register) to an enum symbol to use it for SoC identification. Come to think of it, there is no need for the conversion in the first place. Using the SoC ID from the register as-is a straightforward way. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-21 09:05:26 +00:00
if (uniphier_get_soc_id() != UNIPHIER_LD20_ID)
ARM: uniphier: reserve memory for DRAM PHY training on PH1-LD20 The DRAM PHY layer on PH1-LD20 is able to calibrate PHY parameters periodically. This compensates for the voltage and temperature deviation and improves the PHY parameter adjustment. Instead, it requires 64 byte scratch memory in each DRAM channel for the dynamic training. The memory regions must be reserved in DT before jumping to the kernel. The scratch area can be anywhere in each DRAM channel, but the DRAM init code in SPL currently assigns it at the end of each channel. So, it makes sense to reserve the regions on run-time by U-Boot instead of statically embedding it in the DT in Linux. Anyway, a boot-loader should know much more about memory initialization than the kernel. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-06-17 10:24:29 +00:00
return 0;
ARM: uniphier: use gd->bd->bi_dram for memory reserve on LD20 SoC For LD20 SoC, the last 64 byte of each DRAM bank is used for the dynamic training of DRAM PHY. The regions must be reserved in DT to prevent the kernel from using them. Now gd->bd->bi_dram reflects the actual memory banks. Just use it instead of getting access to the board parameters. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:44 +00:00
for (i = 0; i < ARRAY_SIZE(gd->bd->bi_dram); i++) {
ARM: uniphier: skip memreserve of unused DRAM bank of LD20 Now the "for" loop here iterates on the detected memory banks. It must skip unused DRAM banks. Fixes: c995f3a3c526 ("ARM: uniphier: use gd->bd->bi_dram for memory reserve on LD20 SoC") Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-02-20 08:13:32 +00:00
if (!gd->bd->bi_dram[i].size)
continue;
ARM: uniphier: use gd->bd->bi_dram for memory reserve on LD20 SoC For LD20 SoC, the last 64 byte of each DRAM bank is used for the dynamic training of DRAM PHY. The regions must be reserved in DT to prevent the kernel from using them. Now gd->bd->bi_dram reflects the actual memory banks. Just use it instead of getting access to the board parameters. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-01-27 21:53:44 +00:00
rsv_addr = gd->bd->bi_dram[i].start + gd->bd->bi_dram[i].size;
ARM: uniphier: reserve memory for DRAM PHY training on PH1-LD20 The DRAM PHY layer on PH1-LD20 is able to calibrate PHY parameters periodically. This compensates for the voltage and temperature deviation and improves the PHY parameter adjustment. Instead, it requires 64 byte scratch memory in each DRAM channel for the dynamic training. The memory regions must be reserved in DT before jumping to the kernel. The scratch area can be anywhere in each DRAM channel, but the DRAM init code in SPL currently assigns it at the end of each channel. So, it makes sense to reserve the regions on run-time by U-Boot instead of statically embedding it in the DT in Linux. Anyway, a boot-loader should know much more about memory initialization than the kernel. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-06-17 10:24:29 +00:00
rsv_addr -= rsv_size;
ret = fdt_add_mem_rsv(fdt, rsv_addr, rsv_size);
if (ret)
return -ENOSPC;
ARM: uniphier: use pr_() instead of printf() where appropriate Replace printf() with pr_() to specify proper loglevel. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-13 10:21:55 +00:00
pr_notice(" Reserved memory region for DRAM PHY training: addr=%lx size=%lx\n",
rsv_addr, rsv_size);
ARM: uniphier: reserve memory for DRAM PHY training on PH1-LD20 The DRAM PHY layer on PH1-LD20 is able to calibrate PHY parameters periodically. This compensates for the voltage and temperature deviation and improves the PHY parameter adjustment. Instead, it requires 64 byte scratch memory in each DRAM channel for the dynamic training. The memory regions must be reserved in DT before jumping to the kernel. The scratch area can be anywhere in each DRAM channel, but the DRAM init code in SPL currently assigns it at the end of each channel. So, it makes sense to reserve the regions on run-time by U-Boot instead of statically embedding it in the DT in Linux. Anyway, a boot-loader should know much more about memory initialization than the kernel. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-06-17 10:24:29 +00:00
}
return 0;
}
#endif
Reference in a new issue Copy permalink