January 2019 - U-Boot

[U-Boot] memcpy/memset on arm64 platforms
by Lokesh Vutla 12 Jan '19

12 Jan '19

Hi All, I am trying to enable CONFIG_USE_ARCH_MEMSET/MEMCPY on arm64 platforms and realized that there is no arm64 specific memcpy available in u-boot. So I tried porting arm64 specific memcpy from kernel[1]. Memcpy stopped working after that and observed that if destination address is unaligned then system hangs. After doing a bit more research, understood that unaligned access to device or strongly ordered memories will fail. And the memory system (even normal RAM) behaves like strongly ordered memory when the MMU is disabled[2]. In u-boot MMU is enabled very late after relocation and SPL doesn't enable MMU at all. Before I proceed any further wanted to hear from others if anyone have already tried and have any working solution. If not should we update the kernel memcpy to use unaligned destination address and use it in u-boot? [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arc… [2] https://community.arm.com/processors/f/discussions/7557/when-and-where-will… Thanks and regards, Lokesh

6 7

[U-Boot] [PATCH 0/7] mmc: sunxi: Enable DM_MMC
by Jagan Teki 11 Jan '19

11 Jan '19

I thought of waiting this till CLK framework gets Mainline, but migration deadline for DM_MMC and BLK seems expiring in next release. So instead of doing so huddle and make some last minute changes, I have managed to add CLK, Reset code for mmc driver via driver data. Add for all Allwinner SoC's and enable at arch/arm/Kconfig. I shall merge this in comming MW, so early test feel better to go for the release. Request to test respective board takers. Any inputs, Jagan. Jagan Teki (7): mmc: sunxi: Configure reset support for DM_MMC mmc: sunxi: Add A83T emmc compatible mmc: sunxi: Add mmc, emmc H5/A64 compatible mmc: sunxi: Add DM_MMC support for H6 mmc: sunxi: Add DM_MMC support for A80 arm: sunxi: Enable DM_MMC arm: dts: sunxi: Enumerate MMC2 as MMC1 arch/arm/Kconfig | 1 + arch/arm/dts/sunxi-u-boot.dtsi | 4 + .../include/asm/arch-sunxi/clock_sun50i_h6.h | 3 + arch/arm/mach-sunxi/Kconfig | 1 - configs/Linksprite_pcDuino3_defconfig | 1 - drivers/mmc/sunxi_mmc.c | 73 ++++++++++++++++++- 6 files changed, 79 insertions(+), 4 deletions(-) -- 2.18.0.321.gffc6fa0e3

1 0

[U-Boot] [RFC] Device model for block devices - integration with EFI subsystem
by Heinrich Schuchardt 11 Jan '19

11 Jan '19

