Re: [PATCH] sunxi: psci: remove redundant initialization from psci_arch_init

[Chen-Yu Tsai]

On Tue, Aug 15, 2023 at 4:40 AM Andre Przywara  wrote:
>
> On Wed, 31 May 2023 14:15:20 -0600
> Sam Edwards  wrote:
>
> Hi,
>
> (CC:ing Marc and Chen-Yu as the original authors)
>
> sorry for the delay, found that mouldering in my Drafts folder.
>
> > The nonsec code overrides/handles these:
> > - Setting PMR to 0xFF happens earlier, in _nonsec_init, so this is
> >   redundant.
> > - The NS bit is not yet set: it gets set later in _secure_monitor.
> >   Trying to clear it here is pointless and misleading.
>
> So superficially this looks alright, but I am still somewhat reluctant
> to apply this, see below ...
>
> > Signed-off-by: Sam Edwards 
> > ---
> >  arch/arm/cpu/armv7/sunxi/psci.c | 4 
> >  1 file changed, 4 deletions(-)
> >
> > diff --git a/arch/arm/cpu/armv7/sunxi/psci.c 
> > b/arch/arm/cpu/armv7/sunxi/psci.c
> > index e1d3638b5c..f866025c37 100644
> > --- a/arch/arm/cpu/armv7/sunxi/psci.c
> > +++ b/arch/arm/cpu/armv7/sunxi/psci.c
> > @@ -300,14 +300,10 @@ void __secure psci_arch_init(void)
> >   /* Set SGI15 priority to 0 */
> >   writeb(0, GICD_BASE + GICD_IPRIORITYRn + 15);
> >
> > - /* Be cool with non-secure */
> > - writel(0xff, GICC_BASE + GICC_PMR);
> > -
> >   /* Switch FIQEn on */
> >   setbits_le32(GICC_BASE + GICC_CTLR, BIT(3));
> >
> >   reg = cp15_read_scr();
> >   reg |= BIT(2);  /* Enable FIQ in monitor mode */
> > - reg &= ~BIT(0); /* Secure mode */
>
> I am scratching my head on this one: I see it deliberately being done in
> the original patch by Marc[1], and wonder why. If I read the code and
> the architecture correctly, this routine is called only(?) from the SMC
> handler, which means we are in monitor mode, that only exists in secure
> state. So the NS bit is irrelevant until we switch to another mode. And
> we indeed set the bit later, before dropping back to non-secure. So I
> agree that clearing the bit is pointless. Was it put in to be more
> robust, for other potential callers of this function, for instance in
> the boot path?

IIRC the GIC manual says that the secure bit is set or cleared to select
which bank of registers is accessed.

And I suppose it is here to be more robust.

ChenYu

> Does anyone remember?
>
> Cheers,
> Andre
>
> [1]
> https://source.denx.de/u-boot/u-boot/-/commit/d5db7024aafc5ea603f3a34f83bb29a1eaa3cbe7#f377950449a5dba076796d9e48fbd21f5d6ac545_0_65
>
> >   cp15_write_scr(reg);
> >  }
>

Re: [PATCH] sunxi: psci: remove redundant initialization from psci_arch_init

[Chen-Yu Tsai]

(resent from kernel.org address)

On Tue, Aug 29, 2023 at 5:49 AM Sam Edwards  wrote:
>
> On 8/26/23 04:22, Marc Zyngier wrote:
>
> Hi Marc!
>
> > The GIC definitely has the NS bit routed to it. Otherwise, the secure
> > configuration would just be an utter joke. Just try it.
>
> Thank you for your response. I'd like to revisit my prior point about
> the distinction between the NS bit and AxPROT[1] bits in the context of
> monitor mode: in monitor mode, the NS bit does not determine the
> security state of the CPU core (monitor mode is always secure). But even
> then, the NS bit is still significant for other purposes, such as to
> bank accesses to certain CP15 registers -- and if I understand Chen-Yu
> correctly, some GIC registers also. That would require a special NS bit
> signal routed to the GIC so that it can distinguish between "secure,
> NS=0" and "secure, NS=1" accesses, which is why I asked if such a thing
> exists.
>
> I understand that the GIC is designed to be aware of the security state
> (using the existing AxPROT[1] signals) so that it can protect the
> sensitive registers. And unless I misunderstand, this seems to be the
> point that you made here (my interpretation -- correct me if I'm wrong
> -- is that you are using "NS bit" as a metonym for "security state").
> However I must clarify that my question was to seek further information
> from Chen-Yu about the possibility that NS is significant when accessing
> the GIC, even in monitor mode. Alternatively, his point might be merely
> highlighting that the GIC permits different types of access depending on
> the CPU's security state, which aligns with the viewpoint you've reiterated.
>
> I apologize if my previous message didn't convey this context clearly
> enough. My goal was to unravel this nuanced aspect of the NS bit when in
> monitor mode, and to determine if NS needs to be getting set/cleared
> during GIC setup to maneuver around the banking, or if the value of the
> NS bit when in psci_arch_init() is truly of no consequence due to
> monitor mode.

Sorry for my previous misleading comment. The banked registers refer to
the CP15 registers. From ARM's documentation [1]:

When the processor is in Monitor mode, the processor is in Secure state
regardless of the value of the SCR.NS bit. In Monitor mode, the SCR.NS
bit determines whether the Secure Banked CP15 registers or Non-secure
Banked CP15 registers are read or written using MRC or MCR instructions.

[1] 
https://developer.arm.com/documentation/ddi0406/b/System-Level-Architecture/Virtual-Memory-System-Architecture--VMSA-/CP15-registers-for-a-VMSA-implementation/Effect-of-the-Security-Extensions-on-the-CP15-registers?lang=en#Cbbdffad

> > Well, history is unfortunately against you on that front. Running on
> > the secure side definitely was a requirement when this code was
> > initially written, as the AW BSP *required* to run on the secure side.
> >
> > If that requirement is no more, great. But I don't think you can
> > decide that unilaterally.
>
> I have no idea when/if this requirement was changed. It might have never
> happened "formally": perhaps at some point, the SCR.NS=1 code got added
> after the call to psci_arch_init(), breaking (that version of) the AW
> BSP, and nobody ever complained or changed it back... so it stayed.

There was never any BSP code for PSCI before this. This code was written
by Marc in ARM assembly. I merely translated most of it to C code.
The snippet to clear SCR.NS is there in the first commit,

d5db7024aafc sunxi: HYP/non-sec: add sun7i PSCI backend

ChenYu

> But we're starting to digress from what _this_ patch does. The intent
> here is only to remove two lines of code that (we're discussing to
> confirm) have no effect. I'm not touching the code that *actually*
> determines the world into which monitor mode exits.
>
> Cheers,
> Sam

Re: [PATCH] sunxi: psci: remove redundant initialization from psci_arch_init

[Chen-Yu Tsai]

On Tue, Aug 29, 2023 at 5:49 AM Sam Edwards  wrote:
>
> On 8/26/23 04:22, Marc Zyngier wrote:
>
> Hi Marc!
>
> > The GIC definitely has the NS bit routed to it. Otherwise, the secure
> > configuration would just be an utter joke. Just try it.
>
> Thank you for your response. I'd like to revisit my prior point about
> the distinction between the NS bit and AxPROT[1] bits in the context of
> monitor mode: in monitor mode, the NS bit does not determine the
> security state of the CPU core (monitor mode is always secure). But even
> then, the NS bit is still significant for other purposes, such as to
> bank accesses to certain CP15 registers -- and if I understand Chen-Yu
> correctly, some GIC registers also. That would require a special NS bit
> signal routed to the GIC so that it can distinguish between "secure,
> NS=0" and "secure, NS=1" accesses, which is why I asked if such a thing
> exists.
>
> I understand that the GIC is designed to be aware of the security state
> (using the existing AxPROT[1] signals) so that it can protect the
> sensitive registers. And unless I misunderstand, this seems to be the
> point that you made here (my interpretation -- correct me if I'm wrong
> -- is that you are using "NS bit" as a metonym for "security state").
> However I must clarify that my question was to seek further information
> from Chen-Yu about the possibility that NS is significant when accessing
> the GIC, even in monitor mode. Alternatively, his point might be merely
> highlighting that the GIC permits different types of access depending on
> the CPU's security state, which aligns with the viewpoint you've reiterated.
>
> I apologize if my previous message didn't convey this context clearly
> enough. My goal was to unravel this nuanced aspect of the NS bit when in
> monitor mode, and to determine if NS needs to be getting set/cleared
> during GIC setup to maneuver around the banking, or if the value of the
> NS bit when in psci_arch_init() is truly of no consequence due to
> monitor mode.

Sorry for my previous misleading comment. The banked registers refer to
the CP15 registers. From ARM's documentation [1]:

When the processor is in Monitor mode, the processor is in Secure state
regardless of the value of the SCR.NS bit. In Monitor mode, the SCR.NS
bit determines whether the Secure Banked CP15 registers or Non-secure
Banked CP15 registers are read or written using MRC or MCR instructions.

[1] 
https://developer.arm.com/documentation/ddi0406/b/System-Level-Architecture/Virtual-Memory-System-Architecture--VMSA-/CP15-registers-for-a-VMSA-implementation/Effect-of-the-Security-Extensions-on-the-CP15-registers?lang=en#Cbbdffad

> > Well, history is unfortunately against you on that front. Running on
> > the secure side definitely was a requirement when this code was
> > initially written, as the AW BSP *required* to run on the secure side.
> >
> > If that requirement is no more, great. But I don't think you can
> > decide that unilaterally.
>
> I have no idea when/if this requirement was changed. It might have never
> happened "formally": perhaps at some point, the SCR.NS=1 code got added
> after the call to psci_arch_init(), breaking (that version of) the AW
> BSP, and nobody ever complained or changed it back... so it stayed.

There was never any BSP code for PSCI before this. This code was written
by Marc in ARM assembly. I merely translated most of it to C code.
The snippet to clear SCR.NS is there in the first commit,

d5db7024aafc sunxi: HYP/non-sec: add sun7i PSCI backend

ChenYu

> But we're starting to digress from what _this_ patch does. The intent
> here is only to remove two lines of code that (we're discussing to
> confirm) have no effect. I'm not touching the code that *actually*
> determines the world into which monitor mode exits.
>
> Cheers,
> Sam

Re: [PATCH] rockchip: rk3399: add ethaddr and serial# init, enable for R4S

[Chen-Yu Tsai]

On Mon, Sep 26, 2022 at 7:53 PM Christian Kohlschütter
 wrote:
>
> Some RK3399 boards, such as newer revisions of NanoPi R4S, do not
> provide an EEPROM chip containing a globally unique MAC address.
>
> Currently, this means that a randomly generated temporary MAC address
> may be generated each time the device is rebooted, leading to ARP cache
> issues and other confusing bugs.
>
> Since RK3399 CPUs provide a built-in unique serial number, we can
> reliably derive a locally MAC address from it by reading the
> corresponding bits from the non-secure efuse block.
>
> Port from uboot-rockchip 0c294d0, fix compilation issues and adjust
> coding style.
>
> rockchip: board: puma_rk3399: derive ethaddr from cpuid
> rockchip: board: puma_rk3399: add support for serial# and cpuid#
> rockchip: efuse: add (misc) driver for RK3399 non-secure efuse block
> via efuses
>
> Signed-off-by: Christian Kohlschütter 
> ---
>  board/rockchip/evb_rk3399/evb-rk3399.c | 120 +
>  configs/nanopi-r4s-rk3399_defconfig|   4 +
>  drivers/misc/Makefile  |   2 +-

There's already code in arch/arm/mach-rockchip/misc.c that does pretty much
the same thing.

IIRC all you need to do is enable MISC_INIT_R and ROCKCHIP_EFUSE
or ROCKCHIP_OTP.

ChenYu

Re: [PATCH] rockchip: rk3399: add ethaddr and serial# init, enable for R4S

[Chen-Yu Tsai]

On Tue, Sep 27, 2022 at 5:27 AM Christian Kohlschütter
 wrote:
>
> > On 26. Sep 2022, at 13:59, Chen-Yu Tsai  wrote:
> >
> > On Mon, Sep 26, 2022 at 7:53 PM Christian Kohlschütter
> >  wrote:
> >>
> >> Some RK3399 boards, such as newer revisions of NanoPi R4S, do not
> >> provide an EEPROM chip containing a globally unique MAC address.
> >>
> >> Currently, this means that a randomly generated temporary MAC address
> >> may be generated each time the device is rebooted, leading to ARP cache
> >> issues and other confusing bugs.
> >>
> >> Since RK3399 CPUs provide a built-in unique serial number, we can
> >> reliably derive a locally MAC address from it by reading the
> >> corresponding bits from the non-secure efuse block.
> >>
> >> Port from uboot-rockchip 0c294d0, fix compilation issues and adjust
> >> coding style.
> >>
> >> rockchip: board: puma_rk3399: derive ethaddr from cpuid
> >> rockchip: board: puma_rk3399: add support for serial# and cpuid#
> >> rockchip: efuse: add (misc) driver for RK3399 non-secure efuse block
> >> via efuses
> >>
> >> Signed-off-by: Christian Kohlschütter 
> >> ---
> >> board/rockchip/evb_rk3399/evb-rk3399.c | 120 +
> >> configs/nanopi-r4s-rk3399_defconfig|   4 +
> >> drivers/misc/Makefile  |   2 +-
> >
> > There's already code in arch/arm/mach-rockchip/misc.c that does pretty much
> > the same thing.
> >
> > IIRC all you need to do is enable MISC_INIT_R and ROCKCHIP_EFUSE
> > or ROCKCHIP_OTP.
> >
> > ChenYu
>
> Oh cool, thanks ChenYu!
>
> Is there a reason to not enable these options by default (at least for the 
> R4S)?

Personally I think they could be enabled by default for all RK3399 boards.

> Following up with "[PATCH] rockchip: rk3399: add ethaddr and serial# init, 
> enable for R4S", which enables these settings in 
> configs/nanopi-r4s-rk3399_defconfig.

This doesn't look any different from what you already sent.

ChenYu

Re: [linux-sunxi] [PATCH] sunxi: H616: Enable full 4GB of DRAM

[Chen-Yu Tsai]

Hi,

On Thu, Apr 29, 2021 at 6:53 AM Andre Przywara  wrote:
>
> The H616 is our first supported Allwinner SoC which goes beyond the 4GB
> address space "barrier", by having more than 32 address bits.

Nit: I wouldn't say it's the first. The A80 supports up to 8GB address
space with LPAE. It just never shipped with more than 2GB DRAM.


ChenYu

Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

[Chen-Yu Tsai]

On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> Hi Simon,
> 
> Thank you for the patch.
> 
> On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > Add a script which produces a Flat Image Tree (FIT), a single file
> > containing the built kernel and associated devicetree files.
> > Compression defaults to gzip which gives a good balance of size and
> > performance.
> > 
> > The files compress from about 86MB to 24MB using this approach.
> > 
> > The FIT can be used by bootloaders which support it, such as U-Boot
> > and Linuxboot. It permits automatic selection of the correct
> > devicetree, matching the compatible string of the running board with
> > the closest compatible string in the FIT. There is no need for
> > filenames or other workarounds.
> > 
> > Add a 'make image.fit' build target for arm64, as well. Use
> > FIT_COMPRESSION to select a different algorithm.
> > 
> > The FIT can be examined using 'dumpimage -l'.
> > 
> > This features requires pylibfdt (use 'pip install libfdt'). It also
> > requires compression utilities for the algorithm being used. Supported
> > compression options are the same as the Image.xxx files. For now there
> > is no way to change the compression other than by editing the rule for
> > $(obj)/image.fit
> > 
> > While FIT supports a ramdisk / initrd, no attempt is made to support
> > this here, since it must be built separately from the Linux build.
> 
> FIT images are very useful, so I think this is a very welcome addition
> to the kernel build system. It can get tricky though: given the
> versatile nature of FIT images, there can't be any
> one-size-fits-them-all solution to build them, and striking the right
> balance between what makes sense for the kernel and the features that
> users may request will probably lead to bikeshedding. As we all love
> bikeshedding, I thought I would start selfishly, with a personal use
> case :-) This isn't a yak-shaving request though, I don't see any reason
> to delay merging this series.
> 
> Have you envisioned building FIT images with a subset of DTBs, or adding
> DTBOs ? Both would be fairly trivial extensions to this script by
> extending the supported command line arguments. It would perhaps be more
> difficult to integrate in the kernel build system though. This leads me
> to a second question: would you consider merging extensions to this
> script if they are not used by the kernel build system, but meant for
> users who manually invoke the script ? More generally, is the script

We'd also be interested in some customization, though in a different way.
We imagine having a rule file that says X compatible string should map
to A base DTB, plus B and C DTBO for the configuration section. The base
DTB would carry all common elements of some device, while the DTBOs
carry all the possible second source components, like different display
panels or MIPI cameras for instance. This could drastically reduce the
size of FIT images in ChromeOS by deduplicating all the common stuff.

> meant to be used stand-alone as well, in which case its command line
> arguments need to remain backward-compatible, or do you see it as being
> internal to the kernel ?

[...]

ChenYu

Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

[Chen-Yu Tsai]

On Thu, Dec 7, 2023 at 11:38 PM Laurent Pinchart
 wrote:
>
> On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > Hi Simon,
> > >
> > > Thank you for the patch.
> > >
> > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > containing the built kernel and associated devicetree files.
> > > > Compression defaults to gzip which gives a good balance of size and
> > > > performance.
> > > >
> > > > The files compress from about 86MB to 24MB using this approach.
> > > >
> > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > and Linuxboot. It permits automatic selection of the correct
> > > > devicetree, matching the compatible string of the running board with
> > > > the closest compatible string in the FIT. There is no need for
> > > > filenames or other workarounds.
> > > >
> > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > FIT_COMPRESSION to select a different algorithm.
> > > >
> > > > The FIT can be examined using 'dumpimage -l'.
> > > >
> > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > requires compression utilities for the algorithm being used. Supported
> > > > compression options are the same as the Image.xxx files. For now there
> > > > is no way to change the compression other than by editing the rule for
> > > > $(obj)/image.fit
> > > >
> > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > this here, since it must be built separately from the Linux build.
> > >
> > > FIT images are very useful, so I think this is a very welcome addition
> > > to the kernel build system. It can get tricky though: given the
> > > versatile nature of FIT images, there can't be any
> > > one-size-fits-them-all solution to build them, and striking the right
> > > balance between what makes sense for the kernel and the features that
> > > users may request will probably lead to bikeshedding. As we all love
> > > bikeshedding, I thought I would start selfishly, with a personal use
> > > case :-) This isn't a yak-shaving request though, I don't see any reason
> > > to delay merging this series.
> > >
> > > Have you envisioned building FIT images with a subset of DTBs, or adding
> > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > extending the supported command line arguments. It would perhaps be more
> > > difficult to integrate in the kernel build system though. This leads me
> > > to a second question: would you consider merging extensions to this
> > > script if they are not used by the kernel build system, but meant for
> > > users who manually invoke the script ? More generally, is the script
> >
> > We'd also be interested in some customization, though in a different way.
> > We imagine having a rule file that says X compatible string should map
> > to A base DTB, plus B and C DTBO for the configuration section. The base
> > DTB would carry all common elements of some device, while the DTBOs
> > carry all the possible second source components, like different display
> > panels or MIPI cameras for instance. This could drastically reduce the
> > size of FIT images in ChromeOS by deduplicating all the common stuff.
>
> Do you envision the "mapping" compatible string mapping to a config
> section in the FIT image, that would bundle the base DTB and the DTBOs ?

That's exactly the idea. The mapping compatible string could be untied
from the base board's compatible string if needed (which we probably do).

So something like:

config {
config-1 {
compatible = "google,krane-sku0";
fdt = "krane-baseboard", "krane-sku0-overlay";
};
};

With "krane-sku0-overlay" being an overlay that holds the differences
between the SKUs, in this case the display panel and MIPI camera (not
upstreamed) that applies to SKU0 in particular.

Sorry for not giving a more concrete idea.


ChenYu

> > > meant to be used stand-alone as well, in which case its command line
> > > arguments need to remain backward-compatible, or do you see it as being
> > > internal to the kernel ?
> >
> > [...]
> >
> > ChenYu
>
> --
> Regards,
>
> Laurent Pinchart

Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

[Chen-Yu Tsai]

On Sun, Dec 10, 2023 at 1:31 AM Geert Uytterhoeven  wrote:
>
> Hi Laurent,
>
> On Sat, Dec 9, 2023 at 4:29 PM Laurent Pinchart
>  wrote:
> > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > > On Thu, Dec 7, 2023 at 11:38 PM Laurent Pinchart
> > >  wrote:
> > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > > > > containing the built kernel and associated devicetree files.
> > > > > > > Compression defaults to gzip which gives a good balance of size 
> > > > > > > and
> > > > > > > performance.
> > > > > > >
> > > > > > > The files compress from about 86MB to 24MB using this approach.
> > > > > > >
> > > > > > > The FIT can be used by bootloaders which support it, such as 
> > > > > > > U-Boot
> > > > > > > and Linuxboot. It permits automatic selection of the correct
> > > > > > > devicetree, matching the compatible string of the running board 
> > > > > > > with
> > > > > > > the closest compatible string in the FIT. There is no need for
> > > > > > > filenames or other workarounds.
> > > > > > >
> > > > > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > >
> > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > >
> > > > > > > This features requires pylibfdt (use 'pip install libfdt'). It 
> > > > > > > also
> > > > > > > requires compression utilities for the algorithm being used. 
> > > > > > > Supported
> > > > > > > compression options are the same as the Image.xxx files. For now 
> > > > > > > there
> > > > > > > is no way to change the compression other than by editing the 
> > > > > > > rule for
> > > > > > > $(obj)/image.fit
> > > > > > >
> > > > > > > While FIT supports a ramdisk / initrd, no attempt is made to 
> > > > > > > support
> > > > > > > this here, since it must be built separately from the Linux build.
> > > > > >
> > > > > > FIT images are very useful, so I think this is a very welcome 
> > > > > > addition
> > > > > > to the kernel build system. It can get tricky though: given the
> > > > > > versatile nature of FIT images, there can't be any
> > > > > > one-size-fits-them-all solution to build them, and striking the 
> > > > > > right
> > > > > > balance between what makes sense for the kernel and the features 
> > > > > > that
> > > > > > users may request will probably lead to bikeshedding. As we all love
> > > > > > bikeshedding, I thought I would start selfishly, with a personal use
> > > > > > case :-) This isn't a yak-shaving request though, I don't see any 
> > > > > > reason
> > > > > > to delay merging this series.
> > > > > >
> > > > > > Have you envisioned building FIT images with a subset of DTBs, or 
> > > > > > adding
> > > > > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > > > > extending the supported command line arguments. It would perhaps be 
> > > > > > more
> > > > > > difficult to integrate in the kernel build system though. This 
> > > > > > leads me
> > > > > > to a second question: would you consider merging extensions to this
> > > > > > script if they are not used by the kernel build system, but meant 
> > > > > > for
> > > > > > users who manually invoke the script ? More generally, is the script
> > > > >
> > > > > We'd also be interested in some customization, though in a different 
> > > > > way.
> > > > &

Re: [PATCH v3 3/3] configs: rockchip: imply OF_LIBFDT_OVERLAY for rk3308 and rk3328

[Chen-Yu Tsai]

On Wed, Jul 17, 2024 at 12:47 PM FUKAUMI Naoki  wrote:
>
> for rk3308, all defconfigs have CONFIG_OF_LIBFDT_OVERLAY=y, so enable it
> by default.
>
> for rk3328, any defconfig doesn't have it. but there is no strong reason
> not to enable it. at least it's required for ROCK Pi E.

I wonder if it makes sense to eventually move it up to ARCH_ROCKCHIP?

ChenYu

> Signed-off-by: FUKAUMI Naoki 
> ---
> Changes in v3:
> - add missing separator in commit message
> Changes in v2:
> - none
> ---
>  arch/arm/mach-rockchip/Kconfig | 2 ++
>  configs/evb-rk3308_defconfig   | 1 -
>  configs/roc-cc-rk3308_defconfig| 1 -
>  configs/rock-pi-s-rk3308_defconfig | 1 -
>  4 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
> index 661e7fd1c9..5f6a4dd24a 100644
> --- a/arch/arm/mach-rockchip/Kconfig
> +++ b/arch/arm/mach-rockchip/Kconfig
> @@ -166,6 +166,7 @@ config ROCKCHIP_RK3308
> imply LEGACY_IMAGE_FORMAT
> imply MISC
> imply MISC_INIT_R
> +   imply OF_LIBFDT_OVERLAY
> imply OF_UPSTREAM
> imply RNG_ROCKCHIP
> imply ROCKCHIP_COMMON_BOARD
> @@ -196,6 +197,7 @@ config ROCKCHIP_RK3328
> imply ARMV8_SET_SMPEN
> imply MISC
> imply MISC_INIT_R
> +   imply OF_LIBFDT_OVERLAY
> imply OF_LIVE
> imply OF_UPSTREAM
> imply PRE_CONSOLE_BUFFER
> diff --git a/configs/evb-rk3308_defconfig b/configs/evb-rk3308_defconfig
> index f4c2ea12ad..6d090dba30 100644
> --- a/configs/evb-rk3308_defconfig
> +++ b/configs/evb-rk3308_defconfig
> @@ -3,7 +3,6 @@ CONFIG_SKIP_LOWLEVEL_INIT=y
>  CONFIG_COUNTER_FREQUENCY=2400
>  CONFIG_ARCH_ROCKCHIP=y
>  CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3308-evb"
> -CONFIG_OF_LIBFDT_OVERLAY=y
>  CONFIG_DM_RESET=y
>  CONFIG_ROCKCHIP_RK3308=y
>  CONFIG_TARGET_EVB_RK3308=y
> diff --git a/configs/roc-cc-rk3308_defconfig b/configs/roc-cc-rk3308_defconfig
> index 862ea4301f..b1b59d9cb5 100644
> --- a/configs/roc-cc-rk3308_defconfig
> +++ b/configs/roc-cc-rk3308_defconfig
> @@ -4,7 +4,6 @@ CONFIG_COUNTER_FREQUENCY=2400
>  CONFIG_ARCH_ROCKCHIP=y
>  CONFIG_SPL_GPIO=y
>  CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3308-roc-cc"
> -CONFIG_OF_LIBFDT_OVERLAY=y
>  CONFIG_DM_RESET=y
>  CONFIG_ROCKCHIP_RK3308=y
>  CONFIG_TARGET_ROC_RK3308_CC=y
> diff --git a/configs/rock-pi-s-rk3308_defconfig 
> b/configs/rock-pi-s-rk3308_defconfig
> index c15ba3d8a4..e450a06180 100644
> --- a/configs/rock-pi-s-rk3308_defconfig
> +++ b/configs/rock-pi-s-rk3308_defconfig
> @@ -3,7 +3,6 @@ CONFIG_SKIP_LOWLEVEL_INIT=y
>  CONFIG_COUNTER_FREQUENCY=2400
>  CONFIG_ARCH_ROCKCHIP=y
>  CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3308-rock-pi-s"
> -CONFIG_OF_LIBFDT_OVERLAY=y
>  CONFIG_DM_RESET=y
>  CONFIG_ROCKCHIP_RK3308=y
>  CONFIG_TARGET_EVB_RK3308=y
> --
> 2.43.0
>

Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

[Chen-Yu Tsai]

