ARM: tegra: pick up actual memory size
On Tegra186, U-Boot is booted by the binary firmware as if it were a
Linux kernel. Consequently, a DTB is passed to U-Boot. Cache the address
of that DTB, and parse the /memory/reg property to determine the actual
RAM regions that U-Boot and subsequent EL2/EL1 SW may actually use.
Given the binary FW passes a DTB to U-Boot, I anticipate the suggestion
that U-Boot use that DTB as its control DTB. I don't believe that would
work well, so I do not plan to put any effort into this. By default the
FW-supplied DTB is the L4T kernel's DTB, which uses non-upstreamed DT
bindings. U-Boot aims to use only upstreamed DT bindings, or as close as
it can get. Replacing this DTB with a DTB using upstream bindings is
physically quite easy; simply replace the content of one of the GPT
partitions on the eMMC. However, the binary FW at least partially relies
on the existence/content of some nodes in the DTB, and that requires the
DTB to be written according to downstream bindings. Equally, if U-Boot
continues to use appended DTBs built from its own source tree, as it does
for all other Tegra platforms, development and deployment is much easier.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2016-07-18 23:01:51 +00:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2016, NVIDIA CORPORATION.
|
|
|
|
*
|
|
|
|
* SPDX-License-Identifier: GPL-2.0+
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <common.h>
|
|
|
|
#include <fdt_support.h>
|
|
|
|
#include <fdtdec.h>
|
|
|
|
#include <asm/arch/tegra.h>
|
|
|
|
|
|
|
|
DECLARE_GLOBAL_DATA_PTR;
|
|
|
|
|
|
|
|
extern unsigned long nvtboot_boot_x0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* A parsed version of /memory/reg from the DTB that is passed to U-Boot in x0.
|
|
|
|
*
|
|
|
|
* We only support up to two banks since that's all the binary bootloader
|
|
|
|
* ever sets. We assume bank 0 is RAM below 4G and bank 1 is RAM above 4G.
|
|
|
|
* This is all a fairly safe assumption, since the L4T kernel makes the same
|
|
|
|
* assumptions, so the bootloader is unlikely to change.
|
|
|
|
*
|
|
|
|
* This is written to before relocation, and hence cannot be in .bss, since
|
|
|
|
* .bss overlaps the DTB that's appended to the U-Boot binary. The initializer
|
|
|
|
* forces this into .data and avoids this issue. This also has the nice side-
|
|
|
|
* effect of the content being valid after relocation.
|
|
|
|
*/
|
|
|
|
static struct {
|
|
|
|
u64 start;
|
|
|
|
u64 size;
|
|
|
|
} ram_banks[2] = {{1}};
|
|
|
|
|
|
|
|
int dram_init(void)
|
|
|
|
{
|
|
|
|
unsigned int na, ns;
|
|
|
|
const void *nvtboot_blob = (void *)nvtboot_boot_x0;
|
|
|
|
int node, len, i;
|
|
|
|
const u32 *prop;
|
|
|
|
|
|
|
|
memset(ram_banks, 0, sizeof(ram_banks));
|
|
|
|
|
|
|
|
na = fdtdec_get_uint(nvtboot_blob, 0, "#address-cells", 2);
|
|
|
|
ns = fdtdec_get_uint(nvtboot_blob, 0, "#size-cells", 2);
|
|
|
|
|
|
|
|
node = fdt_path_offset(nvtboot_blob, "/memory");
|
|
|
|
if (node < 0) {
|
|
|
|
error("Can't find /memory node in nvtboot DTB");
|
|
|
|
hang();
|
|
|
|
}
|
|
|
|
prop = fdt_getprop(nvtboot_blob, node, "reg", &len);
|
|
|
|
if (!prop) {
|
|
|
|
error("Can't find /memory/reg property in nvtboot DTB");
|
|
|
|
hang();
|
|
|
|
}
|
|
|
|
|
|
|
|
len /= (na + ns);
|
|
|
|
if (len > ARRAY_SIZE(ram_banks))
|
|
|
|
len = ARRAY_SIZE(ram_banks);
|
|
|
|
|
|
|
|
gd->ram_size = 0;
|
|
|
|
for (i = 0; i < len; i++) {
|
2017-05-19 02:09:26 +00:00
|
|
|
ram_banks[i].start = fdt_read_number(prop, na);
|
ARM: tegra: pick up actual memory size
On Tegra186, U-Boot is booted by the binary firmware as if it were a
Linux kernel. Consequently, a DTB is passed to U-Boot. Cache the address
of that DTB, and parse the /memory/reg property to determine the actual
RAM regions that U-Boot and subsequent EL2/EL1 SW may actually use.
Given the binary FW passes a DTB to U-Boot, I anticipate the suggestion
that U-Boot use that DTB as its control DTB. I don't believe that would
work well, so I do not plan to put any effort into this. By default the
FW-supplied DTB is the L4T kernel's DTB, which uses non-upstreamed DT
bindings. U-Boot aims to use only upstreamed DT bindings, or as close as
it can get. Replacing this DTB with a DTB using upstream bindings is
physically quite easy; simply replace the content of one of the GPT
partitions on the eMMC. However, the binary FW at least partially relies
on the existence/content of some nodes in the DTB, and that requires the
DTB to be written according to downstream bindings. Equally, if U-Boot
continues to use appended DTBs built from its own source tree, as it does
for all other Tegra platforms, development and deployment is much easier.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2016-07-18 23:01:51 +00:00
|
|
|
prop += na;
|
2017-05-19 02:09:26 +00:00
|
|
|
ram_banks[i].size = fdt_read_number(prop, ns);
|
ARM: tegra: pick up actual memory size
On Tegra186, U-Boot is booted by the binary firmware as if it were a
Linux kernel. Consequently, a DTB is passed to U-Boot. Cache the address
of that DTB, and parse the /memory/reg property to determine the actual
RAM regions that U-Boot and subsequent EL2/EL1 SW may actually use.
Given the binary FW passes a DTB to U-Boot, I anticipate the suggestion
that U-Boot use that DTB as its control DTB. I don't believe that would
work well, so I do not plan to put any effort into this. By default the
FW-supplied DTB is the L4T kernel's DTB, which uses non-upstreamed DT
bindings. U-Boot aims to use only upstreamed DT bindings, or as close as
it can get. Replacing this DTB with a DTB using upstream bindings is
physically quite easy; simply replace the content of one of the GPT
partitions on the eMMC. However, the binary FW at least partially relies
on the existence/content of some nodes in the DTB, and that requires the
DTB to be written according to downstream bindings. Equally, if U-Boot
continues to use appended DTBs built from its own source tree, as it does
for all other Tegra platforms, development and deployment is much easier.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2016-07-18 23:01:51 +00:00
|
|
|
prop += ns;
|
|
|
|
gd->ram_size += ram_banks[i].size;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
extern unsigned long nvtboot_boot_x0;
|
|
|
|
|
2017-03-31 14:40:32 +00:00
|
|
|
int dram_init_banksize(void)
|
ARM: tegra: pick up actual memory size
On Tegra186, U-Boot is booted by the binary firmware as if it were a
Linux kernel. Consequently, a DTB is passed to U-Boot. Cache the address
of that DTB, and parse the /memory/reg property to determine the actual
RAM regions that U-Boot and subsequent EL2/EL1 SW may actually use.
Given the binary FW passes a DTB to U-Boot, I anticipate the suggestion
that U-Boot use that DTB as its control DTB. I don't believe that would
work well, so I do not plan to put any effort into this. By default the
FW-supplied DTB is the L4T kernel's DTB, which uses non-upstreamed DT
bindings. U-Boot aims to use only upstreamed DT bindings, or as close as
it can get. Replacing this DTB with a DTB using upstream bindings is
physically quite easy; simply replace the content of one of the GPT
partitions on the eMMC. However, the binary FW at least partially relies
on the existence/content of some nodes in the DTB, and that requires the
DTB to be written according to downstream bindings. Equally, if U-Boot
continues to use appended DTBs built from its own source tree, as it does
for all other Tegra platforms, development and deployment is much easier.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2016-07-18 23:01:51 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < 2; i++) {
|
|
|
|
gd->bd->bi_dram[i].start = ram_banks[i].start;
|
|
|
|
gd->bd->bi_dram[i].size = ram_banks[i].size;
|
|
|
|
}
|
2017-03-31 14:40:32 +00:00
|
|
|
|
|
|
|
return 0;
|
ARM: tegra: pick up actual memory size
On Tegra186, U-Boot is booted by the binary firmware as if it were a
Linux kernel. Consequently, a DTB is passed to U-Boot. Cache the address
of that DTB, and parse the /memory/reg property to determine the actual
RAM regions that U-Boot and subsequent EL2/EL1 SW may actually use.
Given the binary FW passes a DTB to U-Boot, I anticipate the suggestion
that U-Boot use that DTB as its control DTB. I don't believe that would
work well, so I do not plan to put any effort into this. By default the
FW-supplied DTB is the L4T kernel's DTB, which uses non-upstreamed DT
bindings. U-Boot aims to use only upstreamed DT bindings, or as close as
it can get. Replacing this DTB with a DTB using upstream bindings is
physically quite easy; simply replace the content of one of the GPT
partitions on the eMMC. However, the binary FW at least partially relies
on the existence/content of some nodes in the DTB, and that requires the
DTB to be written according to downstream bindings. Equally, if U-Boot
continues to use appended DTBs built from its own source tree, as it does
for all other Tegra platforms, development and deployment is much easier.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2016-07-18 23:01:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
ulong board_get_usable_ram_top(ulong total_size)
|
|
|
|
{
|
|
|
|
return ram_banks[0].start + ram_banks[0].size;
|
|
|
|
}
|