# Motivation At different times we have noted that in U-Boot device model and the EFI subsystem we have parallel structures. The most recent being Takahiro's patch series [1]. Before adding any more dependencies I think we should develop a sound architectural vision. We should end up with a design specification on which we can base our future development. This year hopefully all block devices will be eliminated in U-Boot that are not following the device model. This gives us the chance to clean up our code base. Topics of this mail are: - how devices and drivers are modeled in EFI - how devices and drivers are modeled in U-Boot - how both are related - the state of block devices and drivers in U-Boot - first thoughts on joining the two worlds # Devices and drivers in EFI An overview of devices and drivers in EFI is given in doc/README.uefi. A device is represented by a handle (struct efi_obj *) exposing the device path protocol. This device path protocol is a sequence of device path nodes. The device tree is modeled via the device path protocol. A driver (also called controller) is represented by a handle exposing the EFI_DRIVER_BINDING_PROTOCOL. Drivers are attached to a device by calling the ConnectController service. Drivers are removed from a device by calling the DisconnectController service. The ConnectController service iterates over all handles exposing the driver binding protocol and calls the Supported() method of the protocol. For each driver supporting the device it calls the Start() method of the protocol. The driver now installs its own protocol on the device handle with its own handle referenced as the controller and setting an attribute indicating if it is binding exclusively (no other driver may be connected to the device). The driver may create additional handles representing sub-devices in the StartService. The ConnectController service can recursively bind drivers to these. The DisconnectController service iterates of all protocols on the device handle which are marked as being controlled by a driver and calls the Stop() method of the driver binding protocol. The driver now uninstalls its protocol. There can be handles that are neither drivers nor devices. Devices may be created by the sub-system without any pre-existing U-Boot device, e.g. an iSCSI drive may be set up as a handle exposing the EFI_BLOCK_IO_PROTOCOL, or a VPN tunnel may be created as a virtual network interface with the EFI_SIMPLE_NETWORK_PROTOCOL installed. # Devices and drivers in U-Boot doc/driver-model/README.txt has an overview. A driver has a U_BLOCK_DRIVER entry linking it to a uclass. In the ops pointer U_BLOCK_DRIVER it exposes the available operations. A uclass represents a group of drivers exposing the same interface. A device is represented by a udevice structure. It has a pointer to its uclass. It is connected to a driver by calling the bind() function of its uclass and can be disconnected by calling the unbind() function of the uclass. All devices have a parent device except for the top level device. These relationships make up the device tree. Some devices to be created are defined in the device tree. Other devices are detected by scanning hardware buses. New devices may be found at runtime, e.g. when a USB device is connected. # Relationship between EFI and U-Boot devices ConnectController in EFI is the equivalent to bind(), ofdata_to_platdata(), and probe() in U-Boot. DisconnectController in EFI is the equivalent to unbind() in U-Boot. We have discovered a single case where objects are devices in EFI but not in U-Boot. EFI partitions are block io devices where the disk is the parent. A block device exposes the EFI_BLOCK_IO_PROTOCOL. If the partition is formatted the EFI device additionally exposes the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. In U-Boot partitions and file systems are not following the device model. We have devices in U-Boot where there is no protocol existing in EFI to access it. We could represent them in EFI as a handle with a device path protocol. As described above the EFI subsystem may create (virtual) devices. For block io devices we have integrated the two worlds. When ConnectController is called for a block io device we create a U-Boot block device marked as being of type UCLASS_EFI. The unbinding of the driver is not yet implemented. # How we can tie the worlds together Every device in the EFI world should have an equivalent in the U-Boot world. This requires modeling partitions as U-Boot devices. Every U-Boot device relevant for EFI and all its ancestors should have an EFI handle with the EFI_DEVICE_PATH_PROTOCOL installed. For convenient look up a pointer to the device in the EFI handle (struct efi_obj) would be helpful. When trying to join the EFI and the U-Boot driver model the best abstraction level would be uclasses having EFI handles exposing the EFI_DRIVER_BINDING_PROTOCOL. EFI handles should be created when bind() is called for the U-Boot device. Block devices seem to be the best starting point for the exercise. [1] [PATCH v2 0/3] efi_loader: add removable device support https://lists.denx.de/pipermail/u-boot/2018-November/347491.html

1 0

[U-Boot] [PATCH 0/3] tools: mkimage: Add Allwinner eGON support
by Andre Przywara 11 Jan '19

11 Jan '19