On Fri, Dec 29, 2023 at 2:39 PM Simon Glass  wrote:
>
> Hi Masahiro,
>
> On Thu, Dec 14, 2023 at 7:34 AM Masahiro Yamada  wrote:
> >
> > On Thu, Dec 14, 2023 at 3:12 PM Masahiro Yamada  
> > wrote:
> > >
> > > On Thu, Dec 14, 2023 at 1:03 PM Chen-Yu Tsai  wrote:
> > > >
> > > > On Sun, Dec 10, 2023 at 1:31 AM Geert Uytterhoeven 
> > > >  wrote:
> > > > >
> > > > > Hi Laurent,
> > > > >
> > > > > On Sat, Dec 9, 2023 at 4:29 PM Laurent Pinchart
> > > > >  wrote:
> > > > > > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > > > > > > On Thu, Dec 7, 2023 at 11:38 PM Laurent Pinchart
> > > > > > >  wrote:
> > > > > > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > > > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart 
> > > > > > > > > wrote:
> > > > > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > > > > > > Add a script which produces a Flat Image Tree (FIT), a 
> > > > > > > > > > > single file
> > > > > > > > > > > containing the built kernel and associated devicetree 
> > > > > > > > > > > files.
> > > > > > > > > > > Compression defaults to gzip which gives a good balance 
> > > > > > > > > > > of size and
> > > > > > > > > > > performance.
> > > > > > > > > > >
> > > > > > > > > > > The files compress from about 86MB to 24MB using this 
> > > > > > > > > > > approach.
> > > > > > > > > > >
> > > > > > > > > > > The FIT can be used by bootloaders which support it, such 
> > > > > > > > > > > as U-Boot
> > > > > > > > > > > and Linuxboot. It permits automatic selection of the 
> > > > > > > > > > > correct
> > > > > > > > > > > devicetree, matching the compatible string of the running 
> > > > > > > > > > > board with
> > > > > > > > > > > the closest compatible string in the FIT. There is no 
> > > > > > > > > > > need for
> > > > > > > > > > > filenames or other workarounds.
> > > > > > > > > > >
> > > > > > > > > > > Add a 'make image.fit' build target for arm64, as well. 
> > > > > > > > > > > Use
> > > > > > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > > > > > >
> > > > > > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > > > > > >
> > > > > > > > > > > This features requires pylibfdt (use 'pip install 
> > > > > > > > > > > libfdt'). It also
> > > > > > > > > > > requires compression utilities for the algorithm being 
> > > > > > > > > > > used. Supported
> > > > > > > > > > > compression options are the same as the Image.xxx files. 
> > > > > > > > > > > For now there
> > > > > > > > > > > is no way to change the compression other than by editing 
> > > > > > > > > > > the rule for
> > > > > > > > > > > $(obj)/image.fit
> > > > > > > > > > >
> > > > > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made 
> > > > > > > > > > > to support
> > > > > > > > > > > this here, since it must be built separately from the 
> > > > > > > > > > > Linux build.
> > > > > > > > > >
> > > > > > > > > > FIT images are very useful, so I think this is a very 
> > > > > > > > > > welcome addition
> > > > > > > > > > to the kernel build system. It can get 

Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

[Chen-Yu Tsai]

On Tue, Jan 9, 2024 at 9:47 PM Masahiro Yamada  wrote:
>
> On Fri, Dec 29, 2023 at 3:39 PM Simon Glass  wrote:
> >
> > Hi Masahiro,
> >
> > On Thu, Dec 14, 2023 at 7:34 AM Masahiro Yamada  
> > wrote:
> > >
> > > On Thu, Dec 14, 2023 at 3:12 PM Masahiro Yamada  
> > > wrote:
> > > >
> > > > On Thu, Dec 14, 2023 at 1:03 PM Chen-Yu Tsai  wrote:
> > > > >
> > > > > On Sun, Dec 10, 2023 at 1:31 AM Geert Uytterhoeven 
> > > > >  wrote:
> > > > > >
> > > > > > Hi Laurent,
> > > > > >
> > > > > > On Sat, Dec 9, 2023 at 4:29 PM Laurent Pinchart
> > > > > >  wrote:
> > > > > > > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > > > > > > > On Thu, Dec 7, 2023 at 11:38 PM Laurent Pinchart
> > > > > > > >  wrote:
> > > > > > > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > > > > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart 
> > > > > > > > > > wrote:
> > > > > > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > Add a script which produces a Flat Image Tree (FIT), a 
> > > > > > > > > > > > single file
> > > > > > > > > > > > containing the built kernel and associated devicetree 
> > > > > > > > > > > > files.
> > > > > > > > > > > > Compression defaults to gzip which gives a good balance 
> > > > > > > > > > > > of size and
> > > > > > > > > > > > performance.
> > > > > > > > > > > >
> > > > > > > > > > > > The files compress from about 86MB to 24MB using this 
> > > > > > > > > > > > approach.
> > > > > > > > > > > >
> > > > > > > > > > > > The FIT can be used by bootloaders which support it, 
> > > > > > > > > > > > such as U-Boot
> > > > > > > > > > > > and Linuxboot. It permits automatic selection of the 
> > > > > > > > > > > > correct
> > > > > > > > > > > > devicetree, matching the compatible string of the 
> > > > > > > > > > > > running board with
> > > > > > > > > > > > the closest compatible string in the FIT. There is no 
> > > > > > > > > > > > need for
> > > > > > > > > > > > filenames or other workarounds.
> > > > > > > > > > > >
> > > > > > > > > > > > Add a 'make image.fit' build target for arm64, as well. 
> > > > > > > > > > > > Use
> > > > > > > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > > > > > > >
> > > > > > > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > > > > > > >
> > > > > > > > > > > > This features requires pylibfdt (use 'pip install 
> > > > > > > > > > > > libfdt'). It also
> > > > > > > > > > > > requires compression utilities for the algorithm being 
> > > > > > > > > > > > used. Supported
> > > > > > > > > > > > compression options are the same as the Image.xxx 
> > > > > > > > > > > > files. For now there
> > > > > > > > > > > > is no way to change the compression other than by 
> > > > > > > > > > > > editing the rule for
> > > > > > > > > > > > $(obj)/image.fit
> > > > > > > > > > > >
> > > > > > > > > > > > While FIT supports a ramdisk / initrd, no attempt is 
> > > > > > > > > > > > made to support
> > > > > > > > > > > >

Re: Proposal: FIT support for extension boards / overlays

[Chen-Yu Tsai]

On Tue, Dec 12, 2023 at 10:06 PM Simon Glass  wrote:
>
> Hi,
>
> The devicetree files for a board can be quite large, perhaps around
> 60KB. To boot on any supported board, many of them need to be
> provided, typically hundreds.
>
> All boards for a particular SoC share common parts.  It would be
> helpful to use overlays for common pieces, to reduce the overall size.
>
> Some boards have extension add-ons which have their own devicetree
> overlays. It would be helpful to know which ones should be applied for
> a particular extension.
>
> I propose implementing extensions in FIT. This has a new '/extensions'
> node, so you can specify what extensions are available for each FIT
> configuration.
>
> For example:
>
> / {
>   images {
> kernel {
>   // common kernel
> };
>
> fdt-1 {
>   // FDT for board1
> };
>
> fdto-1 {
>   // FDT overlay
> };
>
> fdto-2 {
>   // FDT overlay
> };
>
> fdto-3 {
>   // FDT overlay
> };
>   };
>
>   configurations {
> conf-1 {
> compatible = ...
> fdt = "fdt-1";
> extensions = "ext1", "ext-2";
> };
>   };
>
>   extensions {
> ext-1 {
> fdto = "fdto-1";   // FDT overlay for this 'cape' or 'hat'
> kernel = "kernel-1";
> compatible = "vendor,combined-device1";

I think the example would be a bit better if the extension compatibles
were something like "vendor,device-X-feature-Y", so as not to be confused
with device-specific compatibles for the configurations.

> extensions = "ext-3";

I assume this means "existence of ext-1 makes ext-3 a valid option"?

I think a valid example would come in the form of:
- ext-1 as a M.2 E-key hat, and
- ext-3 as a WiFi/BT combo adapter for the M.2 slot, with BT UART and/or
  GPIOs described

> };
>
> ext-2 {
> fdto = "fdto-2";   // fdt overlay for this 'cape'
> compatible = "vendor,device2";
> };
>
> ext-3 {
> fdto = "fdto-3";
> compatible = "vendor,device3";
> };
>   };
> };
>
> So FIT configurations have a list of supported extensions. The
> extensions are hierarchical so that you can have ext-1 which can
> optionally have ext-2 as well. This allows boards to share a common
> SoC to add in overlays as needed by their board. It also allows common
> 'capes' or 'hats' to be specified only once and used by a group of
> boards which share the same interface.
>
> Within U-Boot, extensions actually present are declared by a sysinfo
> driver for the board, with new methods:
>
> get_compat() - determine the compatible strings for the current platform
> get_ext() - get a list of compatible strings for extensions which are
> actually present
>
> The extension compatible-strings are used to select the correct things
> from the FIT, apply the overlays and produce the final DT.
>
> To make this simpler for the common case (without extensions), we can
> allow multiple FDT images for a configuration, with the first one
> being the base SoC .dtb and the others being the .dtbo overlay(s) for
> the board:
>
> confi-1 {
> compatible = ...
> fdt = "fdt-1", "fdto-1";
> };

I thought this was already supported? At least that is what the FIT image
spec says:

Unit name of the corresponding fdt blob (component image node of a
"fdt type"). Additional fdt overlay nodes can be supplied which
signify that the resulting device tree blob is generated by the
first base fdt blob with all subsequent overlays applied.

> Comments welcome.

Very happy to see this. This could help cut down the DT duplication for
some of the ARM Chromebooks.


Thanks
ChenYu

Re: Proposal: FIT support for extension boards / overlays

[Chen-Yu Tsai]

On Thu, Dec 28, 2023 at 1:49 AM Simon Glass  wrote:
>
> Hi Heinrich,
>
> On Tue, Dec 12, 2023 at 3:43 PM Heinrich Schuchardt  
> wrote:
> >
> > On 12.12.23 15:05, Simon Glass wrote:
> > > Hi,
> > >
> > > The devicetree files for a board can be quite large, perhaps around
> > > 60KB. To boot on any supported board, many of them need to be
> > > provided, typically hundreds.
> > >
> > > All boards for a particular SoC share common parts.  It would be
> > > helpful to use overlays for common pieces, to reduce the overall size.
> > >
> > > Some boards have extension add-ons which have their own devicetree
> > > overlays. It would be helpful to know which ones should be applied for
> > > a particular extension.
> > >
> > > I propose implementing extensions in FIT. This has a new '/extensions'
> > > node, so you can specify what extensions are available for each FIT
> > > configuration.
> > >
> > > For example:
> > >
> > > / {
> > >images {
> > >  kernel {
> > >// common kernel
> > >  };
> > >
> > >  fdt-1 {
> > >// FDT for board1
> > >  };
> > >
> > >  fdto-1 {
> > >// FDT overlay
> > >  };
> > >
> > >  fdto-2 {
> > >// FDT overlay
> > >  };
> > >
> > >  fdto-3 {
> > >// FDT overlay
> > >  };
> > >};
> > >
> > >configurations {
> > >  conf-1 {
> > >  compatible = ...
> > >  fdt = "fdt-1";
> > >  extensions = "ext1", "ext-2";
> >
> > Shouldn't there be braces around the item list?
>
> I don't think so.
>
> >
> > How do you specify optional and required but otherwise unrelated
> > extensions for a configuration?
>
> Do we actually need to know which extensions are required or optional?
> Do you have an example?

If an extension is required for a device, then it wouldn't be an extension
per se. The referenced DT overlay should be directly tied to the device
compatible through the configuration node.

If say "ext-3" depends on "ext-1" (assuming that is one definition of
"required"), then based on the syntax I believe "ext-3" should only
be listed in the "extensions" property under "ext-1", and not the
base configuration?

> > >  };
> > >};
> > >
> > >extensions {
> > >  ext-1 {
> > >  fdto = "fdto-1";   // FDT overlay for this 'cape' or 'hat'
> > >  kernel = "kernel-1";
> > >  compatible = "vendor,combined-device1";
> > >  extensions = "ext-3";
> > >  };
> > >
> > >  ext-2 {
> > >  fdto = "fdto-2";   // fdt overlay for this 'cape'
> > >  compatible = "vendor,device2";
> > >  };
> > >
> > >  ext-3 {
> > >  fdto = "fdto-3";
> > >  compatible = "vendor,device3";
> > >  };
> > >};
> > > };
> > >
> > > So FIT configurations have a list of supported extensions. The
> > > extensions are hierarchical so that you can have ext-1 which can
> > > optionally have ext-2 as well. This allows boards to share a common
> >
> > ext2 seems not to be related to ext-3. Do you mean ext-3 optionally
> > extending ext-1? How would you specify that ext-n is required for ext-m
> > to work?
>
> Yes, I mean "optionally extending ext2". Again, I don't consider
> required extensions here.

See above for my take on extension dependencies.

ChenYu

> > The sequence of applying overlays may make a difference. I cannot see
> > that your current suggestion defines a sequence in which the overlays
> > are applied.
> >
> > > SoC to add in overlays as needed by their board. It also allows common
> > > 'capes' or 'hats' to be specified only once and used by a group of
> > > boards which share the same interface.
> > >
> > > Within U-Boot, extensions actually present are declared by a sysinfo
> > > driver for the board, with new methods:
> > >
> > > get_compat() - determine the compatible strings for the current platform
> > > get_ext() - get a list of compatible strings for extensions which are
> > > actually present
> >
> > Do you expect U-Boot to have code that injects device-tree fragments
> > with a compatible string into the control FDT after discovering add-ons?
>
> Yes, that's right, by applying overlays.
>
> >
> > Why can't we simply write the compatible constraint into the overlay
> > definition (fdto-#) and enumerate the overlays in the configuration?
>
> Yes, that is the example quoted below.
>
> >
> > On some busses detection is problematic. Two alternative add-ons may use
> > the same SPI address but need different FDT overlays.
>
> If there is no way to detect the extension, then it cannot work anyway, right?
>
> BTW I am not suggesting that the bus is used for detection, although I
> suppose this is possible. More likely there are GPIOs which can be
> decoded to indicate the extension, or perhaps an I2C EEPROM.
>
>
> >
> > Best regards
> >
> > Heinrich
> >
> >
> > >
> > > The extension compatible-strings are used to select the correct things
> > > from the FIT, apply the overlays and produce the final DT.
> > >
> > > To

Re: [PATCH] sunxi: spl: h616: fix booting from high MMC offset

[Chen-Yu Tsai]

On Fri, May 10, 2024 at 7:13 AM Andre Przywara  wrote:
>
> The BootROM in the Allwinner H616 tries to load the initial boot code
> from sector 16 (8KB) of an SD card or eMMC device, but also looks at
> sector 512 (256KB). This helps with GPT formatted cards.
> A "high" boot offset is also used on previous SoCs, but it's sector 256
> (128KB) there instead.
>
> Extend the existing offset calculation code to consider the different
> sector offset when running on an H616 SoC. This allows to load U-Boot
> on any H616 device when the SPL is not located at 8KB.
>
> Signed-off-by: Andre Przywara 

Make sense.

Reviewed-by: Chen-Yu Tsai 

Re: [PATCH 04/15] rockchip: rk3328-roc-cc: Update defconfig

[Chen-Yu Tsai]

(Resend from subscribed address.)

On Wed, Feb 7, 2024 at 8:04 AM Jonas Karlman  wrote:
>
> Update defconfig for rk3328-roc-cc with new defaults.
>
> Remove the SPL_DRIVERS_MISC=y option, no misc driver is used in SPL.
>
> Add CONFIG_SPL_FIT_SIGNATURE=y to let SPL verify an auto generated hash
> of FIT images. This help indicate if there is an issue loading any of
> the images to DRAM or SRAM. Also add LEGACY_IMAGE_FORMAT=y to keep
> support for scripts.
>
> Add ROCKCHIP_EFUSE=y and remove NET_RANDOM_ETHADDR=y, ethaddr and
> eth1addr is set based on cpuid read from eFUSE.

I wonder if it would make sense to enable ROCKCHIP_EFUSE or ROCKCHIP_OTP
for the respective SoCs by default, either with "imply" under the SoC
Kconfig options, or "default if XXX" under the driver Kconfig options?
Not sure which is preferred.

Same goes for CONFIG_MISC_INIT_R for actually generating the serial number
and MAC addresses from the efuse/OTP.

At least for RK3566 and RK3588 these options are implied.


ChenYu

> Add SPL_DM_SEQ_ALIAS=y option to use alias sequence number in SPL.
>
> Add DM_ETH_PHY=y, PHY_MOTORCOMM=y and PHY_REALTEK=y to support common
> ethernet PHYs.
>
> Add RNG_ROCKCHIP=y and DM_RNG=y options to support the onboard random
> generator.
>
> Also add missing device tree file to MAINTAINERS and add myself as a
> reviewer for this board.
>
> Signed-off-by: Jonas Karlman 
> ---
>  board/rockchip/evb_rk3328/MAINTAINERS | 2 ++
>  configs/roc-cc-rk3328_defconfig   | 9 +++--
>  doc/board/rockchip/rockchip.rst   | 2 +-
>  3 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/board/rockchip/evb_rk3328/MAINTAINERS 
> b/board/rockchip/evb_rk3328/MAINTAINERS
> index 419bc8ded375..09488eaf083f 100644
> --- a/board/rockchip/evb_rk3328/MAINTAINERS
> +++ b/board/rockchip/evb_rk3328/MAINTAINERS
> @@ -41,8 +41,10 @@ F:  
> arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
>  ROC-RK3328-CC
>  M:  Loic Devulder 
>  M:  Chen-Yu Tsai 
> +R:  Jonas Karlman 
>  S:  Maintained
>  F:  configs/roc-cc-rk3328_defconfig
> +F:  arch/arm/dts/rk3328-roc-cc.dts
>  F:  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
>
>  ROCK64-RK3328
> diff --git a/configs/roc-cc-rk3328_defconfig b/configs/roc-cc-rk3328_defconfig
> index 4ac3c9403b02..7d81a715ef25 100644
> --- a/configs/roc-cc-rk3328_defconfig
> +++ b/configs/roc-cc-rk3328_defconfig
> @@ -15,7 +15,6 @@ CONFIG_ROCKCHIP_RK3328=y
>  CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
>  CONFIG_TPL_LIBCOMMON_SUPPORT=y
>  CONFIG_TPL_LIBGENERIC_SUPPORT=y
> -CONFIG_SPL_DRIVERS_MISC=y
>  CONFIG_SPL_STACK_R_ADDR=0x60
>  CONFIG_SPL_STACK=0x40
>  CONFIG_TPL_SYS_MALLOC_F_LEN=0x800
> @@ -26,7 +25,9 @@ CONFIG_DEBUG_UART=y
>  # CONFIG_ANDROID_BOOT_IMAGE is not set
>  CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
> +CONFIG_SPL_FIT_SIGNATURE=y
>  CONFIG_SPL_LOAD_FIT=y
> +CONFIG_LEGACY_IMAGE_FORMAT=y
>  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-roc-cc.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
> @@ -58,8 +59,8 @@ CONFIG_TPL_OF_PLATDATA=y
>  CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>  CONFIG_SYS_MMC_ENV_DEV=1
> -CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_TPL_DM=y
> +CONFIG_SPL_DM_SEQ_ALIAS=y
>  CONFIG_REGMAP=y
>  CONFIG_SPL_REGMAP=y
>  CONFIG_TPL_REGMAP=y
> @@ -73,9 +74,11 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
>  CONFIG_ROCKCHIP_GPIO=y
>  CONFIG_SYS_I2C_ROCKCHIP=y
>  CONFIG_MISC=y
> +CONFIG_ROCKCHIP_EFUSE=y
>  CONFIG_MMC_DW=y
>  CONFIG_MMC_DW_ROCKCHIP=y
>  CONFIG_PHY_REALTEK=y
> +CONFIG_DM_ETH_PHY=y
>  CONFIG_PHY_GIGE=y
>  CONFIG_ETH_DESIGNWARE=y
>  CONFIG_GMAC_ROCKCHIP=y
> @@ -95,6 +98,8 @@ CONFIG_PWM_ROCKCHIP=y
>  CONFIG_RAM=y
>  CONFIG_SPL_RAM=y
>  CONFIG_TPL_RAM=y
> +CONFIG_DM_RNG=y
> +CONFIG_RNG_ROCKCHIP=y
>  CONFIG_BAUDRATE=150
>  CONFIG_DEBUG_UART_SHIFT=2
>  CONFIG_SYS_NS16550_MEM32=y
> diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
> index de2195deadca..99f48b6d6fa5 100644
> --- a/doc/board/rockchip/rockchip.rst
> +++ b/doc/board/rockchip/rockchip.rst
> @@ -60,8 +60,8 @@ List of mainline supported Rockchip boards:
>   - ODROID-GO Advance (odroid-go2)
>  * rk3328
>   - Rockchip Evb-RK3328 (evb-rk3328)
> + - Firefly ROC-RK3328-CC (roc-cc-rk3328)
>   - Pine64 Rock64 (rock64-rk3328)
> - - Firefly-RK3328 (roc-cc-rk3328)
>   - Radxa Rockpi E (rock-pi-e-rk3328)
>  * rk3368
>   - GeekBox (geekbox)
> --
> 2.43.0
>

Re: [PATCH 04/15] rockchip: rk3328-roc-cc: Update defconfig

[Chen-Yu Tsai]

On Wed, Feb 7, 2024 at 8:04 AM Jonas Karlman  wrote:
>
> Update defconfig for rk3328-roc-cc with new defaults.
>
> Remove the SPL_DRIVERS_MISC=y option, no misc driver is used in SPL.
>
> Add CONFIG_SPL_FIT_SIGNATURE=y to let SPL verify an auto generated hash
> of FIT images. This help indicate if there is an issue loading any of
> the images to DRAM or SRAM. Also add LEGACY_IMAGE_FORMAT=y to keep
> support for scripts.
>
> Add ROCKCHIP_EFUSE=y and remove NET_RANDOM_ETHADDR=y, ethaddr and
> eth1addr is set based on cpuid read from eFUSE.

I wonder if it would make sense to enable ROCKCHIP_EFUSE or ROCKCHIP_OTP
for the respective SoCs by default, either with "imply" under the SoC
Kconfig options, or "default if XXX" under the driver Kconfig options?
Not sure which is preferred.

Same goes for CONFIG_MISC_INIT_R for actually generating the serial number
and MAC addresses from the efuse/OTP.

At least for RK3566 and RK3588 we are implying these options.


ChenYu

> Add SPL_DM_SEQ_ALIAS=y option to use alias sequence number in SPL.
>
> Add DM_ETH_PHY=y, PHY_MOTORCOMM=y and PHY_REALTEK=y to support common
> ethernet PHYs.
>
> Add RNG_ROCKCHIP=y and DM_RNG=y options to support the onboard random
> generator.
>
> Also add missing device tree file to MAINTAINERS and add myself as a
> reviewer for this board.
>
> Signed-off-by: Jonas Karlman 
> ---
>  board/rockchip/evb_rk3328/MAINTAINERS | 2 ++
>  configs/roc-cc-rk3328_defconfig   | 9 +++--
>  doc/board/rockchip/rockchip.rst   | 2 +-
>  3 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/board/rockchip/evb_rk3328/MAINTAINERS 
> b/board/rockchip/evb_rk3328/MAINTAINERS
> index 419bc8ded375..09488eaf083f 100644
> --- a/board/rockchip/evb_rk3328/MAINTAINERS
> +++ b/board/rockchip/evb_rk3328/MAINTAINERS
> @@ -41,8 +41,10 @@ F:  
> arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
>  ROC-RK3328-CC
>  M:  Loic Devulder 
>  M:  Chen-Yu Tsai 
> +R:  Jonas Karlman 
>  S:  Maintained
>  F:  configs/roc-cc-rk3328_defconfig
> +F:  arch/arm/dts/rk3328-roc-cc.dts
>  F:  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
>
>  ROCK64-RK3328
> diff --git a/configs/roc-cc-rk3328_defconfig b/configs/roc-cc-rk3328_defconfig
> index 4ac3c9403b02..7d81a715ef25 100644
> --- a/configs/roc-cc-rk3328_defconfig
> +++ b/configs/roc-cc-rk3328_defconfig
> @@ -15,7 +15,6 @@ CONFIG_ROCKCHIP_RK3328=y
>  CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
>  CONFIG_TPL_LIBCOMMON_SUPPORT=y
>  CONFIG_TPL_LIBGENERIC_SUPPORT=y
> -CONFIG_SPL_DRIVERS_MISC=y
>  CONFIG_SPL_STACK_R_ADDR=0x60
>  CONFIG_SPL_STACK=0x40
>  CONFIG_TPL_SYS_MALLOC_F_LEN=0x800
> @@ -26,7 +25,9 @@ CONFIG_DEBUG_UART=y
>  # CONFIG_ANDROID_BOOT_IMAGE is not set
>  CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
> +CONFIG_SPL_FIT_SIGNATURE=y
>  CONFIG_SPL_LOAD_FIT=y
> +CONFIG_LEGACY_IMAGE_FORMAT=y
>  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-roc-cc.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
> @@ -58,8 +59,8 @@ CONFIG_TPL_OF_PLATDATA=y
>  CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>  CONFIG_SYS_MMC_ENV_DEV=1
> -CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_TPL_DM=y
> +CONFIG_SPL_DM_SEQ_ALIAS=y
>  CONFIG_REGMAP=y
>  CONFIG_SPL_REGMAP=y
>  CONFIG_TPL_REGMAP=y
> @@ -73,9 +74,11 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
>  CONFIG_ROCKCHIP_GPIO=y
>  CONFIG_SYS_I2C_ROCKCHIP=y
>  CONFIG_MISC=y
> +CONFIG_ROCKCHIP_EFUSE=y
>  CONFIG_MMC_DW=y
>  CONFIG_MMC_DW_ROCKCHIP=y
>  CONFIG_PHY_REALTEK=y
> +CONFIG_DM_ETH_PHY=y
>  CONFIG_PHY_GIGE=y
>  CONFIG_ETH_DESIGNWARE=y
>  CONFIG_GMAC_ROCKCHIP=y
> @@ -95,6 +98,8 @@ CONFIG_PWM_ROCKCHIP=y
>  CONFIG_RAM=y
>  CONFIG_SPL_RAM=y
>  CONFIG_TPL_RAM=y
> +CONFIG_DM_RNG=y
> +CONFIG_RNG_ROCKCHIP=y
>  CONFIG_BAUDRATE=150
>  CONFIG_DEBUG_UART_SHIFT=2
>  CONFIG_SYS_NS16550_MEM32=y
> diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
> index de2195deadca..99f48b6d6fa5 100644
> --- a/doc/board/rockchip/rockchip.rst
> +++ b/doc/board/rockchip/rockchip.rst
> @@ -60,8 +60,8 @@ List of mainline supported Rockchip boards:
>   - ODROID-GO Advance (odroid-go2)
>  * rk3328
>   - Rockchip Evb-RK3328 (evb-rk3328)
> + - Firefly ROC-RK3328-CC (roc-cc-rk3328)
>   - Pine64 Rock64 (rock64-rk3328)
> - - Firefly-RK3328 (roc-cc-rk3328)
>   - Radxa Rockpi E (rock-pi-e-rk3328)
>  * rk3368
>   - GeekBox (geekbox)
> --
> 2.43.0
>

[PATCH 0/4] rockchip: Read cpuid and generate MAC address from efuse for RK3328 and RK3399

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Hi folks,

This series enables ROCKCHIP_EFUSE and MISC_INIT_R by default for RK3328
and RK3399 so that the cpuid is read from the efuse and used to generate
a serial number and MAC addresses for all boards.

This stacks on top of the recent defconfig update series [1] from Jonas.

[1] https://lore.kernel.org/u-boot/20240207000301.3270722-1-jo...@kwiboo.se/


Chen-Yu Tsai (4):
  rockchip: rk3328: Read cpuid and generate MAC address from efuse
  rockchip: rk3399: Read cpuid and generate MAC address from efuse
  rockchip: rk3328: regenerate defconfigs
  rockchip: rk3399: regenerate defconfigs

 arch/arm/mach-rockchip/Kconfig| 4 
 configs/chromebook_bob_defconfig  | 2 --
 configs/chromebook_kevin_defconfig| 2 --
 configs/evb-rk3328_defconfig  | 2 --
 configs/firefly-rk3399_defconfig  | 2 --
 configs/nanopi-r2c-plus-rk3328_defconfig  | 2 --
 configs/nanopi-r2c-rk3328_defconfig   | 2 --
 configs/nanopi-r2s-rk3328_defconfig   | 2 --
 configs/nanopi-r4s-rk3399_defconfig   | 2 --
 configs/orangepi-r1-plus-lts-rk3328_defconfig | 2 --
 configs/orangepi-r1-plus-rk3328_defconfig | 2 --
 configs/pinebook-pro-rk3399_defconfig | 2 --
 configs/pinephone-pro-rk3399_defconfig| 2 --
 configs/puma-rk3399_defconfig | 2 --
 configs/roc-cc-rk3328_defconfig   | 2 --
 configs/roc-pc-mezzanine-rk3399_defconfig | 2 --
 configs/roc-pc-rk3399_defconfig   | 2 --
 configs/rock-4c-plus-rk3399_defconfig | 3 ---
 configs/rock-4se-rk3399_defconfig | 3 ---
 configs/rock-pi-4-rk3399_defconfig| 3 ---
 configs/rock-pi-4c-rk3399_defconfig   | 3 ---
 configs/rock-pi-e-rk3328_defconfig| 2 --
 configs/rock-pi-n10-rk3399pro_defconfig   | 1 -
 configs/rock64-rk3328_defconfig   | 2 --
 configs/rock960-rk3399_defconfig  | 1 -
 configs/rockpro64-rk3399_defconfig| 2 --
 26 files changed, 4 insertions(+), 52 deletions(-)

-- 
2.39.2

[PATCH 1/4] rockchip: rk3328: Read cpuid and generate MAC address from efuse

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The rockchip-efuse driver supports the efuse found on RK3328. This
hardware block is part of the SoC and contains the CPUID, which can
be used to generate stable serial numbers and MAC addresses.

Enable the driver and reading cpuid by default for RK3328.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/mach-rockchip/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 1bc7ee904275..20670fb57376 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -189,6 +189,8 @@ config ROCKCHIP_RK3328
select ENABLE_ARM_SOC_BOOT0_HOOK
select DEBUG_UART_BOARD_INIT
select SYS_NS16550
+   imply ROCKCHIP_EFUSE
+   imply MISC_INIT_R
help
  The Rockchip RK3328 is a ARM-based SoC with a quad-core Cortex-A53.
  including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two
-- 
2.39.2

[PATCH 2/4] rockchip: rk3399: Read cpuid and generate MAC address from efuse

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The rockchip-efuse driver supports the efuse found on RK3399. This
hardware block is part of the SoC and contains the CPUID, which can
be used to generate stable serial numbers and MAC addresses.

Enable the driver and reading cpuid by default for RK3399.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/mach-rockchip/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 20670fb57376..2558d956b8c6 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -269,6 +269,8 @@ config ROCKCHIP_RK3399
imply SYS_BOOTCOUNT_SINGLEWORD if BOOTCOUNT_LIMIT
imply BOOTSTD_FULL
imply CMD_BOOTCOUNT if BOOTCOUNT_LIMIT
+   imply ROCKCHIP_EFUSE
+   imply MISC_INIT_R
help
  The Rockchip RK3399 is a ARM-based SoC with a dual-core Cortex-A72
  and quad-core Cortex-A53.
-- 
2.39.2

[PATCH 3/4] rockchip: rk3328: regenerate defconfigs

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Regenerate RK3328 defconfigs after adding imply statements.

Signed-off-by: Chen-Yu Tsai 
---
 configs/evb-rk3328_defconfig  | 2 --
 configs/nanopi-r2c-plus-rk3328_defconfig  | 2 --
 configs/nanopi-r2c-rk3328_defconfig   | 2 --
 configs/nanopi-r2s-rk3328_defconfig   | 2 --
 configs/orangepi-r1-plus-lts-rk3328_defconfig | 2 --
 configs/orangepi-r1-plus-rk3328_defconfig | 2 --
 configs/roc-cc-rk3328_defconfig   | 2 --
 configs/rock-pi-e-rk3328_defconfig| 2 --
 configs/rock64-rk3328_defconfig   | 2 --
 9 files changed, 18 deletions(-)

diff --git a/configs/evb-rk3328_defconfig b/configs/evb-rk3328_defconfig
index 995bfd0558b1..004cbd33e80a 100644
--- a/configs/evb-rk3328_defconfig
+++ b/configs/evb-rk3328_defconfig
@@ -30,7 +30,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-evb.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -71,7 +70,6 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/nanopi-r2c-plus-rk3328_defconfig 
b/configs/nanopi-r2c-plus-rk3328_defconfig
index 1cb0ed855398..2f0d253b4b7c 100644
--- a/configs/nanopi-r2c-plus-rk3328_defconfig
+++ b/configs/nanopi-r2c-plus-rk3328_defconfig
@@ -31,7 +31,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-nanopi-r2c-plus.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -73,7 +72,6 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/nanopi-r2c-rk3328_defconfig 
b/configs/nanopi-r2c-rk3328_defconfig
index 59801328deda..ca13eb873a72 100644
--- a/configs/nanopi-r2c-rk3328_defconfig
+++ b/configs/nanopi-r2c-rk3328_defconfig
@@ -31,7 +31,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-nanopi-r2c.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -73,7 +72,6 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/nanopi-r2s-rk3328_defconfig 
b/configs/nanopi-r2s-rk3328_defconfig
index 61914b1650d2..619707436130 100644
--- a/configs/nanopi-r2s-rk3328_defconfig
+++ b/configs/nanopi-r2s-rk3328_defconfig
@@ -31,7 +31,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-nanopi-r2s.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -73,7 +72,6 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/orangepi-r1-plus-lts-rk3328_defconfig 
b/configs/orangepi-r1-plus-lts-rk3328_defconfig
index 968110c8cd6f..8e9a9411a763 100644
--- a/configs/orangepi-r1-plus-lts-rk3328_defconfig
+++ b/configs/orangepi-r1-plus-lts-rk3328_defconfig
@@ -34,7 +34,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-orangepi-r1-plus-lts.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -78,7 +77,6 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_SPI_FLASH_SFDP_SUPPORT=y
diff --git a/configs/orangepi-r1-plus-rk3328_defconfig 
b/configs/orangepi-r1-plus-rk3328_defconfig
index 7038f09f202c..240fcdeb221f 100644
--- a/configs/orangepi-r1-plus-rk3328_defconfig
+++ b/configs/orangepi-r1-plus-rk3328_defconfig
@@ -34,7 +34,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-orangepi-r1-plus.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -78,7 +77,6 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=

[PATCH 4/4] rockchip: rk3399: regenerate defconfigs

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Regenerate RK3399 defconfigs after adding imply statements.

Signed-off-by: Chen-Yu Tsai 
---
 configs/chromebook_bob_defconfig  | 2 --
 configs/chromebook_kevin_defconfig| 2 --
 configs/firefly-rk3399_defconfig  | 2 --
 configs/nanopi-r4s-rk3399_defconfig   | 2 --
 configs/pinebook-pro-rk3399_defconfig | 2 --
 configs/pinephone-pro-rk3399_defconfig| 2 --
 configs/puma-rk3399_defconfig | 2 --
 configs/roc-pc-mezzanine-rk3399_defconfig | 2 --
 configs/roc-pc-rk3399_defconfig   | 2 --
 configs/rock-4c-plus-rk3399_defconfig | 3 ---
 configs/rock-4se-rk3399_defconfig | 3 ---
 configs/rock-pi-4-rk3399_defconfig| 3 ---
 configs/rock-pi-4c-rk3399_defconfig   | 3 ---
 configs/rock-pi-n10-rk3399pro_defconfig   | 1 -
 configs/rock960-rk3399_defconfig  | 1 -
 configs/rockpro64-rk3399_defconfig| 2 --
 16 files changed, 34 deletions(-)

diff --git a/configs/chromebook_bob_defconfig b/configs/chromebook_bob_defconfig
index b5a5ae737e52..bffa0d33b75c 100644
--- a/configs/chromebook_bob_defconfig
+++ b/configs/chromebook_bob_defconfig
@@ -27,7 +27,6 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-bob.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_BOARD_EARLY_INIT_R=y
-CONFIG_MISC_INIT_R=y
 CONFIG_BLOBLIST=y
 CONFIG_BLOBLIST_ADDR=0x10
 CONFIG_BLOBLIST_SIZE=0x1000
@@ -68,7 +67,6 @@ CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_I2C_MUX=y
 CONFIG_CROS_EC_KEYB=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_CROS_EC=y
 CONFIG_CROS_EC_SPI=y
 CONFIG_PWRSEQ=y
diff --git a/configs/chromebook_kevin_defconfig 
b/configs/chromebook_kevin_defconfig
index 20913d2cf0fe..e14fc358c504 100644
--- a/configs/chromebook_kevin_defconfig
+++ b/configs/chromebook_kevin_defconfig
@@ -28,7 +28,6 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-kevin.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_BOARD_EARLY_INIT_R=y
-CONFIG_MISC_INIT_R=y
 CONFIG_BLOBLIST=y
 CONFIG_BLOBLIST_ADDR=0x10
 CONFIG_BLOBLIST_SIZE=0x1000
@@ -69,7 +68,6 @@ CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_I2C_MUX=y
 CONFIG_CROS_EC_KEYB=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_CROS_EC=y
 CONFIG_CROS_EC_SPI=y
 CONFIG_PWRSEQ=y
diff --git a/configs/firefly-rk3399_defconfig b/configs/firefly-rk3399_defconfig
index b7c8e95b7b89..b01b1a327896 100644
--- a/configs/firefly-rk3399_defconfig
+++ b/configs/firefly-rk3399_defconfig
@@ -20,7 +20,6 @@ CONFIG_PCI=y
 CONFIG_DEBUG_UART=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-firefly.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x2e000
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -46,7 +45,6 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_MMC_SDHCI=y
diff --git a/configs/nanopi-r4s-rk3399_defconfig 
b/configs/nanopi-r4s-rk3399_defconfig
index cacaab14d21f..18a1e68aa049 100644
--- a/configs/nanopi-r4s-rk3399_defconfig
+++ b/configs/nanopi-r4s-rk3399_defconfig
@@ -17,7 +17,6 @@ CONFIG_SYS_LOAD_ADDR=0x800800
 CONFIG_DEBUG_UART=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-nanopi-r4s.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x2e000
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -42,7 +41,6 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_ROCKCHIP_OTP=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
diff --git a/configs/pinebook-pro-rk3399_defconfig 
b/configs/pinebook-pro-rk3399_defconfig
index de357415fbe4..6b83daf07945 100644
--- a/configs/pinebook-pro-rk3399_defconfig
+++ b/configs/pinebook-pro-rk3399_defconfig
@@ -26,7 +26,6 @@ CONFIG_BOOTDELAY=3
 CONFIG_USE_PREBOOT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-pinebook-pro.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -61,7 +60,6 @@ CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_LED=y
 CONFIG_LED_GPIO=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_IO_VOLTAGE=y
 CONFIG_SPL_MMC_IO_VOLTAGE=y
 CONFIG_MMC_UHS_SUPPORT=y
diff --git a/configs/pinephone-pro-rk3399_defconfig 
b/configs/pinephone-pro-rk3399_defconfig
index d08224fe536b..96316c4b303f 100644
--- a/configs/pinephone-pro-rk3399_defconfig
+++ b/configs/pinephone-pro-rk3399_defconfig
@@ -25,7 +25,6 @@ CONFIG_BOOTDELAY=3
 CONFIG_USE_PREBOOT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-pinephone-pro.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -60,7 +59,6 @@ CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_LED=y
 CONFIG_LED_GPIO=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=

Re: [PATCH 4/4] rockchip: rk3399: regenerate defconfigs

[Chen-Yu Tsai]

On Sun, Feb 11, 2024 at 3:49 AM Jonas Karlman  wrote:
>
> Hi Chen-Yu,
>
> On 2024-02-10 07:32, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai 
> >
> > Regenerate RK3399 defconfigs after adding imply statements.
> >
> > Signed-off-by: Chen-Yu Tsai 
> > ---
> >  configs/chromebook_bob_defconfig  | 2 --
> >  configs/chromebook_kevin_defconfig| 2 --
> >  configs/firefly-rk3399_defconfig  | 2 --
> >  configs/nanopi-r4s-rk3399_defconfig   | 2 --
> >  configs/pinebook-pro-rk3399_defconfig | 2 --
> >  configs/pinephone-pro-rk3399_defconfig| 2 --
> >  configs/puma-rk3399_defconfig | 2 --
> >  configs/roc-pc-mezzanine-rk3399_defconfig | 2 --
> >  configs/roc-pc-rk3399_defconfig   | 2 --
> >  configs/rock-4c-plus-rk3399_defconfig | 3 ---
> >  configs/rock-4se-rk3399_defconfig | 3 ---
> >  configs/rock-pi-4-rk3399_defconfig| 3 ---
> >  configs/rock-pi-4c-rk3399_defconfig   | 3 ---
> >  configs/rock-pi-n10-rk3399pro_defconfig   | 1 -
> >  configs/rock960-rk3399_defconfig  | 1 -
> >  configs/rockpro64-rk3399_defconfig| 2 --
> >  16 files changed, 34 deletions(-)
> >
>
> [snip]
>
> > diff --git a/configs/rock-4c-plus-rk3399_defconfig 
> > b/configs/rock-4c-plus-rk3399_defconfig
> > index 18525c8bf504..12587b1eba10 100644
> > --- a/configs/rock-4c-plus-rk3399_defconfig
> > +++ b/configs/rock-4c-plus-rk3399_defconfig
> > @@ -8,7 +8,6 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> >  CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30
> >  CONFIG_ENV_OFFSET=0x3F8000
> >  CONFIG_DEFAULT_DEVICE_TREE="rk3399-rock-4c-plus"
> > -CONFIG_OF_LIBFDT_OVERLAY=y
>
> This patch seems to also remove a few OF_LIBFDT_OVERLAY, guessing this
> was unintentional?

Yeah, that was unintentional. I have a local patch that enables
OF_LIBFDT_OVERLAY for ARCH_ROCKCHIP by default.

> If you are re-spinning this series, please also include change to:
> - add CONFIG_MISC=y to ficus-rk3399_defconfig, its required for efuse

I suppose we should just also imply CONFIG_MISC.

> - drop CONFIG_ROCKCHIP_OTP=y from nanopi-r4s-rk3399_defconfig, soc have
>   efuse or otp and on rk3399 it is efuse

Will add a cleanup.

> And possible also drop CONFIG_NET_RANDOM_ETHADDR=y from:
> - evb-rk3399_defconfig
> - ficus-rk3399_defconfig
> - khadas-edge-captain-rk3399_defconfig
> - khadas-edge-v-rk3399_defconfig
> now that these boards will have proper ethaddr.

Will add a separate cleanup.


ChenYu

[PATCH v2 0/5] rockchip: Read cpuid and generate MAC address from efuse for RK3328 and RK3399

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Hi folks,

This is v2 of my "read cpuid and generate MAC address from efuse on
RK3328 and RK3399 by default" series.

Changes since v1:
- Also imply "CONFIG_MISC"
- Add back unintentionally removed CONFIG_OF_LIBFDT_OVERLAY=y
- Remove ROCKCHIP_OTP from nanopi-r4s-rk3399_defconfig as requested by
  Jonas

This series enables ROCKCHIP_EFUSE and MISC_INIT_R by default for RK3328
and RK3399 so that the cpuid is read from the efuse and used to generate
a serial number and MAC addresses for all boards.

This stacks on top of the recent defconfig update series [1] from Jonas.

[1] https://lore.kernel.org/u-boot/20240207000301.3270722-1-jo...@kwiboo.se/

Chen-Yu Tsai (5):
  rockchip: rk3328: Read cpuid and generate MAC address from efuse
  rockchip: rk3399: Read cpuid and generate MAC address from efuse
  rockchip: rk3328: regenerate defconfigs
  rockchip: rk3399: regenerate defconfigs
  rockchip: nanopi-r4s: Drop ROCKCHIP_OTP

 arch/arm/mach-rockchip/Kconfig| 6 ++
 configs/chromebook_bob_defconfig  | 3 ---
 configs/chromebook_kevin_defconfig| 3 ---
 configs/eaidk-610-rk3399_defconfig| 1 -
 configs/evb-rk3328_defconfig  | 3 ---
 configs/evb-rk3399_defconfig  | 1 -
 configs/firefly-rk3399_defconfig  | 3 ---
 configs/khadas-edge-captain-rk3399_defconfig  | 1 -
 configs/khadas-edge-rk3399_defconfig  | 1 -
 configs/khadas-edge-v-rk3399_defconfig| 1 -
 configs/leez-rk3399_defconfig | 1 -
 configs/nanopc-t4-rk3399_defconfig| 1 -
 configs/nanopi-m4-2gb-rk3399_defconfig| 1 -
 configs/nanopi-m4-rk3399_defconfig| 1 -
 configs/nanopi-m4b-rk3399_defconfig   | 1 -
 configs/nanopi-neo4-rk3399_defconfig  | 1 -
 configs/nanopi-r2c-plus-rk3328_defconfig  | 3 ---
 configs/nanopi-r2c-rk3328_defconfig   | 3 ---
 configs/nanopi-r2s-rk3328_defconfig   | 3 ---
 configs/nanopi-r4s-rk3399_defconfig   | 4 
 configs/orangepi-r1-plus-lts-rk3328_defconfig | 3 ---
 configs/orangepi-r1-plus-rk3328_defconfig | 3 ---
 configs/orangepi-rk3399_defconfig | 1 -
 configs/pinebook-pro-rk3399_defconfig | 3 ---
 configs/pinephone-pro-rk3399_defconfig| 3 ---
 configs/puma-rk3399_defconfig | 3 ---
 configs/roc-cc-rk3328_defconfig   | 3 ---
 configs/roc-pc-mezzanine-rk3399_defconfig | 3 ---
 configs/roc-pc-rk3399_defconfig   | 3 ---
 configs/rock-4c-plus-rk3399_defconfig | 3 ---
 configs/rock-4se-rk3399_defconfig | 3 ---
 configs/rock-pi-4-rk3399_defconfig| 3 ---
 configs/rock-pi-4c-rk3399_defconfig   | 3 ---
 configs/rock-pi-e-rk3328_defconfig| 3 ---
 configs/rock-pi-n10-rk3399pro_defconfig   | 2 --
 configs/rock64-rk3328_defconfig   | 3 ---
 configs/rock960-rk3399_defconfig  | 2 --
 configs/rockpro64-rk3399_defconfig| 3 ---
 38 files changed, 6 insertions(+), 86 deletions(-)

-- 
2.39.2

[PATCH v2 1/5] rockchip: rk3328: Read cpuid and generate MAC address from efuse

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The rockchip-efuse driver supports the efuse found on RK3328. This
hardware block is part of the SoC and contains the CPUID, which can
be used to generate stable serial numbers and MAC addresses.

Enable the driver and reading cpuid by default for RK3328.

Signed-off-by: Chen-Yu Tsai 
Reviewed-by: Christopher Obbard 
Reviewed-by: Dragan Simic 
---
 arch/arm/mach-rockchip/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 1bc7ee904275..0553967b947f 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -189,6 +189,9 @@ config ROCKCHIP_RK3328
select ENABLE_ARM_SOC_BOOT0_HOOK
select DEBUG_UART_BOARD_INIT
select SYS_NS16550
+   imply MISC
+   imply ROCKCHIP_EFUSE
+   imply MISC_INIT_R
help
  The Rockchip RK3328 is a ARM-based SoC with a quad-core Cortex-A53.
  including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two
-- 
2.39.2

[PATCH v2 2/5] rockchip: rk3399: Read cpuid and generate MAC address from efuse

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The rockchip-efuse driver supports the efuse found on RK3399. This
hardware block is part of the SoC and contains the CPUID, which can
be used to generate stable serial numbers and MAC addresses.

Enable the driver and reading cpuid by default for RK3399.

Signed-off-by: Chen-Yu Tsai 
Reviewed-by: Christopher Obbard 
Reviewed-by: Dragan Simic 
---
 arch/arm/mach-rockchip/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 0553967b947f..2c6b045c51c8 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -270,6 +270,9 @@ config ROCKCHIP_RK3399
imply SYS_BOOTCOUNT_SINGLEWORD if BOOTCOUNT_LIMIT
imply BOOTSTD_FULL
imply CMD_BOOTCOUNT if BOOTCOUNT_LIMIT
+   imply MISC
+   imply ROCKCHIP_EFUSE
+   imply MISC_INIT_R
help
  The Rockchip RK3399 is a ARM-based SoC with a dual-core Cortex-A72
  and quad-core Cortex-A53.
-- 
2.39.2

[PATCH v2 3/5] rockchip: rk3328: regenerate defconfigs

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Regenerate RK3328 defconfigs after adding imply statements.

Signed-off-by: Chen-Yu Tsai 
Reviewed-by: Christopher Obbard 
Reviewed-by: Dragan Simic 
---
 configs/evb-rk3328_defconfig  | 3 ---
 configs/nanopi-r2c-plus-rk3328_defconfig  | 3 ---
 configs/nanopi-r2c-rk3328_defconfig   | 3 ---
 configs/nanopi-r2s-rk3328_defconfig   | 3 ---
 configs/orangepi-r1-plus-lts-rk3328_defconfig | 3 ---
 configs/orangepi-r1-plus-rk3328_defconfig | 3 ---
 configs/roc-cc-rk3328_defconfig   | 3 ---
 configs/rock-pi-e-rk3328_defconfig| 3 ---
 configs/rock64-rk3328_defconfig   | 3 ---
 9 files changed, 27 deletions(-)

diff --git a/configs/evb-rk3328_defconfig b/configs/evb-rk3328_defconfig
index 995bfd0558b1..c3bde3e5c457 100644
--- a/configs/evb-rk3328_defconfig
+++ b/configs/evb-rk3328_defconfig
@@ -30,7 +30,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-evb.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -70,8 +69,6 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/nanopi-r2c-plus-rk3328_defconfig 
b/configs/nanopi-r2c-plus-rk3328_defconfig
index 1cb0ed855398..1b0fa27ced16 100644
--- a/configs/nanopi-r2c-plus-rk3328_defconfig
+++ b/configs/nanopi-r2c-plus-rk3328_defconfig
@@ -31,7 +31,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-nanopi-r2c-plus.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -72,8 +71,6 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/nanopi-r2c-rk3328_defconfig 
b/configs/nanopi-r2c-rk3328_defconfig
index 59801328deda..edf24623da2a 100644
--- a/configs/nanopi-r2c-rk3328_defconfig
+++ b/configs/nanopi-r2c-rk3328_defconfig
@@ -31,7 +31,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-nanopi-r2c.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -72,8 +71,6 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/nanopi-r2s-rk3328_defconfig 
b/configs/nanopi-r2s-rk3328_defconfig
index 61914b1650d2..32c99dfecb86 100644
--- a/configs/nanopi-r2s-rk3328_defconfig
+++ b/configs/nanopi-r2s-rk3328_defconfig
@@ -31,7 +31,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-nanopi-r2s.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -72,8 +71,6 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/orangepi-r1-plus-lts-rk3328_defconfig 
b/configs/orangepi-r1-plus-lts-rk3328_defconfig
index 968110c8cd6f..f554a284d930 100644
--- a/configs/orangepi-r1-plus-lts-rk3328_defconfig
+++ b/configs/orangepi-r1-plus-lts-rk3328_defconfig
@@ -34,7 +34,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-orangepi-r1-plus-lts.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -77,8 +76,6 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_SPI_FLASH_SFDP_SUPPORT=y
diff --git a/configs/orangepi-r1-plus-rk3328_defconfig 
b/configs/orangepi-r1-plus-rk3328_defconfig
index 7038f09f202c..162032460fe0 100644
--- a/configs/orangepi-r1-plus-rk3328_defconfig
+++ b/configs/orangepi-r1-plus-rk3328_defconfig
@@ -34,7 +34,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-orangepi-r1-plus.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_

[PATCH v2 4/5] rockchip: rk3399: regenerate defconfigs

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Regenerate RK3399 defconfigs after adding imply statements.

Signed-off-by: Chen-Yu Tsai 
Reviewed-by: Christopher Obbard 
Reviewed-by: Dragan Simic 
Reviewed-by: Quentin Schulz 
---
 configs/chromebook_bob_defconfig | 3 ---
 configs/chromebook_kevin_defconfig   | 3 ---
 configs/eaidk-610-rk3399_defconfig   | 1 -
 configs/evb-rk3399_defconfig | 1 -
 configs/firefly-rk3399_defconfig | 3 ---
 configs/khadas-edge-captain-rk3399_defconfig | 1 -
 configs/khadas-edge-rk3399_defconfig | 1 -
 configs/khadas-edge-v-rk3399_defconfig   | 1 -
 configs/leez-rk3399_defconfig| 1 -
 configs/nanopc-t4-rk3399_defconfig   | 1 -
 configs/nanopi-m4-2gb-rk3399_defconfig   | 1 -
 configs/nanopi-m4-rk3399_defconfig   | 1 -
 configs/nanopi-m4b-rk3399_defconfig  | 1 -
 configs/nanopi-neo4-rk3399_defconfig | 1 -
 configs/nanopi-r4s-rk3399_defconfig  | 3 ---
 configs/orangepi-rk3399_defconfig| 1 -
 configs/pinebook-pro-rk3399_defconfig| 3 ---
 configs/pinephone-pro-rk3399_defconfig   | 3 ---
 configs/puma-rk3399_defconfig| 3 ---
 configs/roc-pc-mezzanine-rk3399_defconfig| 3 ---
 configs/roc-pc-rk3399_defconfig  | 3 ---
 configs/rock-4c-plus-rk3399_defconfig| 3 ---
 configs/rock-4se-rk3399_defconfig| 3 ---
 configs/rock-pi-4-rk3399_defconfig   | 3 ---
 configs/rock-pi-4c-rk3399_defconfig  | 3 ---
 configs/rock-pi-n10-rk3399pro_defconfig  | 2 --
 configs/rock960-rk3399_defconfig | 2 --
 configs/rockpro64-rk3399_defconfig   | 3 ---
 28 files changed, 58 deletions(-)

diff --git a/configs/chromebook_bob_defconfig b/configs/chromebook_bob_defconfig
index b5a5ae737e52..989a8211f64d 100644
--- a/configs/chromebook_bob_defconfig
+++ b/configs/chromebook_bob_defconfig
@@ -27,7 +27,6 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-bob.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_BOARD_EARLY_INIT_R=y
-CONFIG_MISC_INIT_R=y
 CONFIG_BLOBLIST=y
 CONFIG_BLOBLIST_ADDR=0x10
 CONFIG_BLOBLIST_SIZE=0x1000
@@ -67,8 +66,6 @@ CONFIG_I2C_CROS_EC_TUNNEL=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_I2C_MUX=y
 CONFIG_CROS_EC_KEYB=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_CROS_EC=y
 CONFIG_CROS_EC_SPI=y
 CONFIG_PWRSEQ=y
diff --git a/configs/chromebook_kevin_defconfig 
b/configs/chromebook_kevin_defconfig
index 20913d2cf0fe..07a96aa18989 100644
--- a/configs/chromebook_kevin_defconfig
+++ b/configs/chromebook_kevin_defconfig
@@ -28,7 +28,6 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-kevin.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_BOARD_EARLY_INIT_R=y
-CONFIG_MISC_INIT_R=y
 CONFIG_BLOBLIST=y
 CONFIG_BLOBLIST_ADDR=0x10
 CONFIG_BLOBLIST_SIZE=0x1000
@@ -68,8 +67,6 @@ CONFIG_I2C_CROS_EC_TUNNEL=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_I2C_MUX=y
 CONFIG_CROS_EC_KEYB=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_CROS_EC=y
 CONFIG_CROS_EC_SPI=y
 CONFIG_PWRSEQ=y
diff --git a/configs/eaidk-610-rk3399_defconfig 
b/configs/eaidk-610-rk3399_defconfig
index 22ad98b95ad3..0ca4cebc4d90 100644
--- a/configs/eaidk-610-rk3399_defconfig
+++ b/configs/eaidk-610-rk3399_defconfig
@@ -40,7 +40,6 @@ CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_MMC_SDHCI=y
diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index d6140527b752..1d1e55162290 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -43,7 +43,6 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
 CONFIG_MMC_HS400_SUPPORT=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
diff --git a/configs/firefly-rk3399_defconfig b/configs/firefly-rk3399_defconfig
index b7c8e95b7b89..2fe38f81c50d 100644
--- a/configs/firefly-rk3399_defconfig
+++ b/configs/firefly-rk3399_defconfig
@@ -20,7 +20,6 @@ CONFIG_PCI=y
 CONFIG_DEBUG_UART=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-firefly.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x2e000
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -45,8 +44,6 @@ CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_MMC_SDHCI=y
diff --git a/configs/khadas-edge-captain-rk3399_defconfig 
b/configs/khadas-edge-captain-rk3399_defconfig
index 7f4e48a4e750..28a59899e1cb 100644
--- a/configs/khadas-edge-captain-rk3399_defconfig
+++ b/configs/khadas-edge-captain-rk3399_defconfig
@@ -43,7 +43,6 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y

[PATCH v2 5/5] rockchip: nanopi-r4s: Drop ROCKCHIP_OTP

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The NanoPi R4S has an RK3399 SoC, which has efuse supported by
ROCKCHIP_EFUSE, not ROCKCHIP_OTP.

Signed-off-by: Chen-Yu Tsai 
---
 configs/nanopi-r4s-rk3399_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/nanopi-r4s-rk3399_defconfig 
b/configs/nanopi-r4s-rk3399_defconfig
index f97c06412f07..50dbd7a854d4 100644
--- a/configs/nanopi-r4s-rk3399_defconfig
+++ b/configs/nanopi-r4s-rk3399_defconfig
@@ -40,7 +40,6 @@ CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_ROCKCHIP_OTP=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_MMC_SDHCI=y
-- 
2.39.2

Re: [PATCH 0/4] rockchip: Read cpuid and generate MAC address from efuse for RK3328 and RK3399

[Chen-Yu Tsai]

On Mon, Feb 12, 2024 at 9:57 PM Peter Robinson  wrote:
>
> On Sat, 10 Feb 2024 at 06:32, Chen-Yu Tsai  wrote:
> >
> > From: Chen-Yu Tsai 
> >
> > Hi folks,
> >
> > This series enables ROCKCHIP_EFUSE and MISC_INIT_R by default for RK3328
> > and RK3399 so that the cpuid is read from the efuse and used to generate
> > a serial number and MAC addresses for all boards.
>
> For the series:
> Reviewed-by: Peter Robinson 

Thanks. I just sent out v2. Could you reply there as well?

Re: [PATCH v3 8/9] rockchip: rk3328: Add support for ROC-RK3328-CC board

[Chen-Yu Tsai]

On Thu, Apr 30, 2020 at 5:08 PM Kever Yang  wrote:
>
>
> On 2020/4/27 下午2:52, Chen-Yu Tsai wrote:
> > --- a/board/rockchip/evb_rk3328/MAINTAINERS
> > +++ b/board/rockchip/evb_rk3328/MAINTAINERS
> > @@ -5,6 +5,13 @@ F:  board/rockchip/evb_rk3328
> >   F:  include/configs/evb_rk3328.h
> >   F:  configs/evb-rk3328_defconfig
> >
> > +ROC-RK3328-CC
> > +M:  Loic Devulder
> > +M:  Chen-Yu Tsai
> > +S:  Maintained
> > +F:  configs/roc-rk3328-cc_defconfig
>
> This need to be roc-cc-rk3328_defconfig, or else there will be warning:
>
> WARNING: no status info for 'roc-cc-rk3328'
> WARNING: no maintainers for 'roc-cc-rk3328'
>
> I will update it before merge.

Sorry about that, and thanks for fixing it up.

ChenYu

> Thanks,
>
> - Kever
>
> > +F:  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
> > +
>
>

Re: [PATCH v3 7/9] rockchip: dts: rk3328: Sync device tree files from Linux

[Chen-Yu Tsai]

Hi Kurt

On Tue, May 12, 2020 at 3:00 AM Kurt Miller  wrote:
>
> On Mon, 2020-04-27 at 14:52 +0800, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai 
> >
> > This syncs rk3328 device tree files from the Linux kernel next-20200324.
> > The last commit to touch these files is:
> >
> > b2411befed60 ("arm64: dts: add bus to rockchip amba nodenames")
> >
> > Additional changes not yet in the Linux kernel include:
> >
> > arm64: dts: rockchip: rk3328: drop #address-cells, #size-cells from grf 
> > node
> > arm64: dts: rockchip: rk3328: drop non-existent gmac2phy pinmux options
> > arm64: dts: rockchip: rk3328: Replace RK805 PMIC node name with "pmic"
> >
> > Changes include:
> >
> >   - conversion of raw pin numbers to macros
> >   - removal of deprecated RK_FUNC_* macros
> >   - update of device tree binding headers
> >   - new devices
> >   - device tree cleanups
> >   - gmac2phy disabled in -u-boot.dtsi as it is not supported in U-boot
> >
> > This includes a re-ordering of the USB device nodes compared to upstream
> > Linux, moving the dwc2 OTG controller after the EHCI/OHCI nodes. This is
> > currently required as otherwise the dwc2 controller would not be able to
> > detect devices in some cases. This may be due to lack of USB PHY support
> > in U-boot.
>
> Hi Chen-Yu,
>
> Thank you for syncing rk3328 device tree files. On the rock64 with
> v2020.04 one USB 2.0 port was working (the lower one). Building
> master now with this merged, no USB ports are working. No power
> appears to be enabled on them and USB devices are not recognized.

When I was working on v3, it was based on

d202f67db077 Merge branch '2020-04-25-master-imports'

And it was definitely working. My Rock64 is back in its case, so I tested
again with the ROC-RK3328-CC just now. All three USB ports work properly,
on both the old tree and current master.

Are you using the defconfig, or have you deviated from it? XHCI must be
enabled, as VBUS is tied to it (to get everything to work).

ChenYu

> Do you have any suggestions for me to try to get them enabled again?
>
> Thanks,
> -Kurt

Re: [PATCH v1 0/2] Add roc-rk3328-cc support

[Chen-Yu Tsai]

Hi,

On Fri, Feb 28, 2020 at 1:47 AM Peter Geis  wrote:
>
> On Fri, Feb 14, 2020 at 9:47 AM Loic Devulder  wrote:
> >
> > This serie add support for roc-rk33239 board from Firefly/Libre
> > Computer:
> >   - add missing L2 cache entry in rk3328 dts
> >   - add roc-rk3328-cc board support
> >
> > With this we can successfully boot the board with mainline U-Boot and
> > binary blob firmwares. Boot with ATF and TPL/SPL partially works: TPL
> > works fine but SPL fails to find a bootable device.
>
> I have tpl/spl fully enabled on this device privately.
> The SPL fails to find a boot device when booted from the sdcard.
> It successfully boots from emmc though.
> I believe this is due to the 3.3/1.8 mode switch.

Actually this is due to no power being supplied to the card.

The SD card's VCC is driven by a switched regulator, which is controlled
by SDMMC0_PWREN, and is also pulled down externally. The enable line is
active low. The bootrom does not touch the line, but the MMC driver in
U-boot sets PWREN in the MMC controller, which I assume changes the state
of SDMMC0_PWREN.

My solution was to simply mux the pin over to GPIO, instead of being
controlled through the MMC controller, the latter being the default.
The GPIO default state is input, and so the external pull-down works
to keep the power enabled. This is done by creating spl_board_init()
especially for this board, so essentially creating another target.

I suppose the other way to do it is to enable a bunch of stuff such
as regulators and GPIO in SPL, and also do proper pinmuxing, i.e.
not throwing away pinctrl properties in the SPL device tree.

My work also includes syncing the rk3328 device tree files from the
Linux kernel, along with some cleanups. If Loic and Kever are OK with
another series, I can send it out.

Regards
ChenYu



> Have you tested off emmc with your patch?
>
> >
> > I didn't used the DTS from Linux kernel: USB2 fails in that case, this
> > should be corrected but maybe later?
> >
> > Note: sorry if this serie has been send twice, but I had issue with my
> > email server...
> >
> >
> > Loic Devulder (2):
> >   rockchip: rk3328: dts: add L2 cache entry
> >   rockchip: rk3328: add roc-rk3328-cc support
> >
> >  arch/arm/dts/Makefile  |   3 +-
> >  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi |  16 ++
> >  arch/arm/dts/rk3328-roc-cc.dts | 260 +
> >  arch/arm/dts/rk3328.dtsi   |  25 ++-
> >  arch/arm/mach-rockchip/rk3328/Kconfig  |   1 -
> >  board/rockchip/evb_rk3328/MAINTAINERS  |   6 +
> >  configs/roc-cc-rk3328_defconfig|  95 +
> >  doc/README.rockchip|   9 +-
> >  8 files changed, 408 insertions(+), 7 deletions(-)
> >  create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
> >  create mode 100644 arch/arm/dts/rk3328-roc-cc.dts
> >  create mode 100644 configs/roc-cc-rk3328_defconfig
> >
> > --
> > 2.25.0
> >

[PATCH 4/6] dt-bindings: power: rk3328-power: sync from upstream Linux kernel

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

This syncs the rk3328 power domain header file from Linux kernel
next-20200324, to support newer hardware blocks when syncing the
device tree files.

The last non-merge commit to touch it was

b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to 
files with no license")

Signed-off-by: Chen-Yu Tsai 
---
 include/dt-bindings/power/rk3328-power.h | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 include/dt-bindings/power/rk3328-power.h

diff --git a/include/dt-bindings/power/rk3328-power.h 
b/include/dt-bindings/power/rk3328-power.h
new file mode 100644
index ..02e3d7fc1cce
--- /dev/null
+++ b/include/dt-bindings/power/rk3328-power.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __DT_BINDINGS_POWER_RK3328_POWER_H__
+#define __DT_BINDINGS_POWER_RK3328_POWER_H__
+
+/**
+ * RK3328 idle id Summary.
+ */
+#define RK3328_PD_CORE 0
+#define RK3328_PD_GPU  1
+#define RK3328_PD_BUS  2
+#define RK3328_PD_MSCH 3
+#define RK3328_PD_PERI 4
+#define RK3328_PD_VIDEO5
+#define RK3328_PD_HEVC 6
+#define RK3328_PD_SYS  7
+#define RK3328_PD_VPU  8
+#define RK3328_PD_VIO  9
+
+#endif
-- 
2.25.1

[PATCH 1/6] rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-boot.dtsi

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

USB 3.0 is only supported in U-boot, not in the Linux kernel where the
device tree files are ultimately synced from. While the xhci node was
moved, the external vbus regulator was not.

Move it as well.

Fixes: 2e91e2025c1b ("rockchip: rk3328: migrate u-boot node to -u-boot.dtsi")
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/dts/rk3328-evb-u-boot.dtsi | 11 +++
 arch/arm/dts/rk3328-evb.dts |  9 -
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 4a827063c555..5679897279aa 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -6,6 +6,17 @@
 #include "rk3328-u-boot.dtsi"
 #include "rk3328-sdram-ddr3-666.dtsi"
 
+/{
+   vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpio = <&gpio0 0 GPIO_ACTIVE_HIGH>;
+   regulator-name = "vcc5v0_host_xhci";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+};
+
 &usb_host0_xhci {
vbus-supply = <&vcc5v0_host_xhci>;
status = "okay";
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index a2ee838fcd6b..e9bc849f8c23 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -38,15 +38,6 @@
regulator-max-microvolt = <500>;
};
 
-   vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
-   compatible = "regulator-fixed";
-   enable-active-high;
-   regulator-name = "vcc5v0_host_xhci";
-   gpio = <&gpio0 0 GPIO_ACTIVE_HIGH>;
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   };
-
vcc_phy: vcc-phy-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc_phy";
-- 
2.25.1

[PATCH 3/6] dt-bindings: clock: rk3328: sync from upstream Linux kernel

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

This syncs the rk3328 clock header file from Linux kernel next-20200324,
to support newer hardware blocks when syncing the device tree files.

The last non-merge commit to touch it was

0dc14b013f79 ("clk: rockchip: add clock id for watchdog pclk on rk3328")

Signed-off-by: Chen-Yu Tsai 
---
 include/dt-bindings/clock/rk3328-cru.h | 212 -
 1 file changed, 106 insertions(+), 106 deletions(-)

diff --git a/include/dt-bindings/clock/rk3328-cru.h 
b/include/dt-bindings/clock/rk3328-cru.h
index cde61ed8830b..555b4ff660ae 100644
--- a/include/dt-bindings/clock/rk3328-cru.h
+++ b/include/dt-bindings/clock/rk3328-cru.h
@@ -1,6 +1,7 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
+/* SPDX-License-Identifier: GPL-2.0-or-later */
 /*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
+ * Author: Elaine 
  */
 
 #ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3328_H
@@ -90,119 +91,118 @@
 #define SCLK_MAC2IO_EXT102
 
 /* dclk gates */
-#define DCLK_LCDC  180
-#define DCLK_HDMIPHY   181
-#define HDMIPHY182
-#define USB480M183
-#define DCLK_LCDC_SRC  184
+#define DCLK_LCDC  120
+#define DCLK_HDMIPHY   121
+#define HDMIPHY122
+#define USB480M123
+#define DCLK_LCDC_SRC  124
 
 /* aclk gates */
-#define ACLK_AXISRAM   190
-#define ACLK_VOP_PRE   191
-#define ACLK_USB3OTG   192
-#define ACLK_RGA_PRE   193
-#define ACLK_DMAC  194
-#define ACLK_GPU   195
-#define ACLK_BUS_PRE   196
-#define ACLK_PERI_PRE  197
-#define ACLK_RKVDEC_PRE198
-#define ACLK_RKVDEC199
-#define ACLK_RKVENC200
-#define ACLK_VPU_PRE   201
-#define ACLK_VIO_PRE   202
-#define ACLK_VPU   203
-#define ACLK_VIO   204
-#define ACLK_VOP   205
-#define ACLK_GMAC  206
-#define ACLK_H265  207
-#define ACLK_H264  208
-#define ACLK_MAC2PHY   209
-#define ACLK_MAC2IO210
-#define ACLK_DCF   211
-#define ACLK_TSP   212
-#define ACLK_PERI  213
-#define ACLK_RGA   214
-#define ACLK_IEP   215
-#define ACLK_CIF   216
-#define ACLK_HDCP  217
+#define ACLK_AXISRAM   130
+#define ACLK_VOP_PRE   131
+#define ACLK_USB3OTG   132
+#define ACLK_RGA_PRE   133
+#define ACLK_DMAC  134
+#define ACLK_GPU   135
+#define ACLK_BUS_PRE   136
+#define ACLK_PERI_PRE  137
+#define ACLK_RKVDEC_PRE138
+#define ACLK_RKVDEC139
+#define ACLK_RKVENC140
+#define ACLK_VPU_PRE   141
+#define ACLK_VIO_PRE   142
+#define ACLK_VPU   143
+#define ACLK_VIO   144
+#define ACLK_VOP   145
+#define ACLK_GMAC  146
+#define ACLK_H265  147
+#define ACLK_H264  148
+#define ACLK_MAC2PHY   149
+#define ACLK_MAC2IO150
+#define ACLK_DCF   151
+#define ACLK_TSP   152
+#define ACLK_PERI  153
+#define ACLK_RGA   154
+#define ACLK_IEP   155
+#define ACLK_CIF   156
+#define ACLK_HDCP  157
 
 /* pclk gates */
-#define PCLK_GPIO0 300
-#define PCLK_GPIO1 301
-#define PCLK_GPIO2 302
-#define PCLK_GPIO3 303
-#define PCLK_GRF   304
-#define PCLK_I2C0  305
-#define PCLK_I2C1  306
-#define PCLK_I2C2  307
-#define PCLK_I2C3  308
-#define PCLK_SPI   309
-#define PCLK_UART0 310
-#define PCLK_UART1 311
-#define PCLK_UART2 312
-#define PCLK_TSADC 313
-#define PCLK_PWM   314
-#define PCLK_TIMER 315
-#define PCLK_BUS_PRE   316
-#define PCLK_PERI_PRE  317
-#define PCLK_HDMI_CTRL 318
-#define PCLK_HDMI_PHY  319
-#define PCLK_GMAC  320
-#define PCLK_H265  321
-#define PCLK_MAC2PHY   322
-#define PCLK_MAC2IO323
-#define PCLK_USB3PHY_OTG   324
-#define PCLK_USB3PHY_PIPE  325
-#define PCLK_USB3_GRF  326
-#define PCLK_USB2_GRF  327
-#define PCLK_HDMIPHY   328
-#define PCLK_DDR   329
-#define PCLK_PERI  330
-#define PCLK_HDMI  331
-#define PCLK_HDCP  332
-#define PCLK_DCF   333
-#define PCLK_SARADC334
+#define PCLK_GPIO0 200
+#define PCLK_GPIO1 201
+#define PCLK_GPIO2 202
+#define PCLK_GPIO3 203
+#define PCLK_GRF   204
+#define PCLK_I2C0  20

[PATCH 6/6] rockchip: rk3328: Add support for ROC-RK3328-CC board

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
card size development board based on the Rockchip RK3328 SoC, with:

  - 1/2/4 GB DDR4 DRAM
  - eMMC connector for optional module
  - micro SD card slot
  - 1 x USB 3.0 host port
  - 2 x USB 2.0 host port
  - 1 x USB 2.0 OTG port
  - HDMI video output
  - TRRS connector with audio and composite video output
  - gigabit Ethernet
  - consumer IR receiver
  - debug UART pins

The ROC-RK3328-CC has the enable pin of the SD card power switch tied
to GPIO_0_D6. This pin also has the function SDMMC0_PWREN, which is
muxed by default. SDMMC0_PWREN is an active high signal controlled by
the MMC controller, however the switch enable is active low, and
pulled low (enabled) by default to make things work on boot.

As such, we need to mux away from SDMMC0_PWREN and use GPIO to enable
power to the card. The default GPIO state for the pin is pull-down and
input, which doesn't require extra configuration when paired with the
external pull-down and active low switch.

Thus we make a custom target for this board and do the muxing in its
spl_board_init() function.

The device tree file is synced from the Linux kernel next-20200324.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/dts/Makefile   |   1 +
 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi  |  17 ++
 arch/arm/dts/rk3328-roc-cc.dts  | 354 
 arch/arm/mach-rockchip/rk3328/Kconfig   |   8 +
 board/firefly/roc-cc-rk3328/Kconfig |  24 ++
 board/firefly/roc-cc-rk3328/MAINTAINERS |   7 +
 board/firefly/roc-cc-rk3328/Makefile|   1 +
 board/firefly/roc-cc-rk3328/board.c |  38 +++
 configs/roc-cc-rk3328_defconfig |  97 +++
 doc/README.rockchip |   4 +-
 10 files changed, 550 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3328-roc-cc.dts
 create mode 100644 board/firefly/roc-cc-rk3328/Kconfig
 create mode 100644 board/firefly/roc-cc-rk3328/MAINTAINERS
 create mode 100644 board/firefly/roc-cc-rk3328/Makefile
 create mode 100644 board/firefly/roc-cc-rk3328/board.c
 create mode 100644 configs/roc-cc-rk3328_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9c593b2c986a..023cb010532d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -104,6 +104,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3308) += \
 
 dtb-$(CONFIG_ROCKCHIP_RK3328) += \
rk3328-evb.dtb \
+   rk3328-roc-cc.dtb \
rk3328-rock64.dtb
 
 dtb-$(CONFIG_ROCKCHIP_RK3368) += \
diff --git a/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi 
b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
new file mode 100644
index ..15b67f8bbdf4
--- /dev/null
+++ b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2018-2019 Rockchip Electronics Co., Ltd
+ */
+
+#include "rk3328-u-boot.dtsi"
+#include "rk3328-sdram-ddr4-666.dtsi"
+/ {
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", &sdmmc, &emmc;
+   };
+};
+
+&usb_host0_xhci {
+   vbus-supply = <&vcc_host1_5v>;
+   status = "okay";
+};
diff --git a/arch/arm/dts/rk3328-roc-cc.dts b/arch/arm/dts/rk3328-roc-cc.dts
new file mode 100644
index ..8d553c92182a
--- /dev/null
+++ b/arch/arm/dts/rk3328-roc-cc.dts
@@ -0,0 +1,354 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 T-Chip Intelligent Technology Co., Ltd
+ */
+
+/dts-v1/;
+#include "rk3328.dtsi"
+
+/ {
+   model = "Firefly roc-rk3328-cc";
+   compatible = "firefly,roc-rk3328-cc", "rockchip,rk3328";
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   gmac_clkin: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "gmac_clkin";
+   #clock-cells = <0>;
+   };
+
+   dc_12v: dc-12v {
+   compatible = "regulator-fixed";
+   regulator-name = "dc_12v";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+
+   vcc_sd: sdmmc-regulator {
+   compatible = "regulator-fixed";
+   gpio = <&gpio0 RK_PD6 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&sdmmc0m1_gpio>;
+   regulator-boot-on;
+   regulator-name = "vcc_sd";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <&vcc_io>;
+   }

[PATCH 2/6] rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-boot.dtsi

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The device tree file for rk3328-evb in the Linux kernel does not have
gmac2io enabled. Instead, gmac2phy is enabled, but that is not supported
in U-boot.

Move the gmac2io related nodes to rk3328-evb-u-boot.dtsi to preserve the
current functionality. When the device tree files are synced, gmac2phy
should be marked as "broken" in -u-boot.dtsi files.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/dts/rk3328-evb-u-boot.dtsi | 23 +++
 arch/arm/dts/rk3328-evb.dts | 23 ---
 2 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 5679897279aa..8ba53cf8f44b 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -7,6 +7,13 @@
 #include "rk3328-sdram-ddr3-666.dtsi"
 
 /{
+   gmac_clkin: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "gmac_clkin";
+   #clock-cells = <0>;
+   };
+
vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
compatible = "regulator-fixed";
enable-active-high;
@@ -17,6 +24,22 @@
};
 };
 
