On Mon, Apr 10, 2023 at 10:17:56AM +0100, Diogo Ivo wrote:
> On Wed, Apr 05, 2023 at 03:18:23PM +0200, Thierry Reding wrote:
> > On Sun, Mar 19, 2023 at 07:42:55PM +0000, Diogo Ivo wrote:
> > > Add the reserved-memory regions of the nominal and derated tables setup by
> > > the bootloader so that the EMC frequency change code can access them.
> > >
> > > Signed-off-by: Diogo Ivo <diogo.ivo@xxxxxxxxxxxxxxxxxx>
> > > ---
> > > arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 21 +++++++++++++++++++
> > > 1 file changed, 21 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
> > > index 709f3f417a19..a74826ae97b4 100644
> > > --- a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
> > > +++ b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
> > > @@ -30,6 +30,22 @@ memory {
> > > reg = <0x0 0x80000000 0x0 0xc0000000>;
> > > };
> > >
> > > + reserved-memory {
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + ranges;
> > > +
> > > + nominal: emc-table@f67cc000 {
> > > + compatible = "nvidia,tegra210-emc-table";
> > > + reg = <0x0 0xf67cc000 0x0 0xbea0>;
> > > + };
> > > +
> > > + derated: emc-table@f67d7ea0 {
> > > + compatible = "nvidia,tegra210-emc-table";
> > > + reg = <0x0 0xf67d7ea0 0x0 0xbea0>;
> > > + };
> > > + };
> > > +
> >
> > These tables are typically generated by the firmware/bootloader at
> > runtime. Often they'll use heap allocations for these, so the addresses
> > are not guaranteed to be static.
> >
> > Can you share a few details about what set of components you've used to
> > set this up? If we add these we want to be as specific as possible that
> > people use exactly the same set of firmware files.
> >
> > Thierry
>
> In the case of the Pixel C, coreboot takes care of copying these tables
> into a static cbmem region. The actual function taking care of this is
> tegra210_run_mtc(), found in [1], and from here it is possible to
> construct the cbmem memory layout. I have confirmed that the device is
> actually running this version of coreboot from the cbmem_console logs,
> where the commits are explicitly stated. These logs also indicate where
> the tables are located,
>
> Wrote coreboot table at: 00000000f66ca000, 0x2c0 bytes, checksum 3601
> coreboot table: 728 bytes.
> CBMEM ROOT 0. f67ff000 00001000
> CONSOLE 1. f67ef000 00010000
> TIME STAMP 2. f67ee000 00001000
> VBOOT 3. f67ed000 00001000
> VPD 4. f67e4000 00009000
> MTC 5. f67cc000 00018000
> RAMOOPS 6. f66cc000 00100000
> COREBOOT 7. f66ca000 00002000
>
> and
>
> MTC: Copied 0x17d40 bytes from 0000000081008b70 to 00000000f67cc000
Okay, so this sounds good. My only worry is what could happen if
somebody were to run a slightly different version of coreboot that puts
these tables elsewhere. It's been a long time since I looked at
coreboot, but do you think perhaps it would be possible to update
coreboot to update the DTB at runtime to always point at the correct
location?
Alternatively, do we have an easy way of checking that the tables are
valid? Looking at the data structure that we're mapping, there's very
limited data there that could be used for validation, so garbage could
easily be mistaken for an actual table and mess things up.
Thierry
Attachment:
signature.asc
Description: PGP signature
