Re: [RFC PATCH 4/4] rockchip: rk3399: attempt to redirect uart2dbga to sdcard
On Wed, Sep 28, 2022 at 04:20:37AM -0600, Simon Glass wrote: > Hi Marty, > > On Thu, 22 Sept 2022 at 00:47, Marty E. Plummer > wrote: > > > > The meat of my problem. rk3399 has the ability to redirect uart2 to > > sdcard pins. This setup half works; I can push input into the uart, but > > not see output. > > > > Signed-off-by: Marty E. Plummer > > > > --- > > > > arch/arm/dts/rk3399-gru.dtsi | 7 ++- > > arch/arm/dts/rk3399.dtsi | 4 ++-- > > .../arm/include/asm/arch-rockchip/grf_rk3399.h | 3 +++ > > arch/arm/mach-rockchip/rk3399/rk3399.c | 18 +- > > 4 files changed, 16 insertions(+), 16 deletions(-) > > Perhaps the C code could be behind a Kconfig, with a comment about how > to change the DT? > Maybe if I do end up making this up for mainline inclusion, sure, but as of right now I just wanna get some console output to see why things aren't booting properly, so looking for dirty hax to work with for now. > Regards, > Simon
[RFC PATCH 4/4] rockchip: rk3399: attempt to redirect uart2dbga to sdcard
The meat of my problem. rk3399 has the ability to redirect uart2 to
sdcard pins. This setup half works; I can push input into the uart, but
not see output.
Signed-off-by: Marty E. Plummer
---
arch/arm/dts/rk3399-gru.dtsi | 7 ++-
arch/arm/dts/rk3399.dtsi | 4 ++--
.../arm/include/asm/arch-rockchip/grf_rk3399.h | 3 +++
arch/arm/mach-rockchip/rk3399/rk3399.c | 18 +-
4 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/dts/rk3399-gru.dtsi b/arch/arm/dts/rk3399-gru.dtsi
index b80f19066b..8c87c1cf19 100644
--- a/arch/arm/dts/rk3399-gru.dtsi
+++ b/arch/arm/dts/rk3399-gru.dtsi
@@ -510,7 +510,7 @@ ap_i2c_audio: {
};
{
- status = "okay";
+ status = "disabled";
/*
* Note: configure "sdmmc_cd" as card detect even though it's actually
@@ -520,14 +520,11 @@ ap_i2c_audio: {
* turned on that the system will still make sure the port is
* configured as SDMMC and not JTAG.
*/
- pinctrl-names = "default";
- pinctrl-0 = <_clk _cmd _cd _cd_pin
-_bus4>;
bus-width = <4>;
cap-mmc-highspeed;
cap-sd-highspeed;
- cd-gpios = < 24 GPIO_ACTIVE_LOW>;
+ // cd-gpios = < 24 GPIO_ACTIVE_LOW>;
disable-wp;
sd-uhs-sdr12;
sd-uhs-sdr25;
diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
index 3871c7fd83..55d5ee15be 100644
--- a/arch/arm/dts/rk3399.dtsi
+++ b/arch/arm/dts/rk3399.dtsi
@@ -638,7 +638,7 @@
reg-shift = <2>;
reg-io-width = <4>;
pinctrl-names = "default";
- pinctrl-0 = <_xfer>;
+ pinctrl-0 = <_xfer>;
status = "disabled";
};
@@ -2571,7 +2571,7 @@
uart2a_xfer: uart2a-xfer {
rockchip,pins =
<4 RK_PB0 2 _pull_up>,
- <4 RK_PB1 2 _pull_none>;
+ <4 RK_PB1 2 _pull_up>;
};
};
diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
index 658cc0dfc4..e1bfa31af7 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
@@ -554,6 +554,9 @@ enum {
/* GRF_SOC_CON7 */
GRF_UART_DBG_SEL_SHIFT = 10,
GRF_UART_DBG_SEL_MASK = 3 << GRF_UART_DBG_SEL_SHIFT,
+ // assumptions, none of this is documented in the TRM as far as I can
see
+ GRF_UART_DBG_SEL_A = 0,
+ GRF_UART_DBG_SEL_B = 1,
GRF_UART_DBG_SEL_C = 2,
/* GRF_SOC_CON20 */
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c
b/arch/arm/mach-rockchip/rk3399/rk3399.c
index 21db03b961..7d35e524dc 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -157,17 +157,17 @@ void board_debug_uart_init(void)
GPIO_PULL_NORMAL);
}
- /* Enable early UART2 channel C on the RK3399 */
- rk_clrsetreg(>gpio4c_iomux,
-GRF_GPIO4C3_SEL_MASK,
-GRF_UART2DGBC_SIN << GRF_GPIO4C3_SEL_SHIFT);
- rk_clrsetreg(>gpio4c_iomux,
-GRF_GPIO4C4_SEL_MASK,
-GRF_UART2DBGC_SOUT << GRF_GPIO4C4_SEL_SHIFT);
- /* Set channel C as UART2 input */
+ /* Enable early UART2 channel A on the RK3399 */
+ rk_clrsetreg(>gpio4b_iomux,
+GRF_GPIO4B0_SEL_MASK,
+GRF_UART2DBGA_SIN << GRF_GPIO4B0_SEL_SHIFT);
+ rk_clrsetreg(>gpio4b_iomux,
+GRF_GPIO4B1_SEL_MASK,
+GRF_UART2DBGA_SOUT << GRF_GPIO4B0_SEL_SHIFT);
+ /* Set channel A as UART2 input */
rk_clrsetreg(>soc_con7,
GRF_UART_DBG_SEL_MASK,
-GRF_UART_DBG_SEL_C << GRF_UART_DBG_SEL_SHIFT);
+GRF_UART_DBG_SEL_A << GRF_UART_DBG_SEL_SHIFT);
#endif
}
#endif
--
2.37.3
[RFC PATCH 3/4] rockchip: rk3399: fix typo in grf file
Not even used as far as I can see, but still.
Signed-off-by: Marty E. Plummer
---
arch/arm/include/asm/arch-rockchip/grf_rk3399.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
index dd89cd2050..658cc0dfc4 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
@@ -466,7 +466,7 @@ enum {
/* GRF_GPIO4C_IOMUX */
GRF_GPIO4C0_SEL_SHIFT = 0,
GRF_GPIO4C0_SEL_MASK= 3 << GRF_GPIO4C0_SEL_SHIFT,
- GRF_UART2DGBB_SIN = 2,
+ GRF_UART2DBGB_SIN = 2,
GRF_HDMII2C_SCL = 3,
GRF_GPIO4C1_SEL_SHIFT = 2,
GRF_GPIO4C1_SEL_MASK= 3 << GRF_GPIO4C1_SEL_SHIFT,
--
2.37.3
[RFC PATCH 2/4] rockchip: rk3288: enable uart2->usb redirection
Code snagged from rk3188's u-boot implementation and the linux kernel's
implementation of rockchip.usb_uart=1
Tested on rk3288-veyron-speedy
patman/checkpatch.pl doesn't like my indentation here and I can't quite
figure out what it actually wants.
Complaint is:
arch/arm/mach-rockchip/rk3288/rk3288.c:95: check: Alignment should match open
parenthesis
arch/arm/mach-rockchip/rk3288/rk3288.c:99: check: Alignment should match open
parenthesis
arch/arm/mach-rockchip/rk3288/rk3288.c:101: check: Alignment should match open
parenthesis
arch/arm/mach-rockchip/rk3288/rk3288.c:108: check: Alignment should match open
parenthesis
Signed-off-by: Marty E. Plummer
---
.../include/asm/arch-rockchip/grf_rk3288.h| 41 +++
arch/arm/mach-rockchip/rk3288/rk3288.c| 20 +
2 files changed, 61 insertions(+)
diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3288.h
b/arch/arm/include/asm/arch-rockchip/grf_rk3288.h
index 894d3a40b0..d94cd9a27a 100644
--- a/arch/arm/include/asm/arch-rockchip/grf_rk3288.h
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3288.h
@@ -1152,4 +1152,45 @@ enum GPIO_BIAS {
#define GPIO_PULL_MASK 0x3
#define GPIO_PULL_SHIFT(x) ((x) * 2)
+/* GRF_UOC_CON0 */
+enum {
+ SIDDQ_SHIFT = 13,
+ SIDDQ_MASK = 1 << SIDDQ_SHIFT,
+
+ UOC_DISABLE_SHIFT = 4,
+ UOC_DISABLE_MASK= 1 << UOC_DISABLE_SHIFT,
+
+ COMMON_ON_N_SHIFT = 0,
+ COMMON_ON_N_MASK= 1 << COMMON_ON_N_SHIFT,
+};
+
+/* GRF_UOC_CON2 */
+enum {
+ SOFT_CON_SEL_SHIFT = 2,
+ SOFT_CON_SEL_MASK = 1 << SOFT_CON_SEL_SHIFT,
+};
+
+/* GRF_UOC0_CON3 */
+enum {
+ BYPASSSEL_SHIFT = 7,
+ BYPASSSEL_MASK = 1 << BYPASSSEL_SHIFT,
+
+ BYPASSDMEN_SHIFT= 6,
+ BYPASSDMEN_MASK = 1 << BYPASSDMEN_SHIFT,
+
+ TERMSEL_FULLSPEED_SHIFT = 5,
+ TERMSEL_FULLSPEED_MASK = 1 << TERMSEL_FULLSPEED_SHIFT,
+
+ XCVRSELECT_SHIFT= 3,
+ XCVRSELECT_FSTRANSC = 1,
+ XCVRSELECT_MASK = 3 << XCVRSELECT_SHIFT,
+
+ OPMODE_SHIFT= 1,
+ OPMODE_NODRIVING= 1,
+ OPMODE_MASK = 3 << OPMODE_SHIFT,
+
+ SUSPENDN_SHIFT = 0,
+ SUSPENDN_MASK = 1 << SUSPENDN_SHIFT,
+};
+
#endif
diff --git a/arch/arm/mach-rockchip/rk3288/rk3288.c
b/arch/arm/mach-rockchip/rk3288/rk3288.c
index 3ad2887575..d9bb1add87 100644
--- a/arch/arm/mach-rockchip/rk3288/rk3288.c
+++ b/arch/arm/mach-rockchip/rk3288/rk3288.c
@@ -89,6 +89,26 @@ int arch_cpu_init(void)
rk_clrreg(>soc_con0, 1 << 12);
rk3288_qos_init();
+
+ if (IS_ENABLED(CONFIG_ROCKCHIP_USB_UART)) {
+ rk_clrsetreg(>uoc0_con[0],
+ SIDDQ_MASK | UOC_DISABLE_MASK | COMMON_ON_N_MASK,
+ 1 << SIDDQ_SHIFT | 1 << UOC_DISABLE_SHIFT |
+ 1 << COMMON_ON_N_SHIFT);
+ rk_clrsetreg(>uoc0_con[2],
+ SOFT_CON_SEL_MASK, 1 << SOFT_CON_SEL_SHIFT);
+ rk_clrsetreg(>uoc0_con[3],
+ OPMODE_MASK | XCVRSELECT_MASK |
+ TERMSEL_FULLSPEED_MASK | SUSPENDN_MASK,
+ OPMODE_NODRIVING << OPMODE_SHIFT |
+ XCVRSELECT_FSTRANSC << XCVRSELECT_SHIFT |
+ 1 << TERMSEL_FULLSPEED_SHIFT |
+ 1 << SUSPENDN_SHIFT);
+ rk_clrsetreg(>uoc0_con[3],
+ BYPASSSEL_MASK | BYPASSDMEN_MASK,
+ 1 << BYPASSSEL_SHIFT | 1 << BYPASSDMEN_SHIFT);
+ }
+
#endif
return 0;
--
2.37.3
[RFC PATCH 1/4] rockchip: rk3288: enable u-boot.rom for speedy
Trivial change, builds a bootable u-boot.rom properly. Signed-off-by: Marty E. Plummer --- arch/arm/mach-rockchip/rk3288/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-rockchip/rk3288/Kconfig b/arch/arm/mach-rockchip/rk3288/Kconfig index e8c57843a3..99bf2397e6 100644 --- a/arch/arm/mach-rockchip/rk3288/Kconfig +++ b/arch/arm/mach-rockchip/rk3288/Kconfig @@ -37,7 +37,9 @@ config TARGET_CHROMEBOOK_MINNIE config TARGET_CHROMEBOOK_SPEEDY bool "Google/Rockchip Veyron-Speedy Chromebook" + select HAS_ROM select BOARD_LATE_INIT + select ROCKCHIP_SPI_IMAGE help Speedy is a RK3288-based clamshell device with 2 USB 2.0 ports, micro HDMI, an 11.6 inch display, micro-SD card, -- 2.37.3
[RFC PATCH 0/4] Alternative debug outputs for rockchip devices
I don't intend for the last change to be included in mainline, I just need some form of serial output to see why archlinuxarm, alpine linux, and Fedora workstation all fail to boot on this hardware (rk3399-gru-kevin). Or at least, I think its failing. At the point of booting the kernel the bottom inch or so of the screen corrupts a bit and then nothing. It could be working, but without output on screen or uart2dbga I have no idea what is going wrong. I *would* use the uart-to-usb functionality of the rk3399, but as far as I know this only works with the 2.0, and I'm not sure if those are available on the rk3399-gru-kevin's type c ports. Do correct me if I'm wrong. In addition, the GRF_SOC_CON7:grf_uart_dbg_sel is, as far as I know, undocumented, outside of the GRF_UART_DBG_SEL_C enum in grf_rk3399, so the other two options (A and B) are just based on my assumptions. If someone who *actually knows* could elaborate on it and correct me if needed I'd greatly appreciate it. Marty E. Plummer (4): rockchip: rk3288: enable u-boot.rom for speedy rockchip: rk3288: enable uart2->usb redirection rockchip: rk3399: fix typo in grf file rockchip: rk3399: attempt to redirect uart2dbga to sdcard arch/arm/dts/rk3399-gru.dtsi | 7 +--- arch/arm/dts/rk3399.dtsi | 4 +- .../include/asm/arch-rockchip/grf_rk3288.h| 41 +++ .../include/asm/arch-rockchip/grf_rk3399.h| 5 ++- arch/arm/mach-rockchip/rk3288/Kconfig | 2 + arch/arm/mach-rockchip/rk3288/rk3288.c| 20 + arch/arm/mach-rockchip/rk3399/rk3399.c| 18 7 files changed, 80 insertions(+), 17 deletions(-) -- 2.37.3
Re: rk3399-gru-kevin: issues on bringup
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 > 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@fe32: 1, sdhci@fe33: 0 > Loading Environment from MMC... *** Warning - bad CRC, using default > environment > > Got rc -1, expected 100 > Failed to probe keyboard 'keyboard-controller' > In:serial@ff1a > Out: serial@ff1a > Err: serial@ff1a > 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
Re: rk3399-gru-kevin: issues on bringup
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 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 > > > 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=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
Re: rk3399-gru-kevin: issues on bringup
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 > 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
Re: rk3399-gru-kevin: issues on bringup
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 wrote: > > > > Hi Marty, > > > > On Sun, 2 Aug 2020 at 21:02, Simon Glass 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
Re: rk3399-gru-kevin: issues on bringup
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 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
Re: rk3399-gru-kevin: issues on bringup
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 00..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
+ */
+
+#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 0xff72
#define PMUGRF_BASE0xff32
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(>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 00..ea975264b5
--- /dev/null
+++ b/configs/chromebook_kevin_defconfig
@@ -0,0 +1,82 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x0020
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_ENV_OFFSET=0x3F8000
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x4
+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=0xff1a
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI_SUPPORT=y
+CONFIG_DEBUG_UART=y
rk3399-gru-kevin: issues on bringup
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 # 0x6 chosen from doc/board/rockchip/rockchip.rst:187 $ dd if=idbloader.img of=start bs=$((0x6)) 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_INSERTED0x0f /* set = pen inserted */ +#define SW_MAX 0x10 #define SW_CNT (SW_MAX+1) /*
Re: [U-Boot] changes in rk3288 code have made me unable to boot u-boot on veyron speedy
On Sat, Mar 09, 2019 at 05:43:24PM +0100, Heiko Stuebner wrote: > Hi Marty, > > Am Samstag, 9. März 2019, 08:15:23 CET schrieb Marty E. Plummer: > > Was going to work on getting that usb->uart redirection code from the > > linux kernel into u-boot for rk3288, like we have for rk3188, but > > apparently there have been some changes which render > > chromebook_speedy_defconfig > > unable to produce a bootable image. Guidance and suggestions welcome. > > > > Current chromebook_speedy_defconfig results: > > U-Boot SPL 2019.04-rc3-03639-ge8e3f2d2d4 (Mar 09 2019 - 00:59:05 -0600) > > > > Trying to boot from SPI > > SPI probe failed. > > SPL: failed to boot from all boot devices > > ### ERROR ### Please RESET the board ### > > > > chromebook_speedy_defconfig with CONFIG_SPI_FLASH turned on (didn't get > > moved into the defconfig like the rest) > > U-Boot SPL 2019.04-rc3-03639-ge8e3f2d2d4 (Mar 09 2019 - 01:01:38 -0600) > > > > Trying to boot from SPI > > initcall sequence 001511f4 failed at call 00101ad5 (err=-38) > > ### ERROR ### Please RESET the board ### > > > > And enabling the full pinctrl driver and the needed libfdt stuff results > > in no output at all. > > Maybe you could try the in flight patch from David first: > http://patchwork.ozlabs.org/patch/1040541/ > Are you meaning I should apply said patch to hopefully fix the no-output when i add the pinctrl driver? > In general I noticed in recent tries that rk3288 scrapes really narrow > at the 32kb limit of the sram, so possibly we'll need TPL on all rk3288 > boards similar to what the rk3288-vyasa board already does now. > Yeah I was eyeballing that as well since adding some features to speedy from jerry in an attempt to get around the issue made the spl image too large. > > Heiko > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] changes in rk3288 code have made me unable to boot u-boot on veyron speedy
Was going to work on getting that usb->uart redirection code from the linux kernel into u-boot for rk3288, like we have for rk3188, but apparently there have been some changes which render chromebook_speedy_defconfig unable to produce a bootable image. Guidance and suggestions welcome. Current chromebook_speedy_defconfig results: U-Boot SPL 2019.04-rc3-03639-ge8e3f2d2d4 (Mar 09 2019 - 00:59:05 -0600) Trying to boot from SPI SPI probe failed. SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### chromebook_speedy_defconfig with CONFIG_SPI_FLASH turned on (didn't get moved into the defconfig like the rest) U-Boot SPL 2019.04-rc3-03639-ge8e3f2d2d4 (Mar 09 2019 - 01:01:38 -0600) Trying to boot from SPI initcall sequence 001511f4 failed at call 00101ad5 (err=-38) ### ERROR ### Please RESET the board ### And enabling the full pinctrl driver and the needed libfdt stuff results in no output at all. .config: # # Automatically generated file; DO NOT EDIT. # U-Boot 2019.04-rc3 Configuration # CONFIG_CREATE_ARCH_SYMLINK=y # CONFIG_ARC is not set CONFIG_ARM=y # CONFIG_M68K is not set # CONFIG_MICROBLAZE is not set # CONFIG_MIPS is not set # CONFIG_NDS32 is not set # CONFIG_NIOS2 is not set # CONFIG_PPC is not set # CONFIG_RISCV is not set # CONFIG_SANDBOX is not set # CONFIG_SH is not set # CONFIG_X86 is not set # CONFIG_XTENSA is not set CONFIG_SYS_ARCH="arm" CONFIG_SYS_CPU="armv7" CONFIG_SYS_SOC="rockchip" CONFIG_SYS_VENDOR="google" CONFIG_SYS_BOARD="veyron" CONFIG_SYS_CONFIG_NAME="veyron" # # ARM architecture # CONFIG_HAS_VBAR=y CONFIG_HAS_THUMB2=y CONFIG_ARM_ASM_UNIFIED=y CONFIG_SYS_ARM_CACHE_CP15=y CONFIG_SYS_ARM_MMU=y # CONFIG_SYS_ARM_MPU is not set CONFIG_CPU_V7A=y CONFIG_SYS_ARM_ARCH=7 CONFIG_SYS_CACHE_SHIFT_6=y CONFIG_SYS_CACHELINE_SIZE=64 # CONFIG_SYS_ARCH_TIMER is not set # CONFIG_ARM_SMCCC is not set # CONFIG_SEMIHOSTING is not set CONFIG_SYS_THUMB_BUILD=y CONFIG_SPL_SYS_THUMB_BUILD=y # CONFIG_SYS_L2CACHE_OFF is not set CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK=y CONFIG_USE_ARCH_MEMCPY=y CONFIG_SPL_USE_ARCH_MEMCPY=y CONFIG_USE_ARCH_MEMSET=y CONFIG_SPL_USE_ARCH_MEMSET=y # CONFIG_ARM64_SUPPORT_AARCH32 is not set # CONFIG_ARCH_AT91 is not set # CONFIG_TARGET_EDB93XX is not set # CONFIG_TARGET_ASPENITE is not set # CONFIG_TARGET_GPLUGD is not set # CONFIG_ARCH_DAVINCI is not set # CONFIG_KIRKWOOD is not set # CONFIG_ARCH_MVEBU is not set # CONFIG_TARGET_APF27 is not set # CONFIG_ORION5X is not set # CONFIG_TARGET_SPEAR300 is not set # CONFIG_TARGET_SPEAR310 is not set # CONFIG_TARGET_SPEAR320 is not set # CONFIG_TARGET_SPEAR600 is not set # CONFIG_TARGET_STV0991 is not set # CONFIG_TARGET_X600 is not set # CONFIG_TARGET_WOODBURN is not set # CONFIG_TARGET_WOODBURN_SD is not set # CONFIG_TARGET_FLEA3 is not set # CONFIG_TARGET_MX35PDK is not set # CONFIG_ARCH_BCM283X is not set # CONFIG_ARCH_BCM63158 is not set # CONFIG_ARCH_BCM6858 is not set # CONFIG_TARGET_VEXPRESS_CA15_TC2 is not set # CONFIG_ARCH_BCMSTB is not set # CONFIG_TARGET_VEXPRESS_CA5X2 is not set # CONFIG_TARGET_VEXPRESS_CA9X4 is not set # CONFIG_TARGET_BCM23550_W1D is not set # CONFIG_TARGET_BCM28155_AP is not set # CONFIG_TARGET_BCMCYGNUS is not set # CONFIG_TARGET_BCMNSP is not set # CONFIG_TARGET_BCMNS2 is not set # CONFIG_ARCH_EXYNOS is not set # CONFIG_ARCH_S5PC1XX is not set # CONFIG_ARCH_HIGHBANK is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_KEYSTONE is not set # CONFIG_ARCH_K3 is not set # CONFIG_ARCH_OMAP2PLUS is not set # CONFIG_ARCH_MESON is not set # CONFIG_ARCH_MEDIATEK is not set # CONFIG_ARCH_LPC32XX is not set # CONFIG_ARCH_IMX8 is not set # CONFIG_ARCH_IMX8M is not set # CONFIG_ARCH_MX23 is not set # CONFIG_ARCH_MX25 is not set # CONFIG_ARCH_MX28 is not set # CONFIG_ARCH_MX31 is not set # CONFIG_ARCH_MX7ULP is not set # CONFIG_ARCH_MX7 is not set # CONFIG_ARCH_MX6 is not set CONFIG_SPL_LDSCRIPT="arch/$(ARCH)/cpu/u-boot-spl.lds" # CONFIG_ARCH_MX5 is not set # CONFIG_ARCH_OWL is not set # CONFIG_ARCH_QEMU is not set # CONFIG_ARCH_RMOBILE is not set # CONFIG_TARGET_S32V234EVB is not set # CONFIG_ARCH_SNAPDRAGON is not set # CONFIG_ARCH_SOCFPGA is not set # CONFIG_ARCH_SUNXI is not set # CONFIG_ARCH_VERSAL is not set # CONFIG_ARCH_VF610 is not set # CONFIG_ARCH_ZYNQ is not set # CONFIG_ARCH_ZYNQMP_R5 is not set # CONFIG_ARCH_ZYNQMP is not set # CONFIG_TEGRA is not set # CONFIG_TARGET_VEXPRESS64_AEMV8A is not set # CONFIG_TARGET_VEXPRESS64_BASE_FVP is not set # CONFIG_TARGET_VEXPRESS64_BASE_FVP_DRAM is not set # CONFIG_TARGET_VEXPRESS64_JUNO is not set # CONFIG_TARGET_LS2080A_EMU is not set # CONFIG_TARGET_LS2080A_SIMU is not set # CONFIG_TARGET_LS1088AQDS is not set # CONFIG_TARGET_LS2080AQDS is not set # CONFIG_TARGET_LS2080ARDB is not set # CONFIG_TARGET_LS2081ARDB is not set # CONFIG_TARGET_LX2160ARDB is not set # CONFIG_TARGET_LX2160AQDS is not set # CONFIG_TARGET_HIKEY is not set #
[U-Boot] [PATCH] rockchip: rk3399: add support for chromebook_kevin
What I've got so far. Currently it does not get any further than the following: U-Boot SPL board init spl_early_init SPL malloc() before relocation used 0x23c8 bytes (8 KB) >>SPL: board_init_r() spl_init SPL: Unsupported Boot Device! SPL: failed to boot from all boot devices ERROR ### Please RESET the board ### Posting to the lists so someone could perhaps assist Signed-off-by: Marty E. Plummer --- arch/arm/dts/rk3399-gru-kevin.dts | 1 + arch/arm/mach-rockchip/rk3399-board-spl.c | 6 +- arch/arm/mach-rockchip/rk3399/Kconfig | 3 + board/google/gru/Kconfig | 16 +++ configs/chromebook_kevin_defconfig| 99 +++ include/dt-bindings/input/linux-event-codes.h | 1 + 6 files changed, 123 insertions(+), 3 deletions(-) create mode 100644 configs/chromebook_kevin_defconfig diff --git a/arch/arm/dts/rk3399-gru-kevin.dts b/arch/arm/dts/rk3399-gru-kevin.dts index 2cc7c47d6a..c7ead02af8 100644 --- a/arch/arm/dts/rk3399-gru-kevin.dts +++ b/arch/arm/dts/rk3399-gru-kevin.dts @@ -7,6 +7,7 @@ /dts-v1/; #include "rk3399-gru-chromebook.dtsi" +#include "rk3399-sdram-lpddr3-samsung-4GB-1866.dtsi" #include /* diff --git a/arch/arm/mach-rockchip/rk3399-board-spl.c b/arch/arm/mach-rockchip/rk3399-board-spl.c index ccc136f388..799fb95013 100644 --- a/arch/arm/mach-rockchip/rk3399-board-spl.c +++ b/arch/arm/mach-rockchip/rk3399-board-spl.c @@ -133,7 +133,7 @@ void board_debug_uart_init(void) #define GPIO0_BASE 0xff72 #define PMUGRF_BASE0xff32 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 @@ -147,7 +147,7 @@ void board_debug_uart_init(void) GRF_GPIO2C1_SEL_MASK, GRF_UART0BT_SOUT << GRF_GPIO2C1_SEL_SHIFT); #else -# ifdef CONFIG_TARGET_CHROMEBOOK_BOB +# if defined(CONFIG_TARGET_CHROMEBOOK_BOB) || defined(CONFIG_TARGET_CHROMEBOOK_KEVIN) rk_setreg(>io_vsel, 1 << 0); /* @@ -187,7 +187,7 @@ void board_init_f(ulong dummy) #ifdef EARLY_UART debug_uart_init(); -# ifdef CONFIG_TARGET_CHROMEBOOK_BOB +#if defined(CONFIG_TARGET_CHROMEBOOK_BOB) || defined(CONFIG_TARGET_CHROMEBOOK_KEVIN) int sum, i; /* diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig b/arch/arm/mach-rockchip/rk3399/Kconfig index 2408adb420..9124bc145a 100644 --- a/arch/arm/mach-rockchip/rk3399/Kconfig +++ b/arch/arm/mach-rockchip/rk3399/Kconfig @@ -62,6 +62,9 @@ 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)" + endchoice config SYS_SOC 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/configs/chromebook_kevin_defconfig b/configs/chromebook_kevin_defconfig new file mode 100644 index 00..9e251137ee --- /dev/null +++ b/configs/chromebook_kevin_defconfig @@ -0,0 +1,99 @@ +CONFIG_ARM=y +CONFIG_ARCH_ROCKCHIP=y +CONFIG_SYS_TEXT_BASE=0x0020 +CONFIG_SPL_GPIO_SUPPORT=y +CONFIG_SPL_LIBCOMMON_SUPPORT=y +CONFIG_SPL_LIBGENERIC_SUPPORT=y +CONFIG_SYS_MALLOC_F_LEN=0x4000 +CONFIG_ROCKCHIP_RK3399=y +CONFIG_ROCKCHIP_BOOT_MODE_REG=0 +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000 +# CONFIG_SPL_MMC_SUPPORT is not set +CONFIG_TARGET_CHROMEBOOK_KEVIN=y +CONFIG_DEBUG_UART_BASE=0xff1a +CONFIG_DEBUG_UART_CLOCK=2400 +CONFIG_SPL_STACK_R_ADDR=0x8 +CONFIG_SPL_SPI_FLASH_SUPPORT=y +CONFIG_SPL_SPI_SUPPORT=y +CONFIG_DEBUG_UART=y +CONFIG_NR_DRAM_BANKS=1 +CONFIG_FIT=y +CONFIG_SPL_LOAD_FIT=y +CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py" +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-kevin.dtb" +# CONFIG_DISPLAY_CPUINFO is not set +CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_SPL_STACK_R=y +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000 +CONFIG_SPL_SPI_LOAD=y +CONFIG_SPL_ATF=y +CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y +CONFIG_CMD_BOOTZ=y +CONFIG_CMD_GPIO=y +CONFIG_CMD_GPT=y +CONFIG_CMD_I2C=y +CONFIG_CMD_MMC=y +CONFIG_CMD_SF=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
[U-Boot] [PATCH v3] rockchip: add support for veyron-speedy (ASUS Chromebook C201)
This adds support for the ASUS C201, a RK3288-based clamshell
device. The device tree comes from linus's linux tree at
3f16503b7d2274ac8cbab11163047ac0b4c66cfe. The SDRAM parameters
are for 4GB Samsung LPDDR3, decoded from coreboot's
src/mainboard/google/veyron/sdram_inf/sdram-lpddr3-samsung-4GB.inc
Signed-off-by: Marty E. Plummer
---
v2: drop sf: Add GigaDevice gd25q32b entry: subsumed by commit
b1f2b72e39465f2d4582bb4d8c426489ee94e2d9
split out rk3288-veyron-speedy-u-boot.dtsi
drop useless if (!size_mb)
apply changes from chromebook_jerry_defconfig
v3: drop rockchip: fix incorrect detection of ram size: subsumed by commit
3119ecc4accceb99cf931683567cc26148b7f99c
sort defconfig option to match changes in chromebook_jerry_defconfig
enable CONSOLE_TRUETYPE
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi | 31
arch/arm/dts/rk3288-veyron-speedy.dts | 143 ++
arch/arm/mach-rockchip/rk3288-board-spl.c | 3 +-
arch/arm/mach-rockchip/rk3288/Kconfig | 11 ++
board/google/veyron/Kconfig | 16 ++
configs/chromebook_speedy_defconfig | 100
7 files changed, 304 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3288-veyron-speedy.dts
create mode 100644 configs/chromebook_speedy_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dda4e59491..5bddf824cd 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -40,6 +40,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-veyron-jerry.dtb \
rk3288-veyron-mickey.dtb \
rk3288-veyron-minnie.dtb \
+ rk3288-veyron-speedy.dtb \
rk3288-vyasa.dtb \
rk3328-evb.dtb \
rk3399-ficus.dtb \
diff --git a/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
b/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
new file mode 100644
index 00..22ba3490f2
--- /dev/null
+++ b/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2015 Google, Inc
+ */
+
+ {
+ rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
+ 0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
+ 0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
+ 0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4
+ 0x8 0x1f4>;
+ rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
+ 0x0 0xc3 0x6 0x1>;
+ rockchip,sdram-params = <0x20D266A4 0x5B6 6 53300 6 13 0>;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/rk3288-veyron-speedy.dts
b/arch/arm/dts/rk3288-veyron-speedy.dts
new file mode 100644
index 00..58c1fe96ee
--- /dev/null
+++ b/arch/arm/dts/rk3288-veyron-speedy.dts
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Veyron Speedy Rev 1+ board device tree source
+ *
+ * Copyright 2015 Google, Inc
+ */
+
+/dts-v1/;
+#include "rk3288-veyron-chromebook.dtsi"
+#include "cros-ec-sbs.dtsi"
+#include "rk3288-veyron-speedy-u-boot.dtsi"
+
+/ {
+ model = "Google Speedy";
+ compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8",
+"google,veyron-speedy-rev7", "google,veyron-speedy-rev6",
+"google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
+"google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
+"google,veyron-speedy", "google,veyron", "rockchip,rk3288";
+
+ panel_regulator: panel-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < RK_PB6 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_enable_h>;
+ regulator-name = "panel_regulator";
+ startup-delay-us = <10>;
+ vin-supply = <_sys>;
+ };
+
+ vcc18_lcd: vcc18-lcd {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < RK_PB5 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_1v8_disp_en>;
+ regulator-name = "vcc18_lcd";
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <_wl>;
+ };
+
+ backlight_regulator: backlight-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < RK_
Re: [U-Boot] [U-Boot, v2, 2/2] rockchip: fix incorrect detection of ram size
On Fri, Nov 30, 2018 at 10:08:07PM +0100, Philipp Tomsich wrote: > Marty, > > > On 30.11.2018, at 22:05, Philipp Tomsich > > wrote: > > > >> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c > >> > >> Without this change, my u-boot build for the asus c201 chromebook (4GiB) > >> is incorrectly detected as 0 Bytes of ram. > >> > >> Signed-off-by: Marty E. Plummer > >> Reviewed-by: Philipp Tomsich > >> --- > >> arch/arm/mach-rockchip/sdram_common.c | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > > > > Applied to u-boot-rockchip, thanks! > > Oops. I just had to pull this series out of the tree again... > Didn’t realise that it hadn’t been revised, so it triggered the same build > error again. > Sorry, I've been a bit busy (work and school; this is a hobby until I can turn it/something similar into a real job). I've attempted to build the defconfig but it fails out some fdt issue I can't quite solve atm. I'd leave it alone for now, I'm going to try fixing the issue. I may need some help. > When can you get an updated patch for me? > As soon as I can figure out fixing 'normal' builds (without my patch) for rk3399 I'll figure what I can do for the ram size clamp. I could ifdef it around aarch64 or something, but that seems hacky(?), thoughts? > Thanks, > Philipp. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 1/2] rockchip: add support for veyron-speedy (ASUS Chromebook C201)
On Tue, Nov 13, 2018 at 01:35:48PM -0800, Simon Glass wrote: > Hi, > > On 13 November 2018 at 11:58, Vagrant Cascadian wrote: > > On 2018-09-13, Marty E. Plummer wrote: > >> This adds support for the ASUS C201, a RK3288-based clamshell > >> device. The device tree comes from linus's linux tree at > >> 3f16503b7d2274ac8cbab11163047ac0b4c66cfe. The SDRAM parameters > >> are for 4GB Samsung LPDDR3, decoded from coreboot's > >> src/mainboard/google/veyron/sdram_inf/sdram-lpddr3-samsung-4GB.inc > > > > Any outstanding blockers on getting this patch series merged? > > Not that I know of. > > The version history should be included with v2 patch so we know what > changes were made from v1. > So, resend the series with changes from v1 to v2? As v2 again? Just wanna be sure. Regards, Marty ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] rockchip: add support for veyron-speedy (ASUS Chromebook C201)
On Fri, Sep 14, 2018 at 12:55:16PM +0200, Simon Glass wrote: > On 13 September 2018 at 23:55, Marty E. Plummer > wrote: > > This adds support for the ASUS C201, a RK3288-based clamshell > > device. The device tree comes from linus's linux tree at > > 3f16503b7d2274ac8cbab11163047ac0b4c66cfe. The SDRAM parameters > > are for 4GB Samsung LPDDR3, decoded from coreboot's > > src/mainboard/google/veyron/sdram_inf/sdram-lpddr3-samsung-4GB.inc > > > > Signed-off-by: Marty E. Plummer > > --- > > arch/arm/dts/Makefile | 1 + > > arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi | 31 > > arch/arm/dts/rk3288-veyron-speedy.dts | 143 ++ > > arch/arm/mach-rockchip/rk3288-board-spl.c | 3 +- > > arch/arm/mach-rockchip/rk3288/Kconfig | 11 ++ > > board/google/veyron/Kconfig | 16 ++ > > configs/chromebook_speedy_defconfig | 98 > > 7 files changed, 302 insertions(+), 1 deletion(-) > > create mode 100644 arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi > > create mode 100644 arch/arm/dts/rk3288-veyron-speedy.dts > > create mode 100644 configs/chromebook_speedy_defconfig > > Reviewed-by: Simon Glass > > But aren't you missing a changelog? > I don't follow. > - Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] rockchip: fix incorrect detection of ram size
On Fri, Sep 14, 2018 at 12:55:19PM +0200, Simon Glass wrote: > Hi Marty, > > > On 13 September 2018 at 23:55, Marty E. Plummer > wrote: > > Taken from coreboot's src/soc/rockchip/rk3288/sdram.c > > > > Without this change, my u-boot build for the asus c201 chromebook (4GiB) > > is incorrectly detected as 0 Bytes of ram. > > > > Signed-off-by: Marty E. Plummer > > --- > > arch/arm/mach-rockchip/sdram_common.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/arch/arm/mach-rockchip/sdram_common.c > > b/arch/arm/mach-rockchip/sdram_common.c > > index 650d53e4d9..194dc74b9f 100644 > > --- a/arch/arm/mach-rockchip/sdram_common.c > > +++ b/arch/arm/mach-rockchip/sdram_common.c > > @@ -48,6 +48,8 @@ size_t rockchip_sdram_size(phys_addr_t reg) > > rank, col, bk, cs0_row, bw, row_3_4); > > } > > > > + size_mb = min(size_mb, SDRAM_MAX_SIZE/SZ_1M); > > + > > Is this because size_mb is only 32-bits? > Yeah. This has been discussed a bit before on the ml. 0x1__ for 4GiB, and due to memory mapped peripherals it can only address 0xff00_ bytes anyways so clamp it down. Code is lifted from coreboot's init code. > > return (size_t)size_mb << 20; > > } > > > > -- > > 2.18.0 > > > > Regards, > Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] rockchip: fix incorrect detection of ram size
Taken from coreboot's src/soc/rockchip/rk3288/sdram.c Without this change, my u-boot build for the asus c201 chromebook (4GiB) is incorrectly detected as 0 Bytes of ram. Signed-off-by: Marty E. Plummer --- arch/arm/mach-rockchip/sdram_common.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-rockchip/sdram_common.c b/arch/arm/mach-rockchip/sdram_common.c index 650d53e4d9..194dc74b9f 100644 --- a/arch/arm/mach-rockchip/sdram_common.c +++ b/arch/arm/mach-rockchip/sdram_common.c @@ -48,6 +48,8 @@ size_t rockchip_sdram_size(phys_addr_t reg) rank, col, bk, cs0_row, bw, row_3_4); } + size_mb = min(size_mb, SDRAM_MAX_SIZE/SZ_1M); + return (size_t)size_mb << 20; } -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] rockchip: add support for veyron-speedy (ASUS Chromebook C201)
This adds support for the ASUS C201, a RK3288-based clamshell
device. The device tree comes from linus's linux tree at
3f16503b7d2274ac8cbab11163047ac0b4c66cfe. The SDRAM parameters
are for 4GB Samsung LPDDR3, decoded from coreboot's
src/mainboard/google/veyron/sdram_inf/sdram-lpddr3-samsung-4GB.inc
Signed-off-by: Marty E. Plummer
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi | 31
arch/arm/dts/rk3288-veyron-speedy.dts | 143 ++
arch/arm/mach-rockchip/rk3288-board-spl.c | 3 +-
arch/arm/mach-rockchip/rk3288/Kconfig | 11 ++
board/google/veyron/Kconfig | 16 ++
configs/chromebook_speedy_defconfig | 98
7 files changed, 302 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3288-veyron-speedy.dts
create mode 100644 configs/chromebook_speedy_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 44ebc50bfa..eab90216f0 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -40,6 +40,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-veyron-jerry.dtb \
rk3288-veyron-mickey.dtb \
rk3288-veyron-minnie.dtb \
+ rk3288-veyron-speedy.dtb \
rk3288-vyasa.dtb \
rk3328-evb.dtb \
rk3368-lion.dtb \
diff --git a/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
b/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
new file mode 100644
index 00..22ba3490f2
--- /dev/null
+++ b/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2015 Google, Inc
+ */
+
+ {
+ rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
+ 0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
+ 0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
+ 0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4
+ 0x8 0x1f4>;
+ rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
+ 0x0 0xc3 0x6 0x1>;
+ rockchip,sdram-params = <0x20D266A4 0x5B6 6 53300 6 13 0>;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/rk3288-veyron-speedy.dts
b/arch/arm/dts/rk3288-veyron-speedy.dts
new file mode 100644
index 00..20100bbdee
--- /dev/null
+++ b/arch/arm/dts/rk3288-veyron-speedy.dts
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Veyron Speedy Rev 1+ board device tree source
+ *
+ * Copyright 2015 Google, Inc
+ */
+
+/dts-v1/;
+#include "rk3288-veyron-chromebook.dtsi"
+#include "cros-ec-sbs.dtsi"
+#include "rk3288-veyron-speedy-u-boot.dtsi"
+
+/ {
+ model = "Google Speedy";
+ compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8",
+"google,veyron-speedy-rev7", "google,veyron-speedy-rev6",
+"google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
+"google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
+"google,veyron-speedy", "google,veyron", "rockchip,rk3288";
+
+ panel_regulator: panel-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < RK_PB6 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_enable_h>;
+ regulator-name = "panel_regulator";
+ startup-delay-us = <10>;
+ vin-supply = <_sys>;
+ };
+
+ vcc18_lcd: vcc18-lcd {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < RK_PB5 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_1v8_disp_en>;
+ regulator-name = "vcc18_lcd";
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <_wl>;
+ };
+
+ backlight_regulator: backlight-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < RK_PB4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pwr_en>;
+ regulator-name = "backlight_regulator";
+ vin-supply = <_sys>;
+ startup-delay-us = <15000>;
+ };
+};
+
+ {
+ power-supply = <_regulator>;
+};
+
+_alert0 {
+ temperature = <65000>;
+};
+
+_alert1 {
+ temperature = <7>;
+};
Re: [U-Boot] [PATCH 2/3] rockchip: add support for veyron-speedy (ASUS Chromebook C201)
On Fri, Jul 13, 2018 at 12:31:49PM +0200, Dr. Philipp Tomsich wrote:
>
> > On 7 May 2018, at 02:20, Marty E. Plummer wrote:
> >
> > On Mon, May 07, 2018 at 12:12:54AM +0200, klaus.go...@theobroma-systems.com
> > <mailto:klaus.go...@theobroma-systems.com> wrote:
> >>
> >>> On 06.05.2018, at 16:25, Marty E. Plummer wrote:
> >>>
> >>> This adds support for the ASUS C201, a RK3288-based clamshell
> >>> device. The device tree comes from linus's linux tree at
> >>> 87ef12027b9b1dd0e0b12cf311fbcb19f9d92539. The SDRAM parameters
> >>> are for 4GB Samsung LPDDR3, decoded from coreboot's
> >>> src/mainboard/google/veyron/sdram_inf/sdram-lpddr3-samsung-4GB.inc
> >>>
> >>> Signed-off-by: Marty E. Plummer
> >>> ---
> >>> arch/arm/dts/Makefile | 1 +
> >>> arch/arm/dts/rk3288-veyron-speedy.dts | 189 ++
> >>> arch/arm/mach-rockchip/rk3288-board-spl.c | 3 +-
> >>> arch/arm/mach-rockchip/rk3288/Kconfig | 11 ++
> >>> board/google/veyron/Kconfig | 16 ++
> >>> configs/chromebook_speedy_defconfig | 96 +++
> >>> 6 files changed, 315 insertions(+), 1 deletion(-)
> >>> create mode 100644 arch/arm/dts/rk3288-veyron-speedy.dts
> >>> create mode 100644 configs/chromebook_speedy_defconfig
> >>>
> >>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> >>> index ac7667b1e8..ee04d9bedd 100644
> >>> --- a/arch/arm/dts/Makefile
> >>> +++ b/arch/arm/dts/Makefile
> >>> @@ -42,6 +42,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
> >>> rk3288-veyron-jerry.dtb \
> >>> rk3288-veyron-mickey.dtb \
> >>> rk3288-veyron-minnie.dtb \
> >>> + rk3288-veyron-speedy.dtb \
> >>> rk3288-vyasa.dtb \
> >>> rk3328-evb.dtb \
> >>> rk3368-lion.dtb \
> >>> diff --git a/arch/arm/dts/rk3288-veyron-speedy.dts
> >>> b/arch/arm/dts/rk3288-veyron-speedy.dts
> >>> new file mode 100644
> >>> index 00..d5383cef0d
> >>> --- /dev/null
> >>> +++ b/arch/arm/dts/rk3288-veyron-speedy.dts
> >>
> >> This file looks quite different then the one I see on kernel.org with that
> >> revision id. So you are sure you
> >> imported that one?
> > Dafuq... it seems I borked something up in doing the patch juggling to
> > turn my single-commit mess of a patch (you know, the 'get the thing to
> > work branch') into a good patch series I messed up on this one.
> >>
> >>> @@ -0,0 +1,189 @@
> >>> +/*
> >>> + * Google Veyron Speedy Rev 1+ board device tree source
> >>> + *
> >>> + * Copyright 2015 Google, Inc
> >>> + *
> >>> + * SPDX-License-Identifier: GPL-2.0
> >>
> >> This file is dual licensed upstream, keep it that way.
> >> The comment will claim it's a X11 license but the license text below
> >> is actually MIT so you may want to use the MIT SPDX tag for that.
> >>
> > Yeah, I was listening in on the convo on irc. So, even though it 'says'
> > its GPL/X11, the actual license text is MIT, so I should use that tag?
> > Its not my code, obviously, so I have no dog in that race anyways.
> >>> + */
> >>> +
> >>> +/dts-v1/;
> >>> +#include "rk3288-veyron-chromebook.dtsi"
> >>> +#include "cros-ec-sbs.dtsi"
> >>> +
> >>> +/ {
> >>> + model = "Google Speedy";
> >>> + compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8",
> >>> + "google,veyron-speedy-rev7", "google,veyron-speedy-rev6",
> >>> + "google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
> >>> + "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
> >>> + "google,veyron-speedy", "google,veyron", "rockchip,rk3288";
> >>> +
> >>> + chosen {
> >>> + stdout-path =
> >>> + };
> >>> +
> >>> + panel_regulator: panel-regulator {
> >>> + compatible = "regulator-fixed";
> >>> + enable-active-high;
> >>> + gpio = < RK_PB6 GPIO_ACTIVE_HIGH>;
> >>> + pinctrl-names = "de
Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size
On Sat, May 19, 2018 at 02:08:53PM +0200, Dr. Philipp Tomsich wrote: > Marty, > > > On 19 May 2018, at 12:40, Marty E. Plummer wrote: > > > > So explain to me what you'd like me to do here, if you would. What I > > gather from this is you want me to flip CONFIG_PHYS_64BIT and see if it > > works or what? I can flash/reflash u-boot and coreboot pretty easily on > > the device, so I'm down for any sort of hardware testing needed to get > > this into a usable state. > > Yes, just enable PHYS_64BIT and report on how far it goes (activating some > debug may be helpful to understand what goes wrong, if it fails). > > My gut feeling is that it could work, but there’s a number of pitfalls and we > may > not be lucky. > Testing flipping CONFIG_PHYS_64BIT, both with and without my 'clamping' patch to sdram_common.c, has the same results, in that all that is output on the servo console is that wierd output. Where to from here, then? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size
On Mon, May 14, 2018 at 05:56:27PM +0200, Dr. Philipp Tomsich wrote: > I had a bit more time to look into this and it looks as if we have two > problem-spots... > > First, there's a type-mismatch between ram_info.size (a size_t) and > gd.ram_size (phys_size_t). > While we can increase the size of a phys_size_t to 64bit (by defining > CONFIG_PHYS_64BIT), > the size_t will always be an unsigned int on a 32bit arm architecture. So > here's one possible > pitfall that should be resolved. > > Once this is adjusted, we might just increase the width of ram_info.size to > 64bit by enabling > CONFIG_PHYS_64BIT ... however, this comes with a caveat: the default cell > sizes for the > FDT (via fdtdec) also increases. I.e. if any come in our arch or the drivers > still goes through > the fdtdec-functions, we'll end up with a problem. > > As my test coverage is limited to 64bit targets, I can't tell whether > defining the PHYS_64BIT > configuration would be possible for the RK3288 -- if it is, we'd have a > rather easy way forward > and could reuse the phys_size_t for ram_info.size. > > I'd appreciate if you could take a look at whether CONFIG_PHYS_64BIT gets us > into a lot > of trouble on the RK3288 or whether this will trigger just a few minor > adjustments... > > Thanks, > Philipp. So explain to me what you'd like me to do here, if you would. What I gather from this is you want me to flip CONFIG_PHYS_64BIT and see if it works or what? I can flash/reflash u-boot and coreboot pretty easily on the device, so I'm down for any sort of hardware testing needed to get this into a usable state. Regards, Marty. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size
On Tue, May 08, 2018 at 11:08:14PM +0200, Dr. Philipp Tomsich wrote:
>
> > On 8 May 2018, at 21:21, Marty E. Plummer <hanet...@startmail.com> wrote:
> >
> > On Tue, May 08, 2018 at 12:21:24PM +0200, Dr. Philipp Tomsich wrote:
> >> Marty,
> >>
> >>> On 8 May 2018, at 02:52, Marty E. Plummer <hanet...@startmail.com> wrote:
> >>>
> >>> On Mon, May 07, 2018 at 11:16:28AM +0200, Dr. Philipp Tomsich wrote:
> >>>>
> >>>>> On 7 May 2018, at 04:34, Marty E. Plummer <hanet...@startmail.com>
> >>>>> wrote:
> >>>>>
> >>>>> On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
> >>>>>> Hi Marty,
> >>>>>>
> >>>>>>
> >>>>>> On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
> >>>>>>> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
> >>>>>>>
> >>>>>>> Without this change, my u-boot build for the asus c201 chromebook
> >>>>>>> (4GiB)
> >>>>>>> is incorrectly detected as 0 Bytes of ram.
> >>>>>>
> >>>>>> I know the root cause for this issue, and I have a local patch for it.
> >>>>>> The rk3288 is 32bit, and 4GB size is just out of range, so we need to
> >>>>>> before
> >>>>>> the max size before return with '<<20'. Sorry for forgot to send it
> >>>>>> out.
> >>>>>>
> >>>>>>>
> >>>>>>> Signed-off-by: Marty E. Plummer <hanet...@startmail.com>
> >>>>>>> ---
> >>>>>>> arch/arm/mach-rockchip/sdram_common.c | 62 ---
> >>>>>>> 1 file changed, 37 insertions(+), 25 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/arch/arm/mach-rockchip/sdram_common.c
> >>>>>>> b/arch/arm/mach-rockchip/sdram_common.c
> >>>>>>> index 76dbdc8715..a9c9f970a4 100644
> >>>>>>> --- a/arch/arm/mach-rockchip/sdram_common.c
> >>>>>>> +++ b/arch/arm/mach-rockchip/sdram_common.c
> >>>>>>> @@ -10,6 +10,8 @@
> >>>>>>> #include
> >>>>>>> #include
> >>>>>>> #include
> >>>>>>> +#include
> >>>>>>> +#include
> >>>>>>>
> >>>>>>> DECLARE_GLOBAL_DATA_PTR;
> >>>>>>> size_t rockchip_sdram_size(phys_addr_t reg)
> >>>>>>> @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
> >>>>>>> size_t size_mb = 0;
> >>>>>>> u32 ch;
> >>>>>>>
> >>>>>>> - u32 sys_reg = readl(reg);
> >>>>>>> - u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
> >>>>>>> -& SYS_REG_NUM_CH_MASK);
> >>>>>>> + if (!size_mb) {
> >>>>>>
> >>>>>> I don't understand this and follow up changes, we don't really need it,
> >>>>>> isn't it?
> >>>>>> I think don't need the changes before here.
> >>>>> Yeah, that was just another level of indentation for the if (!size_mb)
> >>>>> guard, but I've reworked the patch to not do that as it was pointed out
> >>>>> that since size_mb is initialized to 0 prior.
> >>>>>>> + /*
> >>>>>>> + * we use the 0x~0xfeff space
> >>>>>>> + * since 0xff00~0x is soc register space
> >>>>>>> + * so we reserve it
> >>>>>>> + */
> >>>>>>> + size_mb = min(size_mb, 0xff00/SZ_1M);
> >>>>>>
> >>>>>> This is what we really need, as Klaus point out, we need to use
> >>>>>> SDRAM_MAX_SIZE
> >>>>>> instead of hard code.
> >>>>> Yeah, I've got a rework on that which uses SDRAM_MAX_SIZE as instructed,
> >>>>> build and boot tested on my hardware.
> >>>>
> >>>> In that case you just masked the problem but didn???t solve it: assuming
> >>>> siz
Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size
On Tue, May 08, 2018 at 12:21:24PM +0200, Dr. Philipp Tomsich wrote:
> Marty,
>
> > On 8 May 2018, at 02:52, Marty E. Plummer <hanet...@startmail.com> wrote:
> >
> > On Mon, May 07, 2018 at 11:16:28AM +0200, Dr. Philipp Tomsich wrote:
> >>
> >>> On 7 May 2018, at 04:34, Marty E. Plummer <hanet...@startmail.com> wrote:
> >>>
> >>> On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
> >>>> Hi Marty,
> >>>>
> >>>>
> >>>> On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
> >>>>> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
> >>>>>
> >>>>> Without this change, my u-boot build for the asus c201 chromebook (4GiB)
> >>>>> is incorrectly detected as 0 Bytes of ram.
> >>>>
> >>>> I know the root cause for this issue, and I have a local patch for it.
> >>>> The rk3288 is 32bit, and 4GB size is just out of range, so we need to
> >>>> before
> >>>> the max size before return with '<<20'. Sorry for forgot to send it out.
> >>>>
> >>>>>
> >>>>> Signed-off-by: Marty E. Plummer <hanet...@startmail.com>
> >>>>> ---
> >>>>> arch/arm/mach-rockchip/sdram_common.c | 62 ---
> >>>>> 1 file changed, 37 insertions(+), 25 deletions(-)
> >>>>>
> >>>>> diff --git a/arch/arm/mach-rockchip/sdram_common.c
> >>>>> b/arch/arm/mach-rockchip/sdram_common.c
> >>>>> index 76dbdc8715..a9c9f970a4 100644
> >>>>> --- a/arch/arm/mach-rockchip/sdram_common.c
> >>>>> +++ b/arch/arm/mach-rockchip/sdram_common.c
> >>>>> @@ -10,6 +10,8 @@
> >>>>> #include
> >>>>> #include
> >>>>> #include
> >>>>> +#include
> >>>>> +#include
> >>>>>
> >>>>> DECLARE_GLOBAL_DATA_PTR;
> >>>>> size_t rockchip_sdram_size(phys_addr_t reg)
> >>>>> @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
> >>>>> size_t size_mb = 0;
> >>>>> u32 ch;
> >>>>>
> >>>>> - u32 sys_reg = readl(reg);
> >>>>> - u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
> >>>>> - & SYS_REG_NUM_CH_MASK);
> >>>>> + if (!size_mb) {
> >>>>
> >>>> I don't understand this and follow up changes, we don't really need it,
> >>>> isn't it?
> >>>> I think don't need the changes before here.
> >>> Yeah, that was just another level of indentation for the if (!size_mb)
> >>> guard, but I've reworked the patch to not do that as it was pointed out
> >>> that since size_mb is initialized to 0 prior.
> >>>>> + /*
> >>>>> +* we use the 0x~0xfeff space
> >>>>> +* since 0xff00~0x is soc register space
> >>>>> +* so we reserve it
> >>>>> +*/
> >>>>> + size_mb = min(size_mb, 0xff00/SZ_1M);
> >>>>
> >>>> This is what we really need, as Klaus point out, we need to use
> >>>> SDRAM_MAX_SIZE
> >>>> instead of hard code.
> >>> Yeah, I've got a rework on that which uses SDRAM_MAX_SIZE as instructed,
> >>> build and boot tested on my hardware.
> >>
> >> In that case you just masked the problem but didn???t solve it: assuming
> >> size_mb
> >> is size_t (I???ll assume this is 64bit, but did not check), then your 4GB
> >> is 0x1__ )
> >> which overflows to 0x0 when converted to a u32.
> >>
> >> In other words: we need to figure out where the truncation occurs (image
> >> what
> >> happens if a new 32bit processor with LPAE comes out???).
> >>
> > A very valid point. With the following patch to sdram_common.c and
> > sdram_rk3288.c applied I get the debug output that follows it:
> > diff --git a/arch/arm/mach-rockchip/sdram_common.c
> > b/arch/arm/mach-rockchip/sdram_common.c
> > index 232a7fa655..0fe69bf558 100644
> > --- a/arch/arm/mach-rockchip/sdram_common.c
> > +++ b/arch/arm/mach-rockchip/sdram_common.c
> > @@ -4,6 +4,7 @@
>
Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size
On Mon, May 07, 2018 at 11:16:28AM +0200, Dr. Philipp Tomsich wrote:
>
> > On 7 May 2018, at 04:34, Marty E. Plummer <hanet...@startmail.com> wrote:
> >
> > On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
> >> Hi Marty,
> >>
> >>
> >> On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
> >>> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
> >>>
> >>> Without this change, my u-boot build for the asus c201 chromebook (4GiB)
> >>> is incorrectly detected as 0 Bytes of ram.
> >>
> >> I know the root cause for this issue, and I have a local patch for it.
> >> The rk3288 is 32bit, and 4GB size is just out of range, so we need to
> >> before
> >> the max size before return with '<<20'. Sorry for forgot to send it out.
> >>
> >>>
> >>> Signed-off-by: Marty E. Plummer <hanet...@startmail.com>
> >>> ---
> >>> arch/arm/mach-rockchip/sdram_common.c | 62 ---
> >>> 1 file changed, 37 insertions(+), 25 deletions(-)
> >>>
> >>> diff --git a/arch/arm/mach-rockchip/sdram_common.c
> >>> b/arch/arm/mach-rockchip/sdram_common.c
> >>> index 76dbdc8715..a9c9f970a4 100644
> >>> --- a/arch/arm/mach-rockchip/sdram_common.c
> >>> +++ b/arch/arm/mach-rockchip/sdram_common.c
> >>> @@ -10,6 +10,8 @@
> >>> #include
> >>> #include
> >>> #include
> >>> +#include
> >>> +#include
> >>>
> >>> DECLARE_GLOBAL_DATA_PTR;
> >>> size_t rockchip_sdram_size(phys_addr_t reg)
> >>> @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
> >>> size_t size_mb = 0;
> >>> u32 ch;
> >>>
> >>> - u32 sys_reg = readl(reg);
> >>> - u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
> >>> -& SYS_REG_NUM_CH_MASK);
> >>> + if (!size_mb) {
> >>
> >> I don't understand this and follow up changes, we don't really need it,
> >> isn't it?
> >> I think don't need the changes before here.
> > Yeah, that was just another level of indentation for the if (!size_mb)
> > guard, but I've reworked the patch to not do that as it was pointed out
> > that since size_mb is initialized to 0 prior.
> >>> + /*
> >>> + * we use the 0x~0xfeff space
> >>> + * since 0xff00~0x is soc register space
> >>> + * so we reserve it
> >>> + */
> >>> + size_mb = min(size_mb, 0xff00/SZ_1M);
> >>
> >> This is what we really need, as Klaus point out, we need to use
> >> SDRAM_MAX_SIZE
> >> instead of hard code.
> > Yeah, I've got a rework on that which uses SDRAM_MAX_SIZE as instructed,
> > build and boot tested on my hardware.
>
> In that case you just masked the problem but didn???t solve it: assuming
> size_mb
> is size_t (I???ll assume this is 64bit, but did not check), then your 4GB is
> 0x1__ )
> which overflows to 0x0 when converted to a u32.
>
> In other words: we need to figure out where the truncation occurs (image what
> happens if a new 32bit processor with LPAE comes out???).
>
A very valid point. With the following patch to sdram_common.c and
sdram_rk3288.c applied I get the debug output that follows it:
diff --git a/arch/arm/mach-rockchip/sdram_common.c
b/arch/arm/mach-rockchip/sdram_common.c
index 232a7fa655..0fe69bf558 100644
--- a/arch/arm/mach-rockchip/sdram_common.c
+++ b/arch/arm/mach-rockchip/sdram_common.c
@@ -4,6 +4,7 @@
* SPDX-License-Identifier: GPL-2.0+
*/
+#define DEBUG 1
#include
#include
#include
@@ -39,16 +40,19 @@ size_t rockchip_sdram_size(phys_addr_t reg)
SYS_REG_ROW_3_4_MASK;
chipsize_mb = (1 << (cs0_row + col + bk + bw - 20));
+ debug("%s: %d: chipsize_mb %x\n", __func__, __LINE__,
chipsize_mb);
if (rank > 1)
chipsize_mb += chipsize_mb >> (cs0_row - cs1_row);
if (row_3_4)
chipsize_mb = chipsize_mb * 3 / 4;
size_mb += chipsize_mb;
+ debug("%s: %d: size_mb %x\n", __func__, __LINE__, size_mb);
debug("rank %d col %d bk %d cs0_row %d bw %d row_3_4 %d\n",
rank, col, bk, cs0_row, bw, row_3_4);
}
+ debug("%s: %d: size_mb %x\n", __func__, __LINE__, size_mb);
size_mb = min(size_mb, SD
Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size
On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
> Hi Marty,
>
>
> On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
> > Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
> >
> > Without this change, my u-boot build for the asus c201 chromebook (4GiB)
> > is incorrectly detected as 0 Bytes of ram.
>
> I know the root cause for this issue, and I have a local patch for it.
> The rk3288 is 32bit, and 4GB size is just out of range, so we need to before
> the max size before return with '<<20'. Sorry for forgot to send it out.
>
> >
> > Signed-off-by: Marty E. Plummer <hanet...@startmail.com>
> > ---
> > arch/arm/mach-rockchip/sdram_common.c | 62 ---
> > 1 file changed, 37 insertions(+), 25 deletions(-)
> >
> > diff --git a/arch/arm/mach-rockchip/sdram_common.c
> > b/arch/arm/mach-rockchip/sdram_common.c
> > index 76dbdc8715..a9c9f970a4 100644
> > --- a/arch/arm/mach-rockchip/sdram_common.c
> > +++ b/arch/arm/mach-rockchip/sdram_common.c
> > @@ -10,6 +10,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> >
> > DECLARE_GLOBAL_DATA_PTR;
> > size_t rockchip_sdram_size(phys_addr_t reg)
> > @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
> > size_t size_mb = 0;
> > u32 ch;
> >
> > - u32 sys_reg = readl(reg);
> > - u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
> > - & SYS_REG_NUM_CH_MASK);
> > + if (!size_mb) {
>
> I don't understand this and follow up changes, we don't really need it,
> isn't it?
> I think don't need the changes before here.
Yeah, that was just another level of indentation for the if (!size_mb)
guard, but I've reworked the patch to not do that as it was pointed out
that since size_mb is initialized to 0 prior.
> > + /*
> > +* we use the 0x~0xfeff space
> > +* since 0xff00~0x is soc register space
> > +* so we reserve it
> > +*/
> > + size_mb = min(size_mb, 0xff00/SZ_1M);
>
> This is what we really need, as Klaus point out, we need to use
> SDRAM_MAX_SIZE
> instead of hard code.
Yeah, I've got a rework on that which uses SDRAM_MAX_SIZE as instructed,
build and boot tested on my hardware.
>
> Thanks,
> - Kever
> > }
> >
> > return (size_t)size_mb << 20;
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] add support for the asus C201 chromebook (4GiB)
On Sun, May 06, 2018 at 09:25:10AM -0500, Marty E. Plummer wrote: > Build and boot tested on my chromebook, which was generously altered by > Simon Glass to have a servo header and also generously provided a servo > board itself to do debugging with. > > It ''works'', but has a few oddities. I can't seem to get it to see my > external sdcard or a usb flash drive, so I've been having to ymodem my > kernel, fdt, and initramfs over to test booting (which does work). The > screen is a bit inconsistent on whether or not it activates any given > power cycle, but when it does work, it works right. > > The changes to sdram_common.c were taken from coreboot, as it has > otherwise identical code (minus the if (!size_mb) block), and actually > works on my hardware. > Oh, and one other thing: unless I revert commit c3c0331db1fb7b1f4ff41e144fc04353b37c785c, I do not get any output on the debug uart, but I didn't want to send a revert commit without discussion, even more so than the the other stuff I'm providing. That being said, can anyone else with a rockchip device using u-boot give current u-boot master a try and see if I'm the only one not getting console output after that commit? > Marty E. Plummer (3): > sf: Add GigaDevice gd25q32b entry > rockchip: add support for veyron-speedy (ASUS Chromebook C201) > rockchip: fix incorrect detection of ram size > > arch/arm/dts/Makefile | 1 + > arch/arm/dts/rk3288-veyron-speedy.dts | 189 ++ > arch/arm/mach-rockchip/rk3288-board-spl.c | 3 +- > arch/arm/mach-rockchip/rk3288/Kconfig | 11 ++ > arch/arm/mach-rockchip/sdram_common.c | 62 --- > board/google/veyron/Kconfig | 16 ++ > configs/chromebook_speedy_defconfig | 96 +++ > drivers/mtd/spi/spi_flash_ids.c | 1 + > 8 files changed, 353 insertions(+), 26 deletions(-) > create mode 100644 arch/arm/dts/rk3288-veyron-speedy.dts > create mode 100644 configs/chromebook_speedy_defconfig > > -- > 2.17.0 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size
On Mon, May 07, 2018 at 12:19:11AM +0200, Dr. Philipp Tomsich wrote:
>
> > On 6 May 2018, at 16:25, Marty E. Plummer <hanet...@startmail.com> wrote:
> >
> > Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
> >
> > Without this change, my u-boot build for the asus c201 chromebook (4GiB)
> > is incorrectly detected as 0 Bytes of ram.
>
> Could you elaborate what the change is and what root-cause this addresses (4GB
> reporting as 0 sounds a bit like a 32bit type overflowing)?
> It's really hard to tell from the patch below (which seems to have everything
> simply
> reformatted to a different indentation)...
>
if (!size_mb) {} wrapping, plus the min code near the end. However,
actual testing on hardware shows this if guard to be unneeded, so I'll
be dropping it. I was just taking what was different from coreboot's
implementation (which I knew to work), but not all was needed it seems.
> >
> > Signed-off-by: Marty E. Plummer <hanet...@startmail.com>
> > ---
> > arch/arm/mach-rockchip/sdram_common.c | 62 ---
> > 1 file changed, 37 insertions(+), 25 deletions(-)
> >
> > diff --git a/arch/arm/mach-rockchip/sdram_common.c
> > b/arch/arm/mach-rockchip/sdram_common.c
> > index 76dbdc8715..a9c9f970a4 100644
> > --- a/arch/arm/mach-rockchip/sdram_common.c
> > +++ b/arch/arm/mach-rockchip/sdram_common.c
> > @@ -10,6 +10,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> >
> > DECLARE_GLOBAL_DATA_PTR;
> > size_t rockchip_sdram_size(phys_addr_t reg)
> > @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
> > size_t size_mb = 0;
> > u32 ch;
> >
> > - u32 sys_reg = readl(reg);
> > - u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
> > - & SYS_REG_NUM_CH_MASK);
> > + if (!size_mb) {
>
> Given that there's a "size_mb = 0" just above it, this will always evaluate
> to true...
>
Very true, next patch revision will do away with this if guard, as its
unneeded according to hardware retesting.
> >
> > - debug("%s %x %x\n", __func__, (u32)reg, sys_reg);
> > - for (ch = 0; ch < ch_num; ch++) {
> > - rank = 1 + (sys_reg >> SYS_REG_RANK_SHIFT(ch) &
> > - SYS_REG_RANK_MASK);
> > - col = 9 + (sys_reg >> SYS_REG_COL_SHIFT(ch) & SYS_REG_COL_MASK);
> > - bk = 3 - ((sys_reg >> SYS_REG_BK_SHIFT(ch)) & SYS_REG_BK_MASK);
> > - cs0_row = 13 + (sys_reg >> SYS_REG_CS0_ROW_SHIFT(ch) &
> > - SYS_REG_CS0_ROW_MASK);
> > - cs1_row = 13 + (sys_reg >> SYS_REG_CS1_ROW_SHIFT(ch) &
> > - SYS_REG_CS1_ROW_MASK);
> > - bw = (2 >> ((sys_reg >> SYS_REG_BW_SHIFT(ch)) &
> > - SYS_REG_BW_MASK));
> > - row_3_4 = sys_reg >> SYS_REG_ROW_3_4_SHIFT(ch) &
> > - SYS_REG_ROW_3_4_MASK;
> > + u32 sys_reg = readl(reg);
> > + u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
> > + & SYS_REG_NUM_CH_MASK);
> >
> > - chipsize_mb = (1 << (cs0_row + col + bk + bw - 20));
> > + debug("%s %x %x\n", __func__, (u32)reg, sys_reg);
> > + for (ch = 0; ch < ch_num; ch++) {
> > + rank = 1 + (sys_reg >> SYS_REG_RANK_SHIFT(ch) &
> > + SYS_REG_RANK_MASK);
> > + col = 9 + (sys_reg >> SYS_REG_COL_SHIFT(ch) &
> > SYS_REG_COL_MASK);
> > + bk = 3 - ((sys_reg >> SYS_REG_BK_SHIFT(ch)) &
> > SYS_REG_BK_MASK);
> > + cs0_row = 13 + (sys_reg >> SYS_REG_CS0_ROW_SHIFT(ch) &
> > + SYS_REG_CS0_ROW_MASK);
> > + cs1_row = 13 + (sys_reg >> SYS_REG_CS1_ROW_SHIFT(ch) &
> > + SYS_REG_CS1_ROW_MASK);
> > + bw = (2 >> ((sys_reg >> SYS_REG_BW_SHIFT(ch)) &
> > + SYS_REG_BW_MASK));
> > + row_3_4 = sys_reg >> SYS_REG_ROW_3_4_SHIFT(ch) &
> > + SYS_REG_ROW_3_4_MASK;
> >
> > - if (rank > 1)
> > - chipsize_mb += chipsize_mb >> (cs0_row - cs1_row);
> > - if (row_3_4)
> > - chips
Re: [U-Boot] [PATCH 2/3] rockchip: add support for veyron-speedy (ASUS Chromebook C201)
On Mon, May 07, 2018 at 12:12:54AM +0200, klaus.go...@theobroma-systems.com
wrote:
>
> > On 06.05.2018, at 16:25, Marty E. Plummer <hanet...@startmail.com> wrote:
> >
> > This adds support for the ASUS C201, a RK3288-based clamshell
> > device. The device tree comes from linus's linux tree at
> > 87ef12027b9b1dd0e0b12cf311fbcb19f9d92539. The SDRAM parameters
> > are for 4GB Samsung LPDDR3, decoded from coreboot's
> > src/mainboard/google/veyron/sdram_inf/sdram-lpddr3-samsung-4GB.inc
> >
> > Signed-off-by: Marty E. Plummer <hanet...@startmail.com>
> > ---
> > arch/arm/dts/Makefile | 1 +
> > arch/arm/dts/rk3288-veyron-speedy.dts | 189 ++
> > arch/arm/mach-rockchip/rk3288-board-spl.c | 3 +-
> > arch/arm/mach-rockchip/rk3288/Kconfig | 11 ++
> > board/google/veyron/Kconfig | 16 ++
> > configs/chromebook_speedy_defconfig | 96 +++
> > 6 files changed, 315 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm/dts/rk3288-veyron-speedy.dts
> > create mode 100644 configs/chromebook_speedy_defconfig
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index ac7667b1e8..ee04d9bedd 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -42,6 +42,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
> > rk3288-veyron-jerry.dtb \
> > rk3288-veyron-mickey.dtb \
> > rk3288-veyron-minnie.dtb \
> > + rk3288-veyron-speedy.dtb \
> > rk3288-vyasa.dtb \
> > rk3328-evb.dtb \
> > rk3368-lion.dtb \
> > diff --git a/arch/arm/dts/rk3288-veyron-speedy.dts
> > b/arch/arm/dts/rk3288-veyron-speedy.dts
> > new file mode 100644
> > index 00..d5383cef0d
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3288-veyron-speedy.dts
>
> This file looks quite different then the one I see on kernel.org with that
> revision id. So you are sure you
> imported that one?
Dafuq... it seems I borked something up in doing the patch juggling to
turn my single-commit mess of a patch (you know, the 'get the thing to
work branch') into a good patch series I messed up on this one.
>
> > @@ -0,0 +1,189 @@
> > +/*
> > + * Google Veyron Speedy Rev 1+ board device tree source
> > + *
> > + * Copyright 2015 Google, Inc
> > + *
> > + * SPDX-License-Identifier:GPL-2.0
>
> This file is dual licensed upstream, keep it that way.
> The comment will claim it's a X11 license but the license text below
> is actually MIT so you may want to use the MIT SPDX tag for that.
>
Yeah, I was listening in on the convo on irc. So, even though it 'says'
its GPL/X11, the actual license text is MIT, so I should use that tag?
Its not my code, obviously, so I have no dog in that race anyways.
> > + */
> > +
> > +/dts-v1/;
> > +#include "rk3288-veyron-chromebook.dtsi"
> > +#include "cros-ec-sbs.dtsi"
> > +
> > +/ {
> > + model = "Google Speedy";
> > + compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8",
> > +"google,veyron-speedy-rev7", "google,veyron-speedy-rev6",
> > +"google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
> > +"google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
> > +"google,veyron-speedy", "google,veyron", "rockchip,rk3288";
> > +
> > + chosen {
> > + stdout-path =
> > + };
> > +
> > + panel_regulator: panel-regulator {
> > + compatible = "regulator-fixed";
> > + enable-active-high;
> > + gpio = < RK_PB6 GPIO_ACTIVE_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_enable_h>;
> > + regulator-name = "panel_regulator";
> > + startup-delay-us = <10>;
> > + vin-supply = <_sys>;
> > + };
> > +
> > + vcc18_lcd: vcc18-lcd {
> > + compatible = "regulator-fixed";
> > + enable-active-high;
> > + gpio = < RK_PB5 GPIO_ACTIVE_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_1v8_disp_en>;
> > + regulator-name = "vcc18_lcd";
> > + regulator-always-on;
> > + regulator-boot-on;
> > + vin-supply = <_wl>;
> > + };
> > +
> > +
Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size
On Sun, May 06, 2018 at 10:21:55PM +0200, klaus.go...@theobroma-systems.com wrote: > > > On 06.05.2018, at 22:03, Marty E. Plummer <hanet...@startmail.com> wrote: > > > > On Sun, May 06, 2018 at 02:08:25PM -0500, Marty E. Plummer wrote: > >>> On Sun, May 06, 2018 at 08:39:23PM +0200, > >>> klaus.go...@theobroma-systems.com wrote: > >>>> On 06.05.2018, at 16:25, Marty E. Plummer <hanet...@startmail.com> wrote: > >>>> + * we use the 0x~0xfeff space > >>>> + * since 0xff00~0x is soc register space > >>>> + * so we reserve it > >>>> + */ > >>> > >>> That's not true for all Rockchip SoCs. On the RK3399 for example the > >>> upper limit > >>> is 0xf800. Even on the RK3288 DRAM address range is actually > >>> 0x-0xfe0 > >>> > >>>> +size_mb = min(size_mb, 0xff00/SZ_1M); > >>>> } > >>> > >>> Should be 0xfe00 (4G-32MB) for RK3288. > >>> But there is already a define for that, SDRAM_MAX_SIZE is defined in > >>> rkxxx_common.h. Using that one would help to avoid possible breakage > >>> of other Rockchip SoCs. > >>> > >> Oh, does that get #defined properly for each SoC? if so, I'll sub that > >> in for better compat. > > In fact, could you or someone else help me to understand the #include > > chain here? I'm not certain as to what that is available in each header > > mentioned can be used in this file to get max compat across the rockchip > > lineup, and I don't want to break someone elses board/etc with something > > that 'works for me'. > > You can get a full list of included headers by adding the -H file to the gcc > command line. > make V=1 will help you to see how it's called on your system. > > In that particular case the relevant include chain is: > . include/common.h > .. include/config.h > ... include/configs/popmetal_rk3288.h > include/configs/rk3288_common.h > > So the correct rk3xxx_common.h will be selected by config.h and SDRAM_MAX_SIZE > is defined in all of them. > Ah, so 's:0xff00:SDRAM_MAX_SIZE:' in that spot and it should be golden for all the rockchip stuffs. I'll try that, then try without the if (!size_mb) guard as well. Should it still work after that, I'll resubmit that patch. Probably with patman, if I can grok how to use it. Aside from these issues, does the rest of the series look fine? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size
On Sun, May 06, 2018 at 02:08:25PM -0500, Marty E. Plummer wrote: > > On Sun, May 06, 2018 at 08:39:23PM +0200, klaus.go...@theobroma-systems.com > > wrote: > > > On 06.05.2018, at 16:25, Marty E. Plummer <hanet...@startmail.com> wrote: > > > + * we use the 0x~0xfeff space > > > + * since 0xff00~0x is soc register space > > > + * so we reserve it > > > + */ > > > > That's not true for all Rockchip SoCs. On the RK3399 for example the upper > > limit > > is 0xf800. Even on the RK3288 DRAM address range is actually > > 0x-0xfe0 > > > > > + size_mb = min(size_mb, 0xff00/SZ_1M); > > > } > > > > Should be 0xfe00 (4G-32MB) for RK3288. > > But there is already a define for that, SDRAM_MAX_SIZE is defined in > > rkxxx_common.h. Using that one would help to avoid possible breakage > > of other Rockchip SoCs. > > > Oh, does that get #defined properly for each SoC? if so, I'll sub that > in for better compat. In fact, could you or someone else help me to understand the #include chain here? I'm not certain as to what that is available in each header mentioned can be used in this file to get max compat across the rockchip lineup, and I don't want to break someone elses board/etc with something that 'works for me'. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size
On Sun, May 06, 2018 at 08:39:23PM +0200, klaus.go...@theobroma-systems.com
wrote:
> CC Philipp and Simon due maintainership (you may want to use
> get_maintainer.pl in the future)
> and Kever as the original author of the file.
>
> > On 06.05.2018, at 16:25, Marty E. Plummer <hanet...@startmail.com> wrote:
> >
> > Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
> >
> > Without this change, my u-boot build for the asus c201 chromebook (4GiB)
> > is incorrectly detected as 0 Bytes of ram.
> >
> > Signed-off-by: Marty E. Plummer <hanet...@startmail.com>
> > ---
> > arch/arm/mach-rockchip/sdram_common.c | 62 ---
> > 1 file changed, 37 insertions(+), 25 deletions(-)
> >
> > diff --git a/arch/arm/mach-rockchip/sdram_common.c
> > b/arch/arm/mach-rockchip/sdram_common.c
> > index 76dbdc8715..a9c9f970a4 100644
> > --- a/arch/arm/mach-rockchip/sdram_common.c
> > +++ b/arch/arm/mach-rockchip/sdram_common.c
> > @@ -10,6 +10,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
>
> Is adding these headers really necessary?
> common.h already includes kernel.h and sizes.h (with some redirections of
> config.h)
>
If it it does get that in eventually, I suppose its not required.
I didn't know that chain of inclusion existed, so I grabbed what I
needed.
> > DECLARE_GLOBAL_DATA_PTR;
> > size_t rockchip_sdram_size(phys_addr_t reg)
> > @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
> > size_t size_mb = 0;
> > u32 ch;
> >
> > - u32 sys_reg = readl(reg);
> > - u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
> > - & SYS_REG_NUM_CH_MASK);
> > + if (!size_mb) {
>
> Is this really required? I don't see a way that size_mb will already be set
> at this point.
> But it blows up your diff that it takes quite a while to see that your only
> real change is
> the size_mb = min(...) part at the end.
>
It may be unneeded. I just knew that ram init worked on coreboot and not
on u-boot, and the only difference between the codepaths on both was the
if and min()
> > - debug("%s %x %x\n", __func__, (u32)reg, sys_reg);
> > - for (ch = 0; ch < ch_num; ch++) {
> > - rank = 1 + (sys_reg >> SYS_REG_RANK_SHIFT(ch) &
> > - SYS_REG_RANK_MASK);
> > - col = 9 + (sys_reg >> SYS_REG_COL_SHIFT(ch) & SYS_REG_COL_MASK);
> > - bk = 3 - ((sys_reg >> SYS_REG_BK_SHIFT(ch)) & SYS_REG_BK_MASK);
> > - cs0_row = 13 + (sys_reg >> SYS_REG_CS0_ROW_SHIFT(ch) &
> > - SYS_REG_CS0_ROW_MASK);
> > - cs1_row = 13 + (sys_reg >> SYS_REG_CS1_ROW_SHIFT(ch) &
> > - SYS_REG_CS1_ROW_MASK);
> > - bw = (2 >> ((sys_reg >> SYS_REG_BW_SHIFT(ch)) &
> > - SYS_REG_BW_MASK));
> > - row_3_4 = sys_reg >> SYS_REG_ROW_3_4_SHIFT(ch) &
> > - SYS_REG_ROW_3_4_MASK;
> > + u32 sys_reg = readl(reg);
> > + u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
> > + & SYS_REG_NUM_CH_MASK);
> >
> > - chipsize_mb = (1 << (cs0_row + col + bk + bw - 20));
> > + debug("%s %x %x\n", __func__, (u32)reg, sys_reg);
> > + for (ch = 0; ch < ch_num; ch++) {
> > + rank = 1 + (sys_reg >> SYS_REG_RANK_SHIFT(ch) &
> > + SYS_REG_RANK_MASK);
> > + col = 9 + (sys_reg >> SYS_REG_COL_SHIFT(ch) &
> > SYS_REG_COL_MASK);
> > + bk = 3 - ((sys_reg >> SYS_REG_BK_SHIFT(ch)) &
> > SYS_REG_BK_MASK);
> > + cs0_row = 13 + (sys_reg >> SYS_REG_CS0_ROW_SHIFT(ch) &
> > + SYS_REG_CS0_ROW_MASK);
> > + cs1_row = 13 + (sys_reg >> SYS_REG_CS1_ROW_SHIFT(ch) &
> > + SYS_REG_CS1_ROW_MASK);
> > + bw = (2 >> ((sys_reg >> SYS_REG_BW_SHIFT(ch)) &
> > + SYS_REG_BW_MASK));
> > + row_3_4 = sys_reg >> SYS_REG_ROW_3_4_SHIFT(ch) &
> > + SYS_REG_ROW_3_4_MASK;
> >
> > - if (rank > 1)
> > - chipsize_mb += chipsize_mb >> (cs0_row - cs1_row);
> > - if (row_3_4)
> > - ch
[U-Boot] [PATCH 2/3] rockchip: add support for veyron-speedy (ASUS Chromebook C201)
This adds support for the ASUS C201, a RK3288-based clamshell
device. The device tree comes from linus's linux tree at
87ef12027b9b1dd0e0b12cf311fbcb19f9d92539. The SDRAM parameters
are for 4GB Samsung LPDDR3, decoded from coreboot's
src/mainboard/google/veyron/sdram_inf/sdram-lpddr3-samsung-4GB.inc
Signed-off-by: Marty E. Plummer <hanet...@startmail.com>
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3288-veyron-speedy.dts | 189 ++
arch/arm/mach-rockchip/rk3288-board-spl.c | 3 +-
arch/arm/mach-rockchip/rk3288/Kconfig | 11 ++
board/google/veyron/Kconfig | 16 ++
configs/chromebook_speedy_defconfig | 96 +++
6 files changed, 315 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/rk3288-veyron-speedy.dts
create mode 100644 configs/chromebook_speedy_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ac7667b1e8..ee04d9bedd 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -42,6 +42,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-veyron-jerry.dtb \
rk3288-veyron-mickey.dtb \
rk3288-veyron-minnie.dtb \
+ rk3288-veyron-speedy.dtb \
rk3288-vyasa.dtb \
rk3328-evb.dtb \
rk3368-lion.dtb \
diff --git a/arch/arm/dts/rk3288-veyron-speedy.dts
b/arch/arm/dts/rk3288-veyron-speedy.dts
new file mode 100644
index 00..d5383cef0d
--- /dev/null
+++ b/arch/arm/dts/rk3288-veyron-speedy.dts
@@ -0,0 +1,189 @@
+/*
+ * Google Veyron Speedy Rev 1+ board device tree source
+ *
+ * Copyright 2015 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+/dts-v1/;
+#include "rk3288-veyron-chromebook.dtsi"
+#include "cros-ec-sbs.dtsi"
+
+/ {
+ model = "Google Speedy";
+ compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8",
+"google,veyron-speedy-rev7", "google,veyron-speedy-rev6",
+"google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
+"google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
+"google,veyron-speedy", "google,veyron", "rockchip,rk3288";
+
+ chosen {
+ stdout-path =
+ };
+
+ panel_regulator: panel-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < RK_PB6 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_enable_h>;
+ regulator-name = "panel_regulator";
+ startup-delay-us = <10>;
+ vin-supply = <_sys>;
+ };
+
+ vcc18_lcd: vcc18-lcd {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < RK_PB5 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_1v8_disp_en>;
+ regulator-name = "vcc18_lcd";
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <_wl>;
+ };
+
+ backlight_regulator: backlight-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < RK_PB4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pwr_en>;
+ regulator-name = "backlight_regulator";
+ vin-supply = <_sys>;
+ startup-delay-us = <15000>;
+ };
+};
+
+ {
+ rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
+ 0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
+ 0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
+ 0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4
+ 0x8 0x1f4>;
+ rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
+ 0x0 0xc3 0x6 0x1>;
+ rockchip,sdram-params = <0x20D266A4 0x5B6 6 53300 6 13 0>;
+};
+
+_keys {
+ power {
+ gpios = < RK_PA5 GPIO_ACTIVE_LOW>;
+ };
+};
+
+ {
+ power-supply = <_regulator>;
+};
+
+ {
+ power-supply = <_regulator>;
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_int_l>;
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_clk _cmd _cd_disabled _cd_gpio
+ _bus4>;
+ disable-wp;
+};
+
+_5v {
+ enable-active-high;
+ gpio = < RK_PC5 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_5v>;
+};
+
+_hdmi {
+ enable-active-high;
+ gpio = < RK_PC3 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "defau
[U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size
Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
Without this change, my u-boot build for the asus c201 chromebook (4GiB)
is incorrectly detected as 0 Bytes of ram.
Signed-off-by: Marty E. Plummer <hanet...@startmail.com>
---
arch/arm/mach-rockchip/sdram_common.c | 62 ---
1 file changed, 37 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-rockchip/sdram_common.c
b/arch/arm/mach-rockchip/sdram_common.c
index 76dbdc8715..a9c9f970a4 100644
--- a/arch/arm/mach-rockchip/sdram_common.c
+++ b/arch/arm/mach-rockchip/sdram_common.c
@@ -10,6 +10,8 @@
#include
#include
#include
+#include
+#include
DECLARE_GLOBAL_DATA_PTR;
size_t rockchip_sdram_size(phys_addr_t reg)
@@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
size_t size_mb = 0;
u32 ch;
- u32 sys_reg = readl(reg);
- u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
- & SYS_REG_NUM_CH_MASK);
+ if (!size_mb) {
- debug("%s %x %x\n", __func__, (u32)reg, sys_reg);
- for (ch = 0; ch < ch_num; ch++) {
- rank = 1 + (sys_reg >> SYS_REG_RANK_SHIFT(ch) &
- SYS_REG_RANK_MASK);
- col = 9 + (sys_reg >> SYS_REG_COL_SHIFT(ch) & SYS_REG_COL_MASK);
- bk = 3 - ((sys_reg >> SYS_REG_BK_SHIFT(ch)) & SYS_REG_BK_MASK);
- cs0_row = 13 + (sys_reg >> SYS_REG_CS0_ROW_SHIFT(ch) &
- SYS_REG_CS0_ROW_MASK);
- cs1_row = 13 + (sys_reg >> SYS_REG_CS1_ROW_SHIFT(ch) &
- SYS_REG_CS1_ROW_MASK);
- bw = (2 >> ((sys_reg >> SYS_REG_BW_SHIFT(ch)) &
- SYS_REG_BW_MASK));
- row_3_4 = sys_reg >> SYS_REG_ROW_3_4_SHIFT(ch) &
- SYS_REG_ROW_3_4_MASK;
+ u32 sys_reg = readl(reg);
+ u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
+ & SYS_REG_NUM_CH_MASK);
- chipsize_mb = (1 << (cs0_row + col + bk + bw - 20));
+ debug("%s %x %x\n", __func__, (u32)reg, sys_reg);
+ for (ch = 0; ch < ch_num; ch++) {
+ rank = 1 + (sys_reg >> SYS_REG_RANK_SHIFT(ch) &
+ SYS_REG_RANK_MASK);
+ col = 9 + (sys_reg >> SYS_REG_COL_SHIFT(ch) &
SYS_REG_COL_MASK);
+ bk = 3 - ((sys_reg >> SYS_REG_BK_SHIFT(ch)) &
SYS_REG_BK_MASK);
+ cs0_row = 13 + (sys_reg >> SYS_REG_CS0_ROW_SHIFT(ch) &
+ SYS_REG_CS0_ROW_MASK);
+ cs1_row = 13 + (sys_reg >> SYS_REG_CS1_ROW_SHIFT(ch) &
+ SYS_REG_CS1_ROW_MASK);
+ bw = (2 >> ((sys_reg >> SYS_REG_BW_SHIFT(ch)) &
+ SYS_REG_BW_MASK));
+ row_3_4 = sys_reg >> SYS_REG_ROW_3_4_SHIFT(ch) &
+ SYS_REG_ROW_3_4_MASK;
- if (rank > 1)
- chipsize_mb += chipsize_mb >> (cs0_row - cs1_row);
- if (row_3_4)
- chipsize_mb = chipsize_mb * 3 / 4;
- size_mb += chipsize_mb;
- debug("rank %d col %d bk %d cs0_row %d bw %d row_3_4 %d\n",
- rank, col, bk, cs0_row, bw, row_3_4);
+ chipsize_mb = (1 << (cs0_row + col + bk + bw - 20));
+
+ if (rank > 1)
+ chipsize_mb += chipsize_mb >> (cs0_row -
cs1_row);
+ if (row_3_4)
+ chipsize_mb = chipsize_mb * 3 / 4;
+ size_mb += chipsize_mb;
+ debug("rank %d col %d bk %d cs0_row %d bw %d row_3_4
%d\n",
+ rank, col, bk, cs0_row, bw, row_3_4);
+ }
+
+ /*
+* we use the 0x~0xfeff space
+* since 0xff00~0x is soc register space
+* so we reserve it
+*/
+ size_mb = min(size_mb, 0xff00/SZ_1M);
}
return (size_t)size_mb << 20;
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] sf: Add GigaDevice gd25q32b entry
Add entry for GigaDevice gd25q32b part.
Signed-off-by: Marty E. Plummer <hanet...@startmail.com>
---
drivers/mtd/spi/spi_flash_ids.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
index ef55abb01d..de940645ed 100644
--- a/drivers/mtd/spi/spi_flash_ids.c
+++ b/drivers/mtd/spi/spi_flash_ids.c
@@ -63,6 +63,7 @@ const struct spi_flash_info spi_flash_ids[] = {
{"en25s64",INFO(0x1c3817, 0x0, 64 * 1024, 128, 0) },
#endif
#ifdef CONFIG_SPI_FLASH_GIGADEVICE /* GIGADEVICE */
+ {"gd25q32b", INFO(0xc84016, 0x0, 64 * 1024,64, SECT_4K) },
{"gd25q64b", INFO(0xc84017, 0x0, 64 * 1024, 128, SECT_4K) },
{"gd25lq32", INFO(0xc86016, 0x0, 64 * 1024,64, SECT_4K) },
#endif
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/3] add support for the asus C201 chromebook (4GiB)
Build and boot tested on my chromebook, which was generously altered by Simon Glass to have a servo header and also generously provided a servo board itself to do debugging with. It ''works'', but has a few oddities. I can't seem to get it to see my external sdcard or a usb flash drive, so I've been having to ymodem my kernel, fdt, and initramfs over to test booting (which does work). The screen is a bit inconsistent on whether or not it activates any given power cycle, but when it does work, it works right. The changes to sdram_common.c were taken from coreboot, as it has otherwise identical code (minus the if (!size_mb) block), and actually works on my hardware. Marty E. Plummer (3): sf: Add GigaDevice gd25q32b entry rockchip: add support for veyron-speedy (ASUS Chromebook C201) rockchip: fix incorrect detection of ram size arch/arm/dts/Makefile | 1 + arch/arm/dts/rk3288-veyron-speedy.dts | 189 ++ arch/arm/mach-rockchip/rk3288-board-spl.c | 3 +- arch/arm/mach-rockchip/rk3288/Kconfig | 11 ++ arch/arm/mach-rockchip/sdram_common.c | 62 --- board/google/veyron/Kconfig | 16 ++ configs/chromebook_speedy_defconfig | 96 +++ drivers/mtd/spi/spi_flash_ids.c | 1 + 8 files changed, 353 insertions(+), 26 deletions(-) create mode 100644 arch/arm/dts/rk3288-veyron-speedy.dts create mode 100644 configs/chromebook_speedy_defconfig -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,RFC] rockchip: asus c201 support
So, regarding my old patchset. Thanks to the generous support of Simon, I have been able to use a google servo board to obtain an output log of my boot failure. Whereas Simon got the following: U-Boot SPL 2017.11-rc2-00017-g6cda208-dirty (Oct 19 2017 - 17:20:26) Trying to boot from SPI U-Boot 2017.11-rc2-00017-g6cda208-dirty (Oct 19 2017 - 17:20:26 -0600) Model: Google Speedy DRAM: 2 GiB MMC: dwmmc@ff0c: 1, dwmmc@ff0d: 2, dwmmc@ff0f: 0 Using default environment In:cros-ec-keyb Out: vidconsole Err: vidconsole Model: Google Speedy Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 => On his 2 GiB Asus C201, I only get the following: U-Boot SPL 2017.11-rc2-00017-g6cda208-dirty (Oct 19 2017 - 17:20:26) Trying to boot from SPI U-Boot 2017.11-rc2-00017-g6cda208-dirty (Oct 19 2017 - 17:20:26 -0600) Model: Google Speedy DRAM: 0 Bytes Further, after rebasing my patch against master to commit ec1754f091c3c06d76592a3f9fecf6184f27e4c9 I don't get any output at all, except for one of those unicode mojibake characters everytime I hit the servo reset button. It seems somewhere along the lines between 0def58f7fd (upstream/master) Merge git://git.denx.de/u-boot-x86 and ec1754f091 (upstream/master) Prepare v2018.05-rc3 something went funky. If someone with one of the supported rockchip chromebooks could dry the above commit I would greatly appreciate it. Regards, Marty ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH] rockchip: asus c201 support
From: "Marty E. Plummer" <hanet...@protonmail.com>
I realize this patch is not up to standards for the sake of mainlining
right now, but I'm mostly interested in getting some feedback on how
to make it work before getting into the nicities of mainline inclusion.
As of right now the bulk of this is the rk3288-veyron-speedy.dts file,
which I assume has a similar enough boot system to the jerry and minnie.
If the resultant u-boot-spl.bin and u-boot-dtb.img are prepared according
to the instructions in doc/README.rockchip and then flashed to the c201's
spi memory I get very little in the way of result; the most I/O that to
be seen is the board reacts to the power switch (led on, led off). I can
not seem to get it to output the u-boot console to the built-in screen,
and currently do not have a mini-hdmi cable to see if that is working or
not (one is ordered, arrives thursday). Can't find a location to purchase
a servo board for better debugging possibilities.
I was hoping someone on this mailing list could assist me in getting this
to work; once a working setup is figured I'll do proper patchset for
mainline inclusion.
Regards,
Marty
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3288-veyron-speedy.dts | 203 ++
arch/arm/mach-rockchip/rk3288-board-spl.c | 3 +-
arch/arm/mach-rockchip/rk3288/Kconfig | 11 ++
board/google/veyron/Kconfig | 16 +++
configs/chromebook_speedy_defconfig | 92 ++
drivers/mtd/spi/spi_flash_ids.c | 1 +
7 files changed, 326 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/rk3288-veyron-speedy.dts
create mode 100644 configs/chromebook_speedy_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7c062f0cad..c8630889dc 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -41,6 +41,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-veyron-jerry.dtb \
rk3288-veyron-mickey.dtb \
rk3288-veyron-minnie.dtb \
+ rk3288-veyron-speedy.dtb \
rk3288-vyasa.dtb \
rk3328-evb.dtb \
rk3368-lion.dtb \
diff --git a/arch/arm/dts/rk3288-veyron-speedy.dts
b/arch/arm/dts/rk3288-veyron-speedy.dts
new file mode 100644
index 00..51e155d141
--- /dev/null
+++ b/arch/arm/dts/rk3288-veyron-speedy.dts
@@ -0,0 +1,203 @@
+/*
+ * Google Veyron Speedy Rev 1+ board device tree source
+ *
+ * Copyright 2015 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+/dts-v1/;
+#include
+#include
+#include
+#include "rk3288-veyron-chromebook.dtsi"
+#include "cros-ec-sbs.dtsi"
+
+/ {
+ model = "Google Jerry";
+ compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8",
+"google,veyron-speedy-rev7", "google,veyron-speedy-rev6",
+"google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
+"google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
+"google,veyron-speedy", "google,veyron", "rockchip,rk3288";
+
+/* chosen { */
+/* stdout-path = */
+/* }; */
+
+ panel_regulator: panel-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < RK_PB6 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_enable_h>;
+ regulator-name = "panel_regulator";
+ vin-supply = <_sys>;
+ };
+
+ vcc18_lcd: vcc18-lcd {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < RK_PB5 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_1v8_disp_en>;
+ regulator-name = "vcc18_lcd";
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <_wl>;
+ };
+
+ backlight_regulator: backlight-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = < RK_PB4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pwr_en>;
+ regulator-name = "backlight_regulator";
+ vin-supply = <_sys>;
+ startup-delay-us = <15000>;
+ };
+};
+
+ {
+ rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
+ 0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
+ 0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
+ 0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4
+ 0x8 0x1f4>;
+ rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
+
