On 07/29/2014 02:30 AM, Mikko Perttunen wrote:
Looks like the TRM doesn't document this either. I'll add an option
("nvidia,short-ram-code" ?) for the next version.
Using the 2-bit RAM code field as the RAM code is normal operation, so I
wouldn't call this "short".
Using the 2-bit boot device code field as extra RAM code bits is
non-standard.
I would suggest nvidia,use-4-bit-ram-code or
nvidia,use-boot-device-code-as-ram-code-msbs(!) as the property.
I see that the TRM implies the whole 4-bit field is RAM code, rather
than there being 2 separate 2-bit fields for RAM code and boot device
code. Can you please file a bug against the TRM to document this
correctly? (The details of which bits are which are visible on the
Jetson TK1 schematics for example).
On 22/07/14 20:34, Stephen Warren wrote:
On 07/22/2014 11:22 AM, Andrew Bresticker wrote:
On Tue, Jul 22, 2014 at 9:45 AM, Stephen Warren
<swarren@xxxxxxxxxxxxx> wrote:
Does the bootloader adjust the DT that's passed to the kernel so that
only the relevant single set of EMC timings is contained in the DT?
No, the DT contains all possible EMC timings for that board.
On a system where the boot ROM initializes RAM, and where the HW design
might have multiple SDRAM configuration, here's what usually happens:
a) The BCT contains N sets of SDRAM configurations.
b) The boot ROM reads the SDRAM strapping bits, and uses them to pick
the correct SDRAM configuration from the N sets in the BCT.
c) The kernel DT has N sets of SDRAM configurations.
d) The kernel reads the SDRAM strapping bits, and uses them to pick the
correct SDRAM configuration from the N sets in the DT.
On the ChromeOS boards (so (a) and (b) above are irrelevant) where N is
too large to fit into APBDEV_PMC_STRAPPING_OPT_A_0[7:4], (c) and (d)
won't work. I assume the kernel DT therefore must be adjusted to only
contain the single SDRAM configuration that is relevant for the
current HW?
(isn't STRAPPING_OPT_A split into 2 2-bit fields; 2 bits for SDRAM
index
and 2 bits for boot flash index, so max N is quite small?)
Right, there are normally only 2 SDRAM strapping bits available.
ChromeOS gets around this by having 4 identical boot device entries in
the BCT, so all possible values of STRAPPING_OPT_A[7:6] map to the
same boot device. This allows us to use all 4 strapping bits in
coreboot to pick the SDRAM configuration.
OK, that explains how it works.
But that means that when the kernel reads the strapping options, it will
have to know if it uses just 2 bits (standard) or all 4 bits
(non-standard) to index into the DT's array of SDRAM configurations.
We'll need a DT property to represent that.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
