From: Jessica Clarke <jrtc27@jrtc27.com>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: Samuel Holland <samuel@sholland.org>,
Conor.Dooley@microchip.com,
devicetree <devicetree@vger.kernel.org>,
Peter Korsgaard <peter@korsgaard.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
jernej.skrabec@gmail.com, Chen-Yu Tsai <wens@csie.org>,
robh+dt@kernel.org, palmer@dabbelt.com,
krzysztof.kozlowski+dt@linaro.org, paul.walmsley@sifive.com,
linux-riscv@lists.infradead.org, linux-sunxi@lists.linux.dev
Subject: Re: [PATCH 07/12] riscv: dts: allwinner: Add Allwinner D1 Nezha devicetree
Date: Fri, 9 Sep 2022 20:04:02 +0100 [thread overview]
Message-ID: <F27C6531-E91E-4311-B64D-D26FE12086CA@jrtc27.com> (raw)
In-Reply-To: <3687587.6M6d0yLqnL@diego>
On 9 Sept 2022, at 09:11, Heiko Stübner <heiko@sntech.de> wrote:
>
> Am Freitag, 9. September 2022, 09:18:40 CEST schrieb Conor.Dooley@microchip.com:
>> On 09/09/2022 05:37, Samuel Holland wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you
>>> know the content is safe
>>>
>>> Hi Conor,
>>>
>>> On 8/19/22 5:10 PM, Conor.Dooley@microchip.com wrote:
>>>> Finally got around to giving this a go with the fix for loading
>>>> modules which is mostly what was blocking me before..
>>>>
>>>> On 15/08/2022 06:08, Samuel Holland wrote:
>>>>> "D1 Nezha" is Allwinner's first-party development board for the
>>>>> D1 SoC. It was shipped with 512M, 1G, or 2G of DDR3. It supports
>>>>> onboard audio,
>>>>
>>>> I am really not keen on the way you have things, with the memory
>>>> nodes removed from the device tree. I know your preferred flow for
>>>> booting these things might be to pass the dtb up from U-Boot, but I
>>>> think the devicetree in the kernel should be usable in a standalone
>>>> manner, even if that is the barest-minimum memory config.
>>>
>>> That is simply not possible to guarantee. As an obvious example,
>>> consider the MangoPi MQ-Pro board with socketed DRAM:
>>
>> Yeah, I knew in my heart-of-hearts that this probably was a non
>> runner.
>>
>>>
>>> https://twitter.com/mangopi_sbc/status/1516225559214583808
>>>
>>> But focusing on the /memory node misses the bigger picture. The DTB
>>> is passed through _all_ of the firmware stages, and gets patched by
>>> every one of them:
>>>
>>> - SPL/boot0 adds the /memory node with the detected DRAM size. If the
>>> in-tree DTS has a "minimum memory config" (which for a board with
>>> socketed DRAM means the smallest possible die), I guarantee people
>>> will use it and complain about missing DRAM.
>>
>> True, but they are also complaining about missing DRAM as is ;)
>> No possibility of winning here unfortunately.
>>
>>> - The SBI implementation reserves memory for itself and any possible
>>> secure partitions. Right now, booting happens to work without the
>>> reserved-memory node because the SBI implementation is loaded at the
>>> beginning of RAM, and Linux ignores RAM below the kernel load
>>> address.
>>
>> Surely this sort of thing is a common problem though, it's not like
>> any of us are doing something unique here are we? At least if there
>> was a arch wide policy about the validity of the upstream DTS in the
>> face of the SBI etc inflicting changes there'd be something to point
>> to. I am just looking at this from a "everyone else has a usable dts
>> in the kernel, but the D1 boards wont have" point of view.
>
> Not sure if this would fly, but what about having an sbi call for
> "modify this dtb for me as well"?
>
> I'll just assume that spl/boot0 + main uboot come in some sort
> of package so moving the memory node over should be in uboot's
> scope, but for the sbi part just have a call pointing to the
> new dtb in memory and have it modify it in the same way as the
> original one?
There’s an EFI protocol for it.
Jess
> Heiko
>
>
>
>>> However, memory-constrained devices (e.g. D1s) will need to get those
>>> 2 MiB back by loading the kernel at the start of DRAM and SBI at the
>>> end of DRAM. Then the reserved-memory node becomes quite important.
>>>
>>> It also adds nodes for CPU idle states, since the available states
>>> and their latencies depend on the SBI implementation.
>>>
>>> It also reserves devices used by it or by a secure partition. And it
>>> is responsible for extracting data (e.g. MAC addresses) from "secure"
>>> eFuses which the OS may not have access to.
>>>
>>> - U-Boot adds other information, like boot arguments, the address of
>>> the initramfs and framebuffer, etc. These are less of a concern
>>> because of course U-Boot can patch these in to a DTB loaded from
>>> disk, but they are relevant if you want to load a DTB from a later
>>> bootloader like GRUB.
>>>
>>> If you load a DTB from disk, you lose all of the changes made by the
>>> earlier firmware stages. On ARM, U-Boot tries to work around this by
>>> copying a few specific bits of information from the firmware DTB to
>>> the DTB loaded from disk. But this misses the point that the SBI
>>> implementation can modify *any* part of the DTB. (So in practice
>>> U-Boot on ARM already loses CPU idle states and reserved memory nodes
>>> that were added by the PSCI implementation.)
>>
>> All of these things are valid, but they are reasons why your flow in
>> your bootloaders etc are the way they are more than a reason why the
>> upstream dts will not work for someone who is not interested in that
>> flow. At the end of the day, I only care so much about this as it is
>> not me that has to deal with any confusion from either approach. I'll
>> continue to modify my dts in U-Boot so I can test things without me
>> having to re-program the world. /shrug
>>
>>> As an extreme example, consider paravirtualization, where only a
>>> small subset of DRAM and peripherals may be made available to any one
>>> OS partition.
>>
>> Or AMP - though not likely that that is a problem for the D1..
>>
>>> Fundamentally, I reserve the right to make arbitrary changes to the
>>> DTB in the SBI implementation, and thus I cannot condone using the
>>> DTBs generated from the Linux source tree for any purpose other than
>>> validation.
>>
>> Fundamentally, I reserve the right to complain that the upstream dts
>> cannot be entirely validated as it does not work out-of-the-box ;)
>>
>> Either way, I am only going to complain so much about something that
>> triggers my OCD about keeping things the same, you have a
>> Tested-by: Conor Dooley <conor.dooley@microchip.com>
>> already and once the other issues are cleaned up an R-b too. Not trying
>> make an issue out of this, just expressing my dislike for the
>> inconsistency between the D1 stuff and vendors - partly in the hopes
>> that the "higher powers" get involved. I can't imagine that this is
>> the last time something like this comes up.
>>
>> Thanks,
>> Conor.
>>
>>
>>
>>
>>
>>
>
>
>
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2022-09-09 19:04 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-15 5:08 [PATCH 00/12] riscv: Allwinner D1 platform support Samuel Holland
2022-08-15 5:08 ` [PATCH 01/12] MAINTAINERS: Match the sun20i family of Allwinner SoCs Samuel Holland
2022-08-15 17:06 ` Heiko Stübner
2022-08-15 5:08 ` [PATCH 02/12] dt-bindings: riscv: Add T-HEAD C906 and C910 compatibles Samuel Holland
2022-08-15 17:07 ` Heiko Stübner
2022-08-16 17:34 ` Rob Herring
2022-11-04 2:57 ` Icenowy Zheng
2022-11-20 11:23 ` Conor Dooley
2022-11-20 11:25 ` Conor Dooley
2022-08-15 5:08 ` [PATCH 03/12] dt-bindings: vendor-prefixes: Add Allwinner D1 board vendors Samuel Holland
2022-08-15 17:12 ` Heiko Stübner
2022-08-16 17:34 ` Rob Herring
2022-08-15 5:08 ` [PATCH 04/12] dt-bindings: riscv: Add Allwinner D1 board compatibles Samuel Holland
2022-08-16 7:39 ` Krzysztof Kozlowski
2022-08-16 9:02 ` Heiko Stübner
2022-08-16 9:12 ` Heiko Stübner
2022-08-16 17:35 ` Rob Herring
2022-08-15 5:08 ` [PATCH 05/12] riscv: Add the Allwinner SoC family Kconfig option Samuel Holland
2022-08-15 16:56 ` Conor.Dooley
2022-08-16 9:17 ` Heiko Stübner
2022-08-16 9:23 ` Conor.Dooley
2022-08-15 17:13 ` Heiko Stübner
2022-08-15 5:08 ` [PATCH 06/12] riscv: dts: allwinner: Add the D1 SoC base devicetree Samuel Holland
2022-08-15 13:11 ` Andre Przywara
2022-08-15 17:01 ` Conor.Dooley
2022-08-20 17:24 ` Samuel Holland
2022-08-20 17:29 ` Conor.Dooley
2022-08-21 6:45 ` Icenowy Zheng
2022-08-21 10:04 ` Conor.Dooley
2022-08-22 11:46 ` Geert Uytterhoeven
2022-08-22 12:13 ` Conor.Dooley
2022-08-22 12:29 ` Andre Przywara
2022-08-22 12:31 ` Geert Uytterhoeven
2022-08-22 13:56 ` Conor.Dooley
2022-08-22 15:29 ` Jessica Clarke
2022-09-09 3:42 ` Samuel Holland
2022-09-09 7:10 ` Geert Uytterhoeven
2022-09-21 7:49 ` Geert Uytterhoeven
2022-08-22 10:50 ` Andre Przywara
2022-08-16 7:41 ` Krzysztof Kozlowski
2022-08-16 7:49 ` Jernej Škrabec
2022-08-16 9:12 ` Heiko Stübner
2022-08-16 9:25 ` Jernej Škrabec
2022-08-16 9:42 ` Krzysztof Kozlowski
2022-08-16 11:00 ` Andre Przywara
2022-08-16 11:11 ` Krzysztof Kozlowski
2022-08-16 11:12 ` Krzysztof Kozlowski
2022-08-16 11:34 ` Conor.Dooley
2022-08-22 11:40 ` Geert Uytterhoeven
2022-08-16 9:11 ` Heiko Stübner
2022-08-17 8:29 ` Krzysztof Kozlowski
2022-08-19 22:19 ` Conor.Dooley
2022-08-15 5:08 ` [PATCH 07/12] riscv: dts: allwinner: Add Allwinner D1 Nezha devicetree Samuel Holland
2022-08-15 17:37 ` Conor.Dooley
2022-08-15 18:34 ` Conor.Dooley
2022-08-16 8:55 ` Heiko Stübner
2022-08-19 22:10 ` Conor.Dooley
2022-08-21 7:06 ` Icenowy Zheng
2022-09-04 20:10 ` Peter Korsgaard
2022-09-09 4:37 ` Samuel Holland
2022-09-09 7:18 ` Conor.Dooley
2022-09-09 8:11 ` Heiko Stübner
2022-09-09 19:04 ` Jessica Clarke [this message]
2022-09-03 15:21 ` Peter Korsgaard
2022-08-15 5:08 ` [PATCH 08/12] riscv: dts: allwinner: Add Sipeed Lichee RV devicetrees Samuel Holland
2022-08-15 5:08 ` [PATCH 09/12] riscv: dts: allwinner: Add MangoPi MQ Pro devicetree Samuel Holland
2022-08-15 5:08 ` [PATCH 10/12] riscv: dts: allwinner: Add Dongshan Nezha STU devicetree Samuel Holland
2022-08-15 5:08 ` [PATCH 11/12] riscv: dts: allwinner: Add ClockworkPi and DevTerm devicetrees Samuel Holland
2022-08-15 5:08 ` [PATCH 12/12] riscv: defconfig: Enable the Allwinner D1 platform and drivers Samuel Holland
2022-08-15 7:05 ` [PATCH 00/12] riscv: Allwinner D1 platform support Conor.Dooley
2022-08-15 17:12 ` Conor.Dooley
2022-08-16 2:42 ` Samuel Holland
2022-08-16 6:38 ` Conor.Dooley
2022-09-01 18:10 ` Palmer Dabbelt
2022-09-02 5:42 ` Conor.Dooley
2022-09-06 20:29 ` Jernej Škrabec
2022-09-07 20:43 ` Conor.Dooley
2022-09-08 7:00 ` Geert Uytterhoeven
2022-09-08 9:04 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F27C6531-E91E-4311-B64D-D26FE12086CA@jrtc27.com \
--to=jrtc27@jrtc27.com \
--cc=Conor.Dooley@microchip.com \
--cc=aou@eecs.berkeley.edu \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=jernej.skrabec@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=peter@korsgaard.com \
--cc=robh+dt@kernel.org \
--cc=samuel@sholland.org \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).