+&gmac2io {
+   phy-supply = <&vcc_phy>;
+   phy-mode = "rgmii";
+   clock_in_out = "input";
+   snps,reset-gpio = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>;
+   snps,reset-active-low;
+   snps,reset-delays-us = <0 1 5>;
+   assigned-clocks = <&cru SCLK_MAC2IO>, <&cru SCLK_MAC2IO_EXT>;
+   assigned-clock-parents = <&gmac_clkin>, <&gmac_clkin>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&rgmiim1_pins>;
+   tx_delay = <0x26>;
+   rx_delay = <0x11>;
+   status = "okay";
+};
+
 &usb_host0_xhci {
vbus-supply = <&vcc5v0_host_xhci>;
status = "okay";
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index e9bc849f8c23..97bef37cf610 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -14,13 +14,6 @@
stdout-path = &uart2;
};
 
-   gmac_clkin: external-gmac-clock {
-   compatible = "fixed-clock";
-   clock-frequency = <12500>;
-   clock-output-names = "gmac_clkin";
-   #clock-cells = <0>;
-   };
-
vcc3v3_sdmmc: sdmmc-pwren {
compatible = "regulator-fixed";
regulator-name = "vcc3v3";
@@ -78,22 +71,6 @@
status = "okay";
 };
 
-&gmac2io {
-   phy-supply = <&vcc_phy>;
-   phy-mode = "rgmii";
-   clock_in_out = "input";
-   snps,reset-gpio = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>;
-   snps,reset-active-low;
-   snps,reset-delays-us = <0 1 5>;
-   assigned-clocks = <&cru SCLK_MAC2IO>, <&cru SCLK_MAC2IO_EXT>;
-   assigned-clock-parents = <&gmac_clkin>, <&gmac_clkin>;
-   pinctrl-names = "default";
-   pinctrl-0 = <&rgmiim1_pins>;
-   tx_delay = <0x26>;
-   rx_delay = <0x11>;
-   status = "okay";
-};
-
 &usb_host0_ehci {
status = "okay";
 };
-- 
2.25.1

[PATCH 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Hi everyone,

This series adds proper support for Firefly / Libre Computer ROC-RK3328-CC
single board computer.

The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
card size development board based on the Rockchip RK3328 SoC, with:

  - 1/2/4 GB DDR4 DRAM
  - eMMC connector for optional module
  - micro SD card slot
  - 1 x USB 3.0 host port
  - 2 x USB 2.0 host port
  - 1 x USB 2.0 OTG port
  - HDMI video output
  - TRRS connector with audio and composite video output
  - gigabit Ethernet
  - consumer IR receiver
  - debug UART pins

Originally I started with Loic's patches, and syncing the device tree
files from Linux. That didn't get very far, with SPL failing to detect
the SD card. Examining the schematics and internal state of GRF and
GPIOs, I realized that the logic for the SD card power enable switch
is opposite that of what the SD card controller's SDMMC0_PWREN pin
would use. Instead, directly using the GPIO is required.

Thus this series creates a special target for this board to handle
muxing this specific pin to GPIO state. The GPIO is left in input mode,
letting the external pull-down work its magic.

Along the way, there are some clean-ups of existing dts files, moving
U-boot only features to -u-boot.dtsi files, and then a wholesale sync
from Linux. Only boards already existing in U-boot are synced. DT
binding header files are synced separately as there is already one
patch floating around. The DT sync also includes clean-up changes only
recently posted, and likely won't make it in for at least a few weeks.

Please have a look, and test if possible. I cc-ed a couple people that
showed interest in this board on mailing lists recently.

Regards
ChenYu


Chen-Yu Tsai (6):
  rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-boot.dtsi
  rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-boot.dtsi
  dt-bindings: clock: rk3328: sync from upstream Linux kernel
  dt-bindings: power: rk3328-power: sync from upstream Linux kernel
  rockchip: dts: rk3328: Sync device tree files from Linux
  rockchip: rk3328: Add support for ROC-RK3328-CC board

 arch/arm/dts/Makefile |1 +
 arch/arm/dts/rk3328-evb-u-boot.dtsi   |   39 +
 arch/arm/dts/rk3328-evb.dts   |  220 +--
 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi|   17 +
 .../{rk3328-rock64.dts => rk3328-roc-cc.dts}  |  135 +-
 arch/arm/dts/rk3328-rock64.dts|  132 +-
 arch/arm/dts/rk3328.dtsi  | 1420 +++--
 arch/arm/mach-rockchip/rk3328/Kconfig |8 +
 board/firefly/roc-cc-rk3328/Kconfig   |   24 +
 board/firefly/roc-cc-rk3328/MAINTAINERS   |7 +
 board/firefly/roc-cc-rk3328/Makefile  |1 +
 board/firefly/roc-cc-rk3328/board.c   |   38 +
 configs/roc-cc-rk3328_defconfig   |   97 ++
 doc/README.rockchip   |4 +-
 include/dt-bindings/clock/rk3328-cru.h|  212 +--
 include/dt-bindings/power/rk3328-power.h  |   19 +
 16 files changed, 1622 insertions(+), 752 deletions(-)
 create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
 copy arch/arm/dts/{rk3328-rock64.dts => rk3328-roc-cc.dts} (68%)
 create mode 100644 board/firefly/roc-cc-rk3328/Kconfig
 create mode 100644 board/firefly/roc-cc-rk3328/MAINTAINERS
 create mode 100644 board/firefly/roc-cc-rk3328/Makefile
 create mode 100644 board/firefly/roc-cc-rk3328/board.c
 create mode 100644 configs/roc-cc-rk3328_defconfig
 create mode 100644 include/dt-bindings/power/rk3328-power.h

-- 
2.25.1

[PATCH 5/6] rockchip: dts: rk3328: Sync device tree files from Linux

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

This syncs rk3328 device tree files from the Linux kernel next-20200324.
The last commit to touch these files is:

b2411befed60 ("arm64: dts: add bus to rockchip amba nodenames")

Additional changes not yet in the Linux kernel include:

arm64: dts: rockchip: rk3328: drop #address-cells, #size-cells from grf node
arm64: dts: rockchip: rk3328: drop non-existent gmac2phy pinmux options
arm64: dts: rockchip: rk3328: Replace RK805 PMIC node name with "pmic"

Changes include:

  - conversion of raw pin numbers to macros
  - removal of deprecated RK_FUNC_* macros
  - update of device tree binding headers
  - new devices
  - device tree cleanups
  - gmac2phy disabled in -u-boot.dtsi as it is not supported in U-boot

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/dts/rk3328-evb-u-boot.dtsi |5 +
 arch/arm/dts/rk3328-evb.dts |  196 ++--
 arch/arm/dts/rk3328-rock64.dts  |  132 ++-
 arch/arm/dts/rk3328.dtsi| 1420 +--
 4 files changed, 1164 insertions(+), 589 deletions(-)

diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 8ba53cf8f44b..4bfa0c2330ba 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -40,6 +40,11 @@
status = "okay";
 };
 
