[PATCH 0/4] rockchip: Improve support for Bob chromebook and add support for Kevin
I have recently started testing booting U-Boot from SPI on my gru-kevin (as opposed to chainloading it from vendor coreboot + depthcharge) and brought it to a better working state based on an initial support patch from Marty [1][2] and some follow-up work by Simon [3].
I tried to keep them as the git author when I took things from their work, but squashing other changes into those and rewriting commit messages makes things a bit weird in my opinion, especially for keeping their signoff. Do tell me if there is a better way to that.
As the Kevin and Bob boards are very similar. I assumed the config and devicetree changes will be appropriate for Bob as well, and applied them to it first. I do not have a Bob, so could not test on one myself, but Simon did test an earlier version of this and it appears to work [4].
Other useful things for these boards: - Patch to fix a hang when usb controllers exit [5] - Series to support HS400ES mode as HS400 training fails [6] - Hack to skip eMMC reinitialization so it keeps working [7]
[1] https://patchwork.ozlabs.org/patch/1053386/ [2] https://patchwork.ozlabs.org/comment/2488899/ [3] https://github.com/sjg20/u-boot/commits/kevin [4] https://lore.kernel.org/u-boot/CAPnjgZ23jD92y9Ni8YW1FTL0a1sjhGOUoaKx13ZkoKN6... [5] https://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-ic... [6] https://patchwork.ozlabs.org/project/uboot/list/?series=269768 [7] https://patchwork.ozlabs.org/comment/2779784/
Alper Nebi Yasak (2): rockchip: gru: Set up SoC IO domain registers rockchip: bob: Enable more configs
Marty E. Plummer (1): rockchip: rk3399: Add support for chromebook_kevin
Simon Glass (1): rockchip: gru: Add more devicetree settings
arch/arm/dts/Makefile | 1 + arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi | 11 ++ arch/arm/dts/rk3399-gru-u-boot.dtsi | 55 +++++++++ arch/arm/mach-rockchip/rk3399/Kconfig | 11 ++ arch/arm/mach-rockchip/rk3399/rk3399.c | 4 +- arch/arm/mach-rockchip/spl.c | 3 +- board/google/gru/Kconfig | 16 +++ board/google/gru/MAINTAINERS | 8 ++ board/google/gru/gru.c | 56 ++++++++- configs/chromebook_bob_defconfig | 27 +++- configs/chromebook_kevin_defconfig | 116 ++++++++++++++++++ doc/board/rockchip/rockchip.rst | 1 + include/configs/gru.h | 3 + include/dt-bindings/input/linux-event-codes.h | 3 +- 14 files changed, 309 insertions(+), 6 deletions(-) create mode 100644 arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi create mode 100644 configs/chromebook_kevin_defconfig
The RK3399 SoC needs to know the voltage value provided by some regulators, which is done by setting relevant register bits. Configure these the way other RK3399 boards do, but with values set in coreboot.
Signed-off-by: Alper Nebi Yasak alpernebiyasak@gmail.com --- There is a driver for this on Rockchip's repo, I managed to forward-port it and get it working. If that's more desirable than doing it per-board like this I can send that upstream (but I'd prefer to do it after this).
board/google/gru/gru.c | 54 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+)
diff --git a/board/google/gru/gru.c b/board/google/gru/gru.c index 23080c1798b7..cddcb286a380 100644 --- a/board/google/gru/gru.c +++ b/board/google/gru/gru.c @@ -6,6 +6,17 @@ #include <common.h> #include <dm.h> #include <init.h> +#include <syscon.h> +#include <asm/io.h> +#include <asm/arch-rockchip/clock.h> +#include <asm/arch-rockchip/grf_rk3399.h> +#include <asm/arch-rockchip/hardware.h> +#include <asm/arch-rockchip/misc.h> + +#define GRF_IO_VSEL_BT656_SHIFT 0 +#define GRF_IO_VSEL_AUDIO_SHIFT 1 +#define PMUGRF_CON0_VSEL_SHIFT 8 +#define PMUGRF_CON0_VOL_SHIFT 9
#ifdef CONFIG_SPL_BUILD /* provided to defeat compiler optimisation in board_init_f() */ @@ -54,3 +65,46 @@ int board_early_init_r(void) return 0; } #endif + +#ifdef CONFIG_MISC_INIT_R +static void setup_iodomain(void) +{ + struct rk3399_grf_regs *grf = + syscon_get_first_range(ROCKCHIP_SYSCON_GRF); + struct rk3399_pmugrf_regs *pmugrf = + syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF); + + /* BT656 and audio is in 1.8v domain */ + rk_setreg(&grf->io_vsel, (1 << GRF_IO_VSEL_BT656_SHIFT | + 1 << GRF_IO_VSEL_AUDIO_SHIFT)); + + /* + * Set GPIO1 1.8v/3.0v source select to PMU1830_VOL + * and explicitly configure that PMU1830_VOL to be 1.8V + */ + rk_setreg(&pmugrf->soc_con0, (1 << PMUGRF_CON0_VSEL_SHIFT | + 1 << PMUGRF_CON0_VOL_SHIFT)); +} + +int misc_init_r(void) +{ + const u32 cpuid_offset = 0x7; + const u32 cpuid_length = 0x10; + u8 cpuid[cpuid_length]; + int ret; + + setup_iodomain(); + + ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid); + if (ret) + return ret; + + ret = rockchip_cpuid_set(cpuid, cpuid_length); + if (ret) + return ret; + + ret = rockchip_setup_macaddr(); + + return ret; +} +#endif
Hi Alper,
On Thu, 25 Nov 2021 at 10:40, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
The RK3399 SoC needs to know the voltage value provided by some regulators, which is done by setting relevant register bits. Configure these the way other RK3399 boards do, but with values set in coreboot.
What do you mean by values set in coreboot? We don't need that to run here, do we?
Signed-off-by: Alper Nebi Yasak alpernebiyasak@gmail.com
There is a driver for this on Rockchip's repo, I managed to forward-port it and get it working. If that's more desirable than doing it per-board like this I can send that upstream (but I'd prefer to do it after this).
board/google/gru/gru.c | 54 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+)
diff --git a/board/google/gru/gru.c b/board/google/gru/gru.c index 23080c1798b7..cddcb286a380 100644 --- a/board/google/gru/gru.c +++ b/board/google/gru/gru.c @@ -6,6 +6,17 @@ #include <common.h> #include <dm.h> #include <init.h> +#include <syscon.h> +#include <asm/io.h> +#include <asm/arch-rockchip/clock.h> +#include <asm/arch-rockchip/grf_rk3399.h> +#include <asm/arch-rockchip/hardware.h> +#include <asm/arch-rockchip/misc.h>
+#define GRF_IO_VSEL_BT656_SHIFT 0 +#define GRF_IO_VSEL_AUDIO_SHIFT 1 +#define PMUGRF_CON0_VSEL_SHIFT 8 +#define PMUGRF_CON0_VOL_SHIFT 9
#ifdef CONFIG_SPL_BUILD /* provided to defeat compiler optimisation in board_init_f() */ @@ -54,3 +65,46 @@ int board_early_init_r(void) return 0; } #endif
+#ifdef CONFIG_MISC_INIT_R
Can you just drop this #ifdef? It doesn't seem necessasry.
+static void setup_iodomain(void) +{
struct rk3399_grf_regs *grf =syscon_get_first_range(ROCKCHIP_SYSCON_GRF);struct rk3399_pmugrf_regs *pmugrf =syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF);/* BT656 and audio is in 1.8v domain */rk_setreg(&grf->io_vsel, (1 << GRF_IO_VSEL_BT656_SHIFT |1 << GRF_IO_VSEL_AUDIO_SHIFT));/** Set GPIO1 1.8v/3.0v source select to PMU1830_VOL* and explicitly configure that PMU1830_VOL to be 1.8V*/rk_setreg(&pmugrf->soc_con0, (1 << PMUGRF_CON0_VSEL_SHIFT |1 << PMUGRF_CON0_VOL_SHIFT));+}
+int misc_init_r(void) +{
const u32 cpuid_offset = 0x7;const u32 cpuid_length = 0x10;u8 cpuid[cpuid_length];int ret;setup_iodomain();ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);if (ret)return ret;ret = rockchip_cpuid_set(cpuid, cpuid_length);if (ret)return ret;ret = rockchip_setup_macaddr();return ret;+}
+#endif
2.34.0
Regards, Simon
On 03/12/2021 06:31, Simon Glass wrote:
On Thu, 25 Nov 2021 at 10:40, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
The RK3399 SoC needs to know the voltage value provided by some regulators, which is done by setting relevant register bits. Configure these the way other RK3399 boards do, but with values set in coreboot.
What do you mean by values set in coreboot? We don't need that to run here, do we?
I meant that I wasn't blindly copying from other boards which have the same block (e.g. Pinebook Pro), but was using known-good values for Gru boards that coreboot also uses [1].
I tested again and it looks like my Kevin works just as good without this patch, so I'll drop it.
[1] https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src...
Signed-off-by: Alper Nebi Yasak alpernebiyasak@gmail.com
There is a driver for this on Rockchip's repo, I managed to forward-port it and get it working. If that's more desirable than doing it per-board like this I can send that upstream (but I'd prefer to do it after this).
board/google/gru/gru.c | 54 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+)
Hi Alper,
On Tue, 7 Dec 2021 at 13:31, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
On 03/12/2021 06:31, Simon Glass wrote:
On Thu, 25 Nov 2021 at 10:40, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
The RK3399 SoC needs to know the voltage value provided by some regulators, which is done by setting relevant register bits. Configure these the way other RK3399 boards do, but with values set in coreboot.
What do you mean by values set in coreboot? We don't need that to run here, do we?
I meant that I wasn't blindly copying from other boards which have the same block (e.g. Pinebook Pro), but was using known-good values for Gru boards that coreboot also uses [1].
I tested again and it looks like my Kevin works just as good without this patch, so I'll drop it.
Well I have no objection to the patch. I'd suggest saying 'but with the same values as asre set in the equivalent code in coreboot'.
Regards, Simon
[1] https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src...
Signed-off-by: Alper Nebi Yasak alpernebiyasak@gmail.com
There is a driver for this on Rockchip's repo, I managed to forward-port it and get it working. If that's more desirable than doing it per-board like this I can send that upstream (but I'd prefer to do it after this).
board/google/gru/gru.c | 54 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+)
On 09/12/2021 05:32, Simon Glass wrote:
On Tue, 7 Dec 2021 at 13:31, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
On 03/12/2021 06:31, Simon Glass wrote:
On Thu, 25 Nov 2021 at 10:40, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
The RK3399 SoC needs to know the voltage value provided by some regulators, which is done by setting relevant register bits. Configure these the way other RK3399 boards do, but with values set in coreboot.
What do you mean by values set in coreboot? We don't need that to run here, do we?
I meant that I wasn't blindly copying from other boards which have the same block (e.g. Pinebook Pro), but was using known-good values for Gru boards that coreboot also uses [1].
I tested again and it looks like my Kevin works just as good without this patch, so I'll drop it.
Well I have no objection to the patch. I'd suggest saying 'but with the same values as asre set in the equivalent code in coreboot'.
Ah, OK. I'll keep it with that change, then.
(I'll also remove the unnecessary ifdef.)
From: Simon Glass sjg@chromium.org
This adds some devicetree settings for the Gru-based boards, based on what works on a Kevin board.
Gru-based boards usually have an 8MiB SPI flash chip and boot from it. Make the u-boot.rom file intended to be flashed on it match its size. Add properties for booting from SPI, and only try to boot from SPI as MMC and SD card don't seem to work in SPL yet.
The Chromium OS EC needs a delay between transactions so it can get itself ready. Also it currently uses a non-standard way of specifying the interrupt. Add these so that the EC works reliably.
The Rockchip Embedded DisplayPort driver is looking for a rockchip,panel property to find the panel it should work on. Add the property for the Gru-based boards.
The U-Boot GPIO controlled regulator driver only considers the "enable-gpios" devicetree property, not the singular "enable-gpio" one. Some devicetree source files have the singular form as they were added to Linux kernel when it used that form, and imported to U-Boot as is. Fix one instance of this in the Gru boards' devicetree to the form that works in U-Boot.
The PWM controlled regulator driver complains that there is no init voltage set for a regulator it drives, though it's not clear which one. Set them all to the voltage levels coreboot sets them: 900 mV.
The RK3399 SoC needs to know the voltage level that some supplies provides, including one fixed 1.8V audio-related regulator. Although this synchronization is currently statically done in the board init functions, a not-so-hypothetical driver that does this dynamically would query the regulator only to get -ENODATA and be confused. Make sure U-Boot knows this supply is at 1.8V by setting its limits to that.
Most of this is a reapplication of commit 08c85b57a5ec ("rockchip: gru: Add extra device-tree settings") whose changes were removed during a sync with Linux at commit 167efc2c7a46 ("arm64: dts: rk3399: Sync v5.7-rc1 from Linux"). Apply things to rk3399-gru-u-boot.dtsi instead so they don't get lost again.
Signed-off-by: Simon Glass sjg@chromium.org [Alper: move to -u-boot.dtsi, rewrite commit message, add more nodes] Co-developed-by: Alper Nebi Yasak alpernebiyasak@gmail.com Signed-off-by: Alper Nebi Yasak alpernebiyasak@gmail.com --- Kept sign-off and author as Simon based on the aforementioned commit.
arch/arm/dts/rk3399-gru-u-boot.dtsi | 55 +++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+)
diff --git a/arch/arm/dts/rk3399-gru-u-boot.dtsi b/arch/arm/dts/rk3399-gru-u-boot.dtsi index 390ac2bb5a9a..33734e99be50 100644 --- a/arch/arm/dts/rk3399-gru-u-boot.dtsi +++ b/arch/arm/dts/rk3399-gru-u-boot.dtsi @@ -5,6 +5,61 @@
#include "rk3399-u-boot.dtsi"
+/ { + chosen { + u-boot,spl-boot-order = &spi_flash; + }; + + config { + u-boot,spl-payload-offset = <0x40000>; + }; +}; + +&binman { + rom { + size = <0x800000>; + }; +}; + +&cros_ec { + ec-interrupt = <&gpio0 RK_PA1 GPIO_ACTIVE_LOW>; +}; + +&edp { + rockchip,panel = <&edp_panel>; +}; + +&pp1800_audio { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; +}; + +&ppvar_bigcpu_pwm { + regulator-init-microvolt = <900000>; +}; + +&ppvar_centerlogic_pwm { + regulator-init-microvolt = <900000>; +}; + +&ppvar_gpu_pwm { + regulator-init-microvolt = <900000>; +}; + +&ppvar_litcpu_pwm { + regulator-init-microvolt = <900000>; +}; + +&ppvar_sd_card_io { + enable-gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>; +}; + +&spi5 { + spi-activate-delay = <100>; + spi-max-frequency = <3000000>; + spi-deactivate-delay = <200>; +}; + &spi_flash { u-boot,dm-pre-reloc; };
This patch enables some configs that should be working on the Bob board, based on what is observed to work on the Kevin board.
The Bob board uses an Embedded DisplayPort panel compatible with the simple panel and Rockchip eDP drivers. Its backlight is controlled by the Chromium OS Embedded Controller Pulse Width Modulator. Enable these for the board.
Also set VIDEO_ROCKCHIP_MAX_{XRES,YRES} to 1280x800, the resolution of its panel. This had to be done for the Kevin board, but it's untested if this is actually necessary for Bob.
The Rockchip video driver needs to assert/deassert some resets, so also enable the reset controller. RESET_ROCKCHIP defaults to y for this board when DM_RESET=y, so it's enough to set that.
The Bob board has two USB 3.0 Type-C ports and one USB 2.0 Type-A port on its right side. Enable the configs relevant to USB devices so these can be used. This is despite a known issue with RK3399 boards where USB de-init causes a hang, as there is a known workaround.
Some other rk3399-based devices enable support for the SoC's random number generator in commit a475bef5340c ("configs: rk3399: enable rng on firefly/rock960/rockpro64"), as it can provide a KASLR seed when booting using UEFI. Enable it for Bob as well.
The default misc_init_r() for Rockchip boards sets cpuid and ethernet MAC address based on e-fuse block. A previous patch extends this on Gru boards to set registers related to SoC IO domains as is necessary on these boards. Enable this function and configs for it on Bob.
The eMMC on this board is capable of running at a HS400 Enhanced Strobe configuration, and the microSD slot at Ultra High Speed SDR104. Enable the configs for these as the hardware supports these modes. There are problems causing the devices to run at lower speeds, but these configs are enabled in hope that these will be solved later. Enabling ADMA currently makes the eMMC stop working, so it is kept disabled.
The microSD card slot on this board (and others based on Gru) is connected to a GPIO controlled regulator (ppvar-sd-card-io), which must be operable by U-Boot. Enable the relevant config option to allow this.
Bob boards also use the Winbond W25Q64DW SPI flash chip, enable support for Winbond SPI flash chips in the board config so U-Boot can boot with this chip.
Signed-off-by: Alper Nebi Yasak alpernebiyasak@gmail.com ---
configs/chromebook_bob_defconfig | 27 ++++++++++++++++++++++++++- include/configs/gru.h | 3 +++ 2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/configs/chromebook_bob_defconfig b/configs/chromebook_bob_defconfig index fe938c659172..048fa8e0c043 100644 --- a/configs/chromebook_bob_defconfig +++ b/configs/chromebook_bob_defconfig @@ -21,6 +21,7 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-bob.dtb" # CONFIG_DISPLAY_CPUINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_BOARD_EARLY_INIT_R=y +CONFIG_MISC_INIT_R=y CONFIG_BLOBLIST=y CONFIG_BLOBLIST_SIZE=0x1000 CONFIG_BLOBLIST_ADDR=0x100000 @@ -52,26 +53,40 @@ 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_MISC=y +CONFIG_ROCKCHIP_EFUSE=y CONFIG_CROS_EC=y CONFIG_CROS_EC_SPI=y CONFIG_PWRSEQ=y CONFIG_MMC_PWRSEQ=y +CONFIG_MMC_IO_VOLTAGE=y +CONFIG_MMC_UHS_SUPPORT=y +CONFIG_MMC_HS400_ES_SUPPORT=y +CONFIG_MMC_HS400_SUPPORT=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_ROCKCHIP=y CONFIG_SF_DEFAULT_BUS=1 CONFIG_SF_DEFAULT_SPEED=20000000 CONFIG_SPI_FLASH_GIGADEVICE=y +CONFIG_SPI_FLASH_WINBOND=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y +CONFIG_PHY_ROCKCHIP_INNO_USB2=y +CONFIG_PHY_ROCKCHIP_TYPEC=y CONFIG_PMIC_RK8XX=y CONFIG_REGULATOR_PWM=y +CONFIG_DM_REGULATOR_GPIO=y CONFIG_REGULATOR_RK8XX=y +CONFIG_PWM_CROS_EC=y CONFIG_PWM_ROCKCHIP=y +CONFIG_DM_RESET=y +CONFIG_DM_RNG=y +CONFIG_RNG_ROCKCHIP=y CONFIG_DEBUG_UART_SHIFT=2 CONFIG_ROCKCHIP_SPI=y CONFIG_SYSRESET=y @@ -80,11 +95,21 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_GENERIC=y +CONFIG_USB_DWC3=y +CONFIG_USB_KEYBOARD=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_DM_VIDEO=y +CONFIG_DISPLAY=y +CONFIG_VIDEO_ROCKCHIP=y +CONFIG_VIDEO_ROCKCHIP_MAX_XRES=1280 +CONFIG_VIDEO_ROCKCHIP_MAX_YRES=800 +CONFIG_DISPLAY_ROCKCHIP_EDP=y CONFIG_CMD_DHRYSTONE=y CONFIG_ERRNO_STR=y diff --git a/include/configs/gru.h b/include/configs/gru.h index be2dc79968c0..b1084bb21d4d 100644 --- a/include/configs/gru.h +++ b/include/configs/gru.h @@ -13,4 +13,7 @@
#include <configs/rk3399_common.h>
+#define CONFIG_USB_OHCI_NEW +#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 2 + #endif
From: "Marty E. Plummer" hanetzer@startmail.com
Add support for Kevin, an RK3399-based convertible chromebook that is very similar to Bob. This patch is mostly based on existing support for Bob, with only minor changes for Kevin-specific things.
Unlike other Gru boards, coreboot sets Kevin's center logic to 925 mV, so adjust it here in the dts as well. The rk3399-gru-kevin devicetree has an unknown event code reference which has to be defined, set it to the Linux counterpart. The new defconfig is copied from Bob with the diffconfig:
DEFAULT_DEVICE_TREE "rk3399-gru-bob" -> "rk3399-gru-kevin" DEFAULT_FDT_FILE "rockchip/rk3399-gru-bob.dtb" -> "rockchip/rk3399-gru-kevin.dtb" VIDEO_ROCKCHIP_MAX_XRES 1280 -> 2400 VIDEO_ROCKCHIP_MAX_YRES 800 -> 1600 +TARGET_CHROMEBOOK_KEVIN y
With this Kevin can boot from SPI flash to a usable U-Boot prompt on the display with the keyboard working, but cannot boot into Linux for unknown reasons.
eMMC starts in a working state but fails to re-init, microSD card works but at a lower-than-expected speed, USB works but causes a hang on de-init. There are known workarounds to solve eMMC and USB issues.
Cc: Marty E. Plummer hanetzer@startmail.com Cc: Simon Glass sjg@chromium.org [Alper: commit message, resync config with Bob, update MAINTAINERS, add to Rockchip doc, add Kconfig help message, set regulator] Co-developed-by: Alper Nebi Yasak alpernebiyasak@gmail.com Signed-off-by: Alper Nebi Yasak alpernebiyasak@gmail.com --- Marty had signed-off an earlier version of this [1], but not the updated version I continued on top of [2]. So I'm not sure if I can add his sign-off to this as is, and I hope he can reply to this with a sign-off.
[1] https://patchwork.ozlabs.org/patch/1053386/ [2] https://patchwork.ozlabs.org/comment/2488899/
arch/arm/dts/Makefile | 1 + arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi | 11 ++ arch/arm/mach-rockchip/rk3399/Kconfig | 11 ++ arch/arm/mach-rockchip/rk3399/rk3399.c | 4 +- arch/arm/mach-rockchip/spl.c | 3 +- board/google/gru/Kconfig | 16 +++ board/google/gru/MAINTAINERS | 8 ++ board/google/gru/gru.c | 2 +- configs/chromebook_kevin_defconfig | 116 ++++++++++++++++++ doc/board/rockchip/rockchip.rst | 1 + include/dt-bindings/input/linux-event-codes.h | 3 +- 11 files changed, 171 insertions(+), 5 deletions(-) create mode 100644 arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi create mode 100644 configs/chromebook_kevin_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 7f622fedbda7..d6883994f21a 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -132,6 +132,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 000000000000..c03bd48e95d7 --- /dev/null +++ b/arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi @@ -0,0 +1,11 @@ +// 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" + +&ppvar_centerlogic_pwm { + regulator-init-microvolt = <925000>; +}; diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig b/arch/arm/mach-rockchip/rk3399/Kconfig index 17628f917127..0833e083d9ef 100644 --- a/arch/arm/mach-rockchip/rk3399/Kconfig +++ b/arch/arm/mach-rockchip/rk3399/Kconfig @@ -14,6 +14,17 @@ 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 + help + Kevin is a RK3399-based convertible chromebook. It has two USB 3.0 + Type-C ports, 4GB of SDRAM, WiFi and a 12.3" 2400x1600 display. It + uses its USB ports for both power and external display. It includes + a Chromium OS EC (Cortex-M3) to provide access to the keyboard and + battery functions. + 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 2bc8e60b99ba..e486f69e48c8 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -118,7 +118,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 @@ -140,7 +140,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 02c40fb37ed6..7a8db632b80c 100644 --- a/arch/arm/mach-rockchip/spl.c +++ b/arch/arm/mach-rockchip/spl.c @@ -56,7 +56,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 61f7bbca989b..1455e1481dc2 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/MAINTAINERS b/board/google/gru/MAINTAINERS index e1cda756b8c8..53257c52a04b 100644 --- a/board/google/gru/MAINTAINERS +++ b/board/google/gru/MAINTAINERS @@ -4,3 +4,11 @@ S: Maintained F: board/google/gru/ F: include/configs/gru.h F: configs/chromebook_bob_defconfig + +CHROMEBOOK KEVIN BOARD +M: Simon Glass sjg@chromium.org +M: Alper Nebi Yasak alpernebiyasak@gmail.com +S: Maintained +F: board/google/gru/ +F: include/configs/gru.h +F: configs/chromebook_kevin_defconfig diff --git a/board/google/gru/gru.c b/board/google/gru/gru.c index cddcb286a380..2d26f862d214 100644 --- a/board/google/gru/gru.c +++ b/board/google/gru/gru.c @@ -26,7 +26,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 000000000000..7284248c65b3 --- /dev/null +++ b/configs/chromebook_kevin_defconfig @@ -0,0 +1,116 @@ +CONFIG_ARM=y +CONFIG_SKIP_LOWLEVEL_INIT=y +CONFIG_ARCH_ROCKCHIP=y +CONFIG_SYS_TEXT_BASE=0x00200000 +CONFIG_SPL_GPIO=y +CONFIG_NR_DRAM_BANKS=1 +CONFIG_ENV_OFFSET=0x3F8000 +CONFIG_DEFAULT_DEVICE_TREE="rk3399-gru-kevin" +CONFIG_SPL_TEXT_BASE=0xff8c2000 +CONFIG_ROCKCHIP_RK3399=y +CONFIG_ROCKCHIP_BOOT_MODE_REG=0 +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000 +# CONFIG_SPL_MMC is not set +CONFIG_TARGET_CHROMEBOOK_KEVIN=y +CONFIG_DEBUG_UART_BASE=0xff1a0000 +CONFIG_DEBUG_UART_CLOCK=24000000 +CONFIG_SPL_SPI_FLASH_SUPPORT=y +CONFIG_SPL_SPI=y +CONFIG_DEBUG_UART=y +CONFIG_SYS_LOAD_ADDR=0x800800 +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-kevin.dtb" +# CONFIG_DISPLAY_CPUINFO is not set +CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_BOARD_EARLY_INIT_R=y +CONFIG_MISC_INIT_R=y +CONFIG_BLOBLIST=y +CONFIG_BLOBLIST_SIZE=0x1000 +CONFIG_BLOBLIST_ADDR=0x100000 +CONFIG_HANDOFF=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_SYS_SPI_U_BOOT_OFFS=0x40000 +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_CROS_EC_KEYB=y +CONFIG_MISC=y +CONFIG_ROCKCHIP_EFUSE=y +CONFIG_CROS_EC=y +CONFIG_CROS_EC_SPI=y +CONFIG_PWRSEQ=y +CONFIG_MMC_PWRSEQ=y +CONFIG_MMC_IO_VOLTAGE=y +CONFIG_MMC_UHS_SUPPORT=y +CONFIG_MMC_HS400_ES_SUPPORT=y +CONFIG_MMC_HS400_SUPPORT=y +CONFIG_MMC_DW=y +CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_SDMA=y +CONFIG_MMC_SDHCI_ROCKCHIP=y +CONFIG_SF_DEFAULT_BUS=1 +CONFIG_SF_DEFAULT_SPEED=20000000 +CONFIG_SPI_FLASH_GIGADEVICE=y +CONFIG_SPI_FLASH_WINBOND=y +CONFIG_DM_ETH=y +CONFIG_ETH_DESIGNWARE=y +CONFIG_GMAC_ROCKCHIP=y +CONFIG_PHY_ROCKCHIP_INNO_USB2=y +CONFIG_PHY_ROCKCHIP_TYPEC=y +CONFIG_PMIC_RK8XX=y +CONFIG_REGULATOR_PWM=y +CONFIG_DM_REGULATOR_GPIO=y +CONFIG_REGULATOR_RK8XX=y +CONFIG_PWM_CROS_EC=y +CONFIG_PWM_ROCKCHIP=y +CONFIG_DM_RESET=y +CONFIG_DM_RNG=y +CONFIG_RNG_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_OHCI_HCD=y +CONFIG_USB_OHCI_GENERIC=y +CONFIG_USB_DWC3=y +CONFIG_USB_KEYBOARD=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_DM_VIDEO=y +CONFIG_DISPLAY=y +CONFIG_VIDEO_ROCKCHIP=y +CONFIG_VIDEO_ROCKCHIP_MAX_XRES=2400 +CONFIG_VIDEO_ROCKCHIP_MAX_YRES=1600 +CONFIG_DISPLAY_ROCKCHIP_EDP=y +CONFIG_CMD_DHRYSTONE=y +CONFIG_ERRNO_STR=y diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst index 144cb98ef941..a75e60b9fa30 100644 --- a/doc/board/rockchip/rockchip.rst +++ b/doc/board/rockchip/rockchip.rst @@ -66,6 +66,7 @@ List of mainline supported Rockchip boards: - FriendlyElec NanoPi M4B (nanopi-m4b-rk3399) - FriendlyARM NanoPi NEO4 (nanopi-neo4-rk3399) - Google Bob (chromebook_bob) + - Google Kevin (chromebook_kevin) - Khadas Edge (khadas-edge-rk3399) - Khadas Edge-Captain (khadas-edge-captain-rk3399) - Khadas Edge-V (hadas-edge-v-rk3399) diff --git a/include/dt-bindings/input/linux-event-codes.h b/include/dt-bindings/input/linux-event-codes.h index 87cf351bab03..331458c0e710 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)
/*
Hi Alper,
On Thu, 25 Nov 2021 at 10:40, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
From: "Marty E. Plummer" hanetzer@startmail.com
Add support for Kevin, an RK3399-based convertible chromebook that is very similar to Bob. This patch is mostly based on existing support for Bob, with only minor changes for Kevin-specific things.
Unlike other Gru boards, coreboot sets Kevin's center logic to 925 mV, so adjust it here in the dts as well. The rk3399-gru-kevin devicetree has an unknown event code reference which has to be defined, set it to the Linux counterpart. The new defconfig is copied from Bob with the diffconfig:
DEFAULT_DEVICE_TREE "rk3399-gru-bob" -> "rk3399-gru-kevin" DEFAULT_FDT_FILE "rockchip/rk3399-gru-bob.dtb" -> "rockchip/rk3399-gru-kevin.dtb" VIDEO_ROCKCHIP_MAX_XRES 1280 -> 2400 VIDEO_ROCKCHIP_MAX_YRES 800 -> 1600 +TARGET_CHROMEBOOK_KEVIN yWith this Kevin can boot from SPI flash to a usable U-Boot prompt on the display with the keyboard working, but cannot boot into Linux for unknown reasons.
eMMC starts in a working state but fails to re-init, microSD card works but at a lower-than-expected speed, USB works but causes a hang on de-init. There are known workarounds to solve eMMC and USB issues.
Cc: Marty E. Plummer hanetzer@startmail.com Cc: Simon Glass sjg@chromium.org [Alper: commit message, resync config with Bob, update MAINTAINERS, add to Rockchip doc, add Kconfig help message, set regulator] Co-developed-by: Alper Nebi Yasak alpernebiyasak@gmail.com Signed-off-by: Alper Nebi Yasak alpernebiyasak@gmail.com
Marty had signed-off an earlier version of this [1], but not the updated version I continued on top of [2]. So I'm not sure if I can add his sign-off to this as is, and I hope he can reply to this with a sign-off.
[1] https://patchwork.ozlabs.org/patch/1053386/ [2] https://patchwork.ozlabs.org/comment/2488899/
arch/arm/dts/Makefile | 1 + arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi | 11 ++ arch/arm/mach-rockchip/rk3399/Kconfig | 11 ++ arch/arm/mach-rockchip/rk3399/rk3399.c | 4 +- arch/arm/mach-rockchip/spl.c | 3 +- board/google/gru/Kconfig | 16 +++ board/google/gru/MAINTAINERS | 8 ++ board/google/gru/gru.c | 2 +- configs/chromebook_kevin_defconfig | 116 ++++++++++++++++++ doc/board/rockchip/rockchip.rst | 1 + include/dt-bindings/input/linux-event-codes.h | 3 +- 11 files changed, 171 insertions(+), 5 deletions(-) create mode 100644 arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi create mode 100644 configs/chromebook_kevin_defconfig
This needs a rebase on next, just for a change in rk3399.c but I suppose it could be done when applying.
Regards, Simon
On 03/12/2021 06:31, Simon Glass wrote:
On Thu, 25 Nov 2021 at 10:40, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
Add support for Kevin, an RK3399-based convertible chromebook that is very similar to Bob. This patch is mostly based on existing support for Bob, with only minor changes for Kevin-specific things.
[...]
This needs a rebase on next, just for a change in rk3399.c but I suppose it could be done when applying.
Will do for v2.
I was low-key hoping these could get merged to master though :)
Hi Alper,
On Tue, 7 Dec 2021 at 13:53, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
On 03/12/2021 06:31, Simon Glass wrote:
On Thu, 25 Nov 2021 at 10:40, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
Add support for Kevin, an RK3399-based convertible chromebook that is very similar to Bob. This patch is mostly based on existing support for Bob, with only minor changes for Kevin-specific things.
[...]
This needs a rebase on next, just for a change in rk3399.c but I suppose it could be done when applying.
Will do for v2.
I was low-key hoping these could get merged to master though :)
Well it's a bit later now, but they will in January.
Regards, Simon
On Thu, Nov 25, 2021 at 5:39 PM Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
I have recently started testing booting U-Boot from SPI on my gru-kevin (as opposed to chainloading it from vendor coreboot + depthcharge) and brought it to a better working state based on an initial support patch from Marty [1][2] and some follow-up work by Simon [3].
I tried to keep them as the git author when I took things from their work, but squashing other changes into those and rewriting commit messages makes things a bit weird in my opinion, especially for keeping their signoff. Do tell me if there is a better way to that.
As the Kevin and Bob boards are very similar. I assumed the config and devicetree changes will be appropriate for Bob as well, and applied them to it first. I do not have a Bob, so could not test on one myself, but Simon did test an earlier version of this and it appears to work [4].
Other useful things for these boards:
- Patch to fix a hang when usb controllers exit [5]
- Series to support HS400ES mode as HS400 training fails [6]
- Hack to skip eMMC reinitialization so it keeps working [7]
Is there docs updates to be done in doc/chromium/ for this so people know how to use it ?
[1] https://patchwork.ozlabs.org/patch/1053386/ [2] https://patchwork.ozlabs.org/comment/2488899/ [3] https://github.com/sjg20/u-boot/commits/kevin [4] https://lore.kernel.org/u-boot/CAPnjgZ23jD92y9Ni8YW1FTL0a1sjhGOUoaKx13ZkoKN6... [5] https://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-ic... [6] https://patchwork.ozlabs.org/project/uboot/list/?series=269768 [7] https://patchwork.ozlabs.org/comment/2779784/
Alper Nebi Yasak (2): rockchip: gru: Set up SoC IO domain registers rockchip: bob: Enable more configs
Marty E. Plummer (1): rockchip: rk3399: Add support for chromebook_kevin
Simon Glass (1): rockchip: gru: Add more devicetree settings
arch/arm/dts/Makefile | 1 + arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi | 11 ++ arch/arm/dts/rk3399-gru-u-boot.dtsi | 55 +++++++++ arch/arm/mach-rockchip/rk3399/Kconfig | 11 ++ arch/arm/mach-rockchip/rk3399/rk3399.c | 4 +- arch/arm/mach-rockchip/spl.c | 3 +- board/google/gru/Kconfig | 16 +++ board/google/gru/MAINTAINERS | 8 ++ board/google/gru/gru.c | 56 ++++++++- configs/chromebook_bob_defconfig | 27 +++- configs/chromebook_kevin_defconfig | 116 ++++++++++++++++++ doc/board/rockchip/rockchip.rst | 1 + include/configs/gru.h | 3 + include/dt-bindings/input/linux-event-codes.h | 3 +- 14 files changed, 309 insertions(+), 6 deletions(-) create mode 100644 arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi create mode 100644 configs/chromebook_kevin_defconfig
-- 2.34.0
Hi Peter,
On Wed, 1 Dec 2021 at 07:23, Peter Robinson pbrobinson@gmail.com wrote:
On Thu, Nov 25, 2021 at 5:39 PM Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
I have recently started testing booting U-Boot from SPI on my gru-kevin (as opposed to chainloading it from vendor coreboot + depthcharge) and brought it to a better working state based on an initial support patch from Marty [1][2] and some follow-up work by Simon [3].
I tried to keep them as the git author when I took things from their work, but squashing other changes into those and rewriting commit messages makes things a bit weird in my opinion, especially for keeping their signoff. Do tell me if there is a better way to that.
As the Kevin and Bob boards are very similar. I assumed the config and devicetree changes will be appropriate for Bob as well, and applied them to it first. I do not have a Bob, so could not test on one myself, but Simon did test an earlier version of this and it appears to work [4].
Other useful things for these boards:
- Patch to fix a hang when usb controllers exit [5]
- Series to support HS400ES mode as HS400 training fails [6]
- Hack to skip eMMC reinitialization so it keeps working [7]
Is there docs updates to be done in doc/chromium/ for this so people know how to use it ?
This is for bare-metal use though, so it isn't anything to do with Chromium at present.
Regards, Simon
On Fri, Dec 3, 2021 at 3:32 AM Simon Glass sjg@chromium.org wrote:
Hi Peter,
On Wed, 1 Dec 2021 at 07:23, Peter Robinson pbrobinson@gmail.com wrote:
On Thu, Nov 25, 2021 at 5:39 PM Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
I have recently started testing booting U-Boot from SPI on my gru-kevin (as opposed to chainloading it from vendor coreboot + depthcharge) and brought it to a better working state based on an initial support patch from Marty [1][2] and some follow-up work by Simon [3].
I tried to keep them as the git author when I took things from their work, but squashing other changes into those and rewriting commit messages makes things a bit weird in my opinion, especially for keeping their signoff. Do tell me if there is a better way to that.
As the Kevin and Bob boards are very similar. I assumed the config and devicetree changes will be appropriate for Bob as well, and applied them to it first. I do not have a Bob, so could not test on one myself, but Simon did test an earlier version of this and it appears to work [4].
Other useful things for these boards:
- Patch to fix a hang when usb controllers exit [5]
- Series to support HS400ES mode as HS400 training fails [6]
- Hack to skip eMMC reinitialization so it keeps working [7]
Is there docs updates to be done in doc/chromium/ for this so people know how to use it ?
This is for bare-metal use though, so it isn't anything to do with Chromium at present.
So are there docs for how do this? I didn't manage to find any, although the docs I find can be a little over the place in U-Boot so they may be there and I missed them, so either way docs would be fab.
Hi Peter,
On Fri, 3 Dec 2021 at 05:20, Peter Robinson pbrobinson@gmail.com wrote:
On Fri, Dec 3, 2021 at 3:32 AM Simon Glass sjg@chromium.org wrote:
Hi Peter,
On Wed, 1 Dec 2021 at 07:23, Peter Robinson pbrobinson@gmail.com wrote:
On Thu, Nov 25, 2021 at 5:39 PM Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
I have recently started testing booting U-Boot from SPI on my gru-kevin (as opposed to chainloading it from vendor coreboot + depthcharge) and brought it to a better working state based on an initial support patch from Marty [1][2] and some follow-up work by Simon [3].
I tried to keep them as the git author when I took things from their work, but squashing other changes into those and rewriting commit messages makes things a bit weird in my opinion, especially for keeping their signoff. Do tell me if there is a better way to that.
As the Kevin and Bob boards are very similar. I assumed the config and devicetree changes will be appropriate for Bob as well, and applied them to it first. I do not have a Bob, so could not test on one myself, but Simon did test an earlier version of this and it appears to work [4].
Other useful things for these boards:
- Patch to fix a hang when usb controllers exit [5]
- Series to support HS400ES mode as HS400 training fails [6]
- Hack to skip eMMC reinitialization so it keeps working [7]
Is there docs updates to be done in doc/chromium/ for this so people know how to use it ?
This is for bare-metal use though, so it isn't anything to do with Chromium at present.
So are there docs for how do this? I didn't manage to find any, although the docs I find can be a little over the place in U-Boot so they may be there and I missed them, so either way docs would be fab.
There are SPI instructions at doc/board/rockchip but they are pretty 'one way'. So you would need a way to get your old SPI-flash contents back when it doesn't work, because I don't think these platforms support SD boot. I use a 'servo' board and a Dediprog em100 SPI emulator. I know that kevin does not support CCD (Close-Case Debugging) so you cannot program the SPI flash that way...
Regards, Simon
On 03/12/2021 23:13, Simon Glass wrote:
On Fri, 3 Dec 2021 at 05:20, Peter Robinson pbrobinson@gmail.com wrote:
On Fri, Dec 3, 2021 at 3:32 AM Simon Glass sjg@chromium.org wrote:
On Wed, 1 Dec 2021 at 07:23, Peter Robinson pbrobinson@gmail.com wrote:
On Thu, Nov 25, 2021 at 5:39 PM Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
I have recently started testing booting U-Boot from SPI on my gru-kevin (as opposed to chainloading it from vendor coreboot + depthcharge) and [...]
Is there docs updates to be done in doc/chromium/ for this so people know how to use it ?
I tried to document how I'm using this at my GitHub wiki [1]. I want to eventually rework that for U-Boot docs, but I feel I need to explore chromium things a bit more, and want to solve the major problems with these boards before doing that exploration.
[1] https://github.com/alpernebbi/u-boot/wiki
This is for bare-metal use though, so it isn't anything to do with Chromium at present.
So are there docs for how do this? I didn't manage to find any, although the docs I find can be a little over the place in U-Boot so they may be there and I missed them, so either way docs would be fab.
There are SPI instructions at doc/board/rockchip but they are pretty 'one way'. So you would need a way to get your old SPI-flash contents back when it doesn't work, because I don't think these platforms support SD boot. I use a 'servo' board and a Dediprog em100 SPI emulator. I know that kevin does not support CCD (Close-Case Debugging) so you cannot program the SPI flash that way...
The doc/board/rockchip instructions are slightly outdated in that they don't mention u-boot.rom, it's enough just to flash that whichever way possible. There's also the additional prerequisite of disabling write-protection, which I tried to explain a bit in that wiki as well.
I can usually flash things from U-Boot/Linux, but when I flash a bad build I do have to use my CH341A + 1.8V adapter to recover from it.
I don't know if booting from an SD card is outright impossible on these boards, but current config doesn't even have the devices enabled in SPL, and I couldn't get it to work with my naive blind attempts.
On Fri, Dec 3, 2021 at 8:13 PM Simon Glass sjg@chromium.org wrote:
Hi Peter,
On Fri, 3 Dec 2021 at 05:20, Peter Robinson pbrobinson@gmail.com wrote:
On Fri, Dec 3, 2021 at 3:32 AM Simon Glass sjg@chromium.org wrote:
Hi Peter,
On Wed, 1 Dec 2021 at 07:23, Peter Robinson pbrobinson@gmail.com wrote:
On Thu, Nov 25, 2021 at 5:39 PM Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
I have recently started testing booting U-Boot from SPI on my gru-kevin (as opposed to chainloading it from vendor coreboot + depthcharge) and brought it to a better working state based on an initial support patch from Marty [1][2] and some follow-up work by Simon [3].
I tried to keep them as the git author when I took things from their work, but squashing other changes into those and rewriting commit messages makes things a bit weird in my opinion, especially for keeping their signoff. Do tell me if there is a better way to that.
As the Kevin and Bob boards are very similar. I assumed the config and devicetree changes will be appropriate for Bob as well, and applied them to it first. I do not have a Bob, so could not test on one myself, but Simon did test an earlier version of this and it appears to work [4].
Other useful things for these boards:
- Patch to fix a hang when usb controllers exit [5]
- Series to support HS400ES mode as HS400 training fails [6]
- Hack to skip eMMC reinitialization so it keeps working [7]
Is there docs updates to be done in doc/chromium/ for this so people know how to use it ?
This is for bare-metal use though, so it isn't anything to do with Chromium at present.
So are there docs for how do this? I didn't manage to find any, although the docs I find can be a little over the place in U-Boot so they may be there and I missed them, so either way docs would be fab.
There are SPI instructions at doc/board/rockchip but they are pretty 'one way'. So you would need a way to get your old SPI-flash contents back when it doesn't work, because I don't think these platforms support SD boot. I use a 'servo' board and a Dediprog em100 SPI emulator. I know that kevin does not support CCD (Close-Case Debugging) so you cannot program the SPI flash that way...
I thought there was a different process for the chtomebooks than the usual rockchip route. Do the rockchip chomebooks support writing to a space in SPI and chainloading like some of the other arm chtomebooks did (I think tegra/samsung but my memory fades there)? I think it would be useful to document the rockchip chromebook options somewhere so that people that are interested in using the U-Boot option have some resources, we've had a few queries over the time around that.
Peter
On 08/12/2021 12:31, Peter Robinson wrote:
I thought there was a different process for the chtomebooks than the usual rockchip route. Do the rockchip chomebooks support writing to a space in SPI and chainloading like some of the other arm chtomebooks did (I think tegra/samsung but my memory fades there)? I think it would be useful to document the rockchip chromebook options somewhere so that people that are interested in using the U-Boot option have some resources, we've had a few queries over the time around that.
What I usually do is exactly that, chainloading from an SPI region called RW_LEGACY. This is the predecessor of the 'altfw' feature mentioned in doc/chromium/overview.rst, there's a link there that leads to some information about this as well. In short it goes like this:
- Build U-Boot with CONFIG_OF_EMBED=y (or do some objcopy/elfedit magic to merge dtb into u-boot ELF) - cbfstool "u-boot.cbfs" create -s "$((2 * 1024 * 1024))" -m arm64 - cbfstool "u-boot.cbfs" add-payload -f "u-boot" -n payload -c lzma - dd if="u-boot.cbfs" of="u-boot.cbfs.rom" bs=2M seek=3 count=1 - sudo flashrom -p linux_mtd --fmap -i RW_LEGACY -w "u-boot.cbfs.rom" - Reboot and press CTRL+L on Chrome OS developer mode screen
There's also the doc/chromium/chainload.rst process which packs U-Boot as if it's the Chrome OS kernel on a disk. I couldn't manage to boot U-Boot that way, but I somewhat automated that process with binman. I think I can automate the RW_LEGACY image as well but haven't tried it.
I could document what I know as is, but wanted to do it after I get those files automated during upstream build, as things should be quite simple after that.
Hi Alper,
On Thu, 25 Nov 2021 at 10:39, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
I have recently started testing booting U-Boot from SPI on my gru-kevin (as opposed to chainloading it from vendor coreboot + depthcharge) and brought it to a better working state based on an initial support patch from Marty [1][2] and some follow-up work by Simon [3].
I tried to keep them as the git author when I took things from their work, but squashing other changes into those and rewriting commit messages makes things a bit weird in my opinion, especially for keeping their signoff. Do tell me if there is a better way to that.
As the Kevin and Bob boards are very similar. I assumed the config and devicetree changes will be appropriate for Bob as well, and applied them to it first. I do not have a Bob, so could not test on one myself, but Simon did test an earlier version of this and it appears to work [4].
Other useful things for these boards:
- Patch to fix a hang when usb controllers exit [5]
- Series to support HS400ES mode as HS400 training fails [6]
- Hack to skip eMMC reinitialization so it keeps working [7]
[1] https://patchwork.ozlabs.org/patch/1053386/ [2] https://patchwork.ozlabs.org/comment/2488899/ [3] https://github.com/sjg20/u-boot/commits/kevin [4] https://lore.kernel.org/u-boot/CAPnjgZ23jD92y9Ni8YW1FTL0a1sjhGOUoaKx13ZkoKN6... [5] https://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-ic... [6] https://patchwork.ozlabs.org/project/uboot/list/?series=269768 [7] https://patchwork.ozlabs.org/comment/2779784/
Alper Nebi Yasak (2): rockchip: gru: Set up SoC IO domain registers rockchip: bob: Enable more configs
Marty E. Plummer (1): rockchip: rk3399: Add support for chromebook_kevin
Simon Glass (1): rockchip: gru: Add more devicetree settings
arch/arm/dts/Makefile | 1 + arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi | 11 ++ arch/arm/dts/rk3399-gru-u-boot.dtsi | 55 +++++++++ arch/arm/mach-rockchip/rk3399/Kconfig | 11 ++ arch/arm/mach-rockchip/rk3399/rk3399.c | 4 +- arch/arm/mach-rockchip/spl.c | 3 +- board/google/gru/Kconfig | 16 +++ board/google/gru/MAINTAINERS | 8 ++ board/google/gru/gru.c | 56 ++++++++- configs/chromebook_bob_defconfig | 27 +++- configs/chromebook_kevin_defconfig | 116 ++++++++++++++++++ doc/board/rockchip/rockchip.rst | 1 + include/configs/gru.h | 3 + include/dt-bindings/input/linux-event-codes.h | 3 +- 14 files changed, 309 insertions(+), 6 deletions(-) create mode 100644 arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi create mode 100644 configs/chromebook_kevin_defconfig
-- 2.34.0
My test results below. It seems that MMC is broken (I think by a previous change). The garbage on the console with kevin is new but may be unrelated to your patches, not sure. So it seems that your patches work for me on both.
Bob:
do-try-int.sh bob Revision 68acce8a08beb24618343a1ce7ee6c0c4c234b97, board bob
Checking revision 68acce8a08beb24618343a1ce7ee6c0c4c234b97 /vid/software/devel/ubtest tbot starting ... ├─Parameters: │ rev = '68acce8a08beb24618343a1ce7ee6c0c4c234b97' │ clean = False ├─Calling uboot_build_and_flash ... │ ├─bob is on port 9904 and uses /dev/pts/37 │ ├─Calling uboot_build ... │ │ ├─Calling uboot_checkout ... │ │ │ ├─Builder: bob │ │ │ └─Done. (1.104s) │ │ ├─Configuring build ... │ │ ├─Calling uboot_make ... │ │ │ └─Done. (10.289s) │ │ └─Done. (11.767s) │ ├─Calling uboot_flash ... │ │ └─Done. (2.209s) │ └─Done. (14.438s) ├───────────────────────────────────────── └─SUCCESS (16.780s) 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 2022.01-rc3-00130-g68acce8a08b (Dec 02 2021 - 20:05:54 -0700) 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 2022.01-rc3-00130-g68acce8a08b (Dec 02 2021 - 20:05:54 -0700)
Model: Google Bob DRAM: 3.9 GiB MMC: mmc@fe320000: 1, mmc@fe330000: 0 Loading Environment from MMC... Select HS400ES failed -524 unable to select a mode : -5 *** Warning - No block device, 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 Select HS400ES failed -524 unable to select a mode : -5 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 Retrieving file: pxelinux.cfg/00000000 No ethernet found. Retrieving file: pxelinux.cfg/0000000 No ethernet found. Retrieving file: pxelinux.cfg/000000 No ethernet found. Retrieving file: pxelinux.cfg/00000 No ethernet found. Retrieving file: pxelinux.cfg/0000 No ethernet found. Retrieving file: pxelinux.cfg/000 No ethernet found. Retrieving file: pxelinux.cfg/00 No ethernet found. Retrieving file: pxelinux.cfg/0 No ethernet found. Retrieving file: pxelinux.cfg/default-arm-rk3399-gru No ethernet found. Retrieving file: pxelinux.cfg/default-arm-rk3399 No ethernet found. Retrieving file: pxelinux.cfg/default-arm No ethernet found. 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... => mmc info Select HS400ES failed -524 unable to select a mode : -5 => mmc dev 0 Select HS400ES failed -524 unable to select a mode : -5 => mmc dev 1 => => mmc info Select HS400ES failed -524 unable to select a mode : -5 => │ ├─POWEROFF (bob) │ └─Done. (91.515s) ├───────────────────────────────────────── └─SUCCESS (91.618s)
kevin
do-try-int.sh kevin Revision db055a91992886388ca8de0b2408a91f7b7c5d3e, board kevin
Checking revision db055a91992886388ca8de0b2408a91f7b7c5d3e /vid/software/devel/ubtest tbot starting ... ├─Parameters: │ rev = 'db055a91992886388ca8de0b2408a91f7b7c5d3e' │ clean = False ├─Calling uboot_build_and_flash ... │ ├─kevin is on port 9907 and uses /dev/pts/25 │ ├─Calling uboot_build ... │ │ ├─Calling uboot_checkout ... │ │ │ ├─Builder: kevin │ │ │ └─Done. (0.243s) │ │ ├─Configuring build ... │ │ ├─Calling uboot_make ... │ │ │ └─Done. (2.085s) │ │ └─Done. (2.516s) │ ├─Calling uboot_flash ... │ │ └─Done. (2.460s) │ └─Done. (5.426s) ├───────────────────────────────────────── └─SUCCESS (5.663s) tbot starting ... ├─Calling interactive_board ... │ ├─kevin is on port 9907 and uses /dev/pts/25 │ ├─POWERON (kevin) │ ├─Entering interactive shell (CTRL+D to exit) ... ��^o���?�����߿���?�ߴ��[�:�>Ͽ�ݧ���������/���O���>��?�^�i�J����K�k�~ߟ�j�����k��~��[��?2<��ڙ�/�]�����h������ۻo���/����{��jU_�����j��]����7T������o?�W�����}~��;8���陷������w����v���kӿ�;���w�������>�����n|߶��~���\�z���߿7۪������.������WΧ��g��;����������9����ϟ�?�w������?���������ժ����:ۊ�}����>�������j���������~���Wvj2;7�������0^������G�����;��_��r��}�S�Ҿ�������G�o����K���������1ٽ=����ߺb^\������?��M���}/{����7������f�T�����u�sm�7���������3Wo����<�מ����7ho?��z�����=������#���ܿ��q������w�����w����I����������u�=����������������������=��۾������������������������������������������������������w������~���������߷w������������������������������������������������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 2022.01-rc3-00130-gdb055a91992 (Dec 02 2021 - 20:20:17 -0700) 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 2022.01-rc3-00130-gdb055a91992 (Dec 02 2021 - 20:20:17 -0700)
Model: Google Kevin DRAM: 3.9 GiB MMC: mmc@fe320000: 1, mmc@fe330000: 0 Loading Environment from MMC... Select HS400ES failed -524 *** Warning - bad CRC, using default environment
In: cros-ec-keyb Out: vidconsole Err: vidconsole Model: Google Kevin Net: No ethernet found. Hit any key to stop autoboot: 0
Regards, Simon
On 03/12/2021 06:31, Simon Glass wrote:
On Thu, 25 Nov 2021 at 10:39, Alper Nebi Yasak alpernebiyasak@gmail.com wrote:
I have recently started testing booting U-Boot from SPI on my gru-kevin
[...]
Other useful things for these boards:
- Patch to fix a hang when usb controllers exit [5]
- Series to support HS400ES mode as HS400 training fails [6]
- Hack to skip eMMC reinitialization so it keeps working [7]
[5] https://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-ic... [6] https://patchwork.ozlabs.org/project/uboot/list/?series=269768 [7] https://patchwork.ozlabs.org/comment/2779784/
My test results below. It seems that MMC is broken (I think by a previous change). The garbage on the console with kevin is new but may be unrelated to your patches, not sure. So it seems that your patches work for me on both.
The eMMC failure is because I've also enabled HS400ES configs, assuming my series for that (see quoted above) would get merged before these. Sorry I wasn't clear enough about that. Should I disable those?
I have no idea about the console garbage.
participants (3)
-
Alper Nebi Yasak -
Peter Robinson -
Simon Glass