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: <CAODwPW-9njhmjf1jEYsm68-StqciovgXo8VFBYksrdmqDJGC7g@mail.gmail.com>
Date:   Wed, 31 Aug 2022 18:11:46 -0700
From:   Julius Werner <jwerner@...omium.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Julius Werner <jwerner@...omium.org>,
        Rob Herring <robh+dt@...nel.org>,
        Dmitry Osipenko <digetx@...il.com>,
        Doug Anderson <dianders@...omium.org>,
        Jian-Jia Su <jjsu@...gle.com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/4] dt-bindings: memory: Add jedec,lpddrX-channel binding

> > +description:
> > +  An LPDDR channel is a completely independent set of LPDDR pins (DQ, CA, CS,
> > +  CK, etc.) that connect one or more LPDDR chips to a host system. The main
> > +  purpose of this node is to overall LPDDR topology of the system, including the
> > +  amount of individual LPDDR chips and the ranks per chip.
>
> "channel" in this context confuses me a bit, because usually everyone is
> talking about DDR controller channels, not memory channels. I think this
> actually maps to a DDR controller channel?

I'm not really sure what you mean by "memory channel" here (that would
be different from the DDR controller channel)? According to my
understanding there's only one kind of "channel" in the context of
main memory, that's the DDR controller channel (i.e. each separate
complete set of DDR pins coming out of the controller, as I tried to
explain in the description).

> > +    lpddr-channel1 {
> > +      #address-cells = <1>;
> > +      #size-cells = <0>;
> > +      compatible = "jedec,lpddr4-channel";
> > +      io-width = <32>;
>
> I wonder now, how does it exactly work - channel is 32 bits, two ranks
> each with 32 bit IO bus. Your description said that:
>
> total_ram = (rank0 + rank1) * (channel_width / chip_width)
> so for this case: (4+2)*(32/32) = 6 Mbit
>
> If channel io-width = <64>, then memories are stacked in parallel and
> according to your description total RAM would be: (4+2)*(64/32) = 12 Mbit
> I wonder why stacking memories in parallel increases their size?

Well, stacking in parallel just means you have more of them? In the
original example, you have a single LPDDR chip with two ranks, one
4Gbit rank and one 2Gbit rank. That chip is directly hooked up to the
LPDDR controller and that's the only chip you have, so you have 4+2 =
6Gbit total memory in the system.

In your next example, the LPDDR controller has a 64 bit wide channel,
but you're still using that same 6Gbit LPDDR chip that only has 32 DQ
pins. The only way to fill out that 64 bit channel with this kind of
chip is to have two of them in parallel (one connected to DQ[0:31] and
one connected to DQ[32:63]). So we infer from the mismatch in io-width
that we have two chips. Each chip still has 6Gbit of memory, so the
total system would have 12Gbit.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