| Message ID | 20230822092358.309835-1-andrej.skvortzov@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v2] arm64: dts: pinephone: Add pstore support for PinePhone A64 | expand |
Hi Andrey, send new revision as standalone e-mail, not as reply to old discussion. Dne torek, 22. avgust 2023 ob 11:23:58 CEST je Andrey Skvortsov napisal(a): > This patch reserves some memory in the DTS and sets up a > pstore device tree node to enable pstore support. > > In general any DRAM address, that isn't overwritten during a boot is > suitable for pstore. > > Range from 0x40000000 - 0x50000000 is heavily used by u-boot for > internal use and to load kernel, fdt, fdto, scripts, pxefile and ramdisk > later in the boot process. Ramdisk start address is 0x4FF00000, > initramfs for kernel with some hacking features and debug info enabled > can take more than 100Mb and final address will be around 0x58000000. > Address 0x61000000 will most likely not overlap with that. There are other bootloaders as U-Boot, especially on PinePhone. Are you sure it works there too? What about U-Boot configuration, will those addresses still be used if configuration is changed? Best regards, Jernej > > Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> > --- > > Changes in v2: > - Update commit description with information about why this base address is > used. > > .../boot/dts/allwinner/sun50i-a64-pinephone.dtsi | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi > b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi index > 87847116ab6d..84f9410b0b70 100644 > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi > @@ -19,6 +19,22 @@ aliases { > serial0 = &uart0; > }; > > + reserved-memory { > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + > + pstore_mem: ramoops@61000000 { > + compatible = "ramoops"; > + reg = <0x61000000 0x100000>; > + record-size = <0x20000>; > + console-size = <0x20000>; > + ftrace-size = <0x20000>; > + pmsg-size = <0x20000>; > + ecc-size = <16>; > + }; > + }; > + > backlight: backlight { > compatible = "pwm-backlight"; > pwms = <&r_pwm 0 50000 PWM_POLARITY_INVERTED>;
On Wed, 23 Aug 2023 21:36:51 +0200 Jernej Škrabec <jernej.skrabec@gmail.com> wrote: Hi Andrey, > send new revision as standalone e-mail, not as reply to old discussion. > > Dne torek, 22. avgust 2023 ob 11:23:58 CEST je Andrey Skvortsov napisal(a): > > This patch reserves some memory in the DTS and sets up a > > pstore device tree node to enable pstore support. > > > > In general any DRAM address, that isn't overwritten during a boot is > > suitable for pstore. > > > > Range from 0x40000000 - 0x50000000 is heavily used by u-boot for > > internal use and to load kernel, fdt, fdto, scripts, pxefile and ramdisk > > later in the boot process. Ramdisk start address is 0x4FF00000, > > initramfs for kernel with some hacking features and debug info enabled > > can take more than 100Mb and final address will be around 0x58000000. > > Address 0x61000000 will most likely not overlap with that. > > There are other bootloaders as U-Boot, especially on PinePhone. Are you sure > it works there too? What about U-Boot configuration, will those addresses still > be used if configuration is changed? Also going along with what Pavel said (that's it more a policy decision, not a device property), I feel like this node should be added by the bootloader then. And indeed U-Boot has support for that already.
Hi Andre, On 23-08-24 14:50, Andre Przywara wrote: > On Wed, 23 Aug 2023 21:36:51 +0200 > Jernej Škrabec <jernej.skrabec@gmail.com> wrote: > > > Hi Andrey, > > > send new revision as standalone e-mail, not as reply to old discussion. > > > > Dne torek, 22. avgust 2023 ob 11:23:58 CEST je Andrey Skvortsov napisal(a): > > > This patch reserves some memory in the DTS and sets up a > > > pstore device tree node to enable pstore support. > > > > > > In general any DRAM address, that isn't overwritten during a boot is > > > suitable for pstore. > > > > > > Range from 0x40000000 - 0x50000000 is heavily used by u-boot for > > > internal use and to load kernel, fdt, fdto, scripts, pxefile and ramdisk > > > later in the boot process. Ramdisk start address is 0x4FF00000, > > > initramfs for kernel with some hacking features and debug info enabled > > > can take more than 100Mb and final address will be around 0x58000000. > > > Address 0x61000000 will most likely not overlap with that. > > > > There are other bootloaders as U-Boot, especially on PinePhone. Are you sure > > it works there too? What about U-Boot configuration, will those addresses still > > be used if configuration is changed? > > Also going along with what Pavel said (that's it more a policy > decision, not a device property), I feel like this node should be added > by the bootloader then. And indeed U-Boot has support for that already. > From skimming over the code in cmd/pstore.c: if you enable > CONFIG_CMD_PSTORE and set CONFIG_CMD_PSTORE_MEM_ADDR to your chosen > address, then the U-Boot code will insert a reserved memory node on the > fly. Would that solve your problem? > I've tried pstore command in u-boot in the past to make sure it's working there as well. I didn't know, that it adds reserved-memory node as well. Thanks, Andre. That is very helpful. I've tried it again without patching a kernel as you suggested. Unfortunately it's not working on A64. If there is no reserved-memory defined, u-boot adds a new one with following properties: reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; } But with these default address-cells and size-cells values, pstore isn't working on A64. Root node for A64 defines 'address-cells' and 'size-cells' as 1. dtc complains if reserved-memory has different address-cells and size-cells. ``` Warning (ranges_format): /reserved-memory:ranges: empty "ranges" property but its #address-cells (2) differs from / (1) ``` If empty reserved-memory is added to arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi in the kernel, then u-boot adds working pstore subnode. ``` reserved-memory { #address-cells = <1>; #size-cells = <1>; ranges; /* bootloader will add new entries here * for example, for pstore. */ }; ``` It looks like a bug in u-boot for me. IMHO, it should look at #address-cells/#size-cells of the root-node for default values. I have tried that and this way pstore is working without any changes to the kernel dts. What do you think? Should I submit fix to u-boot instead?
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi index 87847116ab6d..84f9410b0b70 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi @@ -19,6 +19,22 @@ aliases { serial0 = &uart0; }; + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + + pstore_mem: ramoops@61000000 { + compatible = "ramoops"; + reg = <0x61000000 0x100000>; + record-size = <0x20000>; + console-size = <0x20000>; + ftrace-size = <0x20000>; + pmsg-size = <0x20000>; + ecc-size = <16>; + }; + }; + backlight: backlight { compatible = "pwm-backlight"; pwms = <&r_pwm 0 50000 PWM_POLARITY_INVERTED>;
This patch reserves some memory in the DTS and sets up a pstore device tree node to enable pstore support. In general any DRAM address, that isn't overwritten during a boot is suitable for pstore. Range from 0x40000000 - 0x50000000 is heavily used by u-boot for internal use and to load kernel, fdt, fdto, scripts, pxefile and ramdisk later in the boot process. Ramdisk start address is 0x4FF00000, initramfs for kernel with some hacking features and debug info enabled can take more than 100Mb and final address will be around 0x58000000. Address 0x61000000 will most likely not overlap with that. Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> --- Changes in v2: - Update commit description with information about why this base address is used. .../boot/dts/allwinner/sun50i-a64-pinephone.dtsi | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)