So far creating a bootable SPL image for Allwinner based boards uses the mksunxiboot tool. Most other platforms seemed to have integrated this kind of functionality into the common mkimage tool. Since there is nothing special about the Allwinner image in this respect, just add support for the so-called "eGON" image type into mkimage. If there was a particular reason this hasn't been done before, please let me know. This will eventually allow us to remove mksunxiboot, but I leave it around for now in case of regressions and since some people depend on it from external projects. Patch 1/3 fixes a small annoyance in mkimage -T list. Patch 2/3 adds the actually support to mkimage, patch 3/3 then switches the Makefile to use mkimage instead of mksunxiboot. I tested all 144 Allwinner boards by building each sunxi-spl.bin and comparing it against the version created using mksunxiboot (using SOURCE_DATE_EPOCH and .scmversion to create reproducible builds). All files before and after were identical. Cheers, Andre Andre Przywara (3): tools: mkimage: Add missing names for imx8mimage and loadables tools: mkimage: Add Allwinner eGON support sunxi: Use mkimage -T sunxi_egon for SPL boot image generation common/image.c | 3 ++ include/image.h | 1 + scripts/Makefile.spl | 8 +-- tools/Makefile | 1 + tools/sunxi_egon.c | 136 +++++++++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 145 insertions(+), 4 deletions(-) create mode 100644 tools/sunxi_egon.c -- 2.14.5

4 10

[U-Boot] [PATCH] mmc: sunxi: Fix mmc clocks for DM_MMC
by Jagan Teki 11 Jan '19

11 Jan '19

Existing clock configure code has been followed based on the legacy MMC dt node definitions and it cannot work with recent dts(i) sync from Linux. So, add clock configure code for Allwinner platforms which support DM_MMC and eventually this will drop once CLK support is in Mainline. Fixes: 3c92cca3cda0 ("ARM: dts: sun4i: Update A10 dts(i) files from Linux-v4.18-rc3") Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com> --- drivers/mmc/sunxi_mmc.c | 50 ++++++++++++++++++++++++++++++----------- 1 file changed, 37 insertions(+), 13 deletions(-) diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c index 9bf040cb40..c55b8b753d 100644 --- a/drivers/mmc/sunxi_mmc.c +++ b/drivers/mmc/sunxi_mmc.c @@ -19,6 +19,13 @@ #include <asm/arch/mmc.h> #include <asm-generic/gpio.h> +#ifdef CONFIG_DM_MMC +struct sunxi_mmc_variant { + u8 gate_offset; + u8 mclk_offset; +}; +#endif + struct sunxi_mmc_plat { struct mmc_config cfg; struct mmc mmc; @@ -32,6 +39,9 @@ struct sunxi_mmc_priv { int cd_inverted; /* Inverted Card Detect */ struct sunxi_mmc *reg; struct mmc_config cfg; +#ifdef CONFIG_DM_MMC + const struct sunxi_mmc_variant *variant; +#endif }; #if !CONFIG_IS_ENABLED(DM_MMC) @@ -599,7 +609,7 @@ static int sunxi_mmc_probe(struct udevice *dev) struct sunxi_mmc_priv *priv = dev_get_priv(dev); struct mmc_config *cfg = &plat->cfg; struct ofnode_phandle_args args; - u32 *gate_reg; + u32 *gate_reg, *ccu_reg; int bus_width, ret; cfg->name = dev->name; @@ -618,21 +628,21 @@ static int sunxi_mmc_probe(struct udevice *dev) cfg->f_max = 52000000; priv->reg = (void *)dev_read_addr(dev); + priv->variant = + (const struct sunxi_mmc_variant *)dev_get_driver_data(dev); /* We don't have a sunxi clock driver so find the clock address here */ ret = dev_read_phandle_with_args(dev, "clocks", "#clock-cells", 0, 1, &args); if (ret) return ret; - priv->mclkreg = (u32 *)ofnode_get_addr(args.node); + ccu_reg = (u32 *)ofnode_get_addr(args.node); - ret = dev_read_phandle_with_args(dev, "clocks", "#clock-cells", 0, - 0, &args); - if (ret) - return ret; - gate_reg = (u32 *)ofnode_get_addr(args.node); - setbits_le32(gate_reg, 1 << args.args[0]); - priv->mmc_no = args.args[0] - 8; + priv->mmc_no = ((uintptr_t)priv->reg - SUNXI_MMC0_BASE) / 0x1000; + priv->mclkreg = (void *)ccu_reg + + (priv->variant->mclk_offset + (priv->mmc_no * 4)); + gate_reg = (void *)ccu_reg + priv->variant->gate_offset; + setbits_le32(gate_reg, BIT(AHB_GATE_OFFSET_MMC(priv->mmc_no))); ret = mmc_set_mod_clk(priv, 24000000); if (ret) @@ -665,11 +675,25 @@ static int sunxi_mmc_bind(struct udevice *dev) return mmc_bind(dev, &plat->mmc, &plat->cfg); } +static const struct sunxi_mmc_variant sun4i_a10_variant = { + .gate_offset = 0x60, + .mclk_offset = 0x88, +}; + static const struct udevice_id sunxi_mmc_ids[] = { - { .compatible = "allwinner,sun4i-a10-mmc" }, - { .compatible = "allwinner,sun5i-a13-mmc" }, - { .compatible = "allwinner,sun7i-a20-mmc" }, - { } + { + .compatible = "allwinner,sun4i-a10-mmc", + .data = (ulong)&sun4i_a10_variant, + }, + { + .compatible = "allwinner,sun5i-a13-mmc", + .data = (ulong)&sun4i_a10_variant, + }, + { + .compatible = "allwinner,sun7i-a20-mmc", + .data = (ulong)&sun4i_a10_variant, + }, + { /* sentinel */ } }; U_BOOT_DRIVER(sunxi_mmc_drv) = { -- 2.18.0.321.gffc6fa0e3

