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

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