2018-05-06 21:58:06 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0+
|
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>
|
2014-10-03 10:21:06 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <common.h>
|
2017-01-21 09:05:24 +00:00
|
|
|
#include <linux/errno.h>
|
2019-06-28 17:38:04 +00:00
|
|
|
#include <linux/io.h>
|
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>
|
2017-10-13 10:21:55 +00:00
|
|
|
#include <asm/global_data.h>
|
2015-09-11 11:17:49 +00:00
|
|
|
|
2019-07-10 11:07:45 +00:00
|
|
|
#include "init.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 "sg-regs.h"
|
2016-06-17 10:24:29 +00:00
|
|
|
#include "soc-info.h"
|
|
|
|
|
|
2015-09-11 11:17:49 +00:00
|
|
|
DECLARE_GLOBAL_DATA_PTR;
|
|
|
|
|
|
2017-02-05 01:52:12 +00:00
|
|
|
struct uniphier_dram_map {
|
|
|
|
|
unsigned long base;
|
|
|
|
|
unsigned long size;
|
|
|
|
|
};
|
|
|
|
|
|
2019-07-10 11:07:43 +00:00
|
|
|
static int uniphier_memconf_decode(struct uniphier_dram_map *dram_map,
|
|
|
|
|
unsigned long sparse_ch1_base, bool have_ch2)
|
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
|
|
|
unsigned long size;
|
|
|
|
|
u32 val;
|
2015-09-11 11:17:49 +00:00
|
|
|
|
2019-07-10 11:07:40 +00:00
|
|
|
val = readl(sg_base + SG_MEMCONF);
|
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 */
|
2019-07-10 11:07:46 +00:00
|
|
|
dram_map[0].base = 0x80000000;
|
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:
|
2017-02-20 03:09:00 +00:00
|
|
|
pr_err("error: invalid value is set to MEMCONF ch0 size\n");
|
2015-09-11 11:17:49 +00:00
|
|
|
return -EINVAL;
|
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;
|
|
|
|
|
|
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 */
|
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) {
|
2019-07-10 11:07:43 +00:00
|
|
|
if (dram_map[1].base > 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");
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-10 11:07:43 +00:00
|
|
|
dram_map[1].base = 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:
|
2017-02-20 03:09:00 +00:00
|
|
|
pr_err("error: invalid value is set to MEMCONF ch1 size\n");
|
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;
|
2016-03-29 11:18:45 +00:00
|
|
|
|
2017-02-05 01:52:12 +00:00
|
|
|
dram_map[1].size = size;
|
2015-09-11 11:17:49 +00:00
|
|
|
|
2019-07-10 11:07:43 +00:00
|
|
|
if (!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;
|
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 */
|
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:
|
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;
|
|
|
|
|
|
2017-02-05 01:52:12 +00:00
|
|
|
dram_map[2].size = size;
|
2014-10-03 10:21:06 +00:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2015-09-11 11:17:49 +00:00
|
|
|
|
2019-07-10 11:07:43 +00:00
|
|
|
static int uniphier_ld4_dram_map_get(struct uniphier_dram_map dram_map[])
|
|
|
|
|
{
|
|
|
|
|
return uniphier_memconf_decode(dram_map, 0xc0000000, false);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int uniphier_pro4_dram_map_get(struct uniphier_dram_map dram_map[])
|
|
|
|
|
{
|
|
|
|
|
return uniphier_memconf_decode(dram_map, 0xa0000000, false);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int uniphier_pxs2_dram_map_get(struct uniphier_dram_map dram_map[])
|
|
|
|
|
{
|
|
|
|
|
return uniphier_memconf_decode(dram_map, 0xc0000000, true);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct uniphier_dram_init_data {
|
|
|
|
|
unsigned int soc_id;
|
|
|
|
|
int (*dram_map_get)(struct uniphier_dram_map dram_map[]);
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const struct uniphier_dram_init_data uniphier_dram_init_data[] = {
|
|
|
|
|
{
|
|
|
|
|
.soc_id = UNIPHIER_LD4_ID,
|
|
|
|
|
.dram_map_get = uniphier_ld4_dram_map_get,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
.soc_id = UNIPHIER_PRO4_ID,
|
|
|
|
|
.dram_map_get = uniphier_pro4_dram_map_get,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
.soc_id = UNIPHIER_SLD8_ID,
|
|
|
|
|
.dram_map_get = uniphier_ld4_dram_map_get,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
.soc_id = UNIPHIER_PRO5_ID,
|
|
|
|
|
.dram_map_get = uniphier_ld4_dram_map_get,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
.soc_id = UNIPHIER_PXS2_ID,
|
|
|
|
|
.dram_map_get = uniphier_pxs2_dram_map_get,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
.soc_id = UNIPHIER_LD6B_ID,
|
|
|
|
|
.dram_map_get = uniphier_pxs2_dram_map_get,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
.soc_id = UNIPHIER_LD11_ID,
|
|
|
|
|
.dram_map_get = uniphier_ld4_dram_map_get,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
.soc_id = UNIPHIER_LD20_ID,
|
|
|
|
|
.dram_map_get = uniphier_pxs2_dram_map_get,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
.soc_id = UNIPHIER_PXS3_ID,
|
|
|
|
|
.dram_map_get = uniphier_pxs2_dram_map_get,
|
|
|
|
|
},
|
|
|
|
|
};
|
|
|
|
|
UNIPHIER_DEFINE_SOCDATA_FUNC(uniphier_get_dram_init_data,
|
|
|
|
|
uniphier_dram_init_data)
|
|
|
|
|
|
|
|
|
|
static int uniphier_dram_map_get(struct uniphier_dram_map *dram_map)
|
|
|
|
|
{
|
|
|
|
|
const struct uniphier_dram_init_data *data;
|
|
|
|
|
|
|
|
|
|
data = uniphier_get_dram_init_data();
|
|
|
|
|
if (!data) {
|
|
|
|
|
pr_err("unsupported SoC\n");
|
|
|
|
|
return -ENOTSUPP;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return data->dram_map_get(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
|
|
|
int dram_init(void)
|
2015-09-11 11:17:49 +00:00
|
|
|
{
|
2017-02-05 01:52:12 +00:00
|
|
|
struct uniphier_dram_map dram_map[3] = {};
|
2019-07-10 11:07:44 +00:00
|
|
|
bool valid_bank_found = false;
|
|
|
|
|
unsigned long prev_top;
|
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;
|
|
|
|
|
|
2019-07-10 11:07:43 +00:00
|
|
|
ret = uniphier_dram_map_get(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;
|
|
|
|
|
|
2017-02-05 01:52:12 +00:00
|
|
|
for (i = 0; i < ARRAY_SIZE(dram_map); i++) {
|
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
|
|
|
|
2017-02-05 01:52:12 +00:00
|
|
|
if (!dram_map[i].size)
|
2019-07-10 11:07:44 +00:00
|
|
|
continue;
|
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
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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.
|
|
|
|
|
*/
|
2019-07-10 11:07:44 +00:00
|
|
|
if (valid_bank_found && prev_top < 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;
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2017-02-05 01:52:12 +00:00
|
|
|
gd->ram_size += dram_map[i].size;
|
2019-07-10 11:07:44 +00:00
|
|
|
|
2019-07-10 11:07:46 +00:00
|
|
|
if (!valid_bank_found)
|
|
|
|
|
gd->ram_base = dram_map[i].base;
|
|
|
|
|
|
2019-07-10 11:07:44 +00:00
|
|
|
prev_top = dram_map[i].base + dram_map[i].size;
|
|
|
|
|
valid_bank_found = true;
|
2016-03-29 11:18:45 +00:00
|
|
|
}
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
{
|
2017-02-05 01:52:12 +00:00
|
|
|
struct uniphier_dram_map dram_map[3] = {};
|
2019-07-10 11:07:45 +00:00
|
|
|
unsigned long base, top;
|
|
|
|
|
bool valid_bank_found = false;
|
2019-07-10 11:07:43 +00:00
|
|
|
int ret, i;
|
2016-03-29 11:18:45 +00:00
|
|
|
|
2019-07-10 11:07:43 +00:00
|
|
|
ret = uniphier_dram_map_get(dram_map);
|
|
|
|
|
if (ret)
|
|
|
|
|
return ret;
|
2015-09-11 11:17:49 +00:00
|
|
|
|
2017-02-05 01:52:12 +00:00
|
|
|
for (i = 0; i < ARRAY_SIZE(dram_map); i++) {
|
2019-07-10 11:07:45 +00:00
|
|
|
if (i < ARRAY_SIZE(gd->bd->bi_dram)) {
|
|
|
|
|
gd->bd->bi_dram[i].start = dram_map[i].base;
|
|
|
|
|
gd->bd->bi_dram[i].size = dram_map[i].size;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!dram_map[i].size)
|
|
|
|
|
continue;
|
2015-09-11 11:17:49 +00:00
|
|
|
|
2019-07-10 11:07:45 +00:00
|
|
|
if (!valid_bank_found)
|
|
|
|
|
base = dram_map[i].base;
|
|
|
|
|
top = dram_map[i].base + dram_map[i].size;
|
|
|
|
|
valid_bank_found = true;
|
2015-09-11 11:17:49 +00:00
|
|
|
}
|
2017-03-31 14:40:32 +00:00
|
|
|
|
2019-07-10 11:07:45 +00:00
|
|
|
if (!valid_bank_found)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
/* map all the DRAM regions */
|
|
|
|
|
uniphier_mem_map_init(base, top - base);
|
|
|
|
|
|
2017-03-31 14:40:32 +00:00
|
|
|
return 0;
|
2015-09-11 11:17:49 +00:00
|
|
|
}
|