3 3

[U-Boot] [PATCH 1/2] board: tbs2910: Add u-boot.imx size limit check
by Soeren Moch 11 Jan '19

11 Jan '19

Check the size of the generated u-boot.imx file. Report an error if it would be too big and overwrite the u-boot environment. Signed-off-by: Soeren Moch <smoch(a)web.de> --- Cc: Stefano Babic <sbabic(a)denx.de> Cc: Fabio Estevam <fabio.estevam(a)nxp.com> Cc: u-boot(a)lists.denx.de --- include/configs/tbs2910.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/tbs2910.h b/include/configs/tbs2910.h index a60223c623..2d4b9c9bfe 100644 --- a/include/configs/tbs2910.h +++ b/include/configs/tbs2910.h @@ -122,6 +122,8 @@ #define CONFIG_ENV_OFFSET (384 * 1024) #define CONFIG_ENV_OVERWRITE +#define CONFIG_BOARD_SIZE_LIMIT 392192 /* (CONFIG_ENV_OFFSET - 1024) */ + #define CONFIG_EXTRA_ENV_SETTINGS \ "bootargs_mmc1=console=ttymxc0,115200 di0_primary console=tty1\0" \ "bootargs_mmc2=video=mxcfb0:dev=hdmi,1920x1080M@60 " \ -- 2.17.1

6 28

[U-Boot] [PATCH] of-platdata: improve documentation
by Simon Goldschmidt 11 Jan '19

11 Jan '19