+&gmac2phy {
+   /* Integrated PHY unsupported by U-boot */
+   status = "broken";
+};
+
 &usb_host0_xhci {
vbus-supply = <&vcc5v0_host_xhci>;
status = "okay";
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index 97bef37cf610..6abc6f4a86cf 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -1,6 +1,6 @@
-// SPDX-License-Identifier: GPL-2.0+
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
 /*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
  */
 
 /dts-v1/;
@@ -11,24 +11,51 @@
compatible = "rockchip,rk3328-evb", "rockchip,rk3328";
 
chosen {
-   stdout-path = &uart2;
+   stdout-path = "serial2:150n8";
};
 
-   vcc3v3_sdmmc: sdmmc-pwren {
+   dc_12v: dc-12v {
compatible = "regulator-fixed";
-   regulator-name = "vcc3v3";
-   gpio = <&gpio0 30 GPIO_ACTIVE_LOW>;
+   regulator-name = "dc_12v";
regulator-always-on;
regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+
+   sdio_pwrseq: sdio-pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   pinctrl-names = "default";
+   pinctrl-0 = <&wifi_enable_h>;
+
+   /*
+* On the module itself this is one of these (depending
+* on the actual card populated):
+* - SDIO_RESET_L_WL_REG_ON
+* - PDN (power down when low)
+*/
+   reset-gpios = <&gpio1 18 GPIO_ACTIVE_LOW>;
+   };
+
+   vcc_sd: sdmmc-regulator {
+   compatible = "regulator-fixed";
+   gpio = <&gpio0 30 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&sdmmc0m1_gpio>;
+   regulator-name = "vcc_sd";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <&vcc_io>;
};
 
-   vcc5v0_otg: vcc5v0-otg-drv {
+   vcc_sys: vcc-sys {
compatible = "regulator-fixed";
-   enable-active-high;
-   regulator-name = "vcc5v0_otg";
-   gpio = <&gpio0 27 GPIO_ACTIVE_HIGH>;
+   regulator-name = "vcc_sys";
+   regulator-always-on;
+   regulator-boot-on;
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
+   vin-supply = <&dc_12v>;
};
 
vcc_phy: vcc-phy-regulator {
@@ -39,80 +66,60 @@
};
 };
 
-&saradc {
-   status = "okay";
-};
-
-&uart2 {
-   status = "okay";
-};
-
-&sdmmc {
-   bus-width = <4>;
-   cap-mmc-highspeed;
-   cap-sd-highspeed;
-   card-detect-delay = <200>;
-   disable-wp;
-   num-slots = <1>;
-   pinctrl-names = "default";
-   pinctrl-0 = <&sdmmc0_clk>, <&sdmmc0_cmd>, <&sdmmc0_dectn>, 
<&sdmmc0_bus4>;
-   status = "okay";
+&cpu0 {
+   cpu-supply = <&vdd_arm>;
 };
 
 &emmc {
 

Re: [PATCH 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board

[Chen-Yu Tsai]

Hi,

On Fri, Mar 27, 2020 at 11:07 PM Kurt Miller  wrote:
>
> On Fri, 2020-03-27 at 12:41 +0800, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai 
> >
> > Hi everyone,
> >
> > This series adds proper support for Firefly / Libre Computer ROC-RK3328-CC
> > single board computer.
> >
> > The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
> > card size development board based on the Rockchip RK3328 SoC, with:
> >
> >   - 1/2/4 GB DDR4 DRAM
> >   - eMMC connector for optional module
> >   - micro SD card slot
> >   - 1 x USB 3.0 host port
> >   - 2 x USB 2.0 host port
> >   - 1 x USB 2.0 OTG port
> >   - HDMI video output
> >   - TRRS connector with audio and composite video output
> >   - gigabit Ethernet
> >   - consumer IR receiver
> >   - debug UART pins
> >
> > Originally I started with Loic's patches, and syncing the device tree
> > files from Linux. That didn't get very far, with SPL failing to detect
> > the SD card. Examining the schematics and internal state of GRF and
> > GPIOs, I realized that the logic for the SD card power enable switch
> > is opposite that of what the SD card controller's SDMMC0_PWREN pin
> > would use. Instead, directly using the GPIO is required.
> >
> > Thus this series creates a special target for this board to handle
> > muxing this specific pin to GPIO state. The GPIO is left in input mode,
> > letting the external pull-down work its magic.
> >
> > Along the way, there are some clean-ups of existing dts files, moving
> > U-boot only features to -u-boot.dtsi files, and then a wholesale sync
> > from Linux. Only boards already existing in U-boot are synced. DT
> > binding header files are synced separately as there is already one
> > patch floating around. The DT sync also includes clean-up changes only
> > recently posted, and likely won't make it in for at least a few weeks.
> >
> > Please have a look, and test if possible. I cc-ed a couple people that
> > showed interest in this board on mailing lists recently.
> >
>
> Thank you for updating the dts for rk3328. I have Rock64 v2 and v3
> boards and have tested your patchset with OpenBSD-current. The v2 board
> is working and I have not noticed any regressions. The v3 board prior
> to your patchset was not booting and continues to not boot.
>
> U-Boot TPL 2020.04-rc3-00172-gaf827140e5-dirty (Mar 27 2020 - 09:44:24)
> LPDDR3, 800MHz
> BW=32 Col=11 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=4096MB
> Trying to boot from BOOTROM
> Returning to boot ROM...
>
> U-Boot SPL 2020.04-rc3-00172-gaf827140e5-dirty (Mar 27 2020 - 09:44:24 -0400)
> Trying to boot from MMC1
> Card did not respond to voltage select!
> spl: mmc init failed with error: -95
> Trying to boot from MMC2
> Card did not respond to voltage select!
> spl: mmc init failed with error: -95
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
>
> The Rock64 v3 board issues are unrelated to your patch set, but I
> believe it needs a similar approach as ROC-RK3328-CC. Here is some
> info previously posted regarding this:
>
> https://marc.info/?t=15575150651&r=1&w=2

So based on the changes from Pine64, it looks like v3 follows a similar
design as the ROC-RK3328-CC, that is use the SDMMC0_PWREN pin to control
power to the SD card. On the Rock64 v3, there's no external pull-down,
but the internal pull-down might be enough...

You could try setting the target to ROC-RK3328-CC through menuconfig
after you use the defconfig for rock64 and see if that works for you.


ChenYu

> Regards,
> -Kurt
>
>
> > Regards
> > ChenYu
> >
> >
> > Chen-Yu Tsai (6):
> >   rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-boot.dtsi
> >   rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-boot.dtsi
> >   dt-bindings: clock: rk3328: sync from upstream Linux kernel
> >   dt-bindings: power: rk3328-power: sync from upstream Linux kernel
> >   rockchip: dts: rk3328: Sync device tree files from Linux
> >   rockchip: rk3328: Add support for ROC-RK3328-CC board
> >
> >  arch/arm/dts/Makefile |1 +
> >  arch/arm/dts/rk3328-evb-u-boot.dtsi   |   39 +
> >  arch/arm/dts/rk3328-evb.dts   |  220 +--
> >  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi|   17 +
> >  .../{rk3328-rock64.dts => rk3328-roc-cc.dts}  |  135 +-
> >  arch/arm/dts/rk3328-rock64.dts|  132 +-
> >  arch/arm/dts/rk3328.dtsi  | 1420 +++--
> >  arch/arm/mach-rockchip/

Re: [PATCH 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board

[Chen-Yu Tsai]

On Sat, Mar 28, 2020 at 6:03 AM Kurt Miller  wrote:
>
> On Sat, 2020-03-28 at 01:44 +0800, Chen-Yu Tsai wrote:
> > Hi,
> >
> > On Fri, Mar 27, 2020 at 11:07 PM Kurt Miller  
> > wrote:
> > >
> > >
> > > On Fri, 2020-03-27 at 12:41 +0800, Chen-Yu Tsai wrote:
> > > >
> > > > From: Chen-Yu Tsai 
> > > >
> > > > Hi everyone,
> > > >
> > > > This series adds proper support for Firefly / Libre Computer 
> > > > ROC-RK3328-CC
> > > > single board computer.
> > > >
> > > > The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
> > > > card size development board based on the Rockchip RK3328 SoC, with:
> > > >
> > > >   - 1/2/4 GB DDR4 DRAM
> > > >   - eMMC connector for optional module
> > > >   - micro SD card slot
> > > >   - 1 x USB 3.0 host port
> > > >   - 2 x USB 2.0 host port
> > > >   - 1 x USB 2.0 OTG port
> > > >   - HDMI video output
> > > >   - TRRS connector with audio and composite video output
> > > >   - gigabit Ethernet
> > > >   - consumer IR receiver
> > > >   - debug UART pins
> > > >
> > > > Originally I started with Loic's patches, and syncing the device tree
> > > > files from Linux. That didn't get very far, with SPL failing to detect
> > > > the SD card. Examining the schematics and internal state of GRF and
> > > > GPIOs, I realized that the logic for the SD card power enable switch
> > > > is opposite that of what the SD card controller's SDMMC0_PWREN pin
> > > > would use. Instead, directly using the GPIO is required.
> > > >
> > > > Thus this series creates a special target for this board to handle
> > > > muxing this specific pin to GPIO state. The GPIO is left in input mode,
> > > > letting the external pull-down work its magic.
> > > >
> > > > Along the way, there are some clean-ups of existing dts files, moving
> > > > U-boot only features to -u-boot.dtsi files, and then a wholesale sync
> > > > from Linux. Only boards already existing in U-boot are synced. DT
> > > > binding header files are synced separately as there is already one
> > > > patch floating around. The DT sync also includes clean-up changes only
> > > > recently posted, and likely won't make it in for at least a few weeks.
> > > >
> > > > Please have a look, and test if possible. I cc-ed a couple people that
> > > > showed interest in this board on mailing lists recently.
> > > >
> > > Thank you for updating the dts for rk3328. I have Rock64 v2 and v3
> > > boards and have tested your patchset with OpenBSD-current. The v2 board
> > > is working and I have not noticed any regressions. The v3 board prior
> > > to your patchset was not booting and continues to not boot.
> > >
> > > U-Boot TPL 2020.04-rc3-00172-gaf827140e5-dirty (Mar 27 2020 - 09:44:24)
> > > LPDDR3, 800MHz
> > > BW=32 Col=11 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=4096MB
> > > Trying to boot from BOOTROM
> > > Returning to boot ROM...
> > >
> > > U-Boot SPL 2020.04-rc3-00172-gaf827140e5-dirty (Mar 27 2020 - 09:44:24 
> > > -0400)
> > > Trying to boot from MMC1
> > > Card did not respond to voltage select!
> > > spl: mmc init failed with error: -95
> > > Trying to boot from MMC2
> > > Card did not respond to voltage select!
> > > spl: mmc init failed with error: -95
> > > SPL: failed to boot from all boot devices
> > > ### ERROR ### Please RESET the board ###
> > >
> > > The Rock64 v3 board issues are unrelated to your patch set, but I
> > > believe it needs a similar approach as ROC-RK3328-CC. Here is some
> > > info previously posted regarding this:
> > >
> > > https://marc.info/?t=15575150651&r=1&w=2
> > So based on the changes from Pine64, it looks like v3 follows a similar
> > design as the ROC-RK3328-CC, that is use the SDMMC0_PWREN pin to control
> > power to the SD card. On the Rock64 v3, there's no external pull-down,
> > but the internal pull-down might be enough...
> >
> > You could try setting the target to ROC-RK3328-CC through menuconfig
> > after you use the defconfig for rock64 and see if that works for you.
> >
>
> Yes, that works for both the v2 and v3 boards. Thank you.
>
> Would you be able to create a patch 7 in your series to
> apply this approch to the rock64?

I took a look at the schematics again. The SDMMC0_PWREN pin is used to
toggle the I/O signalling voltage. There is no power cut for the SD card.
So configuring SDMMC0_PWREN to GPIO will get you through SPL, but why it
works is slightly different for the Rock64 compared to the ROC-RK3328-CC.

ChenYu

Re: [PATCH 6/6] rockchip: rk3328: Add support for ROC-RK3328-CC board

[Chen-Yu Tsai]

On Tue, Mar 31, 2020 at 1:44 AM Jagan Teki  wrote:
>
> Hi Chen-Yu,
>
> On Fri, Mar 27, 2020 at 10:12 AM Chen-Yu Tsai  wrote:
> >
> > From: Chen-Yu Tsai 
> >
> > The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
> > card size development board based on the Rockchip RK3328 SoC, with:
> >
> >   - 1/2/4 GB DDR4 DRAM
> >   - eMMC connector for optional module
> >   - micro SD card slot
> >   - 1 x USB 3.0 host port
> >   - 2 x USB 2.0 host port
> >   - 1 x USB 2.0 OTG port
> >   - HDMI video output
> >   - TRRS connector with audio and composite video output
> >   - gigabit Ethernet
> >   - consumer IR receiver
> >   - debug UART pins
> >
> > The ROC-RK3328-CC has the enable pin of the SD card power switch tied
> > to GPIO_0_D6. This pin also has the function SDMMC0_PWREN, which is
> > muxed by default. SDMMC0_PWREN is an active high signal controlled by
> > the MMC controller, however the switch enable is active low, and
> > pulled low (enabled) by default to make things work on boot.
> >
> > As such, we need to mux away from SDMMC0_PWREN and use GPIO to enable
> > power to the card. The default GPIO state for the pin is pull-down and
> > input, which doesn't require extra configuration when paired with the
> > external pull-down and active low switch.
> >
> > Thus we make a custom target for this board and do the muxing in its
> > spl_board_init() function.
> >
> > The device tree file is synced from the Linux kernel next-20200324.
> >
> > Signed-off-by: Chen-Yu Tsai 
> > ---
>
> [snip]
>
> > diff --git a/board/firefly/roc-cc-rk3328/MAINTAINERS 
> > b/board/firefly/roc-cc-rk3328/MAINTAINERS
> > new file mode 100644
> > index ..f2318e71ac33
> > --- /dev/null
> > +++ b/board/firefly/roc-cc-rk3328/MAINTAINERS
> > @@ -0,0 +1,7 @@
> > +ROC-RK3328-CC
> > +M:  Loic Devulder 
> > +M: Chen-Yu Tsai 
> > +S:  Maintained
> > +F: board/firefly/roc-cc-rk3328/
> > +F:  configs/roc-rk3328-cc_defconfig
> > +F:  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
> > diff --git a/board/firefly/roc-cc-rk3328/Makefile 
> > b/board/firefly/roc-cc-rk3328/Makefile
> > new file mode 100644
> > index ..1550b5f5f16e
> > --- /dev/null
> > +++ b/board/firefly/roc-cc-rk3328/Makefile
> > @@ -0,0 +1 @@
> > +obj-y  := board.o
> > diff --git a/board/firefly/roc-cc-rk3328/board.c 
> > b/board/firefly/roc-cc-rk3328/board.c
> > new file mode 100644
> > index ..eca58c86b53e
> > --- /dev/null
> > +++ b/board/firefly/roc-cc-rk3328/board.c
> > @@ -0,0 +1,38 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * (C) Copyright 2020 Chen-Yu Tsai 
> > + */
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +#if defined(CONFIG_SPL_BUILD)
> > +
> > +#define GRF_BASE   0xFF10
> > +
> > +enum {
> > +   GPIO_0_D6_GPIO  = 0   << 12,
> > +   GPIO_0_D6_MASK  = 0x3 << 12
> > +};
> > +
> > +/*
> > + * The ROC-RK3328-CC has the enable pin of the SD card power switch tied
> > + * to GPIO_0_D6. This pin also has the function SDMMC0_PWREN, which is
> > + * muxed by default. SDMMC0_PWREN is an active high signal controlled by
> > + * the MMC controller, however the switch enable is active low, and
> > + * pulled low (enabled) by default to make things work on boot.
> > + *
> > + * As such, we need to mux away from SDMMC0_PWREN and use GPIO to enable
> > + * power to the card. The default GPIO state for the pin is pull-down and
> > + * input, which doesn't require extra configuration when paired with the
> > + * external pull-down and active low switch.
> > + */
> > +void spl_board_init(void)
> > +{
> > +   struct rk3328_grf_regs * const grf = (void *)GRF_BASE;
> > +
> > +   rk_clrsetreg(&grf->gpio0d_iomux, GPIO_0_D6_MASK, GPIO_0_D6_GPIO);
> > +}
>
> So, this seem toggle the bit 12, 13 of GRF_GPIO0D_IOMUX so-that it
> operate like a gpio(not like default sdmmc0_pwrenm1), isn't it
> required for the next stages like U-Boot proper and Linux? these has
> vcc_sd node where it operates a fixed regulator to active low the same
> pin.
>
> gpio = <&gpio0 RK_PD6 GPIO_ACTIVE_LOW>;

So U-boot proper and Linux both have pinctrl and GPIO and all the stuff
to deal with this. SPL doesn't have GPIO enabled, and I believe all the
pinctrl properties are striped out. (BTW, not sure why we're enabling
pinctrl driver support in SPL if nothing is triggering them.) It seems
a bit heavy pulling all that stuff in just for one pin mux in SPL. The
same is also done for the UART pins.

ChenYu

Re: [PATCH 6/6] rockchip: rk3328: Add support for ROC-RK3328-CC board

[Chen-Yu Tsai]

On Tue, Mar 31, 2020 at 6:57 PM Jagan Teki  wrote:
>
> On Mon, Mar 30, 2020 at 11:54 PM Chen-Yu Tsai  wrote:
> >
> > On Tue, Mar 31, 2020 at 1:44 AM Jagan Teki  
> > wrote:
> > >
> > > Hi Chen-Yu,
> > >
> > > On Fri, Mar 27, 2020 at 10:12 AM Chen-Yu Tsai  wrote:
> > > >
> > > > From: Chen-Yu Tsai 
> > > >
> > > > The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
> > > > card size development board based on the Rockchip RK3328 SoC, with:
> > > >
> > > >   - 1/2/4 GB DDR4 DRAM
> > > >   - eMMC connector for optional module
> > > >   - micro SD card slot
> > > >   - 1 x USB 3.0 host port
> > > >   - 2 x USB 2.0 host port
> > > >   - 1 x USB 2.0 OTG port
> > > >   - HDMI video output
> > > >   - TRRS connector with audio and composite video output
> > > >   - gigabit Ethernet
> > > >   - consumer IR receiver
> > > >   - debug UART pins
> > > >
> > > > The ROC-RK3328-CC has the enable pin of the SD card power switch tied
> > > > to GPIO_0_D6. This pin also has the function SDMMC0_PWREN, which is
> > > > muxed by default. SDMMC0_PWREN is an active high signal controlled by
> > > > the MMC controller, however the switch enable is active low, and
> > > > pulled low (enabled) by default to make things work on boot.
> > > >
> > > > As such, we need to mux away from SDMMC0_PWREN and use GPIO to enable
> > > > power to the card. The default GPIO state for the pin is pull-down and
> > > > input, which doesn't require extra configuration when paired with the
> > > > external pull-down and active low switch.
> > > >
> > > > Thus we make a custom target for this board and do the muxing in its
> > > > spl_board_init() function.
> > > >
> > > > The device tree file is synced from the Linux kernel next-20200324.
> > > >
> > > > Signed-off-by: Chen-Yu Tsai 
> > > > ---
> > >
> > > [snip]
> > >
> > > > diff --git a/board/firefly/roc-cc-rk3328/MAINTAINERS 
> > > > b/board/firefly/roc-cc-rk3328/MAINTAINERS
> > > > new file mode 100644
> > > > index ..f2318e71ac33
> > > > --- /dev/null
> > > > +++ b/board/firefly/roc-cc-rk3328/MAINTAINERS
> > > > @@ -0,0 +1,7 @@
> > > > +ROC-RK3328-CC
> > > > +M:  Loic Devulder 
> > > > +M: Chen-Yu Tsai 
> > > > +S:  Maintained
> > > > +F: board/firefly/roc-cc-rk3328/
> > > > +F:  configs/roc-rk3328-cc_defconfig
> > > > +F:  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
> > > > diff --git a/board/firefly/roc-cc-rk3328/Makefile 
> > > > b/board/firefly/roc-cc-rk3328/Makefile
> > > > new file mode 100644
> > > > index ..1550b5f5f16e
> > > > --- /dev/null
> > > > +++ b/board/firefly/roc-cc-rk3328/Makefile
> > > > @@ -0,0 +1 @@
> > > > +obj-y  := board.o
> > > > diff --git a/board/firefly/roc-cc-rk3328/board.c 
> > > > b/board/firefly/roc-cc-rk3328/board.c
> > > > new file mode 100644
> > > > index ..eca58c86b53e
> > > > --- /dev/null
> > > > +++ b/board/firefly/roc-cc-rk3328/board.c
> > > > @@ -0,0 +1,38 @@
> > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > +/*
> > > > + * (C) Copyright 2020 Chen-Yu Tsai 
> > > > + */
> > > > +#include 
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +#if defined(CONFIG_SPL_BUILD)
> > > > +
> > > > +#define GRF_BASE   0xFF10
> > > > +
> > > > +enum {
> > > > +   GPIO_0_D6_GPIO  = 0   << 12,
> > > > +   GPIO_0_D6_MASK  = 0x3 << 12
> > > > +};
> > > > +
> > > > +/*
> > > > + * The ROC-RK3328-CC has the enable pin of the SD card power switch 
> > > > tied
> > > > + * to GPIO_0_D6. This pin also has the function SDMMC0_PWREN, which is
> > > > + * muxed by default. SDMMC0_PWREN is an active high signal controlled 
> > > > by
> > > > + * the MMC controller, however the switch enable is active low, and
> > > > + * pulled low (enabled) by default to make things work on boot.
> > > 

Re: [PATCH 6/6] rockchip: rk3328: Add support for ROC-RK3328-CC board

[Chen-Yu Tsai]

On Tue, Mar 31, 2020 at 8:37 PM Jagan Teki  wrote:
>
> On Tue, Mar 31, 2020 at 5:16 PM Chen-Yu Tsai  wrote:
> >
> > On Tue, Mar 31, 2020 at 6:57 PM Jagan Teki  
> > wrote:
> > >
> > > On Mon, Mar 30, 2020 at 11:54 PM Chen-Yu Tsai  wrote:
> > > >
> > > > On Tue, Mar 31, 2020 at 1:44 AM Jagan Teki  
> > > > wrote:
> > > > >
> > > > > Hi Chen-Yu,
> > > > >
> > > > > On Fri, Mar 27, 2020 at 10:12 AM Chen-Yu Tsai  wrote:
> > > > > >
> > > > > > From: Chen-Yu Tsai 
> > > > > >
> > > > > > The ROC-RK3328-CC from Firefly and Libre Computer Project is a 
> > > > > > credit
> > > > > > card size development board based on the Rockchip RK3328 SoC, with:
> > > > > >
> > > > > >   - 1/2/4 GB DDR4 DRAM
> > > > > >   - eMMC connector for optional module
> > > > > >   - micro SD card slot
> > > > > >   - 1 x USB 3.0 host port
> > > > > >   - 2 x USB 2.0 host port
> > > > > >   - 1 x USB 2.0 OTG port
> > > > > >   - HDMI video output
> > > > > >   - TRRS connector with audio and composite video output
> > > > > >   - gigabit Ethernet
> > > > > >   - consumer IR receiver
> > > > > >   - debug UART pins
> > > > > >
> > > > > > The ROC-RK3328-CC has the enable pin of the SD card power switch 
> > > > > > tied
> > > > > > to GPIO_0_D6. This pin also has the function SDMMC0_PWREN, which is
> > > > > > muxed by default. SDMMC0_PWREN is an active high signal controlled 
> > > > > > by
> > > > > > the MMC controller, however the switch enable is active low, and
> > > > > > pulled low (enabled) by default to make things work on boot.
> > > > > >
> > > > > > As such, we need to mux away from SDMMC0_PWREN and use GPIO to 
> > > > > > enable
> > > > > > power to the card. The default GPIO state for the pin is pull-down 
> > > > > > and
> > > > > > input, which doesn't require extra configuration when paired with 
> > > > > > the
> > > > > > external pull-down and active low switch.
> > > > > >
> > > > > > Thus we make a custom target for this board and do the muxing in its
> > > > > > spl_board_init() function.
> > > > > >
> > > > > > The device tree file is synced from the Linux kernel next-20200324.
> > > > > >
> > > > > > Signed-off-by: Chen-Yu Tsai 
> > > > > > ---
> > > > >
> > > > > [snip]
> > > > >
> > > > > > diff --git a/board/firefly/roc-cc-rk3328/MAINTAINERS 
> > > > > > b/board/firefly/roc-cc-rk3328/MAINTAINERS
> > > > > > new file mode 100644
> > > > > > index ..f2318e71ac33
> > > > > > --- /dev/null
> > > > > > +++ b/board/firefly/roc-cc-rk3328/MAINTAINERS
> > > > > > @@ -0,0 +1,7 @@
> > > > > > +ROC-RK3328-CC
> > > > > > +M:  Loic Devulder 
> > > > > > +M: Chen-Yu Tsai 
> > > > > > +S:  Maintained
> > > > > > +F: board/firefly/roc-cc-rk3328/
> > > > > > +F:  configs/roc-rk3328-cc_defconfig
> > > > > > +F:  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
> > > > > > diff --git a/board/firefly/roc-cc-rk3328/Makefile 
> > > > > > b/board/firefly/roc-cc-rk3328/Makefile
> > > > > > new file mode 100644
> > > > > > index ..1550b5f5f16e
> > > > > > --- /dev/null
> > > > > > +++ b/board/firefly/roc-cc-rk3328/Makefile
> > > > > > @@ -0,0 +1 @@
> > > > > > +obj-y  := board.o
> > > > > > diff --git a/board/firefly/roc-cc-rk3328/board.c 
> > > > > > b/board/firefly/roc-cc-rk3328/board.c
> > > > > > new file mode 100644
> > > > > > index ..eca58c86b53e
> > > > > > --- /dev/null
> > > > > > +++ b/board/firefly/roc-cc-rk3328/board.c
> > > > > > @@ -0,0 +1,38 @@
> > > > > > +// SPDX-License-Identifier: GPL-2.0+
> > &g

[PATCH v2 4/6] dt-bindings: power: rk3328-power: sync from upstream Linux kernel

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

This syncs the rk3328 power domain header file from Linux kernel
next-20200324, to support newer hardware blocks when syncing the
device tree files.

The last non-merge commit to touch it was

b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to 
files with no license")

Reviewed-by: Kever Yang 
Signed-off-by: Chen-Yu Tsai 
---
Changes since v1:
  - Added Kever's reviewed-by
---
 include/dt-bindings/power/rk3328-power.h | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 include/dt-bindings/power/rk3328-power.h

diff --git a/include/dt-bindings/power/rk3328-power.h 
b/include/dt-bindings/power/rk3328-power.h
new file mode 100644
index ..02e3d7fc1cce
--- /dev/null
+++ b/include/dt-bindings/power/rk3328-power.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __DT_BINDINGS_POWER_RK3328_POWER_H__
+#define __DT_BINDINGS_POWER_RK3328_POWER_H__
+
+/**
+ * RK3328 idle id Summary.
+ */
+#define RK3328_PD_CORE 0
+#define RK3328_PD_GPU  1
+#define RK3328_PD_BUS  2
+#define RK3328_PD_MSCH 3
+#define RK3328_PD_PERI 4
+#define RK3328_PD_VIDEO5
+#define RK3328_PD_HEVC 6
+#define RK3328_PD_SYS  7
+#define RK3328_PD_VPU  8
+#define RK3328_PD_VIO  9
+
+#endif
-- 
2.26.0

[PATCH v2 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Hi everyone,

This is v2 of my ROC-RK3328-CC series. Changes from v1 are mainly
dropping the custom board target, and dealing with the pinmuxing
through proper use of DM regulators / GPIO / pinctrl in SPL.

This series adds proper support for Firefly / Libre Computer ROC-RK3328-CC
single board computer.

The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
card size development board based on the Rockchip RK3328 SoC, with:

  - 1/2/4 GB DDR4 DRAM
  - eMMC connector for optional module
  - micro SD card slot
  - 1 x USB 3.0 host port
  - 2 x USB 2.0 host port
  - 1 x USB 2.0 OTG port
  - HDMI video output
  - TRRS connector with audio and composite video output
  - gigabit Ethernet
  - consumer IR receiver
  - debug UART pins

Originally I started with Loic's patches, and syncing the device tree
files from Linux. That didn't get very far, with SPL failing to detect
the SD card. Examining the schematics and internal state of GRF and
GPIOs, I realized that the logic for the SD card power enable switch
is opposite that of what the SD card controller's SDMMC0_PWREN pin
would use. Instead, directly using the GPIO is required.

To deal with this, DM regulator and GPIO are enabled in SPL, and
various device nodes are marked with u-boot,dm-spl to have them work.
pinctrl properties are not stripped, so as to have the SDMMC0_PWREN
pin muxed over to GPIO.

Along the way, there are some clean-ups of existing dts files, moving
U-boot only features to -u-boot.dtsi files, and then a wholesale sync
from Linux. Only boards already existing in U-boot are synced. DT
binding header files are synced separately as there is already one
patch floating around. The DT sync also includes clean-up changes only
recently posted, and likely won't make it in for at least a few weeks.

Please have a look, and test if possible. I cc-ed a couple people that
showed interest in this board on mailing lists recently.

Regards
ChenYu


Chen-Yu Tsai (6):
  rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-boot.dtsi
  rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-boot.dtsi
  dt-bindings: clock: rk3328: sync from upstream Linux kernel
  dt-bindings: power: rk3328-power: sync from upstream Linux kernel
  rockchip: dts: rk3328: Sync device tree files from Linux
  rockchip: rk3328: Add support for ROC-RK3328-CC board

 arch/arm/dts/Makefile |1 +
 arch/arm/dts/rk3328-evb-u-boot.dtsi   |   39 +
 arch/arm/dts/rk3328-evb.dts   |  220 +--
 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi|   38 +
 .../{rk3328-rock64.dts => rk3328-roc-cc.dts}  |  135 +-
 arch/arm/dts/rk3328-rock64.dts|  132 +-
 arch/arm/dts/rk3328.dtsi  | 1420 +++--
 board/rockchip/evb_rk3328/MAINTAINERS |7 +
 configs/roc-cc-rk3328_defconfig   |  103 ++
 doc/README.rockchip   |4 +-
 include/dt-bindings/clock/rk3328-cru.h|  212 +--
 include/dt-bindings/power/rk3328-power.h  |   19 +
 12 files changed, 1578 insertions(+), 752 deletions(-)
 create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
 copy arch/arm/dts/{rk3328-rock64.dts => rk3328-roc-cc.dts} (68%)
 create mode 100644 configs/roc-cc-rk3328_defconfig
 create mode 100644 include/dt-bindings/power/rk3328-power.h

-- 
2.26.0

[PATCH v2 1/6] rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-boot.dtsi

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

USB 3.0 is only supported in U-boot, not in the Linux kernel where the
device tree files are ultimately synced from. While the xhci node was
moved, the external vbus regulator was not.

Move it as well.

Fixes: 2e91e2025c1b ("rockchip: rk3328: migrate u-boot node to -u-boot.dtsi")
Reviewed-by: Kever Yang 
Signed-off-by: Chen-Yu Tsai 
---
Changes since v1:
  - Added Kever's reviewed-by
---
 arch/arm/dts/rk3328-evb-u-boot.dtsi | 11 +++
 arch/arm/dts/rk3328-evb.dts |  9 -
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 4a827063c555..5679897279aa 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -6,6 +6,17 @@
 #include "rk3328-u-boot.dtsi"
 #include "rk3328-sdram-ddr3-666.dtsi"
 
+/{
+   vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpio = <&gpio0 0 GPIO_ACTIVE_HIGH>;
+   regulator-name = "vcc5v0_host_xhci";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+};
+
 &usb_host0_xhci {
vbus-supply = <&vcc5v0_host_xhci>;
status = "okay";
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index a2ee838fcd6b..e9bc849f8c23 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -38,15 +38,6 @@
regulator-max-microvolt = <500>;
};
 
-   vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
-   compatible = "regulator-fixed";
-   enable-active-high;
-   regulator-name = "vcc5v0_host_xhci";
-   gpio = <&gpio0 0 GPIO_ACTIVE_HIGH>;
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   };
-
vcc_phy: vcc-phy-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc_phy";
-- 
2.26.0

[PATCH v2 5/6] rockchip: dts: rk3328: Sync device tree files from Linux

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

This syncs rk3328 device tree files from the Linux kernel next-20200324.
The last commit to touch these files is:

b2411befed60 ("arm64: dts: add bus to rockchip amba nodenames")

Additional changes not yet in the Linux kernel include:

arm64: dts: rockchip: rk3328: drop #address-cells, #size-cells from grf node
arm64: dts: rockchip: rk3328: drop non-existent gmac2phy pinmux options
arm64: dts: rockchip: rk3328: Replace RK805 PMIC node name with "pmic"

Changes include:

  - conversion of raw pin numbers to macros
  - removal of deprecated RK_FUNC_* macros
  - update of device tree binding headers
  - new devices
  - device tree cleanups
  - gmac2phy disabled in -u-boot.dtsi as it is not supported in U-boot

Reviewed-by: Kever Yang 
Signed-off-by: Chen-Yu Tsai 
---
Changes since v1:
  - Added Kever's reviewed-by
---
 arch/arm/dts/rk3328-evb-u-boot.dtsi |5 +
 arch/arm/dts/rk3328-evb.dts |  196 ++--
 arch/arm/dts/rk3328-rock64.dts  |  132 ++-
 arch/arm/dts/rk3328.dtsi| 1420 +--
 4 files changed, 1164 insertions(+), 589 deletions(-)

diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 8ba53cf8f44b..4bfa0c2330ba 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -40,6 +40,11 @@
status = "okay";
 };
 
+&gmac2phy {
+   /* Integrated PHY unsupported by U-boot */
+   status = "broken";
+};
+
 &usb_host0_xhci {
vbus-supply = <&vcc5v0_host_xhci>;
status = "okay";
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index 97bef37cf610..6abc6f4a86cf 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -1,6 +1,6 @@
-// SPDX-License-Identifier: GPL-2.0+
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
 /*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
  */
 
 /dts-v1/;
@@ -11,24 +11,51 @@
compatible = "rockchip,rk3328-evb", "rockchip,rk3328";
 
chosen {
-   stdout-path = &uart2;
+   stdout-path = "serial2:150n8";
};
 
-   vcc3v3_sdmmc: sdmmc-pwren {
+   dc_12v: dc-12v {
compatible = "regulator-fixed";
-   regulator-name = "vcc3v3";
-   gpio = <&gpio0 30 GPIO_ACTIVE_LOW>;
+   regulator-name = "dc_12v";
regulator-always-on;
regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+
+   sdio_pwrseq: sdio-pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   pinctrl-names = "default";
+   pinctrl-0 = <&wifi_enable_h>;
+
+   /*
+* On the module itself this is one of these (depending
+* on the actual card populated):
+* - SDIO_RESET_L_WL_REG_ON
+* - PDN (power down when low)
+*/
+   reset-gpios = <&gpio1 18 GPIO_ACTIVE_LOW>;
+   };
+
+   vcc_sd: sdmmc-regulator {
+   compatible = "regulator-fixed";
+   gpio = <&gpio0 30 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&sdmmc0m1_gpio>;
+   regulator-name = "vcc_sd";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <&vcc_io>;
};
 
-   vcc5v0_otg: vcc5v0-otg-drv {
+   vcc_sys: vcc-sys {
compatible = "regulator-fixed";
-   enable-active-high;
-   regulator-name = "vcc5v0_otg";
-   gpio = <&gpio0 27 GPIO_ACTIVE_HIGH>;
+   regulator-name = "vcc_sys";
+   regulator-always-on;
+   regulator-boot-on;
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
+   vin-supply = <&dc_12v>;
};
 
vcc_phy: vcc-phy-regulator {
@@ -39,80 +66,60 @@
};
 };
 
-&saradc {
-   status = "okay";
-};
-
-&uart2 {
-   status = "okay";
-};
-
-&sdmmc {
-   bus-width = <4>;
-   cap-mmc-highspeed;
-   cap-sd-highspeed;
-   card-detect-delay = <200>;
-   disable-wp;
-   num-slots = <1>;
-   pinctrl-names = "default";
-   pinctrl-0 = <&sdmmc0_clk>, <&sdmmc0_cmd>, <&sdmmc0_dectn>, 
<&sdmmc0_bus4>;
-   status = "oka

[PATCH v2 3/6] dt-bindings: clock: rk3328: sync from upstream Linux kernel

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

This syncs the rk3328 clock header file from Linux kernel next-20200324,
to support newer hardware blocks when syncing the device tree files.

The last non-merge commit to touch it was

0dc14b013f79 ("clk: rockchip: add clock id for watchdog pclk on rk3328")

Reviewed-by: Kever Yang 
Signed-off-by: Chen-Yu Tsai 
---
Changes since v1:
  - Added Kever's reviewed-by
---
 include/dt-bindings/clock/rk3328-cru.h | 212 -
 1 file changed, 106 insertions(+), 106 deletions(-)

diff --git a/include/dt-bindings/clock/rk3328-cru.h 
b/include/dt-bindings/clock/rk3328-cru.h
index cde61ed8830b..555b4ff660ae 100644
--- a/include/dt-bindings/clock/rk3328-cru.h
+++ b/include/dt-bindings/clock/rk3328-cru.h
@@ -1,6 +1,7 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
+/* SPDX-License-Identifier: GPL-2.0-or-later */
 /*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
+ * Author: Elaine 
  */
 
 #ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3328_H
@@ -90,119 +91,118 @@
 #define SCLK_MAC2IO_EXT102
 
 /* dclk gates */
-#define DCLK_LCDC  180
-#define DCLK_HDMIPHY   181
-#define HDMIPHY182
-#define USB480M183
-#define DCLK_LCDC_SRC  184
+#define DCLK_LCDC  120
+#define DCLK_HDMIPHY   121
+#define HDMIPHY122
+#define USB480M123
+#define DCLK_LCDC_SRC  124
 
 /* aclk gates */
-#define ACLK_AXISRAM   190
-#define ACLK_VOP_PRE   191
-#define ACLK_USB3OTG   192
-#define ACLK_RGA_PRE   193
-#define ACLK_DMAC  194
-#define ACLK_GPU   195
-#define ACLK_BUS_PRE   196
-#define ACLK_PERI_PRE  197
-#define ACLK_RKVDEC_PRE198
-#define ACLK_RKVDEC199
-#define ACLK_RKVENC200
-#define ACLK_VPU_PRE   201
-#define ACLK_VIO_PRE   202
-#define ACLK_VPU   203
-#define ACLK_VIO   204
-#define ACLK_VOP   205
-#define ACLK_GMAC  206
-#define ACLK_H265  207
-#define ACLK_H264  208
-#define ACLK_MAC2PHY   209
-#define ACLK_MAC2IO210
-#define ACLK_DCF   211
-#define ACLK_TSP   212
-#define ACLK_PERI  213
-#define ACLK_RGA   214
-#define ACLK_IEP   215
-#define ACLK_CIF   216
-#define ACLK_HDCP  217
+#define ACLK_AXISRAM   130
+#define ACLK_VOP_PRE   131
+#define ACLK_USB3OTG   132
+#define ACLK_RGA_PRE   133
+#define ACLK_DMAC  134
+#define ACLK_GPU   135
+#define ACLK_BUS_PRE   136
+#define ACLK_PERI_PRE  137
+#define ACLK_RKVDEC_PRE138
+#define ACLK_RKVDEC139
+#define ACLK_RKVENC140
+#define ACLK_VPU_PRE   141
+#define ACLK_VIO_PRE   142
+#define ACLK_VPU   143
+#define ACLK_VIO   144
+#define ACLK_VOP   145
+#define ACLK_GMAC  146
+#define ACLK_H265  147
+#define ACLK_H264  148
+#define ACLK_MAC2PHY   149
+#define ACLK_MAC2IO150
+#define ACLK_DCF   151
+#define ACLK_TSP   152
+#define ACLK_PERI  153
+#define ACLK_RGA   154
+#define ACLK_IEP   155
+#define ACLK_CIF   156
+#define ACLK_HDCP  157
 
 /* pclk gates */
-#define PCLK_GPIO0 300
-#define PCLK_GPIO1 301
-#define PCLK_GPIO2 302
-#define PCLK_GPIO3 303
-#define PCLK_GRF   304
-#define PCLK_I2C0  305
-#define PCLK_I2C1  306
-#define PCLK_I2C2  307
-#define PCLK_I2C3  308
-#define PCLK_SPI   309
-#define PCLK_UART0 310
-#define PCLK_UART1 311
-#define PCLK_UART2 312
-#define PCLK_TSADC 313
-#define PCLK_PWM   314
-#define PCLK_TIMER 315
-#define PCLK_BUS_PRE   316
-#define PCLK_PERI_PRE  317
-#define PCLK_HDMI_CTRL 318
-#define PCLK_HDMI_PHY  319
-#define PCLK_GMAC  320
-#define PCLK_H265  321
-#define PCLK_MAC2PHY   322
-#define PCLK_MAC2IO323
-#define PCLK_USB3PHY_OTG   324
-#define PCLK_USB3PHY_PIPE  325
-#define PCLK_USB3_GRF  326
-#define PCLK_USB2_GRF  327
-#define PCLK_HDMIPHY   328
-#define PCLK_DDR   329
-#define PCLK_PERI  330
-#define PCLK_HDMI  331
-#define PCLK_HDCP  332
-#define PCLK_DCF   333
-#define PCLK_SARADC334
+#define PCLK_GPIO0 200
+#define PCLK_GPIO1 201
+#define PCLK_GPIO2 202
+#define PCLK_GPIO3  

[PATCH v2 2/6] rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-boot.dtsi

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The device tree file for rk3328-evb in the Linux kernel does not have
gmac2io enabled. Instead, gmac2phy is enabled, but that is not supported
in U-boot.

Move the gmac2io related nodes to rk3328-evb-u-boot.dtsi to preserve the
current functionality. When the device tree files are synced, gmac2phy
should be marked as "broken" in -u-boot.dtsi files.

Reviewed-by: Kever Yang 
Signed-off-by: Chen-Yu Tsai 
---
Changes since v1:
  - Added Kever's reviewed-by
---
 arch/arm/dts/rk3328-evb-u-boot.dtsi | 23 +++
 arch/arm/dts/rk3328-evb.dts | 23 ---
 2 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 5679897279aa..8ba53cf8f44b 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -7,6 +7,13 @@
 #include "rk3328-sdram-ddr3-666.dtsi"
 
 /{
+   gmac_clkin: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "gmac_clkin";
+   #clock-cells = <0>;
+   };
+
vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
compatible = "regulator-fixed";
enable-active-high;
@@ -17,6 +24,22 @@
};
 };
 
+&gmac2io {
+   phy-supply = <&vcc_phy>;
+   phy-mode = "rgmii";
+   clock_in_out = "input";
+   snps,reset-gpio = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>;
+   snps,reset-active-low;
+   snps,reset-delays-us = <0 1 5>;
+   assigned-clocks = <&cru SCLK_MAC2IO>, <&cru SCLK_MAC2IO_EXT>;
+   assigned-clock-parents = <&gmac_clkin>, <&gmac_clkin>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&rgmiim1_pins>;
+   tx_delay = <0x26>;
+   rx_delay = <0x11>;
+   status = "okay";
+};
+
 &usb_host0_xhci {
vbus-supply = <&vcc5v0_host_xhci>;
status = "okay";
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index e9bc849f8c23..97bef37cf610 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -14,13 +14,6 @@
stdout-path = &uart2;
};
 
-   gmac_clkin: external-gmac-clock {
-   compatible = "fixed-clock";
-   clock-frequency = <12500>;
-   clock-output-names = "gmac_clkin";
-   #clock-cells = <0>;
-   };
-
vcc3v3_sdmmc: sdmmc-pwren {
compatible = "regulator-fixed";
regulator-name = "vcc3v3";
@@ -78,22 +71,6 @@
status = "okay";
 };
 
-&gmac2io {
-   phy-supply = <&vcc_phy>;
-   phy-mode = "rgmii";
-   clock_in_out = "input";
-   snps,reset-gpio = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>;
-   snps,reset-active-low;
-   snps,reset-delays-us = <0 1 5>;
-   assigned-clocks = <&cru SCLK_MAC2IO>, <&cru SCLK_MAC2IO_EXT>;
-   assigned-clock-parents = <&gmac_clkin>, <&gmac_clkin>;
-   pinctrl-names = "default";
-   pinctrl-0 = <&rgmiim1_pins>;
-   tx_delay = <0x26>;
-   rx_delay = <0x11>;
-   status = "okay";
-};
-
 &usb_host0_ehci {
status = "okay";
 };
-- 
2.26.0

[PATCH v2 6/6] rockchip: rk3328: Add support for ROC-RK3328-CC board

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
card size development board based on the Rockchip RK3328 SoC, with:

  - 1/2/4 GB DDR4 DRAM
  - eMMC connector for optional module
  - micro SD card slot
  - 1 x USB 3.0 host port
  - 2 x USB 2.0 host port
  - 1 x USB 2.0 OTG port
  - HDMI video output
  - TRRS connector with audio and composite video output
  - gigabit Ethernet
  - consumer IR receiver
  - debug UART pins

The ROC-RK3328-CC has the enable pin of the SD card power switch tied
to GPIO_0_D6. This pin also has the function SDMMC0_PWREN, which is
muxed by default. SDMMC0_PWREN is an active high signal controlled by
the MMC controller, however the switch enable is active low, and
pulled low (enabled) by default to make things work on boot.

As such, we need to mux away from SDMMC0_PWREN and use GPIO to enable
power to the card. The default GPIO state for the pin is pull-down and
input, which doesn't require extra configuration when paired with the
external pull-down and active low switch.

Deal with this by enabling regulator support in SPL, and setting
"u-boot,dm-spl" for the regulator and other device nodes needed for
muxing the pin.

The device tree file is synced from the Linux kernel next-20200324.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v1:

  - Drop custom target; use pinctrl and regulators in SPL
---
 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi |  38 +++
 arch/arm/dts/rk3328-roc-cc.dts | 354 +
 board/rockchip/evb_rk3328/MAINTAINERS  |   7 +
 configs/roc-cc-rk3328_defconfig| 103 +++
 doc/README.rockchip|   4 +-
 6 files changed, 506 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3328-roc-cc.dts
 create mode 100644 configs/roc-cc-rk3328_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9c593b2c986a..023cb010532d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -104,6 +104,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3308) += \
 
 dtb-$(CONFIG_ROCKCHIP_RK3328) += \
rk3328-evb.dtb \
+   rk3328-roc-cc.dtb \
rk3328-rock64.dtb
 
 dtb-$(CONFIG_ROCKCHIP_RK3368) += \
diff --git a/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi 
b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
new file mode 100644
index ..c268fbb9b5b6
--- /dev/null
+++ b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2018-2019 Rockchip Electronics Co., Ltd
+ */
+
+#include "rk3328-u-boot.dtsi"
+#include "rk3328-sdram-ddr4-666.dtsi"
+/ {
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", &sdmmc, &emmc;
+   };
+};
+
+&gpio0 {
+   u-boot,dm-spl;
+};
+
+&pinctrl {
+   u-boot,dm-spl;
+};
+
+&sdmmc0m1_gpio {
+   u-boot,dm-spl;
+};
+
+&pcfg_pull_up_4ma {
+   u-boot,dm-spl;
+};
+
+&usb_host0_xhci {
+   vbus-supply = <&vcc_host1_5v>;
+   status = "okay";
+};
+
+/* Need this and all the pinctrl/gpio stuff above to set pinmux */
+&vcc_sd {
+   u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/rk3328-roc-cc.dts b/arch/arm/dts/rk3328-roc-cc.dts
new file mode 100644
index ..8d553c92182a
--- /dev/null
+++ b/arch/arm/dts/rk3328-roc-cc.dts
@@ -0,0 +1,354 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 T-Chip Intelligent Technology Co., Ltd
+ */
+
+/dts-v1/;
+#include "rk3328.dtsi"
+
+/ {
+   model = "Firefly roc-rk3328-cc";
+   compatible = "firefly,roc-rk3328-cc", "rockchip,rk3328";
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   gmac_clkin: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "gmac_clkin";
+   #clock-cells = <0>;
+   };
+
+   dc_12v: dc-12v {
+   compatible = "regulator-fixed";
+   regulator-name = "dc_12v";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+
+   vcc_sd: sdmmc-regulator {
+   compatible = "regulator-fixed";
+   gpio = <&gpio0 RK_PD6 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&sdmmc0m1_gpio>;
+   regulator-boot-on;
+   regulator-name = "vcc_sd";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <&vcc

Re: arm64: rk3399: Add support NanoPi R4s

[Chen-Yu Tsai]

Hi,

On Mon, Feb 1, 2021 at 9:58 AM Kever Yang  wrote:
>
> Hi Xiaobo,
>
>
>  Thanks for your update, see comments in line.
>
> On 2021/1/29 下午10:34, alex tian wrote:
> > From c9563fe439e07e760d29a42e737b8265d5772150 Mon Sep 17 00:00:00 2001
> > From: Xiaobo Tian mailto:peterwil...@gmail.com>>
> > Date: Fri, 29 Jan 2021 22:30:22 +0800
> > Subject: [PATCH] arm64: rk3399: Add support NanoPi R4s
>
> You need to update the patch version, this is at lease version 4, and
> please add change log
>
> for what have been update in new version, these can be found in the link
> I share with you in previous review.
>
> >
> > NanoPi R4s [1] is SBC base on Rockchip RK3399 hexa-core processor with
> > dual-Core Cortex-A72 and Mali-T864 GPU with 4GiB(LPDDR4) of RAM, SD
> > card support,
> > including 2 gigabit ethernet(RTL8211E 1Gbps - RTL8111H 1Gbps) and 2
> > USB 3.0 port.
> > port.It also has two GPIO headers which allows further peripherals to
> > be used.
> >
> > The devicetree file is taken of the rk3399 nanopi4 Linux kernel [2].
> we need a commit number in mainline kernel instead of file link.
> >
> > [1] https://wiki.friendlyarm.com/wiki/index.php/NanoPi_R4S
> This product is no need in the commit message.
> > [2]
> > https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
> >
> > Cc: Tom Rini mailto:tr...@konsulko.com>>
> > Cc: Kever Yang  > >
> > Reviewed-by: Kever Yang  > >
>
>
> Please don't add my review tag before I reply it to the list with
> "Reviewed-by..." message.
>
> One more thing is that please make sure this patch can pass the
> checkpatch script, 10 warnings for this patch now,
>
> and you will need to add MAINTAINERS info for this board at
> board/rockchip/evb_rk3399/MAINTAINERS if you
>
> want to follow evb with everything other than dts, or else you will need
> to add a board at board/friendlyarm/.
>
>
> Thanks,
>
> - Kever
>
> > Signed-off-by: Xiaobo Tian  > >
> > ---
> >  arch/arm/dts/Makefile  |   1 +
> >  arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi |   7 ++
> >  arch/arm/dts/rk3399-nanopi-r4s.dts | 129 +
> >  configs/nanopi-r4s-rk3399_defconfig|  62 ++
> >  4 files changed, 199 insertions(+)
> >  create mode 100644 arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
> >  create mode 100644 arch/arm/dts/rk3399-nanopi-r4s.dts
> >  create mode 100644 configs/nanopi-r4s-rk3399_defconfig
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 858b79ac97..528dfe069e 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -92,6 +92,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3288) += \
> >   rk3288-evb.dtb \
> >   rk3288-firefly.dtb \
> >   rk3288-miqi.dtb \
> > + rk3399-nanopi-r4s.dtb \
> >   rk3288-phycore-rdk.dtb \
> >   rk3288-popmetal.dtb \
> >   rk3288-rock2-square.dtb \
> > diff --git a/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
> > b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
> > new file mode 100644
> > index 00..df193f0e64
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
> > @@ -0,0 +1,7 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2020 Xiaobo  > >
> > + */
> > +
> > +#include "rk3399-nanopi4-u-boot.dtsi"
> > +#include "rk3399-sdram-lpddr4-100.dtsi"

Because of this ...

> > diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts
> > b/arch/arm/dts/rk3399-nanopi-r4s.dts
> > new file mode 100644
> > index 00..36d55fed39
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3399-nanopi-r4s.dts
> > @@ -0,0 +1,129 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright (c) 2020 FriendlyElec Computer Tech. Co., Ltd.
> > + * (http://www.friendlyarm.com)
> > + *
> > + * Copyright (C) 2020 Xiaobo  > >
> > + */
> > +
> > +/dts-v1/;
> > +#include "rk3399-nanopi4.dtsi"
> > +
> > +/ {
> > + model = "FriendlyElec NanoPi R4S";
> > + compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399";
> > +
> > +  cpuinfo {
> > +  compatible = "rockchip,cpuinfo";
> > +  nvmem-cells = <&cpu_id>;
> > +  nvmem-cell-names = "id";
> > +  };
> > +
> > +  aliases {
> > +  ethernet1 = &r8169;
> > +  };
> > +
> > + vdd_5v: vdd-5v {
> > + compatible = "regulator-fixed";
> > + regulator-name = "vdd_5v";
> > + regulator-always-on;
> > + regulator-boot-on;
> > + };
> > +
> > + fan: pwm-fan {
> > + compatible = "pwm-fan";
> > + cooling-levels = <0 12 18 255>;
> > + #cooling-cells = <2>;
> > + fan-supply = <&vdd_5v>;
> > + pwms = <&pwm1 0 5 0>;
> > + };
> > +};
> > +
> > +&cpu_thermal {
> > + trips {
> > + cpu_warm: cpu_warm {
> > + temperature = <55000>;
> > + hysteresis = <2000>;
> > + type = "active";
> > + };
> > +
> > + cpu_hot: cpu_hot {
> > + temperature = <65000>;
> > + hysteresis = <2000>;
> > + type = "active";
> > + };
> > + };
> > +
> > + cooling-ma

Re: arm64: rk3399: Add support nanopi r4s

[Chen-Yu Tsai]

Hi,

On Mon, Feb 8, 2021 at 9:46 AM alex tian  wrote:
>
> From 01598339be9dbeec6ba41c470b29af1c53e29c40 Mon Sep 17 00:00:00 2001
> From: Xiaobo Tian 
> Date: Mon, 8 Feb 2021 09:40:03 +0800
> Subject: [PATCH] arm64: rk3399: Add support NanoPi R4s

Please tag patches with versions or "resent" if no changes were made.

Also, your patch is pretty messed up, especially on patchwork. For example,
the indents are all wrong. On patchwork, parts of the diff even end up
out of order or in the header.

Please do not copy-paste your patch from a terminal window or editor into
your mail client. Instead, use `git send-email` to send patches.

ChenYu

Re: [PATCH] arch: arm: rockchip: order the rk3399 entries alphabetically

[Chen-Yu Tsai]

On Mon, Jan 20, 2020 at 7:06 PM Peter Robinson  wrote:
>
> On Mon, 20 Jan 2020, 10:08 Kever Yang,  wrote:
>
> > Hi Peter,
> >
> > On 2020/1/20 下午5:22, Peter Robinson wrote:
> > > On Mon, Jan 13, 2020 at 7:03 AM Kever Yang 
> > wrote:
> > >> Hi Peter,
> > >>
> > >> On 2020/1/8 上午11:56, Peter Robinson wrote:
> > >>> Put the target entries for rk3399 devices in alphabetical order.
> > >>>
> > >>> Signed-off-by: Peter Robinson 
> > >> Reviewed-by: Kever Yang 
> > > Any reason this didn't make the latest rockchip MR?
> >
> > This patch break the build for rk3399 boards other than chromebook_bob,
> >
> > and I have to leave it until other boards add CONFIG_TARGET_* to pass
> > the build.
> >
>
> How would it do that by simply reordering a kconfig file? I've tested it
> with at least building evm, rock960, rockpro64 and firefly 3399 builds with
> out issues.

AFAICT if the defconfig has no preferred setting, then the first entry
is used. The targets you tested likely all had a preferred setting, but
other ones such as the NanoPi M4 did not, and was counting on the EVB
target being the default.

ChenYu

Re: [PATCH V2] rockchip: rk3328: add rockpie-rk3328_defconfig

[Chen-Yu Tsai]

On Thu, Apr 9, 2020 at 7:12 PM b.l.huang  wrote:
>
> From f4253df37579aa9d48f98738eb7db3b6a3b9dff5 Mon Sep 17 00:00:00 2001
> From: "banglang.huang" 
> Date: Thu, 9 Apr 2020 11:49:31 +0800
> Subject: [PATCH V2] rockchip: rk3328: add rockpie-rk3328_defconfig
>
> The ROCKPI-E is a credit card size SBC based on Rockchip RK3328
> Quad-Core ARM Cortex A53.
>
> Net - Dual ethernet port, 1 X Gbe, 1 X 100M
> USB - USB 3.0
> DC  - USB-Type C, 5V 2A
> Storage - TF card, eMMC
>
> Just build u-boot-dtb.bin for Rockpi E board and follow the blow
> steps to replace the relevant partition.
>
>   ./rkbin/tools/loaderimage --pack --uboot u-boot-dtb.bin \
>   uboot.img 0x20 --size 1024 1
>   dd if=uboot.img of=/dev/sdcard seek=16384 conv=notrunc
>
> Signed-off-by: banglang.huang 
> ---
>
> Changes for v2
>
> - add introduction for rockpie in doc/README.rockchip
> - enable CONFIG_MISC_INIT_R, CONFIG_SMBIOS_MANUFACTURER,
>   and CONFIG_SMBIOS_PRODUCT_NAME
>
>  arch/arm/dts/Makefile   |   3 +-
>  arch/arm/dts/rk3328-rockpie-u-boot.dtsi |  12 ++
>  arch/arm/dts/rk3328-rockpie.dts | 256 
>  board/rockchip/evb_rk3328/MAINTAINERS   |   7 +
>  configs/rockpie-rk3328_defconfig|  99 +

Can you separate the different bits of the board name?
For instance we already have

rock-pi-4-rk3399_defconfig / rk3399-rock-pi-4.dts,
so

rock-pi-e-rk3328_defconfig / rk3328-rock-pi-e.dts

should fit the bill.

Also, rockpie will not be pronounced the same way as rock-pi-e.
Rockpie will simply become rock pi, which does wonders for figuring
out which board one is referring to.

ChenYu

Re: [PATCH v2 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board

[Chen-Yu Tsai]

Hi,

On Tue, Apr 21, 2020 at 1:35 AM Peter Geis  wrote:
>
> On Thu, Apr 16, 2020 at 5:53 AM Loic Devulder  wrote:
> >
> > Hi Chen,
> >
> > I tested your patches and all work pretty well. I just had issues with
> > USB2 that doesn't recognize any of my USB keys (it's OK on USB3).
> >
> > I also had these issues with XHCI driver:
> > => usb reset
> > resetting USB...
> > BUG at drivers/usb/host/xhci-mem.c:84/xhci_ring_free()!
> > BUG!
> > �esetting ...
> >
> > => usb stop
> > stopping USB..
> > Host not halted after 16000 microseconds.
> > XHCI: failed to set VBus supply
> > device_remove: Device 'usb@ff60' failed to remove, but children are
> > gone
> >
> > But for the whole series: Tested-by: Loic Devulder 
> >
> > On Sun, 2020-04-05 at 10:25 +0800, Chen-Yu Tsai wrote:
> > > From: Chen-Yu Tsai 
> > >
> > > Hi everyone,
> > >
> > > This is v2 of my ROC-RK3328-CC series. Changes from v1 are mainly
> > > dropping the custom board target, and dealing with the pinmuxing
> > > through proper use of DM regulators / GPIO / pinctrl in SPL.
> > >
> > > This series adds proper support for Firefly / Libre Computer ROC-
> > > RK3328-CC
> > > single board computer.
> > >
> > > The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
> > > card size development board based on the Rockchip RK3328 SoC, with:
> > >
> > >   - 1/2/4 GB DDR4 DRAM
> > >   - eMMC connector for optional module
> > >   - micro SD card slot
> > >   - 1 x USB 3.0 host port
> > >   - 2 x USB 2.0 host port
> > >   - 1 x USB 2.0 OTG port
> > >   - HDMI video output
> > >   - TRRS connector with audio and composite video output
> > >   - gigabit Ethernet
> > >   - consumer IR receiver
> > >   - debug UART pins
> > >
> > > Originally I started with Loic's patches, and syncing the device tree
> > > files from Linux. That didn't get very far, with SPL failing to
> > > detect
> > > the SD card. Examining the schematics and internal state of GRF and
> > > GPIOs, I realized that the logic for the SD card power enable switch
> > > is opposite that of what the SD card controller's SDMMC0_PWREN pin
> > > would use. Instead, directly using the GPIO is required.
> > >
> > > To deal with this, DM regulator and GPIO are enabled in SPL, and
> > > various device nodes are marked with u-boot,dm-spl to have them work.
> > > pinctrl properties are not stripped, so as to have the SDMMC0_PWREN
> > > pin muxed over to GPIO.
> > >
> > > Along the way, there are some clean-ups of existing dts files, moving
> > > U-boot only features to -u-boot.dtsi files, and then a wholesale sync
> > > from Linux. Only boards already existing in U-boot are synced. DT
> > > binding header files are synced separately as there is already one
> > > patch floating around. The DT sync also includes clean-up changes
> > > only
> > > recently posted, and likely won't make it in for at least a few
> > > weeks.
> > >
> > > Please have a look, and test if possible. I cc-ed a couple people
> > > that
> > > showed interest in this board on mailing lists recently.
> > >
> > > Regards
> > > ChenYu
> > >
> > >
> > > Chen-Yu Tsai (6):
> > >   rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-
> > > boot.dtsi
> > >   rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-
> > > boot.dtsi
> > >   dt-bindings: clock: rk3328: sync from upstream Linux kernel
> > >   dt-bindings: power: rk3328-power: sync from upstream Linux kernel
> > >   rockchip: dts: rk3328: Sync device tree files from Linux
> > >   rockchip: rk3328: Add support for ROC-RK3328-CC board
> > >
> > >  arch/arm/dts/Makefile |1 +
> > >  arch/arm/dts/rk3328-evb-u-boot.dtsi   |   39 +
> > >  arch/arm/dts/rk3328-evb.dts   |  220 +--
> > >  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi|   38 +
> > >  .../{rk3328-rock64.dts => rk3328-roc-cc.dts}  |  135 +-
> > >  arch/arm/dts/rk3328-rock64.dts|  132 +-
> > >  arch/arm/dts/rk3328.dtsi  | 1420 +++--
> > > 
> > >  board/rockchip/evb_rk3328/MAINTAINERS |7 +
> > >  configs/roc-cc-rk3328_de

Re: [PATCH v2 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board

[Chen-Yu Tsai]

On Fri, Apr 24, 2020 at 5:20 AM Peter Geis  wrote:
>
> On Thu, Apr 23, 2020 at 5:24 AM Chen-Yu Tsai  wrote:
> >
> > Hi,
> >
> > On Tue, Apr 21, 2020 at 1:35 AM Peter Geis  wrote:
> > >
> > > On Thu, Apr 16, 2020 at 5:53 AM Loic Devulder  wrote:
> > > >
> > > > Hi Chen,
> > > >
> > > > I tested your patches and all work pretty well. I just had issues with
> > > > USB2 that doesn't recognize any of my USB keys (it's OK on USB3).
> > > >
> > > > I also had these issues with XHCI driver:
> > > > => usb reset
> > > > resetting USB...
> > > > BUG at drivers/usb/host/xhci-mem.c:84/xhci_ring_free()!
> > > > BUG!
> > > > �esetting ...
> > > >
> > > > => usb stop
> > > > stopping USB..
> > > > Host not halted after 16000 microseconds.
> > > > XHCI: failed to set VBus supply
> > > > device_remove: Device 'usb@ff60' failed to remove, but children are
> > > > gone
> > > >
> > > > But for the whole series: Tested-by: Loic Devulder 
> > > >
> > > > On Sun, 2020-04-05 at 10:25 +0800, Chen-Yu Tsai wrote:
> > > > > From: Chen-Yu Tsai 
> > > > >
> > > > > Hi everyone,
> > > > >
> > > > > This is v2 of my ROC-RK3328-CC series. Changes from v1 are mainly
> > > > > dropping the custom board target, and dealing with the pinmuxing
> > > > > through proper use of DM regulators / GPIO / pinctrl in SPL.
> > > > >
> > > > > This series adds proper support for Firefly / Libre Computer ROC-
> > > > > RK3328-CC
> > > > > single board computer.
> > > > >
> > > > > The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
> > > > > card size development board based on the Rockchip RK3328 SoC, with:
> > > > >
> > > > >   - 1/2/4 GB DDR4 DRAM
> > > > >   - eMMC connector for optional module
> > > > >   - micro SD card slot
> > > > >   - 1 x USB 3.0 host port
> > > > >   - 2 x USB 2.0 host port
> > > > >   - 1 x USB 2.0 OTG port
> > > > >   - HDMI video output
> > > > >   - TRRS connector with audio and composite video output
> > > > >   - gigabit Ethernet
> > > > >   - consumer IR receiver
> > > > >   - debug UART pins
> > > > >
> > > > > Originally I started with Loic's patches, and syncing the device tree
> > > > > files from Linux. That didn't get very far, with SPL failing to
> > > > > detect
> > > > > the SD card. Examining the schematics and internal state of GRF and
> > > > > GPIOs, I realized that the logic for the SD card power enable switch
> > > > > is opposite that of what the SD card controller's SDMMC0_PWREN pin
> > > > > would use. Instead, directly using the GPIO is required.
> > > > >
> > > > > To deal with this, DM regulator and GPIO are enabled in SPL, and
> > > > > various device nodes are marked with u-boot,dm-spl to have them work.
> > > > > pinctrl properties are not stripped, so as to have the SDMMC0_PWREN
> > > > > pin muxed over to GPIO.
> > > > >
> > > > > Along the way, there are some clean-ups of existing dts files, moving
> > > > > U-boot only features to -u-boot.dtsi files, and then a wholesale sync
> > > > > from Linux. Only boards already existing in U-boot are synced. DT
> > > > > binding header files are synced separately as there is already one
> > > > > patch floating around. The DT sync also includes clean-up changes
> > > > > only
> > > > > recently posted, and likely won't make it in for at least a few
> > > > > weeks.
> > > > >
> > > > > Please have a look, and test if possible. I cc-ed a couple people
> > > > > that
> > > > > showed interest in this board on mailing lists recently.
> > > > >
> > > > > Regards
> > > > > ChenYu
> > > > >
> > > > >
> > > > > Chen-Yu Tsai (6):
> > > > >   rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-
> > > > > boot.dtsi
> > > > >   rockchip: dts: rk3328-evb: Move gmac2io re

[PATCH v3 2/9] rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-boot.dtsi

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The device tree file for rk3328-evb in the Linux kernel does not have
gmac2io enabled. Instead, gmac2phy is enabled, but that is not supported
in U-boot.

Move the gmac2io related nodes to rk3328-evb-u-boot.dtsi to preserve the
current functionality. When the device tree files are synced, gmac2phy
should be marked as "broken" in -u-boot.dtsi files.

Reviewed-by: Kever Yang 
Tested-by: Loic Devulder 
Tested-by: Peter Geis 
Signed-off-by: Chen-Yu Tsai 
---
Changes since v2:
  - none
Changes since v1:
  - Added Kever's reviewed-by
---
 arch/arm/dts/rk3328-evb-u-boot.dtsi | 23 +++
 arch/arm/dts/rk3328-evb.dts | 23 ---
 2 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 5679897279aa..8ba53cf8f44b 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -7,6 +7,13 @@
 #include "rk3328-sdram-ddr3-666.dtsi"
 
 /{
+   gmac_clkin: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "gmac_clkin";
+   #clock-cells = <0>;
+   };
+
vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
compatible = "regulator-fixed";
enable-active-high;
@@ -17,6 +24,22 @@
};
 };
 
+&gmac2io {
+   phy-supply = <&vcc_phy>;
+   phy-mode = "rgmii";
+   clock_in_out = "input";
+   snps,reset-gpio = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>;
+   snps,reset-active-low;
+   snps,reset-delays-us = <0 1 5>;
+   assigned-clocks = <&cru SCLK_MAC2IO>, <&cru SCLK_MAC2IO_EXT>;
+   assigned-clock-parents = <&gmac_clkin>, <&gmac_clkin>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&rgmiim1_pins>;
+   tx_delay = <0x26>;
+   rx_delay = <0x11>;
+   status = "okay";
+};
+
 &usb_host0_xhci {
vbus-supply = <&vcc5v0_host_xhci>;
status = "okay";
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index e9bc849f8c23..97bef37cf610 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -14,13 +14,6 @@
stdout-path = &uart2;
};
 
-   gmac_clkin: external-gmac-clock {
-   compatible = "fixed-clock";
-   clock-frequency = <12500>;
-   clock-output-names = "gmac_clkin";
-   #clock-cells = <0>;
-   };
-
vcc3v3_sdmmc: sdmmc-pwren {
compatible = "regulator-fixed";
regulator-name = "vcc3v3";
@@ -78,22 +71,6 @@
status = "okay";
 };
 
-&gmac2io {
-   phy-supply = <&vcc_phy>;
-   phy-mode = "rgmii";
-   clock_in_out = "input";
-   snps,reset-gpio = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>;
-   snps,reset-active-low;
-   snps,reset-delays-us = <0 1 5>;
-   assigned-clocks = <&cru SCLK_MAC2IO>, <&cru SCLK_MAC2IO_EXT>;
-   assigned-clock-parents = <&gmac_clkin>, <&gmac_clkin>;
-   pinctrl-names = "default";
-   pinctrl-0 = <&rgmiim1_pins>;
-   tx_delay = <0x26>;
-   rx_delay = <0x11>;
-   status = "okay";
-};
-
 &usb_host0_ehci {
status = "okay";
 };
-- 
2.26.0

[PATCH v3 1/9] rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-boot.dtsi

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

USB 3.0 is only supported in U-boot, not in the Linux kernel where the
device tree files are ultimately synced from. While the xhci node was
moved, the external vbus regulator was not.

Move it as well.

Fixes: 2e91e2025c1b ("rockchip: rk3328: migrate u-boot node to -u-boot.dtsi")
Reviewed-by: Kever Yang 
Tested-by: Loic Devulder 
Tested-by: Peter Geis 
Signed-off-by: Chen-Yu Tsai 
---
Changes since v2:
  - none
Changes since v1:
  - Added Kever's reviewed-by
---
 arch/arm/dts/rk3328-evb-u-boot.dtsi | 11 +++
 arch/arm/dts/rk3328-evb.dts |  9 -
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 4a827063c555..5679897279aa 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -6,6 +6,17 @@
 #include "rk3328-u-boot.dtsi"
 #include "rk3328-sdram-ddr3-666.dtsi"
 
+/{
+   vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpio = <&gpio0 0 GPIO_ACTIVE_HIGH>;
+   regulator-name = "vcc5v0_host_xhci";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+};
+
 &usb_host0_xhci {
vbus-supply = <&vcc5v0_host_xhci>;
status = "okay";
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index a2ee838fcd6b..e9bc849f8c23 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -38,15 +38,6 @@
regulator-max-microvolt = <500>;
};
 
-   vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
-   compatible = "regulator-fixed";
-   enable-active-high;
-   regulator-name = "vcc5v0_host_xhci";
-   gpio = <&gpio0 0 GPIO_ACTIVE_HIGH>;
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   };
-
vcc_phy: vcc-phy-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc_phy";
-- 
2.26.0

[PATCH v3 3/9] rockchip: dts: rk3328: Move OTG node's hnp-srp-disable to rk3328-u-boot.dtsi

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The "hnp-srp-disable" property for dwc2 is specific to U-boot, not part
of upstream Linux's device tree bindings.

Move it to rk3328-u-boot.dtsi to avoid losing it when syncing device
tree files.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v2:
  - New patch
---
 arch/arm/dts/rk3328-u-boot.dtsi | 4 
 arch/arm/dts/rk3328.dtsi| 1 -
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/rk3328-u-boot.dtsi b/arch/arm/dts/rk3328-u-boot.dtsi
index 6d5b3ec06e07..c69e13e11efe 100644
--- a/arch/arm/dts/rk3328-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-u-boot.dtsi
@@ -62,3 +62,7 @@
/* mmc to sram can't do dma, prevent aborts transfering TF-A parts */
u-boot,spl-fifo-mode;
 };
+
+&usb20_otg {
+   hnp-srp-disable;
+};
diff --git a/arch/arm/dts/rk3328.dtsi b/arch/arm/dts/rk3328.dtsi
index 060c84e6c0cf..57719b82d13e 100644
--- a/arch/arm/dts/rk3328.dtsi
+++ b/arch/arm/dts/rk3328.dtsi
@@ -483,7 +483,6 @@
 "snps,dwc2";
reg = <0x0 0xff58 0x0 0x4>;
interrupts = ;
-   hnp-srp-disable;
dr_mode = "otg";
status = "disabled";
};
-- 
2.26.0

[PATCH v3 6/9] rockchip: rk3328: Disable generic PHY support

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The USB PHYs on the RK3328 aren't supported, nor are any other generic
PHYs. Because upstream Linux device trees already include the USB PHYs
and references in the USB hosts, this would result in various calls
to the generic PHY API to fail.

Instead, just disable generic PHY support for now.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v2:
  - New patch
---
 configs/evb-rk3328_defconfig| 1 -
 configs/rock64-rk3328_defconfig | 1 -
 2 files changed, 2 deletions(-)

diff --git a/configs/evb-rk3328_defconfig b/configs/evb-rk3328_defconfig
index 5bbdc002148c..7667bb037b3d 100644
--- a/configs/evb-rk3328_defconfig
+++ b/configs/evb-rk3328_defconfig
@@ -61,7 +61,6 @@ CONFIG_SF_DEFAULT_SPEED=2000
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_GMAC_ROCKCHIP=y
-CONFIG_PHY=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
 CONFIG_DM_PMIC=y
diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig
index 826c7a691742..7d096d38c6d0 100644
--- a/configs/rock64-rk3328_defconfig
+++ b/configs/rock64-rk3328_defconfig
@@ -60,7 +60,6 @@ CONFIG_SF_DEFAULT_SPEED=2000
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_GMAC_ROCKCHIP=y
-CONFIG_PHY=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
 CONFIG_DM_PMIC=y
-- 
2.26.0

[PATCH v3 4/9] dt-bindings: clock: rk3328: sync from upstream Linux kernel

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

This syncs the rk3328 clock header file from Linux kernel next-20200324,
to support newer hardware blocks when syncing the device tree files.

The last non-merge commit to touch it was

0dc14b013f79 ("clk: rockchip: add clock id for watchdog pclk on rk3328")

Reviewed-by: Kever Yang 
Tested-by: Loic Devulder 
Tested-by: Peter Geis 
Signed-off-by: Chen-Yu Tsai 
---
Changes since v2:
  - none
Changes since v1:
  - Added Kever's reviewed-by
---
 include/dt-bindings/clock/rk3328-cru.h | 212 -
 1 file changed, 106 insertions(+), 106 deletions(-)

diff --git a/include/dt-bindings/clock/rk3328-cru.h 
b/include/dt-bindings/clock/rk3328-cru.h
index cde61ed8830b..555b4ff660ae 100644
--- a/include/dt-bindings/clock/rk3328-cru.h
+++ b/include/dt-bindings/clock/rk3328-cru.h
@@ -1,6 +1,7 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
+/* SPDX-License-Identifier: GPL-2.0-or-later */
 /*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
+ * Author: Elaine 
  */
 
 #ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3328_H
@@ -90,119 +91,118 @@
 #define SCLK_MAC2IO_EXT102
 
 /* dclk gates */
-#define DCLK_LCDC  180
-#define DCLK_HDMIPHY   181
-#define HDMIPHY182
-#define USB480M183
-#define DCLK_LCDC_SRC  184
+#define DCLK_LCDC  120
+#define DCLK_HDMIPHY   121
+#define HDMIPHY122
+#define USB480M123
+#define DCLK_LCDC_SRC  124
 
 /* aclk gates */
-#define ACLK_AXISRAM   190
-#define ACLK_VOP_PRE   191
-#define ACLK_USB3OTG   192
-#define ACLK_RGA_PRE   193
-#define ACLK_DMAC  194
-#define ACLK_GPU   195
-#define ACLK_BUS_PRE   196
-#define ACLK_PERI_PRE  197
-#define ACLK_RKVDEC_PRE198
-#define ACLK_RKVDEC199
-#define ACLK_RKVENC200
-#define ACLK_VPU_PRE   201
-#define ACLK_VIO_PRE   202
-#define ACLK_VPU   203
-#define ACLK_VIO   204
-#define ACLK_VOP   205
-#define ACLK_GMAC  206
-#define ACLK_H265  207
-#define ACLK_H264  208
-#define ACLK_MAC2PHY   209
-#define ACLK_MAC2IO210
-#define ACLK_DCF   211
-#define ACLK_TSP   212
-#define ACLK_PERI  213
-#define ACLK_RGA   214
-#define ACLK_IEP   215
-#define ACLK_CIF   216
-#define ACLK_HDCP  217
+#define ACLK_AXISRAM   130
+#define ACLK_VOP_PRE   131
+#define ACLK_USB3OTG   132
+#define ACLK_RGA_PRE   133
+#define ACLK_DMAC  134
+#define ACLK_GPU   135
+#define ACLK_BUS_PRE   136
+#define ACLK_PERI_PRE  137
+#define ACLK_RKVDEC_PRE138
+#define ACLK_RKVDEC139
+#define ACLK_RKVENC140
+#define ACLK_VPU_PRE   141
+#define ACLK_VIO_PRE   142
+#define ACLK_VPU   143
+#define ACLK_VIO   144
+#define ACLK_VOP   145
+#define ACLK_GMAC  146
+#define ACLK_H265  147
+#define ACLK_H264  148
+#define ACLK_MAC2PHY   149
+#define ACLK_MAC2IO150
+#define ACLK_DCF   151
+#define ACLK_TSP   152
+#define ACLK_PERI  153
+#define ACLK_RGA   154
+#define ACLK_IEP   155
+#define ACLK_CIF   156
+#define ACLK_HDCP  157
 
 /* pclk gates */
-#define PCLK_GPIO0 300
-#define PCLK_GPIO1 301
-#define PCLK_GPIO2 302
-#define PCLK_GPIO3 303
-#define PCLK_GRF   304
-#define PCLK_I2C0  305
-#define PCLK_I2C1  306
-#define PCLK_I2C2  307
-#define PCLK_I2C3  308
-#define PCLK_SPI   309
-#define PCLK_UART0 310
-#define PCLK_UART1 311
-#define PCLK_UART2 312
-#define PCLK_TSADC 313
-#define PCLK_PWM   314
-#define PCLK_TIMER 315
-#define PCLK_BUS_PRE   316
-#define PCLK_PERI_PRE  317
-#define PCLK_HDMI_CTRL 318
-#define PCLK_HDMI_PHY  319
-#define PCLK_GMAC  320
-#define PCLK_H265  321
-#define PCLK_MAC2PHY   322
-#define PCLK_MAC2IO323
-#define PCLK_USB3PHY_OTG   324
-#define PCLK_USB3PHY_PIPE  325
-#define PCLK_USB3_GRF  326
-#define PCLK_USB2_GRF  327
-#define PCLK_HDMIPHY   328
-#define PCLK_DDR   329
-#define PCLK_PERI  330
-#define PCLK_HDMI  331
-#define PCLK_HDCP  332
-#define PCLK_DCF   333
-#define PCLK_SARADC334
+#define PCLK_GPIO0 200
+#define PCLK_GPIO1  

[PATCH v3 9/9] rockchip: dts: rock64: Fix XHCI usage

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

If the VBUS regulator is always-on, XHCI will fail to detect USB 3.0
devices; USB 2.0 devices will work however.

Make the VBUS regulator controllable and tie it to only the XHCI. This
makes all three USB ports usable.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v2:
  - new patch
---
 arch/arm/dts/rk3328-rock64-u-boot.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi 
b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
index e5946d2d2dc7..8318bf4e6030 100644
--- a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
@@ -12,5 +12,16 @@
 };
 
 &usb_host0_xhci {
+   vbus-supply = <&vcc_host_5v>;
status = "okay";
 };
+
+/*
+ * This makes XHCI responsible for toggling VBUS. This is needed to work
+ * around an issue where either XHCI only works with USB 2.0 or OTG doesn't
+ * work, depending on how VBUS is configured. Having USB 3.0 seems better.
+ */
+&vcc_host_5v {
+   /delete-property/ regulator-always-on;
+   /delete-property/ regulator-boot-on;
+};
-- 
2.26.0

[PATCH v3 5/9] dt-bindings: power: rk3328-power: sync from upstream Linux kernel

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

This syncs the rk3328 power domain header file from Linux kernel
next-20200324, to support newer hardware blocks when syncing the
device tree files.

The last non-merge commit to touch it was

b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to 
files with no license")

Reviewed-by: Kever Yang 
Tested-by: Loic Devulder 
Tested-by: Peter Geis 
Signed-off-by: Chen-Yu Tsai 
---
Changes since v2:
  - none
Changes since v1:
  - Added Kever's reviewed-by
---
 include/dt-bindings/power/rk3328-power.h | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 include/dt-bindings/power/rk3328-power.h

diff --git a/include/dt-bindings/power/rk3328-power.h 
b/include/dt-bindings/power/rk3328-power.h
new file mode 100644
index ..02e3d7fc1cce
--- /dev/null
+++ b/include/dt-bindings/power/rk3328-power.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __DT_BINDINGS_POWER_RK3328_POWER_H__
+#define __DT_BINDINGS_POWER_RK3328_POWER_H__
+
+/**
+ * RK3328 idle id Summary.
+ */
+#define RK3328_PD_CORE 0
+#define RK3328_PD_GPU  1
+#define RK3328_PD_BUS  2
+#define RK3328_PD_MSCH 3
+#define RK3328_PD_PERI 4
+#define RK3328_PD_VIDEO5
+#define RK3328_PD_HEVC 6
+#define RK3328_PD_SYS  7
+#define RK3328_PD_VPU  8
+#define RK3328_PD_VIO  9
+
+#endif
-- 
2.26.0

[PATCH v3 0/9] rockchip: rk3328: sync dts and add ROC-RK3328-CC board

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Hi everyone,

This is v3 of my ROC-RK3328-CC series. Changes from v2 are mainly
fixing USB functionality on RK3328 in U-boot. This includes restoring
the U-Boot specific "hnp-srp-disable" property for dwc2, moving the
dwc2 device node after the ehci/ohci ones, and making vbus controllable
and tied only to the XHCI controller. Because of this, I dropped review
and tested tags from the DTS sync and new board patches.

Changes from v1 are mainly dropping the custom board target, and dealing
with the pinmuxing through proper use of DM regulators / GPIO / pinctrl
in SPL.

This series adds proper support for Firefly / Libre Computer ROC-RK3328-CC
single board computer.

The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
card size development board based on the Rockchip RK3328 SoC, with:

  - 1/2/4 GB DDR4 DRAM
  - eMMC connector for optional module
  - micro SD card slot
  - 1 x USB 3.0 host port
  - 2 x USB 2.0 host port
  - 1 x USB 2.0 OTG port
  - HDMI video output
  - TRRS connector with audio and composite video output
  - gigabit Ethernet
  - consumer IR receiver
  - debug UART pins

Originally I started with Loic's patches, and syncing the device tree
files from Linux. That didn't get very far, with SPL failing to detect
the SD card. Examining the schematics and internal state of GRF and
GPIOs, I realized that the logic for the SD card power enable switch
is opposite that of what the SD card controller's SDMMC0_PWREN pin
would use. Instead, directly using the GPIO is required.

To deal with this, DM regulator and GPIO are enabled in SPL, and
various device nodes are marked with u-boot,dm-spl to have them work.
pinctrl properties are not stripped, so as to have the SDMMC0_PWREN
pin muxed over to GPIO.

Along the way, there are some clean-ups of existing dts files, moving
U-boot only features to -u-boot.dtsi files, and then a wholesale sync
from Linux. Only boards already existing in U-boot are synced. DT
binding header files are synced separately as there is already one
patch floating around. The DT sync also includes clean-up changes only
recently posted, and likely won't make it in for at least a few weeks.

Please have a look, and test if possible. I cc-ed a couple people that
showed interest in this board on mailing lists recently.

Regards
ChenYu


Chen-Yu Tsai (9):
  rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-boot.dtsi
  rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-boot.dtsi
  rockchip: dts: rk3328: Move OTG node's hnp-srp-disable to
rk3328-u-boot.dtsi
  dt-bindings: clock: rk3328: sync from upstream Linux kernel
  dt-bindings: power: rk3328-power: sync from upstream Linux kernel
  rockchip: rk3328: Disable generic PHY support
  rockchip: dts: rk3328: Sync device tree files from Linux
  rockchip: rk3328: Add support for ROC-RK3328-CC board
  rockchip: dts: rock64: Fix XHCI usage

 arch/arm/dts/Makefile |1 +
 arch/arm/dts/rk3328-evb-u-boot.dtsi   |   39 +
 arch/arm/dts/rk3328-evb.dts   |  220 +--
 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi|   47 +
 .../{rk3328-rock64.dts => rk3328-roc-cc.dts}  |  135 +-
 arch/arm/dts/rk3328-rock64-u-boot.dtsi|   11 +
 arch/arm/dts/rk3328-rock64.dts|  132 +-
 arch/arm/dts/rk3328-u-boot.dtsi   |4 +
 arch/arm/dts/rk3328.dtsi  | 1415 +++--
 board/rockchip/evb_rk3328/MAINTAINERS |7 +
 configs/evb-rk3328_defconfig  |1 -
 ...3328_defconfig => roc-cc-rk3328_defconfig} |   19 +-
 configs/rock64-rk3328_defconfig   |1 -
 doc/README.rockchip   |4 +-
 include/dt-bindings/clock/rk3328-cru.h|  212 +--
 include/dt-bindings/power/rk3328-power.h  |   19 +
 16 files changed, 1514 insertions(+), 753 deletions(-)
 create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
 copy arch/arm/dts/{rk3328-rock64.dts => rk3328-roc-cc.dts} (68%)
 copy configs/{rock64-rk3328_defconfig => roc-cc-rk3328_defconfig} (81%)
 create mode 100644 include/dt-bindings/power/rk3328-power.h

-- 
2.26.0

[PATCH v3 8/9] rockchip: rk3328: Add support for ROC-RK3328-CC board

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
card size development board based on the Rockchip RK3328 SoC, with:

  - 1/2/4 GB DDR4 DRAM
  - eMMC connector for optional module
  - micro SD card slot
  - 1 x USB 3.0 host port
  - 2 x USB 2.0 host port
  - 1 x USB 2.0 OTG port
  - HDMI video output
  - TRRS connector with audio and composite video output
  - gigabit Ethernet
  - consumer IR receiver
  - debug UART pins

The ROC-RK3328-CC has the enable pin of the SD card power switch tied
to GPIO_0_D6. This pin also has the function SDMMC0_PWREN, which is
muxed by default. SDMMC0_PWREN is an active high signal controlled by
the MMC controller, however the switch enable is active low, and
pulled low (enabled) by default to make things work on boot.

As such, we need to mux away from SDMMC0_PWREN and use GPIO to enable
power to the card. The default GPIO state for the pin is pull-down and
input, which doesn't require extra configuration when paired with the
external pull-down and active low switch.

Deal with this by enabling regulator support in SPL, and setting
"u-boot,dm-spl" for the regulator and other device nodes needed for
muxing the pin.

The device tree file is synced from the Linux kernel next-20200324.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v2:
  - Remove regulator-always-on from VBUS regulator
  - Disable CONFIG_PHY
Changes since v1:
  - Drop custom target; use pinctrl and regulators in SPL
---
 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi |  47 
 arch/arm/dts/rk3328-roc-cc.dts | 354 +
 board/rockchip/evb_rk3328/MAINTAINERS  |   7 +
 configs/roc-cc-rk3328_defconfig| 102 +++
 doc/README.rockchip|   4 +-
 6 files changed, 514 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3328-roc-cc.dts
 create mode 100644 configs/roc-cc-rk3328_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index af7d804b6669..a683525e7c6a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -106,6 +106,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3308) += \
 
 dtb-$(CONFIG_ROCKCHIP_RK3328) += \
