Pull request: u-boot-sunxi/master for 2021.10 - 2nd part

Pull request: u-boot-sunxi/master for 2021.10 - 2nd part

[Andre Przywara]

Hi Tom,

please pull the second sunxi PR for the 2021.10 merge window.
I decided to merge most of Samuel's rework and some smaller patches that
pave the way for more DM transitions and for accommodating the RISC-V SoC
in the future. Merging them now gives us the opportunity to get some wider
testing, since those subtle changes tend to break things.

Compile-tested for all 159 sunxi boards, boot-tested on Pine64-LTS
and OrangePi Zero.

Summary:
- Add and enable watchdog driver
- Prepare for SYSRESET driven AXP poweroff
- Prepare for SoCs without MMC2
- Some fixes for extending SPL (SPL-DM for RISC-V)
- Some preparations for proper VBUS management
- Fix secure monitor move

Thanks,
Andre

================================================
The following changes since commit 355d1e24f6143c4839be3c015c191421c4e9449c:

  Merge https://source.denx.de/u-boot/custodians/u-boot-spi (2021-10-23 10:49:28 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master

for you to fetch changes up to c846fe43f0561311eb7261b34023a04646cdbd0d:

  mmc: sunxi: conditionally include MMC2 initialization code (2021-10-25 14:54:57 +0100)

----------------------------------------------------------------
Andre Przywara (1):
      sunxi: SPL SPI: Allow larger SPL

Icenowy Zheng (2):
      sunxi: only include alias for eMMC when mmc2 used
      mmc: sunxi: conditionally include MMC2 initialization code

Samuel Holland (14):
      sunxi: Select SPL_SEPARATE_BSS
      phy: sun4i-usb: Remove a couple of debug messages
      phy: sun4i-usb: Refactor VBUS detection to match Linux
      phy: sun4i-usb: Support VBUS detection via power supply
      sunxi: A23/A33/H3: Actually move the secure monitor
      tools: mksunxiboot: Use sunxi_image header directly
      include: axp_pmic: Add missing header guard definition
      include: axp_pmic: Include headers for all variants
      power: axp: Avoid do_poweroff conflict with sysreset
      power: pmic: axp: Implement poweroff via sysreset
      clk: sunxi: Extend DM_RESET selection to SPL
      watchdog: Add a driver for the sunxi watchdog
      sunxi: Enable watchdog timer support by default
      sunxi: dts: H616: Enable the watchdog

 arch/arm/Kconfig                      |   2 +
 arch/arm/dts/sun50i-h616.dtsi         |   1 -
 arch/arm/dts/sunxi-u-boot.dtsi        |   2 +
 arch/arm/mach-sunxi/spl_spi_sunxi.c   |  10 +-
 drivers/clk/sunxi/Kconfig             |   1 +
 drivers/mmc/sunxi_mmc.c               |   2 +
 drivers/phy/allwinner/Kconfig         |   1 +
 drivers/phy/allwinner/phy-sun4i-usb.c |  34 +++---
 drivers/power/axp152.c                |   2 +
 drivers/power/axp209.c                |   2 +
 drivers/power/axp221.c                |   2 +
 drivers/power/axp305.c                |   2 +-
 drivers/power/axp809.c                |   2 +
 drivers/power/axp818.c                |   2 +
 drivers/power/pmic/Kconfig            |   2 +
 drivers/power/pmic/axp.c              |  49 ++++++++-
 drivers/watchdog/Kconfig              |   8 ++
 drivers/watchdog/Makefile             |   1 +
 drivers/watchdog/sunxi_wdt.c          | 188 ++++++++++++++++++++++++++++++++++
 include/axp152.h                      |   2 +
 include/axp209.h                      |   2 +
 include/axp221.h                      |   2 +
 include/axp809.h                      |   2 +
 include/axp818.h                      |   2 +
 include/axp_pmic.h                    |  13 +--
 include/configs/sun8i.h               |   2 +
 tools/mksunxiboot.c                   |   2 +-
 27 files changed, 305 insertions(+), 35 deletions(-)
 create mode 100644 drivers/watchdog/sunxi_wdt.c

Re: Pull request: u-boot-sunxi/master for 2021.10 - 2nd part

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]

On Mon, Oct 25, 2021 at 03:06:58PM +0100, Andre Przywara wrote:

> Hi Tom,
> 
> please pull the second sunxi PR for the 2021.10 merge window.
> I decided to merge most of Samuel's rework and some smaller patches that
> pave the way for more DM transitions and for accommodating the RISC-V SoC
> in the future. Merging them now gives us the opportunity to get some wider
> testing, since those subtle changes tend to break things.
> 
> Compile-tested for all 159 sunxi boards, boot-tested on Pine64-LTS
> and OrangePi Zero.
> 
> Summary:
> - Add and enable watchdog driver
> - Prepare for SYSRESET driven AXP poweroff
> - Prepare for SoCs without MMC2
> - Some fixes for extending SPL (SPL-DM for RISC-V)
> - Some preparations for proper VBUS management
> - Fix secure monitor move
> 
> Thanks,
> Andre
> 
> ================================================
> The following changes since commit 355d1e24f6143c4839be3c015c191421c4e9449c:
> 
>   Merge https://source.denx.de/u-boot/custodians/u-boot-spi (2021-10-23 10:49:28 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master
> 
> for you to fetch changes up to c846fe43f0561311eb7261b34023a04646cdbd0d:
> 
>   mmc: sunxi: conditionally include MMC2 initialization code (2021-10-25 14:54:57 +0100)
> 

So first, up, this is now applied to u-boot/master.

