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 at 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.
>