rk3328-evb.dtb \
+   rk3328-roc-cc.dtb \
rk3328-rock64.dtb
 
 dtb-$(CONFIG_ROCKCHIP_RK3368) += \
diff --git a/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi 
b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
new file mode 100644
index ..e929d86e306a
--- /dev/null
+++ b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
@@ -0,0 +1,47 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2018-2019 Rockchip Electronics Co., Ltd
+ */
+
+#include "rk3328-u-boot.dtsi"
+#include "rk3328-sdram-ddr4-666.dtsi"
+/ {
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", &sdmmc, &emmc;
+   };
+};
+
+&gpio0 {
+   u-boot,dm-spl;
+};
+
+&pinctrl {
+   u-boot,dm-spl;
+};
+
+&sdmmc0m1_gpio {
+   u-boot,dm-spl;
+};
+
+&pcfg_pull_up_4ma {
+   u-boot,dm-spl;
+};
+
+&usb_host0_xhci {
+   vbus-supply = <&vcc_host1_5v>;
+   status = "okay";
+};
+
+/*
+ * This makes XHCI responsible for toggling VBUS. This is needed to work
+ * around an issue where either XHCI only works with USB 2.0 or OTG doesn't
+ * work, depending on how VBUS is configured. Having USB 3.0 seems better.
+ */
+&vcc_host1_5v {
+   /delete-property/ regulator-always-on;
+};
+
+/* Need this and all the pinctrl/gpio stuff above to set pinmux */
+&vcc_sd {
+   u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/rk3328-roc-cc.dts b/arch/arm/dts/rk3328-roc-cc.dts
new file mode 100644
index ..8d553c92182a
--- /dev/null
+++ b/arch/arm/dts/rk3328-roc-cc.dts
@@ -0,0 +1,354 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 T-Chip Intelligent Technology Co., Ltd
+ */
+
+/dts-v1/;
+#include "rk3328.dtsi"
+
+/ {
+   model = "Firefly roc-rk3328-cc";
+   compatible = "firefly,roc-rk3328-cc", "rockchip,rk3328";
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   gmac_clkin: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "gmac_clkin";
+   #clock-cells = <0>;
+   };
+
+   dc_12v: dc-12v {
+   compatible = "regulator-fixed";
+   regulator-name = "dc_12v";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+
+   vcc_sd: sdmmc-regulator {
+   compatible = "regulator-fixed";
+   gpio =

[PATCH v3 7/9] rockchip: dts: rk3328: Sync device tree files from Linux

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

This syncs rk3328 device tree files from the Linux kernel next-20200324.
The last commit to touch these files is:

b2411befed60 ("arm64: dts: add bus to rockchip amba nodenames")

Additional changes not yet in the Linux kernel include:

arm64: dts: rockchip: rk3328: drop #address-cells, #size-cells from grf node
arm64: dts: rockchip: rk3328: drop non-existent gmac2phy pinmux options
arm64: dts: rockchip: rk3328: Replace RK805 PMIC node name with "pmic"

Changes include:

  - conversion of raw pin numbers to macros
  - removal of deprecated RK_FUNC_* macros
  - update of device tree binding headers
  - new devices
  - device tree cleanups
  - gmac2phy disabled in -u-boot.dtsi as it is not supported in U-boot

This includes a re-ordering of the USB device nodes compared to upstream
Linux, moving the dwc2 OTG controller after the EHCI/OHCI nodes. This is
currently required as otherwise the dwc2 controller would not be able to
detect devices in some cases. This may be due to lack of USB PHY support
in U-boot.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v2:
  - Dropped reviewed-by
  - Moved dwc2 OTG device node after EHCI/OHCI to make dwc2 work again
Changes since v1:
  - Added Kever's reviewed-by
---
 arch/arm/dts/rk3328-evb-u-boot.dtsi |5 +
 arch/arm/dts/rk3328-evb.dts |  196 ++--
 arch/arm/dts/rk3328-rock64.dts  |  132 ++-
 arch/arm/dts/rk3328.dtsi| 1414 +--
 4 files changed, 1166 insertions(+), 581 deletions(-)

diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 8ba53cf8f44b..4bfa0c2330ba 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -40,6 +40,11 @@
status = "okay";
 };
 
+&gmac2phy {
+   /* Integrated PHY unsupported by U-boot */
+   status = "broken";
+};
+
 &usb_host0_xhci {
vbus-supply = <&vcc5v0_host_xhci>;
status = "okay";
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index 97bef37cf610..6abc6f4a86cf 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -1,6 +1,6 @@
-// SPDX-License-Identifier: GPL-2.0+
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
 /*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
  */
 
 /dts-v1/;
@@ -11,24 +11,51 @@
compatible = "rockchip,rk3328-evb", "rockchip,rk3328";
 
chosen {
-   stdout-path = &uart2;
+   stdout-path = "serial2:150n8";
};
 
-   vcc3v3_sdmmc: sdmmc-pwren {
+   dc_12v: dc-12v {
compatible = "regulator-fixed";
-   regulator-name = "vcc3v3";
-   gpio = <&gpio0 30 GPIO_ACTIVE_LOW>;
+   regulator-name = "dc_12v";
regulator-always-on;
regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+
+   sdio_pwrseq: sdio-pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   pinctrl-names = "default";
+   pinctrl-0 = <&wifi_enable_h>;
+
+   /*
+* On the module itself this is one of these (depending
+* on the actual card populated):
+* - SDIO_RESET_L_WL_REG_ON
+* - PDN (power down when low)
+*/
+   reset-gpios = <&gpio1 18 GPIO_ACTIVE_LOW>;
+   };
+
+   vcc_sd: sdmmc-regulator {
+   compatible = "regulator-fixed";
+   gpio = <&gpio0 30 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&sdmmc0m1_gpio>;
+   regulator-name = "vcc_sd";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <&vcc_io>;
};
 
-   vcc5v0_otg: vcc5v0-otg-drv {
+   vcc_sys: vcc-sys {
compatible = "regulator-fixed";
-   enable-active-high;
-   regulator-name = "vcc5v0_otg";
-   gpio = <&gpio0 27 GPIO_ACTIVE_HIGH>;
+   regulator-name = "vcc_sys";
+   regulator-always-on;
+   regulator-boot-on;
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
+   vin-supply = <&dc_12v>;
};
 
vcc_phy: vcc-phy-regulator {
@@ -39,80 +66,60 @@
};
 };
 
-&saradc {
-   status = "okay";
-};
-
-&uart2 {
-   status = "okay&quo

Re: [PATCH 2/3] sunxi: Add Libre Computer ALL-H3-IT H5 board

[Chen-Yu Tsai]

On Tue, Jan 21, 2020 at 3:29 PM Jagan Teki  wrote:
>
> On Sun, Jan 12, 2020 at 9:06 PM Chen-Yu Tsai  wrote:
> >
> > From: Chen-Yu Tsai 
> >
> > The Libre Computer ALL-H3-IT board is a small single board computer that
> > is roughly the same size as the Raspberry Pi Zero, or around 20% smaller
> > than a credit card.
> >
> > The board features:
> >
> >   - H2, H3, or H5 SoC from Allwinner
> >   - 2 DDR3 DRAM chips
> >   - Realtek RTL8821CU based WiFi module
> >   - 128 Mbit SPI-NOR flash
> >   - micro-SD card slot
> >   - micro HDMI video output
> >   - FPC connector for camera sensor module
> >   - generic Raspberri-Pi style 40 pin GPIO header
> >   - additional pin headers for extra USB host ports, ananlog audio and
> > IR receiver
> >
> > Only H5 variant test samples were made available, but the vendor does
> > have plans to include at least an H3 variant. Thus the device tree is
> > split much like the ALL-H3-CC, with a common dtsi file for the board
> > design, and separate dts files including the common board file and the
> > SoC dtsi file. The other variants will be added as they are made
> > available.
> >
> > The device tree was synced over from the Linux kernel, along with other
> > H3/H5 changes, in a previous patch. Thus only the defconfig and an entry
> > to the MAINTAINERS file is added.
> >
> > Signed-off-by: Chen-Yu Tsai 
> > ---
> >  board/sunxi/MAINTAINERS  |  5 +
> >  configs/libretech_all_h3_it_h5_defconfig | 22 ++
> >  2 files changed, 27 insertions(+)
> >  create mode 100644 configs/libretech_all_h3_it_h5_defconfig
> >
> > diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
> > index 4a89bb0e7b7e..ed620ade766c 100644
> > --- a/board/sunxi/MAINTAINERS
> > +++ b/board/sunxi/MAINTAINERS
> > @@ -318,6 +318,11 @@ F: configs/libretech_all_h3_cc_h2_plus_defconfig
> >  F: configs/libretech_all_h3_cc_h3_defconfig
> >  F: configs/libretech_all_h3_cc_h5_defconfig
> >
> > +LIBRETECH ALL-H3-IT BOARDS
> > +M: Chen-Yu Tsai 
> > +S: Maintained
> > +F: configs/libretech_all_h3_it_h5_defconfig
> > +
> >  NANOPI-M1 BOARD
> >  M: Mylène Josserand 
> >  S: Maintained
> > diff --git a/configs/libretech_all_h3_it_h5_defconfig 
> > b/configs/libretech_all_h3_it_h5_defconfig
> > new file mode 100644
> > index ..df13f4a0d307
> > --- /dev/null
> > +++ b/configs/libretech_all_h3_it_h5_defconfig
> > @@ -0,0 +1,22 @@
> > +CONFIG_ARM=y
> > +CONFIG_ARCH_SUNXI=y
> > +CONFIG_NR_DRAM_BANKS=1
> > +CONFIG_SPL=y
> > +CONFIG_MACH_SUN50I_H5=y
> > +CONFIG_DRAM_CLK=672
> > +CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> > +CONFIG_SPL_SPI_SUNXI=y
> > +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> > +CONFIG_USE_PREBOOT=y
> > +CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000
> > +# CONFIG_SPL_DOS_PARTITION is not set
> > +# CONFIG_SPL_EFI_PARTITION is not set
> > +CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-libretech-all-h3-it"
> > +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> > +CONFIG_DM_SPI_FLASH=y
> > +CONFIG_SPI_FLASH_XMC=y
> > +CONFIG_SPI=y
> > +CONFIG_DM_SPI=y
>
> We just enable SPI_FLASH_XMC and rest we can add it via arch Kconfig?
> like A64 does.

Are you referring to the rest of the SPI stuff?

Only the more recent boards have SPI flash on board, so if we enable
it by default, we might end up with a whole bunch of boards disabling
it because they don't actually have SPI flash, and maybe don't want
the overhead.

The rest of the generic stuff could be moved to Kconfig. DRAM_CLK
is probably not doable as the values vary a lot. NR_DRAM_BANKS yes.
SYS_SPI_U_BOOT_OFFS was already done I believe. Not sure about
some of the rest of the SPL settings.

ChenYu

Re: [PATCH 2/3] sunxi: Add Libre Computer ALL-H3-IT H5 board

[Chen-Yu Tsai]

On Fri, Jan 24, 2020 at 2:24 PM Jagan Teki  wrote:
>
> On Tue, Jan 21, 2020 at 1:11 PM Chen-Yu Tsai  wrote:
> >
> > On Tue, Jan 21, 2020 at 3:29 PM Jagan Teki  
> > wrote:
> > >
> > > On Sun, Jan 12, 2020 at 9:06 PM Chen-Yu Tsai  wrote:
> > > >
> > > > From: Chen-Yu Tsai 
> > > >
> > > > The Libre Computer ALL-H3-IT board is a small single board computer that
> > > > is roughly the same size as the Raspberry Pi Zero, or around 20% smaller
> > > > than a credit card.
> > > >
> > > > The board features:
> > > >
> > > >   - H2, H3, or H5 SoC from Allwinner
> > > >   - 2 DDR3 DRAM chips
> > > >   - Realtek RTL8821CU based WiFi module
> > > >   - 128 Mbit SPI-NOR flash
> > > >   - micro-SD card slot
> > > >   - micro HDMI video output
> > > >   - FPC connector for camera sensor module
> > > >   - generic Raspberri-Pi style 40 pin GPIO header
> > > >   - additional pin headers for extra USB host ports, ananlog audio and
> > > > IR receiver
> > > >
> > > > Only H5 variant test samples were made available, but the vendor does
> > > > have plans to include at least an H3 variant. Thus the device tree is
> > > > split much like the ALL-H3-CC, with a common dtsi file for the board
> > > > design, and separate dts files including the common board file and the
> > > > SoC dtsi file. The other variants will be added as they are made
> > > > available.
> > > >
> > > > The device tree was synced over from the Linux kernel, along with other
> > > > H3/H5 changes, in a previous patch. Thus only the defconfig and an entry
> > > > to the MAINTAINERS file is added.
> > > >
> > > > Signed-off-by: Chen-Yu Tsai 
> > > > ---
> > > >  board/sunxi/MAINTAINERS  |  5 +
> > > >  configs/libretech_all_h3_it_h5_defconfig | 22 ++
> > > >  2 files changed, 27 insertions(+)
> > > >  create mode 100644 configs/libretech_all_h3_it_h5_defconfig
> > > >
> > > > diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
> > > > index 4a89bb0e7b7e..ed620ade766c 100644
> > > > --- a/board/sunxi/MAINTAINERS
> > > > +++ b/board/sunxi/MAINTAINERS
> > > > @@ -318,6 +318,11 @@ F: configs/libretech_all_h3_cc_h2_plus_defconfig
> > > >  F: configs/libretech_all_h3_cc_h3_defconfig
> > > >  F: configs/libretech_all_h3_cc_h5_defconfig
> > > >
> > > > +LIBRETECH ALL-H3-IT BOARDS
> > > > +M: Chen-Yu Tsai 
> > > > +S: Maintained
> > > > +F: configs/libretech_all_h3_it_h5_defconfig
> > > > +
> > > >  NANOPI-M1 BOARD
> > > >  M: Mylène Josserand 
> > > >  S: Maintained
> > > > diff --git a/configs/libretech_all_h3_it_h5_defconfig 
> > > > b/configs/libretech_all_h3_it_h5_defconfig
> > > > new file mode 100644
> > > > index ..df13f4a0d307
> > > > --- /dev/null
> > > > +++ b/configs/libretech_all_h3_it_h5_defconfig
> > > > @@ -0,0 +1,22 @@
> > > > +CONFIG_ARM=y
> > > > +CONFIG_ARCH_SUNXI=y
> > > > +CONFIG_NR_DRAM_BANKS=1
> > > > +CONFIG_SPL=y
> > > > +CONFIG_MACH_SUN50I_H5=y
> > > > +CONFIG_DRAM_CLK=672
> > > > +CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> > > > +CONFIG_SPL_SPI_SUNXI=y
> > > > +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> > > > +CONFIG_USE_PREBOOT=y
> > > > +CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000
> > > > +# CONFIG_SPL_DOS_PARTITION is not set
> > > > +# CONFIG_SPL_EFI_PARTITION is not set
> > > > +CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-libretech-all-h3-it"
> > > > +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> > > > +CONFIG_DM_SPI_FLASH=y
> > > > +CONFIG_SPI_FLASH_XMC=y
> > > > +CONFIG_SPI=y
> > > > +CONFIG_DM_SPI=y
> > >
> > > We just enable SPI_FLASH_XMC and rest we can add it via arch Kconfig?
> > > like A64 does.
> >
> > Are you referring to the rest of the SPI stuff?
>
> Yes.
>
> >
> > Only the more recent boards have SPI flash on board, so if we enable
> > it by default, we might end up with a whole bunch of boards disabling
> > it because they don't actually have SPI flash, and maybe don't want
> > the

Re: Pull request: u-boot-rockchip-20200120

[Chen-Yu Tsai]

On Tue, Jan 28, 2020 at 2:32 AM Tom Rini  wrote:
>
> On Mon, Jan 27, 2020 at 11:25:16PM +0530, Jagan Teki wrote:
> > Hi Tom,
> >
> > On Thu, Jan 23, 2020 at 11:30 PM Tom Rini  wrote:
> > >
> > > On Mon, Jan 20, 2020 at 10:30:07AM +0800, Kever Yang wrote:
> > >
> > > > Hi Tom,
> > > >
> > > > Please pull the rockchip updates:
> > > > - Support SPI boot and redundant boot for rk3399
> > > > - Support binman for rockchip platform
> > > > - Update ram driver and add ddr4 support for rk3328
> > > >
> > > > Travis:
> > > > https://travis-ci.org/keveryang/u-boot/builds/639069624
> > > >
> > > > Thanks,
> > > > - Kever
> > > >
> > > > The following changes since commit 
> > > > d7bb6aceb2e99a832efbb96f9bf480bf95602192:
> > > >
> > > >   Merge tag 'mmc-1-16-2020' of 
> > > > https://gitlab.denx.de/u-boot/custodians/u-boot-mmc (2020-01-16 
> > > > 13:20:51 -0500)
> > > >
> > > > are available in the Git repository at:
> > > >
> > > >   https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git 
> > > > tags/u-boot-rockchip-20200120
> > > >
> > > > for you to fetch changes up to f9a0f5b83e9eabf4d064c7ec46fe2f9b9b694b4e:
> > > >
> > > >   configs: firefly-rk3399: Enable CONFIG_MISC_INIT_R and ROCKCHIP_EFUSE 
> > > > (2020-01-19 15:19:03 +0800)
> > > >
> > >
> > > Per the details in the "distro_bootcmd: Add SF support" thread, I'm not
> > > taking this as the distro_bootcmd changes need to be dropped.  Thanks!
> >
> > Seems like Kever was Off for vacations or so, if possible maybe you
> > can drop below 'sf distro changes from PR'
> >
> >   distro_bootcmd: Add SF support
> >   rockchip: Include SF on distrocmd devices
> >   rk3399: Add boot flash script offet, size
>
> I will just wait for a new PR early in the -rc2 cycle to take care of
> outstanding rockchip changes.  Thanks.

It's Chinese New Year, with an extended vacation in China till this Sunday,
due to the coronavirus outbreak [1].

[1] https://www.bbc.com/news/world-asia-china-51259649

Re: [PATCH 2/3] sunxi: Add Libre Computer ALL-H3-IT H5 board

[Chen-Yu Tsai]

On Fri, Jan 24, 2020 at 4:32 PM Chen-Yu Tsai  wrote:
>
> On Fri, Jan 24, 2020 at 2:24 PM Jagan Teki  wrote:
> >
> > On Tue, Jan 21, 2020 at 1:11 PM Chen-Yu Tsai  wrote:
> > >
> > > On Tue, Jan 21, 2020 at 3:29 PM Jagan Teki  
> > > wrote:
> > > >
> > > > On Sun, Jan 12, 2020 at 9:06 PM Chen-Yu Tsai  wrote:
> > > > >
> > > > > From: Chen-Yu Tsai 
> > > > >
> > > > > The Libre Computer ALL-H3-IT board is a small single board computer 
> > > > > that
> > > > > is roughly the same size as the Raspberry Pi Zero, or around 20% 
> > > > > smaller
> > > > > than a credit card.
> > > > >
> > > > > The board features:
> > > > >
> > > > >   - H2, H3, or H5 SoC from Allwinner
> > > > >   - 2 DDR3 DRAM chips
> > > > >   - Realtek RTL8821CU based WiFi module
> > > > >   - 128 Mbit SPI-NOR flash
> > > > >   - micro-SD card slot
> > > > >   - micro HDMI video output
> > > > >   - FPC connector for camera sensor module
> > > > >   - generic Raspberri-Pi style 40 pin GPIO header
> > > > >   - additional pin headers for extra USB host ports, ananlog audio and
> > > > > IR receiver
> > > > >
> > > > > Only H5 variant test samples were made available, but the vendor does
> > > > > have plans to include at least an H3 variant. Thus the device tree is
> > > > > split much like the ALL-H3-CC, with a common dtsi file for the board
> > > > > design, and separate dts files including the common board file and the
> > > > > SoC dtsi file. The other variants will be added as they are made
> > > > > available.
> > > > >
> > > > > The device tree was synced over from the Linux kernel, along with 
> > > > > other
> > > > > H3/H5 changes, in a previous patch. Thus only the defconfig and an 
> > > > > entry
> > > > > to the MAINTAINERS file is added.
> > > > >
> > > > > Signed-off-by: Chen-Yu Tsai 
> > > > > ---
> > > > >  board/sunxi/MAINTAINERS  |  5 +
> > > > >  configs/libretech_all_h3_it_h5_defconfig | 22 ++
> > > > >  2 files changed, 27 insertions(+)
> > > > >  create mode 100644 configs/libretech_all_h3_it_h5_defconfig
> > > > >
> > > > > diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
> > > > > index 4a89bb0e7b7e..ed620ade766c 100644
> > > > > --- a/board/sunxi/MAINTAINERS
> > > > > +++ b/board/sunxi/MAINTAINERS
> > > > > @@ -318,6 +318,11 @@ F: configs/libretech_all_h3_cc_h2_plus_defconfig
> > > > >  F: configs/libretech_all_h3_cc_h3_defconfig
> > > > >  F: configs/libretech_all_h3_cc_h5_defconfig
> > > > >
> > > > > +LIBRETECH ALL-H3-IT BOARDS
> > > > > +M: Chen-Yu Tsai 
> > > > > +S: Maintained
> > > > > +F: configs/libretech_all_h3_it_h5_defconfig
> > > > > +
> > > > >  NANOPI-M1 BOARD
> > > > >  M: Mylène Josserand 
> > > > >  S: Maintained
> > > > > diff --git a/configs/libretech_all_h3_it_h5_defconfig 
> > > > > b/configs/libretech_all_h3_it_h5_defconfig
> > > > > new file mode 100644
> > > > > index ..df13f4a0d307
> > > > > --- /dev/null
> > > > > +++ b/configs/libretech_all_h3_it_h5_defconfig
> > > > > @@ -0,0 +1,22 @@
> > > > > +CONFIG_ARM=y
> > > > > +CONFIG_ARCH_SUNXI=y
> > > > > +CONFIG_NR_DRAM_BANKS=1
> > > > > +CONFIG_SPL=y
> > > > > +CONFIG_MACH_SUN50I_H5=y
> > > > > +CONFIG_DRAM_CLK=672
> > > > > +CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> > > > > +CONFIG_SPL_SPI_SUNXI=y
> > > > > +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> > > > > +CONFIG_USE_PREBOOT=y
> > > > > +CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000
> > > > > +# CONFIG_SPL_DOS_PARTITION is not set
> > > > > +# CONFIG_SPL_EFI_PARTITION is not set
> > > > > +CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-libretech-all-h3-it"
> > > > > +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> > > > > +CONFIG_DM_SPI_FLASH=y
> > > &g

Re: [PATCH 1/3] sunxi: dts: OrangePi Zero: Add SPI aliases to make bus usable with u-boot.

[Chen-Yu Tsai]

(Resend from @kernel.org address)

On Tue, Sep 29, 2020 at 5:02 AM Michal Suchanek  wrote:
>
> The u-boot code relies on aliases to assign bus number.
>
> Signed-off-by: Michal Suchanek 
> ---
>  arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts | 2 ++

Anything U-boot specific should be done in the *-u-boot.dts file.
And any changes you do to the U-boot copy of dts files will potentially
be lost when a dts sync happens.

ChenYu

>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts 
> b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
> index f19ed981da..090570148e 100644
> --- a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
> +++ b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
> @@ -59,6 +59,8 @@
> /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
> ethernet0 = &emac;
> ethernet1 = &xr819;
> +   spi0 = &spi0;
> +   spi1 = &spi1;
> };
>
> chosen {
> --
> 2.28.0
>

Re: [PATCH 5/5] arm64: dts: meson: add libretech-pc support

[Chen-Yu Tsai]

On Fri, Dec 20, 2019 at 2:37 AM Jerome Brunet  wrote:
>
> Add support for the Amlogic based libretech-pc platform.
> This platform comes with 2 variant, based on the s905d or s912 SoC.
>
> Signed-off-by: Jerome Brunet 
> ---
>  arch/arm/dts/Makefile |   2 +
>  arch/arm/dts/meson-gx-libretech-pc.dtsi   | 376 ++
>  .../meson-gxl-s905d-libretech-pc-u-boot.dtsi  |   7 +
>  arch/arm/dts/meson-gxl-s905d-libretech-pc.dts |  17 +
>  arch/arm/dts/meson-gxl-s905d.dtsi |  12 +
>  arch/arm/dts/meson-gxl.dtsi   |  35 +-
>  .../meson-gxm-s912-libretech-pc-u-boot.dtsi   |   7 +
>  arch/arm/dts/meson-gxm-s912-libretech-pc.dts  |  62 +++
>  configs/libretech-s905d-pc_defconfig  |  73 
>  configs/libretech-s912-pc_defconfig   |  73 
>  10 files changed, 654 insertions(+), 10 deletions(-)
>  create mode 100644 arch/arm/dts/meson-gx-libretech-pc.dtsi
>  create mode 100644 arch/arm/dts/meson-gxl-s905d-libretech-pc-u-boot.dtsi
>  create mode 100644 arch/arm/dts/meson-gxl-s905d-libretech-pc.dts
>  create mode 100644 arch/arm/dts/meson-gxl-s905d.dtsi
>  create mode 100644 arch/arm/dts/meson-gxm-s912-libretech-pc-u-boot.dtsi
>  create mode 100644 arch/arm/dts/meson-gxm-s912-libretech-pc.dts
>  create mode 100644 configs/libretech-s905d-pc_defconfig
>  create mode 100644 configs/libretech-s912-pc_defconfig

May I suggest including the actual model name "AML-S912-PC" in the
file names? That will make it that much more obvious what these files
are for, instead of "libretech-pc" which few people have heard of.

So something like "meson-libretech-aml-s912-pc.dtsi",
"meson-gxl-s905d-libretech-aml-s912-pc.dts",
"meson-gxm-s912-libretech-aml-s912-pc.dts",
"libretech-aml-s912-pc-s905d_defconfig", and
"libretech-aml-s912-pc-s912_defconfig".

Same goes for the Linux copy.

ChenYu

Re: SUNXI : CONFIG_VIDEO_SUNXI is never set

[Chen-Yu Tsai]

On Sun, Dec 22, 2019 at 10:07 PM Arjan van Vught
 wrote:
>
>
>
> > Op 10 mrt. 2019, om 20:18 heeft Arjan van Vught  
> > het volgende geschreven:
> >
> >
> >
> >> Op 7 mrt. 2019, om 09:04 heeft Chen-Yu Tsai  het volgende 
> >> geschreven:
> >>
> >> On Fri, Mar 1, 2019 at 11:36 PM Arjan van Vught
> >>  wrote:
> >>>
> >>> Version: u-boot-2018.09
> >>>
> >>> This is a follow-up for : "SUNXI : setenv video-mode not working"
> >>>
> >>> Although I have added CONFIG_VIDEO_SUNXI=y in 
> >>> configs/orangepi_one_defconfig
> >>>
> >>> the source file sunxi_display.c is not compiled. Hence the setenv
> >>> video-mode is not working ?
> >>
> >> That file is only used for DE 1.0, while the H3, which the Orange Pi
> >> One is based
> >> on, has DE 2.0.
> > Is it on the roadmap adding support for DE 2.0 ?
>
> Hi ChenYu, any updates for this issue ? Thanks, Arjan

You are asking the wrong person.

[PATCH 0/3] sunxi: Sync H3/H5 DT and add ALL-H3-IT and ALL-H5-CC

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Hi everyone,

This patch series syncs up the device tree files and header files for
Allwinner H3/H5 SoCs and related boards to linux-next-20200108, and
then adds support for Libre Computer ALL-H3-IT H5 and ALL-H5-CC H5
boards.

Patch 1 syncs up the device tree files and related device tree binding
header files for the Allwinner H3 and H5 SoCs, and boards using these
chips. These were compile tested.

Patch 2 adds a defconfig and MAINTAINERS entry for the ALL-H3-IT's H5
variant. Other variants will be added as they are made available.

Patch 3 adds a defconfig and MAINTAINERS entry for the ALL-H5-CC's H5
variant. Other variants will be added as they are made available.

Please have a look.


Regards
ChenYu


Chen-Yu Tsai (3):
  sunxi: H3/H5 Sync DT files from upstream Linux kernel as of
next-20200108
  sunxi: Add Libre Computer ALL-H3-IT H5 board
  sunxi: Add Libre Computer ALL-H5-CC H5 board

 arch/arm/dts/Makefile |   9 +-
 .../dts/sun50i-h5-bananapi-m2-plus-v1.2.dts   |  11 ++
 .../sun50i-h5-emlid-neutis-n5-devboard.dts| 137 ++---
 arch/arm/dts/sun50i-h5-emlid-neutis-n5.dtsi   |  95 +
 .../arm/dts/sun50i-h5-libretech-all-h3-cc.dts |  10 +-
 .../arm/dts/sun50i-h5-libretech-all-h3-it.dts |  11 ++
 .../arm/dts/sun50i-h5-libretech-all-h5-cc.dts |  61 ++
 arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts   |  53 +
 arch/arm/dts/sun50i-h5-nanopi-neo2.dts|  45 +
 arch/arm/dts/sun50i-h5-orangepi-pc2.dts   |  47 +
 arch/arm/dts/sun50i-h5-orangepi-prime.dts |  52 +
 arch/arm/dts/sun50i-h5-orangepi-zero-plus.dts |  11 +-
 .../arm/dts/sun50i-h5-orangepi-zero-plus2.dts |  46 +
 arch/arm/dts/sun50i-h5.dtsi   | 186 +-
 .../dts/sun8i-h2-plus-bananapi-m2-zero.dts|  40 +++-
 arch/arm/dts/sun8i-h2-plus-orangepi-r1.dts|   2 -
 arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts  |  22 ++-
 .../dts/sun8i-h3-bananapi-m2-plus-v1.2.dts|  13 ++
 arch/arm/dts/sun8i-h3-beelink-x2.dts  |  11 +-
 .../sun8i-h3-emlid-neutis-n5h3-devboard.dts   |  72 +++
 arch/arm/dts/sun8i-h3-emlid-neutis-n5h3.dtsi  |  11 ++
 arch/arm/dts/sun8i-h3-mapleboard-mp130.dts| 152 ++
 arch/arm/dts/sun8i-h3-nanopi-duo2.dts | 173 
 arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts  |  28 ++-
 arch/arm/dts/sun8i-h3-nanopi-m1.dts   |   2 +-
 arch/arm/dts/sun8i-h3-nanopi-neo-air.dts  |   2 +-
 arch/arm/dts/sun8i-h3-nanopi.dtsi |  25 +--
 arch/arm/dts/sun8i-h3-orangepi-2.dts  |  34 +---
 arch/arm/dts/sun8i-h3-orangepi-lite.dts   |  27 +--
 arch/arm/dts/sun8i-h3-orangepi-one.dts|  28 +--
 arch/arm/dts/sun8i-h3-orangepi-pc.dts |  27 +--
 arch/arm/dts/sun8i-h3-orangepi-plus.dts   |  23 ++-
 arch/arm/dts/sun8i-h3-orangepi-zero-plus2.dts |   2 +-
 arch/arm/dts/sun8i-h3-rervision-dvk.dts   | 114 +++
 arch/arm/dts/sun8i-h3.dtsi|  86 +++-
 arch/arm/dts/sunxi-bananapi-m2-plus-v1.2.dtsi |  30 +++
 arch/arm/dts/sunxi-bananapi-m2-plus.dtsi  |   7 +-
 arch/arm/dts/sunxi-h3-h5-emlid-neutis.dtsi| 170 
 arch/arm/dts/sunxi-h3-h5.dtsi | 137 -
 arch/arm/dts/sunxi-libretech-all-h3-cc.dtsi   |  65 +-
 arch/arm/dts/sunxi-libretech-all-h3-it.dtsi   | 180 +
 board/sunxi/MAINTAINERS   |  10 +
 configs/libretech_all_h3_it_h5_defconfig  |  22 +++
 configs/libretech_all_h5_cc_h5_defconfig  |  23 +++
 include/dt-bindings/clock/sun8i-h3-ccu.h  |  11 +-
 include/dt-bindings/reset/sun8i-h3-ccu.h  |   5 +-
 46 files changed, 1605 insertions(+), 723 deletions(-)
 create mode 100644 arch/arm/dts/sun50i-h5-bananapi-m2-plus-v1.2.dts
 create mode 100644 arch/arm/dts/sun50i-h5-libretech-all-h3-it.dts
 create mode 100644 arch/arm/dts/sun50i-h5-libretech-all-h5-cc.dts
 create mode 100644 arch/arm/dts/sun8i-h3-bananapi-m2-plus-v1.2.dts
 create mode 100644 arch/arm/dts/sun8i-h3-emlid-neutis-n5h3-devboard.dts
 create mode 100644 arch/arm/dts/sun8i-h3-emlid-neutis-n5h3.dtsi
 create mode 100644 arch/arm/dts/sun8i-h3-mapleboard-mp130.dts
 create mode 100644 arch/arm/dts/sun8i-h3-nanopi-duo2.dts
 create mode 100644 arch/arm/dts/sun8i-h3-rervision-dvk.dts
 create mode 100644 arch/arm/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
 create mode 100644 arch/arm/dts/sunxi-h3-h5-emlid-neutis.dtsi
 create mode 100644 arch/arm/dts/sunxi-libretech-all-h3-it.dtsi
 create mode 100644 configs/libretech_all_h3_it_h5_defconfig
 create mode 100644 configs/libretech_all_h5_cc_h5_defconfig

-- 
2.24.1

[PATCH 2/3] sunxi: Add Libre Computer ALL-H3-IT H5 board

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The Libre Computer ALL-H3-IT board is a small single board computer that
is roughly the same size as the Raspberry Pi Zero, or around 20% smaller
than a credit card.

The board features:

  - H2, H3, or H5 SoC from Allwinner
  - 2 DDR3 DRAM chips
  - Realtek RTL8821CU based WiFi module
  - 128 Mbit SPI-NOR flash
  - micro-SD card slot
  - micro HDMI video output
  - FPC connector for camera sensor module
  - generic Raspberri-Pi style 40 pin GPIO header
  - additional pin headers for extra USB host ports, ananlog audio and
IR receiver

Only H5 variant test samples were made available, but the vendor does
have plans to include at least an H3 variant. Thus the device tree is
split much like the ALL-H3-CC, with a common dtsi file for the board
design, and separate dts files including the common board file and the
SoC dtsi file. The other variants will be added as they are made
available.

The device tree was synced over from the Linux kernel, along with other
H3/H5 changes, in a previous patch. Thus only the defconfig and an entry
to the MAINTAINERS file is added.

Signed-off-by: Chen-Yu Tsai 
---
 board/sunxi/MAINTAINERS  |  5 +
 configs/libretech_all_h3_it_h5_defconfig | 22 ++
 2 files changed, 27 insertions(+)
 create mode 100644 configs/libretech_all_h3_it_h5_defconfig

diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 4a89bb0e7b7e..ed620ade766c 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -318,6 +318,11 @@ F: configs/libretech_all_h3_cc_h2_plus_defconfig
 F: configs/libretech_all_h3_cc_h3_defconfig
 F: configs/libretech_all_h3_cc_h5_defconfig
 
+LIBRETECH ALL-H3-IT BOARDS
+M: Chen-Yu Tsai 
+S: Maintained
+F: configs/libretech_all_h3_it_h5_defconfig
+
 NANOPI-M1 BOARD
 M: Mylène Josserand 
 S: Maintained
diff --git a/configs/libretech_all_h3_it_h5_defconfig 
b/configs/libretech_all_h3_it_h5_defconfig
new file mode 100644
index ..df13f4a0d307
--- /dev/null
+++ b/configs/libretech_all_h3_it_h5_defconfig
@@ -0,0 +1,22 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL=y
+CONFIG_MACH_SUN50I_H5=y
+CONFIG_DRAM_CLK=672
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2
+CONFIG_SPL_SPI_SUNXI=y
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_USE_PREBOOT=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-libretech-all-h3-it"
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH_XMC=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
-- 
2.24.1

[PATCH 3/3] sunxi: Add Libre Computer ALL-H5-CC H5 board

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The Libre Computer ALL-H5-CC board is an upgraded version of the
ALL-H3-CC. Changes include:

  - Gigabit Ethernet via external RTL8211E Ethernet PHY
  - 16 MiB SPI NOR flash memory
  - PoE tap header
  - Line out jack removed

Only H5 variant test samples were made available, and the vendor is not
certain whether other SoC variants would be made or not. Furthermore the
board is a minor upgrade compared to the ALL-H3-CC. Thus the device tree
simply includes the one for the ALL-H3-CC, and adds the changes on top.

The device tree was synced over from the Linux kernel, along with other
H3/H5 changes, in a previous patch. Thus only the defconfig and an entry
to the MAINTAINERS file is added.

Signed-off-by: Chen-Yu Tsai 
---
 board/sunxi/MAINTAINERS  |  5 +
 configs/libretech_all_h5_cc_h5_defconfig | 23 +++
 2 files changed, 28 insertions(+)
 create mode 100644 configs/libretech_all_h5_cc_h5_defconfig

diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index ed620ade766c..1180b86db3ba 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -323,6 +323,11 @@ M: Chen-Yu Tsai 
 S: Maintained
 F: configs/libretech_all_h3_it_h5_defconfig
 
+LIBRETECH ALL-H5-CC BOARDS
+M: Chen-Yu Tsai 
+S: Maintained
+F: configs/libretech_all_h5_cc_h5_defconfig
+
 NANOPI-M1 BOARD
 M: Mylène Josserand 
 S: Maintained
diff --git a/configs/libretech_all_h5_cc_h5_defconfig 
b/configs/libretech_all_h5_cc_h5_defconfig
new file mode 100644
index ..97a1b6ddae39
--- /dev/null
+++ b/configs/libretech_all_h5_cc_h5_defconfig
@@ -0,0 +1,23 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL=y
+CONFIG_MACH_SUN50I_H5=y
+CONFIG_DRAM_CLK=672
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2
+CONFIG_SPL_SPI_SUNXI=y
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_USE_PREBOOT=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-libretech-all-h5-cc"
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH_XMC=y
+CONFIG_SUN8I_EMAC=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
-- 
2.24.1

[PATCH 1/3] sunxi: H3/H5 Sync DT files from upstream Linux kernel as of next-20200108

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Sync the device tree files and device tree header files from upstream
Linux kernel, as of 2020-01-08. The commit synced to in the sunxi repo

98d25b0b266d Merge branch 'sunxi/dt-for-5.6' into sunxi/for-next

which is also part of next-20200108.

Changes brought in include:

  - cleanup of pinmux node names
  - addition of Security ID, MBUS, CSI, crypto engine, video codec,
pmu, and thermal sensor device nodes for both SoCs
  - addition of deinterlacing engine device node on H3
  - cleanup of RTC device node and addition of its clocks
  - various board cleanups and improvements
- removal of pinmux node for GPIO lines
- cpufreq / DVFS
- HDMI output
- UART-based Bluetooth
- audio codec
- USB ports
  - new boards

Most of the changes don't concern U-boot.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/dts/Makefile |   9 +-
 .../dts/sun50i-h5-bananapi-m2-plus-v1.2.dts   |  11 ++
 .../sun50i-h5-emlid-neutis-n5-devboard.dts| 137 ++---
 arch/arm/dts/sun50i-h5-emlid-neutis-n5.dtsi   |  95 +
 .../arm/dts/sun50i-h5-libretech-all-h3-cc.dts |  10 +-
 .../arm/dts/sun50i-h5-libretech-all-h3-it.dts |  11 ++
 .../arm/dts/sun50i-h5-libretech-all-h5-cc.dts |  61 ++
 arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts   |  53 +
 arch/arm/dts/sun50i-h5-nanopi-neo2.dts|  45 +
 arch/arm/dts/sun50i-h5-orangepi-pc2.dts   |  47 +
 arch/arm/dts/sun50i-h5-orangepi-prime.dts |  52 +
 arch/arm/dts/sun50i-h5-orangepi-zero-plus.dts |  11 +-
 .../arm/dts/sun50i-h5-orangepi-zero-plus2.dts |  46 +
 arch/arm/dts/sun50i-h5.dtsi   | 186 +-
 .../dts/sun8i-h2-plus-bananapi-m2-zero.dts|  40 +++-
 arch/arm/dts/sun8i-h2-plus-orangepi-r1.dts|   2 -
 arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts  |  22 ++-
 .../dts/sun8i-h3-bananapi-m2-plus-v1.2.dts|  13 ++
 arch/arm/dts/sun8i-h3-beelink-x2.dts  |  11 +-
 .../sun8i-h3-emlid-neutis-n5h3-devboard.dts   |  72 +++
 arch/arm/dts/sun8i-h3-emlid-neutis-n5h3.dtsi  |  11 ++
 arch/arm/dts/sun8i-h3-mapleboard-mp130.dts| 152 ++
 arch/arm/dts/sun8i-h3-nanopi-duo2.dts | 173 
 arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts  |  28 ++-
 arch/arm/dts/sun8i-h3-nanopi-m1.dts   |   2 +-
 arch/arm/dts/sun8i-h3-nanopi-neo-air.dts  |   2 +-
 arch/arm/dts/sun8i-h3-nanopi.dtsi |  25 +--
 arch/arm/dts/sun8i-h3-orangepi-2.dts  |  34 +---
 arch/arm/dts/sun8i-h3-orangepi-lite.dts   |  27 +--
 arch/arm/dts/sun8i-h3-orangepi-one.dts|  28 +--
 arch/arm/dts/sun8i-h3-orangepi-pc.dts |  27 +--
 arch/arm/dts/sun8i-h3-orangepi-plus.dts   |  23 ++-
 arch/arm/dts/sun8i-h3-orangepi-zero-plus2.dts |   2 +-
 arch/arm/dts/sun8i-h3-rervision-dvk.dts   | 114 +++
 arch/arm/dts/sun8i-h3.dtsi|  86 +++-
 arch/arm/dts/sunxi-bananapi-m2-plus-v1.2.dtsi |  30 +++
 arch/arm/dts/sunxi-bananapi-m2-plus.dtsi  |   7 +-
 arch/arm/dts/sunxi-h3-h5-emlid-neutis.dtsi| 170 
 arch/arm/dts/sunxi-h3-h5.dtsi | 137 -
 arch/arm/dts/sunxi-libretech-all-h3-cc.dtsi   |  65 +-
 arch/arm/dts/sunxi-libretech-all-h3-it.dtsi   | 180 +
 include/dt-bindings/clock/sun8i-h3-ccu.h  |  11 +-
 include/dt-bindings/reset/sun8i-h3-ccu.h  |   5 +-
 43 files changed, 1550 insertions(+), 723 deletions(-)
 create mode 100644 arch/arm/dts/sun50i-h5-bananapi-m2-plus-v1.2.dts
 create mode 100644 arch/arm/dts/sun50i-h5-libretech-all-h3-it.dts
 create mode 100644 arch/arm/dts/sun50i-h5-libretech-all-h5-cc.dts
 create mode 100644 arch/arm/dts/sun8i-h3-bananapi-m2-plus-v1.2.dts
 create mode 100644 arch/arm/dts/sun8i-h3-emlid-neutis-n5h3-devboard.dts
 create mode 100644 arch/arm/dts/sun8i-h3-emlid-neutis-n5h3.dtsi
 create mode 100644 arch/arm/dts/sun8i-h3-mapleboard-mp130.dts
 create mode 100644 arch/arm/dts/sun8i-h3-nanopi-duo2.dts
 create mode 100644 arch/arm/dts/sun8i-h3-rervision-dvk.dts
 create mode 100644 arch/arm/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
 create mode 100644 arch/arm/dts/sunxi-h3-h5-emlid-neutis.dtsi
 create mode 100644 arch/arm/dts/sunxi-libretech-all-h3-it.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 983e235f4427..b89ed48e9a4e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -513,8 +513,12 @@ dtb-$(CONFIG_MACH_SUN8I_H3) += \
sun8i-h2-plus-orangepi-r1.dtb \
sun8i-h2-plus-orangepi-zero.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
+   sun8i-h3-bananapi-m2-plus-v1.2.dtb \
sun8i-h3-beelink-x2.dtb \
+   sun8i-h3-emlid-neutis-n5h3-devboard.dtb \
sun8i-h3-libretech-all-h3-cc.dtb \
+   sun8i-h3-mapleboard-mp130.dtb \
+   sun8i-h3-nanopi-duo2.dtb \
sun8i-h3-nanopi-m1.dtb \
sun8i-h3-nanopi-m1-plus.dtb \
sun8i-h3-nanopi-neo.dtb \
@@ -526,7 +530,8 @@ dtb-$(CONFI

Re: [PATCH 0/3] sunxi: Sync H3/H5 DT and add ALL-H3-IT and ALL-H5-CC

[Chen-Yu Tsai]

Hi Jagan,

On Sun, Jan 12, 2020 at 11:36 PM Chen-Yu Tsai  wrote:
>
> From: Chen-Yu Tsai 
>
> Hi everyone,
>
> This patch series syncs up the device tree files and header files for
> Allwinner H3/H5 SoCs and related boards to linux-next-20200108, and
> then adds support for Libre Computer ALL-H3-IT H5 and ALL-H5-CC H5
> boards.
>
> Patch 1 syncs up the device tree files and related device tree binding
> header files for the Allwinner H3 and H5 SoCs, and boards using these
> chips. These were compile tested.
>
> Patch 2 adds a defconfig and MAINTAINERS entry for the ALL-H3-IT's H5
> variant. Other variants will be added as they are made available.
>
> Patch 3 adds a defconfig and MAINTAINERS entry for the ALL-H5-CC's H5
> variant. Other variants will be added as they are made available.
>
> Please have a look.

One week left in the merge window. Any thoughts on this series?

Thanks
ChenYu

> Regards
> ChenYu
>
>
> Chen-Yu Tsai (3):
>   sunxi: H3/H5 Sync DT files from upstream Linux kernel as of
> next-20200108
>   sunxi: Add Libre Computer ALL-H3-IT H5 board
>   sunxi: Add Libre Computer ALL-H5-CC H5 board
>
>  arch/arm/dts/Makefile |   9 +-
>  .../dts/sun50i-h5-bananapi-m2-plus-v1.2.dts   |  11 ++
>  .../sun50i-h5-emlid-neutis-n5-devboard.dts| 137 ++---
>  arch/arm/dts/sun50i-h5-emlid-neutis-n5.dtsi   |  95 +
>  .../arm/dts/sun50i-h5-libretech-all-h3-cc.dts |  10 +-
>  .../arm/dts/sun50i-h5-libretech-all-h3-it.dts |  11 ++
>  .../arm/dts/sun50i-h5-libretech-all-h5-cc.dts |  61 ++
>  arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts   |  53 +
>  arch/arm/dts/sun50i-h5-nanopi-neo2.dts|  45 +
>  arch/arm/dts/sun50i-h5-orangepi-pc2.dts   |  47 +
>  arch/arm/dts/sun50i-h5-orangepi-prime.dts |  52 +
>  arch/arm/dts/sun50i-h5-orangepi-zero-plus.dts |  11 +-
>  .../arm/dts/sun50i-h5-orangepi-zero-plus2.dts |  46 +
>  arch/arm/dts/sun50i-h5.dtsi   | 186 +-
>  .../dts/sun8i-h2-plus-bananapi-m2-zero.dts|  40 +++-
>  arch/arm/dts/sun8i-h2-plus-orangepi-r1.dts|   2 -
>  arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts  |  22 ++-
>  .../dts/sun8i-h3-bananapi-m2-plus-v1.2.dts|  13 ++
>  arch/arm/dts/sun8i-h3-beelink-x2.dts  |  11 +-
>  .../sun8i-h3-emlid-neutis-n5h3-devboard.dts   |  72 +++
>  arch/arm/dts/sun8i-h3-emlid-neutis-n5h3.dtsi  |  11 ++
>  arch/arm/dts/sun8i-h3-mapleboard-mp130.dts| 152 ++
>  arch/arm/dts/sun8i-h3-nanopi-duo2.dts | 173 
>  arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts  |  28 ++-
>  arch/arm/dts/sun8i-h3-nanopi-m1.dts   |   2 +-
>  arch/arm/dts/sun8i-h3-nanopi-neo-air.dts  |   2 +-
>  arch/arm/dts/sun8i-h3-nanopi.dtsi |  25 +--
>  arch/arm/dts/sun8i-h3-orangepi-2.dts  |  34 +---
>  arch/arm/dts/sun8i-h3-orangepi-lite.dts   |  27 +--
>  arch/arm/dts/sun8i-h3-orangepi-one.dts|  28 +--
>  arch/arm/dts/sun8i-h3-orangepi-pc.dts |  27 +--
>  arch/arm/dts/sun8i-h3-orangepi-plus.dts   |  23 ++-
>  arch/arm/dts/sun8i-h3-orangepi-zero-plus2.dts |   2 +-
>  arch/arm/dts/sun8i-h3-rervision-dvk.dts   | 114 +++
>  arch/arm/dts/sun8i-h3.dtsi|  86 +++-
>  arch/arm/dts/sunxi-bananapi-m2-plus-v1.2.dtsi |  30 +++
>  arch/arm/dts/sunxi-bananapi-m2-plus.dtsi  |   7 +-
>  arch/arm/dts/sunxi-h3-h5-emlid-neutis.dtsi| 170 
>  arch/arm/dts/sunxi-h3-h5.dtsi | 137 -
>  arch/arm/dts/sunxi-libretech-all-h3-cc.dtsi   |  65 +-
>  arch/arm/dts/sunxi-libretech-all-h3-it.dtsi   | 180 +
>  board/sunxi/MAINTAINERS   |  10 +
>  configs/libretech_all_h3_it_h5_defconfig  |  22 +++
>  configs/libretech_all_h5_cc_h5_defconfig  |  23 +++
>  include/dt-bindings/clock/sun8i-h3-ccu.h  |  11 +-
>  include/dt-bindings/reset/sun8i-h3-ccu.h  |   5 +-
>  46 files changed, 1605 insertions(+), 723 deletions(-)
>  create mode 100644 arch/arm/dts/sun50i-h5-bananapi-m2-plus-v1.2.dts
>  create mode 100644 arch/arm/dts/sun50i-h5-libretech-all-h3-it.dts
>  create mode 100644 arch/arm/dts/sun50i-h5-libretech-all-h5-cc.dts
>  create mode 100644 arch/arm/dts/sun8i-h3-bananapi-m2-plus-v1.2.dts
>  create mode 100644 arch/arm/dts/sun8i-h3-emlid-neutis-n5h3-devboard.dts
>  create mode 100644 arch/arm/dts/sun8i-h3-emlid-neutis-n5h3.dtsi
>  create mode 100644 arch/arm/dts/sun8i-h3-mapleboard-mp130.dts
>  create mode 100644 arch/arm/dts/sun8i-h3-nanopi-duo2.dts
>  create mode 100644 arch/arm/dts/sun8i-h3-rervision-dvk.dts
>  create mode 100644 arch/arm/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
>  create mode 100644 arch/arm/dts/sunxi-h3-h5-emlid-neutis.dtsi
>  create mode 100644 arch/arm/dts/sunxi-libretech-all-h3-it.dtsi
>  create mode 100644 configs/libretech_all_h3_it_h5_defconfig
>  create mode 100644 configs/libretech_all_h5_cc_h5_defconfig
>
> --
> 2.24.1
>

Re: [PATCH 10/11] rockchip: misc: Set eth1addr mac address

[Chen-Yu Tsai]

On Thu, Feb 16, 2023 at 7:57 AM Jonas Karlman  wrote:
>
> Set eth1addr when there is an ethernet1 alias in the fdt.

Maybe it makes sense to set it regardless whether an alias is present
or not?

The user might be loading a custom FDT for the kernel, or have DT
overlays stacked on, either could have the "ethernet1" alias while
the U-boot DT doesn't.

ChenYu

> Also allow fdt fixup of ethernet mac addresses when CMD_NET is disabled.
> Set ethaddr and eth1addr based on HASH and SHA256 options.
>
> Signed-off-by: Jonas Karlman 
> ---
>  arch/arm/mach-rockchip/misc.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-rockchip/misc.c b/arch/arm/mach-rockchip/misc.c
> index b350f18f1140..aceaea6b29b7 100644
> --- a/arch/arm/mach-rockchip/misc.c
> +++ b/arch/arm/mach-rockchip/misc.c
> @@ -21,9 +21,11 @@
>
>  #include 
>
> +DECLARE_GLOBAL_DATA_PTR;
> +
>  int rockchip_setup_macaddr(void)
>  {
> -#if IS_ENABLED(CONFIG_CMD_NET)
> +#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256)
> int ret;
> const char *cpuid = env_get("cpuid#");
> u8 hash[SHA256_SUM_LEN];
> @@ -52,6 +54,12 @@ int rockchip_setup_macaddr(void)
> mac_addr[0] &= 0xfe;  /* clear multicast bit */
> mac_addr[0] |= 0x02;  /* set local assignment bit (IEEE802) */
> eth_env_set_enetaddr("ethaddr", mac_addr);
> +
> +   if (gd->fdt_blob && fdt_get_alias(gd->fdt_blob, "ethernet1")) {
> +   /* Make a valid MAC address for eth1 */
> +   mac_addr[5] += 0x20;
> +   eth_env_set_enetaddr("eth1addr", mac_addr);
> +   }
>  #endif
> return 0;
>  }
> --
> 2.39.1
>

Re: [PATCH v2] sunxi: psci: Fix sunxi_power_switch on sun8i-r40 platform

[Chen-Yu Tsai]

Hi,

On Sat, May 14, 2022 at 11:19 AM  wrote:
>
> From: qianfan Zhao 
>
> linux system will die if we offline one of the cpu on R40 based board:
> eg: echo 0 > /sys/devices/system/cpu/cpu3/online
>
> Fixed sunxi_power_switch based on allwinner lichee 3.10 kernel driver.
>
> Signed-off-by: qianfan Zhao 

Please add a Fixes tag.

> ---
> v2 changes: Fix the commit message, the source code doesn't change.
>
>  arch/arm/cpu/armv7/sunxi/psci.c | 24 +++-
>  1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/sunxi/psci.c b/arch/arm/cpu/armv7/sunxi/psci.c
> index 1ac50f558a..63186a9388 100644
> --- a/arch/arm/cpu/armv7/sunxi/psci.c
> +++ b/arch/arm/cpu/armv7/sunxi/psci.c
> @@ -79,8 +79,7 @@ static void __secure __mdelay(u32 ms)
>  static void __secure clamp_release(u32 __maybe_unused *clamp)
>  {
>  #if defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN7I) || \
> -   defined(CONFIG_MACH_SUN8I_H3) || \
> -   defined(CONFIG_MACH_SUN8I_R40)
> +   defined(CONFIG_MACH_SUN8I_H3)
> u32 tmp = 0x1ff;
> do {
> tmp >>= 1;
> @@ -88,15 +87,30 @@ static void __secure clamp_release(u32 __maybe_unused 
> *clamp)
> } while (tmp);
>
> __mdelay(10);
> +#elif defined(CONFIG_MACH_SUN8I_R40)
> +   u8 i, tmp = 0xfe;
> +
> +   for (i = 0; i < 5; i++) { /* 0xfe, 0xf8, 0xe0, 0x80, 0x00 */
> +   writel(tmp, clamp);
> +   tmp <<= 2;
> +   }
> +
> +   while (0x00 != readl(clamp)) {
> +   ;
> +   }
>  #endif
>  }
>
>  static void __secure clamp_set(u32 __maybe_unused *clamp)
>  {
>  #if defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN7I) || \
> -   defined(CONFIG_MACH_SUN8I_H3) || \
> -   defined(CONFIG_MACH_SUN8I_R40)
> +   defined(CONFIG_MACH_SUN8I_H3)
> writel(0xff, clamp);
> +#elif defined(CONFIG_MACH_SUN8I_R40)
> +   writel(0xff, clamp);
> +   while (0xff != readl(clamp)) {
> +   ;
> +   }
>  #endif
>  }
>
> @@ -153,7 +167,7 @@ static void __secure sunxi_cpu_set_power(int cpu, bool on)
>
> sunxi_power_switch((void *)cpucfg + SUN8I_R40_PWR_CLAMP(cpu),
>(void *)cpucfg + SUN8I_R40_PWROFF,
> -  on, 0);
> +  on, cpu);

I think this is the only change that is needed. Looking again at the
R40 user manual, the original code turned off core 0 regardless of
which core was being brought down.

Could you give that a try? The power clamp stuff shouldn't change
much, as the end result is the same. The readback might make a
difference, but if it does, it should be applied to all SoCs.


Regards
ChenYu

>  }
>  #else /* ! CONFIG_MACH_SUN7I && ! CONFIG_MACH_SUN8I_R40 */
>  static void __secure sunxi_cpu_set_power(int cpu, bool on)
> --
> 2.25.1
>

Re: [U-Boot] [PATCH 2/9] ARM: Factor out reusable psci_cpu_entry

[Chen-Yu Tsai]

Hi,

On Sun, Feb 15, 2015 at 5:28 AM, Jan Kiszka  wrote:
> From: Jan Kiszka 
>
> _sunxi_cpu_entry can be converted completely into a reusable
> psci_cpu_entry. Tegra124 will use it as well.
>
> Signed-off-by: Jan Kiszka 
> ---
>  arch/arm/cpu/armv7/psci.S   | 19 +++
>  arch/arm/cpu/armv7/sunxi/psci.S | 21 ++---
>  2 files changed, 21 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/psci.S b/arch/arm/cpu/armv7/psci.S
> index d688607..e916d71 100644
> --- a/arch/arm/cpu/armv7/psci.S
> +++ b/arch/arm/cpu/armv7/psci.S
> @@ -170,4 +170,23 @@ ENTRY(psci_cpu_off_common)
> bx  lr
>  ENDPROC(psci_cpu_off_common)
>
> +ENTRY(psci_cpu_entry)
> +   @ Set SMP bit
> +   mrc p15, 0, r0, c1, c0, 1   @ ACTLR
> +   orr r0, r0, #(1 << 6)   @ Set SMP bit
> +   mcr p15, 0, r0, c1, c0, 1   @ ACTLR
> +   isb
> +
> +   bl  _nonsec_init
> +   bl  psci_arch_init
> +
> +   adr r0, _psci_target_pc
> +   ldr r0, [r0]
> +   b   _do_nonsec_entry
> +ENDPROC(psci_cpu_entry)
> +
> +.globl _psci_target_pc
> +_psci_target_pc:
> +   .word   0

The sunxi version didn't have a per-core target_pc variable.
It is still the case here. Is this the correct way to implement
it? I see per-core storage of this in some of the kernel's smp
ops.

On sunxi it works because the only platform using it only has
one secondary core.


ChenYu

> +
> .popsection
> diff --git a/arch/arm/cpu/armv7/sunxi/psci.S b/arch/arm/cpu/armv7/sunxi/psci.S
> index 6785fdd..c3a8dc1 100644
> --- a/arch/arm/cpu/armv7/sunxi/psci.S
> +++ b/arch/arm/cpu/armv7/sunxi/psci.S
> @@ -138,7 +138,7 @@ out:mcr p15, 0, r7, c1, c1, 0
> @ r2 = target PC
>  .globl psci_cpu_on
>  psci_cpu_on:
> -   adr r0, _target_pc
> +   ldr r0, =_psci_target_pc
> str r2, [r0]
> dsb
>
> @@ -150,7 +150,7 @@ psci_cpu_on:
> mov r4, #1
> lsl r4, r4, r1
>
> -   adr r6, _sunxi_cpu_entry
> +   ldr r6, =psci_cpu_entry
> str r6, [r0, #0x1a4] @ PRIVATE_REG (boot vector)
>
> @ Assert reset on target CPU
> @@ -196,23 +196,6 @@ psci_cpu_on:
> mov r0, #ARM_PSCI_RET_SUCCESS   @ Return PSCI_RET_SUCCESS
> mov pc, lr
>
> -_target_pc:
> -   .word   0
> -
> -_sunxi_cpu_entry:
> -   @ Set SMP bit
> -   mrc p15, 0, r0, c1, c0, 1
> -   orr r0, r0, #0x40
> -   mcr p15, 0, r0, c1, c0, 1
> -   isb
> -
> -   bl  _nonsec_init
> -   bl  psci_arch_init
> -
> -   adr r0, _target_pc
> -   ldr r0, [r0]
> -   b   _do_nonsec_entry
> -
>  .globl psci_cpu_off
>  psci_cpu_off:
> bl  psci_cpu_off_common
> --
> 2.1.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] [PATCH v1 9/9] sunxi: add gmac Ethernet support

[Chen-Yu Tsai]

On Fri, Mar 14, 2014 at 6:33 PM, Ian Campbell  wrote:
> Based linux-sunxi#sunxi commit d854c4de2f57 "arm: Handle .gnu.hash section in
> ldscripts" vs v2014.01.
>
> Signed-off-by: Chen-Yu Tsai 
> Signed-off-by: Jens Kuske 
> Signed-off-by: Ian Campbell 
> ---
>  arch/arm/cpu/armv7/sunxi/board.c | 15 +
>  boards.cfg   |  4 +--
>  drivers/net/Makefile |  1 +
>  drivers/net/sunxi_gmac.c | 34 
>  include/configs/sunxi-common.h   | 68 
> 
>  5 files changed, 120 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/net/sunxi_gmac.c
[..]
> diff --git a/drivers/net/sunxi_gmac.c b/drivers/net/sunxi_gmac.c
> new file mode 100644
> index 000..432d7b2
> --- /dev/null
> +++ b/drivers/net/sunxi_gmac.c
> @@ -0,0 +1,34 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +int sunxi_gmac_initialize(bd_t *bis)
> +{
> +   int pin;
> +   struct sunxi_ccm_reg *const ccm =
> +   (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
> +
> +   /* Set up clock gating */
> +   setbits_le32(&ccm->ahb_gate1, 0x1 << AHB_GATE_OFFSET_GMAC);
> +
> +   /* Set MII clock */
> +   setbits_le32(&ccm->gmac_clk_cfg, CCM_GMAC_CTRL_TX_CLK_SRC_INT_RGMII |
> +   CCM_GMAC_CTRL_GPIT_RGMII);
> +
> +   /* Configure pin mux settings for GMAC */
> +   for (pin = SUNXI_GPA(0); pin <= SUNXI_GPA(16); pin++) {
> +   /* skip unused pins in RGMII mode */
> +   if (pin == SUNXI_GPA(9) || pin == SUNXI_GPA(14))
> +   continue;
> +   sunxi_gpio_set_cfgpin(pin, 5);
> +   sunxi_gpio_set_drv(pin, 3);
> +   }
> +
> +   designware_initialize(0, SUNXI_GMAC_BASE, 0x1, 
> PHY_INTERFACE_MODE_RGMII);

Hi,

Thanks for working on this!

I see you left out all the CONFIG_RGMII ifdefs from this file. Not
sure if it's because you're aiming to support only the Cubietruck
first. I think you should keep them in the same patch. You can then
just add the appropriate config options when support of other A20
boards roll in.

There are 3 changes to the designware driver since u-boot-sunxi's
last merge (2014.1-rc1):

50b0df8 net/designware: make driver compatible with data cache
92a190a net/designware - switch driver to phylib usage
74cb708 net/designware: add explicit reset of {tx|rx}_currdescnum

The move to phylib will likely break the current code. Maybe we could
merge 2014.4-rc1 in to fix it first.

Also, GMAC support depends on

5a51af3 net/designware: Reduce DMA burst length

by Jens Kuske (jemk). Neither of us bothered to send this upstream yet.

Cheers
ChenYu


> +
> +   return 0;
> +}
[..]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] Re: [PATCH v1 7/9] sunxi: mmc support

[Chen-Yu Tsai]

On Mon, Mar 17, 2014 at 4:38 AM, Ian Campbell  wrote:
> On Fri, 2014-03-14 at 17:36 +0200, Pantelis Antoniou wrote:
>> [...]
>
> Thanks for your review. It seems there are still quite a few issues
> dating back to the original allwinner dumps here.
>
> @linux-sunxi: if anyone wants to volunteer to help cleanup this
> particular driver I'd be very happy -- there's a lot of it!
>
>> +
>> > +static void dumpmmcreg(struct sunxi_mmc *reg)
>> > +{
>> > +   debug("dump mmc registers:\n");
>> > +   debug("gctrl 0x%08x\n", reg->gctrl);
>> > +   debug("clkcr 0x%08x\n", reg->clkcr);
>> > +   debug("timeout   0x%08x\n", reg->timeout);
>> > +   debug("width 0x%08x\n", reg->width);
>> > +   debug("blksz 0x%08x\n", reg->blksz);
>> [...] lots more debug(foo)
>> > +}
>>
>> ^^^ #ifdef DEBUG here?
>
> I can if you prefer but debug() itself effectively includes the same
> ifdef so the end result is already the same.
>
>> [...]
>
>> > +/* support 4 mmc hosts */
>> > +struct mmc mmc_dev[4];
>> > +struct sunxi_mmc_host mmc_host[4];
>> > +
>>
>> ^ hosts & mmc structs can be allocated even for SPL now
>
> Can be or must be?
>
>> > +   struct sunxi_mmc_host *mmchost = &mmc_host[sdc_no];
>> > +   static struct sunxi_gpio *gpio_c =
>> > +   &((struct sunxi_gpio_reg 
>> > *)SUNXI_PIO_BASE)->gpio_bank[SUNXI_GPIO_C];
>> > +   static struct sunxi_gpio *gpio_f =
>> > +   &((struct sunxi_gpio_reg 
>> > *)SUNXI_PIO_BASE)->gpio_bank[SUNXI_GPIO_F];
>> > +#if CONFIG_MMC1_PG
>> > +   static struct sunxi_gpio *gpio_g =
>> > +   &((struct sunxi_gpio_reg 
>> > *)SUNXI_PIO_BASE)->gpio_bank[SUNXI_GPIO_G];
>> > +#endif
>> > +   static struct sunxi_gpio *gpio_h =
>> > +   &((struct sunxi_gpio_reg 
>> > *)SUNXI_PIO_BASE)->gpio_bank[SUNXI_GPIO_H];
>> > +   static struct sunxi_gpio *gpio_i =
>> > +   &((struct sunxi_gpio_reg 
>> > *)SUNXI_PIO_BASE)->gpio_bank[SUNXI_GPIO_I];
>> > +   struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
>> > +
>>
>> ^ Castings are ugly; rework with a temporary variable.
>
> Ack.
>
> The static's here are odd too and date back to the original alwinner
> code dumps. I'll get rid of them too.

You can drop the gpio ones in favor of using the sunxi gpio driver.

>> [...]
>> > +   case 3:
>> > +   /* PI4-CMD, PI5-CLK, PI6~9-D0~D3 : 2 */
>> > +   writel(0x << 16, &gpio_i->cfg[0]);
>> > +   writel(0x22, &gpio_i->cfg[1]);
>> > +   writel(0x555 << 8, &gpio_i->pull[0]);
>> > +   writel(0x555 << 8, &gpio_i->drv[0]);
>> > +   break;
>> > +
>> > +   default:
>> > +   return -1;
>> > +   }
>> > +
>>
>> Lots of magic constants. I have no idea what's going on here.
>> Use a few defines.
>
> Right. These came from the original allwinner dumps so I was worried
> that they might be undocumented magic, but actually since the are gpio
> frobbing I reckon I can figure them out.

Should be something like this:

for (pin = SUNXI_GPI(4); pin <= SUNXI_GPI(9); pin++) {
sunxi_gpio_set_cfgpin(pin, SUNXI_GPI_SDC3);
sunxi_gpio_set_drv(pin, 1);
sunxi_gpio_set_pull(pin, SUNXI_PULL_UP);
}

Note that SUNXI_GPI_* and SUNXI_PULL_* have not been defined.

I will send a patch for both the macros and MMC pinmux setting.

[..]

Thanks for working on this!


Cheers
ChenYu
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/6] sunxi: add Cubieboard2 support

[Chen-Yu Tsai]

On Thu, Jul 24, 2014 at 11:12 AM, Siarhei Siamashka
 wrote:
> On Thu,  5 Jun 2014 19:00:14 +0100
> Ian Campbell  wrote:
>
>> This is a sun7i (A20) based followup to the sun4i (A10)
>> Cubieboard. It has GMAC using MII mode.
>>
>> Signed-off-by: Ian Campbell 
>> Acked-by: Hans de Goede 
>
> This board is using exactly the same PCB as the Cubieboard1. And only
> the SoC is different (Allwinner A20 instead of the pin-compatible
> Allwinner A10).
>
> Before piling up more board configurations, we might want to consider
> supporting both Cubieboard1 and Cubieboard2 with a single u-boot binary
> (and perhaps keep Cubieboard1 and Cubieboard2 as aliases in boards.cfg).
> The Allwinner SoCs have support for runtime identification of the SoC
> type (sun4i/sun5i/sun7i) via the VER_REG (Version Register) located at
> the address 0x01C00024 as explained in the Allwinner A20 user manual.
> This requires replacing all the CONFIG_SUN4I/CONFIG_SUN5I/CONFIG_SUN7I
> ifdefs in the u-boot code with a runtime SoC type checks, but there
> are not too many places affected (mostly just the DRAM code).

A20 will need PSCI for SMP and virtualization support.
(I know the related code isn't in there yet.)
Won't this be slightly hard to do if you mix them together?

Just a though.

Cheers
ChenYu

> Here is a quick and dirty example (not a patch submission yet), which
> allows to boot the Cubieboard2 hardware using the existing Cubieboard1
> config:
> https://github.com/ssvb/u-boot-sunxi-dram/commit/3153905e0221
>
> If the u-boot code is further extended to define a variable with the
> relevant dtb file name in the u-boot environment (depending on the
> runtime detected SoC type and selecting from "sun4i-a10-cubieboard.dtb"
> and "sun7i-a20-cubieboard2.dtb"), then we can have the same SD card
> with the whole pre-installed Linux system usable on both Cubieboard1
> and Cubieboard2 hardware by just swapping the card.
>
> Also the Cubieboards are not alone. Sharing the same PCB happens for
> the LIME boards from Olimex too:
>https://www.olimex.com/Products/OLinuXino/A10/A10-OLinuXino-LIME
>https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME
>
>>  Active  arm armv7  sunxi   -   sunxi
>>Cubieboard
>> sun4i:CUBIEBOARD,SPL,AXP209_POWER,SUNXI_EMAC 
>>  Hans de Goede 
>> 
>> +Active  arm armv7  sunxi   -   sunxi
>>Cubieboard2   
>> sun7i:CUBIEBOARD2,SPL,SUNXI_GMAC 
>>  Ian Campbell 
>> :Hans de Goede 
>> +Active  arm armv7  sunxi   -   sunxi
>>Cubieboard2_FEL   
>> sun7i:CUBIEBOARD2,SPL_FEL,SUNXI_GMAC 
>>  Ian Campbell 
>> :Hans de Goede 
>
> The newly added Cubieboard2 from your patch appears to be missing the
> important AXP209_POWER option. So the patch is not good enough to be
> pushed anywhere in its current form.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] Re: [PATCH 4/7] sunxi: Add CONFIG_MACPWR option

[Chen-Yu Tsai]

On Mon, Jul 28, 2014 at 3:48 PM, Ian Campbell  wrote:
> On Sun, 2014-07-27 at 23:25 +0200, Hans de Goede wrote:
>> On some boards the phy needs to be powered up through a gpio, add support for
>> this.
>
> I assume from the context that this is the Ethernet PHY?
>
> I'm a bit surprised there isn't some sort of de facto existing naming
> etc for something like this, but if there is my grep's aren't finding it
> so:

My guess would be most other platforms have separate board files
for each board they support, instead of our mixed approach.

They can just put whatever GPIO poking stuff in them under one of the
standard weak symbols.

>> Signed-off-by: Hans de Goede 
>
> Acked-by: Ian Campbell 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 6/7] sunxi: Kconfig: move common settings into a shared code block

