Pull request: u-boot-sunxi/master for 2021.10 - 2nd part
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
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!
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
在 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%A0master
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
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%A0master
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.
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%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%A0master
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.
在 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...
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.
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%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...
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!
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.
participants (3)
-
Andre Przywara -
Icenowy Zheng -
Tom Rini