rk3399-gru-kevin: issues on bringup

rk3399-gru-kevin: issues on bringup

[Marty E. Plummer]

Greetings.

I've been working on u-boot for rk3399-gru-kevin, Samsung Chromebook
Plus. In theory it should be fairly similar to the Bob chromebook, and
as such my work is largely based on it. Aside from some trivial changes,
and adding chromebook_kevin_defconfig (direct copy of bob's config, with
bob exchanged for kevin where apropriate) there is no major changes done
(current diff at bottom).

After building, I prepare the image like this:

===============
$ ./tools/mkimage -n rk3399 -T rkspi -d spl/u-boot-spl.bin idbloader.img
# 0x60000 chosen from doc/board/rockchip/rockchip.rst:187
$ dd if=idbloader.img of=start bs=$((0x60000)) conv=sync count=1
$ cat u-boot.itb >> start
# 8mb spi flash
$ dd if=start of=flash.bin bs=$((1024*1024*8)) conv=sync count=1
===============

and flash it from within a chromeos dev env with a servo, like this:
===============
# power down
$ dut-control spi2_buf_en:on spi2_buf_on_flex_en:on spi2_vref:pp3300 cold_reset:on
# flash
$ sudo flashrom -V --programmer ft2232_spi:type=google-servo-v2 -w flash.bin
# power up
$ dut-control spi2_buf_en:off spi2_buf_on_flex_en:off spi2_vref:off cold_reset:off
===============

But I do not get any more output than the following: (using the same ddr
config as bob, as it matches what coreboot's source tree has listed
during coreboot's bootup, to the best of my ability to tell.
src/mainboard/google/gru/sdram_params/sdram-lpddr3-generic-4GB-928.c

===============
Channel 0: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
256B stride

U-Boot SPL 2020.07-10102-g1c4b5038af-dirty (Jul 19 2020 - 22:04:50 -0500)
SPL: Unsupported Boot Device!
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
===============

Unsure where to proceed from here. I notice that when bob was originally
ported the chosen node had a u-boot,spl-boot-order property and the
config node had u-boot,spl-payload-offset, which is no more, perhaps
there is something to that?

Current changes:

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index cee10f533f..0e3e1cc553 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -122,6 +122,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
        rk3399-ficus.dtb \
        rk3399-firefly.dtb \
        rk3399-gru-bob.dtb \
+       rk3399-gru-kevin.dtb \
        rk3399-khadas-edge.dtb \
        rk3399-khadas-edge-captain.dtb \
        rk3399-khadas-edge-v.dtb \

diff --git a/include/dt-bindings/input/linux-event-codes.h b/include/dt-bindings/input/linux-event-codes.h
index 87cf351bab..331458c0e7 100644
--- a/include/dt-bindings/input/linux-event-codes.h
+++ b/include/dt-bindings/input/linux-event-codes.h
@@ -749,7 +749,8 @@
 #define SW_ROTATE_LOCK         0x0c  /* set = rotate locked/disabled */
 #define SW_LINEIN_INSERT       0x0d  /* set = inserted */
 #define SW_MUTE_DEVICE         0x0e  /* set = device disabled */
-#define SW_MAX                 0x0f
+#define SW_PEN_INSERTED                0x0f  /* set = pen inserted */
+#define SW_MAX                 0x10
 #define SW_CNT                 (SW_MAX+1)
 
 /*

rk3399-gru-kevin: issues on bringup

[Simon Glass]

Hi Marty,

On Sun, 19 Jul 2020 at 21:33, Marty E. Plummer <hanetzer@startmail.com> wrote:
>
> Greetings.
>
> I've been working on u-boot for rk3399-gru-kevin, Samsung Chromebook
> Plus. In theory it should be fairly similar to the Bob chromebook, and
> as such my work is largely based on it. Aside from some trivial changes,
> and adding chromebook_kevin_defconfig (direct copy of bob's config, with
> bob exchanged for kevin where apropriate) there is no major changes done
> (current diff at bottom).
>
> After building, I prepare the image like this:
>
> ===============
> $ ./tools/mkimage -n rk3399 -T rkspi -d spl/u-boot-spl.bin idbloader.img
> # 0x60000 chosen from doc/board/rockchip/rockchip.rst:187
> $ dd if=idbloader.img of=start bs=$((0x60000)) conv=sync count=1
> $ cat u-boot.itb >> start
> # 8mb spi flash
> $ dd if=start of=flash.bin bs=$((1024*1024*8)) conv=sync count=1
> ===============
>
> and flash it from within a chromeos dev env with a servo, like this:
> ===============
> # power down
> $ dut-control spi2_buf_en:on spi2_buf_on_flex_en:on spi2_vref:pp3300 cold_reset:on
> # flash
> $ sudo flashrom -V --programmer ft2232_spi:type=google-servo-v2 -w flash.bin
> # power up
> $ dut-control spi2_buf_en:off spi2_buf_on_flex_en:off spi2_vref:off cold_reset:off
> ===============
>
> But I do not get any more output than the following: (using the same ddr
> config as bob, as it matches what coreboot's source tree has listed
> during coreboot's bootup, to the best of my ability to tell.
> src/mainboard/google/gru/sdram_params/sdram-lpddr3-generic-4GB-928.c
>
> ===============
> Channel 0: LPDDR3, 933MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> Channel 1: LPDDR3, 933MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> 256B stride
> 256B stride
>
> U-Boot SPL 2020.07-10102-g1c4b5038af-dirty (Jul 19 2020 - 22:04:50 -0500)
> SPL: Unsupported Boot Device!
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
> ===============
>
> Unsure where to proceed from here. I notice that when bob was originally
> ported the chosen node had a u-boot,spl-boot-order property and the
> config node had u-boot,spl-payload-offset, which is no more, perhaps
> there is something to that?

Did you check spl_boot_device()?

Also take a look at the CONFIG_TARGET stuff in the code as it might
speciy BOB but not KEVIN.

Regards,
Simon

rk3399-gru-kevin: issues on bringup

[Marty E. Plummer]

On Tue, Jul 21, 2020 at 10:21:52AM -0600, Simon Glass wrote:
> Hi Marty,
> 
> Did you check spl_boot_device()?
> 
After sending the initial email I noticed your binman work, which does
some of the stuff I think I need. My current setup is as follows:

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index cee10f533f..0e3e1cc553 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -122,6 +122,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
 	rk3399-ficus.dtb \
 	rk3399-firefly.dtb \
 	rk3399-gru-bob.dtb \
+	rk3399-gru-kevin.dtb \
 	rk3399-khadas-edge.dtb \
 	rk3399-khadas-edge-captain.dtb \
 	rk3399-khadas-edge-v.dtb \
diff --git a/arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi b/arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi
new file mode 100644
index 0000000000..726f396f32
--- /dev/null
+++ b/arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki <jagan@amarulasolutions.com>
+ */
+
+#include "rk3399-gru-u-boot.dtsi"
+#include "rk3399-sdram-lpddr3-samsung-4GB-1866.dtsi"
diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig b/arch/arm/mach-rockchip/rk3399/Kconfig
index 17628f9171..851083cd8a 100644
--- a/arch/arm/mach-rockchip/rk3399/Kconfig
+++ b/arch/arm/mach-rockchip/rk3399/Kconfig
@@ -14,6 +14,11 @@ config TARGET_CHROMEBOOK_BOB
 	  display. It includes a Chrome OS EC (Cortex-M3) to provide access to
 	  the keyboard and battery functions.
 
+config TARGET_CHROMEBOOK_KEVIN
+	bool "Samsung Chromebook Plus (RK3399)"
+	select HAS_ROM
+	select ROCKCHIP_SPI_IMAGE
+
 config TARGET_EVB_RK3399
 	bool "RK3399 evaluation board"
 	help
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c
index 4fda93b152..92b418a9cf 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -117,7 +117,7 @@ void board_debug_uart_init(void)
 #define GPIO0_BASE	0xff720000
 #define PMUGRF_BASE	0xff320000
 	struct rk3399_grf_regs * const grf = (void *)GRF_BASE;
-#ifdef CONFIG_TARGET_CHROMEBOOK_BOB
+#if defined(CONFIG_TARGET_CHROMEBOOK_BOB) || defined(CONFIG_TARGET_CHROMEBOOK_KEVIN)
 	struct rk3399_pmugrf_regs * const pmugrf = (void *)PMUGRF_BASE;
 	struct rockchip_gpio_regs * const gpio = (void *)GPIO0_BASE;
 #endif
@@ -139,7 +139,7 @@ void board_debug_uart_init(void)
 		     GRF_GPIO3B7_SEL_MASK,
 		     GRF_UART3_SOUT << GRF_GPIO3B7_SEL_SHIFT);
 #else
-# ifdef CONFIG_TARGET_CHROMEBOOK_BOB
+# if defined(CONFIG_TARGET_CHROMEBOOK_BOB) || defined(CONFIG_TARGET_CHROMEBOOK_KEVIN)
 	rk_setreg(&grf->io_vsel, 1 << 0);
 
 	/*
diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
index f148d48b6a..a7a2bf10a1 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -55,7 +55,8 @@ u32 spl_boot_device(void)
 		defined(CONFIG_TARGET_CHROMEBIT_MICKEY) || \
 		defined(CONFIG_TARGET_CHROMEBOOK_MINNIE) || \
 		defined(CONFIG_TARGET_CHROMEBOOK_SPEEDY) || \
-		defined(CONFIG_TARGET_CHROMEBOOK_BOB)
+		defined(CONFIG_TARGET_CHROMEBOOK_BOB) || \
+		defined(CONFIG_TARGET_CHROMEBOOK_KEVIN)
 	return BOOT_DEVICE_SPI;
 #endif
 	if (CONFIG_IS_ENABLED(ROCKCHIP_BACK_TO_BROM))
diff --git a/board/google/gru/Kconfig b/board/google/gru/Kconfig
index 61f7bbca98..1455e1481d 100644
--- a/board/google/gru/Kconfig
+++ b/board/google/gru/Kconfig
@@ -13,3 +13,19 @@ config BOARD_SPECIFIC_OPTIONS # dummy
 	def_bool y
 
 endif
+
+if TARGET_CHROMEBOOK_KEVIN
+
+config SYS_BOARD
+	default "gru"
+
+config SYS_VENDOR
+	default "google"
+
+config SYS_CONFIG_NAME
+	default "gru"
+
+config BOARD_SPECIFIC_OPTIONS # dummy
+	def_bool y
+
+endif
diff --git a/board/google/gru/gru.c b/board/google/gru/gru.c
index 7dfbc3ac86..99ac658e32 100644
--- a/board/google/gru/gru.c
+++ b/board/google/gru/gru.c
@@ -14,7 +14,7 @@ void gru_dummy_function(int i)
 
 int board_early_init_f(void)
 {
-# ifdef CONFIG_TARGET_CHROMEBOOK_BOB
+# if defined(CONFIG_TARGET_CHROMEBOOK_BOB) || defined(CONFIG_TARGET_CHROMEBOOK_KEVIN)
 	int sum, i;
 
 	/*
diff --git a/configs/chromebook_kevin_defconfig b/configs/chromebook_kevin_defconfig
new file mode 100644
index 0000000000..ea975264b5
--- /dev/null
+++ b/configs/chromebook_kevin_defconfig
@@ -0,0 +1,82 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x00200000
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_ENV_OFFSET=0x3F8000
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x40000
+CONFIG_SPL_TEXT_BASE=0xff8c2000
+CONFIG_ROCKCHIP_RK3399=y
+CONFIG_ROCKCHIP_BOOT_MODE_REG=0
+CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
+# CONFIG_SPL_MMC_SUPPORT is not set
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEBUG_UART_BASE=0xff1a0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI_SUPPORT=y
+CONFIG_DEBUG_UART=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-gru-kevin"
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-kevin.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF_TEST=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_PMIC=y
+CONFIG_CMD_REGULATOR=y
+CONFIG_CMD_LOG=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_I2C_CROS_EC_TUNNEL=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_I2C_MUX=y
+CONFIG_DM_KEYBOARD=y
+CONFIG_CROS_EC_KEYB=y
+CONFIG_CROS_EC=y
+CONFIG_CROS_EC_SPI=y
+CONFIG_PWRSEQ=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_SF_DEFAULT_BUS=1
+CONFIG_SF_DEFAULT_SPEED=20000000
+CONFIG_SPI_FLASH_GIGADEVICE=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_ROCKCHIP_SPI=y
+CONFIG_SYSRESET=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_ETHER_MCS7830=y
+CONFIG_USB_ETHER_RTL8152=y
+CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_CMD_DHRYSTONE=y
+CONFIG_ERRNO_STR=y
diff --git a/include/dt-bindings/input/linux-event-codes.h b/include/dt-bindings/input/linux-event-codes.h
index 87cf351bab..331458c0e7 100644
--- a/include/dt-bindings/input/linux-event-codes.h
+++ b/include/dt-bindings/input/linux-event-codes.h
@@ -749,7 +749,8 @@
 #define SW_ROTATE_LOCK		0x0c  /* set = rotate locked/disabled */
 #define SW_LINEIN_INSERT	0x0d  /* set = inserted */
 #define SW_MUTE_DEVICE		0x0e  /* set = device disabled */