[Chen-Yu Tsai]

On Tue, Aug 5, 2014 at 5:26 AM, Ian Campbell  wrote:
> On Fri, 2014-08-01 at 09:46 +0200, Hans de Goede wrote:
>> SYS_CPU, SYS_BOARD and SYS_SOC are identical for all sunxi boards, move
>> them to a shared code block.
>>
>> Signed-off-by: Hans de Goede 
>
> This is an improvement so:
> Acked-by: Ian Campbell 
>
> But eventually we could clean up even more, e.g.
>
> config SYS_CONFIG_NAME
> string
> default "sun4i" if TARGET_SUN4I
> default "sun5i" if TARGET_SUN5I
> etc
>
> Possibly even some things should be select'd rather than default'd.

Selected sounds better. :)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/7] ARM: sunxi: Add basic support for Allwinner A31 (sun6i)

[Chen-Yu Tsai]

Hi everyone,

This series add basic support for Allwinner's A31 SoC. The patches,
excluding the first one, were cherry-picked from u-boot-sunxi. Due to
the difference between u-boot mainline and u-boot-sunxi, some patches
were rearranged or squashed to better fit the current state of u-boot,
and not introduce any build breaks. It follows Ian's initial merge
method of sun7i support: introducing various components first, then
enabling them in the last commit. I tried to keep the commits separate,
thus retaining the original author and Signed-off-bys.

