On 9 Sept 2022, at 09:11, Heiko Stübner <heiko@xxxxxxxxx> wrote: > > Am Freitag, 9. September 2022, 09:18:40 CEST schrieb Conor.Dooley@xxxxxxxxxxxxx: >> 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@xxxxxxxxxxxxx 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@xxxxxxxxxxxxx> >> 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@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-riscv