-#define SW_MAX			0x0f
+#define SW_PEN_INSERTED		0x0f  /* set = pen inserted */
+#define SW_MAX			0x10
 #define SW_CNT			(SW_MAX+1)
 
 /*

> Also take a look at the CONFIG_TARGET stuff in the code as it might
> speciy BOB but not KEVIN.
Yeah. I worked that in.

Currently, a rom which is built with these changes (assuming u-boot.rom
is what I want for SPI booting; strange its only 4mb, aren't these
devices 8mb flash?) I get no output at all over the servo, aside from
the EC.
> 
> Regards,
> Simon

rk3399-gru-kevin: issues on bringup

[Simon Glass]

Hi Marty,

On Tue, 21 Jul 2020 at 21:07, Marty E. Plummer <hanetzer@startmail.com> wrote:
>
> On Tue, Jul 21, 2020 at 10:21:52AM -0600, Simon Glass wrote:
> > Hi Marty,
> >
> > Did you check spl_boot_device()?
> >
> After sending the initial email I noticed your binman work, which does
> some of the stuff I think I need. My current setup is as follows:
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index cee10f533f..0e3e1cc553 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -122,6 +122,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
>         rk3399-ficus.dtb \
>         rk3399-firefly.dtb \
>         rk3399-gru-bob.dtb \
> +       rk3399-gru-kevin.dtb \
>         rk3399-khadas-edge.dtb \
>         rk3399-khadas-edge-captain.dtb \
>         rk3399-khadas-edge-v.dtb \
> diff --git a/arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi b/arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi
> new file mode 100644
> index 0000000000..726f396f32
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Jagan Teki <jagan@amarulasolutions.com>
> + */
> +
> +#include "rk3399-gru-u-boot.dtsi"
> +#include "rk3399-sdram-lpddr3-samsung-4GB-1866.dtsi"
> diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig b/arch/arm/mach-rockchip/rk3399/Kconfig
> index 17628f9171..851083cd8a 100644
> --- a/arch/arm/mach-rockchip/rk3399/Kconfig
> +++ b/arch/arm/mach-rockchip/rk3399/Kconfig
> @@ -14,6 +14,11 @@ config TARGET_CHROMEBOOK_BOB
>           display. It includes a Chrome OS EC (Cortex-M3) to provide access to
>           the keyboard and battery functions.
>
> +config TARGET_CHROMEBOOK_KEVIN
> +       bool "Samsung Chromebook Plus (RK3399)"
> +       select HAS_ROM
> +       select ROCKCHIP_SPI_IMAGE
> +
>  config TARGET_EVB_RK3399
>         bool "RK3399 evaluation board"
>         help
> diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c
> index 4fda93b152..92b418a9cf 100644
> --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> @@ -117,7 +117,7 @@ void board_debug_uart_init(void)
>  #define GPIO0_BASE     0xff720000
>  #define PMUGRF_BASE    0xff320000
>         struct rk3399_grf_regs * const grf = (void *)GRF_BASE;
> -#ifdef CONFIG_TARGET_CHROMEBOOK_BOB
> +#if defined(CONFIG_TARGET_CHROMEBOOK_BOB) || defined(CONFIG_TARGET_CHROMEBOOK_KEVIN)
>         struct rk3399_pmugrf_regs * const pmugrf = (void *)PMUGRF_BASE;
>         struct rockchip_gpio_regs * const gpio = (void *)GPIO0_BASE;
>  #endif
> @@ -139,7 +139,7 @@ void board_debug_uart_init(void)
>                      GRF_GPIO3B7_SEL_MASK,
>                      GRF_UART3_SOUT << GRF_GPIO3B7_SEL_SHIFT);
>  #else
> -# ifdef CONFIG_TARGET_CHROMEBOOK_BOB
> +# if defined(CONFIG_TARGET_CHROMEBOOK_BOB) || defined(CONFIG_TARGET_CHROMEBOOK_KEVIN)
>         rk_setreg(&grf->io_vsel, 1 << 0);
>
>         /*
> diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
> index f148d48b6a..a7a2bf10a1 100644
> --- a/arch/arm/mach-rockchip/spl.c
> +++ b/arch/arm/mach-rockchip/spl.c
> @@ -55,7 +55,8 @@ u32 spl_boot_device(void)
>                 defined(CONFIG_TARGET_CHROMEBIT_MICKEY) || \
>                 defined(CONFIG_TARGET_CHROMEBOOK_MINNIE) || \
>                 defined(CONFIG_TARGET_CHROMEBOOK_SPEEDY) || \
> -               defined(CONFIG_TARGET_CHROMEBOOK_BOB)
> +               defined(CONFIG_TARGET_CHROMEBOOK_BOB) || \
> +               defined(CONFIG_TARGET_CHROMEBOOK_KEVIN)
>         return BOOT_DEVICE_SPI;
>  #endif
>         if (CONFIG_IS_ENABLED(ROCKCHIP_BACK_TO_BROM))
> diff --git a/board/google/gru/Kconfig b/board/google/gru/Kconfig
> index 61f7bbca98..1455e1481d 100644
> --- a/board/google/gru/Kconfig
> +++ b/board/google/gru/Kconfig
> @@ -13,3 +13,19 @@ config BOARD_SPECIFIC_OPTIONS # dummy
>         def_bool y
>
>  endif
> +
> +if TARGET_CHROMEBOOK_KEVIN
> +
> +config SYS_BOARD
> +       default "gru"
> +
> +config SYS_VENDOR
> +       default "google"
> +
> +config SYS_CONFIG_NAME
> +       default "gru"
> +
> +config BOARD_SPECIFIC_OPTIONS # dummy
> +       def_bool y
> +
> +endif
> diff --git a/board/google/gru/gru.c b/board/google/gru/gru.c
> index 7dfbc3ac86..99ac658e32 100644
> --- a/board/google/gru/gru.c
> +++ b/board/google/gru/gru.c
> @@ -14,7 +14,7 @@ void gru_dummy_function(int i)
>
>  int board_early_init_f(void)
>  {
> -# ifdef CONFIG_TARGET_CHROMEBOOK_BOB
> +# if defined(CONFIG_TARGET_CHROMEBOOK_BOB) || defined(CONFIG_TARGET_CHROMEBOOK_KEVIN)
>         int sum, i;
>
>         /*
> diff --git a/configs/chromebook_kevin_defconfig b/configs/chromebook_kevin_defconfig
> new file mode 100644
> index 0000000000..ea975264b5
> --- /dev/null
> +++ b/configs/chromebook_kevin_defconfig
> @@ -0,0 +1,82 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_SYS_TEXT_BASE=0x00200000
> +CONFIG_SPL_GPIO_SUPPORT=y
> +CONFIG_ENV_OFFSET=0x3F8000
> +CONFIG_SYS_SPI_U_BOOT_OFFS=0x40000
> +CONFIG_SPL_TEXT_BASE=0xff8c2000
> +CONFIG_ROCKCHIP_RK3399=y
> +CONFIG_ROCKCHIP_BOOT_MODE_REG=0
> +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
> +# CONFIG_SPL_MMC_SUPPORT is not set
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_DEBUG_UART_BASE=0xff1a0000
> +CONFIG_DEBUG_UART_CLOCK=24000000
> +CONFIG_SPL_SPI_FLASH_SUPPORT=y
> +CONFIG_SPL_SPI_SUPPORT=y
> +CONFIG_DEBUG_UART=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-gru-kevin"
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-kevin.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
> +CONFIG_SPL_SPI_LOAD=y
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_I2C=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF_TEST=y
> +CONFIG_CMD_SPI=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_CMD_PMIC=y
> +CONFIG_CMD_REGULATOR=y
> +CONFIG_CMD_LOG=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> +CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_SPL_DM_SEQ_ALIAS=y
> +CONFIG_ROCKCHIP_GPIO=y
> +CONFIG_I2C_CROS_EC_TUNNEL=y
> +CONFIG_SYS_I2C_ROCKCHIP=y
> +CONFIG_I2C_MUX=y
> +CONFIG_DM_KEYBOARD=y
> +CONFIG_CROS_EC_KEYB=y
> +CONFIG_CROS_EC=y
> +CONFIG_CROS_EC_SPI=y
> +CONFIG_PWRSEQ=y
> +CONFIG_MMC_DW=y
> +CONFIG_MMC_DW_ROCKCHIP=y
> +CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_ROCKCHIP=y
> +CONFIG_SF_DEFAULT_BUS=1
> +CONFIG_SF_DEFAULT_SPEED=20000000
> +CONFIG_SPI_FLASH_GIGADEVICE=y
> +CONFIG_DM_ETH=y
> +CONFIG_ETH_DESIGNWARE=y
> +CONFIG_GMAC_ROCKCHIP=y
> +CONFIG_PMIC_RK8XX=y
> +CONFIG_REGULATOR_PWM=y
> +CONFIG_REGULATOR_RK8XX=y
> +CONFIG_PWM_ROCKCHIP=y
> +CONFIG_DEBUG_UART_SHIFT=2
> +CONFIG_ROCKCHIP_SPI=y
> +CONFIG_SYSRESET=y
> +CONFIG_USB=y
> +CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_DWC3=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_GENERIC=y
> +CONFIG_USB_HOST_ETHER=y
> +CONFIG_USB_ETHER_ASIX=y
> +CONFIG_USB_ETHER_ASIX88179=y
> +CONFIG_USB_ETHER_MCS7830=y
> +CONFIG_USB_ETHER_RTL8152=y
> +CONFIG_USB_ETHER_SMSC95XX=y
> +CONFIG_CMD_DHRYSTONE=y
> +CONFIG_ERRNO_STR=y
> diff --git a/include/dt-bindings/input/linux-event-codes.h b/include/dt-bindings/input/linux-event-codes.h
> index 87cf351bab..331458c0e7 100644
> --- a/include/dt-bindings/input/linux-event-codes.h
> +++ b/include/dt-bindings/input/linux-event-codes.h
> @@ -749,7 +749,8 @@
>  #define SW_ROTATE_LOCK         0x0c  /* set = rotate locked/disabled */
>  #define SW_LINEIN_INSERT       0x0d  /* set = inserted */
>  #define SW_MUTE_DEVICE         0x0e  /* set = device disabled */
> -#define SW_MAX                 0x0f
> +#define SW_PEN_INSERTED                0x0f  /* set = pen inserted */
> +#define SW_MAX                 0x10
>  #define SW_CNT                 (SW_MAX+1)
>
>  /*
>
> > Also take a look at the CONFIG_TARGET stuff in the code as it might
> > speciy BOB but not KEVIN.
> Yeah. I worked that in.
>
> Currently, a rom which is built with these changes (assuming u-boot.rom
> is what I want for SPI booting; strange its only 4mb, aren't these
> devices 8mb flash?) I get no output at all over the servo, aside from
> the EC.

I think it is only 4MB.

I am not sure that I have a kevin. Did you try using the debug UART?

Regards,
Simon

rk3399-gru-kevin: issues on bringup

[Marty E. Plummer]

On Tue, Jul 28, 2020 at 12:58:30PM -0600, Simon Glass wrote:
> Hi Marty,
> 
> On Tue, 21 Jul 2020 at 21:07, Marty E. Plummer <hanetzer@startmail.com> wrote:
> >
> > On Tue, Jul 21, 2020 at 10:21:52AM -0600, Simon Glass wrote:
> > > Hi Marty,
> > >
> > > Did you check spl_boot_device()?
> > >
> > After sending the initial email I noticed your binman work, which does
> > some of the stuff I think I need. My current setup is as follows:
> >
> >
> > > Also take a look at the CONFIG_TARGET stuff in the code as it might
> > > speciy BOB but not KEVIN.
> > Yeah. I worked that in.
> >
> > Currently, a rom which is built with these changes (assuming u-boot.rom
> > is what I want for SPI booting; strange its only 4mb, aren't these
> > devices 8mb flash?) I get no output at all over the servo, aside from
> > the EC.
> 
> I think it is only 4MB.
> 
Nah, kevin is deffo 8mb flash chip. Otherwise I wouldn't have been able
to shove a 7.xmb kernel+initramfs into a coreboot image and flash it.

I have to pad the u-boot.rom with dd to flash it.
> I am not sure that I have a kevin. Did you try using the debug UART?
> 
Yeah, assuming you mean `dut-control cpu_uart_pty` with a servo hooked
up, and using `socat READLINE /dev/pts/something`. I get no output, but
the same chromiumos chroot with vanilla coreboot+depthcharge and
hardware config does do output as expected.

Perhaps I'm missing something simple.
> Regards,
> Simon

rk3399-gru-kevin: issues on bringup

[Simon Glass]

Hi Marty,

On Fri, 31 Jul 2020 at 05:19, Marty E. Plummer <hanetzer@startmail.com> wrote:
>
> On Tue, Jul 28, 2020 at 12:58:30PM -0600, Simon Glass wrote:
> > Hi Marty,
> >
> > On Tue, 21 Jul 2020 at 21:07, Marty E. Plummer <hanetzer@startmail.com> wrote:
> > >
> > > On Tue, Jul 21, 2020 at 10:21:52AM -0600, Simon Glass wrote:
> > > > Hi Marty,
> > > >
> > > > Did you check spl_boot_device()?
> > > >
> > > After sending the initial email I noticed your binman work, which does
> > > some of the stuff I think I need. My current setup is as follows:
> > >
> > >
> > > > Also take a look at the CONFIG_TARGET stuff in the code as it might
> > > > speciy BOB but not KEVIN.
> > > Yeah. I worked that in.
> > >
> > > Currently, a rom which is built with these changes (assuming u-boot.rom
> > > is what I want for SPI booting; strange its only 4mb, aren't these
> > > devices 8mb flash?) I get no output at all over the servo, aside from
> > > the EC.
> >
> > I think it is only 4MB.
> >
> Nah, kevin is deffo 8mb flash chip. Otherwise I wouldn't have been able
> to shove a 7.xmb kernel+initramfs into a coreboot image and flash it.

Well that's odd. Maybe Kevin got a larger device than gru?

>
> I have to pad the u-boot.rom with dd to flash it.
> > I am not sure that I have a kevin. Did you try using the debug UART?
> >
> Yeah, assuming you mean `dut-control cpu_uart_pty` with a servo hooked
> up, and using `socat READLINE /dev/pts/something`. I get no output, but
> the same chromiumos chroot with vanilla coreboot+depthcharge and
> hardware config does do output as expected.
>
> Perhaps I'm missing something simple.

Probably, it often is. But what?!

I actually just found some old Chromebooks I didn't know i had, so I
have a Kevin. If you push your tree somewhere I might be able to take
a look this weekend.

Regards,
Simon

rk3399-gru-kevin: issues on bringup

[Simon Glass]

Hi Marty,

On Fri, 31 Jul 2020 at 12:30, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Marty,
>
> On Fri, 31 Jul 2020 at 05:19, Marty E. Plummer <hanetzer@startmail.com> wrote:
> >
> > On Tue, Jul 28, 2020 at 12:58:30PM -0600, Simon Glass wrote:
> > > Hi Marty,
> > >
> > > On Tue, 21 Jul 2020 at 21:07, Marty E. Plummer <hanetzer@startmail.com> wrote:
> > > >
> > > > On Tue, Jul 21, 2020 at 10:21:52AM -0600, Simon Glass wrote:
> > > > > Hi Marty,
> > > > >
> > > > > Did you check spl_boot_device()?
> > > > >
> > > > After sending the initial email I noticed your binman work, which does
> > > > some of the stuff I think I need. My current setup is as follows:
> > > >
> > > >
> > > > > Also take a look at the CONFIG_TARGET stuff in the code as it might
> > > > > speciy BOB but not KEVIN.
> > > > Yeah. I worked that in.
> > > >
> > > > Currently, a rom which is built with these changes (assuming u-boot.rom
> > > > is what I want for SPI booting; strange its only 4mb, aren't these
> > > > devices 8mb flash?) I get no output at all over the servo, aside from
> > > > the EC.
> > >
> > > I think it is only 4MB.
> > >
> > Nah, kevin is deffo 8mb flash chip. Otherwise I wouldn't have been able
> > to shove a 7.xmb kernel+initramfs into a coreboot image and flash it.
>
> Well that's odd. Maybe Kevin got a larger device than gru?
>
> >
> > I have to pad the u-boot.rom with dd to flash it.
> > > I am not sure that I have a kevin. Did you try using the debug UART?
> > >
> > Yeah, assuming you mean `dut-control cpu_uart_pty` with a servo hooked
> > up, and using `socat READLINE /dev/pts/something`. I get no output, but
> > the same chromiumos chroot with vanilla coreboot+depthcharge and
> > hardware config does do output as expected.
> >
> > Perhaps I'm missing something simple.
>
> Probably, it often is. But what?!
>
> I actually just found some old Chromebooks I didn't know i had, so I
> have a Kevin. If you push your tree somewhere I might be able to take
> a look this weekend.

I dug this out but I cannot get it to boot with the em100 emulator.
I'll see if I can figure that out at some point. Sometimes I get
serial garbage as well.

It is surprising that the flash is 8MB when Gru is 4MB. Must have run
out of room.

Regards,
Simon

rk3399-gru-kevin: issues on bringup

[Simon Glass]

Hi Marty,

On Sun, 2 Aug 2020 at 21:02, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Marty,
>
> On Fri, 31 Jul 2020 at 12:30, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Marty,
> >
> > On Fri, 31 Jul 2020 at 05:19, Marty E. Plummer <hanetzer@startmail.com> wrote:
> > >
> > > On Tue, Jul 28, 2020 at 12:58:30PM -0600, Simon Glass wrote:
> > > > Hi Marty,
> > > >
> > > > On Tue, 21 Jul 2020 at 21:07, Marty E. Plummer <hanetzer@startmail.com> wrote:
> > > > >
> > > > > On Tue, Jul 21, 2020 at 10:21:52AM -0600, Simon Glass wrote:
> > > > > > Hi Marty,
> > > > > >
> > > > > > Did you check spl_boot_device()?
> > > > > >
> > > > > After sending the initial email I noticed your binman work, which does
> > > > > some of the stuff I think I need. My current setup is as follows:
> > > > >
> > > > >
> > > > > > Also take a look at the CONFIG_TARGET stuff in the code as it might
> > > > > > speciy BOB but not KEVIN.
> > > > > Yeah. I worked that in.
> > > > >
> > > > > Currently, a rom which is built with these changes (assuming u-boot.rom
> > > > > is what I want for SPI booting; strange its only 4mb, aren't these
> > > > > devices 8mb flash?) I get no output at all over the servo, aside from
> > > > > the EC.
> > > >
> > > > I think it is only 4MB.
> > > >
> > > Nah, kevin is deffo 8mb flash chip. Otherwise I wouldn't have been able
> > > to shove a 7.xmb kernel+initramfs into a coreboot image and flash it.
> >
> > Well that's odd. Maybe Kevin got a larger device than gru?
> >
> > >
> > > I have to pad the u-boot.rom with dd to flash it.
> > > > I am not sure that I have a kevin. Did you try using the debug UART?
> > > >
> > > Yeah, assuming you mean `dut-control cpu_uart_pty` with a servo hooked
> > > up, and using `socat READLINE /dev/pts/something`. I get no output, but
> > > the same chromiumos chroot with vanilla coreboot+depthcharge and
> > > hardware config does do output as expected.
> > >
> > > Perhaps I'm missing something simple.
> >
> > Probably, it often is. But what?!
> >
> > I actually just found some old Chromebooks I didn't know i had, so I
> > have a Kevin. If you push your tree somewhere I might be able to take
> > a look this weekend.
>
> I dug this out but I cannot get it to boot with the em100 emulator.
> I'll see if I can figure that out at some point. Sometimes I get
> serial garbage as well.
>
> It is surprising that the flash is 8MB when Gru is 4MB. Must have run
> out of room.

Also I pushed the tree with your changes and one of mine here:

https://github.com/sjg20/u-boot/tree/kevin

Regards,
SImon

rk3399-gru-kevin: issues on bringup

[Simon Glass]

Hi Marty,

On Mon, 3 Aug 2020 at 07:49, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Marty,
>
> On Sun, 2 Aug 2020 at 21:02, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Marty,
> >
> > On Fri, 31 Jul 2020 at 12:30, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Marty,
> > >
> > > On Fri, 31 Jul 2020 at 05:19, Marty E. Plummer <hanetzer@startmail.com> wrote:
> > > >
> > > > On Tue, Jul 28, 2020 at 12:58:30PM -0600, Simon Glass wrote:
> > > > > Hi Marty,
> > > > >
> > > > > On Tue, 21 Jul 2020 at 21:07, Marty E. Plummer <hanetzer@startmail.com> wrote:
> > > > > >
> > > > > > On Tue, Jul 21, 2020 at 10:21:52AM -0600, Simon Glass wrote:
> > > > > > > Hi Marty,
> > > > > > >
> > > > > > > Did you check spl_boot_device()?
> > > > > > >
> > > > > > After sending the initial email I noticed your binman work, which does
> > > > > > some of the stuff I think I need. My current setup is as follows:
> > > > > >
> > > > > >
> > > > > > > Also take a look at the CONFIG_TARGET stuff in the code as it might
> > > > > > > speciy BOB but not KEVIN.
> > > > > > Yeah. I worked that in.
> > > > > >
> > > > > > Currently, a rom which is built with these changes (assuming u-boot.rom
> > > > > > is what I want for SPI booting; strange its only 4mb, aren't these
> > > > > > devices 8mb flash?) I get no output at all over the servo, aside from
> > > > > > the EC.
> > > > >
> > > > > I think it is only 4MB.
> > > > >
> > > > Nah, kevin is deffo 8mb flash chip. Otherwise I wouldn't have been able
> > > > to shove a 7.xmb kernel+initramfs into a coreboot image and flash it.
> > >
> > > Well that's odd. Maybe Kevin got a larger device than gru?
> > >
> > > >
> > > > I have to pad the u-boot.rom with dd to flash it.
> > > > > I am not sure that I have a kevin. Did you try using the debug UART?
> > > > >
> > > > Yeah, assuming you mean `dut-control cpu_uart_pty` with a servo hooked
> > > > up, and using `socat READLINE /dev/pts/something`. I get no output, but
> > > > the same chromiumos chroot with vanilla coreboot+depthcharge and
> > > > hardware config does do output as expected.
> > > >
> > > > Perhaps I'm missing something simple.
> > >
> > > Probably, it often is. But what?!
> > >
> > > I actually just found some old Chromebooks I didn't know i had, so I
> > > have a Kevin. If you push your tree somewhere I might be able to take
> > > a look this weekend.
> >
> > I dug this out but I cannot get it to boot with the em100 emulator.
> > I'll see if I can figure that out at some point. Sometimes I get
> > serial garbage as well.
> >
> > It is surprising that the flash is 8MB when Gru is 4MB. Must have run
> > out of room.
>
> Also I pushed the tree with your changes and one of mine here:
>
> https://github.com/sjg20/u-boot/tree/kevin

Well I don't know why the em100 doesn't work, but apparently it never did.

Anyway the image seems to jump into ATF first, then to U-Boot SPL. So
perhaps the problem is in ATF. From what I can tell, it prints about
10 characters of junk before it starts setting up SDRAM. Perhaps it
has a clock wrong.

In any case, it should be possible to jump directly into U-Boot SPL
and hopefully the debug UART works. Can you try that, perhaps by
building an image without ATF?

Regards,
SImon

rk3399-gru-kevin: issues on bringup

[Marty E. Plummer]

On Mon, Aug 03, 2020 at 08:13:38PM -0600, Simon Glass wrote:
> Hi Marty,
> 
> On Mon, 3 Aug 2020 at 07:49, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Marty,
> >
> > On Sun, 2 Aug 2020 at 21:02, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Marty,
> > >
> > >
> > > I dug this out but I cannot get it to boot with the em100 emulator.
> > > I'll see if I can figure that out at some point. Sometimes I get
> > > serial garbage as well.
> > >
> > > It is surprising that the flash is 8MB when Gru is 4MB. Must have run
> > > out of room.
> >
> > Also I pushed the tree with your changes and one of mine here:
> >
> > https://github.com/sjg20/u-boot/tree/kevin
> 
> Well I don't know why the em100 doesn't work, but apparently it never did.
> 
> Anyway the image seems to jump into ATF first, then to U-Boot SPL. So
> perhaps the problem is in ATF. From what I can tell, it prints about
> 10 characters of junk before it starts setting up SDRAM. Perhaps it
> has a clock wrong.
> 
> In any case, it should be possible to jump directly into U-Boot SPL
> and hopefully the debug UART works. Can you try that, perhaps by
> building an image without ATF?
> 
Sure, though I'm not certain how that even works, I don't recall
explicitly setting that up. Just to put goals out there, my plan is
to falcon-mode load a kernel and petitboot for use with 'normal'
distros.
> Regards,
> SImon

rk3399-gru-kevin: issues on bringup

[Alper Nebi Yasak]

Hi Simon, Marty,

I'm interested in getting U-Boot to work with Kevin as well, but don't 
have a Servo (or the willingness to open up the case yet), so I've been 
trying to boot from depthcharge as in README.chromium-chainload.

I don't have a way to see serial output and I see no other signs of 
life. Can you give me a tested configuration that immediately powers-off 
or reboots a Kevin so I can confirm what I'm doing works on the 
chainloading side? I mean I can boot Linux, but trying the same with 
U-Boot just gives me a blank screen even after accounting for a lot of 
things.

Meanwhile, I've wrote some code to automate making depthcharge partition 
images, and to enable the display on Kevin (and perhaps Bob). Since I 
don't know if chainloading works, I don't know if these are broken or 
not either. I'm unsure about sending untested patches to the list, so I 
put them up here if you want to take a look (and maybe test/fix them?):

https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip

They're not really things that'd make a non-booting Kevin boot, though. 
I hope at least some of it can be useful in some way.

rk3399-gru-kevin: issues on bringup

[Simon Glass]

Hi Marty,

On Thu, 13 Aug 2020 at 13:35, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>
> Hi Simon, Marty,
>
> I'm interested in getting U-Boot to work with Kevin as well, but don't
> have a Servo (or the willingness to open up the case yet), so I've been
> trying to boot from depthcharge as in README.chromium-chainload.
>
> I don't have a way to see serial output and I see no other signs of
> life. Can you give me a tested configuration that immediately powers-off
> or reboots a Kevin so I can confirm what I'm doing works on the
> chainloading side? I mean I can boot Linux, but trying the same with
> U-Boot just gives me a blank screen even after accounting for a lot of
> things.
>
> Meanwhile, I've wrote some code to automate making depthcharge partition
> images, and to enable the display on Kevin (and perhaps Bob). Since I
> don't know if chainloading works, I don't know if these are broken or
> not either. I'm unsure about sending untested patches to the list, so I
> put them up here if you want to take a look (and maybe test/fix them?):
>
> https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip
>
> They're not really things that'd make a non-booting Kevin boot, though.
> I hope at least some of it can be useful in some way.

I am just replying here as you asked for some details on IRC. What
details do you need?

I was intending to try out a kevin if I have one. I will add that to my list.

Regards,
Simon

rk3399-gru-kevin: issues on bringup

[Marty E. Plummer]

On Tue, Feb 23, 2021 at 10:10:11AM -0500, Simon Glass wrote:
> Hi Marty,
> 
> On Thu, 13 Aug 2020 at 13:35, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
> >
> > Hi Simon, Marty,
> >
> > I'm interested in getting U-Boot to work with Kevin as well, but don't
> > have a Servo (or the willingness to open up the case yet), so I've been
> > trying to boot from depthcharge as in README.chromium-chainload.
> >
> > I don't have a way to see serial output and I see no other signs of
> > life. Can you give me a tested configuration that immediately powers-off
> > or reboots a Kevin so I can confirm what I'm doing works on the
> > chainloading side? I mean I can boot Linux, but trying the same with
> > U-Boot just gives me a blank screen even after accounting for a lot of
> > things.
> >
> > Meanwhile, I've wrote some code to automate making depthcharge partition
> > images, and to enable the display on Kevin (and perhaps Bob). Since I
> > don't know if chainloading works, I don't know if these are broken or
> > not either. I'm unsure about sending untested patches to the list, so I
> > put them up here if you want to take a look (and maybe test/fix them?):
> >
> > https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip
> >
> > They're not really things that'd make a non-booting Kevin boot, though.
> > I hope at least some of it can be useful in some way.
> 
> I am just replying here as you asked for some details on IRC. What
> details do you need?
> 
Well, if its possible to actually do openocd/etc on the AP using a
servo, I'd like to know how. All the documentation I could find is about
using openocd to flash the EC, not debug the AP.
> I was intending to try out a kevin if I have one. I will add that to my list.
> 
> Regards,
> Simon

rk3399-gru-kevin: issues on bringup

[Simon Glass]

Hi Marty,

On Tue, 23 Feb 2021 at 16:36, Marty E. Plummer <hanetzer@startmail.com> wrote:
>
> On Tue, Feb 23, 2021 at 10:10:11AM -0500, Simon Glass wrote:
> > Hi Marty,
> >
> > On Thu, 13 Aug 2020 at 13:35, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
> > >
> > > Hi Simon, Marty,
> > >
> > > I'm interested in getting U-Boot to work with Kevin as well, but don't
> > > have a Servo (or the willingness to open up the case yet), so I've been
> > > trying to boot from depthcharge as in README.chromium-chainload.
> > >
> > > I don't have a way to see serial output and I see no other signs of
> > > life. Can you give me a tested configuration that immediately powers-off
> > > or reboots a Kevin so I can confirm what I'm doing works on the
> > > chainloading side? I mean I can boot Linux, but trying the same with
> > > U-Boot just gives me a blank screen even after accounting for a lot of
> > > things.
> > >
> > > Meanwhile, I've wrote some code to automate making depthcharge partition
> > > images, and to enable the display on Kevin (and perhaps Bob). Since I
> > > don't know if chainloading works, I don't know if these are broken or
> > > not either. I'm unsure about sending untested patches to the list, so I
> > > put them up here if you want to take a look (and maybe test/fix them?):
> > >
> > > https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip
> > >
> > > They're not really things that'd make a non-booting Kevin boot, though.
> > > I hope at least some of it can be useful in some way.
> >
> > I am just replying here as you asked for some details on IRC. What
> > details do you need?
> >
> Well, if its possible to actually do openocd/etc on the AP using a
> servo, I'd like to know how. All the documentation I could find is about
> using openocd to flash the EC, not debug the AP.

OK...in my case I attached a ARM DSTREAM JTAG unit to the 20-pin
connector on the servo 2 board. I was then able to connect and debug
U-Boot and linux. This was on a snow (Samsung exynos) so not the same
SoC, but it might work. I can't recall the clock speed, but it
certainly was slower than 200MHz.

This has some info:

https://elinux.org/images/7/7f/Manderson5.pdf

Here are the instructions I wrote, from the history as they have been
removed from the page, being so out of date!

https://sites.google.com/a/google.com/chromeos/system/app/pages/admin/compare?wuid=wuid:gx:300e7216a93e8403&rev1=29

> > I was intending to try out a kevin if I have one. I will add that to my list.

Regards,
Simon

rk3399-gru-kevin: issues on bringup

[Marty E. Plummer]

On Wed, Feb 24, 2021 at 11:31:05AM -0500, Simon Glass wrote:
> Hi Marty,
> 
> On Tue, 23 Feb 2021 at 16:36, Marty E. Plummer <hanetzer@startmail.com> wrote:
> >
> > On Tue, Feb 23, 2021 at 10:10:11AM -0500, Simon Glass wrote:
> > > Hi Marty,
> > >
> > > On Thu, 13 Aug 2020 at 13:35, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
> > > >
> > > > Hi Simon, Marty,
> > > >
> > > > I'm interested in getting U-Boot to work with Kevin as well, but don't
> > > > have a Servo (or the willingness to open up the case yet), so I've been
> > > > trying to boot from depthcharge as in README.chromium-chainload.
> > > >
> > > > I don't have a way to see serial output and I see no other signs of
> > > > life. Can you give me a tested configuration that immediately powers-off
> > > > or reboots a Kevin so I can confirm what I'm doing works on the
> > > > chainloading side? I mean I can boot Linux, but trying the same with
> > > > U-Boot just gives me a blank screen even after accounting for a lot of
> > > > things.
> > > >
> > > > Meanwhile, I've wrote some code to automate making depthcharge partition
> > > > images, and to enable the display on Kevin (and perhaps Bob). Since I
> > > > don't know if chainloading works, I don't know if these are broken or
> > > > not either. I'm unsure about sending untested patches to the list, so I
> > > > put them up here if you want to take a look (and maybe test/fix them?):
> > > >
> > > > https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip
> > > >
> > > > They're not really things that'd make a non-booting Kevin boot, though.
> > > > I hope at least some of it can be useful in some way.
> > >
> > > I am just replying here as you asked for some details on IRC. What
> > > details do you need?
> > >
> > Well, if its possible to actually do openocd/etc on the AP using a
> > servo, I'd like to know how. All the documentation I could find is about
> > using openocd to flash the EC, not debug the AP.
> 
> OK...in my case I attached a ARM DSTREAM JTAG unit to the 20-pin
> connector on the servo 2 board. I was then able to connect and debug
> U-Boot and linux. This was on a snow (Samsung exynos) so not the same
> SoC, but it might work. I can't recall the clock speed, but it
> certainly was slower than 200MHz.
> 
Ok, I thought it may be something like that. I have a flyswatter2 which
should work.
> This has some info:
> 
> https://elinux.org/images/7/7f/Manderson5.pdf
> 
> Here are the instructions I wrote, from the history as they have been
> removed from the page, being so out of date!
> 
> https://sites.google.com/a/google.com/chromeos/system/app/pages/admin/compare?wuid=wuid:gx:300e7216a93e8403&rev1=29
> 
Beh. I can't view this page, 'You need permission\nSwitch to an account
with permission."
> > > I was intending to try out a kevin if I have one. I will add that to my list.
> 
> Regards,
> Simon

rk3399-gru-kevin: issues on bringup

[Simon Glass]

Hi,

On Thu, 13 Aug 2020 at 13:35, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>
> Hi Simon, Marty,
>
> I'm interested in getting U-Boot to work with Kevin as well, but don't
> have a Servo (or the willingness to open up the case yet), so I've been
> trying to boot from depthcharge as in README.chromium-chainload.
>
> I don't have a way to see serial output and I see no other signs of
> life. Can you give me a tested configuration that immediately powers-off
> or reboots a Kevin so I can confirm what I'm doing works on the
> chainloading side? I mean I can boot Linux, but trying the same with
> U-Boot just gives me a blank screen even after accounting for a lot of
> things.
>
> Meanwhile, I've wrote some code to automate making depthcharge partition
> images, and to enable the display on Kevin (and perhaps Bob). Since I
> don't know if chainloading works, I don't know if these are broken or
> not either. I'm unsure about sending untested patches to the list, so I
> put them up here if you want to take a look (and maybe test/fix them?):
>
> https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip
>
> They're not really things that'd make a non-booting Kevin boot, though.
> I hope at least some of it can be useful in some way.

I have the em100 working and have got to the same point as you, Marty.

em100 -s -c gd25lq64 -d /tmp/b/chromebook_kevin/u-boot.rom -r

So I suppose that means that SDRAM is running and we just need a SPI
driver? I will see if I can figure out what is missing...

Update...it seems to just be missing the ID. I pushed a new patch to:

https://github.com/sjg20/u-boot/tree/kevin

Now I see:

Channel 0: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride

U-Boot SPL 2020.10-rc1-00111-gc31b9b4a3f1-dirty (Mar 10 2021 - 21:48:26 -0700)
Trying to boot from SPI


U-Boot 2020.10-rc1-00111-gc31b9b4a3f1-dirty (Mar 10 2021 - 21:48:26 -0700)

Model: Google Kevin
DRAM:  3.9 GiB
Cannot find regulator pwm init_voltage
MMC:   mmc at fe320000: 1, sdhci at fe330000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

Got rc -1, expected 100
Failed to probe keyboard 'keyboard-controller'
In:    serial at ff1a0000
Out:   serial at ff1a0000
Err:   serial at ff1a0000
Model: Google Kevin
Net:   No ethernet found.
Hit any key to stop autoboot:  0
=>

No display and various errors on the way up, but at least it boots to a prompt.

Regards,
Simon

rk3399-gru-kevin: issues on bringup

[Marty E. Plummer]

On Wed, Mar 10, 2021 at 11:52:07PM -0500, Simon Glass wrote:
> Hi,
> 
> On Thu, 13 Aug 2020 at 13:35, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
> >
> > Hi Simon, Marty,
> >
> > I'm interested in getting U-Boot to work with Kevin as well, but don't
> > have a Servo (or the willingness to open up the case yet), so I've been
> > trying to boot from depthcharge as in README.chromium-chainload.
> >
> > I don't have a way to see serial output and I see no other signs of
> > life. Can you give me a tested configuration that immediately powers-off
> > or reboots a Kevin so I can confirm what I'm doing works on the
> > chainloading side? I mean I can boot Linux, but trying the same with
> > U-Boot just gives me a blank screen even after accounting for a lot of
> > things.
> >
> > Meanwhile, I've wrote some code to automate making depthcharge partition
> > images, and to enable the display on Kevin (and perhaps Bob). Since I
> > don't know if chainloading works, I don't know if these are broken or
> > not either. I'm unsure about sending untested patches to the list, so I
> > put them up here if you want to take a look (and maybe test/fix them?):
> >
> > https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip
> >
> > They're not really things that'd make a non-booting Kevin boot, though.
> > I hope at least some of it can be useful in some way.
> 
> I have the em100 working and have got to the same point as you, Marty.
> 
> em100 -s -c gd25lq64 -d /tmp/b/chromebook_kevin/u-boot.rom -r
> 
> So I suppose that means that SDRAM is running and we just need a SPI
> driver? I will see if I can figure out what is missing...
> 
> Update...it seems to just be missing the ID. I pushed a new patch to:
> 
Christ, its always something small and stupid. Perhaps the failure
message should be amended to indicate 'unknown jedec id: %x' or so to be
a bit more informative.
> https://github.com/sjg20/u-boot/tree/kevin
> 
This looks promising. Built it (away from the machine right now so can't
test) and it seems that u-boot-rockchip.bin is just a bit too large to
be flashed (8.8mb)? Or judging by your above em100 invocation this image
is not to be used? If so, why is it produced at all?
> Now I see:
> 
> Channel 0: LPDDR3, 933MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> Channel 1: LPDDR3, 933MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> 256B stride
> 
> U-Boot SPL 2020.10-rc1-00111-gc31b9b4a3f1-dirty (Mar 10 2021 - 21:48:26 -0700)
> Trying to boot from SPI
> 
> 
> U-Boot 2020.10-rc1-00111-gc31b9b4a3f1-dirty (Mar 10 2021 - 21:48:26 -0700)
> 
> Model: Google Kevin
> DRAM:  3.9 GiB
> Cannot find regulator pwm init_voltage
> MMC:   mmc at fe320000: 1, sdhci at fe330000: 0
> Loading Environment from MMC... *** Warning - bad CRC, using default environment
> 
> Got rc -1, expected 100
> Failed to probe keyboard 'keyboard-controller'
> In:    serial at ff1a0000
> Out:   serial at ff1a0000
> Err:   serial at ff1a0000
> Model: Google Kevin
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> =>
> 
> No display and various errors on the way up, but at least it boots to a prompt.
> 
A much better situation then before. I'll pull your changes into my tree
and see what can be done with it.
> Regards,
> Simon

rk3399-gru-kevin: issues on bringup

[Simon Glass]

Hi Marty,

On Sat, 13 Mar 2021 at 12:40, Marty E. Plummer <hanetzer@startmail.com> wrote:
>
> On Wed, Mar 10, 2021 at 11:52:07PM -0500, Simon Glass wrote:
> > Hi,
> >
> > On Thu, 13 Aug 2020 at 13:35, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
> > >
> > > Hi Simon, Marty,
> > >
> > > I'm interested in getting U-Boot to work with Kevin as well, but don't
> > > have a Servo (or the willingness to open up the case yet), so I've been
> > > trying to boot from depthcharge as in README.chromium-chainload.
> > >
> > > I don't have a way to see serial output and I see no other signs of
> > > life. Can you give me a tested configuration that immediately powers-off
> > > or reboots a Kevin so I can confirm what I'm doing works on the
> > > chainloading side? I mean I can boot Linux, but trying the same with
> > > U-Boot just gives me a blank screen even after accounting for a lot of
> > > things.
> > >
> > > Meanwhile, I've wrote some code to automate making depthcharge partition
> > > images, and to enable the display on Kevin (and perhaps Bob). Since I
> > > don't know if chainloading works, I don't know if these are broken or
> > > not either. I'm unsure about sending untested patches to the list, so I
> > > put them up here if you want to take a look (and maybe test/fix them?):
> > >
> > > https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip
> > >
> > > They're not really things that'd make a non-booting Kevin boot, though.
> > > I hope at least some of it can be useful in some way.
> >
> > I have the em100 working and have got to the same point as you, Marty.
> >
> > em100 -s -c gd25lq64 -d /tmp/b/chromebook_kevin/u-boot.rom -r
> >
> > So I suppose that means that SDRAM is running and we just need a SPI
> > driver? I will see if I can figure out what is missing...
> >
> > Update...it seems to just be missing the ID. I pushed a new patch to:
> >
> Christ, its always something small and stupid. Perhaps the failure
> message should be amended to indicate 'unknown jedec id: %x' or so to be
> a bit more informative.

It doesn't do that because it is the SPL 'tiny' version.

> > https://github.com/sjg20/u-boot/tree/kevin
> >
> This looks promising. Built it (away from the machine right now so can't
> test) and it seems that u-boot-rockchip.bin is just a bit too large to
> be flashed (8.8mb)? Or judging by your above em100 invocation this image
> is not to be used? If so, why is it produced at all?

I think it is for booting from eMMC. But I am booting from SPI flash.

> > Now I see:
> >
> > Channel 0: LPDDR3, 933MHz
> > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> > Channel 1: LPDDR3, 933MHz
> > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> > 256B stride
> >
> > U-Boot SPL 2020.10-rc1-00111-gc31b9b4a3f1-dirty (Mar 10 2021 - 21:48:26 -0700)
> > Trying to boot from SPI
> >
> >
> > U-Boot 2020.10-rc1-00111-gc31b9b4a3f1-dirty (Mar 10 2021 - 21:48:26 -0700)
> >
> > Model: Google Kevin
> > DRAM:  3.9 GiB
> > Cannot find regulator pwm init_voltage
> > MMC:   mmc at fe320000: 1, sdhci at fe330000: 0
> > Loading Environment from MMC... *** Warning - bad CRC, using default environment
> >
> > Got rc -1, expected 100
> > Failed to probe keyboard 'keyboard-controller'
> > In:    serial at ff1a0000
> > Out:   serial at ff1a0000
> > Err:   serial at ff1a0000
> > Model: Google Kevin
> > Net:   No ethernet found.
> > Hit any key to stop autoboot:  0
> > =>
> >
> > No display and various errors on the way up, but at least it boots to a prompt.
> >
> A much better situation then before. I'll pull your changes into my tree
> and see what can be done with it.

OK. I added a little patch to fix the EC as well

Regards,
Simon

Re: rk3399-gru-kevin: issues on bringup

[Alper Nebi Yasak]

Hi,

I've had some recent success with my gru-kevin and wanted to update you
on this. Long story short, I can boot from SPI flash and have the
display, keyboard, eMMC, microSD card, USB disks all work (however with
some hacks); but can't boot into Linux. Things seem to hang shortly
after "Starting kernel..." but I don't know if something fails in U-Boot
or if I get a kernel panic. (I still have no serial console).

There are three relevant branches on my GitHub repo now, please have a
look. The first is for what I intend to send upstream soon enough. The
other two include hacks and additional patches that build on top of the
first, meant to improve things on a per-board basis:

    https://github.com/alpernebbi/u-boot/tree/rk3399-gru-chromebooks
    https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin
    https://github.com/alpernebbi/u-boot/tree/rk3399-gru-bob

I have no idea if the gru-bob versions work. I just thought things I did
for gru-kevin are applicable to it as well and decided I should include
them in case anyone wants to test.


I also want to ask you some things I'm indecisive about, before posting
the rk3399-gru-chromebooks branch as patches.

Most of the patches are small config and dts changes that I've grouped
by whatever effect they have. Should I squash them into one commit each
for config/dts?

Simon, I've edited some of your patches and kept you as author &
sign-off. Are you OK with the edited versions, am I doing things right? See:


https://github.com/alpernebbi/u-boot/commit/8c658b7811f4324cd699bd035e802f9339efa8f7

https://github.com/alpernebbi/u-boot/commit/c2c68f23e10a51b8d34c00764a33fc847d785f60

https://github.com/alpernebbi/u-boot/commit/995454193906e04bfb4e0e38f2bf1a18634a1ebf

Marty, your (second) chromebook_kevin support patch didn't have your
sign-off. Is it OK to add it? See:


https://github.com/alpernebbi/u-boot/commit/4cee351e012dc26714640e868069b5cc4b5a8329

I also think I should squash my gru-kevin changes into that commit, add
a commit message about board status, and keep Marty as author & sign-off
while adding myself as Co-authored-by & sign-off. Any better ideas on
how to structure the patches?

Do both of you want to be in /board/google/gru/MAINTAINERS? I have three
of us listed there right now, but no idea if that's fine with you two.

Hope you can spare time on this.

Re: rk3399-gru-kevin: issues on bringup

[Peter Robinson]

On Mon, Nov 1, 2021 at 11:25 PM Alper Nebi Yasak
<alpernebiyasak@gmail.com> wrote:
>
> Hi,
>
> I've had some recent success with my gru-kevin and wanted to update you
> on this. Long story short, I can boot from SPI flash and have the
> display, keyboard, eMMC, microSD card, USB disks all work (however with
> some hacks); but can't boot into Linux. Things seem to hang shortly
> after "Starting kernel..." but I don't know if something fails in U-Boot
> or if I get a kernel panic. (I still have no serial console).

I suspect you need the following patch [1], we had the same hang in
Fedora and even with a serial console and a whole bunch of kernel
debug it was difficult to get to the bottom of. Sadly the fix, whether
this patch or another one is still not upstream.

[1] http://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-icenowy@aosc.io/

> There are three relevant branches on my GitHub repo now, please have a
> look. The first is for what I intend to send upstream soon enough. The
> other two include hacks and additional patches that build on top of the
> first, meant to improve things on a per-board basis:
>
>     https://github.com/alpernebbi/u-boot/tree/rk3399-gru-chromebooks
>     https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin
>     https://github.com/alpernebbi/u-boot/tree/rk3399-gru-bob
>
> I have no idea if the gru-bob versions work. I just thought things I did
> for gru-kevin are applicable to it as well and decided I should include
> them in case anyone wants to test.
>
>
> I also want to ask you some things I'm indecisive about, before posting
> the rk3399-gru-chromebooks branch as patches.
>
> Most of the patches are small config and dts changes that I've grouped
> by whatever effect they have. Should I squash them into one commit each
> for config/dts?
>
> Simon, I've edited some of your patches and kept you as author &
> sign-off. Are you OK with the edited versions, am I doing things right? See:
>
>
> https://github.com/alpernebbi/u-boot/commit/8c658b7811f4324cd699bd035e802f9339efa8f7
>
> https://github.com/alpernebbi/u-boot/commit/c2c68f23e10a51b8d34c00764a33fc847d785f60
>
> https://github.com/alpernebbi/u-boot/commit/995454193906e04bfb4e0e38f2bf1a18634a1ebf
>
> Marty, your (second) chromebook_kevin support patch didn't have your
> sign-off. Is it OK to add it? See:
>
>
> https://github.com/alpernebbi/u-boot/commit/4cee351e012dc26714640e868069b5cc4b5a8329
>
> I also think I should squash my gru-kevin changes into that commit, add
> a commit message about board status, and keep Marty as author & sign-off
> while adding myself as Co-authored-by & sign-off. Any better ideas on
> how to structure the patches?
>
> Do both of you want to be in /board/google/gru/MAINTAINERS? I have three
> of us listed there right now, but no idea if that's fine with you two.
>
> Hope you can spare time on this.

Re: rk3399-gru-kevin: issues on bringup

[Alper Nebi Yasak]

On 02/11/2021 11:09, Peter Robinson wrote:
> On Mon, Nov 1, 2021 at 11:25 PM Alper Nebi Yasak
> <alpernebiyasak@gmail.com> wrote:
>> some hacks); but can't boot into Linux. Things seem to hang shortly
>> after "Starting kernel..." but I don't know if something fails in U-Boot
>> or if I get a kernel panic. (I still have no serial console).
> 
> I suspect you need the following patch [1], we had the same hang in
> Fedora and even with a serial console and a whole bunch of kernel
> debug it was difficult to get to the bottom of. Sadly the fix, whether
> this patch or another one is still not upstream.
> 
> [1] http://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-icenowy@aosc.io/

I already had this patch in the gru-kevin branch because it solves a
hang in the coreboot -> depthcharge -> U-Boot -> Linux-on-USB chain,
thanks for the pointer though :)

This problem I'm seeing now appears to be something else, but I have no
idea as to what it could be. Since that chain works I assume I should
look more into what coreboot/depthcharge does...

Re: rk3399-gru-kevin: issues on bringup

[Simon Glass]

Hi Alpher,

On Mon, 1 Nov 2021 at 17:25, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>
> Hi,
>
> I've had some recent success with my gru-kevin and wanted to update you
> on this. Long story short, I can boot from SPI flash and have the
> display, keyboard, eMMC, microSD card, USB disks all work (however with
> some hacks); but can't boot into Linux. Things seem to hang shortly
> after "Starting kernel..." but I don't know if something fails in U-Boot
> or if I get a kernel panic. (I still have no serial console).
>
> There are three relevant branches on my GitHub repo now, please have a
> look. The first is for what I intend to send upstream soon enough. The
> other two include hacks and additional patches that build on top of the
> first, meant to improve things on a per-board basis:
>
>     https://github.com/alpernebbi/u-boot/tree/rk3399-gru-chromebooks
>     https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin
>     https://github.com/alpernebbi/u-boot/tree/rk3399-gru-bob
>
> I have no idea if the gru-bob versions work. I just thought things I did
> for gru-kevin are applicable to it as well and decided I should include
> them in case anyone wants to test.
>
>
> I also want to ask you some things I'm indecisive about, before posting
> the rk3399-gru-chromebooks branch as patches.
>
> Most of the patches are small config and dts changes that I've grouped
> by whatever effect they have. Should I squash them into one commit each
> for config/dts?

Probably best.

>
> Simon, I've edited some of your patches and kept you as author &
> sign-off. Are you OK with the edited versions, am I doing things right? See:
>
>
> https://github.com/alpernebbi/u-boot/commit/8c658b7811f4324cd699bd035e802f9339efa8f7
>
> https://github.com/alpernebbi/u-boot/commit/c2c68f23e10a51b8d34c00764a33fc847d785f60
>
> https://github.com/alpernebbi/u-boot/commit/995454193906e04bfb4e0e38f2bf1a18634a1ebf

LGTM

>
> Marty, your (second) chromebook_kevin support patch didn't have your
> sign-off. Is it OK to add it? See:
>
>
> https://github.com/alpernebbi/u-boot/commit/4cee351e012dc26714640e868069b5cc4b5a8329
>
> I also think I should squash my gru-kevin changes into that commit, add
> a commit message about board status, and keep Marty as author & sign-off
> while adding myself as Co-authored-by & sign-off. Any better ideas on
> how to structure the patches?
>
> Do both of you want to be in /board/google/gru/MAINTAINERS? I have three
> of us listed there right now, but no idea if that's fine with you two.
>
> Hope you can spare time on this.

I actually have bob in my lab but I have not tried the Chrome OS boot
script on it. I could probably add kevin.

$ do-try-int.sh bob
Revision 77680d8f85b94ffe690b8fe1f35767aef8b1415a, board bob

Checking revision 77680d8f85b94ffe690b8fe1f35767aef8b1415a
/vid/software/devel/ubtest
tbot starting ...
├─Parameters:
│     rev        = '77680d8f85b94ffe690b8fe1f35767aef8b1415a'
│     clean      = False
├─Calling uboot_build_and_flash ...
│   ├─bob is on port 9904 and uses /dev/pts/39
│   ├─POWERON (bob)
│   ├─Calling uboot_build ...
│   │   ├─Calling uboot_checkout ...
│   │   │   ├─Builder: bob
│   │   │   └─Done. (1.038s)
│   │   ├─Configuring build ...
│   │   ├─Calling uboot_make ...
│   │   │   └─Done. (9.073s)
│   │   └─Done. (10.454s)
│   ├─Calling uboot_flash ...
│   │   └─Done. (0.677s)
│   ├─POWEROFF (bob)
│   └─Done. (11.868s)
├─────────────────────────────────────────
└─SUCCESS (11.994s)
tbot starting ...
├─Calling interactive_board ...
│   ├─bob is on port 9904 and uses /dev/pts/39
│   ├─POWERON (bob)
│   ├─Entering interactive shell (CTRL+D to exit) ...
�Channel 0: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride

U-Boot SPL 2021.10-00181-g77680d8f85b (Nov 02 2021 - 09:07:44 -0600)
Trying to boot from SPI
rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full:
uclass_get_device_by_phandle_id: err=-19
rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full:
uclass_get_device_by_phandle_id: err=-19
ns16550_serial serial@ff1a0000: pinctrl_select_state_full:
uclass_get_device_by_phandle_id: err=-19


U-Boot 2021.10-00181-g77680d8f85b (Nov 02 2021 - 09:07:44 -0600)

Model: Google Bob
DRAM:  3.9 GiB
Cannot find regulator pwm init_voltage
MMC:   mmc@fe320000: 1, mmc@fe330000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

Got rc -1, expected 100
Failed to probe keyboard 'keyboard-controller'
In:    serial@ff1a0000
Out:   serial@ff1a0000
Err:   serial@ff1a0000
Model: Google Bob
Net:   No ethernet found.
Hit any key to stop autoboot:  0
=>

Regards,
Simon

Re: rk3399-gru-kevin: issues on bringup

[Simon Glass]

Hi Alper,

On Tue, 2 Nov 2021 at 17:05, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Alpher,
>
> On Mon, 1 Nov 2021 at 17:25, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
> >
> > Hi,
> >
> > I've had some recent success with my gru-kevin and wanted to update you
> > on this. Long story short, I can boot from SPI flash and have the
> > display, keyboard, eMMC, microSD card, USB disks all work (however with
> > some hacks); but can't boot into Linux. Things seem to hang shortly
> > after "Starting kernel..." but I don't know if something fails in U-Boot
> > or if I get a kernel panic. (I still have no serial console).
> >
> > There are three relevant branches on my GitHub repo now, please have a
> > look. The first is for what I intend to send upstream soon enough. The
> > other two include hacks and additional patches that build on top of the
> > first, meant to improve things on a per-board basis:
> >
> >     https://github.com/alpernebbi/u-boot/tree/rk3399-gru-chromebooks
> >     https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin
> >     https://github.com/alpernebbi/u-boot/tree/rk3399-gru-bob
> >
> > I have no idea if the gru-bob versions work. I just thought things I did
> > for gru-kevin are applicable to it as well and decided I should include
> > them in case anyone wants to test.
> >
> >
> > I also want to ask you some things I'm indecisive about, before posting
> > the rk3399-gru-chromebooks branch as patches.
> >
> > Most of the patches are small config and dts changes that I've grouped
> > by whatever effect they have. Should I squash them into one commit each
> > for config/dts?
>
> Probably best.
>
> >
> > Simon, I've edited some of your patches and kept you as author &
> > sign-off. Are you OK with the edited versions, am I doing things right? See:
> >
> >
> > https://github.com/alpernebbi/u-boot/commit/8c658b7811f4324cd699bd035e802f9339efa8f7
> >
> > https://github.com/alpernebbi/u-boot/commit/c2c68f23e10a51b8d34c00764a33fc847d785f60
> >
> > https://github.com/alpernebbi/u-boot/commit/995454193906e04bfb4e0e38f2bf1a18634a1ebf
>
> LGTM
>
> >
> > Marty, your (second) chromebook_kevin support patch didn't have your
> > sign-off. Is it OK to add it? See:
> >
> >
> > https://github.com/alpernebbi/u-boot/commit/4cee351e012dc26714640e868069b5cc4b5a8329
> >
> > I also think I should squash my gru-kevin changes into that commit, add
> > a commit message about board status, and keep Marty as author & sign-off
> > while adding myself as Co-authored-by & sign-off. Any better ideas on
> > how to structure the patches?
> >
> > Do both of you want to be in /board/google/gru/MAINTAINERS? I have three
> > of us listed there right now, but no idea if that's fine with you two.
> >
> > Hope you can spare time on this.
>
> I actually have bob in my lab but I have not tried the Chrome OS boot
> script on it. I could probably add kevin.
>
> $ do-try-int.sh bob
> Revision 77680d8f85b94ffe690b8fe1f35767aef8b1415a, board bob
>
> Checking revision 77680d8f85b94ffe690b8fe1f35767aef8b1415a
> /vid/software/devel/ubtest
> tbot starting ...
> ├─Parameters:
> │     rev        = '77680d8f85b94ffe690b8fe1f35767aef8b1415a'
> │     clean      = False
> ├─Calling uboot_build_and_flash ...
> │   ├─bob is on port 9904 and uses /dev/pts/39
> │   ├─POWERON (bob)
> │   ├─Calling uboot_build ...
> │   │   ├─Calling uboot_checkout ...
> │   │   │   ├─Builder: bob
> │   │   │   └─Done. (1.038s)
> │   │   ├─Configuring build ...
> │   │   ├─Calling uboot_make ...
> │   │   │   └─Done. (9.073s)
> │   │   └─Done. (10.454s)
> │   ├─Calling uboot_flash ...
> │   │   └─Done. (0.677s)
> │   ├─POWEROFF (bob)
> │   └─Done. (11.868s)
> ├─────────────────────────────────────────
> └─SUCCESS (11.994s)
> tbot starting ...
> ├─Calling interactive_board ...
> │   ├─bob is on port 9904 and uses /dev/pts/39
> │   ├─POWERON (bob)
> │   ├─Entering interactive shell (CTRL+D to exit) ...
> �Channel 0: LPDDR3, 933MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> Channel 1: LPDDR3, 933MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> 256B stride
>
> U-Boot SPL 2021.10-00181-g77680d8f85b (Nov 02 2021 - 09:07:44 -0600)
> Trying to boot from SPI
> rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full:
> uclass_get_device_by_phandle_id: err=-19
> rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full:
> uclass_get_device_by_phandle_id: err=-19
> ns16550_serial serial@ff1a0000: pinctrl_select_state_full:
> uclass_get_device_by_phandle_id: err=-19
>
>
> U-Boot 2021.10-00181-g77680d8f85b (Nov 02 2021 - 09:07:44 -0600)
>
> Model: Google Bob
> DRAM:  3.9 GiB
> Cannot find regulator pwm init_voltage
> MMC:   mmc@fe320000: 1, mmc@fe330000: 0
> Loading Environment from MMC... *** Warning - bad CRC, using default environment
>
> Got rc -1, expected 100
> Failed to probe keyboard 'keyboard-controller'
> In:    serial@ff1a0000
> Out:   serial@ff1a0000
> Err:   serial@ff1a0000
> Model: Google Bob
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> =>

Just to note that I have a kevin in my lab now and it boots into
U-Boot with your

https://github.com/alpernebbi/u-boot/tree/rk3399-gru-chromebooks

I also tried Bob and got this:

$ do-try-int.sh bob
Revision 6a549d02fc43408cf4f000cc97688e7a64948572, board bob

Checking revision 6a549d02fc43408cf4f000cc97688e7a64948572
/vid/software/devel/ubtest
tbot starting ...
├─Parameters:
│     rev        = '6a549d02fc43408cf4f000cc97688e7a64948572'
│     clean      = False
├─Calling uboot_build_and_flash ...
│   ├─bob is on port 9904 and uses /dev/pts/37
│   ├─POWERON (bob)
│   ├─Calling uboot_build ...
│   │   ├─Calling uboot_checkout ...
│   │   │   ├─Builder: bob
│   │   │   └─Done. (0.195s)
│   │   ├─Configuring build ...
│   │   ├─Calling uboot_make ...
│   │   │   └─Done. (9.943s)
│   │   └─Done. (10.329s)
│   ├─Calling uboot_flash ...
│   │   └─Done. (2.209s)
│   ├─POWEROFF (bob)
│   └─Done. (13.305s)
├─────────────────────────────────────────
└─SUCCESS (13.438s)
tbot starting ...
├─Calling interactive_board ...
│   ├─bob is on port 9904 and uses /dev/pts/37
│   ├─POWERON (bob)
│   ├─Entering interactive shell (CTRL+D to exit) ...
Channel 0: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride

U-Boot SPL 2021.10-00036-g6a549d02fc4 (Nov 05 2021 - 21:12:30 -0600)
Trying to boot from SPI
rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full:
uclass_get_device_by_phandle_id: err=-19
rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full:
uclass_get_device_by_phandle_id: err=-19
ns16550_serial serial@ff1a0000: pinctrl_select_state_full:
uclass_get_device_by_phandle_id: err=-19


U-Boot 2021.10-00036-g6a549d02fc4 (Nov 05 2021 - 21:12:30 -0600)

Model: Google Bob
DRAM:  3.9 GiB
MMC:   mmc@fe320000: 1, mmc@fe330000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    cros-ec-keyb
Out:   vidconsole
Err:   vidconsole
Model: Google Bob
Net:   No ethernet found.
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:c...
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Scanning disk mmc@fe320000.blk...
Disk mmc@fe320000.blk not ready
Scanning disk mmc@fe330000.blk...
fs_devread read outside partition 2
Failed to mount ext2 filesystem...
fs_devread read outside partition 2
Failed to mount ext2 filesystem...
fs_devread read outside partition 2
Failed to mount ext2 filesystem...
fs_devread read outside partition 2
Failed to mount ext2 filesystem...
Found 13 disks
** Unable to read file ubootefi.var **
Failed to load EFI variables
BootOrder not defined
EFI boot manager: Cannot load any image
starting USB...
Bus usb@fe380000: USB EHCI 1.00
Bus usb@fe3a0000: USB OHCI 1.0
Bus usb@fe3c0000: USB EHCI 1.00
Bus usb@fe3e0000: USB OHCI 1.0
Bus usb@fe800000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus usb@fe900000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe380000 for devices... 2 USB Device(s) found
scanning bus usb@fe3a0000 for devices... 1 USB Device(s) found
scanning bus usb@fe3c0000 for devices... 2 USB Device(s) found
scanning bus usb@fe3e0000 for devices... 1 USB Device(s) found
scanning bus usb@fe800000 for devices... 1 USB Device(s) found
scanning bus usb@fe900000 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

Device 0: unknown device
No ethernet found.
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-rk3399-gru
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-rk3399
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
No ethernet found.
Config file not found
No ethernet found.
No ethernet found.
SF: Detected gd25lq32 with page size 256 Bytes, erase size 4 KiB, total 4 MiB
Offset exceeds device limit
sf - SPI flash sub-system

Usage:
sf probe [[bus:]cs] [hz] [mode] - init flash device on given SPI bus
  and chip select
sf read addr offset|partition len - read `len' bytes starting at
          `offset' or from start of mtd
  `partition'to memory at `addr'
sf write addr offset|partition len - write `len' bytes from memory
          at `addr' to flash at `offset'
  or to start of mtd `partition'
sf erase offset|partition [+]len - erase `len' bytes from `offset'
  or from start of mtd `partition'
`+len' round up `len' to block size
sf update addr offset|partition len - erase and write `len' bytes from memory
  at `addr' to flash at `offset'
  or to start of mtd `partition'
sf protect lock/unlock sector len - protect/unprotect 'len' bytes starting
  at address 'sector'

sf test offset len - run a very basic destructive test
## Executing script at 00500000
Wrong image format for "source" command
SCRIPT FAILED: continuing...
=>

Having both in my lab will make it much easier to test.

Regards,
Simon

Re: rk3399-gru-kevin: issues on bringup

[Alper Nebi Yasak]

On 06/11/2021 06:16, Simon Glass wrote:
> On Tue, 2 Nov 2021 at 17:05, Simon Glass <sjg@chromium.org> wrote:
>> On Mon, 1 Nov 2021 at 17:25, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>>> Most of the patches are small config and dts changes that I've grouped
>>> by whatever effect they have. Should I squash them into one commit each
>>> for config/dts?
>>
>> Probably best.

I did so and updated the branches, now the series goes like this:

  rockchip: gru: Set up SoC IO domain registers
  rockchip: gru: Add more devicetree settings
  rockchip: bob: Enable more configs
  rockchip: rk3399: Add support for chromebook_kevin

>>> Marty, your (second) chromebook_kevin support patch didn't have your
>>> sign-off. Is it OK to add it? See:

I still didn't add a sign-off for this patch. There is an earlier
version with one [1]. I'm not sure if I can add the sign-off citing
that, or send the patches without a sign-off. I guess I'll wait a bit
more for a reply?

[1] https://patchwork.ozlabs.org/patch/1053386/

>> I actually have bob in my lab but I have not tried the Chrome OS boot
>> script on it. I could probably add kevin.

Booting the Chrome OS way would be an interesting experiment. I might
eventually work on it, but not exactly a priority for me right now
unless if it makes it easier for you to test things on these boards :D .

>> $ do-try-int.sh bob
>> Revision 77680d8f85b94ffe690b8fe1f35767aef8b1415a, board bob

(I notice this was on a recent u-boot/master instead of my branch)

> Just to note that I have a kevin in my lab now and it boots into
> U-Boot with your
> 
> https://github.com/alpernebbi/u-boot/tree/rk3399-gru-chromebooks
> 
> I also tried Bob and got this:
> 
> $ do-try-int.sh bob
> Revision 6a549d02fc43408cf4f000cc97688e7a64948572, board bob
> 
> Checking revision 6a549d02fc43408cf4f000cc97688e7a64948572
> /vid/software/devel/ubtest
> tbot starting ...
> ├─Parameters:
> │     rev        = '6a549d02fc43408cf4f000cc97688e7a64948572'
> │     clean      = False
> ├─Calling uboot_build_and_flash ...
> │   ├─bob is on port 9904 and uses /dev/pts/37
> │   ├─POWERON (bob)
> │   ├─Calling uboot_build ...
> │   │   ├─Calling uboot_checkout ...
> │   │   │   ├─Builder: bob
> │   │   │   └─Done. (0.195s)
> │   │   ├─Configuring build ...
> │   │   ├─Calling uboot_make ...
> │   │   │   └─Done. (9.943s)
> │   │   └─Done. (10.329s)
> │   ├─Calling uboot_flash ...
> │   │   └─Done. (2.209s)
> │   ├─POWEROFF (bob)
> │   └─Done. (13.305s)
> ├─────────────────────────────────────────
> └─SUCCESS (13.438s)
> tbot starting ...
> ├─Calling interactive_board ...
> │   ├─bob is on port 9904 and uses /dev/pts/37
> │   ├─POWERON (bob)
> │   ├─Entering interactive shell (CTRL+D to exit) ...
> Channel 0: LPDDR3, 933MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> Channel 1: LPDDR3, 933MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> 256B stride
> 
> U-Boot SPL 2021.10-00036-g6a549d02fc4 (Nov 05 2021 - 21:12:30 -0600)
> Trying to boot from SPI
> rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full:
> uclass_get_device_by_phandle_id: err=-19
> rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full:
> uclass_get_device_by_phandle_id: err=-19
> ns16550_serial serial@ff1a0000: pinctrl_select_state_full:
> uclass_get_device_by_phandle_id: err=-19

I have a feeling that this is because the SPL devicetree filters out
pinctrl subnodes while some other included nodes might be referring to
those. That might be what's causing the same messages in sandbox as well...

> U-Boot 2021.10-00036-g6a549d02fc4 (Nov 05 2021 - 21:12:30 -0600)
> 
> Model: Google Bob
> DRAM:  3.9 GiB
> MMC:   mmc@fe320000: 1, mmc@fe330000: 0
> Loading Environment from MMC... *** Warning - bad CRC, using default environment
> 
> In:    cros-ec-keyb
> Out:   vidconsole
> Err:   vidconsole
> Model: Google Bob
> Net:   No ethernet found.

Could you manually confirm that the display and keyboard works?

> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0(part 0) is current device
> Scanning mmc 0:c...
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> Scanning disk mmc@fe320000.blk...
> Disk mmc@fe320000.blk not ready
> Scanning disk mmc@fe330000.blk...
> fs_devread read outside partition 2
> Failed to mount ext2 filesystem...
> fs_devread read outside partition 2
> Failed to mount ext2 filesystem...
> fs_devread read outside partition 2
> Failed to mount ext2 filesystem...
> fs_devread read outside partition 2
> Failed to mount ext2 filesystem...
> Found 13 disks
> [...]
> =>

This starts with mmc1 (microSD card) for me and gives an error for mmc0
(eMMC) which I have to prevent with a hack to skip its re-init. Nice to
see that Bob doesn't need that. Other than that I see the same output
with Chrome OS installed on eMMC.

I would greatly appreciate it if you could try booting into any Linux
really, to have some logs of what goes wrong while doing so. Debian's
installer images [2] should be somewhat working on Kevin/Bob.
Booting after USB is initialized requires a patch [3] to fix a hang though.

[2]
https://deb.debian.org/debian/dists/bullseye/main/installer-arm64/current/images/netboot/gtk/SD-card-images/

[3]
https://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-icenowy@aosc.io/

> Having both in my lab will make it much easier to test.

Thanks for the tests so far!

Re: rk3399-gru-kevin: issues on bringup

[Simon Glass]

Hi Alper,

On Sun, 7 Nov 2021 at 10:26, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>
> On 06/11/2021 06:16, Simon Glass wrote:
> > On Tue, 2 Nov 2021 at 17:05, Simon Glass <sjg@chromium.org> wrote:
> >> On Mon, 1 Nov 2021 at 17:25, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
> >>> Most of the patches are small config and dts changes that I've grouped
> >>> by whatever effect they have. Should I squash them into one commit each
> >>> for config/dts?
> >>
> >> Probably best.
>
> I did so and updated the branches, now the series goes like this:
>
>   rockchip: gru: Set up SoC IO domain registers
>   rockchip: gru: Add more devicetree settings
>   rockchip: bob: Enable more configs
>   rockchip: rk3399: Add support for chromebook_kevin
>
> >>> Marty, your (second) chromebook_kevin support patch didn't have your
> >>> sign-off. Is it OK to add it? See:
>
> I still didn't add a sign-off for this patch. There is an earlier
> version with one [1]. I'm not sure if I can add the sign-off citing
> that, or send the patches without a sign-off. I guess I'll wait a bit
> more for a reply?
>
> [1] https://patchwork.ozlabs.org/patch/1053386/
>
> >> I actually have bob in my lab but I have not tried the Chrome OS boot
> >> script on it. I could probably add kevin.
>
> Booting the Chrome OS way would be an interesting experiment. I might
> eventually work on it, but not exactly a priority for me right now
> unless if it makes it easier for you to test things on these boards :D .
>
> >> $ do-try-int.sh bob
> >> Revision 77680d8f85b94ffe690b8fe1f35767aef8b1415a, board bob
>
> (I notice this was on a recent u-boot/master instead of my branch)
>
> > Just to note that I have a kevin in my lab now and it boots into
> > U-Boot with your
> >
> > https://github.com/alpernebbi/u-boot/tree/rk3399-gru-chromebooks
> >
> > I also tried Bob and got this:
> >
> > $ do-try-int.sh bob
> > Revision 6a549d02fc43408cf4f000cc97688e7a64948572, board bob
> >
> > Checking revision 6a549d02fc43408cf4f000cc97688e7a64948572
> > /vid/software/devel/ubtest
> > tbot starting ...
> > ├─Parameters:
> > │     rev        = '6a549d02fc43408cf4f000cc97688e7a64948572'
> > │     clean      = False
> > ├─Calling uboot_build_and_flash ...
> > │   ├─bob is on port 9904 and uses /dev/pts/37
> > │   ├─POWERON (bob)
> > │   ├─Calling uboot_build ...
> > │   │   ├─Calling uboot_checkout ...
> > │   │   │   ├─Builder: bob
> > │   │   │   └─Done. (0.195s)
> > │   │   ├─Configuring build ...
> > │   │   ├─Calling uboot_make ...
> > │   │   │   └─Done. (9.943s)
> > │   │   └─Done. (10.329s)
> > │   ├─Calling uboot_flash ...
> > │   │   └─Done. (2.209s)
> > │   ├─POWEROFF (bob)
> > │   └─Done. (13.305s)
> > ├─────────────────────────────────────────
> > └─SUCCESS (13.438s)
> > tbot starting ...
> > ├─Calling interactive_board ...
> > │   ├─bob is on port 9904 and uses /dev/pts/37
> > │   ├─POWERON (bob)
> > │   ├─Entering interactive shell (CTRL+D to exit) ...
> > Channel 0: LPDDR3, 933MHz
> > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> > Channel 1: LPDDR3, 933MHz
> > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> > 256B stride
> >
> > U-Boot SPL 2021.10-00036-g6a549d02fc4 (Nov 05 2021 - 21:12:30 -0600)
> > Trying to boot from SPI
> > rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full:
> > uclass_get_device_by_phandle_id: err=-19
> > rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full:
> > uclass_get_device_by_phandle_id: err=-19
> > ns16550_serial serial@ff1a0000: pinctrl_select_state_full:
> > uclass_get_device_by_phandle_id: err=-19
>
> I have a feeling that this is because the SPL devicetree filters out
> pinctrl subnodes while some other included nodes might be referring to
> those. That might be what's causing the same messages in sandbox as well...
>
> > U-Boot 2021.10-00036-g6a549d02fc4 (Nov 05 2021 - 21:12:30 -0600)
> >
> > Model: Google Bob
> > DRAM:  3.9 GiB
> > MMC:   mmc@fe320000: 1, mmc@fe330000: 0
> > Loading Environment from MMC... *** Warning - bad CRC, using default environment
> >
> > In:    cros-ec-keyb
> > Out:   vidconsole
> > Err:   vidconsole
> > Model: Google Bob
> > Net:   No ethernet found.
>
> Could you manually confirm that the display and keyboard works?
>
> > Hit any key to stop autoboot:  0
> > switch to partitions #0, OK
> > mmc0(part 0) is current device
> > Scanning mmc 0:c...
> > libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> > Scanning disk mmc@fe320000.blk...
> > Disk mmc@fe320000.blk not ready
> > Scanning disk mmc@fe330000.blk...
> > fs_devread read outside partition 2
> > Failed to mount ext2 filesystem...
> > fs_devread read outside partition 2
> > Failed to mount ext2 filesystem...
> > fs_devread read outside partition 2
> > Failed to mount ext2 filesystem...
> > fs_devread read outside partition 2
> > Failed to mount ext2 filesystem...
> > Found 13 disks
> > [...]
> > =>
>
> This starts with mmc1 (microSD card) for me and gives an error for mmc0
> (eMMC) which I have to prevent with a hack to skip its re-init. Nice to
> see that Bob doesn't need that. Other than that I see the same output
> with Chrome OS installed on eMMC.
>
> I would greatly appreciate it if you could try booting into any Linux
> really, to have some logs of what goes wrong while doing so. Debian's
> installer images [2] should be somewhat working on Kevin/Bob.
> Booting after USB is initialized requires a patch [3] to fix a hang though.
>
> [2]
> https://deb.debian.org/debian/dists/bullseye/main/installer-arm64/current/images/netboot/gtk/SD-card-images/
>
> [3]
> https://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-icenowy@aosc.io/
>
> > Having both in my lab will make it much easier to test.
>
> Thanks for the tests so far!

Are you going to send your patches?

I haven't got as far as booting into Linux, nor trying some other
kernel, but we should get these patches in...

Regards,
Simon

Re: rk3399-gru-kevin: issues on bringup

[Alper Nebi Yasak]

On 25/11/2021 03:12, Simon Glass wrote:
> On Sun, 7 Nov 2021 at 10:26, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>> I did so and updated the branches, now the series goes like this:
>>
>>   rockchip: gru: Set up SoC IO domain registers
>>   rockchip: gru: Add more devicetree settings
>>   rockchip: bob: Enable more configs
>>   rockchip: rk3399: Add support for chromebook_kevin
>>
>> [...]
> 
> Are you going to send your patches?
> 
> I haven't got as far as booting into Linux, nor trying some other
> kernel, but we should get these patches in...

I got sidetracked while waiting for a reply from Marty... I'll send them
now and hope for the best.