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%C2%A0(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%C2%A0mas 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.