Improve some things in the documentation of OF_PLATDATA that I found while porting socfgpa_gen5 to it. Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt(a)gmail.com> --- doc/driver-model/of-plat.txt | 18 ++++++++++++------ dts/Kconfig | 6 ++---- 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/doc/driver-model/of-plat.txt b/doc/driver-model/of-plat.txt index 732bc34f06..ecb5f1724b 100644 --- a/doc/driver-model/of-plat.txt +++ b/doc/driver-model/of-plat.txt @@ -69,12 +69,12 @@ How it works ------------ The feature is enabled by CONFIG SPL_OF_PLATDATA. This is only available -in SPL and should be tested with: +in SPL/TPL and should be tested with: #if CONFIG_IS_ENABLED(SPL_OF_PLATDATA) A new tool called 'dtoc' converts a device tree file either into a set of -struct declarations, one for each compatible node, or a set of +struct declarations, one for each compatible node, and a set of U_BOOT_DEVICE() declarations along with the actual platform data for each device. As an example, consider this MMC node: @@ -156,6 +156,12 @@ This avoids the code overhead of converting the device tree data to platform data in the driver. The ofdata_to_platdata() method should therefore do nothing in such a driver. +Note that for the platform data to be matched with a driver, the 'name' +property of the U_BOOT_DEVICE() declaration has to match a driver declared +via U_BOOT_DRIVER(). This effectively means that a U_BOOT_DRIVER() with a +'name' identical to the devicetree 'compatible' string is needed, so a +dedicated driver is required for each 'compatible' string. + Where a node has multiple compatible strings, a #define is used to make them equivalent, e.g.: @@ -165,8 +171,8 @@ equivalent, e.g.: Converting of-platdata to a useful form --------------------------------------- -Of course it would be possible use the of-platdata directly in your driver -whenever configuration information is required. However this meands that the +Of course it would be possible to use the of-platdata directly in your driver +whenever configuration information is required. However this means that the driver will not be able to support device tree, since the of-platdata structure is not available when device tree is used. It would make no sense to use this structure if device tree were available, since the structure has @@ -282,8 +288,8 @@ prevents them being used inadvertently. All usage must be bracketed with The dt-platdata.c file contains the device declarations and is is built in spl/dt-platdata.c. -Some phandles (thsoe that are recognised as such) are converted into -points to platform data. This pointer can potentially be used to access the +Some phandles (those that are recognised as such) are converted into +pointer to platform data. This pointer can potentially be used to access the referenced device (by searching for the pointer value). This feature is not yet implemented, however. diff --git a/dts/Kconfig b/dts/Kconfig index 8917f42444..3e85914d11 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -265,8 +265,7 @@ config SPL_OF_PLATDATA This option works by generating C structure declarations for each compatible string, then adding platform data and U_BOOT_DEVICE - declarations for each node. See README.platdata for more - information. + declarations for each node. See of-plat.txt for more information. config TPL_OF_PLATDATA bool "Generate platform data for use in TPL" @@ -287,8 +286,7 @@ config TPL_OF_PLATDATA This option works by generating C structure declarations for each compatible string, then adding platform data and U_BOOT_DEVICE - declarations for each node. See README.platdata for more - information. + declarations for each node. See of-plat.txt for more information. endmenu -- 2.17.1

3 3

[U-Boot] [PATCH v5 0/6] MSCC: Add Jaguar2 SOC family
by Horatiu Vultur 11 Jan '19

11 Jan '19

