linux-kernel - Re: [RFC PATCH] riscv: dts: nezha-d1: Add memory

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] [day] [month] [year] [list]

Message-ID: <CALs-Hss-W78x04LS7X_RiTmU19Xv6d3f4x5rgeEhV7TVy7_CEA@mail.gmail.com>
Date:   Fri, 31 Mar 2023 12:02:28 -0700
From:   Evan Green <evan@...osinc.com>
To:     Conor Dooley <conor@...nel.org>
Cc:     linux-sunxi@...ts.linux.dev, conor.dooley@...rochip.com,
        Albert Ou <aou@...s.berkeley.edu>,
        Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Rob Herring <robh+dt@...nel.org>,
        Samuel Holland <samuel@...lland.org>,
        Trevor Woerner <twoerner@...il.com>,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [RFC PATCH] riscv: dts: nezha-d1: Add memory

On Fri, Mar 31, 2023 at 11:39 AM Conor Dooley <conor@...nel.org> wrote:
>
> On Fri, Mar 31, 2023 at 11:27:27AM -0700, Evan Green wrote:
> > Add memory info for the D1 Nezha, which seems to be required for it to
> > boot with the stock firmware. Note that this hardcodes 1GB, which is
> > not technically correct as they also make models with different amounts
> > of RAM.
>
> > Is the firmware supposed to populate this?
>
> Yup. Samuel intentionally did it this way:
> https://lore.kernel.org/linux-riscv/8a2194bf-93bd-de4d-8d39-0cd72aabb0a9@sholland.org/
>
> Since I don't like using the firmware provided stuff to more easily
> test I do this in my u-boot boot script:
>
> tftp 0x54000000 d1-fitImage.fit
> bootm start 0x54000000
> bootm loados 0x54000000
> bootm ramdisk;
> bootm prep;
> fdt memory 0x40000000 0x20000000
> bootm go;
>
> Hope either of the above are helpful,
> Conor.

Ah, I see, thanks for the pointers. I've got whatever firmware came
with the "dd and go" Fedora image I found on the internet somewhere,
which doesn't seem to do the memory node population for me. I've been
hesitant to rebuild the firmware as I don't want to break the Fedora
"safe OS", and if there's a way to get mired in some build
environment, I seem to have a nose for finding it.

I'll probably just keep the patch locally in my tree, and if I'm
forced to update the firmware for some other reason I'll try removing
it.

-Evan