| Message ID | 20191111030434.29977-1-afaerber@suse.de |
|---|---|
| Headers | show |
| Series | arm64: dts: Initial RTD1395 and BPi-M4 support | expand |
Hi Andreas, > + rbus: r-bus@98000000 { > + compatible = "simple-bus"; > + reg = <0x98000000 0x100000>; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0x0 0x98000000 0x100000>; > + The r-bus size of RTD1395 is 0x200000. Regards, James
Hi Andreas, > + rbus: r-bus@18000000 { > + compatible = "simple-bus"; > + reg = <0x18000000 0x100000>; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0x0 0x18000000 0x100000>; > + The r-bus size of RTD1195 is 0x70000. Regards, James
Hi Andreas, > + soc { > + compatible = "simple-bus"; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0x98000000 0x0 0x98000000 0x68000000>; > + > + rbus: r-bus@98000000 { > + compatible = "simple-bus"; > + reg = <0x98000000 0x100000>; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0x0 0x98000000 0x100000>; The r-bus size of RTD1395 is 0x200000. Regards, James
> Hi Andreas, > > > + rbus: r-bus@98000000 { > > + compatible = "simple-bus"; > > + reg = <0x98000000 0x100000>; > > + #address-cells = <1>; > > + #size-cells = <1>; > > + ranges = <0x0 0x98000000 0x100000>; > > + > > The r-bus size of RTD1395 is 0x200000. > Sorry for the typo. The r-bus size of RTD1295 is 0x200000. Regards, James
Hi James, Am 13.11.19 um 04:02 schrieb James Tai: >>> + rbus: r-bus@98000000 { >>> + compatible = "simple-bus"; >>> + reg = <0x98000000 0x100000>; >>> + #address-cells = <1>; >>> + #size-cells = <1>; >>> + ranges = <0x0 0x98000000 0x100000>; >>> + >> >> The r-bus size of RTD1395 is 0x200000. >> > > Sorry for the typo. The r-bus size of RTD1295 is 0x200000. Fixed. Thanks, Andreas
Hi James, Am 13.11.19 um 03:53 schrieb James Tai: >> + rbus: r-bus@18000000 { >> + compatible = "simple-bus"; >> + reg = <0x18000000 0x100000>; >> + #address-cells = <1>; >> + #size-cells = <1>; >> + ranges = <0x0 0x18000000 0x100000>; >> + > > The r-bus size of RTD1195 is 0x70000. Fixed, also further above for the soc node. This now leaves a gap until 0x18100000 - is that gap RAM or non-r-bus registers then? ranges = <0x18000000 0x18000000 0x00070000>, <0x18100000 0x18100000 0x01000000>, <0x40000000 0x40000000 0xc0000000>; Did you also review the other two ranges? The middle one was labeled NOR flash somewhere - are start and size correct? The final one depends on the maximum RAM size - does RTD1195 allow more than 1 GiB RAM? All non-RAM regions should be covered here. So another question, applicable to all SoCs: This reserved Boot ROM area at the start of the address space, here of size 0xa800, is that copied into RAM, or is that the actual ROM overlapping RAM? If the latter, we should exclude it from /memory@0's reg (making it /memory@a800), and add it to soc's ranges here for correctness. With the follow-up question: Is it correct that, given the size 0xa800, I have a gap between /memreserve/s from 0xa800 to 0xc000, or should we reserve that gap by extending the next /memreserve/ or inserting one? Thanks, Andreas
Hi James, Am 13.11.19 um 03:57 schrieb James Tai: >> + soc { >> + compatible = "simple-bus"; >> + #address-cells = <1>; >> + #size-cells = <1>; >> + ranges = <0x98000000 0x0 0x98000000 0x68000000>; >> + >> + rbus: r-bus@98000000 { >> + compatible = "simple-bus"; >> + reg = <0x98000000 0x100000>; >> + #address-cells = <1>; >> + #size-cells = <1>; >> + ranges = <0x0 0x98000000 0x100000>; > > The r-bus size of RTD1395 is 0x200000. Fixed. Thanks, Andreas
On Sun, Nov 10, 2019 at 9:04 PM Andreas Färber <afaerber@suse.de> wrote: > > Model Realtek's register bus in DT. > > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- > This could be squashed into the original RTD1195 patch. > > arch/arm/boot/dts/rtd1195.dtsi | 52 ++++++++++++++++++++++++------------------ > 1 file changed, 30 insertions(+), 22 deletions(-) > > diff --git a/arch/arm/boot/dts/rtd1195.dtsi b/arch/arm/boot/dts/rtd1195.dtsi > index a8cc2d23e7ef..3439647ecf97 100644 > --- a/arch/arm/boot/dts/rtd1195.dtsi > +++ b/arch/arm/boot/dts/rtd1195.dtsi > @@ -92,28 +92,36 @@ > <0x18100000 0x18100000 0x01000000>, > <0x40000000 0x40000000 0xc0000000>; > > - wdt: watchdog@18007680 { > - compatible = "realtek,rtd1295-watchdog"; > - reg = <0x18007680 0x100>; > - clocks = <&osc27M>; > - }; > - > - uart0: serial@18007800 { > - compatible = "snps,dw-apb-uart"; > - reg = <0x18007800 0x400>; > - reg-shift = <2>; > - reg-io-width = <4>; > - clock-frequency = <27000000>; > - status = "disabled"; > - }; > - > - uart1: serial@1801b200 { > - compatible = "snps,dw-apb-uart"; > - reg = <0x1801b200 0x100>; > - reg-shift = <2>; > - reg-io-width = <4>; > - clock-frequency = <27000000>; > - status = "disabled"; > + rbus: r-bus@18000000 { Following node names should be generic: bus@... > + compatible = "simple-bus"; > + reg = <0x18000000 0x100000>; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0x0 0x18000000 0x100000>; > + > + wdt: watchdog@7680 { > + compatible = "realtek,rtd1295-watchdog"; > + reg = <0x7680 0x100>; > + clocks = <&osc27M>; > + }; > + > + uart0: serial@7800 { > + compatible = "snps,dw-apb-uart"; > + reg = <0x7800 0x400>; > + reg-shift = <2>; > + reg-io-width = <4>; > + clock-frequency = <27000000>; > + status = "disabled"; > + }; > + > + uart1: serial@1b200 { > + compatible = "snps,dw-apb-uart"; > + reg = <0x1b200 0x100>; > + reg-shift = <2>; > + reg-io-width = <4>; > + clock-frequency = <27000000>; > + status = "disabled"; > + }; > }; > > gic: interrupt-controller@ff011000 { > -- > 2.16.4 >
Am 15.11.19 um 02:34 schrieb Rob Herring: >> diff --git a/arch/arm/boot/dts/rtd1195.dtsi b/arch/arm/boot/dts/rtd1195.dtsi >> index a8cc2d23e7ef..3439647ecf97 100644 >> --- a/arch/arm/boot/dts/rtd1195.dtsi >> +++ b/arch/arm/boot/dts/rtd1195.dtsi >> @@ -92,28 +92,36 @@ >> <0x18100000 0x18100000 0x01000000>, >> <0x40000000 0x40000000 0xc0000000>; >> >> - wdt: watchdog@18007680 { >> - compatible = "realtek,rtd1295-watchdog"; >> - reg = <0x18007680 0x100>; >> - clocks = <&osc27M>; >> - }; >> - >> - uart0: serial@18007800 { >> - compatible = "snps,dw-apb-uart"; >> - reg = <0x18007800 0x400>; >> - reg-shift = <2>; >> - reg-io-width = <4>; >> - clock-frequency = <27000000>; >> - status = "disabled"; >> - }; >> - >> - uart1: serial@1801b200 { >> - compatible = "snps,dw-apb-uart"; >> - reg = <0x1801b200 0x100>; >> - reg-shift = <2>; >> - reg-io-width = <4>; >> - clock-frequency = <27000000>; >> - status = "disabled"; >> + rbus: r-bus@18000000 { > > Following node names should be generic: bus@... Fixed for all four SoCs. That seems inconsistent with specific pci@... & usb@... (both from OF), but I see now the Amlogic-specific buses that I was inspired by do use bus@..., too. Thanks, Andreas
Hi Andreas, > > Fixed, also further above for the soc node. This now leaves a gap until > 0x18100000 - is that gap RAM or non-r-bus registers then? > > ranges = <0x18000000 0x18000000 0x00070000>, > <0x18100000 0x18100000 0x01000000>, > <0x40000000 0x40000000 0xc0000000>; > > Did you also review the other two ranges? The middle one was labeled NOR > flash somewhere - are start and size correct? The final one depends on the > maximum RAM size - does RTD1195 allow more than 1 GiB RAM? All > non-RAM regions should be covered here. > It is reserved for NOR flash. The start and size is correct. The rtd1195 can support to 2GiB RAM. > So another question, applicable to all SoCs: This reserved Boot ROM area at > the start of the address space, here of size 0xa800, is that copied into RAM, or > is that the actual ROM overlapping RAM? If the latter, we should exclude it > from /memory@0's reg (making it /memory@a800), and add it to soc's ranges > here for correctness. > Yes, we should exclude it from /memory@0's reg. > With the follow-up question: Is it correct that, given the size 0xa800, I have a > gap between /memreserve/s from 0xa800 to 0xc000, or should we reserve that > gap by extending the next /memreserve/ or inserting one? We should reserve memory address from 0x0000 to 0xa800 for the internal ROM. Regards, James
Hi James, Am 18.11.19 um 07:53 schrieb James Tai: >> So another question, applicable to all SoCs: This reserved Boot ROM area at >> the start of the address space, here of size 0xa800, is that copied into RAM, or >> is that the actual ROM overlapping RAM? If the latter, we should exclude it >> from /memory@0's reg (making it /memory@a800), and add it to soc's ranges >> here for correctness. >> > Yes, we should exclude it from /memory@0's reg. OK, will look into it. > >> With the follow-up question: Is it correct that, given the size 0xa800, I have a >> gap between /memreserve/s from 0xa800 to 0xc000, or should we reserve that >> gap by extending the next /memreserve/ or inserting one? > > We should reserve memory address from 0x0000 to 0xa800 for the internal ROM. Please see [1] - I had already updated the second reservation to start at 0xa800 and extended it to 0x100000 before your response here. The previous "bootcode" size of 0xc000 can be found here: https://github.com/BPI-SINOVOIP/BPI-M4-bsp/blob/master/linux-rtk/arch/arm/mach-rtd119x/include/mach/memory.h https://github.com/BPI-SINOVOIP/BPI-M4-bsp/blob/master/linux-rtk/arch/arm/boot/dts/realtek/rtd119x/rtd-119x-horseradish.dts As you can see the 0xc000 and 0xf4000 were hardcoded and did not depend on SYS_BOOTCODE_MEMSIZE... For later SoCs I saw some FIXME(?) comment that area up to 0x100000 was reserved due to some Jira ticket and should get fixed? Any insights on what is in that memory range causing problems? Regards, Andreas [1] https://patchwork.kernel.org/patch/11248033/
Hi Andreas, > Please see [1] - I had already updated the second reservation to start at > 0xa800 and extended it to 0x100000 before your response here. Thank you. > The previous "bootcode" size of 0xc000 can be found here: > https://github.com/BPI-SINOVOIP/BPI-M4-bsp/blob/master/linux-rtk/arch/arm > /mach-rtd119x/include/mach/memory.h > https://github.com/BPI-SINOVOIP/BPI-M4-bsp/blob/master/linux-rtk/arch/arm > /boot/dts/realtek/rtd119x/rtd-119x-horseradish.dts > > As you can see the 0xc000 and 0xf4000 were hardcoded and did not depend on > SYS_BOOTCODE_MEMSIZE... > For later SoCs I saw some FIXME(?) comment that area up to 0x100000 was > reserved due to some Jira ticket and should get fixed? Any insights on what is > in that memory range causing problems? > The problem is solved. (memory overwrite by FW) Regards, James
Hi James and Realtek colleagues, Am 11.11.19 um 04:04 schrieb Andreas Färber: > Move /reserved-memory node from RTD1295 to RTD129x DT. > Convert RPC /memreserve/s into /reserved-memory nodes. > > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- > arch/arm64/boot/dts/realtek/rtd1295.dtsi | 13 +------------ > arch/arm64/boot/dts/realtek/rtd129x.dtsi | 23 ++++++++++++++++++++--- > 2 files changed, 21 insertions(+), 15 deletions(-) > > diff --git a/arch/arm64/boot/dts/realtek/rtd1295.dtsi b/arch/arm64/boot/dts/realtek/rtd1295.dtsi > index 34f6cc6f16fe..1402abe80ea1 100644 > --- a/arch/arm64/boot/dts/realtek/rtd1295.dtsi > +++ b/arch/arm64/boot/dts/realtek/rtd1295.dtsi > @@ -2,7 +2,7 @@ > /* > * Realtek RTD1295 SoC > * > - * Copyright (c) 2016-2017 Andreas Färber > + * Copyright (c) 2016-2019 Andreas Färber > */ > > #include "rtd129x.dtsi" > @@ -47,17 +47,6 @@ > }; > }; > > - reserved-memory { > - #address-cells = <1>; > - #size-cells = <1>; > - ranges; > - > - tee@10100000 { > - reg = <0x10100000 0xf00000>; > - no-map; > - }; > - }; > - > timer { > compatible = "arm,armv8-timer"; > interrupts = <GIC_PPI 13 > diff --git a/arch/arm64/boot/dts/realtek/rtd129x.dtsi b/arch/arm64/boot/dts/realtek/rtd129x.dtsi > index 4433114476f5..8d80cca945bc 100644 > --- a/arch/arm64/boot/dts/realtek/rtd129x.dtsi > +++ b/arch/arm64/boot/dts/realtek/rtd129x.dtsi > @@ -2,14 +2,12 @@ > /* > * Realtek RTD1293/RTD1295/RTD1296 SoC > * > - * Copyright (c) 2016-2017 Andreas Färber > + * Copyright (c) 2016-2019 Andreas Färber > */ > > /memreserve/ 0x0000000000000000 0x0000000000030000; > -/memreserve/ 0x000000000001f000 0x0000000000001000; > /memreserve/ 0x0000000000030000 0x00000000000d0000; > /memreserve/ 0x0000000001b00000 0x00000000004be000; > -/memreserve/ 0x0000000001ffe000 0x0000000000004000; > > #include <dt-bindings/interrupt-controller/arm-gic.h> > #include <dt-bindings/reset/realtek,rtd1295.h> > @@ -19,6 +17,25 @@ > #address-cells = <1>; > #size-cells = <1>; > > + reserved-memory { > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + > + rpc_comm: rpc@1f000 { > + reg = <0x1f000 0x1000>; > + }; > + > + rpc_ringbuf: rpc@1ffe000 { > + reg = <0x1ffe000 0x4000>; > + }; Have you reviewed this patch to be correct? I.e., are the above two regions reserved RAM (assumption above), or is this rather MMIO shadowing RAM? (then we would need to update the /memory reg and /soc ranges properties) That also affects RTD1619, which currently has neither. Thanks, Andreas > + > + tee: tee@10100000 { > + reg = <0x10100000 0xf00000>; > + no-map; > + }; > + }; > + > arm_pmu: arm-pmu { > compatible = "arm,cortex-a53-pmu"; > interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
Hi Andreas, > > /memreserve/ 0x0000000000000000 0x0000000000030000; > > -/memreserve/ 0x000000000001f000 0x0000000000001000; > > /memreserve/ 0x0000000000030000 0x00000000000d0000; > > /memreserve/ 0x0000000001b00000 0x00000000004be000; > > -/memreserve/ 0x0000000001ffe000 0x0000000000004000; > > > > #include <dt-bindings/interrupt-controller/arm-gic.h> > > #include <dt-bindings/reset/realtek,rtd1295.h> > > @@ -19,6 +17,25 @@ > > #address-cells = <1>; > > #size-cells = <1>; > > > > + reserved-memory { > > + #address-cells = <1>; > > + #size-cells = <1>; > > + ranges; > > + > > + rpc_comm: rpc@1f000 { > > + reg = <0x1f000 0x1000>; > > + }; > > + > > + rpc_ringbuf: rpc@1ffe000 { > > + reg = <0x1ffe000 0x4000>; > > + }; > > Have you reviewed this patch to be correct? I.e., are the above two regions > reserved RAM (assumption above), or is this rather MMIO shadowing RAM? > (then we would need to update the /memory reg and /soc ranges properties) > > That also affects RTD1619, which currently has neither. > The RPC common buffer and RPC ring buffer address is correct. Regards, James