This patch series add support for MSCC Jaguar2 SOC family. In this family there are the following boards: Jagaur2(pcb110), Jaguar2-48(pcb111) and Serval2(pcb112). This is based off the u-boot-mips/next repository This version address comments from Gregory Clement <gregory.clement(a)bootlin.com> v5-changes: - update pinctrl to be similar with linux version v4-changes: - remove sysreset driver v3-changes: - remove any target specific code from mscc-common.c v2-changes: - create sysreset driver for Jaguar2 - update pinctrl Horatiu Vultur (6): pinctrl: mscc: Add gpio and pinctrl for Jaguar2 SOC family MSCC: Add support for Jaguar2 SOC family MSCC: Add device tree for Jaguar2 board MSCC: Add device tree for Jaguar2-48 board MSCC: add device tree for Serval2 board MSCC: Add board support for Jaguar2 SOC family MAINTAINERS | 3 + arch/mips/dts/Makefile | 1 + arch/mips/dts/jr2_pcb110.dts | 74 +++++ arch/mips/dts/jr2_pcb111.dts | 74 +++++ arch/mips/dts/mscc,jr2.dtsi | 187 ++++++++++++ arch/mips/dts/serval2_pcb112.dts | 60 ++++ arch/mips/mach-mscc/Kconfig | 9 + arch/mips/mach-mscc/Makefile | 5 +- arch/mips/mach-mscc/cpu.c | 7 + arch/mips/mach-mscc/dram.c | 2 +- arch/mips/mach-mscc/include/mach/common.h | 5 + arch/mips/mach-mscc/include/mach/ddr.h | 38 ++- arch/mips/mach-mscc/include/mach/jr2/jr2.h | 24 ++ .../mach-mscc/include/mach/jr2/jr2_devcpu_gcb.h | 20 ++ .../include/mach/jr2/jr2_devcpu_gcb_miim_regs.h | 25 ++ .../mips/mach-mscc/include/mach/jr2/jr2_icpu_cfg.h | 321 ++++++++++++++++++++ arch/mips/mach-mscc/reset.c | 17 ++ board/mscc/common/Makefile | 4 + board/mscc/common/spi.c | 31 ++ board/mscc/jr2/Kconfig | 15 + board/mscc/jr2/Makefile | 4 + board/mscc/jr2/jr2.c | 115 ++++++++ board/mscc/ocelot/ocelot.c | 22 -- configs/mscc_jr2_defconfig | 59 ++++ drivers/pinctrl/mscc/Kconfig | 9 + drivers/pinctrl/mscc/Makefile | 1 + drivers/pinctrl/mscc/mscc-common.c | 90 ++++-- drivers/pinctrl/mscc/mscc-common.h | 17 +- drivers/pinctrl/mscc/pinctrl-jr2.c | 323 +++++++++++++++++++++ drivers/pinctrl/mscc/pinctrl-luton.c | 16 +- drivers/pinctrl/mscc/pinctrl-ocelot.c | 16 +- 31 files changed, 1533 insertions(+), 61 deletions(-) create mode 100644 arch/mips/dts/jr2_pcb110.dts create mode 100644 arch/mips/dts/jr2_pcb111.dts create mode 100644 arch/mips/dts/mscc,jr2.dtsi create mode 100644 arch/mips/dts/serval2_pcb112.dts create mode 100644 arch/mips/mach-mscc/include/mach/jr2/jr2.h create mode 100644 arch/mips/mach-mscc/include/mach/jr2/jr2_devcpu_gcb.h create mode 100644 arch/mips/mach-mscc/include/mach/jr2/jr2_devcpu_gcb_miim_regs.h create mode 100644 arch/mips/mach-mscc/include/mach/jr2/jr2_icpu_cfg.h create mode 100644 board/mscc/common/Makefile create mode 100644 board/mscc/common/spi.c create mode 100644 board/mscc/jr2/Kconfig create mode 100644 board/mscc/jr2/Makefile create mode 100644 board/mscc/jr2/jr2.c create mode 100644 configs/mscc_jr2_defconfig create mode 100644 drivers/pinctrl/mscc/pinctrl-jr2.c -- 2.7.4

1 6

[U-Boot] SPL Platdata howto?
by Simon Goldschmidt 11 Jan '19

11 Jan '19

Hi, while searching for bytes to save in SPL in order to add FIT signature handling, I am currently trying to get socfpga-gen5 to use OF_PLATDATA. To begin, I stripped down socfpga_socrates_defconfig to absolutely nothing but serial drivers in SPL (with some modifications to the Kconfig) and enabled DEBUG_UART to see what's going on. Now while this config runs OK with a dtb (it just won't boot as drivers are missing -> "failed to boot from all boot devices"), it does not find the serial driver after enabling OF_PLATDATA. So since serial_rockchip.c already uses OF_PLATDATA and is based on ns16550 that my socfpga-gen5 platform is using: what do I have to do besides enabling OF_PLATDATA to get this working? I just seems like uclass_first_device does not find any UCLASS_SERIAL deivce when OF_PLATDATA is enabled. (And when answering this, keep in mind I need to get MMC and QSPI drivers working with OF_PLATDATA - I already fixed compiler errors in those, nothing more.) Thanks, Simon

2 10

[U-Boot] [PATCH 1/1] sunxi: board: Add i2c initialization for sun50i
by Stefan Mavrodiev 11 Jan '19