Next, I dug out my original Kickstarted Pine A64 board (as it's the only
sunxi platform I have), and I see it's detected with 1GB memory and as
Pine64+ which seems wrong, with the pine64_plus_defconfig (which is what
I thought handled all of the A64 platforms).  I've not booted this up in
forever, and Armbian (the first binary I grabbed) does this as well with
v2020.10 (and I'm using the same TF-A rev of 87311b4) so maybe the
answer is I should just e-waste this board and pick up something else?
Thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Pull request: u-boot-sunxi/master for 2021.10 - 2nd part

[Andre Przywara]

On Mon, 25 Oct 2021 14:29:10 -0400
Tom Rini <trini@konsulko.com> wrote:

Hi Tom,

> On Mon, Oct 25, 2021 at 03:06:58PM +0100, Andre Przywara wrote:
> 
> > Hi Tom,
> > 
> > please pull the second sunxi PR for the 2021.10 merge window.
> > I decided to merge most of Samuel's rework and some smaller patches that
> > pave the way for more DM transitions and for accommodating the RISC-V SoC
> > in the future. Merging them now gives us the opportunity to get some wider
> > testing, since those subtle changes tend to break things.
> > 
> > Compile-tested for all 159 sunxi boards, boot-tested on Pine64-LTS
> > and OrangePi Zero.
> > 
> > Summary:
> > - Add and enable watchdog driver
> > - Prepare for SYSRESET driven AXP poweroff
> > - Prepare for SoCs without MMC2
> > - Some fixes for extending SPL (SPL-DM for RISC-V)
> > - Some preparations for proper VBUS management
> > - Fix secure monitor move
> > 
> > Thanks,
> > Andre
> > 
> > ================================================
> > The following changes since commit 355d1e24f6143c4839be3c015c191421c4e9449c:
> > 
> >   Merge https://source.denx.de/u-boot/custodians/u-boot-spi (2021-10-23 10:49:28 -0400)
> > 
> > are available in the Git repository at:
> > 
> >   https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master
> > 
> > for you to fetch changes up to c846fe43f0561311eb7261b34023a04646cdbd0d:
> > 
> >   mmc: sunxi: conditionally include MMC2 initialization code (2021-10-25 14:54:57 +0100)
> >   
> 
> So first, up, this is now applied to u-boot/master.

Many thanks, and sorry for the late push!

> Next, I dug out my original Kickstarted Pine A64 board (as it's the only
> sunxi platform I have), and I see it's detected with 1GB memory and as
> Pine64+ which seems wrong, with the pine64_plus_defconfig (which is what
> I thought handled all of the A64 platforms).

For the naming: There are three SKUs for the original Pine A64 board:
- Pine A64: 512 MB with 100Mbit Ethernet PHY, lacking display and camera
  connectors (rare, mostly to meet the original 15 USD price tag)
- Pine A64+ 1GB: 1GB DRAM with 1Gbit Ethernet PHY, with all connectors
- Pine A64+ 2GB: 2GB DRAM with 1Gbit Ethernet PHY, with all connectors

Also note that for those first boards from Pine64 the name of the
company (Pine64) is sometimes uses for the boards as well ("Pine64
board"), even though this should be "Pine A64 board from Pine64". That
is somewhat reflected in the defconfig name. In hindsight the defconfig
should have been named more "pine-a64_defconfig", but I guess this is
too late now? I see a lot of inconsistencies in naming, especially
regarding capitalisation and dashes vs. underscores, check
configs/[bB]anana* for instance, but probably renaming causes more harm
than good?

So I guess you have the middle one (the most common among the first
wave), so that all seems correct? We differentiate between the non-plus
and plus version at runtime, by the amount of DRAM detected, so that's
pretty reliable. The 1GB and 2GB are otherwise the same, so same DT.
The actual non-plus versions are somewhat rare, I guess most people
just added the 4(!) bucks to get more RAM and Gigabit Ethernet.

> I've not booted this up in
> forever, and Armbian (the first binary I grabbed) does this as well with
> v2020.10 (and I'm using the same TF-A rev of 87311b4) so maybe the
> answer is I should just e-waste this board and pick up something else?

Not sure exactly why? Is there anything that's broken, apart from the
presumed misnaming? I would be happy to hear about any issues you have,
in my experience those "outsider" inputs are very useful (I am far too
familiar with all those tiny quirks).
When U-Boot starts, UEFI boot should work out of the box, just pop a
generic arm64 Debian/SuSE/Fedora/Ubuntu EFI installer USB stick in,
should work even with HDMI and USB keyboard.

Cheers,
Andre

Re: Pull request: u-boot-sunxi/master for 2021.10 - 2nd part

[Icenowy Zheng]

在 2021-10-29星期五的 11:53 +0100，Andre Przywara写道：
> On Mon, 25 Oct 2021 14:29:10 -0400
> Tom Rini <trini@konsulko.com> wrote:
> 
> Hi Tom,
> 
> > On Mon, Oct 25, 2021 at 03:06:58PM +0100, Andre Przywara wrote:
> > 
> > > Hi Tom,
> > > 
> > > please pull the second sunxi PR for the 2021.10 merge window.
> > > I decided to merge most of Samuel's rework and some smaller
> > > patches that
> > > pave the way for more DM transitions and for accommodating the
> > > RISC-V SoC
> > > in the future. Merging them now gives us the opportunity to get
> > > some wider
> > > testing, since those subtle changes tend to break things.
> > > 
> > > Compile-tested for all 159 sunxi boards, boot-tested on Pine64-
> > > LTS
> > > and OrangePi Zero.
> > > 
> > > Summary:
> > > - Add and enable watchdog driver
> > > - Prepare for SYSRESET driven AXP poweroff
> > > - Prepare for SoCs without MMC2
> > > - Some fixes for extending SPL (SPL-DM for RISC-V)
> > > - Some preparations for proper VBUS management
> > > - Fix secure monitor move
> > > 
> > > Thanks,
> > > Andre
> > > 
> > > ================================================
> > > The following changes since commit
> > > 355d1e24f6143c4839be3c015c191421c4e9449c:
> > > 
> > >   Merge
> > > https://source.denx.de/u-boot/custodians/u-boot-spi (2021-10-23
> > > 10:49:28 -0400)
> > > 
> > > are available in the Git repository at:
> > > 
> > >  
> > > https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master
> > > 
> > > for you to fetch changes up to
> > > c846fe43f0561311eb7261b34023a04646cdbd0d:
> > > 
> > >   mmc: sunxi: conditionally include MMC2 initialization code
> > > (2021-10-25 14:54:57 +0100)
> > >   
> > 
> > So first, up, this is now applied to u-boot/master.
> 
> Many thanks, and sorry for the late push!
> 
> > Next, I dug out my original Kickstarted Pine A64 board (as it's the
> > only
> > sunxi platform I have), and I see it's detected with 1GB memory and
> > as
> > Pine64+ which seems wrong, with the pine64_plus_defconfig (which is
> > what
> > I thought handled all of the A64 platforms).
> 
> For the naming: There are three SKUs for the original Pine A64 board:
> - Pine A64: 512 MB with 100Mbit Ethernet PHY, lacking display and
> camera
>   connectors (rare, mostly to meet the original 15 USD price tag)
> - Pine A64+ 1GB: 1GB DRAM with 1Gbit Ethernet PHY, with all
> connectors
> - Pine A64+ 2GB: 2GB DRAM with 1Gbit Ethernet PHY, with all
> connectors

You can check whether your board is non-Plus or Plus 1G by the model of
the Ethernet PHY (non-Plus has RTL8201) or not soldered FPC connectors.
They do share a PCB design. Plus 2G is a dedicated PCB design as it
needs to use 4x 512MB DRAM chips.

> 
> Also note that for those first boards from Pine64 the name of the
> company (Pine64) is sometimes uses for the boards as well ("Pine64
> board"), even though this should be "Pine A64 board from Pine64".
> That
> is somewhat reflected in the defconfig name. In hindsight the
> defconfig
> should have been named more "pine-a64_defconfig", but I guess this is
> too late now? I see a lot of inconsistencies in naming, especially
> regarding capitalisation and dashes vs. underscores, check
> configs/[bB]anana* for instance, but probably renaming causes more
> harm
> than good?
> 
> So I guess you have the middle one (the most common among the first
> wave), so that all seems correct? We differentiate between the non-
> plus
> and plus version at runtime, by the amount of DRAM detected, so
> that's
> pretty reliable. The 1GB and 2GB are otherwise the same, so same DT.
> The actual non-plus versions are somewhat rare, I guess most people
> just added the 4(!) bucks to get more RAM and Gigabit Ethernet.
> 
> > I've not booted this up in
> > forever, and Armbian (the first binary I grabbed) does this as well
> > with
> > v2020.10 (and I'm using the same TF-A rev of 87311b4) so maybe the
> > answer is I should just e-waste this board and pick up something
> > else?
> 
> Not sure exactly why? Is there anything that's broken, apart from the
> presumed misnaming? I would be happy to hear about any issues you
> have,
> in my experience those "outsider" inputs are very useful (I am far
> too
> familiar with all those tiny quirks).
> When U-Boot starts, UEFI boot should work out of the box, just pop a
> generic arm64 Debian/SuSE/Fedora/Ubuntu EFI installer USB stick in,
> should work even with HDMI and USB keyboard.
> 
> Cheers,
> Andre

Re: Pull request: u-boot-sunxi/master for 2021.10 - 2nd part

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 5438 bytes --]

On Fri, Oct 29, 2021 at 10:20:32PM +0800, Icenowy Zheng wrote:
> 在 2021-10-29星期五的 11:53 +0100，Andre Przywara写道：
> > On Mon, 25 Oct 2021 14:29:10 -0400
> > Tom Rini <trini@konsulko.com> wrote:
> > 
> > Hi Tom,
> > 
> > > On Mon, Oct 25, 2021 at 03:06:58PM +0100, Andre Przywara wrote:
> > > 
> > > > Hi Tom,
> > > > 
> > > > please pull the second sunxi PR for the 2021.10 merge window.
> > > > I decided to merge most of Samuel's rework and some smaller
> > > > patches that
> > > > pave the way for more DM transitions and for accommodating the
> > > > RISC-V SoC
> > > > in the future. Merging them now gives us the opportunity to get
> > > > some wider
> > > > testing, since those subtle changes tend to break things.
> > > > 
> > > > Compile-tested for all 159 sunxi boards, boot-tested on Pine64-
> > > > LTS
> > > > and OrangePi Zero.
> > > > 
> > > > Summary:
> > > > - Add and enable watchdog driver
> > > > - Prepare for SYSRESET driven AXP poweroff
> > > > - Prepare for SoCs without MMC2
> > > > - Some fixes for extending SPL (SPL-DM for RISC-V)
> > > > - Some preparations for proper VBUS management
> > > > - Fix secure monitor move
> > > > 
> > > > Thanks,
> > > > Andre
> > > > 
> > > > ================================================
> > > > The following changes since commit
> > > > 355d1e24f6143c4839be3c015c191421c4e9449c:
> > > > 
> > > >   Merge
> > > > https://source.denx.de/u-boot/custodians/u-boot-spi (2021-10-23
> > > > 10:49:28 -0400)
> > > > 
> > > > are available in the Git repository at:
> > > > 
> > > >  
> > > > https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master
> > > > 
> > > > for you to fetch changes up to
> > > > c846fe43f0561311eb7261b34023a04646cdbd0d:
> > > > 
> > > >   mmc: sunxi: conditionally include MMC2 initialization code
> > > > (2021-10-25 14:54:57 +0100)
> > > >   
> > > 
> > > So first, up, this is now applied to u-boot/master.
> > 
> > Many thanks, and sorry for the late push!
> > 
> > > Next, I dug out my original Kickstarted Pine A64 board (as it's the
> > > only
> > > sunxi platform I have), and I see it's detected with 1GB memory and
> > > as
> > > Pine64+ which seems wrong, with the pine64_plus_defconfig (which is
> > > what
> > > I thought handled all of the A64 platforms).
> > 
> > For the naming: There are three SKUs for the original Pine A64 board:
> > - Pine A64: 512 MB with 100Mbit Ethernet PHY, lacking display and
> > camera
> >   connectors (rare, mostly to meet the original 15 USD price tag)
> > - Pine A64+ 1GB: 1GB DRAM with 1Gbit Ethernet PHY, with all
> > connectors
> > - Pine A64+ 2GB: 2GB DRAM with 1Gbit Ethernet PHY, with all
> > connectors
> 
> You can check whether your board is non-Plus or Plus 1G by the model of
> the Ethernet PHY (non-Plus has RTL8201) or not soldered FPC connectors.
> They do share a PCB design. Plus 2G is a dedicated PCB design as it
> needs to use 4x 512MB DRAM chips.

OK, mine has an RTL8211E and is 1G for sure now that I look harder at
it.

On a related note, this board will draw power via the UART, is there any
easy HW change I can do, to fix that?  It's otherwise a lot harder to
put this in to my CI lab.

> > Also note that for those first boards from Pine64 the name of the
> > company (Pine64) is sometimes uses for the boards as well ("Pine64
> > board"), even though this should be "Pine A64 board from Pine64".
> > That
> > is somewhat reflected in the defconfig name. In hindsight the
> > defconfig
> > should have been named more "pine-a64_defconfig", but I guess this is
> > too late now? I see a lot of inconsistencies in naming, especially
> > regarding capitalisation and dashes vs. underscores, check
> > configs/[bB]anana* for instance, but probably renaming causes more
> > harm
> > than good?
> > 
> > So I guess you have the middle one (the most common among the first
> > wave), so that all seems correct? We differentiate between the non-
> > plus
> > and plus version at runtime, by the amount of DRAM detected, so
> > that's
> > pretty reliable. The 1GB and 2GB are otherwise the same, so same DT.
> > The actual non-plus versions are somewhat rare, I guess most people
> > just added the 4(!) bucks to get more RAM and Gigabit Ethernet.
> > 
> > > I've not booted this up in
> > > forever, and Armbian (the first binary I grabbed) does this as well
> > > with
> > > v2020.10 (and I'm using the same TF-A rev of 87311b4) so maybe the
> > > answer is I should just e-waste this board and pick up something
> > > else?
> > 
> > Not sure exactly why? Is there anything that's broken, apart from the
> > presumed misnaming? I would be happy to hear about any issues you
> > have,
> > in my experience those "outsider" inputs are very useful (I am far
> > too
> > familiar with all those tiny quirks).
> > When U-Boot starts, UEFI boot should work out of the box, just pop a
> > generic arm64 Debian/SuSE/Fedora/Ubuntu EFI installer USB stick in,
> > should work even with HDMI and USB keyboard.

Ah, so Armbian is a fails to boot (I can't even interrupt autoboot).
Given that I was previously sure I had the 512MB model (but, I was
wrong) I thought maybe this is just garbage now.  But! Now that I'm
pretty sure this is being seen right, I'm going to grab a different
distribution and see what happens.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Pull request: u-boot-sunxi/master for 2021.10 - 2nd part

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 6190 bytes --]

On Fri, Oct 29, 2021 at 10:41:01AM -0400, Tom Rini wrote:
> On Fri, Oct 29, 2021 at 10:20:32PM +0800, Icenowy Zheng wrote:
> > 在 2021-10-29星期五的 11:53 +0100，Andre Przywara写道：
> > > On Mon, 25 Oct 2021 14:29:10 -0400
> > > Tom Rini <trini@konsulko.com> wrote:
> > > 
> > > Hi Tom,
> > > 
> > > > On Mon, Oct 25, 2021 at 03:06:58PM +0100, Andre Przywara wrote:
> > > > 
> > > > > Hi Tom,
> > > > > 
> > > > > please pull the second sunxi PR for the 2021.10 merge window.
> > > > > I decided to merge most of Samuel's rework and some smaller
> > > > > patches that
> > > > > pave the way for more DM transitions and for accommodating the
> > > > > RISC-V SoC
> > > > > in the future. Merging them now gives us the opportunity to get
> > > > > some wider
> > > > > testing, since those subtle changes tend to break things.
> > > > > 
> > > > > Compile-tested for all 159 sunxi boards, boot-tested on Pine64-
> > > > > LTS
> > > > > and OrangePi Zero.
> > > > > 
> > > > > Summary:
> > > > > - Add and enable watchdog driver
> > > > > - Prepare for SYSRESET driven AXP poweroff
> > > > > - Prepare for SoCs without MMC2
> > > > > - Some fixes for extending SPL (SPL-DM for RISC-V)
> > > > > - Some preparations for proper VBUS management
> > > > > - Fix secure monitor move
> > > > > 
> > > > > Thanks,
> > > > > Andre
> > > > > 
> > > > > ================================================
> > > > > The following changes since commit
> > > > > 355d1e24f6143c4839be3c015c191421c4e9449c:
> > > > > 
> > > > >   Merge
> > > > > https://source.denx.de/u-boot/custodians/u-boot-spi (2021-10-23
> > > > > 10:49:28 -0400)
> > > > > 
> > > > > are available in the Git repository at:
> > > > > 
> > > > >  
> > > > > https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master
> > > > > 
> > > > > for you to fetch changes up to
> > > > > c846fe43f0561311eb7261b34023a04646cdbd0d:
> > > > > 
> > > > >   mmc: sunxi: conditionally include MMC2 initialization code
> > > > > (2021-10-25 14:54:57 +0100)
> > > > >   
> > > > 
> > > > So first, up, this is now applied to u-boot/master.
> > > 
> > > Many thanks, and sorry for the late push!
> > > 
> > > > Next, I dug out my original Kickstarted Pine A64 board (as it's the
> > > > only
> > > > sunxi platform I have), and I see it's detected with 1GB memory and
> > > > as
> > > > Pine64+ which seems wrong, with the pine64_plus_defconfig (which is
> > > > what
> > > > I thought handled all of the A64 platforms).
> > > 
> > > For the naming: There are three SKUs for the original Pine A64 board:
> > > - Pine A64: 512 MB with 100Mbit Ethernet PHY, lacking display and
> > > camera
> > >   connectors (rare, mostly to meet the original 15 USD price tag)
> > > - Pine A64+ 1GB: 1GB DRAM with 1Gbit Ethernet PHY, with all
> > > connectors
> > > - Pine A64+ 2GB: 2GB DRAM with 1Gbit Ethernet PHY, with all
> > > connectors
> > 
> > You can check whether your board is non-Plus or Plus 1G by the model of
> > the Ethernet PHY (non-Plus has RTL8201) or not soldered FPC connectors.
> > They do share a PCB design. Plus 2G is a dedicated PCB design as it
> > needs to use 4x 512MB DRAM chips.
> 
> OK, mine has an RTL8211E and is 1G for sure now that I look harder at
> it.
> 
> On a related note, this board will draw power via the UART, is there any
> easy HW change I can do, to fix that?  It's otherwise a lot harder to
> put this in to my CI lab.
> 
> > > Also note that for those first boards from Pine64 the name of the
> > > company (Pine64) is sometimes uses for the boards as well ("Pine64
> > > board"), even though this should be "Pine A64 board from Pine64".
> > > That
> > > is somewhat reflected in the defconfig name. In hindsight the
> > > defconfig
> > > should have been named more "pine-a64_defconfig", but I guess this is
> > > too late now? I see a lot of inconsistencies in naming, especially
> > > regarding capitalisation and dashes vs. underscores, check
> > > configs/[bB]anana* for instance, but probably renaming causes more
> > > harm
> > > than good?
> > > 
> > > So I guess you have the middle one (the most common among the first
> > > wave), so that all seems correct? We differentiate between the non-
> > > plus
> > > and plus version at runtime, by the amount of DRAM detected, so
> > > that's
> > > pretty reliable. The 1GB and 2GB are otherwise the same, so same DT.
> > > The actual non-plus versions are somewhat rare, I guess most people
> > > just added the 4(!) bucks to get more RAM and Gigabit Ethernet.
> > > 
> > > > I've not booted this up in
> > > > forever, and Armbian (the first binary I grabbed) does this as well
> > > > with
> > > > v2020.10 (and I'm using the same TF-A rev of 87311b4) so maybe the
> > > > answer is I should just e-waste this board and pick up something
> > > > else?
> > > 
> > > Not sure exactly why? Is there anything that's broken, apart from the
> > > presumed misnaming? I would be happy to hear about any issues you
> > > have,
> > > in my experience those "outsider" inputs are very useful (I am far
> > > too
> > > familiar with all those tiny quirks).
> > > When U-Boot starts, UEFI boot should work out of the box, just pop a
> > > generic arm64 Debian/SuSE/Fedora/Ubuntu EFI installer USB stick in,
> > > should work even with HDMI and USB keyboard.
> 
> Ah, so Armbian is a fails to boot (I can't even interrupt autoboot).
> Given that I was previously sure I had the 512MB model (but, I was
> wrong) I thought maybe this is just garbage now.  But! Now that I'm
> pretty sure this is being seen right, I'm going to grab a different
> distribution and see what happens.

For the record, the problem with Armbian is the ancient and slow SD card
I used.  Walking away for a minute or two and oh, hey, automatic login,
after letting distro_boot just run.  So, this board is in fact actually
fine, aside from the power leakage thing.  And that's not 100% reliable,
so I might just see if I can live with it, in my lab, to start with if
there's not an obvious HW mod to the board or UART adapter.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Pull request: u-boot-sunxi/master for 2021.10 - 2nd part

[Icenowy Zheng]

在 2021-10-29星期五的 10:41 -0400，Tom Rini写道：
> On Fri, Oct 29, 2021 at 10:20:32PM +0800, Icenowy Zheng wrote:
> > 在 2021-10-29星期五的 11:53 +0100，Andre Przywara写道：
> > > On Mon, 25 Oct 2021 14:29:10 -0400
> > > Tom Rini <trini@konsulko.com> wrote:
> > > 
> > > Hi Tom,
> > > 
> > > > On Mon, Oct 25, 2021 at 03:06:58PM +0100, Andre Przywara wrote:
> > > > 
> > > > > Hi Tom,
> > > > > 
> > > > > please pull the second sunxi PR for the 2021.10 merge window.
> > > > > I decided to merge most of Samuel's rework and some smaller
> > > > > patches that
> > > > > pave the way for more DM transitions and for accommodating
> > > > > the
> > > > > RISC-V SoC
> > > > > in the future. Merging them now gives us the opportunity to
> > > > > get
> > > > > some wider
> > > > > testing, since those subtle changes tend to break things.
> > > > > 
> > > > > Compile-tested for all 159 sunxi boards, boot-tested on
> > > > > Pine64-
> > > > > LTS
> > > > > and OrangePi Zero.
> > > > > 
> > > > > Summary:
> > > > > - Add and enable watchdog driver
> > > > > - Prepare for SYSRESET driven AXP poweroff
> > > > > - Prepare for SoCs without MMC2
> > > > > - Some fixes for extending SPL (SPL-DM for RISC-V)
> > > > > - Some preparations for proper VBUS management
> > > > > - Fix secure monitor move
> > > > > 
> > > > > Thanks,
> > > > > Andre
> > > > > 
> > > > > ================================================
> > > > > The following changes since commit
> > > > > 355d1e24f6143c4839be3c015c191421c4e9449c:
> > > > > 
> > > > >   Merge
> > > > > https://source.denx.de/u-boot/custodians/u-boot-spi (2021-10-
> > > > > 23
> > > > > 10:49:28 -0400)
> > > > > 
> > > > > are available in the Git repository at:
> > > > > 
> > > > >  
> > > > > https://source.denx.de/u-boot/custodians/u-boot-sunxi.git mas
> > > > > ter
> > > > > 
> > > > > for you to fetch changes up to
> > > > > c846fe43f0561311eb7261b34023a04646cdbd0d:
> > > > > 
> > > > >   mmc: sunxi: conditionally include MMC2 initialization code
> > > > > (2021-10-25 14:54:57 +0100)
> > > > >   
> > > > 
> > > > So first, up, this is now applied to u-boot/master.
> > > 
> > > Many thanks, and sorry for the late push!
> > > 
> > > > Next, I dug out my original Kickstarted Pine A64 board (as it's
> > > > the
> > > > only
> > > > sunxi platform I have), and I see it's detected with 1GB memory
> > > > and
> > > > as
> > > > Pine64+ which seems wrong, with the pine64_plus_defconfig
> > > > (which is
> > > > what
> > > > I thought handled all of the A64 platforms).
> > > 
> > > For the naming: There are three SKUs for the original Pine A64
> > > board:
> > > - Pine A64: 512 MB with 100Mbit Ethernet PHY, lacking display and
> > > camera
> > >   connectors (rare, mostly to meet the original 15 USD price tag)
> > > - Pine A64+ 1GB: 1GB DRAM with 1Gbit Ethernet PHY, with all
> > > connectors
> > > - Pine A64+ 2GB: 2GB DRAM with 1Gbit Ethernet PHY, with all
> > > connectors
> > 
> > You can check whether your board is non-Plus or Plus 1G by the
> > model of
> > the Ethernet PHY (non-Plus has RTL8201) or not soldered FPC
> > connectors.
> > They do share a PCB design. Plus 2G is a dedicated PCB design as it
> > needs to use 4x 512MB DRAM chips.
> 
> OK, mine has an RTL8211E and is 1G for sure now that I look harder at
> it.
> 
> On a related note, this board will draw power via the UART, is there
> any
> easy HW change I can do, to fix that?  It's otherwise a lot harder to
> put this in to my CI lab.

What UART pins are you using? The ones in Euler bus or the ones in EXP
bus?

The UART pins in EXP bus should have transistors to prevent power
leakage...

> 
> > > Also note that for those first boards from Pine64 the name of the
> > > company (Pine64) is sometimes uses for the boards as well
> > > ("Pine64
> > > board"), even though this should be "Pine A64 board from Pine64".
> > > That
> > > is somewhat reflected in the defconfig name. In hindsight the
> > > defconfig
> > > should have been named more "pine-a64_defconfig", but I guess
> > > this is
> > > too late now? I see a lot of inconsistencies in naming,
> > > especially
> > > regarding capitalisation and dashes vs. underscores, check
> > > configs/[bB]anana* for instance, but probably renaming causes
> > > more
> > > harm
> > > than good?
> > > 
> > > So I guess you have the middle one (the most common among the
> > > first
> > > wave), so that all seems correct? We differentiate between the
> > > non-
> > > plus
> > > and plus version at runtime, by the amount of DRAM detected, so
> > > that's
> > > pretty reliable. The 1GB and 2GB are otherwise the same, so same
> > > DT.
> > > The actual non-plus versions are somewhat rare, I guess most
> > > people
> > > just added the 4(!) bucks to get more RAM and Gigabit Ethernet.
> > > 
> > > > I've not booted this up in
> > > > forever, and Armbian (the first binary I grabbed) does this as
> > > > well
> > > > with
> > > > v2020.10 (and I'm using the same TF-A rev of 87311b4) so maybe
> > > > the
> > > > answer is I should just e-waste this board and pick up
> > > > something
> > > > else?
> > > 
> > > Not sure exactly why? Is there anything that's broken, apart from
> > > the
> > > presumed misnaming? I would be happy to hear about any issues you
> > > have,
> > > in my experience those "outsider" inputs are very useful (I am
> > > far
> > > too
> > > familiar with all those tiny quirks).
> > > When U-Boot starts, UEFI boot should work out of the box, just
> > > pop a
> > > generic arm64 Debian/SuSE/Fedora/Ubuntu EFI installer USB stick
> > > in,
> > > should work even with HDMI and USB keyboard.
> 
> Ah, so Armbian is a fails to boot (I can't even interrupt autoboot).
> Given that I was previously sure I had the 512MB model (but, I was
> wrong) I thought maybe this is just garbage now.  But! Now that I'm
> pretty sure this is being seen right, I'm going to grab a different
> distribution and see what happens.
> 

Re: Pull request: u-boot-sunxi/master for 2021.10 - 2nd part

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4408 bytes --]

On Fri, Oct 29, 2021 at 11:14:45PM +0800, Icenowy Zheng wrote:
> 在 2021-10-29星期五的 10:41 -0400，Tom Rini写道：
> > On Fri, Oct 29, 2021 at 10:20:32PM +0800, Icenowy Zheng wrote:
> > > 在 2021-10-29星期五的 11:53 +0100，Andre Przywara写道：
> > > > On Mon, 25 Oct 2021 14:29:10 -0400
> > > > Tom Rini <trini@konsulko.com> wrote:
> > > > 
> > > > Hi Tom,
> > > > 
> > > > > On Mon, Oct 25, 2021 at 03:06:58PM +0100, Andre Przywara wrote:
> > > > > 
> > > > > > Hi Tom,
> > > > > > 
> > > > > > please pull the second sunxi PR for the 2021.10 merge window.
> > > > > > I decided to merge most of Samuel's rework and some smaller
> > > > > > patches that
> > > > > > pave the way for more DM transitions and for accommodating
> > > > > > the
> > > > > > RISC-V SoC
> > > > > > in the future. Merging them now gives us the opportunity to
> > > > > > get
> > > > > > some wider
> > > > > > testing, since those subtle changes tend to break things.
> > > > > > 
> > > > > > Compile-tested for all 159 sunxi boards, boot-tested on
> > > > > > Pine64-
> > > > > > LTS
> > > > > > and OrangePi Zero.
> > > > > > 
> > > > > > Summary:
> > > > > > - Add and enable watchdog driver
> > > > > > - Prepare for SYSRESET driven AXP poweroff
> > > > > > - Prepare for SoCs without MMC2
> > > > > > - Some fixes for extending SPL (SPL-DM for RISC-V)
> > > > > > - Some preparations for proper VBUS management
> > > > > > - Fix secure monitor move
> > > > > > 
> > > > > > Thanks,
> > > > > > Andre
> > > > > > 
> > > > > > ================================================
> > > > > > The following changes since commit
> > > > > > 355d1e24f6143c4839be3c015c191421c4e9449c:
> > > > > > 
> > > > > >   Merge
> > > > > > https://source.denx.de/u-boot/custodians/u-boot-spi (2021-10-
> > > > > > 23
> > > > > > 10:49:28 -0400)
> > > > > > 
> > > > > > are available in the Git repository at:
> > > > > > 
> > > > > >  
> > > > > > https://source.denx.de/u-boot/custodians/u-boot-sunxi.git mas
> > > > > > ter
> > > > > > 
> > > > > > for you to fetch changes up to
> > > > > > c846fe43f0561311eb7261b34023a04646cdbd0d:
> > > > > > 
> > > > > >   mmc: sunxi: conditionally include MMC2 initialization code
> > > > > > (2021-10-25 14:54:57 +0100)
> > > > > >   
> > > > > 
> > > > > So first, up, this is now applied to u-boot/master.
> > > > 
> > > > Many thanks, and sorry for the late push!
> > > > 
> > > > > Next, I dug out my original Kickstarted Pine A64 board (as it's
> > > > > the
> > > > > only
> > > > > sunxi platform I have), and I see it's detected with 1GB memory
> > > > > and
> > > > > as
> > > > > Pine64+ which seems wrong, with the pine64_plus_defconfig
> > > > > (which is
> > > > > what
> > > > > I thought handled all of the A64 platforms).
> > > > 
> > > > For the naming: There are three SKUs for the original Pine A64
> > > > board:
> > > > - Pine A64: 512 MB with 100Mbit Ethernet PHY, lacking display and
> > > > camera
> > > >   connectors (rare, mostly to meet the original 15 USD price tag)
> > > > - Pine A64+ 1GB: 1GB DRAM with 1Gbit Ethernet PHY, with all
> > > > connectors
> > > > - Pine A64+ 2GB: 2GB DRAM with 1Gbit Ethernet PHY, with all
> > > > connectors
> > > 
> > > You can check whether your board is non-Plus or Plus 1G by the
> > > model of
> > > the Ethernet PHY (non-Plus has RTL8201) or not soldered FPC
> > > connectors.
> > > They do share a PCB design. Plus 2G is a dedicated PCB design as it
> > > needs to use 4x 512MB DRAM chips.
> > 
> > OK, mine has an RTL8211E and is 1G for sure now that I look harder at
> > it.
> > 
> > On a related note, this board will draw power via the UART, is there
> > any
> > easy HW change I can do, to fix that?  It's otherwise a lot harder to
> > put this in to my CI lab.
> 
> What UART pins are you using? The ones in Euler bus or the ones in EXP
> bus?
> 
> The UART pins in EXP bus should have transistors to prevent power
> leakage...

It's the EXP header (I've got the UART adapter from the kickstarter) and
I swear I saw the power LED staying on at least twice, in my previous
experiments.  But maybe that was just some bad luck / timing and
capacitor draining still or something, rather than continued leakage.
I'll assume user error until I can reliably break it.  Thanks again!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Pull request: u-boot-sunxi/master for 2021.10 - 2nd part

[Andre Przywara]

On Fri, 29 Oct 2021 23:14:45 +0800
Icenowy Zheng <icenowy@aosc.io> wrote:

> 在 2021-10-29星期五的 10:41 -0400，Tom Rini写道：
> > On Fri, Oct 29, 2021 at 10:20:32PM +0800, Icenowy Zheng wrote:  
> > > 在 2021-10-29星期五的 11:53 +0100，Andre Przywara写道：  
> > > > On Mon, 25 Oct 2021 14:29:10 -0400
> > > > Tom Rini <trini@konsulko.com> wrote:
> > > > 
> > > > Hi Tom,
> > > >   
> > > > > On Mon, Oct 25, 2021 at 03:06:58PM +0100, Andre Przywara wrote:
> > > > >   
> > > > > > Hi Tom,
> > > > > > 
> > > > > > please pull the second sunxi PR for the 2021.10 merge window.
> > > > > > I decided to merge most of Samuel's rework and some smaller
> > > > > > patches that
> > > > > > pave the way for more DM transitions and for accommodating
> > > > > > the
> > > > > > RISC-V SoC
> > > > > > in the future. Merging them now gives us the opportunity to
> > > > > > get
> > > > > > some wider
> > > > > > testing, since those subtle changes tend to break things.
> > > > > > 
> > > > > > Compile-tested for all 159 sunxi boards, boot-tested on
> > > > > > Pine64-
> > > > > > LTS
> > > > > > and OrangePi Zero.
> > > > > > 
> > > > > > Summary:
> > > > > > - Add and enable watchdog driver
> > > > > > - Prepare for SYSRESET driven AXP poweroff
> > > > > > - Prepare for SoCs without MMC2
> > > > > > - Some fixes for extending SPL (SPL-DM for RISC-V)
> > > > > > - Some preparations for proper VBUS management
> > > > > > - Fix secure monitor move
> > > > > > 
> > > > > > Thanks,
> > > > > > Andre
> > > > > > 
> > > > > > ================================================
> > > > > > The following changes since commit
> > > > > > 355d1e24f6143c4839be3c015c191421c4e9449c:
> > > > > > 
> > > > > >   Merge
> > > > > > https://source.denx.de/u-boot/custodians/u-boot-spi (2021-10-
> > > > > > 23
> > > > > > 10:49:28 -0400)
> > > > > > 
> > > > > > are available in the Git repository at:
> > > > > > 
> > > > > >  
> > > > > > https://source.denx.de/u-boot/custodians/u-boot-sunxi.git mas
> > > > > > ter
> > > > > > 
> > > > > > for you to fetch changes up to
> > > > > > c846fe43f0561311eb7261b34023a04646cdbd0d:
> > > > > > 
> > > > > >   mmc: sunxi: conditionally include MMC2 initialization code
> > > > > > (2021-10-25 14:54:57 +0100)
> > > > > >     
> > > > > 
> > > > > So first, up, this is now applied to u-boot/master.  
> > > > 
> > > > Many thanks, and sorry for the late push!
> > > >   
> > > > > Next, I dug out my original Kickstarted Pine A64 board (as it's
> > > > > the
> > > > > only
> > > > > sunxi platform I have), and I see it's detected with 1GB memory
> > > > > and
> > > > > as
> > > > > Pine64+ which seems wrong, with the pine64_plus_defconfig
> > > > > (which is
> > > > > what
> > > > > I thought handled all of the A64 platforms).  
> > > > 
> > > > For the naming: There are three SKUs for the original Pine A64
> > > > board:
> > > > - Pine A64: 512 MB with 100Mbit Ethernet PHY, lacking display and
> > > > camera
> > > >   connectors (rare, mostly to meet the original 15 USD price tag)
> > > > - Pine A64+ 1GB: 1GB DRAM with 1Gbit Ethernet PHY, with all
> > > > connectors
> > > > - Pine A64+ 2GB: 2GB DRAM with 1Gbit Ethernet PHY, with all
> > > > connectors  
> > > 
> > > You can check whether your board is non-Plus or Plus 1G by the
> > > model of
> > > the Ethernet PHY (non-Plus has RTL8201) or not soldered FPC
> > > connectors.
> > > They do share a PCB design. Plus 2G is a dedicated PCB design as it
> > > needs to use 4x 512MB DRAM chips.  
> > 
> > OK, mine has an RTL8211E and is 1G for sure now that I look harder at
> > it.
> > 
> > On a related note, this board will draw power via the UART, is there
> > any
> > easy HW change I can do, to fix that?  It's otherwise a lot harder to
> > put this in to my CI lab.  
> 
> What UART pins are you using? The ones in Euler bus or the ones in EXP
> bus?
> 
> The UART pins in EXP bus should have transistors to prevent power
> leakage...

Yes, https://linux-sunxi.org/Pine64#Serial_port_.2F_UART has the
details. On the picture it's the pins on the right, next to the SD card
slot.

Cheers,
Andre

> 
> >   
> > > > Also note that for those first boards from Pine64 the name of the
> > > > company (Pine64) is sometimes uses for the boards as well
> > > > ("Pine64
> > > > board"), even though this should be "Pine A64 board from Pine64".
> > > > That
> > > > is somewhat reflected in the defconfig name. In hindsight the
> > > > defconfig
> > > > should have been named more "pine-a64_defconfig", but I guess
> > > > this is
> > > > too late now? I see a lot of inconsistencies in naming,
> > > > especially
> > > > regarding capitalisation and dashes vs. underscores, check
> > > > configs/[bB]anana* for instance, but probably renaming causes
> > > > more
> > > > harm
> > > > than good?
> > > > 
> > > > So I guess you have the middle one (the most common among the
> > > > first
> > > > wave), so that all seems correct? We differentiate between the
> > > > non-
> > > > plus
> > > > and plus version at runtime, by the amount of DRAM detected, so
> > > > that's
> > > > pretty reliable. The 1GB and 2GB are otherwise the same, so same
> > > > DT.
> > > > The actual non-plus versions are somewhat rare, I guess most
> > > > people
> > > > just added the 4(!) bucks to get more RAM and Gigabit Ethernet.
> > > >   
> > > > > I've not booted this up in
> > > > > forever, and Armbian (the first binary I grabbed) does this as
> > > > > well
> > > > > with
> > > > > v2020.10 (and I'm using the same TF-A rev of 87311b4) so maybe
> > > > > the
> > > > > answer is I should just e-waste this board and pick up
> > > > > something
> > > > > else?  
> > > > 
> > > > Not sure exactly why? Is there anything that's broken, apart from
> > > > the
> > > > presumed misnaming? I would be happy to hear about any issues you
> > > > have,
> > > > in my experience those "outsider" inputs are very useful (I am
> > > > far
> > > > too
> > > > familiar with all those tiny quirks).
> > > > When U-Boot starts, UEFI boot should work out of the box, just
> > > > pop a
> > > > generic arm64 Debian/SuSE/Fedora/Ubuntu EFI installer USB stick
> > > > in,
> > > > should work even with HDMI and USB keyboard.  
> > 
> > Ah, so Armbian is a fails to boot (I can't even interrupt autoboot).
> > Given that I was previously sure I had the 512MB model (but, I was
> > wrong) I thought maybe this is just garbage now.  But! Now that I'm
> > pretty sure this is being seen right, I'm going to grab a different
> > distribution and see what happens.
> >   
> 
>