[U-Boot] [PATCH v3] board: sun50i: Add Amarula A64-Relic initial support
Amarula A64-Relic is A64 based IoT device, which support - Allwinner A64 Cortex-A53 - Mali-400MP2 GPU - AXP803 PMIC - 1GB DDR3 RAM - 8GB eMMC - AP6330 Wifi/BLE - MIPI-DSI - CSI: OV5640 sensor - USB OTG - 12V DC power supply
Signed-off-by: Jagan Teki jagan@amarulasolutions.com --- Changes for v3: - Use sun50i-a64-relic.dts name Changes for v2: - Rename dts name to sun50i-a64-relic.dts which is simple to use - Rename defconfig to a64_relic_defconfig - Use licence year as 2018
arch/arm/dts/Makefile | 1 + arch/arm/dts/sun50i-a64-amarula-relic.dts | 65 +++++++++++++++++++++++++++++++ board/sunxi/MAINTAINERS | 6 +++ configs/amarula_a64_relic_defconfig | 18 +++++++++ 4 files changed, 90 insertions(+) create mode 100644 arch/arm/dts/sun50i-a64-amarula-relic.dts create mode 100644 configs/amarula_a64_relic_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index a0349a8975..3efa3b99b9 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -381,6 +381,7 @@ dtb-$(CONFIG_MACH_SUN50I_H5) += \ sun50i-h5-orangepi-prime.dtb \ sun50i-h5-orangepi-zero-plus2.dtb dtb-$(CONFIG_MACH_SUN50I) += \ + sun50i-a64-amarula-relic.dtb \ sun50i-a64-bananapi-m64.dtb \ sun50i-a64-nanopi-a64.dtb \ sun50i-a64-olinuxino.dtb \ diff --git a/arch/arm/dts/sun50i-a64-amarula-relic.dts b/arch/arm/dts/sun50i-a64-amarula-relic.dts new file mode 100644 index 0000000000..f3b4e93ece --- /dev/null +++ b/arch/arm/dts/sun50i-a64-amarula-relic.dts @@ -0,0 +1,65 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Copyright (C) 2018 Amarula Solutions B.V. + * Author: Jagan Teki jagan@amarulasolutions.com + */ + +/dts-v1/; + +#include "sun50i-a64.dtsi" + +#include <dt-bindings/gpio/gpio.h> + +/ { + model = "Amarula A64-Relic"; + compatible = "amarula,a64-relic", "allwinner,sun50i-a64"; + + aliases { + serial0 = &uart0; + }; + + chosen { + stdout-path = "serial0:115200n8"; + }; + + reg_vcc3v3: vcc3v3 { + compatible = "regulator-fixed"; + regulator-name = "vcc3v3"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + }; +}; + +&ehci0 { + status = "okay"; +}; + +&mmc2 { + pinctrl-names = "default"; + pinctrl-0 = <&mmc2_pins>; + vmmc-supply = <®_vcc3v3>; + bus-width = <8>; + non-removable; + cap-mmc-hw-reset; + status = "okay"; +}; + +&ohci0 { + status = "okay"; +}; + +&uart0 { + pinctrl-names = "default"; + pinctrl-0 = <&uart0_pins_a>; + status = "okay"; +}; + +&usb_otg { + dr_mode = "otg"; + status = "okay"; +}; + +&usbphy { + usb0_id_det-gpios = <&pio 7 9 GPIO_ACTIVE_HIGH>; /* PH9 */ + status = "okay"; +}; diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index 1bb2fa8f51..e90c87b560 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -116,6 +116,12 @@ M: Paul Kocialkowski contact@paulk.fr S: Maintained F: configs/Ainol_AW1_defconfig
+AMARULA A64-RELIC +M: Jagan Teki jagan@amarulasolutions.com +S: Maintained +F: configs/amarula_a64_relic_defconfig +F: arch/arm/dts/sun50i-a64-amarula-relic.dts + AMPE A76 BOARD M: Paul Kocialkowski contact@paulk.fr S: Maintained diff --git a/configs/amarula_a64_relic_defconfig b/configs/amarula_a64_relic_defconfig new file mode 100644 index 0000000000..6eab0d2ae5 --- /dev/null +++ b/configs/amarula_a64_relic_defconfig @@ -0,0 +1,18 @@ +CONFIG_ARM=y +CONFIG_ARCH_SUNXI=y +CONFIG_SPL=y +CONFIG_MACH_SUN50I=y +CONFIG_DRAM_ODT_EN=y +CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y +CONFIG_MMC_SUNXI_SLOT_EXTRA=2 +CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-amarula-relic" +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set +# CONFIG_VIDEO_DE2 is not set +# CONFIG_CMD_FLASH is not set +# CONFIG_CMD_FPGA is not set +# CONFIG_SPL_DOS_PARTITION is not set +CONFIG_CMD_USB_MASS_STORAGE=y +# CONFIG_SPL_ISO_PARTITION is not set +# CONFIG_SPL_EFI_PARTITION is not set +CONFIG_USB_MUSB_GADGET=y +CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
On Mon, May 28, 2018 at 04:34:43PM +0530, Jagan Teki wrote:
+CONFIG_CMD_USB_MASS_STORAGE=y
You still haven't explained why this is useful to add it by default on this particular board.
Maxime
On Tue, May 29, 2018 at 9:44 PM, Maxime Ripard maxime.ripard@bootlin.com wrote:
On Mon, May 28, 2018 at 04:34:43PM +0530, Jagan Teki wrote:
+CONFIG_CMD_USB_MASS_STORAGE=y
You still haven't explained why this is useful to add it by default on this particular board.
This board does have only eMMC and no external storage possibilities(like eMMC or Ethernet) so to copy images between eMMC vs host intermediate way (other than fastboot) ums can be the possible way.
On Tue, May 29, 2018 at 09:50:39PM +0530, Jagan Teki wrote:
On Tue, May 29, 2018 at 9:44 PM, Maxime Ripard maxime.ripard@bootlin.com wrote:
On Mon, May 28, 2018 at 04:34:43PM +0530, Jagan Teki wrote:
+CONFIG_CMD_USB_MASS_STORAGE=y
You still haven't explained why this is useful to add it by default on this particular board.
This board does have only eMMC and no external storage possibilities(like eMMC or Ethernet) so to copy images between eMMC vs host intermediate way (other than fastboot) ums can be the possible way.
We have fastboot and DFU to address that already, and a number of other boards accomodate that just fine (the CHIP, the NES Classic, etc.).
Maxime
On Thu, May 31, 2018 at 3:07 PM, Maxime Ripard maxime.ripard@bootlin.com wrote:
On Tue, May 29, 2018 at 09:50:39PM +0530, Jagan Teki wrote:
On Tue, May 29, 2018 at 9:44 PM, Maxime Ripard maxime.ripard@bootlin.com wrote:
On Mon, May 28, 2018 at 04:34:43PM +0530, Jagan Teki wrote:
+CONFIG_CMD_USB_MASS_STORAGE=y
You still haven't explained why this is useful to add it by default on this particular board.
This board does have only eMMC and no external storage possibilities(like eMMC or Ethernet) so to copy images between eMMC vs host intermediate way (other than fastboot) ums can be the possible way.
We have fastboot and DFU to address that already, and a number of other boards accomodate that just fine (the CHIP, the NES Classic, etc.).
Yes, but ums is different where we can simply mount the flash on host and update the partitions data directly instead of create partitions with new data to write again. what's wrong with using ums. I always believe fastboot, DFU is different than ums where former need to create image file and later simply copy.
Jagan.
On Thu, May 31, 2018 at 03:13:15PM +0530, Jagan Teki wrote:
On Thu, May 31, 2018 at 3:07 PM, Maxime Ripard maxime.ripard@bootlin.com wrote:
On Tue, May 29, 2018 at 09:50:39PM +0530, Jagan Teki wrote:
On Tue, May 29, 2018 at 9:44 PM, Maxime Ripard maxime.ripard@bootlin.com wrote:
On Mon, May 28, 2018 at 04:34:43PM +0530, Jagan Teki wrote:
+CONFIG_CMD_USB_MASS_STORAGE=y
You still haven't explained why this is useful to add it by default on this particular board.
This board does have only eMMC and no external storage possibilities(like eMMC or Ethernet) so to copy images between eMMC vs host intermediate way (other than fastboot) ums can be the possible way.
We have fastboot and DFU to address that already, and a number of other boards accomodate that just fine (the CHIP, the NES Classic, etc.).
Yes, but ums is different where we can simply mount the flash on host and update the partitions data directly instead of create partitions with new data to write again. what's wrong with using ums. I always believe fastboot, DFU is different than ums where former need to create image file and later simply copy.
I'm not arguing the usefulness of the UMS gadget itself, I don't have any objections to that, and I totally get why and how it can be useful. What I'm arguing for is why you should enable it *by default*.
You can very easily do that with menuconfig already, and we won't enable each and every command and feature someone finds interesting. We've already been bitten hard by this, and I have no intention of doing that kind of thing a second time.
So yeah, you can definitely use UMS if you wish so. But enabling it by default when we have already two alternatives for the same use case enabled is pointless.
Maxime
participants (3)
-
Jagan Teki -
Jagan Teki -
Maxime Ripard