Patch 1 adds a wrapper around "func(USB, usb, 0)" in BOOT_TARGET_DEVICES
to deal with breakage when USB support is not enabled.

Patch 2 adds memory addresses for some hardware blocks new in sun6i.

Patch 3 adds support for the new PRCM (power reset and clock management)
block, which also contains PLL bias voltage control.

Patch 4 adds support for the clock module. This patch is a bunch of
different sun6i related patches on the clock code, from when sun6i
support was introduced to u-boot-sunxi, up to its current form.
This is done to avoid various conflicts and needlessly introducing
then removing macros.

Patch 5 adds mmc support on sun6i.

Patch 6 adds uart0 muxing on sun6i.

Patch 7 enables sun6i support and adds defconfig for the Colombus board.



Cheers
ChenYu


Chen-Yu Tsai (2):
  ARM: sunxi: Fix build break when CONFIG_USB_EHCI is not defined
  ARM: sun6i: Add clock support

Hans de Goede (1):
  ARM: sunxi-mmc: Add mmc support for sun6i / A31

Maxime Ripard (2):
  ARM: sun6i: Setup the A31 UART0 muxing
  ARM: sunxi: Add basic A31 support

Oliver Schinagl (2):
  ARM: sun6i: Add base address for the new controllers in A31
  ARM: sun6i: Add support for the new power control module found on the
