linux-kernel - RE: [PATCH 5/7] ARM: dts: rtd1195: Introduce r-bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <753c18eee3fb4e9ea25d42798542b3dd@realtek.com>
Date:   Mon, 18 Nov 2019 06:53:39 +0000
From:   James Tai <james.tai@...ltek.com>
To:     Andreas Färber <afaerber@...e.de>
CC:     "linux-realtek-soc@...ts.infradead.org" 
        <linux-realtek-soc@...ts.infradead.org>,
        Mark Rutland <mark.rutland@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH 5/7] ARM: dts: rtd1195: Introduce r-bus

Hi Andreas,

> 
> Fixed, also further above for the soc node. This now leaves a gap until
> 0x18100000 - is that gap RAM or non-r-bus registers then?
> 
> 		ranges = <0x18000000 0x18000000 0x00070000>,
> 		         <0x18100000 0x18100000 0x01000000>,
> 		         <0x40000000 0x40000000 0xc0000000>;
> 

> Did you also review the other two ranges? The middle one was labeled NOR
> flash somewhere - are start and size correct? The final one depends on the
> maximum RAM size - does RTD1195 allow more than 1 GiB RAM? All
> non-RAM regions should be covered here.
> 
It is reserved for NOR flash. The start and size is correct.
The rtd1195 can support to 2GiB RAM.

> So another question, applicable to all SoCs: This reserved Boot ROM area at
> the start of the address space, here of size 0xa800, is that copied into RAM, or
> is that the actual ROM overlapping RAM? If the latter, we should exclude it
> from /memory@0's reg (making it /memory@...0), and add it to soc's ranges
> here for correctness.
> 
Yes, we should exclude it from /memory@0's reg.

> With the follow-up question: Is it correct that, given the size 0xa800, I have a
> gap between /memreserve/s from 0xa800 to 0xc000, or should we reserve that
> gap by extending the next /memreserve/ or inserting one?

We should reserve memory address from 0x0000 to 0xa800 for the internal ROM.


Regards,
James