11 Jan '19

To use TWI0/1/2 the user can select CONFIG_I2C#_ENABLE. However even the controller is enabled, the mux for the pins are not set. This patch follows the existing mux method. Since the pads are different, separate check is added for each i2c. Tested with A64-SOM204 board. Signed-off-by: Stefan Mavrodiev <stefan(a)olimex.com> --- arch/arm/include/asm/arch-sunxi/gpio.h | 3 +++ board/sunxi/board.c | 12 ++++++++++++ 2 files changed, 15 insertions(+) diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h b/arch/arm/include/asm/arch-sunxi/gpio.h index 2daf23f6f5..40a3f845d0 100644 --- a/arch/arm/include/asm/arch-sunxi/gpio.h +++ b/arch/arm/include/asm/arch-sunxi/gpio.h @@ -176,6 +176,7 @@ enum sunxi_gpio_number { #define SUN5I_GPE_SDC2 3 #define SUN8I_GPE_TWI2 3 +#define SUN50I_GPE_TWI2 3 #define SUNXI_GPF_SDC0 2 #define SUNXI_GPF_UART0 4 @@ -193,8 +194,10 @@ enum sunxi_gpio_number { #define SUN4I_GPH_SDC1 5 #define SUN6I_GPH_TWI0 2 #define SUN8I_GPH_TWI0 2 +#define SUN50I_GPH_TWI0 2 #define SUN6I_GPH_TWI1 2 #define SUN8I_GPH_TWI1 2 +#define SUN50I_GPH_TWI1 2 #define SUN6I_GPH_TWI2 2 #define SUN6I_GPH_UART0 2 #define SUN9I_GPH_UART0 2 diff --git a/board/sunxi/board.c b/board/sunxi/board.c index f022f365e9..ad14837291 100644 --- a/board/sunxi/board.c +++ b/board/sunxi/board.c @@ -98,6 +98,10 @@ void i2c_init_board(void) sunxi_gpio_set_cfgpin(SUNXI_GPH(2), SUN8I_GPH_TWI0); sunxi_gpio_set_cfgpin(SUNXI_GPH(3), SUN8I_GPH_TWI0); clock_twi_onoff(0, 1); +#elif defined(CONFIG_MACH_SUN50I) + sunxi_gpio_set_cfgpin(SUNXI_GPH(0), SUN50I_GPH_TWI0); + sunxi_gpio_set_cfgpin(SUNXI_GPH(1), SUN50I_GPH_TWI0); + clock_twi_onoff(0, 1); #endif #endif @@ -120,6 +124,10 @@ void i2c_init_board(void) sunxi_gpio_set_cfgpin(SUNXI_GPH(4), SUN8I_GPH_TWI1); sunxi_gpio_set_cfgpin(SUNXI_GPH(5), SUN8I_GPH_TWI1); clock_twi_onoff(1, 1); +#elif defined(CONFIG_MACH_SUN50I) + sunxi_gpio_set_cfgpin(SUNXI_GPH(2), SUN50I_GPH_TWI1); + sunxi_gpio_set_cfgpin(SUNXI_GPH(3), SUN50I_GPH_TWI1); + clock_twi_onoff(1, 1); #endif #endif @@ -142,6 +150,10 @@ void i2c_init_board(void) sunxi_gpio_set_cfgpin(SUNXI_GPE(12), SUN8I_GPE_TWI2); sunxi_gpio_set_cfgpin(SUNXI_GPE(13), SUN8I_GPE_TWI2); clock_twi_onoff(2, 1); +#elif defined(CONFIG_MACH_SUN50I) + sunxi_gpio_set_cfgpin(SUNXI_GPE(14), SUN50I_GPE_TWI2); + sunxi_gpio_set_cfgpin(SUNXI_GPE(15), SUN50I_GPE_TWI2); + clock_twi_onoff(2, 1); #endif #endif -- 2.17.1

3 2