A31

 arch/arm/Kconfig  |   3 +
 arch/arm/cpu/armv7/sunxi/Makefile |   2 +
 arch/arm/cpu/armv7/sunxi/board.c  |   4 +
 arch/arm/cpu/armv7/sunxi/clock_sun6i.c| 107 
 arch/arm/cpu/armv7/sunxi/cpu_info.c   |   2 +
 arch/arm/cpu/armv7/sunxi/prcm.c   |  37 
 arch/arm/include/asm/arch-sunxi/clock.h   |   4 +
 arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 205 ++
 arch/arm/include/asm/arch-sunxi/cpu.h |   9 +
 arch/arm/include/asm/arch-sunxi/mmc.h |   2 -
 arch/arm/include/asm/arch-sunxi/prcm.h| 238 ++
 board/sunxi/Kconfig   |  10 +-
 configs/Colombus_defconfig|   4 +
 drivers/mmc/sunxi_mmc.c   |   9 +
 include/configs/sun6i.h   |  26 +++
 include/configs/sunxi-common.h|   8 +-
 16 files changed, 666 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/sunxi/clock_sun6i.c
 create mode 100644 arch/arm/cpu/armv7/sunxi/prcm.c
 create mode 100644 arch/arm/include/asm/arch-sunxi/clock_sun6i.h
 create mode 100644 arch/arm/include/asm/arch-sunxi/prcm.h
 create mode 100644 configs/Colombus_defconfig
 create mode 100644 include/configs/sun6i.h

-- 
2.1.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/7] ARM: sunxi: Fix build break when CONFIG_USB_EHCI is not defined

[Chen-Yu Tsai]

BOOT_TARGET_DEVICES includes USB unconditionally. This breaks when
CONFIG_CMD_USB is not defined. Use a secondary macro to conditionally
include it when CONFIG_EHCI is enabled, as we do for CONFIG_AHCI.

Signed-off-by: Chen-Yu Tsai 
---
 include/configs/sunxi-common.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 1d947d7..a31656e 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -233,10 +233,16 @@
 #define BOOT_TARGET_DEVICES_SCSI(func)
 #endif
 
+#ifdef CONFIG_USB_EHCI
+#define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0)
+#else
+#define BOOT_TARGET_DEVICES_USB(func)
+#endif
+
 #define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 0) \
BOOT_TARGET_DEVICES_SCSI(func) \
-   func(USB, usb, 0) \
+   BOOT_TARGET_DEVICES_USB(func) \
func(PXE, pxe, na) \
func(DHCP, dhcp, na)
 
-- 
2.1.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 6/7] ARM: sun6i: Setup the A31 UART0 muxing

[Chen-Yu Tsai]

From: Maxime Ripard 

Signed-off-by: Maxime Ripard 
Signed-off-by: Hans de Goede 
[w...@csie.org: commit message was "ARM: sunxi: Setup the A31 UART0 muxing"]
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/cpu/armv7/sunxi/board.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index f2cedbb..fc6aa4b 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -54,6 +54,10 @@ int gpio_init(void)
sunxi_gpio_set_cfgpin(SUNXI_GPB(22), SUN4I_GPB22_UART0_TX);
sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUN4I_GPB23_UART0_RX);
sunxi_gpio_set_pull(SUNXI_GPB(23), 1);
+#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_SUN6I)
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(20), 2);
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(21), 2);
+   sunxi_gpio_set_pull(SUNXI_GPH(21), 1);
 #elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_SUN5I)
sunxi_gpio_set_cfgpin(SUNXI_GPB(19), SUN5I_GPB19_UART0_TX);
sunxi_gpio_set_cfgpin(SUNXI_GPB(20), SUN5I_GPB20_UART0_RX);
-- 
2.1.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/7] ARM: sun6i: Add base address for the new controllers in A31

[Chen-Yu Tsai]

From: Oliver Schinagl 

A31 has several new and changed memory address. This patch adds them.

Signed-off-by: Oliver Schinagl 
Signed-off-by: Hans de Goede 
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/include/asm/arch-sunxi/cpu.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h 
b/arch/arm/include/asm/arch-sunxi/cpu.h
index a987e51d..313e6c8 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu.h
@@ -95,6 +95,11 @@
 #define SUNXI_MALI400_BASE 0x01c4
 #define SUNXI_GMAC_BASE0x01c5
 
+#define SUNXI_DRAM_COM_BASE0x01c62000
+#define SUNXI_DRAM_CTL_BASE0x01c63000
+#define SUNXI_DRAM_PHY_CH1_BASE0x01c65000
+#define SUNXI_DRAM_PHY_CH2_BASE0x01c66000
+
 /* module sram */
 #define SUNXI_SRAM_C_BASE  0x01d0
 
@@ -105,6 +110,10 @@
 #define SUNXI_MP_BASE  0x01e8
 #define SUNXI_AVG_BASE 0x01ea
 
+#define SUNXI_PRCM_BASE0x01f01400
+#define SUNXI_R_PIO_BASE   0x01f02c00
+#define SUNXI_P2WI_BASE0x01f03400
+
 /* CoreSight Debug Module */
 #define SUNXI_CSDM_BASE0x3f50
 
-- 
2.1.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 7/7] ARM: sunxi: Add basic A31 support

[Chen-Yu Tsai]

From: Maxime Ripard 

Add a new sun6i machine that doesn't do much for now.

Signed-off-by: Maxime Ripard 
Signed-off-by: Hans de Goede 
[w...@csie.org: use SPDX labels, adapt to Kconfig system, drop ifdef
around mmc and smp code, drop MACH_TYPE]
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/Kconfig|  3 +++
 arch/arm/cpu/armv7/sunxi/cpu_info.c |  2 ++
 board/sunxi/Kconfig | 10 +-
 configs/Colombus_defconfig  |  4 
 include/configs/sun6i.h | 26 ++
 5 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 configs/Colombus_defconfig
 create mode 100644 include/configs/sun6i.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 22f0f09..bfbe6f1 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -439,6 +439,9 @@ config TARGET_SUN4I
 config TARGET_SUN5I
bool "Support sun5i"
 
+config TARGET_SUN6I
+   bool "Support sun6i"
+
 config TARGET_SUN7I
bool "Support sun7i"
 
diff --git a/arch/arm/cpu/armv7/sunxi/cpu_info.c 
b/arch/arm/cpu/armv7/sunxi/cpu_info.c
index 5cf35ac..40c4e13 100644
--- a/arch/arm/cpu/armv7/sunxi/cpu_info.c
+++ b/arch/arm/cpu/armv7/sunxi/cpu_info.c
@@ -23,6 +23,8 @@ int print_cpuinfo(void)
case 7: puts("CPU:   Allwinner A10s (SUN5I)\n"); break;
default: puts("CPU:   Allwinner A1X (SUN5I)\n");
}
+#elif defined CONFIG_SUN6I
+   puts("CPU:   Allwinner A31 (SUN6I)\n");
 #elif defined CONFIG_SUN7I
puts("CPU:   Allwinner A20 (SUN7I)\n");
 #else
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 7bdf958..c78750e 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -14,6 +14,14 @@ config SYS_CONFIG_NAME
 
 endif
 
+if TARGET_SUN6I
+
+config SYS_CONFIG_NAME
+   string
+   default "sun6i"
+
+endif
+
 if TARGET_SUN7I
 
 config SYS_CONFIG_NAME
@@ -22,7 +30,7 @@ config SYS_CONFIG_NAME
 
 endif
 
-if TARGET_SUN4I || TARGET_SUN5I || TARGET_SUN7I
+if TARGET_SUN4I || TARGET_SUN5I || TARGET_SUN6I || TARGET_SUN7I
 
 config SYS_CPU
string
diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig
new file mode 100644
index 000..16800de
--- /dev/null
+++ b/configs/Colombus_defconfig
@@ -0,0 +1,4 @@
+CONFIG_SYS_EXTRA_OPTIONS="COLOMBUS"
+CONFIG_ARM=y
+CONFIG_TARGET_SUN6I=y
+CONFIG_FDTFILE="sun6i-a31-colombus.dtb"
diff --git a/include/configs/sun6i.h b/include/configs/sun6i.h
new file mode 100644
index 000..93a1d96
--- /dev/null
+++ b/include/configs/sun6i.h
@@ -0,0 +1,26 @@
+/*
+ * (C) Copyright 2012-2013 Henrik Nordstrom 
+ * (C) Copyright 2013 Luke Kenneth Casson Leighton 
+ * (C) Copyright 2013 Maxime Ripard 
+ *
+ * Configuration settings for the Allwinner A31 (sun6i) CPU
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/*
+ * A31 specific configuration
+ */
+#define CONFIG_SUN6I   /* sun6i SoC generation */
+
+#define CONFIG_SYS_PROMPT  "sun6i# "
+
+/*
+ * Include common sunxi configuration where most the settings are
+ */
+#include 
+
+#endif /* __CONFIG_H */
-- 
2.1.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/7] ARM: sun6i: Add support for the new power control module found on the A31

[Chen-Yu Tsai]

From: Oliver Schinagl 

To setup clocks and control voltages.

HdG: Rename the files from the somewhat generic pmu name to prcm.{c,h}
HdG: Make the prcm code only deal with the prcm, remove axp221 bits

Signed-off-by: Oliver Schinagl 
Signed-off-by: Hans de Goede 
[w...@csie.org: spacing fixes reported by checkpatch.pl]
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/cpu/armv7/sunxi/Makefile  |   1 +
 arch/arm/cpu/armv7/sunxi/prcm.c|  37 +
 arch/arm/include/asm/arch-sunxi/prcm.h | 238 +
 3 files changed, 276 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/sunxi/prcm.c
 create mode 100644 arch/arm/include/asm/arch-sunxi/prcm.h

diff --git a/arch/arm/cpu/armv7/sunxi/Makefile 
b/arch/arm/cpu/armv7/sunxi/Makefile
index e9721b2..f0473d2 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -11,6 +11,7 @@ obj-y += timer.o
 obj-y  += board.o
 obj-y  += clock.o
 obj-y  += pinmux.o
+obj-$(CONFIG_SUN6I)+= prcm.o
 obj-$(CONFIG_SUN4I)+= clock_sun4i.o
 obj-$(CONFIG_SUN5I)+= clock_sun4i.o
 obj-$(CONFIG_SUN7I)+= clock_sun4i.o
diff --git a/arch/arm/cpu/armv7/sunxi/prcm.c b/arch/arm/cpu/armv7/sunxi/prcm.c
new file mode 100644
index 000..8f9bea9
--- /dev/null
+++ b/arch/arm/cpu/armv7/sunxi/prcm.c
@@ -0,0 +1,37 @@
+/*
+ * Sunxi A31 Power Management Unit
+ *
+ * (C) Copyright 2013 Oliver Schinagl 
+ * http://linux-sunxi.org
+ *
+ * Based on sun6i sources and earlier U-Boot Allwiner A10 SPL work
+ *
+ * (C) Copyright 2006-2013
+ * Allwinner Technology Co., Ltd. 
+ * Berg Xing 
+ * Tom Cubie 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+void prcm_init_apb0(void)
+{
+   struct sunxi_prcm_reg *prcm =
+   (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
+   u32 reg_val;
+
+   reg_val = readl(&prcm->apb0_gate);
+   reg_val |= PRCM_APB0_GATE_P2WI | PRCM_APB0_GATE_PIO;
+   writel(reg_val, &prcm->apb0_gate);
+
+   reg_val = readl(&prcm->apb0_reset);
+   reg_val |= PRCM_APB0_RESET_P2WI | PRCM_APB0_RESET_PIO;
+   writel(reg_val, &prcm->apb0_reset);
+}
diff --git a/arch/arm/include/asm/arch-sunxi/prcm.h 
b/arch/arm/include/asm/arch-sunxi/prcm.h
new file mode 100644
index 000..1b40f09
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/prcm.h
@@ -0,0 +1,238 @@
+/*
+ * Sunxi A31 Power Management Unit register definition.
+ *
+ * (C) Copyright 2013 Oliver Schinagl 
+ * http://linux-sunxi.org
+ * Allwinner Technology Co., Ltd. 
+ * Berg Xing 
+ * Tom Cubie 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _SUNXI_PRCM_H
+#define _SUNXI_PRCM_H
+
+#define __PRCM_CPUS_CFG_PRE(n) (((n) & 0x3) << 4)
+#define PRCM_CPUS_CFG_PRE_MASK __PRCM_CPUS_CFG_PRE(0x3)
+#define __PRCM_CPUS_CFG_PRE_DIV(n) (((n) >> 1) - 1)
+#define PRCM_CPUS_CFG_PRE_DIV(n) \
+   __PRCM_CPUS_CFG_PRE(__PRCM_CPUS_CFG_CLK_PRE(n))
+#define __PRCM_CPUS_CFG_POST(n) (((n) & 0x1f) << 8)
+#define PRCM_CPUS_CFG_POST_MASK __PRCM_CPUS_CFG_POST(0x1f)
+#define __PRCM_CPUS_CFG_POST_DIV(n) ((n) - 1)
+#define PRCM_CPUS_CFG_POST_DIV(n) \
+   __PRCM_CPUS_CFG_POST_DIV(__PRCM_CPUS_CFG_POST_DIV(n))
+#define __PRCM_CPUS_CFG_CLK_SRC(n) (((n) & 0x3) << 16)
+#define PRCM_CPUS_CFG_CLK_SRC_MASK __PRCM_CPUS_CFG_CLK_SRC(0x3)
+#define __PRCM_CPUS_CFG_CLK_SRC_LOSC 0x0
+#define __PRCM_CPUS_CFG_CLK_SRC_HOSC 0x1
+#define __PRCM_CPUS_CFG_CLK_SRC_PLL6 0x2
+#define __PRCM_CPUS_CFG_CLK_SRC_PDIV 0x3
+#define PRCM_CPUS_CFG_CLK_SRC_LOSC \
+   __PRCM_CPUS_CFG_CLK_SRC(__PRCM_CPUS_CFG_CLK_SRC_LOSC)
+#define PRCM_CPUS_CFG_CLK_SRC_HOSC \
+   __PRCM_CPUS_CFG_CLK_SRC(__PRCM_CPUS_CFG_CLK_SRC_HOSC)
+#define PRCM_CPUS_CFG_CLK_SRC_PLL6 \
+   __PRCM_CPUS_CFG_CLK_SRC(__PRCM_CPUS_CFG_CLK_SRC_PLL6)
+#define PRCM_CPUS_CFG_CLK_SRC_PDIV \
+   __PRCM_CPUS_CFG_CLK_SRC(__PRCM_CPUS_CFG_CLK_SRC_PDIV)
+
+#define __PRCM_APB0_RATIO(n) (((n) & 0x3) << 0)
+#define PRCM_APB0_RATIO_DIV_MASK __PRCM_APB0_RATIO_DIV(0x3)
+#define __PRCM_APB0_RATIO_DIV(n) (((n) >> 1) - 1)
+#define PRCM_APB0_RATIO_DIV(n) \
+   __PRCM_APB0_RATIO(__PRCM_APB0_RATIO_DIV(n))
+
+#define PRCM_CPU_CFG_NEON_CLK_EN (0x1 << 0)
+#define PRCM_CPU_CFG_CPU_CLK_EN (0x1 << 1)
+
+#define PRCM_APB0_GATE_PIO (0x1 << 0)
+#define PRCM_APB0_GATE_IR (0x1 << 1)
+#define PRCM_APB0_GATE_TIMER01 (0x1 << 2)
+#define PRCM_APB0_GATE_P2WI (0x1 << 3)
+#define PRCM_APB0_GATE_UART (0x1 << 4)
+#define PRCM_APB0_GATE_1WIRE (0x1 << 5)
+#define PRCM_APB0_GATE_I2C (0x1 << 6)
+
+#define PRCM_APB0_RESET_PIO (0x1 << 0)
+#define PRCM_APB0_RESET_IR (0x1 << 1)
+#define PRCM_APB0_RESET_TIMER01 (0x1 << 2)
+#define PRCM_APB0_RESET_P2WI (0x1 << 3)
+#define PRCM_APB0_RESET_UART (0x1 << 4)
+#define PRCM_APB0_RESET_1WIRE (0x1 << 5)
+#define PRCM_APB0_RESET_I2C (0x1 << 6)
+
+#define PRCM

[U-Boot] [PATCH 5/7] ARM: sunxi-mmc: Add mmc support for sun6i / A31

[Chen-Yu Tsai]

From: Hans de Goede 

Signed-off-by: Hans de Goede 
[w...@csie.org: use setbits_le32 for reset control, drop obsolete changes,
squash "sunxi-mmc: sun6i has its fifo at a different address"]
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/include/asm/arch-sunxi/mmc.h | 2 --
 drivers/mmc/sunxi_mmc.c   | 9 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h 
b/arch/arm/include/asm/arch-sunxi/mmc.h
index 53196e3..bafde4b 100644
--- a/arch/arm/include/asm/arch-sunxi/mmc.h
+++ b/arch/arm/include/asm/arch-sunxi/mmc.h
@@ -42,8 +42,6 @@ struct sunxi_mmc {
u32 idie;   /* 0x8c internal DMA interrupt enable */
u32 chda;   /* 0x90 */
u32 cbda;   /* 0x94 */
-   u32 res1[26];
-   u32 fifo;   /* 0x100 FIFO access address */
 };
 
 #define SUNXI_MMC_CLK_POWERSAVE(0x1 << 17)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index d4e574f..b035bba 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -57,7 +57,11 @@ static int mmc_resource_init(int sdc_no)
printf("Wrong mmc number %d\n", sdc_no);
return -1;
}
+#ifdef CONFIG_SUN6I
+   mmchost->database = (unsigned int)mmchost->reg + 0x200;
+#else
mmchost->database = (unsigned int)mmchost->reg + 0x100;
+#endif
mmchost->mmc_no = sdc_no;
 
return 0;
@@ -75,6 +79,11 @@ static int mmc_clk_io_on(int sdc_no)
/* config ahb clock */
setbits_le32(&ccm->ahb_gate0, 1 << AHB_GATE_OFFSET_MMC(sdc_no));
 
+#if defined(CONFIG_SUN6I)
+   /* unassert reset */
+   setbits_le32(&ccm->ahb_reset0_cfg, 1 << AHB_RESET_OFFSET_MMC(sdc_no));
+#endif
+
/* config mod clock */
pll_clk = clock_get_pll6();
/* should be close to 100 MHz but no more, so round up */
-- 
2.1.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 4/7] ARM: sun6i: Add clock support

[Chen-Yu Tsai]

This patch adds the basic clocks support for the Allwinner A31 (sun6i)
processor. This code will not been compiled until the build is hooked
up in a later patch. It has been split out to keep the patches manageable.

This includes changes from the following commits from u-boot-sunxi:

a92051b ARM: sunxi: Add sun6i clock controller structure
1f72c6f ARM: sun6i: Setup the UART0 clocks
5f2e712 ARM: sunxi: Enable pll6 by default on all models
2be2f2a ARM: sunxi-mmc: Add mmc support for sun6i / A31
12e1633 ARM: sun6i: Add initial clock setup for SPL
1a9c9c6 ARM: sunxi: Split clock code into common, sun4i and sun6i code
0b194ee ARM: sun6i: Properly setup the PLL LDO in clock_init_safe
b54c626 sunxi: avoid sr32 for APB1 clock setup.
68fe29c sunxi: remove magic numbers from clock_get_pll{5,6}
c89867d sunxi: clocks: clock_get_pll5 prototype and coding style
501ab1e ARM: sunxi: Fix sun6i PLL6 settings
37f669b ARM: sunxi: Fix macro names for mmc and uart reset offsets
61de1e6 ARM: sunxi: Correct comment for MBUS1 register in sun6i clock 
definitions

Signed-off-by: Maxime Ripard 
Signed-off-by: Ian Campbell 
Signed-off-by: Hans de Goede 
[w...@csie.org: styling fixes reported by checkpatch.pl]
Signed-off-by: Chen-Yu Tsai 
Cc: Tom Cubie 
---
 arch/arm/cpu/armv7/sunxi/Makefile |   1 +
 arch/arm/cpu/armv7/sunxi/clock_sun6i.c| 107 ++
 arch/arm/include/asm/arch-sunxi/clock.h   |   4 +
 arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 205 ++
 4 files changed, 317 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/sunxi/clock_sun6i.c
 create mode 100644 arch/arm/include/asm/arch-sunxi/clock_sun6i.h

diff --git a/arch/arm/cpu/armv7/sunxi/Makefile 
b/arch/arm/cpu/armv7/sunxi/Makefile
index f0473d2..2a42dca 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -14,6 +14,7 @@ obj-y += pinmux.o
 obj-$(CONFIG_SUN6I)+= prcm.o
 obj-$(CONFIG_SUN4I)+= clock_sun4i.o
 obj-$(CONFIG_SUN5I)+= clock_sun4i.o
+obj-$(CONFIG_SUN6I)+= clock_sun6i.o
 obj-$(CONFIG_SUN7I)+= clock_sun4i.o
 
 ifndef CONFIG_SPL_BUILD
diff --git a/arch/arm/cpu/armv7/sunxi/clock_sun6i.c 
b/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
new file mode 100644
index 000..28fc54f
--- /dev/null
+++ b/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
@@ -0,0 +1,107 @@
+/*
+ * sun6i specific clock code
+ *
+ * (C) Copyright 2007-2012
+ * Allwinner Technology Co., Ltd. 
+ * Tom Cubie 
+ *
+ * (C) Copyright 2013 Luke Kenneth Casson Leighton 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_SPL_BUILD
+void clock_init_safe(void)
+{
+   struct sunxi_ccm_reg * const ccm =
+   (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+   struct sunxi_prcm_reg * const prcm =
+   (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
+
+   /* Set PLL ldo voltage without this PLL6 does not work properly */
+   writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN |
+   PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140) |
+   PRCM_PLL_CTRL_LDO_KEY, &prcm->pll_ctrl1);
+   writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN |
+   PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140) |
+   PRCM_PLL_CTRL_LDO_KEY, &prcm->pll_ctrl1);
+   writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN |
+   PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140),
+   &prcm->pll_ctrl1);
+
+   /* AXI and PLL1 settings from boot0 / boot1, PLL1 set to 486 Mhz */
+   writel(AXI_DIV_3 << AXI_DIV_SHIFT |
+  ATB_DIV_2 << ATB_DIV_SHIFT |
+  CPU_CLK_SRC_OSC24M << CPU_CLK_SRC_SHIFT,
+  &ccm->cpu_axi_cfg);
+   writel(PLL1_CFG_DEFAULT, &ccm->pll1_cfg);
+   sdelay(200);
+   writel(AXI_DIV_3 << AXI_DIV_SHIFT |
+  ATB_DIV_2 << ATB_DIV_SHIFT |
+  CPU_CLK_SRC_PLL1 << CPU_CLK_SRC_SHIFT,
+  &ccm->cpu_axi_cfg);
+
+   writel(PLL6_CFG_DEFAULT, &ccm->pll6_cfg);
+}
+#endif
+
+void clock_init_uart(void)
+{
+   struct sunxi_ccm_reg *const ccm =
+   (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+
+   /* uart clock source is apb2 */
+   writel(APB2_CLK_SRC_OSC24M|
+  APB2_CLK_RATE_N_1|
+  APB2_CLK_RATE_M(1),
+  &ccm->apb2_div);
+
+   /* open the clock for uart */
+   setbits_le32(&ccm->apb2_gate,
+CLK_GATE_OPEN << (APB2_GATE_UART_SHIFT +
+  CONFIG_CONS_INDEX - 1));
+
+   /* deassert uart reset */
+   setbits_le32(&ccm->apb2_reset_cfg,
+1 << (APB2_RESET_UART_SHIFT +
+  CONFIG_CONS_INDEX - 1));
+
+   /* Dup with clock_init_safe(), dro

Re: [U-Boot] [PATCH 1/7] ARM: sunxi: Fix build break when CONFIG_USB_EHCI is not defined

[Chen-Yu Tsai]

Hi Ian, Hans,

On Mon, Sep 8, 2014 at 9:28 PM, Chen-Yu Tsai  wrote:
> BOOT_TARGET_DEVICES includes USB unconditionally. This breaks when
> CONFIG_CMD_USB is not defined. Use a secondary macro to conditionally
> include it when CONFIG_EHCI is enabled, as we do for CONFIG_AHCI.

The other patches are for the next release, but maybe this fix could
go into 2014.10?

Thanks

ChenYu

>
> Signed-off-by: Chen-Yu Tsai 
> ---
>  include/configs/sunxi-common.h | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index 1d947d7..a31656e 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -233,10 +233,16 @@
>  #define BOOT_TARGET_DEVICES_SCSI(func)
>  #endif
>
> +#ifdef CONFIG_USB_EHCI
> +#define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0)
> +#else
> +#define BOOT_TARGET_DEVICES_USB(func)
> +#endif
> +
>  #define BOOT_TARGET_DEVICES(func) \
> func(MMC, mmc, 0) \
> BOOT_TARGET_DEVICES_SCSI(func) \
> -   func(USB, usb, 0) \
> +   BOOT_TARGET_DEVICES_USB(func) \
> func(PXE, pxe, na) \
> func(DHCP, dhcp, na)
>
> --
> 2.1.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/7] ARM: sunxi: Fix build break when CONFIG_USB_EHCI is not defined

[Chen-Yu Tsai]

On Fri, Sep 12, 2014 at 2:57 AM, Ian Campbell  wrote:
> On Thu, 2014-09-11 at 19:19 +0200, Hans de Goede wrote:
>> Hi Chen,
>>
>> On 09/11/2014 07:07 PM, Chen-Yu Tsai wrote:
>> > Hi Ian, Hans,
>> >
>> > On Mon, Sep 8, 2014 at 9:28 PM, Chen-Yu Tsai  wrote:
>> >> BOOT_TARGET_DEVICES includes USB unconditionally. This breaks when
>> >> CONFIG_CMD_USB is not defined. Use a secondary macro to conditionally
>> >> include it when CONFIG_EHCI is enabled, as we do for CONFIG_AHCI.
>> >
>> > The other patches are for the next release, but maybe this fix could
>> > go into 2014.10?
>>
>> I agree that this is a benign bug fix, but since we don't have any
>> boards not setting CONFIG_EHCI atm I don't really see the value
>> for getting it into 2014.10.
>
> FWIW I was planning on putting the whole series in #next until the next
> merge window as soon as I find a some spare moments to look through it
> (sorry, might take me a few more days, I'm travelling at the w/e).

OK. Thanks for the heads up.


ChenYu
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] Re: [PATCH 0/7] ARM: sunxi: Add basic support for Allwinner A31 (sun6i)

[Chen-Yu Tsai]

Hi,

On Thu, Sep 18, 2014 at 4:31 PM, Hans de Goede  wrote:
> Hi,
>
> On 09/18/2014 06:27 AM, Siarhei Siamashka wrote:
>> On Tue, 09 Sep 2014 09:00:57 +0200
>> Hans de Goede  wrote:
>>
>>> Hi,
>>>
>>> On 09/08/2014 03:28 PM, Chen-Yu Tsai wrote:
>>>> Hi everyone,
>>>>
>>>> This series add basic support for Allwinner's A31 SoC. The patches,
>>>> excluding the first one, were cherry-picked from u-boot-sunxi. Due to
>>>> the difference between u-boot mainline and u-boot-sunxi, some patches
>>>> were rearranged or squashed to better fit the current state of u-boot,
>>>> and not introduce any build breaks. It follows Ian's initial merge
>>>> method of sun7i support: introducing various components first, then
>>>> enabling them in the last commit. I tried to keep the commits separate,
>>>> thus retaining the original author and Signed-off-bys.
>>>>
>>>> Patch 1 adds a wrapper around "func(USB, usb, 0)" in BOOT_TARGET_DEVICES
>>>> to deal with breakage when USB support is not enabled.
>>>>
>>>> Patch 2 adds memory addresses for some hardware blocks new in sun6i.
>>>>
>>>> Patch 3 adds support for the new PRCM (power reset and clock management)
>>>> block, which also contains PLL bias voltage control.
>>>>
>>>> Patch 4 adds support for the clock module. This patch is a bunch of
>>>> different sun6i related patches on the clock code, from when sun6i
>>>> support was introduced to u-boot-sunxi, up to its current form.
>>>> This is done to avoid various conflicts and needlessly introducing
>>>> then removing macros.
>>>>
>>>> Patch 5 adds mmc support on sun6i.
>>>>
>>>> Patch 6 adds uart0 muxing on sun6i.
>>>>
>>>> Patch 7 enables sun6i support and adds defconfig for the Colombus board.
>>>
>>> Chen,
>>>
>>> Many thanks for working on this!
>>>
>>> Just a quick not for people celebrating too early, this is the *incomplete*
>>> sun7i support from the linux-sunxi/u-boot-sunxi git repo. It is fine to
>>> merge this upstream, but this does not include SPL support.
>>>
>>> This allows replacing u-boot.bin on allwinnner sd-card images, which is
>>> very useful. But it does not get us all the way to booting sun7i devices
>>> we still need boot0 and boot1 binaries from allwinner for that (for now).
>>
>> If I understand it correctly, one of the things that needs to be done
>> in SPL is the initialization of the DRAM controller. A few weeks ago
>> Oliver has updated the http://linux-sunxi.org/DRAM_Controller page
>> and added a link to the 'dram_sun6i.c' file from the rhombus-tech.net
>> u-boot repository:
>> 
>> http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/sunxi/dram_sun6i.c;hb=refs/heads/allwinner-sunxi-a31
>> Does this repository look like exactly the missing part of code?
>
> Yes it does, interesting. I had found that file before, but this one
> was missing in the repo I found then:
>
> http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-sunxi/dram.h;hb=refs/heads/allwinner-sunxi-a31
>
> But with that one added, this is definitely interesting.

The A31 Hummingbird's SDK has provided us with full boot0/boot1,
which also includes the dram code:

http://dl.linux-sunxi.org/SDK/A31/unpacked-stripped/a31_v4.5_hummingbird_kfb_ok/lichee/boot-v1.0/boot/source/init_dram/

It is more complex than what we found in u-boot.
This code also shows what is encoded into the dram parameters
found in the fex files.

>> Assuming that this code works, it provides a usable starting point
>> for us.
>
> Yep, assuming :) If no one beats me to it I'll take a look at this as
> time permits.
>
>> It looks like the Allwinner A31 DRAM controller registers are very
>> similar to what is used in RK3288 (I have not checked the details,
>> but if we are very lucky, it might be even a 100% perfect match):
>> https://chromium-review.googlesource.com/#/c/209419/
>> And thanks to the Rockchip developers (who are contributing this
>> DRAM controller support code to coreboot), now we have a lot of
>> named defines for the individual bitfields in the hardware
>> registers. So we can decode the magic constants used in the
>> Allwinner code. And thanks to Texas Instruments, we also have
>> some useful documentation, which also happens to be a reasonably
>> good match:
>> http://ww

Re: [U-Boot] [PATCH 3/7] ARM: sun6i: Add support for the new power control module found on the A31

[Chen-Yu Tsai]

Hi,

On Mon, Sep 22, 2014 at 1:05 AM, Ian Campbell  wrote:
> On Mon, 2014-09-08 at 21:28 +0800, Chen-Yu Tsai wrote:
>> From: Oliver Schinagl 
>>
>> To setup clocks and control voltages.
>
> perhaps add "... For P2WI and PIO", since that is apparently what it is
> doing?

Sounds good. I'll expand the message to mention what the PRCM
controls, and what we actually use.

>> HdG: Rename the files from the somewhat generic pmu name to prcm.{c,h}
>> HdG: Make the prcm code only deal with the prcm, remove axp221 bits
>
> I suppose these comments aren't really meaningful in the final commit
> message, probably better to drop them.

I was trying to keep the history of the patches intact.
If Hans agress, I can drop them.

>> + * Based on sun6i sources and earlier U-Boot Allwiner A10 SPL work
>
> Typo in "Allwiner"
>
>> + reg_val = readl(&prcm->apb0_gate);
>> + reg_val |= PRCM_APB0_GATE_P2WI | PRCM_APB0_GATE_PIO;
>> + writel(reg_val, &prcm->apb0_gate);
>> +
>> + reg_val = readl(&prcm->apb0_reset);
>> + reg_val |= PRCM_APB0_RESET_P2WI | PRCM_APB0_RESET_PIO;
>> + writel(reg_val, &prcm->apb0_reset);
>
> I think these should both use the setbits helper.

Right. Will change them.

Thanks!

ChenYu
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot