[PATCH V2 2/2] clk: imx8mm: Add qspi clock
Add qspi clock
Signed-off-by: Peng Fan
---
V2:
Split a single patch from
https://patchwork.ozlabs.org/project/uboot/patch/20200503125956.6244-1-peng@nxp.com/
drivers/clk/imx/clk-imx8mm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index d609fad7ac..4743394069 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -119,6 +119,9 @@ static const char *imx8mm_wdog_sels[] = {"clock-osc-24m",
"sys_pll1_133m", "sys_
static const char *imx8mm_usdhc3_sels[] = {"clock-osc-24m", "sys_pll1_400m",
"sys_pll1_800m", "sys_pll2_500m",
"sys_pll3_out", "sys_pll1_266m",
"audio_pll2_clk", "sys_pll1_100m", };
+static const char *imx8mm_qspi_sels[] = {"clock-osc-24m", "sys_pll1_400m",
"sys_pll2_333m", "sys_pll2_500m",
+ "audio_pll2_out", "sys_pll1_266m",
"sys_pll3_out", "sys_pll1_100m", };
+
static ulong imx8mm_clk_get_rate(struct clk *clk)
{
struct clk *c;
@@ -373,6 +376,8 @@ static int imx8mm_clk_probe(struct udevice *dev)
clk_dm(IMX8MM_CLK_USDHC3,
imx8m_clk_composite("usdhc3", imx8mm_usdhc3_sels,
base + 0xbc80));
+ clk_dm(IMX8MM_CLK_QSPI,
+ imx8m_clk_composite("qspi", imx8mm_qspi_sels, base + 0xab80));
clk_dm(IMX8MM_CLK_I2C1_ROOT,
imx_clk_gate4("i2c1_root_clk", "i2c1", base + 0x4170, 0));
@@ -396,6 +401,8 @@ static int imx8mm_clk_probe(struct udevice *dev)
imx_clk_gate4("wdog3_root_clk", "wdog", base + 0x4550, 0));
clk_dm(IMX8MM_CLK_USDHC3_ROOT,
imx_clk_gate4("usdhc3_root_clk", "usdhc3", base + 0x45e0, 0));
+ clk_dm(IMX8MM_CLK_QSPI_ROOT,
+ imx_clk_gate4("qspi_root_clk", "qspi", base + 0x42f0, 0));
/* clks not needed in SPL stage */
#ifndef CONFIG_SPL_BUILD
--
2.16.4
[PATCH V2 1/2] clk: imx8mm: fix clk set parent
Fix clk set parent, so we could still have correct clocks after
parent changing.
Signed-off-by: Peng Fan
---
V2:
Split fix into a single patch of
https://patchwork.ozlabs.org/project/uboot/patch/20200503125956.6244-1-peng@nxp.com/
drivers/clk/imx/clk-imx8mm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index 66c9601b0c..d609fad7ac 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -191,7 +191,10 @@ static int imx8mm_clk_set_parent(struct clk *clk, struct
clk *parent)
if (ret)
return ret;
- return clk_set_parent(c, cp);
+ ret = clk_set_parent(c, cp);
+ c->dev->parent = cp->dev;
+
+ return ret;
}
static struct clk_ops imx8mm_clk_ops = {
--
2.16.4
[PATCH 1/1] crypto/fsl: correct printf() statement.
The sequence of arguments should match the format string.
For printing unsigned numbers we should use %u.
Signed-off-by: Heinrich Schuchardt
---
drivers/crypto/fsl/jobdesc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/fsl/jobdesc.c b/drivers/crypto/fsl/jobdesc.c
index decde64078..fbc1aeddee 100644
--- a/drivers/crypto/fsl/jobdesc.c
+++ b/drivers/crypto/fsl/jobdesc.c
@@ -102,8 +102,8 @@ int caam_page_alloc(uint8_t page_num, uint8_t partition_num)
/* if the page is not owned => problem */
if ((temp_reg & SMCSJR_PO) != PAGE_OWNED) {
- printf("Allocation of page %d in partition %d failed 0x%X\n",
- temp_reg, page_num, partition_num);
+ printf("Allocation of page %u in partition %u failed 0x%X\n",
+ page_num, partition_num, temp_reg);
return ERROR_IN_PAGE_ALLOC;
}
--
2.20.1
[PATCH 1/1] crypto/fsl: unused value in caam_hash_update()
The value 0 assigned to final is overwritten before ever being used.
Remove the assignment.
Signed-off-by: Heinrich Schuchardt
---
drivers/crypto/fsl/fsl_hash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/fsl/fsl_hash.c b/drivers/crypto/fsl/fsl_hash.c
index 953deec9ff..61f953e8a6 100644
--- a/drivers/crypto/fsl/fsl_hash.c
+++ b/drivers/crypto/fsl/fsl_hash.c
@@ -86,7 +86,7 @@ static int caam_hash_update(void *hash_ctx, const void *buf,
unsigned int size, int is_last,
enum caam_hash_algos caam_algo)
{
- uint32_t final = 0;
+ uint32_t final;
phys_addr_t addr = virt_to_phys((void *)buf);
struct sha_ctx *ctx = hash_ctx;
--
2.20.1
[PATCH 1/1] fs: error handling in do_load()
If a file cannot be loaded, show an error message.
Set the EFI boot device only after successfully loading a file.
Signed-off-by: Heinrich Schuchardt
---
fs/fs.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/fs/fs.c b/fs/fs.c
index ad4caaeb1e..12fa5a6489 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -715,15 +715,18 @@ int do_load(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[],
else
pos = 0;
-#ifdef CONFIG_CMD_BOOTEFI
- efi_set_bootdev(argv[1], (argc > 2) ? argv[2] : "",
- (argc > 4) ? argv[4] : "");
-#endif
time = get_timer(0);
ret = _fs_read(filename, addr, pos, bytes, 1, &len_read);
time = get_timer(time);
- if (ret < 0)
+ if (ret < 0) {
+ printf("Failed to load '%s'\n", filename);
return 1;
+ }
+
+#ifdef CONFIG_CMD_BOOTEFI
+ efi_set_bootdev(argv[1], (argc > 2) ? argv[2] : "",
+ (argc > 4) ? argv[4] : "");
+#endif
printf("%llu bytes read in %lu ms", len_read, time);
if (time > 0) {
--
2.27.0
RE: [PATCH v6 3/4] riscv: cpu: correctly handle the setting of CPU_FEAT_MMU bit
Hi, > -Original Message- > From: Bin Meng > Sent: Friday, June 26, 2020 6:50 PM > To: Sagar Kadam > Cc: U-Boot Mailing List ; Rick Chen > ; Bin Meng ; Jagan Teki > ; Pragnesh Patel > ; Anup Patel ; Simon > Glass ; Ye Li ; Peng Fan > ; Sean Anderson > Subject: Re: [PATCH v6 3/4] riscv: cpu: correctly handle the setting of > CPU_FEAT_MMU bit > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On Fri, Jun 26, 2020 at 8:41 PM Sagar Shrikant Kadam > wrote: > > > > The conditional check to read "mmu-type" from the device tree > > is not rightly handled due to which the cpu feature doesn't include > > CPU_FEAT_MMU even if it's corresponding entry is present in the device > > tree. > > > > The initialization of cpu features is now taken care in cpu-uclass > > driver, so no need to zero out cpu_freq in riscv_cpu driver and can be > > removed. > > > > Signed-off-by: Sagar Shrikant Kadam > > Reviewed-by: Pragnesh Patel > > --- > > drivers/cpu/riscv_cpu.c | 5 + > > 1 file changed, 1 insertion(+), 4 deletions(-) > > > > Reviewed-by: Bin Meng Thanks Bin. BR, Sagar
RE: [PATCH v6 2/4] uclass: cpu: fix to display proper CPU features
Hi Bin,
> -Original Message-
> From: Bin Meng
> Sent: Friday, June 26, 2020 6:50 PM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Rick Chen
> ; Bin Meng ; Jagan Teki
> ; Pragnesh Patel
> ; Anup Patel ; Simon
> Glass ; Ye Li ; Peng Fan
> ; Sean Anderson
> Subject: Re: [PATCH v6 2/4] uclass: cpu: fix to display proper CPU features
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> Hi Sagar,
>
> On Fri, Jun 26, 2020 at 8:40 PM Sagar Shrikant Kadam
> wrote:
> >
> > The cmd "cpu detail" fetches uninitialized cpu feature information and
> > thus displays wrong / inconsitent details as below.
> > For eg: FU540-C000 doesn't have any microcode, yet the cmd display's it.
> >
> > => cpu detail
> > 1: cpu@1 rv64imafdc
> > ID = 1, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID
> > Microcode version 0x0
> > Device ID 0x0
> > 2: cpu@2 rv64imafdc
> > ID = 2, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID
> > Microcode version 0x0
> > Device ID 0x0
> > 3: cpu@3 rv64imafdc
> > ID = 3, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID
> > Microcode version 0x0
> > Device ID 0x0
> > 4: cpu@4 rv64imafdc
> > ID = 4, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID
> > Microcode version 0x0
> > Device ID 0x0
> >
> > The L1 cache or MMU entry seen above is also displayed inconsistently.
> > So initialize cpu information to zero into cpu-uclass itself so that
> > similar issues can be avoided for other CPU drivers.
> >
> > We now see correct features as:
> > => cpu detail
> > 1: cpu@1 rv64imafdc
> > ID = 1, freq = 999.100 MHz
> > 2: cpu@2 rv64imafdc
> > ID = 2, freq = 999.100 MHz
> > 3: cpu@3 rv64imafdc
> > ID = 3, freq = 999.100 MHz
> > 4: cpu@4 rv64imafdc
> > ID = 4, freq = 999.100 MHz
> >
> > Signed-off-by: Sagar Shrikant Kadam
> > Reviewed-by: Pragnesh Patel
> > ---
> > drivers/cpu/cpu-uclass.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/cpu/cpu-uclass.c b/drivers/cpu/cpu-uclass.c index
> > 7418c26..9f4a8fd 100644
> > --- a/drivers/cpu/cpu-uclass.c
> > +++ b/drivers/cpu/cpu-uclass.c
> > @@ -83,6 +83,9 @@ int cpu_get_info(struct udevice *dev, struct
> > cpu_info *info) {
> > struct cpu_ops *ops = cpu_get_ops(dev);
> >
> > + /* Init cpu_info to 0 */
> > + memset(info, 0, sizeof(struct cpu_info));
> > +
>
> nits: this should be put after the if() test logic below
>
Ok. I will submit it
> > if (!ops->get_info)
> > return -ENOSYS;
> >
> > --
>
> Other than that,
> Reviewed-by: Bin Meng
>
Thanks here.
BR,
Sagar
> Regards,
> Bin
[PATCH] x86: Don't build some unused objects in TPL
In the future if we have separate symbols for DM_SPI_FLASH and SPL_DM_SPI_FLASH we will not always have function declarations available for some DM calls. This in turn leads to build warnings but not failures as the code isn't used and is discarded at link time. Restructure things to not build code we won't use for TPL anyways. Cc: Bin Meng Signed-off-by: Tom Rini --- I ran in to this as part of testing http://patchwork.ozlabs.org/project/uboot/patch/20200604151153.3980-4-zhiqiang@nxp.com/ which we do need to bring in. I think we might be building a lot of codde that's then discarded for TPL builds, but didn't think this is the right place to tackle that in. --- arch/x86/cpu/apollolake/Makefile | 2 +- arch/x86/lib/Makefile| 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/cpu/apollolake/Makefile b/arch/x86/cpu/apollolake/Makefile index 3aa2a556765a..11621256aebc 100644 --- a/arch/x86/cpu/apollolake/Makefile +++ b/arch/x86/cpu/apollolake/Makefile @@ -3,7 +3,6 @@ # Copyright 2019 Google LLC obj-$(CONFIG_SPL_BUILD) += cpu_spl.o -obj-$(CONFIG_SPL_BUILD) += spl.o obj-$(CONFIG_SPL_BUILD) += systemagent.o obj-y += cpu_common.o @@ -12,6 +11,7 @@ obj-y += cpu.o obj-y += punit.o obj-y += fsp_bindings.o ifdef CONFIG_SPL_BUILD +obj-y += spl.o obj-y += fsp_m.o endif endif diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index 5cd458748038..1079bf20226a 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -22,7 +22,6 @@ obj-y += init_helpers.o obj-y += interrupts.o obj-y += lpc-uclass.o obj-y += mpspec.o -obj-$(CONFIG_ENABLE_MRC_CACHE) += mrccache.o obj-y += northbridge-uclass.o obj-$(CONFIG_I8259_PIC) += i8259.o obj-$(CONFIG_I8254_TIMER) += i8254.o @@ -45,9 +44,12 @@ ifndef CONFIG_SPL_BUILD obj-$(CONFIG_CMD_ZBOOT)+= zimage.o endif obj-$(CONFIG_USE_HOB) += hob.o +ifndef CONFIG_TPL_BUILD +obj-$(CONFIG_ENABLE_MRC_CACHE) += mrccache.o obj-$(CONFIG_HAVE_FSP) += fsp/ obj-$(CONFIG_FSP_VERSION1) += fsp1/ obj-$(CONFIG_FSP_VERSION2) += fsp2/ +endif ifdef CONFIG_SPL_BUILD ifdef CONFIG_TPL_BUILD -- 2.17.1
[PATCH] test/py: test_efi_fit: Update #size-cells to 1
From: Bin Meng
test_efi_fit tests fail on RISC-V currently. This is due to the
RISC-V arch_fixup_fdt() checks the #size-cells of the root node
in order to correctly fix up the reserved memory node.
Update #size-cells to 1 so tests can pass.
Signed-off-by: Bin Meng
---
test/py/tests/test_efi_fit.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/py/tests/test_efi_fit.py b/test/py/tests/test_efi_fit.py
index beaf4a3..3616e99 100644
--- a/test/py/tests/test_efi_fit.py
+++ b/test/py/tests/test_efi_fit.py
@@ -106,7 +106,7 @@ FDT_DATA = '''
/ {
#address-cells = <1>;
-#size-cells = <0>;
+#size-cells = <1>;
model = "%(sys-arch)s %(fdt_type)s EFI FIT Boot Test";
compatible = "%(sys-arch)s";
--
2.7.4
[PATCH] azure: gitlab: travis: Update OpenSBI used for RISC-V testing
From: Bin Meng
Change to use OpenSBI release v0.8 generic platform images for QEMU
RISC-V CI testing for azure, gitlab and travis-ci.
Signed-off-by: Bin Meng
---
Depends on the following 2 patches:
- "fdtdec: Honor #address-cells and #size-cells in fdtdec_add_reserved_memory()"
which is currently in the u-boot/next tree
- "test/py: test_efi_fit: Update #size-cells to 1"
http://patchwork.ozlabs.org/project/uboot/patch/1593259920-32256-1-git-send-email-bmeng...@gmail.com/
.azure-pipelines.yml | 8
.gitlab-ci.yml | 8
.travis.yml | 8
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 28387ce..421953c 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -283,12 +283,12 @@ jobs:
cp /opt/grub/grubaa64.efi ~/grub_arm64.efi
cp /opt/grub/grubarm.efi ~/grub_arm.efi
if [[ "${TEST_PY_BD}" == "qemu-riscv32_spl" ]]; then
- wget -O -
https://github.com/riscv/opensbi/releases/download/v0.6/opensbi-0.6-rv32-bin.tar.xz
| tar -C /tmp -xJ;
- export
OPENSBI=/tmp/opensbi-0.6-rv32-bin/platform/qemu/virt/firmware/fw_dynamic.bin;
+ wget -O -
https://github.com/riscv/opensbi/releases/download/v0.8/opensbi-0.8-rv-bin.tar.xz
| tar -C /tmp -xJ;
+ export
OPENSBI=/tmp/opensbi-0.8-rv-bin/share/opensbi/ilp32/generic/firmware/fw_dynamic.bin;
fi
if [[ "${TEST_PY_BD}" == "qemu-riscv64_spl" ]]; then
- wget -O -
https://github.com/riscv/opensbi/releases/download/v0.6/opensbi-0.6-rv64-bin.tar.xz
| tar -C /tmp -xJ;
- export
OPENSBI=/tmp/opensbi-0.6-rv64-bin/platform/qemu/virt/firmware/fw_dynamic.bin;
+ wget -O -
https://github.com/riscv/opensbi/releases/download/v0.8/opensbi-0.8-rv-bin.tar.xz
| tar -C /tmp -xJ;
+ export
OPENSBI=/tmp/opensbi-0.8-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin;
fi
# the below corresponds to .gitlab-ci.yml "script"
cd ${WORK_DIR}
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index f2e491c..d83e72b 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -25,12 +25,12 @@ stages:
- cp /opt/grub/grubaa64.efi ~/grub_arm64.efi
- cp /opt/grub/grubarm.efi ~/grub_arm.efi
- if [[ "${TEST_PY_BD}" == "qemu-riscv32_spl" ]]; then
-wget -O -
https://github.com/riscv/opensbi/releases/download/v0.6/opensbi-0.6-rv32-bin.tar.xz
| tar -C /tmp -xJ;
-export
OPENSBI=/tmp/opensbi-0.6-rv32-bin/platform/qemu/virt/firmware/fw_dynamic.bin;
+wget -O -
https://github.com/riscv/opensbi/releases/download/v0.8/opensbi-0.8-rv-bin.tar.xz
| tar -C /tmp -xJ;
+export
OPENSBI=/tmp/opensbi-0.8-rv-bin/share/opensbi/ilp32/generic/firmware/fw_dynamic.bin;
fi
- if [[ "${TEST_PY_BD}" == "qemu-riscv64_spl" ]]; then
-wget -O -
https://github.com/riscv/opensbi/releases/download/v0.6/opensbi-0.6-rv64-bin.tar.xz
| tar -C /tmp -xJ;
-export
OPENSBI=/tmp/opensbi-0.6-rv64-bin/platform/qemu/virt/firmware/fw_dynamic.bin;
+wget -O -
https://github.com/riscv/opensbi/releases/download/v0.8/opensbi-0.8-rv-bin.tar.xz
| tar -C /tmp -xJ;
+export
OPENSBI=/tmp/opensbi-0.8-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin;
fi
after_script:
diff --git a/.travis.yml b/.travis.yml
index bb02b6d..a11b972 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -204,12 +204,12 @@ before_script:
popd;
fi
- if [[ "${TEST_PY_BD}" == "qemu-riscv32_spl" ]]; then
- wget -O -
https://github.com/riscv/opensbi/releases/download/v0.6/opensbi-0.6-rv32-bin.tar.xz
| tar -C /tmp -xJ;
- export
OPENSBI=/tmp/opensbi-0.6-rv32-bin/platform/qemu/virt/firmware/fw_dynamic.bin;
+ wget -O -
https://github.com/riscv/opensbi/releases/download/v0.8/opensbi-0.8-rv-bin.tar.xz
| tar -C /tmp -xJ;
+ export
OPENSBI=/tmp/opensbi-0.8-rv-bin/share/opensbi/ilp32/generic/firmware/fw_dynamic.bin;
fi
- if [[ "${TEST_PY_BD}" == "qemu-riscv64_spl" ]]; then
- wget -O -
https://github.com/riscv/opensbi/releases/download/v0.6/opensbi-0.6-rv64-bin.tar.xz
| tar -C /tmp -xJ;
- export
OPENSBI=/tmp/opensbi-0.6-rv64-bin/platform/qemu/virt/firmware/fw_dynamic.bin;
+ wget -O -
https://github.com/riscv/opensbi/releases/download/v0.8/opensbi-0.8-rv-bin.tar.xz
| tar -C /tmp -xJ;
+ export
OPENSBI=/tmp/opensbi-0.8-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin;
fi
script:
--
2.7.4
Re: rockchip: correctly set vop0 or vop1
+Andy Yan for this topic,
Hi Patrick and Arnaud,
I would like to leave this patch until the code fits for all the socs,
Thanks,
- Kever
On 2020/6/8 下午8:39, Patrick Wildt wrote:
On Mon, Jun 08, 2020 at 02:24:32PM +0200, Arnaud Patard wrote:
Patrick Wildt writes:
On Mon, Jun 08, 2020 at 10:18:19AM +0200, Arnaud Patard wrote:
Patrick Wildt writes:
Hi,
The EDP_LCDC_SEL bit has to be set correctly to select vop0 or
vop1, but so far we have set it in both conditions, which is not
correct.
Can someone verify this is the correct way round? vop1 -> set,
vop0 -> clear?
Signed-off-by: Patrick Wildt
diff --git a/drivers/video/rockchip/rk_edp.c b/drivers/video/rockchip/rk_edp.c
index 92188be9275..000bd481408 100644
--- a/drivers/video/rockchip/rk_edp.c
+++ b/drivers/video/rockchip/rk_edp.c
@@ -1062,7 +1062,8 @@ static int rk_edp_probe(struct udevice *dev)
rk_setreg(&priv->grf->soc_con12, 1 << 4);
/* select epd signal from vop0 or vop1 */
- rk_setreg(&priv->grf->soc_con6, (vop_id == 1) ? (1 << 5) : (1 << 5));
+ rk_clrsetreg(&priv->grf->soc_con6, (1 << 5),
+ (vop_id == 1) ? (1 << 5) : (0 << 5));
While working on PBP EDP support, found this too but I'm not sure it's
fine or not. For rk3399, my (not yet published) patch is doing:
+ if (vop_id == 0)
+ rk_clrreg(&priv->grf->soc_con20, (1 << 5));
+ else
+ rk_setreg(&priv->grf->soc_con20, (1 << 5));
I believe that the rk3288 may need similar treatment but I've yet to
look at the rk3288 manual.
Arnaud
Yes, it does. If you look at the linux code, they have:
static const struct rockchip_dp_chip_data rk3399_edp = {
.lcdsel_grf_reg = RK3399_GRF_SOC_CON20,
.lcdsel_big = HIWORD_UPDATE(0, RK3399_EDP_LCDC_SEL),
.lcdsel_lit = HIWORD_UPDATE(RK3399_EDP_LCDC_SEL, RK3399_EDP_LCDC_SEL),
.chip_type = RK3399_EDP,
};
static const struct rockchip_dp_chip_data rk3288_dp = {
.lcdsel_grf_reg = RK3288_GRF_SOC_CON6,
.lcdsel_big = HIWORD_UPDATE(0, RK3288_EDP_LCDC_SEL),
.lcdsel_lit = HIWORD_UPDATE(RK3288_EDP_LCDC_SEL, RK3288_EDP_LCDC_SEL),
.chip_type = RK3288_DP,
};
which indicates that for rk3399 *and* rk3288 the bit has to be set to
select "lit". Now your diff looks equivalent to mine, apart from using
a different operation to achieve the same goal.
The linux code does
ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder);
if (ret < 0)
return;
if (ret)
val = dp->data->lcdsel_lit;
else
val = dp->data->lcdsel_big;
Assuming that endpoint_id essentiall returns vop id 0 or vop id 1, this
would mean that vop1 -> lit -> set bit and vop0 -> big -> clr bit.
That said, my diff seems to be fine, and your RK3399 code as well. Do
you agree?
According to the code you've shown, it should be fine for rk3288 I guess
but not for rk3399. Please note that it's grf soc_con6 register for rk3288
but grf soc_con20 for rk3399.
Arnaud
Exactly, which is why you had that if defined() in your diff, to compile
one part of the code for RK3288, and the other for RK3399. :) The bit
though happens to be the same.
Re: [PATCH] rockchip: Add delay after link-training
Hi Kurt, On 2020/6/4 上午5:17, Peter Geis wrote: On Tue, Jun 2, 2020 at 11:12 AM Kurt Miller wrote: On Tue, 2020-06-02 at 10:23 +0800, Shawn Lin wrote: 在 2020/6/2 9:59, Kever Yang 写道: Hi Kurt, On 2020/6/2 上午4:30, Kurt Miller wrote: On at least the RockPro64, many cards will trip a synchronous abort when first accessing PCIe config space during bus scanning. A delay after link training allows some of these cards to function. Signed-off-by: Kurt Miller --- On the RockPro64, some pci cards trip a synchronous abort when scanning the pci bus. For example with HighPoint Rocket Raid 640L which is based on Marvell 88SE9230 I see this: => pci "Synchronous Abort" handler, esr 0x96000210 elr: 0022d034 lr : 0022cfd0 (reloc) elr: f4568034 lr : f4567fd0 x0 : 0010 x1 : f800 x2 : x3 : 0010 x4 : f2559290 x5 : x6 : 0001 x7 : f2559860 x8 : 0030 x9 : 0008 x10: 0010 x11: f251fd1c x12: 1421 x13: 1468 x14: f251fd4c x15: x16: 00060001 x17: 001f x18: f2532dc0 x19: f251fcd0 x20: 0001 x21: x22: 0001 x23: f45d4000 x24: x25: f45bc000 x26: x27: x28: f2541440 x29: f251fc20 Code: 54c1 35a5 93407c00 f9400081 (b8616800) Resetting CPU ... Adding a delay after link training works-around the problem. I added this delay to the OpenBSD rkpcie driver as well: https://github.com/openbsd/src/commit/9857dee3520d8ca5bec68538f4b0708d7e64fc87 HighPoint Rocket Raid 640L needs a 1.75 sec delay and Crossfield SAS9211-4i needs a 1 second delay, so I arbitrarily decided on 2 seconds. The delay work-around was originally discovered by nuumio: https://github.com/nuumio/linux-kernel/commit/5a65b17686002dc84d461bffa324a2cb68e67aee drivers/pci/pcie_rockchip.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/pci/pcie_rockchip.c b/drivers/pci/pcie_rockchip.c index 0edc2464a8..51cfbf6b18 100644 --- a/drivers/pci/pcie_rockchip.c +++ b/drivers/pci/pcie_rockchip.c @@ -288,6 +288,14 @@ static int rockchip_pcie_init_port(struct udevice *dev) goto err_power_off_phy; } +/* + * XXX: On at least the RockPro64, many cards will trip a + * synchronous abort when first accessing PCIe config space + * during bus scanning. A delay after link training allows + * some of these cards to function. + */ +mdelay(2000); I don't understand what kind of delay for init needs 2 Seconds, root cause will preferred. Hi Kever, While working on this issue for the OpenBSD PCIe driver I was not able to determine the root cause. I tested the following adapters: ROCKPro64 2 Port SATA StarTech PEXSAT32 2 Port SATA Samsung 970 Evo NVMe w/m.2 adapter IO CREST SI-PEX40148 2 Port SATA IO CREST SI-PEX40057 4 port HighPoint Rocket Raid 640L Crossfield SAS9211-4i Del PERC H200 Dell PERC 6/i Intel Gigabit VT Quad Port Server All of the above adapters successfully link trained, however three of them would panic upon the first read of the PCI config space. nuumio's work-around of placing a delay after link-training allows these cards to work. HighPoint Rocket Raid 640L ~1.75 sec delay Crossfield SAS9211-4i ~1 sec delay Dell PERC H200 ~1 sec delay In attempt to determine if there was a way to detect how long to wait, I compared every status and debug register documented in the rk3399 TRM part 2 for the PCI controller. I compared the values pre-delay and post-delay. I was not able to find a value that would indicate it was safe to proceed. Strictly speaking, how long should we need for this had been provided, see this: https://patchwork.kernel.org/patch/11561977/ I can accept the same fix like kernel which is 100ms, but 2 Second is really too much for most cases. Thanks, - Kever If you need more delay, I highly suspect you should check if the power supply is stable before enabling training. Hi Shawn, Thank you for pointing out the need for the 100ms delay before beginning link-training. I believe this is to correct link training failures, while the delay after link training is to work-around post link training reading of PCI config space on certain cards. There are similar issues on the Linux driver with various cards randomly throwing an abort. If it is power, a 2 second wait to allow cards to stabilize after power on might be wise for the Linux driver as well. I imagine some cards take longer to complete power on reset than others, and attempting to read them immediately after powering them up could be the issue here. In my testing I discussed above, I suspected that power was a likely cause. The HighPoint Rocket Raid 640L is a good test card because it documents its 3.3v power at 0.7 watts: https://highpoint-
Re: [PATCH] x86: Don't build some unused objects in TPL
+Simon, On Sat, Jun 27, 2020 at 8:00 PM Tom Rini wrote: > > In the future if we have separate symbols for DM_SPI_FLASH and > SPL_DM_SPI_FLASH we will not always have function declarations available > for some DM calls. This in turn leads to build warnings but not > failures as the code isn't used and is discarded at link time. > Restructure things to not build code we won't use for TPL anyways. > > Cc: Bin Meng > Signed-off-by: Tom Rini > --- > I ran in to this as part of testing > http://patchwork.ozlabs.org/project/uboot/patch/20200604151153.3980-4-zhiqiang@nxp.com/ > which we do need to bring in. I think we might be building a lot of > codde that's then discarded for TPL builds, but didn't think this is the > right place to tackle that in. > --- > arch/x86/cpu/apollolake/Makefile | 2 +- > arch/x86/lib/Makefile| 4 +++- > 2 files changed, 4 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH] test/py: test_efi_fit: Update #size-cells to 1
On 6/27/20 2:12 PM, Bin Meng wrote:
> From: Bin Meng
>
> test_efi_fit tests fail on RISC-V currently. This is due to the
> RISC-V arch_fixup_fdt() checks the #size-cells of the root node
> in order to correctly fix up the reserved memory node.
>
> Update #size-cells to 1 so tests can pass.
>
> Signed-off-by: Bin Meng
> ---
>
> test/py/tests/test_efi_fit.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/test/py/tests/test_efi_fit.py b/test/py/tests/test_efi_fit.py
> index beaf4a3..3616e99 100644
> --- a/test/py/tests/test_efi_fit.py
> +++ b/test/py/tests/test_efi_fit.py
> @@ -106,7 +106,7 @@ FDT_DATA = '''
>
> / {
> #address-cells = <1>;
> -#size-cells = <0>;
> +#size-cells = <1>;
As you describe above the test failed for RISC-V because the #size-cells
property is incorrect for the /reserved-memory node.
Changing the #size-cells property here does not solve the underlying
problem that the code inserting a /reserved-memory node has a bug. That
code should insert properties #address-cells and #size-cells as needed
into the /reserved-memory node itself.
Have you been able to figure out where the /reserved-memory node is created?
In the resulting device tree check that #size-cells remains <0> for the
/reset@0 node.
Best regards
Heinrich
>
> model = "%(sys-arch)s %(fdt_type)s EFI FIT Boot Test";
> compatible = "%(sys-arch)s";
>
Re: [PATCH] rockchip: rockpro64: initialize USB in preboot【请注意，邮件由u-boot-boun...@lists.denx.de代发】
On 2020/6/4 上午11:09, Kever Yang wrote: On 2020/6/3 下午11:44, Marcin Juszkiewicz wrote: With video output enabled and USB keyboard supported there is no need for serial console. So let initialize USB subsystem so keyboard connected to board (either directly or via hub) can be used to interrupt autoboot. U-Boot TPL 2020.07-rc3-00123-g52d6cbd1a7 (Jun 03 2020 - 17:34:20) Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB Channel 1: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB 256B stride 256B stride lpddr4_set_rate: change freq to 4 mhz 0, 1 lpddr4_set_rate: change freq to 8 mhz 1, 0 Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2020.07-rc3-00123-g52d6cbd1a7 (Jun 03 2020 - 17:34:20 +0200) Trying to boot from SPI U-Boot 2020.07-rc3-00123-g52d6cbd1a7 (Jun 03 2020 - 17:34:20 +0200) SoC: Rockchip rk3399 Reset cause: RST Model: Pine64 RockPro64 v2.1 DRAM: 3.9 GiB PMIC: RK808 MMC: mmc@fe31: 2, mmc@fe32: 1, sdhci@fe33: 0 Loading Environment from SPI Flash... SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB OK In: serial Out: vidconsole Err: vidconsole Model: Pine64 RockPro64 v2.1 Net: eth0: ethernet@fe30 starting USB... Bus usb@fe38: USB EHCI 1.00 Bus usb@fe3a: USB OHCI 1.0 Bus usb@fe3c: USB EHCI 1.00 Bus usb@fe3e: USB OHCI 1.0 Bus dwc3: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 Bus dwc3: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe38 for devices... 1 USB Device(s) found scanning bus usb@fe3a for devices... 1 USB Device(s) found scanning bus usb@fe3c for devices... 1 USB Device(s) found scanning bus usb@fe3e for devices... 2 USB Device(s) found scanning bus dwc3 for devices... 1 USB Device(s) found scanning bus dwc3 for devices... 2 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0 => Signed-off-by: Marcin Juszkiewicz Reviewed-by: Kever Yang Applied to u-boot-rockchip next branch Thanks, - Kever --- configs/rockpro64-rk3399_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git configs/rockpro64-rk3399_defconfig configs/rockpro64-rk3399_defconfig index 807747485a..a56126b042 100644 --- configs/rockpro64-rk3399_defconfig +++ configs/rockpro64-rk3399_defconfig @@ -11,6 +11,8 @@ CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI_SUPPORT=y CONFIG_DEBUG_UART=y +CONFIG_USE_PREBOOT=y +CONFIG_PREBOOT="usb start" CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rockpro64.dtb" CONFIG_MISC_INIT_R=y CONFIG_DISPLAY_BOARDINFO_LATE=y
Re: [PATCH] rk3399: Add BOOTENV_SF command
Hi Tom,
On 2020/6/27 上午4:21, Tom Rini wrote:
On Thu, Jun 25, 2020 at 08:32:10PM +0530, Jagan Teki wrote:
On Mon, Jun 8, 2020 at 7:47 PM Jagan Teki wrote:
Add missing BOOTENV_SF command in rk3399 config.
Fix it.
Fixes: f263b860acf8 ("rk3399: Enable SF distro bootcmd")
Signed-off-by: Jagan Teki
Reported-by: Suniel Mahesh
Tested-by: Suniel Mahesh
---
Can someone push this fix patch to master?
Kever, do you want me to pick this up? Do you have some objection?
FWIW, include/configs/rk3399_common.h should get listed under some
MAINTAINER entry directly. Thanks!
I will apply this patch and send to fix RP.
Thanks,
- Kever
Re: [PATCH] rk3399: Add BOOTENV_SF command
On 2020/6/8 下午10:17, Jagan Teki wrote:
Add missing BOOTENV_SF command in rk3399 config.
Fix it.
Fixes: f263b860acf8 ("rk3399: Enable SF distro bootcmd")
Signed-off-by: Jagan Teki
Reported-by: Suniel Mahesh
Tested-by: Suniel Mahesh
Reviewed-by: Kever Yang
Thanks,
- Kever
---
include/configs/rk3399_common.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
index f0ae6e67a7..e63ebb14f7 100644
--- a/include/configs/rk3399_common.h
+++ b/include/configs/rk3399_common.h
@@ -67,6 +67,7 @@
"partitions=" PARTS_DEFAULT \
ROCKCHIP_DEVICE_SETTINGS \
BOOTENV \
+ BOOTENV_SF \
"altbootcmd=" \
"setenv boot_syslinux_conf extlinux/extlinux-rollback.conf;" \
"run distro_bootcmd\0"
Re: [PATCH] rk3399: Add BOOTENV_SF command
On 2020/6/8 下午10:17, Jagan Teki wrote:
Add missing BOOTENV_SF command in rk3399 config.
Fix it.
Fixes: f263b860acf8 ("rk3399: Enable SF distro bootcmd")
Signed-off-by: Jagan Teki
Reported-by: Suniel Mahesh
Tested-by: Suniel Mahesh
Applied to u-boot-rockchip master branch.
---
include/configs/rk3399_common.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
index f0ae6e67a7..e63ebb14f7 100644
--- a/include/configs/rk3399_common.h
+++ b/include/configs/rk3399_common.h
@@ -67,6 +67,7 @@
"partitions=" PARTS_DEFAULT \
ROCKCHIP_DEVICE_SETTINGS \
BOOTENV \
+ BOOTENV_SF \
"altbootcmd=" \
"setenv boot_syslinux_conf extlinux/extlinux-rollback.conf;" \
"run distro_bootcmd\0"
Re: [PATCH] rockchip: rk3188: Fix back to BROM boot
On 2020/6/22 下午9:19, Alexander Kochetkov wrote:
Move the setting for noc remap out of SPL code. Changing
noc remap inside SPL results in breaking back to BROM
boot.
Fixes commit c14fe2a8e192 ("rockchip: rk3188: Move SoC
one time setting into arch_cpu_init()").
Signed-off-by: Alexander Kochetkov
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/mach-rockchip/rk3188/rk3188.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3188/rk3188.c
b/arch/arm/mach-rockchip/rk3188/rk3188.c
index 1b012f7f67..4115f95d77 100644
--- a/arch/arm/mach-rockchip/rk3188/rk3188.c
+++ b/arch/arm/mach-rockchip/rk3188/rk3188.c
@@ -73,15 +73,32 @@ int arch_cpu_init(void)
BYPASSSEL_MASK | BYPASSDMEN_MASK,
1 << BYPASSSEL_SHIFT | 1 << BYPASSDMEN_SHIFT);
#endif
+ return 0;
+}
+#endif
+
+__weak int rk3188_board_late_init(void)
+{
+ return 0;
+}
+
+int rk_board_late_init(void)
+{
+ struct rk3188_grf *grf;
+
+ grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+ if (IS_ERR(grf)) {
+ pr_err("grf syscon returned %ld\n", PTR_ERR(grf));
+ return 0;
+ }
/* enable noc remap to mimic legacy loaders */
rk_clrsetreg(&grf->soc_con0,
NOC_REMAP_MASK << NOC_REMAP_SHIFT,
NOC_REMAP_MASK << NOC_REMAP_SHIFT);
- return 0;
+ return rk3188_board_late_init();
}
-#endif
#ifdef CONFIG_SPL_BUILD
static int setup_led(void)
Re: [PATCH] rockchip: rk3188: Fix back to BROM boot
On 2020/6/22 下午9:19, Alexander Kochetkov wrote:
Move the setting for noc remap out of SPL code. Changing
noc remap inside SPL results in breaking back to BROM
boot.
Fixes commit c14fe2a8e192 ("rockchip: rk3188: Move SoC
one time setting into arch_cpu_init()").
Signed-off-by: Alexander Kochetkov
Applied to u-boot-rockchip master branch.
---
arch/arm/mach-rockchip/rk3188/rk3188.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3188/rk3188.c
b/arch/arm/mach-rockchip/rk3188/rk3188.c
index 1b012f7f67..4115f95d77 100644
--- a/arch/arm/mach-rockchip/rk3188/rk3188.c
+++ b/arch/arm/mach-rockchip/rk3188/rk3188.c
@@ -73,15 +73,32 @@ int arch_cpu_init(void)
BYPASSSEL_MASK | BYPASSDMEN_MASK,
1 << BYPASSSEL_SHIFT | 1 << BYPASSDMEN_SHIFT);
#endif
+ return 0;
+}
+#endif
+
+__weak int rk3188_board_late_init(void)
+{
+ return 0;
+}
+
+int rk_board_late_init(void)
+{
+ struct rk3188_grf *grf;
+
+ grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+ if (IS_ERR(grf)) {
+ pr_err("grf syscon returned %ld\n", PTR_ERR(grf));
+ return 0;
+ }
/* enable noc remap to mimic legacy loaders */
rk_clrsetreg(&grf->soc_con0,
NOC_REMAP_MASK << NOC_REMAP_SHIFT,
NOC_REMAP_MASK << NOC_REMAP_SHIFT);
- return 0;
+ return rk3188_board_late_init();
}
-#endif
#ifdef CONFIG_SPL_BUILD
static int setup_led(void)
Re: [PATCH] rockchip: i2c: fix switch to new implementation for rk3188
+David,
Hi David,
Could you help to commend on this?
Hi Alex,
Thanks for your patch.
On 2020/6/22 下午9:06, Alexander Kochetkov wrote:
The commit e7ae4cf27a6d 'pinctrl: rockchip: Add common rockchip
pinctrl driver' dropped rk3188_pinctrl_request operation, that
did switching to new implementation.
This commit implement switching to new implementation using
writing bits to GRF.
I don't have rk3060
rk3066
board to test, so switching implemented
as a stub returning -ENOSYS.
Signed-off-by: Alexander Kochetkov
---
drivers/i2c/rk_i2c.c | 42 +++---
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/rk_i2c.c b/drivers/i2c/rk_i2c.c
index 32b2ee8578..ad3c66843b 100644
--- a/drivers/i2c/rk_i2c.c
+++ b/drivers/i2c/rk_i2c.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -41,6 +43,7 @@ enum {
*/
struct rk_i2c_soc_data {
int controller_type;
+ int (*switch_to_new_type)(int bus_nr);
};
static inline void rk_i2c_get_div(int div, int *divh, int *divl)
@@ -388,11 +391,33 @@ static int rockchip_i2c_ofdata_to_platdata(struct udevice
*bus)
return 0;
}
+static int rockchip_i2c_switch_to_new_type_rk3066(int bus_nr)
+{
+ return -ENOSYS;
+}
+
+static int rockchip_i2c_switch_to_new_type_rk3188(int bus_nr)
+{
+ struct rk3188_grf *grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+
+ if (grf == NULL)
+ return -ENOSYS;
+
+ if (bus_nr < 0 || bus_nr > (RKI2C4_SEL_SHIFT - RKI2C0_SEL_SHIFT))
+ return -EINVAL;
+
+ /* enable new i2c controller */
+ rk_clrsetreg(&grf->soc_con1,
+1 << (RKI2C0_SEL_SHIFT + bus_nr),
+1 << (RKI2C0_SEL_SHIFT + bus_nr));
+
+ return 0;
+}
+
static int rockchip_i2c_probe(struct udevice *bus)
{
struct rk_i2c *priv = dev_get_priv(bus);
struct rk_i2c_soc_data *soc_data;
- struct udevice *pinctrl;
int bus_nr;
int ret;
@@ -408,17 +433,10 @@ static int rockchip_i2c_probe(struct udevice *bus)
return ret;
}
- ret = uclass_get_device(UCLASS_PINCTRL, 0, &pinctrl);
- if (ret) {
- debug("%s: Cannot find pinctrl device\n", __func__);
- return ret;
- }
-
- /* pinctrl will switch I2C to new type */
- ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_I2C0 + bus_nr);
- if (ret) {
+ ret = soc_data->switch_to_new_type(bus_nr);
+ if (ret < 0) {
debug("%s: Failed to switch I2C to new type %s: %d\n",
- __func__, bus->name, ret);
+__func__, bus->name, ret);
return ret;
}
}
@@ -433,10 +451,12 @@ static const struct dm_i2c_ops rockchip_i2c_ops = {
static const struct rk_i2c_soc_data rk3066_soc_data = {
.controller_type = RK_I2C_LEGACY,
+ .switch_to_new_type = rockchip_i2c_switch_to_new_type_rk3066,
};
static const struct rk_i2c_soc_data rk3188_soc_data = {
.controller_type = RK_I2C_LEGACY,
+ .switch_to_new_type = rockchip_i2c_switch_to_new_type_rk3188,
};
static const struct rk_i2c_soc_data rk3228_soc_data = {
Re: [PATCH 1/3] rockchip: Pinebook Pro: enable rng to provide an entropy source
On 2020/6/9 上午6:50, Peter Robinson wrote:
Enable the rng so UEFI can provide entropy for KASLR
Signed-off-by: Peter Robinson
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi | 4
arch/arm/dts/rk3399-rockpro64-u-boot.dtsi| 4
configs/pinebook-pro-rk3399_defconfig| 2 ++
3 files changed, 10 insertions(+)
diff --git a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
index 1a2e24d3ef..296321d697 100644
--- a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
@@ -24,6 +24,10 @@
u-boot,dm-pre-reloc;
};
+&rng {
+ status = "okay";
+};
+
&sdhci {
max-frequency = <2500>;
u-boot,dm-pre-reloc;
diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
index bac09df4a3..cb8991aa25 100644
--- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
@@ -19,6 +19,10 @@
};
};
+&rng {
+ status = "okay";
+};
+
&spi1 {
spi_flash: flash@0 {
u-boot,dm-pre-reloc;
diff --git a/configs/pinebook-pro-rk3399_defconfig
b/configs/pinebook-pro-rk3399_defconfig
index 0c129b9aeb..21eecf477c 100644
--- a/configs/pinebook-pro-rk3399_defconfig
+++ b/configs/pinebook-pro-rk3399_defconfig
@@ -54,6 +54,8 @@ CONFIG_DM_PMIC_FAN53555=y
CONFIG_PMIC_RK8XX=y
CONFIG_REGULATOR_PWM=y
CONFIG_REGULATOR_RK8XX=y
+CONFIG_DM_RNG=y
+CONFIG_RNG_ROCKCHIP=y
CONFIG_PWM_ROCKCHIP=y
CONFIG_RAM_RK3399_LPDDR4=y
CONFIG_DM_RESET=y
Re: [PATCH 2/3] rockchip: Pinebook Pro: Fix USB and the USB attached keyboard
On 2020/6/9 上午6:50, Peter Robinson wrote: The built in keyboard on the Pinebook Pro is attached via USB so fix this up to ensure USB works as expected. Signed-off-by: Peter Robinson Reviewed-by: Kever Yang Thanks, - Kever --- configs/pinebook-pro-rk3399_defconfig | 5 + include/configs/pinebook-pro-rk3399.h | 3 +++ 2 files changed, 8 insertions(+) diff --git a/configs/pinebook-pro-rk3399_defconfig b/configs/pinebook-pro-rk3399_defconfig index 21eecf477c..733463556a 100644 --- a/configs/pinebook-pro-rk3399_defconfig +++ b/configs/pinebook-pro-rk3399_defconfig @@ -61,6 +61,8 @@ CONFIG_RAM_RK3399_LPDDR4=y CONFIG_DM_RESET=y CONFIG_BAUDRATE=150 CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_USE_PREBOOT=y +CONFIG_PREBOOT="usb start" CONFIG_ROCKCHIP_SPI=y CONFIG_SYSRESET=y CONFIG_USB=y @@ -68,8 +70,11 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_GENERIC=y CONFIG_USB_DWC3=y CONFIG_ROCKCHIP_USB2_PHY=y +CONFIG_DM_KEYBOARD=y CONFIG_USB_KEYBOARD=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y diff --git a/include/configs/pinebook-pro-rk3399.h b/include/configs/pinebook-pro-rk3399.h index 4bc8802d11..d910830582 100644 --- a/include/configs/pinebook-pro-rk3399.h +++ b/include/configs/pinebook-pro-rk3399.h @@ -25,4 +25,7 @@ #define SDRAM_BANK_SIZE (2UL << 30) +#define CONFIG_USB_OHCI_NEW +#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 2 + #endif
Re: [PATCH 3/3] rockchip: Pinebook Pro: Fix SPI flash and store env on it
On 2020/6/9 上午6:50, Peter Robinson wrote:
Some minor fixes for SPI flash on the Pinebook Pro and also
default to saving environment to the SPI flash as it's
guaranteed to be on board.
Signed-off-by: Peter Robinson
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi | 6 +-
configs/pinebook-pro-rk3399_defconfig| 3 +++
include/configs/pinebook-pro-rk3399.h| 9 -
3 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
index 296321d697..ded7db0aef 100644
--- a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
@@ -12,7 +12,11 @@
};
chosen {
- u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc;
+ u-boot,spl-boot-order = "same-as-spl", &sdhci, &spiflash,
&sdmmc;
+ };
+
+ config {
+ u-boot,spl-payload-offset = <0x6>; /* @ 384KB */
};
};
diff --git a/configs/pinebook-pro-rk3399_defconfig b/configs/pinebook-pro-rk3399_defconfig
index 733463556a..18b2d74253 100644
--- a/configs/pinebook-pro-rk3399_defconfig
+++ b/configs/pinebook-pro-rk3399_defconfig
@@ -1,6 +1,7 @@
CONFIG_ARM=y
CONFIG_ARCH_ROCKCHIP=y
CONFIG_SYS_TEXT_BASE=0x0020
+CONFIG_ENV_SIZE=0x8000
CONFIG_ROCKCHIP_RK3399=y
CONFIG_TARGET_PINEBOOK_PRO_RK3399=y
CONFIG_NR_DRAM_BANKS=1
@@ -17,6 +18,7 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_SPL_STACK_R=y
CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
CONFIG_SPL_MTD_SUPPORT=y
+CONFIG_SPL_SPI_LOAD=y
CONFIG_TPL=y
CONFIG_CMD_BOOTZ=y
CONFIG_CMD_GPIO=y
@@ -32,6 +34,7 @@ CONFIG_CMD_REGULATOR=y
CONFIG_SPL_OF_CONTROL=y
CONFIG_DEFAULT_DEVICE_TREE="rk3399-pinebook-pro"
CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent
assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_SPI_FLASH=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_ROCKCHIP_GPIO=y
CONFIG_SYS_I2C_ROCKCHIP=y
diff --git a/include/configs/pinebook-pro-rk3399.h
b/include/configs/pinebook-pro-rk3399.h
index d910830582..d478b19917 100644
--- a/include/configs/pinebook-pro-rk3399.h
+++ b/include/configs/pinebook-pro-rk3399.h
@@ -14,15 +14,6 @@
#include
-#if defined(CONFIG_ENV_IS_IN_MMC)
-#define CONFIG_SYS_MMC_ENV_DEV 0
-#elif defined(CONFIG_ENV_IS_IN_SPI_FLASH)
-#define CONFIG_ENV_SECT_SIZE (8 * 1024)
-#endif
-
-#undef CONFIG_SYS_SPI_U_BOOT_OFFS
-#define CONFIG_SYS_SPI_U_BOOT_OFFS 1024 * 512
-
#define SDRAM_BANK_SIZE (2UL << 30)
#define CONFIG_USB_OHCI_NEW
Re: [PATCH 2/4] arm64: dts: rockchip: Sync v5.7-rc1 VMARC RK3399Pro SOM
On 2020/6/10 下午6:36, Jagan Teki wrote:
VMARC RK3399Pro SOM is a standard SMARC SOM design with
Rockchip RK3399Pro SoC, which is designed by Vamrs.
Specification:
- Rockchip RK3399Pro
- PMIC: RK809-3
- SD slot, 16GiB eMMC
- 2xUSB-2.0, 1xUSB3.0
- USB-C for power supply
- Ethernet, PCIe
- HDMI, MIPI-DSI/CSI, eDP
Add initial support for VMARC RK3399Pro SOM, this would use
with associated carrier board.
Sync this dtsi from linux-next v5.7-rc1.
Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/dts/rk3399pro-vmarc-som.dtsi | 333 ++
1 file changed, 333 insertions(+)
create mode 100644 arch/arm/dts/rk3399pro-vmarc-som.dtsi
diff --git a/arch/arm/dts/rk3399pro-vmarc-som.dtsi
b/arch/arm/dts/rk3399pro-vmarc-som.dtsi
new file mode 100644
index 00..0a516334f1
--- /dev/null
+++ b/arch/arm/dts/rk3399pro-vmarc-som.dtsi
@@ -0,0 +1,333 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd
+ * Copyright (c) 2019 Vamrs Limited
+ * Copyright (c) 2019 Amarula Solutions(India)
+ */
+
+#include
+#include
+#include
+
+/ {
+ compatible = "vamrs,rk3399pro-vmarc-som", "rockchip,rk3399pro";
+
+ clkin_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "clkin_gmac";
+ #clock-cells = <0>;
+ };
+
+ vcc12v_dcin: vcc12v-dcin-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc12v_dcin";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ };
+
+ vcc5v0_sys: vcc5v0-sys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ vin-supply = <&vcc12v_dcin>;
+ };
+};
+
+&cpu_l0 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l1 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l2 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l3 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&emmc_phy {
+ status = "okay";
+};
+
+&gmac {
+ assigned-clocks = <&cru SCLK_RMII_SRC>;
+ assigned-clock-parents = <&clkin_gmac>;
+ clock_in_out = "input";
+ phy-supply = <&vcc_lan>;
+ phy-mode = "rgmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 1 5>;
+ tx_delay = <0x28>;
+ rx_delay = <0x11>;
+};
+
+&i2c0 {
+ clock-frequency = <40>;
+ i2c-scl-rising-time-ns = <180>;
+ i2c-scl-falling-time-ns = <30>;
+ status = "okay";
+
+ rk809: pmic@20 {
+ compatible = "rockchip,rk809";
+ reg = <0x20>;
+ interrupt-parent = <&gpio1>;
+ interrupts = ;
+ #clock-cells = <1>;
+ clock-output-names = "rk808-clkout1", "rk808-clkout2";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int_l>;
+ rockchip,system-power-controller;
+ wakeup-source;
+
+ vcc1-supply = <&vcc5v0_sys>;
+ vcc2-supply = <&vcc5v0_sys>;
+ vcc3-supply = <&vcc5v0_sys>;
+ vcc4-supply = <&vcc5v0_sys>;
+ vcc5-supply = <&vcc_buck5>;
+ vcc6-supply = <&vcc_buck5>;
+ vcc7-supply = <&vcc5v0_sys>;
+ vcc8-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc5v0_sys>;
+
+ regulators {
+ vdd_log: DCDC_REG1 {
+ regulator-name = "vdd_log";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <75>;
+ regulator-max-microvolt = <135>;
+ regulator-initial-mode = <0x2>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <90>;
+ };
+ };
+
+ vdd_cpu_l: DCDC_REG2 {
+ regulator-name = "vdd_cpu_l";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <75>;
+ regulator-max-microvolt = <135>;
+ regulator
Re: [PATCH 1/4] arm64: dts: rockchip: Sync v5.7-rc1 rk3399pro.dtsi
On 2020/6/10 下午6:36, Jagan Teki wrote:
Sync linux-next v5.7-rc1 rk3399pro.dtsi.
Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/dts/rk3399pro.dtsi | 22 ++
1 file changed, 22 insertions(+)
create mode 100644 arch/arm/dts/rk3399pro.dtsi
diff --git a/arch/arm/dts/rk3399pro.dtsi b/arch/arm/dts/rk3399pro.dtsi
new file mode 100644
index 00..bb5ebf6608
--- /dev/null
+++ b/arch/arm/dts/rk3399pro.dtsi
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd.
+
+#include "rk3399.dtsi"
+
+/ {
+ compatible = "rockchip,rk3399pro";
+};
+
+/* Default to enabled since AP talk to NPU part over pcie */
+&pcie_phy {
+ status = "okay";
+};
+
+/* Default to enabled since AP talk to NPU part over pcie */
+&pcie0 {
+ ep-gpios = <&gpio0 RK_PB4 GPIO_ACTIVE_HIGH>;
+ num-lanes = <4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie_clkreqn_cpm>;
+ status = "okay";
+};
Re: [PATCH 4/4] arm64: dts: rockchip: Add Radxa Rock Pi N10 initial support
On 2020/6/10 下午6:36, Jagan Teki wrote:
Rock Pi N10 is a Rockchip RK3399Pro based SBC, which has
- VMARC RK3399Pro SOM (as per SMARC standard) from Vamrs.
- Compatible carrier board from Radxa.
VAMRC RK3399Pro SOM need to mount on top of radxa dalang
carrier board for making Rock Pi N10 SBC.
So, add initial support for Rock Pi N10 by including rk3399,
rk3399pro vamrc-som and raxda dalang carrier board dtsi files.
rk3399pro-rock-pi-n10.dts was synced from linux-next v5.7-rc1.
Tested
- ROCK PI N10 Model B
- ROCK PI N10 Model C
- Boot from SD
Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/dts/Makefile | 3 +-
.../arm/dts/rk3399pro-rock-pi-n10-u-boot.dtsi | 7 +++
arch/arm/dts/rk3399pro-rock-pi-n10.dts| 18
arch/arm/dts/rk3399pro-u-boot.dtsi| 6 +++
board/rockchip/evb_rk3399/MAINTAINERS | 6 +++
configs/rock-pi-n10-rk3399pro_defconfig | 46 +++
6 files changed, 85 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/rk3399pro-rock-pi-n10-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3399pro-rock-pi-n10.dts
create mode 100644 arch/arm/dts/rk3399pro-u-boot.dtsi
create mode 100644 configs/rock-pi-n10-rk3399pro_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9900b44274..07dfe06230 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -136,7 +136,8 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
rk3399-roc-pc-mezzanine.dtb \
rk3399-rock-pi-4.dtb \
rk3399-rock960.dtb \
- rk3399-rockpro64.dtb
+ rk3399-rockpro64.dtb \
+ rk3399pro-rock-pi-n10.dtb
dtb-$(CONFIG_ROCKCHIP_RV1108) += \
rv1108-elgin-r1.dtb \
diff --git a/arch/arm/dts/rk3399pro-rock-pi-n10-u-boot.dtsi
b/arch/arm/dts/rk3399pro-rock-pi-n10-u-boot.dtsi
new file mode 100644
index 00..946a0230db
--- /dev/null
+++ b/arch/arm/dts/rk3399pro-rock-pi-n10-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki
+ */
+
+#include "rk3399pro-u-boot.dtsi"
+#include "rk3399-sdram-lpddr3-4GB-1600.dtsi"
diff --git a/arch/arm/dts/rk3399pro-rock-pi-n10.dts
b/arch/arm/dts/rk3399pro-rock-pi-n10.dts
new file mode 100644
index 00..6ac2d4d721
--- /dev/null
+++ b/arch/arm/dts/rk3399pro-rock-pi-n10.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd
+ * Copyright (c) 2019 Radxa Limited
+ * Copyright (c) 2019 Amarula Solutions(India)
+ */
+
+/dts-v1/;
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+#include "rk3399pro-vmarc-som.dtsi"
+#include
+
+/ {
+ model = "Radxa ROCK Pi N10";
+ compatible = "radxa,rockpi-n10", "vamrs,rk3399pro-vmarc-som",
+"rockchip,rk3399pro";
+};
diff --git a/arch/arm/dts/rk3399pro-u-boot.dtsi
b/arch/arm/dts/rk3399pro-u-boot.dtsi
new file mode 100644
index 00..7bddc3acdb
--- /dev/null
+++ b/arch/arm/dts/rk3399pro-u-boot.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki
+ */
+
+#include "rk3399-u-boot.dtsi"
diff --git a/board/rockchip/evb_rk3399/MAINTAINERS
b/board/rockchip/evb_rk3399/MAINTAINERS
index 792df1087f..578638a58b 100644
--- a/board/rockchip/evb_rk3399/MAINTAINERS
+++ b/board/rockchip/evb_rk3399/MAINTAINERS
@@ -68,3 +68,9 @@ M:Jagan Teki
S:Maintained
F:configs/rock-pi-4-rk3399_defconfig
F:arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi
+
+ROCK-PI-N10
+M: Jagan Teki
+S: Maintained
+F: configs/rock-pi-n10-rk3399pro_defconfig
+F: arch/arm/dts/rk3399pro-rock-pi-n10-u-boot.dtsi
diff --git a/configs/rock-pi-n10-rk3399pro_defconfig
b/configs/rock-pi-n10-rk3399pro_defconfig
new file mode 100644
index 00..c705ce01ce
--- /dev/null
+++ b/configs/rock-pi-n10-rk3399pro_defconfig
@@ -0,0 +1,46 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x0020
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_ENV_OFFSET=0x3F8000
+CONFIG_ROCKCHIP_RK3399=y
+CONFIG_TARGET_EVB_RK3399=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEBUG_UART_BASE=0xFF1A
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_DEBUG_UART=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399pro-rock-pi-n10.dtb"
+CONFIG_MISC_INIT_R=y
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
+CONFIG_TPL=y
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399pro-rock-pi-n10"
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent
assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MISC=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ROCKC
Re: [PATCH 3/4] ARM: dts: rockchip: Sync v5.7-rc1 Radxa Dalang Carrier
On 2020/6/10 下午6:36, Jagan Teki wrote:
Carrier board often referred as baseboard. For making
complete SBC or any other industrial boards, these
carrier boards will be used with associated SOMs.
Radxa has Dalang carrier board which supports on-board
peripherals, ports like USB-2.0, USB-3.0, HDMI, MIPI DSI/CSI,
eDP, Ethernet, WiFi, PCIe, USB-C, 40-Pin GPIO header and etc.
Right now Dalang carrier board is used with two SBC-variants:
Rock Pi N10 => VMARC RK3399Por SOM + Dalang carrier board
Rock Pi N8 => VMARC RK3288 SOM + Dalang carrier board(+codec)
So add this carrier board dtsi as a separate file in
ARM directory, so-that the same can reuse it in both
rk3288, rk3399pro variants of Rockchip SOMs.
Sync this dtsi from linux-next v5.7-rc1.
Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
Thanks,
- Kever
---
.../dts/rockchip-radxa-dalang-carrier.dtsi| 81 +++
1 file changed, 81 insertions(+)
create mode 100644 arch/arm/dts/rockchip-radxa-dalang-carrier.dtsi
diff --git a/arch/arm/dts/rockchip-radxa-dalang-carrier.dtsi
b/arch/arm/dts/rockchip-radxa-dalang-carrier.dtsi
new file mode 100644
index 00..df3712aedf
--- /dev/null
+++ b/arch/arm/dts/rockchip-radxa-dalang-carrier.dtsi
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd
+ * Copyright (c) 2019 Radxa Limited
+ * Copyright (c) 2019 Amarula Solutions(India)
+ */
+
+#include
+
+/ {
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+};
+
+&gmac {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+ i2c-scl-rising-time-ns = <140>;
+ i2c-scl-falling-time-ns = <30>;
+};
+
+&i2c2 {
+ status = "okay";
+ clock-frequency = <40>;
+
+ hym8563: hym8563@51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ clock-output-names = "hym8563";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hym8563_int>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <30 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
+&pwm0 {
+ status = "okay";
+};
+
+&pwm2 {
+ status = "okay";
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
+ disable-wp;
+ vqmmc-supply = <&vccio_sd>;
+ max-frequency = <15000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_xfer &uart0_cts>;
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&pinctrl {
+ hym8563 {
+ hym8563_int: hym8563-int {
+ rockchip,pins =
+ <4 RK_PD6 0 &pcfg_pull_up>;
+ };
+ };
+};
Re: [PATCH] rockchip: rk3399: allow deselecting SPL_ATF_NO_PLATFORM_PARAM
On 2020/6/16 上午7:30, Hugh Cole-Baker wrote: SPL_ATF_NO_PLATFORM_PARAM is selected by default for RK3399 configs, to guard against issues when used with TF-A versions that perform insufficient validation on the platform parameter. However, since commit 8109f738ffa7 "rockchip: increase FDT buffer size" in TF-A, passing a device tree as platform parameter no longer causes problems for upstream TF-A for RK3399. Since SPL_ATF_NO_PLATFORM_PARAM doesn't need to be selected when using upstream TF-A, change the Kconfig option from select to imply. It'll still default to being selected but can be deselected by a user if they know they will be using a compatible version of TF-A. Signed-off-by: Hugh Cole-Baker Reviewed-by: Kever Yang Thanks, - Kever --- For some background, see this thread on the TF-A list [1]. Since the corresponding required change isn't in a tagged version of TF-A yet, and I don't know how many RK3399 boards are normally used with older TF-A versions which required this option, I think it's safest to keep the default as not sending a platform param to TF-A. Once the next TF-A version is released, SPL_ATF_NO_PLATFORM_PARAM could be turned off in defconfigs for boards that use the latest upstream TF-A. [1]: https://lists.trustedfirmware.org/pipermail/tf-a/2020-June/000502.html arch/arm/mach-rockchip/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 0cb1f23d0f3..e2b63265846 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -207,7 +207,6 @@ config ROCKCHIP_RK3399 select SUPPORT_TPL select SPL select SPL_ATF - select SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF select SPL_BOARD_INIT if SPL select SPL_LOAD_FIT select SPL_CLK if SPL @@ -232,6 +231,7 @@ config ROCKCHIP_RK3399 imply PRE_CONSOLE_BUFFER imply ROCKCHIP_COMMON_BOARD imply ROCKCHIP_SDRAM_COMMON + imply SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF imply SPL_ROCKCHIP_COMMON_BOARD imply TPL_SERIAL_SUPPORT imply TPL_LIBCOMMON_SUPPORT
Re: [PATCH v2 1/6] rock-pi-4: Enable USB3 Host【请注意，邮件由linux-rockchip-bounces+kever.yang=rock-chips....@lists.infradead.org代发】
On 2020/6/18 下午10:12, Jagan Teki wrote: Enable USB3.0 Host support for RockPI-4 boards. Note that the Upper USB3.0 port is marked as otg and lower USB3.0 port marked as host, so this below log capture when USB3.0 mass storage plug in at lower USB 3.0 port. Log: Bus usb@fe38: USB EHCI 1.00 Bus usb@fe3c: USB EHCI 1.00 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe38 for devices... 1 USB Device(s) found scanning bus usb@fe3c for devices... 1 USB Device(s) found scanning bus dwc3 for devices... 1 USB Device(s) found scanning bus dwc3 for devices... cannot reset port 1!? 2 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found => usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller 1 Hub (480 Mb/s, 0mA) u-boot EHCI Host Controller 1 Hub (5 Gb/s, 0mA) U-Boot XHCI Host Controller 1 Hub (5 Gb/s, 0mA) | U-Boot XHCI Host Controller | +-2 Mass Storage (5 Gb/s, 224mA) SanDisk Dual Drive 040130e3ee554b7078843f4eb331646 Cc: Tom Cubie Signed-off-by: Jagan Teki Reviewed-by: Kever Yang Thanks, - Kever --- Changes for v2: - rebase on master configs/rock-pi-4-rk3399_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/rock-pi-4-rk3399_defconfig b/configs/rock-pi-4-rk3399_defconfig index 0d86fdc895..2487872219 100644 --- a/configs/rock-pi-4-rk3399_defconfig +++ b/configs/rock-pi-4-rk3399_defconfig @@ -28,6 +28,7 @@ CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MISC=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y @@ -35,11 +36,14 @@ CONFIG_MMC_SDHCI_ROCKCHIP=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y +CONFIG_PHY_ROCKCHIP_INNO_USB2=y +CONFIG_PHY_ROCKCHIP_TYPEC=y CONFIG_PMIC_RK8XX=y CONFIG_REGULATOR_PWM=y CONFIG_REGULATOR_RK8XX=y CONFIG_PWM_ROCKCHIP=y CONFIG_RAM_RK3399_LPDDR4=y +CONFIG_DM_RESET=y CONFIG_BAUDRATE=150 CONFIG_DEBUG_UART_SHIFT=2 CONFIG_SYSRESET=y @@ -48,6 +52,8 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y
Re: [PATCH v2 3/6] rock-pi-4: Enable USB Gadget
On 2020/6/18 下午10:12, Jagan Teki wrote: Enable USB gadget for rock-pi-4 boards. This would help to use fastboot by default. Note: Connect the Host USB cable (Port A or C) to rock-pi-4 Upper USB 3.0 port. Signed-off-by: Jagan Teki Reviewed-by: Kever Yang Thanks, - Kever --- Changes for v2: - rebase on master configs/rock-pi-4-rk3399_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/rock-pi-4-rk3399_defconfig b/configs/rock-pi-4-rk3399_defconfig index 0d86fdc895..2487872219 100644 --- a/configs/rock-pi-4-rk3399_defconfig +++ b/configs/rock-pi-4-rk3399_defconfig @@ -28,6 +28,7 @@ CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MISC=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y @@ -35,11 +36,14 @@ CONFIG_MMC_SDHCI_ROCKCHIP=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y +CONFIG_PHY_ROCKCHIP_INNO_USB2=y configs/rock-pi-4-rk3399_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/rock-pi-4-rk3399_defconfig b/configs/rock-pi-4-rk3399_defconfig index f3eeef0293..a4b322074c 100644 --- a/configs/rock-pi-4-rk3399_defconfig +++ b/configs/rock-pi-4-rk3399_defconfig @@ -8,6 +8,7 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_DEBUG_UART_BASE=0xFF1A CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_DEBUG_UART=y +# CONFIG_ANDROID_BOOT_IMAGE is not set CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rock-pi-4.dtb" CONFIG_MISC_INIT_R=y CONFIG_DISPLAY_BOARDINFO_LATE=y @@ -57,6 +58,7 @@ CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_DWC3=y CONFIG_USB_DWC3_GENERIC=y +CONFIG_USB_GADGET=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y
Re: [PATCH v2 2/6] rock-pi-4: Enable PCI/NVME
On 2020/6/18 下午10:12, Jagan Teki wrote: Enable PCI/NVME for M.2 Slot on RockPI-4 boards. => nvme info Device 0: Vendor: 0x144d Rev: 2B2QEXM7 Prod: S4EUNG0MC10012Y Type: Hard Disk Capacity: 238475.1 MB = 232.8 GB (488397168 x 512) Cc: Tom Cubie Signed-off-by: Jagan Teki Reviewed-by: Kever Yang Thanks, - Kever --- Changes for v2: - rebase on master configs/rock-pi-4-rk3399_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/rock-pi-4-rk3399_defconfig b/configs/rock-pi-4-rk3399_defconfig index 0d86fdc895..2487872219 100644 --- a/configs/rock-pi-4-rk3399_defconfig +++ b/configs/rock-pi-4-rk3399_defconfig @@ -28,6 +28,7 @@ CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MISC=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y @@ -35,11 +36,14 @@ CONFIG_MMC_SDHCI_ROCKCHIP=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y +CONFIG_PHY_ROCKCHIP_INNO_USB2=y configs/rock-pi-4-rk3399_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/rock-pi-4-rk3399_defconfig b/configs/rock-pi-4-rk3399_defconfig index 2487872219..f3eeef0293 100644 --- a/configs/rock-pi-4-rk3399_defconfig +++ b/configs/rock-pi-4-rk3399_defconfig @@ -18,6 +18,7 @@ CONFIG_TPL=y CONFIG_CMD_BOOTZ=y CONFIG_CMD_GPT=y CONFIG_CMD_MMC=y +CONFIG_CMD_PCI=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_TIME=y @@ -36,6 +37,8 @@ CONFIG_MMC_SDHCI_ROCKCHIP=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y +CONFIG_NVME=y +CONFIG_PCI=y CONFIG_PHY_ROCKCHIP_INNO_USB2=y CONFIG_PHY_ROCKCHIP_TYPEC=y CONFIG_PMIC_RK8XX=y
Re: [PATCH v2 5/6] roc-rk3399-pc: Enable USB Gadget
On 2020/6/18 下午10:12, Jagan Teki wrote: Enable DWC3 core, gadget for roc-rk3399-pc board. This would help to use fastboot by default. Signed-off-by: Jagan Teki Reviewed-by: Kever Yang Thanks, - Kever --- Changes for v2: - rebase on master configs/rock-pi-4-rk3399_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/rock-pi-4-rk3399_defconfig b/configs/rock-pi-4-rk3399_defconfig index 0d86fdc895..2487872219 100644 --- a/configs/rock-pi-4-rk3399_defconfig +++ b/configs/rock-pi-4-rk3399_defconfig @@ -28,6 +28,7 @@ CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MISC=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y @@ -35,11 +36,14 @@ CONFIG_MMC_SDHCI_ROCKCHIP=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y +CONFIG_PHY_ROCKCHIP_INNO_USB2=y configs/roc-pc-mezzanine-rk3399_defconfig | 3 +++ configs/roc-pc-rk3399_defconfig | 3 +++ 2 files changed, 6 insertions(+) diff --git a/configs/roc-pc-mezzanine-rk3399_defconfig b/configs/roc-pc-mezzanine-rk3399_defconfig index fd1b85c1e4..7906948374 100644 --- a/configs/roc-pc-mezzanine-rk3399_defconfig +++ b/configs/roc-pc-mezzanine-rk3399_defconfig @@ -12,6 +12,7 @@ CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI_SUPPORT=y CONFIG_DEBUG_UART=y +# CONFIG_ANDROID_BOOT_IMAGE is not set CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-roc-pc-mezzanine.dtb" CONFIG_DISPLAY_BOARDINFO_LATE=y # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set @@ -64,7 +65,9 @@ CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_DWC3=y CONFIG_USB_DWC3_GENERIC=y +CONFIG_ROCKCHIP_USB2_PHY=y CONFIG_USB_KEYBOARD=y +CONFIG_USB_GADGET=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig index 80e7001481..046fb73858 100644 --- a/configs/roc-pc-rk3399_defconfig +++ b/configs/roc-pc-rk3399_defconfig @@ -12,6 +12,7 @@ CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI_SUPPORT=y CONFIG_DEBUG_UART=y +# CONFIG_ANDROID_BOOT_IMAGE is not set CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-roc-pc.dtb" CONFIG_DISPLAY_BOARDINFO_LATE=y # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set @@ -61,7 +62,9 @@ CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_DWC3=y CONFIG_USB_DWC3_GENERIC=y +CONFIG_ROCKCHIP_USB2_PHY=y CONFIG_USB_KEYBOARD=y +CONFIG_USB_GADGET=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y
Re: [PATCH v2 4/6] rock-pi-4: Enable HDMI output
On 2020/6/18 下午10:12, Jagan Teki wrote: Enable config options to get HDMI output on RockPI-4 boards. Signed-off-by: Jagan Teki --- Changes for v2: - rebase on master configs/rock-pi-4-rk3399_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/rock-pi-4-rk3399_defconfig b/configs/rock-pi-4-rk3399_defconfig index 0d86fdc895..2487872219 100644 --- a/configs/rock-pi-4-rk3399_defconfig +++ b/configs/rock-pi-4-rk3399_defconfig @@ -28,6 +28,7 @@ CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MISC=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y @@ -35,11 +36,14 @@ CONFIG_MMC_SDHCI_ROCKCHIP=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y +CONFIG_PHY_ROCKCHIP_INNO_USB2=y This is not for HDMI. configs/rock-pi-4-rk3399_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/configs/rock-pi-4-rk3399_defconfig b/configs/rock-pi-4-rk3399_defconfig index a4b322074c..98f71a50a5 100644 --- a/configs/rock-pi-4-rk3399_defconfig +++ b/configs/rock-pi-4-rk3399_defconfig @@ -58,6 +58,7 @@ CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_DWC3=y CONFIG_USB_DWC3_GENERIC=y +CONFIG_USB_KEYBOARD=y This is not for HDMI. CONFIG_USB_GADGET=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y @@ -65,5 +66,9 @@ CONFIG_USB_ETHER_ASIX88179=y CONFIG_USB_ETHER_MCS7830=y CONFIG_USB_ETHER_RTL8152=y CONFIG_USB_ETHER_SMSC95XX=y +CONFIG_DM_VIDEO=y +CONFIG_DISPLAY=y +CONFIG_VIDEO_ROCKCHIP=y +CONFIG_DISPLAY_ROCKCHIP_HDMI=y CONFIG_SPL_TINY_MEMSET=y CONFIG_ERRNO_STR=y
Re: [PATCH v2 6/6] roc-rk3399-pc: Update ENV offset, size
On 2020/6/18 下午10:12, Jagan Teki wrote: Adjust the ENV offset, size to fit into all images on 16MB flash. Signed-off-by: Jagan Teki --- Changes for v2: - rebase on master configs/rock-pi-4-rk3399_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/rock-pi-4-rk3399_defconfig b/configs/rock-pi-4-rk3399_defconfig index 0d86fdc895..2487872219 100644 --- a/configs/rock-pi-4-rk3399_defconfig +++ b/configs/rock-pi-4-rk3399_defconfig @@ -28,6 +28,7 @@ CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MISC=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y @@ -35,11 +36,14 @@ CONFIG_MMC_SDHCI_ROCKCHIP=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y +CONFIG_PHY_ROCKCHIP_INNO_USB2=y This is not for ENV. Thanks, - Kever configs/roc-pc-mezzanine-rk3399_defconfig | 4 ++-- configs/roc-pc-rk3399_defconfig | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/configs/roc-pc-mezzanine-rk3399_defconfig b/configs/roc-pc-mezzanine-rk3399_defconfig index 7906948374..595f052cb7 100644 --- a/configs/roc-pc-mezzanine-rk3399_defconfig +++ b/configs/roc-pc-mezzanine-rk3399_defconfig @@ -1,8 +1,8 @@ CONFIG_ARM=y CONFIG_ARCH_ROCKCHIP=y CONFIG_SYS_TEXT_BASE=0x0020 -CONFIG_ENV_SIZE=0x6000 -CONFIG_ENV_OFFSET=0x46 +CONFIG_ENV_SIZE=0x8000 +CONFIG_ENV_OFFSET=0x3F8000 CONFIG_ENV_SECT_SIZE=0x1000 CONFIG_ROCKCHIP_RK3399=y CONFIG_TARGET_ROC_PC_RK3399=y diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig index 046fb73858..1c4db3443f 100644 --- a/configs/roc-pc-rk3399_defconfig +++ b/configs/roc-pc-rk3399_defconfig @@ -1,8 +1,8 @@ CONFIG_ARM=y CONFIG_ARCH_ROCKCHIP=y CONFIG_SYS_TEXT_BASE=0x0020 -CONFIG_ENV_SIZE=0x6000 -CONFIG_ENV_OFFSET=0x46 +CONFIG_ENV_SIZE=0x8000 +CONFIG_ENV_OFFSET=0x3F8000 CONFIG_ENV_SECT_SIZE=0x1000 CONFIG_ROCKCHIP_RK3399=y CONFIG_TARGET_ROC_PC_RK3399=y
Re: [PATCH] rockchip: i2c: fix switch to new implementation for rk3188
To make clear, there is kernel driver i2c-rk3x.c.
For rk3066 it write bits in the GRF word at offset 0x154. See [1] and [2].
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/busses/i2c-rk3x.c#n1236
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/busses/i2c-rk3x.c#n1137
In u-boot there is include file cru_rk3036.h [3]. If this include file valid
for rk3066, than offset 0x154 correspond
to soc_con3 register. But all documentation I found for 30xx SoC clarify that
I2C switch bits located in the
soc_con1 registers.
So I don’t know correct location for I2C switch bits.
[3]
https://github.com/u-boot/u-boot/blob/master/arch/arm/include/asm/arch-rockchip/cru_rk3036.h
> 27 июня 2020 г., в 17:17, Kever Yang написал(а):
>
> +David,
>
> Hi David,
>
> Could you help to commend on this?
>
>
> Hi Alex,
>
> Thanks for your patch.
>
> On 2020/6/22 下午9:06, Alexander Kochetkov wrote:
>> The commit e7ae4cf27a6d 'pinctrl: rockchip: Add common rockchip
>> pinctrl driver' dropped rk3188_pinctrl_request operation, that
>> did switching to new implementation.
>>
>> This commit implement switching to new implementation using
>> writing bits to GRF.
>>
>> I don't have rk3060
> rk3066
>> board to test, so switching implemented
>> as a stub returning -ENOSYS.
>>
>> Signed-off-by: Alexander Kochetkov
>> ---
>> drivers/i2c/rk_i2c.c | 42 +++---
>> 1 file changed, 31 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/i2c/rk_i2c.c b/drivers/i2c/rk_i2c.c
>> index 32b2ee8578..ad3c66843b 100644
>> --- a/drivers/i2c/rk_i2c.c
>> +++ b/drivers/i2c/rk_i2c.c
>> @@ -15,6 +15,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> #include
>> #include
>> @@ -41,6 +43,7 @@ enum {
>> */
>> struct rk_i2c_soc_data {
>> int controller_type;
>> +int (*switch_to_new_type)(int bus_nr);
>> };
>>static inline void rk_i2c_get_div(int div, int *divh, int *divl)
>> @@ -388,11 +391,33 @@ static int rockchip_i2c_ofdata_to_platdata(struct
>> udevice *bus)
>> return 0;
>> }
>> +static int rockchip_i2c_switch_to_new_type_rk3066(int bus_nr)
>> +{
>> +return -ENOSYS;
>> +}
>> +
>> +static int rockchip_i2c_switch_to_new_type_rk3188(int bus_nr)
>> +{
>> +struct rk3188_grf *grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
>> +
>> +if (grf == NULL)
>> +return -ENOSYS;
>> +
>> +if (bus_nr < 0 || bus_nr > (RKI2C4_SEL_SHIFT - RKI2C0_SEL_SHIFT))
>> +return -EINVAL;
>> +
>> +/* enable new i2c controller */
>> +rk_clrsetreg(&grf->soc_con1,
>> + 1 << (RKI2C0_SEL_SHIFT + bus_nr),
>> + 1 << (RKI2C0_SEL_SHIFT + bus_nr));
>> +
>> +return 0;
>> +}
>> +
>> static int rockchip_i2c_probe(struct udevice *bus)
>> {
>> struct rk_i2c *priv = dev_get_priv(bus);
>> struct rk_i2c_soc_data *soc_data;
>> -struct udevice *pinctrl;
>> int bus_nr;
>> int ret;
>> @@ -408,17 +433,10 @@ static int rockchip_i2c_probe(struct udevice *bus)
>> return ret;
>> }
>> - ret = uclass_get_device(UCLASS_PINCTRL, 0, &pinctrl);
>> -if (ret) {
>> -debug("%s: Cannot find pinctrl device\n", __func__);
>> -return ret;
>> -}
>> -
>> -/* pinctrl will switch I2C to new type */
>> -ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_I2C0 + bus_nr);
>> -if (ret) {
>> +ret = soc_data->switch_to_new_type(bus_nr);
>> +if (ret < 0) {
>> debug("%s: Failed to switch I2C to new type %s: %d\n",
>> -__func__, bus->name, ret);
>> + __func__, bus->name, ret);
>> return ret;
>> }
>> }
>> @@ -433,10 +451,12 @@ static const struct dm_i2c_ops rockchip_i2c_ops = {
>>static const struct rk_i2c_soc_data rk3066_soc_data = {
>> .controller_type = RK_I2C_LEGACY,
>> +.switch_to_new_type = rockchip_i2c_switch_to_new_type_rk3066,
>> };
>>static const struct rk_i2c_soc_data rk3188_soc_data = {
>> .controller_type = RK_I2C_LEGACY,
>> +.switch_to_new_type = rockchip_i2c_switch_to_new_type_rk3188,
>> };
>>static const struct rk_i2c_soc_data rk3228_soc_data = {
>
>
Re: [PATCH 2/3] ARM: dts: rockchip: Add VMARC RK3288 SOM initial support
On 2020/6/19 上午12:12, Jagan Teki wrote:
VMARC RK3288 SOM is a standard SMARC SOM design with
Rockchip RK3288 SoC, which is designed by Vamrs.
Specification:
- Rockchip RK3288
- PMIC: RK808
- SD slot, 16GiB eMMC
- 2xUSB-2.0, 1xUSB3.0
- USB-C for power supply
- Ethernet, PCIe
- HDMI, MIPI-DSI/CSI, eDP
Add initial support for VMARC RK3288 SOM, this would use
with associated carrier board.
Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/dts/rk3288-vmarc-som.dtsi | 298 +
1 file changed, 298 insertions(+)
create mode 100644 arch/arm/dts/rk3288-vmarc-som.dtsi
diff --git a/arch/arm/dts/rk3288-vmarc-som.dtsi
b/arch/arm/dts/rk3288-vmarc-som.dtsi
new file mode 100644
index 00..1549ac4044
--- /dev/null
+++ b/arch/arm/dts/rk3288-vmarc-som.dtsi
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd
+ * Copyright (c) 2019 Vamrs Limited
+ * Copyright (c) 2019 Amarula Solutions(India)
+ */
+
+#include
+#include
+#include
+
+/ {
+ compatible = "vamrs,rk3288-vmarc-som", "rockchip,rk3288";
+
+ ext_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "ext_gmac";
+ #clock-cells = <0>;
+ };
+
+ vccio_flash: vccio-flash-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vccio_flash";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ startup-delay-us = <150>;
+ vin-supply = <&vcc_io>;
+ };
+
+ vcc_sys: vsys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_sys";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+};
+
+&emmc {
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ disable-wp;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&emmc_clk &emmc_cmd &emmc_pwr &emmc_bus8>;
+ status = "okay";
+};
+
+&gmac {
+ assigned-clocks = <&cru SCLK_MAC>;
+ assigned-clock-parents = <&ext_gmac>;
+ clock_in_out = "input";
+ phy-mode = "rgmii";
+ phy-supply = <&vcc_io>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ snps,reset-gpio = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 1 5>;
+ tx_delay = <0x30>;
+ rx_delay = <0x10>;
+ max-speed = <1000>;
+};
+
+&i2c0 {
+ clock-frequency = <40>;
+ status = "okay";
+
+ rk808: pmic@1b {
+ compatible = "rockchip,rk808";
+ reg = <0x1b>;
+ interrupt-parent = <&gpio0>;
+ interrupts = ;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int &global_pwroff>;
+ rockchip,system-power-controller;
+ wakeup-source;
+ #clock-cells = <1>;
+ clock-output-names = "rk808-clkout1", "rk808-clkout2";
+
+ vcc1-supply = <&vcc_sys>;
+ vcc2-supply = <&vcc_sys>;
+ vcc3-supply = <&vcc_sys>;
+ vcc4-supply = <&vcc_sys>;
+ vcc6-supply = <&vcc_sys>;
+ vcc7-supply = <&vcc_sys>;
+ vcc8-supply = <&vcc_io>;
+ vcc9-supply = <&vcc_io>;
+ vcc10-supply = <&vcc_sys>;
+ vcc11-supply = <&vcc_sys>;
+ vcc12-supply = <&vcc_io>;
+ vddio-supply = <&vcc_io>;
+
+ regulators {
+ vdd_cpu: DCDC_REG1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <75>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd_arm";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu: DCDC_REG2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <85>;
+ regulator-max-microvolt = <125>;
+ regulator-name = "vdd_gpu";
+ regulator-ramp-delay = <6000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_ddr
Re: [PATCH 3/3] ARM: dts: rockchip: Add Radxa Rock Pi N8 initial support
On 2020/6/19 上午12:12, Jagan Teki wrote:
Rock Pi N8 is a Rockchip RK3288 based SBC, which has
- VMARC RK3288 SOM (as per SMARC standard) from Vamrs.
- Compatible carrier board from Radxa.
VAMRC RK3288 SOM need to mount on top of radxa dalang
carrier board for making Rock Pi N8 SBC.
So, add initial support for Rock Pi N8 by including rk3288,
rk3288 vamrc-som and raxda dalang carrier board dtsi files.
Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3288-rock-pi-n8-u-boot.dtsi | 33 +++
arch/arm/dts/rk3288-rock-pi-n8.dts | 17 ++
arch/arm/dts/rk3288-vmarc-som.dtsi | 9 ---
board/rockchip/evb_rk3288/MAINTAINERS | 6 ++
configs/rock-pi-n8-rk3288_defconfig| 66 ++
6 files changed, 123 insertions(+), 9 deletions(-)
create mode 100644 arch/arm/dts/rk3288-rock-pi-n8-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3288-rock-pi-n8.dts
create mode 100644 configs/rock-pi-n8-rk3288_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 07dfe06230..aae95811c1 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -92,6 +92,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3288) += \
rk3288-phycore-rdk.dtb \
rk3288-popmetal.dtb \
rk3288-rock2-square.dtb \
+ rk3288-rock-pi-n8.dtb \
rk3288-tinker.dtb \
rk3288-tinker-s.dtb \
rk3288-veyron-jerry.dtb \
diff --git a/arch/arm/dts/rk3288-rock-pi-n8-u-boot.dtsi
b/arch/arm/dts/rk3288-rock-pi-n8-u-boot.dtsi
new file mode 100644
index 00..e9d7404ed9
--- /dev/null
+++ b/arch/arm/dts/rk3288-rock-pi-n8-u-boot.dtsi
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2017 Jagan Teki
+ */
+
+#include "rk3288-u-boot.dtsi"
+
+&dmc {
+ 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 0x2>;
+ rockchip,sdram-params = <0x20d266a4 0x5b6 2 53300 6 9 0>;
+};
+
+&sdmmc {
+ u-boot,dm-pre-reloc;
+};
+
+&emmc {
+ u-boot,dm-pre-reloc;
+};
+
+&uart2 {
+ u-boot,dm-pre-reloc;
+};
+
+&pinctrl {
+ u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/rk3288-rock-pi-n8.dts
b/arch/arm/dts/rk3288-rock-pi-n8.dts
new file mode 100644
index 00..c8637a50c1
--- /dev/null
+++ b/arch/arm/dts/rk3288-rock-pi-n8.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd
+ * Copyright (c) 2019 Vamrs Limited
+ * Copyright (c) 2019 Amarula Solutions(India)
+ */
+
+/dts-v1/;
+#include "rk3288.dtsi"
+#include "rk3288-vmarc-som.dtsi"
+#include
+
+/ {
+ model = "Radxa ROCK Pi N8";
+ compatible = "radxa,rockpi-n8", "vamrs,rk3288-vmarc-som",
+"rockchip,rk3288";
+};
diff --git a/arch/arm/dts/rk3288-vmarc-som.dtsi
b/arch/arm/dts/rk3288-vmarc-som.dtsi
index 1549ac4044..3cffe61cdf 100644
--- a/arch/arm/dts/rk3288-vmarc-som.dtsi
+++ b/arch/arm/dts/rk3288-vmarc-som.dtsi
@@ -251,15 +251,6 @@
};
};
-&io_domains {
- bb-supply = <&vcc_io>;
- flash0-supply = <&vccio_flash>;
- gpio1830-supply = <&vcc_18>;
- gpio30-supply = <&vcc_io>;
- sdcard-supply = <&vccio_sd>;
- status = "okay";
-};
-
&pinctrl {
pcfg_pull_none_drv_8ma: pcfg-pull-none-drv-8ma {
drive-strength = <8>;
diff --git a/board/rockchip/evb_rk3288/MAINTAINERS
b/board/rockchip/evb_rk3288/MAINTAINERS
index 8a4f127f88..9bd6b1e8a4 100644
--- a/board/rockchip/evb_rk3288/MAINTAINERS
+++ b/board/rockchip/evb_rk3288/MAINTAINERS
@@ -4,3 +4,9 @@ S: Maintained
F:board/rockchip/evb_rk3288
F:include/configs/evb_rk3288.h
F:configs/evb-rk3288_defconfig
+
+ROCK-PI-N8
+M: Jagan Teki
+S: Maintained
+F: configs/rock-pi-n8-rk3288_defconfig
+F: arch/arm/dts/rk3288-rock-pi-n8-u-boot.dtsi
diff --git a/configs/rock-pi-n8-rk3288_defconfig
b/configs/rock-pi-n8-rk3288_defconfig
new file mode 100644
index 00..6b31e19eda
--- /dev/null
+++ b/configs/rock-pi-n8-rk3288_defconfig
@@ -0,0 +1,66 @@
+CONFIG_ARM=y
+# CONFIG_SPL_USE_ARCH_MEMCPY is not set
+# CONFIG_SPL_USE_ARCH_MEMSET is not set
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x0010
+CONFIG_ENV_OFFSET=0x3F8000
+CONFIG_ROCKCHIP_RK3288=y
+CONFIG_TARGET_EVB_RK3288=y
+CONFIG_SPL_STACK_R_ADDR=0x8
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEBUG_UART_BASE=0xff69
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_DEBUG_UART=y
+CONFIG_USE_PREBOOT=y
+CONFIG_SILENT_CONSOLE=y
+CONFIG_DEFAULT_FDT_FILE="rk3288-rock-pi-n8.dtb"
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000
+CONFIG_CMD_SPL=y
+CONFIG_CM
Re: [PATCH 1/3] ARM: dts: rockchip: radxa-dalang: Update sdmmc properties
On 2020/6/19 上午12:12, Jagan Teki wrote:
Radxa dalang carrier boards are used to mount vmarc SoM's
of rk3399pro and rk3288 to make complete SBC.
Among these combinations, card detection gpio, max-frequency
properties are used with rk3399pro SoM but not required for
rk3288 SoM based on the hardware schematics.
So, let's move these sdmmc specific properties on associate
vmarc dtsi to make common use of dalang carrier device tree file.
Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/dts/rk3399pro-vmarc-som.dtsi | 5 +
arch/arm/dts/rockchip-radxa-dalang-carrier.dtsi | 2 --
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/rk3399pro-vmarc-som.dtsi
b/arch/arm/dts/rk3399pro-vmarc-som.dtsi
index 0a516334f1..6fd17e8a81 100644
--- a/arch/arm/dts/rk3399pro-vmarc-som.dtsi
+++ b/arch/arm/dts/rk3399pro-vmarc-som.dtsi
@@ -317,6 +317,11 @@
status = "okay";
};
+&sdmmc {
+ cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
+ max-frequency = <15000>;
+};
+
&tsadc {
status = "okay";
rockchip,hw-tshut-mode = <1>;
diff --git a/arch/arm/dts/rockchip-radxa-dalang-carrier.dtsi
b/arch/arm/dts/rockchip-radxa-dalang-carrier.dtsi
index df3712aedf..3e54f38f0a 100644
--- a/arch/arm/dts/rockchip-radxa-dalang-carrier.dtsi
+++ b/arch/arm/dts/rockchip-radxa-dalang-carrier.dtsi
@@ -52,10 +52,8 @@
bus-width = <4>;
cap-mmc-highspeed;
cap-sd-highspeed;
- cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
disable-wp;
vqmmc-supply = <&vccio_sd>;
- max-frequency = <15000>;
pinctrl-names = "default";
pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
status = "okay";
Re: [PATCH 1/2] rockchip: clk: rk3188: change APLL to safe 600MHz
On 2020/6/22 下午9:17, Alexander Kochetkov wrote:
The commit 84a6a27ae3ff ("rockchip: rk3188: init CPU freq in clock
driver") changed ARM clock from 600MHz to 1600MHz. It made boot
unstable due to the fact that PMIC at the start generates insufficient
voltage for operation. See also: commit f4f57c58b589 ("rockchip:
rk3188: Setup the armclk in spl").
Fixes commit 84a6a27ae3ff ("rockchip: rk3188: init CPU freq in clock
driver").
Signed-off-by: Alexander Kochetkov
Reviewed-by: Kever Yang
Thanks,
- Kever
---
drivers/clk/rockchip/clk_rk3188.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk_rk3188.c
b/drivers/clk/rockchip/clk_rk3188.c
index b193ac913e..4fc5c78563 100644
--- a/drivers/clk/rockchip/clk_rk3188.c
+++ b/drivers/clk/rockchip/clk_rk3188.c
@@ -564,7 +564,8 @@ static int rk3188_clk_probe(struct udevice *dev)
rkclk_init(priv->cru, priv->grf, priv->has_bwadj);
/* Init CPU frequency */
- rkclk_configure_cpu(priv->cru, priv->grf, APLL_HZ, priv->has_bwadj);
+ rkclk_configure_cpu(priv->cru, priv->grf, APLL_SAFE_HZ,
+ priv->has_bwadj);
#endif
return 0;
Re: [PATCH 2/2] rockchip: clk: rk3188: enable bwadj for rk3188 DPLL
Hi Alex,
I think it will be better to update the rk3188_clk_probe() function
instead of
what you have modified if the RK3188 and RK3188A has the same PLL(I'm
not sure
about it now).
Thanks,
- Kever
On 2020/6/22 下午9:17, Alexander Kochetkov wrote:
Empirically, I found that DPLL on rk3188 has bwadj registers.
Configuring DPLL with bwadj increase DPLL stability. Because
of DPLL provide clock for ethernet, enabling bwaj reduces
the number of errors on the ethernet.
Signed-off-by: Alexander Kochetkov
---
drivers/clk/rockchip/clk_rk3188.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/rockchip/clk_rk3188.c
b/drivers/clk/rockchip/clk_rk3188.c
index 4fc5c78563..ee5782d25d 100644
--- a/drivers/clk/rockchip/clk_rk3188.c
+++ b/drivers/clk/rockchip/clk_rk3188.c
@@ -117,7 +117,7 @@ static int rkclk_set_pll(struct rk3188_cru *cru, enum
rk_clk_id clk_id,
}
static int rkclk_configure_ddr(struct rk3188_cru *cru, struct rk3188_grf *grf,
- unsigned int hz, bool has_bwadj)
+ unsigned int hz)
{
static const struct pll_div dpll_cfg[] = {
{.nf = 75, .nr = 1, .no = 6},
@@ -149,7 +149,8 @@ static int rkclk_configure_ddr(struct rk3188_cru *cru,
struct rk3188_grf *grf,
rk_clrsetreg(&cru->cru_mode_con, DPLL_MODE_MASK << DPLL_MODE_SHIFT,
DPLL_MODE_SLOW << DPLL_MODE_SHIFT);
- rkclk_set_pll(cru, CLK_DDR, &dpll_cfg[cfg], has_bwadj);
+ /* rk3188 and rk3188a DPLL has bwadj */
+ rkclk_set_pll(cru, CLK_DDR, &dpll_cfg[cfg], 1);
/* wait for pll lock */
while (!(readl(&grf->soc_status0) & SOCSTS_DPLL_LOCK))
@@ -504,8 +505,7 @@ static ulong rk3188_clk_set_rate(struct clk *clk, ulong
rate)
priv->has_bwadj);
break;
case CLK_DDR:
- new_rate = rkclk_configure_ddr(priv->cru, priv->grf, rate,
- priv->has_bwadj);
+ new_rate = rkclk_configure_ddr(priv->cru, priv->grf, rate);
break;
case HCLK_EMMC:
case HCLK_SDMMC:
Re: [PATCH 2/2] rockchip: clk: rk3188: enable bwadj for rk3188 DPLL
Hi Kever,
Strange… Then I tested a year ago I saw, that writing into bwadj registers had
no effect
for some PLLs. But now I did another test. See patch and output. Looks like
rk3188 allow
writing into bwadj fields.
So I do something like 'priv->has_bwadj = 1' in the rk3188_clk_probe() and
send try 2.
--
--- a/drivers/clk/rockchip/clk_rk3188.c
+++ b/drivers/clk/rockchip/clk_rk3188.c
@@ -91,7 +91,7 @@ static int rkclk_set_pll(struct rk3188_cru *cru, enum
rk_clk_id clk_id,
uint vco_hz = OSC_HZ / 1000 * div->nf / div->nr * 1000;
uint output_hz = vco_hz / div->no;
- debug("PLL at %x: nf=%d, nr=%d, no=%d, vco=%u Hz, output=%u Hz\n",
+ printf("PLL at %x: nf=%d, nr=%d, no=%d, vco=%u Hz, output=%u Hz\n",
(uint)pll, div->nf, div->nr, div->no, vco_hz, output_hz);
assert(vco_hz >= VCO_MIN_HZ && vco_hz <= VCO_MAX_HZ &&
output_hz >= OUTPUT_MIN_HZ && output_hz <= OUTPUT_MAX_HZ &&
@@ -105,8 +105,12 @@ static int rkclk_set_pll(struct rk3188_cru *cru, enum
rk_clk_id clk_id,
((div->nr - 1) << CLKR_SHIFT) | (div->no - 1));
rk_clrsetreg(&pll->con1, CLKF_MASK, div->nf - 1);
- if (has_bwadj)
+ if (has_bwadj) {
+ printf("before: %p: con2=%x, clr=%x, set=%x\n",
+ &pll->con2, readl(&pll->con2), PLL_BWADJ_MASK, (div->nf
>> 1) - 1);
rk_clrsetreg(&pll->con2, PLL_BWADJ_MASK, (div->nf >> 1) - 1);
+ printf("after: %p: con2=%x\n", &pll->con2, readl(&pll->con2));
+ }
udelay(10);
@@ -552,7 +556,9 @@ static int rk3188_clk_probe(struct udevice *dev)
priv->grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
if (IS_ERR(priv->grf))
return PTR_ERR(priv->grf);
- priv->has_bwadj = (type == RK3188A_CRU) ? 1 : 0;
+ printf("type %d\n", type);
+ //priv->has_bwadj = (type == RK3188A_CRU) ? 1 : 0;
+ priv->has_bwadj = 1;
—
type 0
PLL at 2030: nf=64, nr=1, no=2, vco=153600 Hz, output=76800 Hz
before: 2038: con2=94, clr=fff, set=1f
after: 2038: con2=1f
PLL at 2020: nf=32, nr=1, no=2, vco=76800 Hz, output=38400 Hz
before: 2028: con2=63, clr=fff, set=f
after: 2028: con2=f
PLL at 2000: nf=50, nr=1, no=2, vco=12 Hz, output=6 Hz
before: 2008: con2=18, clr=fff, set=18
after: 2008: con2=18
PLL at 2010: nf=75, nr=1, no=4, vco=18 Hz, output=45000 Hz
before: 2018: con2=10b, clr=fff, set=24
after: 2018: con2=24
> 27 июня 2020 г., в 18:17, Kever Yang написал(а):
>
> Hi Alex,
>
> I think it will be better to update the rk3188_clk_probe() function
> instead of
>
> what you have modified if the RK3188 and RK3188A has the same PLL(I'm not sure
>
> about it now).
>
>
> Thanks,
>
> - Kever
>
> On 2020/6/22 下午9:17, Alexander Kochetkov wrote:
>> Empirically, I found that DPLL on rk3188 has bwadj registers.
>> Configuring DPLL with bwadj increase DPLL stability. Because
>> of DPLL provide clock for ethernet, enabling bwaj reduces
>> the number of errors on the ethernet.
>>
>> Signed-off-by: Alexander Kochetkov
>> ---
>> drivers/clk/rockchip/clk_rk3188.c | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/clk/rockchip/clk_rk3188.c
>> b/drivers/clk/rockchip/clk_rk3188.c
>> index 4fc5c78563..ee5782d25d 100644
>> --- a/drivers/clk/rockchip/clk_rk3188.c
>> +++ b/drivers/clk/rockchip/clk_rk3188.c
>> @@ -117,7 +117,7 @@ static int rkclk_set_pll(struct rk3188_cru *cru, enum
>> rk_clk_id clk_id,
>> }
>>static int rkclk_configure_ddr(struct rk3188_cru *cru, struct rk3188_grf
>> *grf,
>> - unsigned int hz, bool has_bwadj)
>> + unsigned int hz)
>> {
>> static const struct pll_div dpll_cfg[] = {
>> {.nf = 75, .nr = 1, .no = 6},
>> @@ -149,7 +149,8 @@ static int rkclk_configure_ddr(struct rk3188_cru *cru,
>> struct rk3188_grf *grf,
>> rk_clrsetreg(&cru->cru_mode_con, DPLL_MODE_MASK << DPLL_MODE_SHIFT,
>> DPLL_MODE_SLOW << DPLL_MODE_SHIFT);
>> - rkclk_set_pll(cru, CLK_DDR, &dpll_cfg[cfg], has_bwadj);
>> +/* rk3188 and rk3188a DPLL has bwadj */
>> +rkclk_set_pll(cru, CLK_DDR, &dpll_cfg[cfg], 1);
>> /* wait for pll lock */
>> while (!(readl(&grf->soc_status0) & SOCSTS_DPLL_LOCK))
>> @@ -504,8 +505,7 @@ static ulong rk3188_clk_set_rate(struct clk *clk, ulong
>> rate)
>> priv->has_bwadj);
>> break;
>> case CLK_DDR:
>> -new_rate = rkclk_configure_ddr(priv->cru, priv->grf, rate,
>> - priv->has_bwadj);
>> +new_rate = rkclk_configure_ddr(priv->cru, priv->grf, rate);
>> break;
>> case HCLK_EMMC:
>> case HCLK_SDMMC:
>
>
Re: [PATCH v3 5/6] crypto/fsl: instantiate the RNG with prediciton resistance
On 6/25/20 2:19 PM, Michael Walle wrote:
> If it is already instantiated tear it down first and then reinstanciate
> it again with prediction resistance.
>
> Signed-off-by: Michael Walle
> ---
> drivers/crypto/fsl/desc.h| 2 ++
> drivers/crypto/fsl/jobdesc.c | 12 ++-
> drivers/crypto/fsl/jobdesc.h | 2 ++
> drivers/crypto/fsl/jr.c | 67
> include/fsl_sec.h| 7 ++--
> 5 files changed, 79 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/crypto/fsl/desc.h b/drivers/crypto/fsl/desc.h
> index 11ad506829..3589e6ea02 100644
> --- a/drivers/crypto/fsl/desc.h
> +++ b/drivers/crypto/fsl/desc.h
> @@ -520,6 +520,8 @@
> #define OP_ALG_ICV_OFF (0 << OP_ALG_ICV_SHIFT)
> #define OP_ALG_ICV_ON(1 << OP_ALG_ICV_SHIFT)
>
> +#define OP_ALG_PR_ON 0x02
> +
> #define OP_ALG_DIR_SHIFT 0
> #define OP_ALG_DIR_MASK 1
> #define OP_ALG_DECRYPT 0
> diff --git a/drivers/crypto/fsl/jobdesc.c b/drivers/crypto/fsl/jobdesc.c
> index 6102e9c06b..d9554c550b 100644
> --- a/drivers/crypto/fsl/jobdesc.c
> +++ b/drivers/crypto/fsl/jobdesc.c
> @@ -266,7 +266,8 @@ void inline_cnstr_jobdesc_rng_instantiation(u32 *desc,
> int handle, int do_sk)
>
> /* INIT RNG in non-test mode */
> append_operation(desc, OP_TYPE_CLASS1_ALG | OP_ALG_ALGSEL_RNG |
> - (handle << OP_ALG_AAI_SHIFT) | OP_ALG_AS_INIT);
> + (handle << OP_ALG_AAI_SHIFT) | OP_ALG_AS_INIT |
> + OP_ALG_PR_ON);
>
> /* For SH0, Secure Keys must be generated as well */
> if (!handle && do_sk) {
> @@ -286,6 +287,15 @@ void inline_cnstr_jobdesc_rng_instantiation(u32 *desc,
> int handle, int do_sk)
> }
> }
>
> +/* Descriptor for deinstantiation of the RNG block. */
> +void inline_cnstr_jobdesc_rng_deinstantiation(u32 *desc, int handle)
> +{
> + init_job_desc(desc, 0);
> +
> + append_operation(desc, OP_TYPE_CLASS1_ALG | OP_ALG_ALGSEL_RNG |
> + (handle << OP_ALG_AAI_SHIFT) | OP_ALG_AS_INITFINAL);
> +}
> +
> /* Change key size to bytes form bits in calling function*/
> void inline_cnstr_jobdesc_pkha_rsaexp(uint32_t *desc,
> struct pk_in_params *pkin, uint8_t *out,
> diff --git a/drivers/crypto/fsl/jobdesc.h b/drivers/crypto/fsl/jobdesc.h
> index 14b2a119d7..5185ddd535 100644
> --- a/drivers/crypto/fsl/jobdesc.h
> +++ b/drivers/crypto/fsl/jobdesc.h
> @@ -41,6 +41,8 @@ void inline_cnstr_jobdesc_blob_decap(uint32_t *desc,
> uint8_t *key_idnfr,
>
> void inline_cnstr_jobdesc_rng_instantiation(u32 *desc, int handle, int
> do_sk);
>
> +void inline_cnstr_jobdesc_rng_deinstantiation(u32 *desc, int handle);
> +
> void inline_cnstr_jobdesc_pkha_rsaexp(uint32_t *desc,
> struct pk_in_params *pkin, uint8_t *out,
> uint32_t out_siz);
> diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
> index 42865a6cd7..00a3244b18 100644
> --- a/drivers/crypto/fsl/jr.c
> +++ b/drivers/crypto/fsl/jr.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
> #include "fsl_sec.h"
> #include "jr.h"
> #include "jobdesc.h"
> @@ -446,6 +447,51 @@ int sec_reset(void)
> return sec_reset_idx(0);
> }
> #ifndef CONFIG_SPL_BUILD
> +static int deinstantiate_rng(u8 sec_idx, int state_handle_mask)
> +{
> + u32 *desc;
> + int sh_idx, ret = 0;
> + int desc_size = sizeof(u32) * 2;
> +
> + desc = malloc_cache_aligned(desc_size);
> + if (!desc) {
> + debug("cannot allocate RNG init descriptor memory\n");
> + return -ENOMEM;
> + }
> +
> + for (sh_idx = 0; sh_idx < RNG4_MAX_HANDLES; sh_idx++) {
> + /*
> + * If the corresponding bit is set, then it means the state
> + * handle was initialized by us, and thus it needs to be
> + * deinitialized as well
> + */
> +
> + if (state_handle_mask & RDSTA_IF(sh_idx)) {
> + /*
> + * Create the descriptor for deinstantating this state
> + * handle.
> + */
> + inline_cnstr_jobdesc_rng_deinstantiation(desc, sh_idx);
> + flush_dcache_range((unsigned long)desc,
> +(unsigned long)desc + desc_size);
flush_dcache_range() tests that start and stop address are multiples of
CONFIG_SYS_CACHELINE_SIZE (= ARCH_DMA_MINALIGN on ARM). See
check_cache_range(start, stop).
So you should use ALIGN(desc_size, ARCH_DMA_MINALIGN) instead of desc_size.
Best regards
Heinrich
> +
> + ret = run_descriptor_jr_idx(desc, sec_idx);
> + if (ret) {
> + printf("SEC%u: RNG4 SH%d deinstantiation
> failed with error 0x%x\n",
> +sec_idx, sh_idx, r
Re: [PATCH v3 0/6] crypto/fsl: add RNG support
Am 2020-06-26 18:26, schrieb Heinrich Schuchardt: On 6/25/20 11:01 PM, Michael Walle wrote: Am 2020-06-25 18:03, schrieb Heinrich Schuchardt: On 25.06.20 16:36, Heinrich Schuchardt wrote: On 25.06.20 14:18, Michael Walle wrote: First, improve the compatibility on newer Era CAAMs. These introduced new version registers. Secondly, add RNG support for the CAAM. This way we get random number generator support for EFI for free and KASLR will work with ARM64 kernels booted with bootefi. It seems that a Kconfig dependency at least on CONFIG_SYS_FSL_HAS_SEC which itself depends on CONFIG_IMX_HAB is missing: wandboard_defconfig + FSL_CAAM + DM_RNG gives me a bunch of errors drivers/crypto/fsl/jr.c: In function ‘start_jr0’: drivers/crypto/fsl/jr.c:47:2: error: unknown type name ‘ccsr_sec_t’; did you mean ‘pci_dev_t’? ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx); ^~ pci_dev_t In file included from ./arch/arm/include/asm/byteorder.h:29, from include/linux/libfdt_env.h:15, from include/linux/libfdt.h:6, from include/fdtdec.h:17, from include/asm-generic/global_data.h:23, from ./arch/arm/include/asm/global_data.h:87, from include/common.h:26, from drivers/crypto/fsl/jr.c:8: drivers/crypto/fsl/jr.c:48:29: error: request for member ‘ctpr_ms’ in something not a structure or union u32 ctpr_ms = sec_in32(&sec->ctpr_ms); ^~ But if I enable IMX_HAB booting fails with: "hab fuse not enabled". Why should I need to enable the HAB fuse to use the random number generator on the i.MX6? With this change I can build the RNG driver for the i.MX6 Wandboard: diff --git a/drivers/crypto/fsl/Kconfig b/drivers/crypto/fsl/Kconfig index 5ed6140da3..84783ea987 100644 --- a/drivers/crypto/fsl/Kconfig +++ b/drivers/crypto/fsl/Kconfig @@ -37,7 +37,6 @@ config SYS_FSL_SEC_BE config SYS_FSL_SEC_COMPAT int "Freescale Secure Boot compatibility" - depends on SYS_FSL_HAS_SEC default 2 if SYS_FSL_SEC_COMPAT_2 default 4 if SYS_FSL_SEC_COMPAT_4 default 5 if SYS_FSL_SEC_COMPAT_5 Even if you do not plan to support the i.MX6, I would recommend this change to separate HAB and RNG. I don't think this is the correct place. Rather the architecture should set SYS_FSL_HAS_SEC if it actually has the SEC. I mean it already sets the COMPAT level but not the actual config which indicates it has one. At the moment it depends on IMX_HAB; I don't know the reasoning behind this. But I don't see how this would be part of this series. ARCH_MX7 (arch/arm/Kconfig) has: select SYS_FSL_HAS_SEC if IMX_HAB So according to your suggestion this should be changed to select SYS_FSL_HAS_SEC ? And the same added to ARCH_MX6? yes, because HAS_SEC is a hardware feature, why should that be dependant on a feature which is selected by the user? But I don't know if there are any side effects. Also I don't know if the SEC is available in all SoC of the imx6/7 series. -michael
Re: [PATCH v3 0/6] crypto/fsl: add RNG support
Am 2020-06-26 18:26, schrieb Heinrich Schuchardt: On 6/25/20 11:01 PM, Michael Walle wrote: Am 2020-06-25 18:03, schrieb Heinrich Schuchardt: On 25.06.20 16:36, Heinrich Schuchardt wrote: On 25.06.20 14:18, Michael Walle wrote: First, improve the compatibility on newer Era CAAMs. These introduced new version registers. Secondly, add RNG support for the CAAM. This way we get random number generator support for EFI for free and KASLR will work with ARM64 kernels booted with bootefi. It seems that a Kconfig dependency at least on CONFIG_SYS_FSL_HAS_SEC which itself depends on CONFIG_IMX_HAB is missing: wandboard_defconfig + FSL_CAAM + DM_RNG gives me a bunch of errors drivers/crypto/fsl/jr.c: In function ‘start_jr0’: drivers/crypto/fsl/jr.c:47:2: error: unknown type name ‘ccsr_sec_t’; did you mean ‘pci_dev_t’? ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx); ^~ pci_dev_t In file included from ./arch/arm/include/asm/byteorder.h:29, from include/linux/libfdt_env.h:15, from include/linux/libfdt.h:6, from include/fdtdec.h:17, from include/asm-generic/global_data.h:23, from ./arch/arm/include/asm/global_data.h:87, from include/common.h:26, from drivers/crypto/fsl/jr.c:8: drivers/crypto/fsl/jr.c:48:29: error: request for member ‘ctpr_ms’ in something not a structure or union u32 ctpr_ms = sec_in32(&sec->ctpr_ms); ^~ But if I enable IMX_HAB booting fails with: "hab fuse not enabled". Why should I need to enable the HAB fuse to use the random number generator on the i.MX6? With this change I can build the RNG driver for the i.MX6 Wandboard: diff --git a/drivers/crypto/fsl/Kconfig b/drivers/crypto/fsl/Kconfig index 5ed6140da3..84783ea987 100644 --- a/drivers/crypto/fsl/Kconfig +++ b/drivers/crypto/fsl/Kconfig @@ -37,7 +37,6 @@ config SYS_FSL_SEC_BE config SYS_FSL_SEC_COMPAT int "Freescale Secure Boot compatibility" - depends on SYS_FSL_HAS_SEC default 2 if SYS_FSL_SEC_COMPAT_2 default 4 if SYS_FSL_SEC_COMPAT_4 default 5 if SYS_FSL_SEC_COMPAT_5 Even if you do not plan to support the i.MX6, I would recommend this change to separate HAB and RNG. I don't think this is the correct place. Rather the architecture should set SYS_FSL_HAS_SEC if it actually has the SEC. I mean it already sets the COMPAT level but not the actual config which indicates it has one. At the moment it depends on IMX_HAB; I don't know the reasoning behind this. But I don't see how this would be part of this series. ARCH_MX7 (arch/arm/Kconfig) has: select SYS_FSL_HAS_SEC if IMX_HAB So according to your suggestion this should be changed to select SYS_FSL_HAS_SEC ? And the same added to ARCH_MX6? Also I don't know why the SYS_FSL_SEC_COMPAT is user selectable: --- a/drivers/crypto/fsl/Kconfig +++ b/drivers/crypto/fsl/Kconfig @@ -36,7 +36,7 @@ config SYS_FSL_SEC_BE bool "Big-endian access to Freescale Secure Boot" config SYS_FSL_SEC_COMPAT - int "Freescale Secure Boot compatibility" + int depends on SYS_FSL_HAS_SEC default 2 if SYS_FSL_SEC_COMPAT_2 default 4 if SYS_FSL_SEC_COMPAT_4 -michael
[PATCH] sync helios4 config to clearfog and dts to kernel
From: Dennis Gilmore
The helios4 is built on the same microsom as the clearfog, by syncing the config
we enable the same featureset that exists in the som on the helios4. The current
config does not boot as some of the clearfog changes needed to be made on the
helios4 also, generally speaking most changes for the clearfog should also be
made on the helios4.
Signed-off-by: Dennis Gilmore
---
arch/arm/dts/armada-388-helios4-u-boot.dtsi | 15
arch/arm/dts/armada-388-helios4.dts | 16 ++--
configs/helios4_defconfig | 20 +++--
include/configs/helios4.h | 95 -
4 files changed, 93 insertions(+), 53 deletions(-)
diff --git a/arch/arm/dts/armada-388-helios4-u-boot.dtsi
b/arch/arm/dts/armada-388-helios4-u-boot.dtsi
index f0da9f42de..0753889854 100644
--- a/arch/arm/dts/armada-388-helios4-u-boot.dtsi
+++ b/arch/arm/dts/armada-388-helios4-u-boot.dtsi
@@ -14,6 +14,9 @@
&spi1 {
u-boot,dm-spl;
+ spi-flash@0 {
+ u-boot,dm-spl;
+ };
};
&w25q32 {
@@ -21,6 +24,18 @@
u-boot,dm-spl;
};
+&gpio0 {
+ u-boot,dm-spl;
+};
+
+&ahci0 {
+ u-boot,dm-spl;
+};
+
+&ahci1 {
+ u-boot,dm-spl;
+};
+
&sdhci {
u-boot,dm-spl;
};
diff --git a/arch/arm/dts/armada-388-helios4.dts
b/arch/arm/dts/armada-388-helios4.dts
index a154e0f4f4..fb49df2a3b 100644
--- a/arch/arm/dts/armada-388-helios4.dts
+++ b/arch/arm/dts/armada-388-helios4.dts
@@ -140,11 +140,6 @@
soc {
internal-regs {
i2c@11000 {
- clock-frequency = <40>;
- pinctrl-0 = <&i2c0_pins>;
- pinctrl-names = "default";
- status = "okay";
-
/*
* PCA9655 GPIO expander, up to 1MHz clock.
* 0-Board Revision bit 0 #
@@ -187,8 +182,7 @@
gpio-hog;
gpios = <5 GPIO_ACTIVE_HIGH>;
input;
- line-name =
- "usb-overcurrent-status";
+ line-name =
"usb-overcurrent-status";
};
};
@@ -248,7 +242,7 @@
bus-width = <4>;
cd-gpios = <&gpio0 20 GPIO_ACTIVE_LOW>;
no-1-8-v;
- pinctrl-0 = <µsom_sdhci_pins
+ pinctrl-0 = <&helios_sdhci_pins
&helios_sdhci_cd_pins>;
pinctrl-names = "default";
status = "okay";
@@ -286,6 +280,12 @@
marvell,pins = "mpp20";
marvell,function = "gpio";
};
+ helios_sdhci_pins: helios-sdhci-pins {
+ marvell,pins = "mpp21", "mpp28",
+ "mpp37", "mpp38",
+ "mpp39", "mpp40";
+ marvell,function = "sd0";
+ };
helios_led_pins: helios-led-pins {
marvell,pins = "mpp24", "mpp25",
"mpp49", "mpp50",
diff --git a/configs/helios4_defconfig b/configs/helios4_defconfig
index e15f10cdd5..9cc87fd96a 100644
--- a/configs/helios4_defconfig
+++ b/configs/helios4_defconfig
@@ -1,5 +1,6 @@
CONFIG_ARM=y
CONFIG_ARCH_CPU_INIT=y
+CONFIG_SYS_THUMB_BUILD=y
CONFIG_ARCH_MVEBU=y
CONFIG_SYS_TEXT_BASE=0x0080
CONFIG_SPL_LIBCOMMON_SUPPORT=y
@@ -24,40 +25,47 @@ CONFIG_USE_PREBOOT=y
CONFIG_SYS_CONSOLE_INFO_QUIET=y
# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_SPL_SYS_MALLOC_SIMPLE=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x141
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET=0x1
+CONFIG_SPL_I2C_SUPPORT=y
+CONFIG_CMD_TLV_EEPROM=y
+CONFIG_SPL_CMD_TLV_EEPROM=y
# CONFIG_CMD_FLASH is not set
CONFIG_CMD_GPIO=y
CONFIG_CMD_I2C=y
CONFIG_CMD_MMC=y
+CONFIG_CMD_PCI=y
CONFIG_CMD_SPI=y
CONFIG_CMD_USB=y
# CONFIG_CMD_SETEXPR is not set
CONFIG_CMD_TFTPPUT=y
CONFIG_CMD_CACHE=y
CONFIG_CMD_TIME=y
+CONFIG_CMD_MVEBU_BUBT=y
# CONFIG_SPL_PARTITION_UUIDS is not set
CONFIG_DEFAULT_DEVICE_TREE="armada-388-helios4"
CONFIG_NET_RANDOM_ETHADDR=y
CONFIG_SPL_OF_TRANSLATE=y
-CONFIG_SCSI_AHCI=y
+CONFIG_AHCI_MVEBU=y
CONFIG_DM_PCA953X=y
CONFIG_DM_I2C=y
-CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
-CONFIG_I2C_DEFAULT_BUS_N
[PATCH v4 1/6] crypto/fsl: make SEC%u status line consistent
Align the status line with all the other output in U-Boot.
Before the change:
DDR3.9 GiB (DDR3, 32-bit, CL=11, ECC on)
SEC0: RNG instantiated
WDT: Started with servicing (60s timeout)
After the change:
DDR3.9 GiB (DDR3, 32-bit, CL=11, ECC on)
SEC0: RNG instantiated
WDT: Started with servicing (60s timeout)
Signed-off-by: Michael Walle
Reviewed-by: Horia Geantă
---
drivers/crypto/fsl/jr.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index e2d9216cfc..bbdbcb8e58 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -478,8 +478,8 @@ static int instantiate_rng(uint8_t sec_idx)
ret = run_descriptor_jr_idx(desc, sec_idx);
if (ret)
- printf("RNG: Instantiation failed with error 0x%x\n",
- ret);
+ printf("SEC%u: RNG4 SH%d instantiation failed with
error 0x%x\n",
+ sec_idx, sh_idx, ret);
rdsta_val = sec_in32(&rng->rdsta) & RNG_STATE_HANDLE_MASK;
if (!(rdsta_val & (1 << sh_idx))) {
@@ -569,7 +569,7 @@ static int rng_init(uint8_t sec_idx)
ret = instantiate_rng(sec_idx);
} while ((ret == -1) && (ent_delay < RTSDCTL_ENT_DLY_MAX));
if (ret) {
- printf("RNG: Failed to instantiate RNG\n");
+ printf("SEC%u: Failed to instantiate RNG\n", sec_idx);
return ret;
}
@@ -592,7 +592,7 @@ int sec_init_idx(uint8_t sec_idx)
#endif
if (!(sec_idx < CONFIG_SYS_FSL_MAX_NUM_OF_SEC)) {
- printf("SEC initialization failed\n");
+ printf("SEC%u: initialization failed\n", sec_idx);
return -1;
}
@@ -640,7 +640,7 @@ int sec_init_idx(uint8_t sec_idx)
ret = jr_init(sec_idx);
if (ret < 0) {
- printf("SEC initialization failed\n");
+ printf("SEC%u: initialization failed\n", sec_idx);
return -1;
}
@@ -654,10 +654,10 @@ int sec_init_idx(uint8_t sec_idx)
#ifndef CONFIG_SPL_BUILD
if (get_rng_vid(sec_idx) >= 4) {
if (rng_init(sec_idx) < 0) {
- printf("SEC%u: RNG instantiation failed\n", sec_idx);
+ printf("SEC%u: RNG instantiation failed\n", sec_idx);
return -1;
}
- printf("SEC%u: RNG instantiated\n", sec_idx);
+ printf("SEC%u: RNG instantiated\n", sec_idx);
}
#endif
return ret;
--
2.20.1
[PATCH v4 2/6] crypto/fsl: export caam_get_era()
We need the era in other modules, too. For example, to get the RNG
version.
Signed-off-by: Michael Walle
Reviewed-by: Horia Geantă
---
drivers/crypto/fsl/sec.c | 10 +-
include/fsl_sec.h| 2 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/fsl/sec.c b/drivers/crypto/fsl/sec.c
index a2c0bfaf44..f0a4a63d88 100644
--- a/drivers/crypto/fsl/sec.c
+++ b/drivers/crypto/fsl/sec.c
@@ -98,7 +98,15 @@ void fdt_fixup_crypto_node(void *blob, int sec_rev)
fdt_strerror(err));
}
#elif CONFIG_SYS_FSL_SEC_COMPAT >= 4 /* SEC4 */
-static u8 caam_get_era(void)
+/**
+ * caam_get_era() - fetch the CAAM's era
+ *
+ * The SEC module povides an "Era" which can be used to differentiate
+ * between different revisions.
+ *
+ * Return: era of the SEC.
+ */
+u8 caam_get_era(void)
{
static const struct {
u16 ip_id;
diff --git a/include/fsl_sec.h b/include/fsl_sec.h
index c0d2c7e866..2ebb75c9b2 100644
--- a/include/fsl_sec.h
+++ b/include/fsl_sec.h
@@ -316,6 +316,8 @@ int blob_dek(const u8 *src, u8 *dst, u8 len);
int sec_init_idx(uint8_t);
#endif
int sec_init(void);
+
+u8 caam_get_era(void);
#endif
#endif /* __FSL_SEC_H */
--
2.20.1
[PATCH v4 3/6] crypto/fsl: support newer SEC modules
Since Era 10, the version registers changed. Add the version registers
and use them on newer modules.
Signed-off-by: Michael Walle
Reviewed-by: Horia Geantă
---
drivers/crypto/fsl/jr.c | 12 --
include/fsl_sec.h | 51 +++--
2 files changed, 54 insertions(+), 9 deletions(-)
diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index bbdbcb8e58..5275c50e8b 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -498,9 +498,17 @@ static int instantiate_rng(uint8_t sec_idx)
static u8 get_rng_vid(uint8_t sec_idx)
{
ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
- u32 cha_vid = sec_in32(&sec->chavid_ls);
+ u8 vid;
- return (cha_vid & SEC_CHAVID_RNG_LS_MASK) >> SEC_CHAVID_LS_RNG_SHIFT;
+ if (caam_get_era() < 10) {
+ vid = (sec_in32(&sec->chavid_ls) & SEC_CHAVID_RNG_LS_MASK)
+ >> SEC_CHAVID_LS_RNG_SHIFT;
+ } else {
+ vid = (sec_in32(&sec->vreg.rng) & CHA_VER_VID_MASK)
+ >> CHA_VER_VID_SHIFT;
+ }
+
+ return vid;
}
/*
diff --git a/include/fsl_sec.h b/include/fsl_sec.h
index 2ebb75c9b2..8dce0bbb1b 100644
--- a/include/fsl_sec.h
+++ b/include/fsl_sec.h
@@ -73,6 +73,41 @@ struct rng4tst {
u32 rsvd2[15];
};
+/* Version registers (Era 10+) */
+struct version_regs {
+ u32 crca; /* CRCA_VERSION */
+ u32 afha; /* AFHA_VERSION */
+ u32 kfha; /* KFHA_VERSION */
+ u32 pkha; /* PKHA_VERSION */
+ u32 aesa; /* AESA_VERSION */
+ u32 mdha; /* MDHA_VERSION */
+ u32 desa; /* DESA_VERSION */
+ u32 snw8a; /* SNW8A_VERSION */
+ u32 snw9a; /* SNW9A_VERSION */
+ u32 zuce; /* ZUCE_VERSION */
+ u32 zuca; /* ZUCA_VERSION */
+ u32 ccha; /* CCHA_VERSION */
+ u32 ptha; /* PTHA_VERSION */
+ u32 rng;/* RNG_VERSION */
+ u32 trng; /* TRNG_VERSION */
+ u32 aaha; /* AAHA_VERSION */
+ u32 rsvd[10];
+ u32 sr; /* SR_VERSION */
+ u32 dma;/* DMA_VERSION */
+ u32 ai; /* AI_VERSION */
+ u32 qi; /* QI_VERSION */
+ u32 jr; /* JR_VERSION */
+ u32 deco; /* DECO_VERSION */
+};
+
+#define CHA_VER_NUM_MASK 0x00ff
+#define CHA_VER_MISC_SHIFT 8
+#define CHA_VER_MISC_MASK 0xff00
+#define CHA_VER_REV_SHIFT 16
+#define CHA_VER_REV_MASK 0x00ff
+#define CHA_VER_VID_SHIFT 24
+#define CHA_VER_VID_MASK 0xff00
+
typedef struct ccsr_sec {
u32 res0;
u32 mcfgr; /* Master CFG Register */
@@ -98,17 +133,19 @@ typedef struct ccsr_sec {
u32 drr;/* DECO Reset Register */
u8 res5[0x4d8];
struct rng4tst rng; /* RNG Registers */
- u8 res6[0x8a0];
+ u8 res6[0x780];
+ struct version_regs vreg; /* version registers since era 10 */
+ u8 res7[0xa0];
u32 crnr_ms;/* CHA Revision Number Register, MS */
u32 crnr_ls;/* CHA Revision Number Register, LS */
u32 ctpr_ms;/* Compile Time Parameters Register, MS */
u32 ctpr_ls;/* Compile Time Parameters Register, LS */
- u8 res7[0x10];
+ u8 res8[0x10];
u32 far_ms; /* Fault Address Register, MS */
u32 far_ls; /* Fault Address Register, LS */
u32 falr; /* Fault Address LIODN Register */
u32 fadr; /* Fault Address Detail Register */
- u8 res8[0x4];
+ u8 res9[0x4];
u32 csta; /* CAAM Status Register */
u32 smpart; /* Secure Memory Partition Parameters */
u32 smvid; /* Secure Memory Version ID */
@@ -121,16 +158,16 @@ typedef struct ccsr_sec {
u32 secvid_ms; /* SEC Version ID Register, MS */
u32 secvid_ls; /* SEC Version ID Register, LS */
#if defined(CONFIG_FSL_LSCH2) || defined(CONFIG_FSL_LSCH3)
- u8 res9[0x6f020];
+ u8 res10[0x6f020];
#else
- u8 res9[0x6020];
+ u8 res10[0x6020];
#endif
u32 qilcr_ms; /* Queue Interface LIODN CFG Register, MS */
u32 qilcr_ls; /* Queue Interface LIODN CFG Register, LS */
#if defined(CONFIG_FSL_LSCH2) || defined(CONFIG_FSL_LSCH3)
- u8 res10[0x8ffd8];
+ u8 res11[0x8ffd8];
#else
- u8 res10[0x8fd8];
+ u8 res11[0x8fd8];
#endif
} ccsr_sec_t;
--
2.20.1
[PATCH v4 5/6] crypto/fsl: instantiate the RNG with prediciton resistance
If it is already instantiated tear it down first and then reinstanciate
it again with prediction resistance.
Signed-off-by: Michael Walle
---
drivers/crypto/fsl/desc.h| 2 ++
drivers/crypto/fsl/jobdesc.c | 12 ++-
drivers/crypto/fsl/jobdesc.h | 2 ++
drivers/crypto/fsl/jr.c | 67
include/fsl_sec.h| 7 ++--
5 files changed, 79 insertions(+), 11 deletions(-)
diff --git a/drivers/crypto/fsl/desc.h b/drivers/crypto/fsl/desc.h
index 11ad506829..3589e6ea02 100644
--- a/drivers/crypto/fsl/desc.h
+++ b/drivers/crypto/fsl/desc.h
@@ -520,6 +520,8 @@
#define OP_ALG_ICV_OFF (0 << OP_ALG_ICV_SHIFT)
#define OP_ALG_ICV_ON (1 << OP_ALG_ICV_SHIFT)
+#define OP_ALG_PR_ON 0x02
+
#define OP_ALG_DIR_SHIFT 0
#define OP_ALG_DIR_MASK1
#define OP_ALG_DECRYPT 0
diff --git a/drivers/crypto/fsl/jobdesc.c b/drivers/crypto/fsl/jobdesc.c
index 6102e9c06b..d9554c550b 100644
--- a/drivers/crypto/fsl/jobdesc.c
+++ b/drivers/crypto/fsl/jobdesc.c
@@ -266,7 +266,8 @@ void inline_cnstr_jobdesc_rng_instantiation(u32 *desc, int
handle, int do_sk)
/* INIT RNG in non-test mode */
append_operation(desc, OP_TYPE_CLASS1_ALG | OP_ALG_ALGSEL_RNG |
- (handle << OP_ALG_AAI_SHIFT) | OP_ALG_AS_INIT);
+(handle << OP_ALG_AAI_SHIFT) | OP_ALG_AS_INIT |
+OP_ALG_PR_ON);
/* For SH0, Secure Keys must be generated as well */
if (!handle && do_sk) {
@@ -286,6 +287,15 @@ void inline_cnstr_jobdesc_rng_instantiation(u32 *desc, int
handle, int do_sk)
}
}
+/* Descriptor for deinstantiation of the RNG block. */
+void inline_cnstr_jobdesc_rng_deinstantiation(u32 *desc, int handle)
+{
+ init_job_desc(desc, 0);
+
+ append_operation(desc, OP_TYPE_CLASS1_ALG | OP_ALG_ALGSEL_RNG |
+(handle << OP_ALG_AAI_SHIFT) | OP_ALG_AS_INITFINAL);
+}
+
/* Change key size to bytes form bits in calling function*/
void inline_cnstr_jobdesc_pkha_rsaexp(uint32_t *desc,
struct pk_in_params *pkin, uint8_t *out,
diff --git a/drivers/crypto/fsl/jobdesc.h b/drivers/crypto/fsl/jobdesc.h
index 14b2a119d7..5185ddd535 100644
--- a/drivers/crypto/fsl/jobdesc.h
+++ b/drivers/crypto/fsl/jobdesc.h
@@ -41,6 +41,8 @@ void inline_cnstr_jobdesc_blob_decap(uint32_t *desc, uint8_t
*key_idnfr,
void inline_cnstr_jobdesc_rng_instantiation(u32 *desc, int handle, int do_sk);
+void inline_cnstr_jobdesc_rng_deinstantiation(u32 *desc, int handle);
+
void inline_cnstr_jobdesc_pkha_rsaexp(uint32_t *desc,
struct pk_in_params *pkin, uint8_t *out,
uint32_t out_siz);
diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index 42865a6cd7..c5802f7d51 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include
#include
#include "fsl_sec.h"
@@ -446,6 +447,51 @@ int sec_reset(void)
return sec_reset_idx(0);
}
#ifndef CONFIG_SPL_BUILD
+static int deinstantiate_rng(u8 sec_idx, int state_handle_mask)
+{
+ u32 *desc;
+ int sh_idx, ret = 0;
+ int desc_size = ALIGN(sizeof(u32) * 2, ARCH_DMA_MINALIGN);
+
+ desc = memalign(ARCH_DMA_MINALIGN, desc_size);
+ if (!desc) {
+ debug("cannot allocate RNG init descriptor memory\n");
+ return -ENOMEM;
+ }
+
+ for (sh_idx = 0; sh_idx < RNG4_MAX_HANDLES; sh_idx++) {
+ /*
+* If the corresponding bit is set, then it means the state
+* handle was initialized by us, and thus it needs to be
+* deinitialized as well
+*/
+
+ if (state_handle_mask & RDSTA_IF(sh_idx)) {
+ /*
+* Create the descriptor for deinstantating this state
+* handle.
+*/
+ inline_cnstr_jobdesc_rng_deinstantiation(desc, sh_idx);
+ flush_dcache_range((unsigned long)desc,
+ (unsigned long)desc + desc_size);
+
+ ret = run_descriptor_jr_idx(desc, sec_idx);
+ if (ret) {
+ printf("SEC%u: RNG4 SH%d deinstantiation
failed with error 0x%x\n",
+ sec_idx, sh_idx, ret);
+ ret = -EIO;
+ break;
+ }
+
+ printf("SEC%u: Deinstantiated RNG4 SH%d\n",
+ sec_idx, sh_idx);
+ }
+ }
+
+ free(desc);
+ return ret;
+}
+
static int instantiate_rng(u8 sec_idx, int gen_sk)
{
u32 *desc;
@@ -466,9 +512,18 @@ static int instantiate_rng(u8 sec_idx, int gen_sk)
[PATCH v4 4/6] crypto/fsl: don't regenerate secure keys
The secure keys (TDKEK, JDKEK, TDSK) can only be generated once after a
POR. Otherwise the RNG4 will throw an error.
Signed-off-by: Michael Walle
Reviewed-by: Horia Geantă
---
drivers/crypto/fsl/jobdesc.c | 4 ++--
drivers/crypto/fsl/jobdesc.h | 2 +-
drivers/crypto/fsl/jr.c | 9 +
include/fsl_sec.h| 1 +
4 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/fsl/jobdesc.c b/drivers/crypto/fsl/jobdesc.c
index 2f35e0c90b..6102e9c06b 100644
--- a/drivers/crypto/fsl/jobdesc.c
+++ b/drivers/crypto/fsl/jobdesc.c
@@ -258,7 +258,7 @@ void inline_cnstr_jobdesc_blob_decap(uint32_t *desc,
uint8_t *key_idnfr,
* Descriptor to instantiate RNG State Handle 0 in normal mode and
* load the JDKEK, TDKEK and TDSK registers
*/
-void inline_cnstr_jobdesc_rng_instantiation(uint32_t *desc, int handle)
+void inline_cnstr_jobdesc_rng_instantiation(u32 *desc, int handle, int do_sk)
{
u32 *jump_cmd;
@@ -269,7 +269,7 @@ void inline_cnstr_jobdesc_rng_instantiation(uint32_t *desc,
int handle)
(handle << OP_ALG_AAI_SHIFT) | OP_ALG_AS_INIT);
/* For SH0, Secure Keys must be generated as well */
- if (handle == 0) {
+ if (!handle && do_sk) {
/* wait for done */
jump_cmd = append_jump(desc, JUMP_CLASS_CLASS1);
set_jump_tgt_here(desc, jump_cmd);
diff --git a/drivers/crypto/fsl/jobdesc.h b/drivers/crypto/fsl/jobdesc.h
index d782c46b9d..14b2a119d7 100644
--- a/drivers/crypto/fsl/jobdesc.h
+++ b/drivers/crypto/fsl/jobdesc.h
@@ -39,7 +39,7 @@ void inline_cnstr_jobdesc_blob_decap(uint32_t *desc, uint8_t
*key_idnfr,
uint8_t *enc_blob, uint8_t *plain_txt,
uint32_t out_sz);
-void inline_cnstr_jobdesc_rng_instantiation(uint32_t *desc, int handle);
+void inline_cnstr_jobdesc_rng_instantiation(u32 *desc, int handle, int do_sk);
void inline_cnstr_jobdesc_pkha_rsaexp(uint32_t *desc,
struct pk_in_params *pkin, uint8_t *out,
diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index 5275c50e8b..42865a6cd7 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -446,7 +446,7 @@ int sec_reset(void)
return sec_reset_idx(0);
}
#ifndef CONFIG_SPL_BUILD
-static int instantiate_rng(uint8_t sec_idx)
+static int instantiate_rng(u8 sec_idx, int gen_sk)
{
u32 *desc;
u32 rdsta_val;
@@ -470,7 +470,7 @@ static int instantiate_rng(uint8_t sec_idx)
if (rdsta_val & (1 << sh_idx))
continue;
- inline_cnstr_jobdesc_rng_instantiation(desc, sh_idx);
+ inline_cnstr_jobdesc_rng_instantiation(desc, sh_idx, gen_sk);
size = roundup(sizeof(uint32_t) * 6, ARCH_DMA_MINALIGN);
flush_dcache_range((unsigned long)desc,
(unsigned long)desc + size);
@@ -546,12 +546,13 @@ static void kick_trng(int ent_delay, uint8_t sec_idx)
static int rng_init(uint8_t sec_idx)
{
- int ret, ent_delay = RTSDCTL_ENT_DLY_MIN;
+ int ret, gen_sk, ent_delay = RTSDCTL_ENT_DLY_MIN;
ccsr_sec_t __iomem *sec = (ccsr_sec_t __iomem *)SEC_ADDR(sec_idx);
struct rng4tst __iomem *rng =
(struct rng4tst __iomem *)&sec->rng;
u32 inst_handles;
+ gen_sk = !(sec_in32(&rng->rdsta) & RDSTA_SKVN);
do {
inst_handles = sec_in32(&rng->rdsta) & RNG_STATE_HANDLE_MASK;
@@ -574,7 +575,7 @@ static int rng_init(uint8_t sec_idx)
* interval, leading to a sucessful initialization of
* the RNG.
*/
- ret = instantiate_rng(sec_idx);
+ ret = instantiate_rng(sec_idx, gen_sk);
} while ((ret == -1) && (ent_delay < RTSDCTL_ENT_DLY_MAX));
if (ret) {
printf("SEC%u: Failed to instantiate RNG\n", sec_idx);
diff --git a/include/fsl_sec.h b/include/fsl_sec.h
index 8dce0bbb1b..64b8751f2d 100644
--- a/include/fsl_sec.h
+++ b/include/fsl_sec.h
@@ -69,6 +69,7 @@ struct rng4tst {
#define RNG_STATE1_HANDLE_INSTANTIATED 0x0002
#define RNG_STATE_HANDLE_MASK \
(RNG_STATE0_HANDLE_INSTANTIATED | RNG_STATE1_HANDLE_INSTANTIATED)
+#define RDSTA_SKVN 0x4000
u32 rdsta; /*RNG DRNG Status Register*/
u32 rsvd2[15];
};
--
2.20.1
[PATCH v4 6/6] crypto/fsl: add RNG support
Register the random number generator with the rng subsystem in u-boot.
This way it can be used by EFI as well as for the 'rng' command.
Signed-off-by: Michael Walle
---
drivers/crypto/fsl/Kconfig | 14 ++
drivers/crypto/fsl/Makefile | 1 +
drivers/crypto/fsl/jobdesc.c | 10
drivers/crypto/fsl/jobdesc.h | 3 ++
drivers/crypto/fsl/jr.c | 9
drivers/crypto/fsl/rng.c | 88
6 files changed, 125 insertions(+)
create mode 100644 drivers/crypto/fsl/rng.c
diff --git a/drivers/crypto/fsl/Kconfig b/drivers/crypto/fsl/Kconfig
index 181a1e5e99..5ed6140da3 100644
--- a/drivers/crypto/fsl/Kconfig
+++ b/drivers/crypto/fsl/Kconfig
@@ -45,3 +45,17 @@ config SYS_FSL_SEC_COMPAT
config SYS_FSL_SEC_LE
bool "Little-endian access to Freescale Secure Boot"
+
+if FSL_CAAM
+
+config FSL_CAAM_RNG
+ bool "Enable Random Number Generator support"
+ depends on DM_RNG
+ default y
+ help
+ Enable support for the hardware based random number generator
+ module of the CAAM. The random data is fetched from the DRGB
+ using the prediction resistance flag which means the DRGB is
+ reseeded from the TRNG every time random data is generated.
+
+endif
diff --git a/drivers/crypto/fsl/Makefile b/drivers/crypto/fsl/Makefile
index cfb36f3bb9..a5e8d38e38 100644
--- a/drivers/crypto/fsl/Makefile
+++ b/drivers/crypto/fsl/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o
obj-$(CONFIG_CMD_BLOB) += fsl_blob.o
obj-$(CONFIG_CMD_DEKBLOB) += fsl_blob.o
obj-$(CONFIG_RSA_FREESCALE_EXP) += fsl_rsa.o
+obj-$(CONFIG_FSL_CAAM_RNG) += rng.o
diff --git a/drivers/crypto/fsl/jobdesc.c b/drivers/crypto/fsl/jobdesc.c
index d9554c550b..decde64078 100644
--- a/drivers/crypto/fsl/jobdesc.c
+++ b/drivers/crypto/fsl/jobdesc.c
@@ -296,6 +296,16 @@ void inline_cnstr_jobdesc_rng_deinstantiation(u32 *desc,
int handle)
(handle << OP_ALG_AAI_SHIFT) | OP_ALG_AS_INITFINAL);
}
+void inline_cnstr_jobdesc_rng(u32 *desc, void *data_out, u32 size)
+{
+ dma_addr_t dma_data_out = virt_to_phys(data_out);
+
+ init_job_desc(desc, 0);
+ append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG |
+OP_ALG_PR_ON);
+ append_fifo_store(desc, dma_data_out, size, FIFOST_TYPE_RNGSTORE);
+}
+
/* Change key size to bytes form bits in calling function*/
void inline_cnstr_jobdesc_pkha_rsaexp(uint32_t *desc,
struct pk_in_params *pkin, uint8_t *out,
diff --git a/drivers/crypto/fsl/jobdesc.h b/drivers/crypto/fsl/jobdesc.h
index 5185ddd535..c4501abd26 100644
--- a/drivers/crypto/fsl/jobdesc.h
+++ b/drivers/crypto/fsl/jobdesc.h
@@ -43,7 +43,10 @@ void inline_cnstr_jobdesc_rng_instantiation(u32 *desc, int
handle, int do_sk);
void inline_cnstr_jobdesc_rng_deinstantiation(u32 *desc, int handle);
+void inline_cnstr_jobdesc_rng(u32 *desc, void *data_out, u32 size);
+
void inline_cnstr_jobdesc_pkha_rsaexp(uint32_t *desc,
struct pk_in_params *pkin, uint8_t *out,
uint32_t out_siz);
+
#endif
diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index c5802f7d51..44273c345f 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -20,6 +20,7 @@
#include
#include
#endif
+#include
#define CIRC_CNT(head, tail, size) (((head) - (tail)) & (size - 1))
#define CIRC_SPACE(head, tail, size) CIRC_CNT((tail), (head) + 1, (size))
@@ -721,6 +722,14 @@ int sec_init_idx(uint8_t sec_idx)
printf("SEC%u: RNG instantiation failed\n", sec_idx);
return -1;
}
+
+ if (IS_ENABLED(CONFIG_DM_RNG)) {
+ ret = device_bind_driver(NULL, "caam-rng", "caam-rng",
+NULL);
+ if (ret)
+ printf("Couldn't bind rng driver (%d)\n", ret);
+ }
+
printf("SEC%u: RNG instantiated\n", sec_idx);
}
#endif
diff --git a/drivers/crypto/fsl/rng.c b/drivers/crypto/fsl/rng.c
new file mode 100644
index 00..3c0c2b067f
--- /dev/null
+++ b/drivers/crypto/fsl/rng.c
@@ -0,0 +1,88 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2020 Michael Walle
+ *
+ * Driver for Freescale Cryptographic Accelerator and Assurance
+ * Module (CAAM) hardware random number generator.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "desc_constr.h"
+#include "jobdesc.h"
+#include "jr.h"
+
+#define CAAM_RNG_MAX_FIFO_STORE_SIZE 16
+#define CAAM_RNG_DESC_LEN (3 * CAAM_CMD_SZ + CAAM_PTR_SZ)
+
+struct caam_rng_priv {
+ u32 desc[CAAM_RNG_DESC_LEN / 4];
+ u8 data[CAAM_RNG_MAX_FIFO_STORE_SIZE] __aligned(ARCH_DMA_MINALIGN);
+};
+
+static int caam_rng_read_one(struct caam_rng_priv *priv)
+{
[PATCH v4 0/6] crypto/fsl: add RNG support
First, improve the compatibility on newer Era CAAMs. These introduced new version registers. Secondly, add RNG support for the CAAM. This way we get random number generator support for EFI for free and KASLR will work with ARM64 kernels booted with bootefi. Changes since v3: - use private data instead of platform data in RNG driver, thanks Heinrich - align end address of any invalidate/flush_dcache_range(), thanks Heinrich - because we do the alignment ourself, use memalign() again (instead of malloc_cache_aligned()) Changes since v2: - fix descriptor size of the deinstantiate descriptor - use malloc_cache_aligned() instead of memalign(ARCH_DMA_MINALIGN..) - don't check the RDSTA_PR() bit - fix memcpy() length - flush the dcache where the rng job description resides Changes since v1: - instantiate RNG with prediction resistance - add annotation for caam_get_era() - fix all prints to match u-boots status lines - remove superfluous #ifdef CONFIG_DM_RNG - changed kconfig help text Michael Walle (6): crypto/fsl: make SEC%u status line consistent crypto/fsl: export caam_get_era() crypto/fsl: support newer SEC modules crypto/fsl: don't regenerate secure keys crypto/fsl: instantiate the RNG with prediciton resistance crypto/fsl: add RNG support drivers/crypto/fsl/Kconfig | 14 + drivers/crypto/fsl/Makefile | 1 + drivers/crypto/fsl/desc.h| 2 + drivers/crypto/fsl/jobdesc.c | 26 +++- drivers/crypto/fsl/jobdesc.h | 7 ++- drivers/crypto/fsl/jr.c | 111 +-- drivers/crypto/fsl/rng.c | 88 +++ drivers/crypto/fsl/sec.c | 10 +++- include/fsl_sec.h| 61 +++ 9 files changed, 285 insertions(+), 35 deletions(-) create mode 100644 drivers/crypto/fsl/rng.c -- 2.20.1
Re: [PATCH v4 6/6] crypto/fsl: add RNG support
On 6/27/20 10:58 PM, Michael Walle wrote: > Register the random number generator with the rng subsystem in u-boot. > This way it can be used by EFI as well as for the 'rng' command. > > Signed-off-by: Michael Walle Tested on a i.MX6 Wandward Quad with additional patch ARM: mx6: make CAAM usable on the i.MX6 boards https://lists.denx.de/pipermail/u-boot/2020-June/417716.html * The rng command produces random output. * No cache alignment warning are shown. * The UEFI random number selftest shows not problem. * Linux announces: "efi: seeding entropy pool". Tested-by: Heinrich Schuchardt
[PATCH v2] video: bmp: support 8bits BMP drawing on 24/32 bpp framebuffer
From: Ye Li
Update video bmp code so that we can display 8 bits logo on
24 or 32 bpp framebuffer.
Signed-off-by: Ye Li
Signed-off-by: Anatolij Gustschin
Reviewed-by: Jagan Teki
Tested-by: Jagan Teki # bpi-m1+, bpi-m64
---
Changes in v2:
- reduce code
- update commit message
drivers/video/video_bmp.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/video/video_bmp.c b/drivers/video/video_bmp.c
index eb9636541d..7d7f37b445 100644
--- a/drivers/video/video_bmp.c
+++ b/drivers/video/video_bmp.c
@@ -233,6 +233,8 @@ int video_bmp_display(struct udevice *dev, ulong bmp_image,
int x, int y,
*/
if (bpix != bmp_bpix &&
!(bmp_bpix == 8 && bpix == 16) &&
+ !(bmp_bpix == 8 && bpix == 24) &&
+ !(bmp_bpix == 8 && bpix == 32) &&
!(bmp_bpix == 24 && bpix == 16) &&
!(bmp_bpix == 24 && bpix == 32)) {
printf("Error: %d bit/pixel mode, but BMP has %d bit/pixel\n",
@@ -265,6 +267,7 @@ int video_bmp_display(struct udevice *dev, ulong bmp_image,
int x, int y,
switch (bmp_bpix) {
case 1:
case 8: {
+ struct bmp_color_table_entry *cte;
cmap_base = priv->cmap;
#ifdef CONFIG_VIDEO_BMP_RLE8
u32 compression = get_unaligned_le32(&bmp->header.compression);
@@ -280,21 +283,33 @@ int video_bmp_display(struct udevice *dev, ulong
bmp_image, int x, int y,
break;
}
#endif
-
- if (bpix != 16)
+ byte_width = width * (bpix / 8);
+ if (!byte_width)
byte_width = width;
- else
- byte_width = width * 2;
for (i = 0; i < height; ++i) {
WATCHDOG_RESET();
for (j = 0; j < width; j++) {
- if (bpix != 16) {
+ if (bpix == 8) {
fb_put_byte(&fb, &bmap);
- } else {
+ } else if (bpix == 16) {
*(uint16_t *)fb = cmap_base[*bmap];
bmap++;
fb += sizeof(uint16_t) / sizeof(*fb);
+ } else {
+ /* Only support big endian */
+ cte = &palette[*bmap];
+ bmap++;
+ if (bpix == 24) {
+ *(fb++) = cte->red;
+ *(fb++) = cte->green;
+ *(fb++) = cte->blue;
+ } else {
+ *(fb++) = cte->blue;
+ *(fb++) = cte->green;
+ *(fb++) = cte->red;
+ *(fb++) = 0;
+ }
}
}
bmap += (padded_width - width);
--
2.17.1
Re: [PATCH] test/py: test_efi_fit: Update #size-cells to 1
Hi Heinrich,
On Sat, Jun 27, 2020 at 9:43 PM Heinrich Schuchardt wrote:
>
> On 6/27/20 2:12 PM, Bin Meng wrote:
> > From: Bin Meng
> >
> > test_efi_fit tests fail on RISC-V currently. This is due to the
> > RISC-V arch_fixup_fdt() checks the #size-cells of the root node
> > in order to correctly fix up the reserved memory node.
> >
> > Update #size-cells to 1 so tests can pass.
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > test/py/tests/test_efi_fit.py | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/test/py/tests/test_efi_fit.py b/test/py/tests/test_efi_fit.py
> > index beaf4a3..3616e99 100644
> > --- a/test/py/tests/test_efi_fit.py
> > +++ b/test/py/tests/test_efi_fit.py
> > @@ -106,7 +106,7 @@ FDT_DATA = '''
> >
> > / {
> > #address-cells = <1>;
> > -#size-cells = <0>;
> > +#size-cells = <1>;
>
> As you describe above the test failed for RISC-V because the #size-cells
> property is incorrect for the /reserved-memory node.
>
> Changing the #size-cells property here does not solve the underlying
> problem that the code inserting a /reserved-memory node has a bug. That
> code should insert properties #address-cells and #size-cells as needed
> into the /reserved-memory node itself.
Per the DT binding, the /reserved-memory node requires #address-cells,
#size-cells and they should use the same values as the root node.
So the fix is to modify the root node to add a size-cell. Besides, I
don't think a root node without a size-cell is useful.
>
> Have you been able to figure out where the /reserved-memory node is created?
>
> In the resulting device tree check that #size-cells remains <0> for the
> /reset@0 node.
I will fix this in v2.
Regards,
Bin
[PATCH v2] test/py: test_efi_fit: Update #size-cells to 1
From: Bin Meng
test_efi_fit tests fail on RISC-V currently. This is due to the
RISC-V arch_fixup_fdt() checks the #size-cells of the root node
in order to correctly fix up the reserved memory node.
Per the DT binding, the /reserved-memory node requires both
<#address-cells> and <#size-cells> and they should use the same
values as the root node. For the root node, it's not very useful
if <#size-cells> is zero.
Update #size-cells to 1 so tests can pass.
Signed-off-by: Bin Meng
---
Changes in v2:
- Update the reset node's property to contain a size
test/py/tests/test_efi_fit.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/test/py/tests/test_efi_fit.py b/test/py/tests/test_efi_fit.py
index beaf4a3..06fb151 100644
--- a/test/py/tests/test_efi_fit.py
+++ b/test/py/tests/test_efi_fit.py
@@ -106,14 +106,14 @@ FDT_DATA = '''
/ {
#address-cells = <1>;
-#size-cells = <0>;
+#size-cells = <1>;
model = "%(sys-arch)s %(fdt_type)s EFI FIT Boot Test";
compatible = "%(sys-arch)s";
reset@0 {
compatible = "%(sys-arch)s,reset";
-reg = <0>;
+reg = <0 4>;
};
};
'''
--
2.7.4
Re: rockchip: correctly set vop0 or vop1
On 2020/6/8 上午2:36, Patrick Wildt wrote: The EDP_LCDC_SEL bit has to be set correctly to select vop0 or vop1, but so far we have set it in both conditions, which is not correct. Can someone verify this is the correct way round? vop1 -> set, vop0 -> clear? Signed-off-by: Patrick Wildt I will take this fix for rk3288 and later you can send support for rk3399. Reviewed-by: Kever Yang Thanks, - Kever diff --git a/drivers/video/rockchip/rk_edp.c b/drivers/video/rockchip/rk_edp.c index 92188be9275..000bd481408 100644 --- a/drivers/video/rockchip/rk_edp.c +++ b/drivers/video/rockchip/rk_edp.c @@ -1062,7 +1062,8 @@ static int rk_edp_probe(struct udevice *dev) rk_setreg(&priv->grf->soc_con12, 1 << 4); /* select epd signal from vop0 or vop1 */ - rk_setreg(&priv->grf->soc_con6, (vop_id == 1) ? (1 << 5) : (1 << 5)); + rk_clrsetreg(&priv->grf->soc_con6, (1 << 5), + (vop_id == 1) ? (1 << 5) : (0 << 5)); rockchip_edp_wait_hpd(priv);
Re: rockchip: correctly set vop0 or vop1
Hi :
On 6/27/20 8:56 PM, Kever Yang wrote:
+Andy Yan for this topic,
Hi Patrick and Arnaud,
I would like to leave this patch until the code fits for all the
socs,
Thanks,
- Kever
On 2020/6/8 下午8:39, Patrick Wildt wrote:
On Mon, Jun 08, 2020 at 02:24:32PM +0200, Arnaud Patard wrote:
Patrick Wildt writes:
On Mon, Jun 08, 2020 at 10:18:19AM +0200, Arnaud Patard wrote:
Patrick Wildt writes:
Hi,
The EDP_LCDC_SEL bit has to be set correctly to select vop0 or
vop1, but so far we have set it in both conditions, which is not
correct.
Can someone verify this is the correct way round? vop1 -> set,
vop0 -> clear?
Signed-off-by: Patrick Wildt
diff --git a/drivers/video/rockchip/rk_edp.c
b/drivers/video/rockchip/rk_edp.c
index 92188be9275..000bd481408 100644
--- a/drivers/video/rockchip/rk_edp.c
+++ b/drivers/video/rockchip/rk_edp.c
@@ -1062,7 +1062,8 @@ static int rk_edp_probe(struct udevice *dev)
rk_setreg(&priv->grf->soc_con12, 1 << 4);
/* select epd signal from vop0 or vop1 */
- rk_setreg(&priv->grf->soc_con6, (vop_id == 1) ? (1 << 5) :
(1 << 5));
+ rk_clrsetreg(&priv->grf->soc_con6, (1 << 5),
+ (vop_id == 1) ? (1 << 5) : (0 << 5));
While working on PBP EDP support, found this too but I'm not sure
it's
fine or not. For rk3399, my (not yet published) patch is doing:
+ if (vop_id == 0)
+ rk_clrreg(&priv->grf->soc_con20, (1 << 5));
+ else
+ rk_setreg(&priv->grf->soc_con20, (1 << 5));
I believe that the rk3288 may need similar treatment but I've yet to
look at the rk3288 manual.
Arnaud
Yes, it does. If you look at the linux code, they have:
static const struct rockchip_dp_chip_data rk3399_edp = {
.lcdsel_grf_reg = RK3399_GRF_SOC_CON20,
.lcdsel_big = HIWORD_UPDATE(0, RK3399_EDP_LCDC_SEL),
.lcdsel_lit = HIWORD_UPDATE(RK3399_EDP_LCDC_SEL,
RK3399_EDP_LCDC_SEL),
.chip_type = RK3399_EDP,
};
static const struct rockchip_dp_chip_data rk3288_dp = {
.lcdsel_grf_reg = RK3288_GRF_SOC_CON6,
.lcdsel_big = HIWORD_UPDATE(0, RK3288_EDP_LCDC_SEL),
.lcdsel_lit = HIWORD_UPDATE(RK3288_EDP_LCDC_SEL,
RK3288_EDP_LCDC_SEL),
.chip_type = RK3288_DP,
};
It's true that different soc have different grf register for selecting
lcdc/vop, and so it is for other modules such as rockchip_gmac/pinctrl.
The above code in linux kernel is a example for how we handle this case.
which indicates that for rk3399 *and* rk3288 the bit has to be set to
select "lit". Now your diff looks equivalent to mine, apart from
using
a different operation to achieve the same goal.
The linux code does
ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node,
encoder);
if (ret < 0)
return;
if (ret)
val = dp->data->lcdsel_lit;
else
val = dp->data->lcdsel_big;
Assuming that endpoint_id essentiall returns vop id 0 or vop id 1,
this
would mean that vop1 -> lit -> set bit and vop0 -> big -> clr bit.
That said, my diff seems to be fine, and your RK3399 code as well. Do
you agree?
According to the code you've shown, it should be fine for rk3288 I
guess
but not for rk3399. Please note that it's grf soc_con6 register for
rk3288
but grf soc_con20 for rk3399.
Arnaud
Exactly, which is why you had that if defined() in your diff, to compile
one part of the code for RK3288, and the other for RK3399. :) The bit
though happens to be the same.
Re: [PATCH v4 4/5] rockchip: Separate the reset cause from display cpuinfo
HI Jagan,
On 2020/6/18 下午11:39, Jagan Teki wrote:
reset cause is a generic functionality based on the soc
cru registers in rockchip. This can be used for printing
the cause of reset in cpuinfo or some other place where
reset cause is needed.
Other than cpuinfo, reset cause can also be using during
bootcount for checking the specific reset cause and glow
the led based on the reset cause.
So, let's separate the reset cause code from cpuinfo, and
add a check to build it for rk3399, rk3288 since these two
soc are supporting reset cause as of now.
Signed-off-by: Jagan Teki
Tested-by: Suniel Mahesh
---
Changes for v4:
- none
arch/arm/include/asm/arch-rockchip/cru.h | 2 ++
arch/arm/mach-rockchip/Makefile | 5 -
arch/arm/mach-rockchip/cpu-info.c| 20
3 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/arch/arm/include/asm/arch-rockchip/cru.h
b/arch/arm/include/asm/arch-rockchip/cru.h
index 5eb17f9d55..317eb61049 100644
--- a/arch/arm/include/asm/arch-rockchip/cru.h
+++ b/arch/arm/include/asm/arch-rockchip/cru.h
@@ -31,4 +31,6 @@ enum {
#define MHz 100
+char *get_reset_cause(void);
Since you add a environment, you should use that instead of export
get_reset_cause().
+
#endif /* _ROCKCHIP_CLOCK_H */
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 5b38526fe0..ef4898e00c 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -15,6 +15,10 @@ obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
+ifeq ($(CONFIG_ROCKCHIP_RK3288)$(CONFIG_ROCKCHIP_RK3399), y)
+obj-y += cpu-info.o
+endif
This change is not need, if the soc does not support this feature, they
should not enable
CONFIG_DISPLAY_CPUINFO.
Thanks,
- Kever
+
ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
# Always include boot_mode.o, as we bypass it (i.e. turn it off)
@@ -22,7 +26,6 @@ ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
# we can have the preprocessor correctly recognise both 0x0 and 0
# meaning "turn it off".
obj-y += boot_mode.o
-obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
obj-$(CONFIG_MISC_INIT_R) += misc.o
endif
diff --git a/arch/arm/mach-rockchip/cpu-info.c
b/arch/arm/mach-rockchip/cpu-info.c
index 21ca9dedce..76a840e2c3 100644
--- a/arch/arm/mach-rockchip/cpu-info.c
+++ b/arch/arm/mach-rockchip/cpu-info.c
@@ -13,7 +13,7 @@
#include
#include
-static char *get_reset_cause(void)
+char *get_reset_cause(void)
{
struct rockchip_cru *cru = rockchip_get_cru();
char *cause = NULL;
@@ -41,12 +41,6 @@ static char *get_reset_cause(void)
cause = "unknown reset";
}
- /**
-* reset_reason env is used by rk3288, due to special use case
-* to figure it the boot behavior. so keep this as it is.
-*/
- env_set("reset_reason", cause);
-
/*
* Clear glb_rst_st, so we can determine the last reset cause
* for following resets.
@@ -56,12 +50,22 @@ static char *get_reset_cause(void)
return cause;
}
+#ifdef CONFIG_DISPLAY_CPUINFO
int print_cpuinfo(void)
{
+ char *cause = get_reset_cause();
+
printf("SoC: Rockchip %s\n", CONFIG_SYS_SOC);
- printf("Reset cause: %s\n", get_reset_cause());
+ printf("Reset cause: %s\n", cause);
+
+ /**
+* reset_reason env is used by rk3288, due to special use case
+* to figure it the boot behavior. so keep this as it is.
+*/
+ env_set("reset_reason", cause);
/* TODO print operating temparature and clock */
return 0;
}
+#endif
Re: [PATCH v4 3/5] roc-rk3399-pc: Move leds setup in SPL
On 2020/6/18 下午11:39, Jagan Teki wrote:
roc-rk3399-pc has some specific requirements to support LEDS,
environment. board detection and etc prior to U-Boot proper.
So as of now SPL would be a better stage for these custom board
requirements to support unlike TPL. Adding few of these custom
requirements like LEDS in TPL would require extra code pulling
and also the size of TPL can grow.
So, this patch moves the leds code from TPL into SPL after relocation.
Signed-off-by: Jagan Teki
Tested-by: Suniel Mahesh
---
Changes for v4:
- none
arch/arm/mach-rockchip/tpl.c| 7 ---
board/firefly/roc-pc-rk3399/Makefile| 4
board/firefly/roc-pc-rk3399/roc-pc-rk3399.c | 21 ---
board/firefly/roc-pc-rk3399/spl.c | 23 +
configs/roc-pc-mezzanine-rk3399_defconfig | 2 +-
configs/roc-pc-rk3399_defconfig | 2 +-
6 files changed, 29 insertions(+), 30 deletions(-)
create mode 100644 board/firefly/roc-pc-rk3399/spl.c
diff --git a/arch/arm/mach-rockchip/tpl.c b/arch/arm/mach-rockchip/tpl.c
index 88f80b05a9..cc908e1b0e 100644
--- a/arch/arm/mach-rockchip/tpl.c
+++ b/arch/arm/mach-rockchip/tpl.c
@@ -43,18 +43,11 @@ __weak void rockchip_stimer_init(void)
TIMER_CONTROL_REG);
}
-__weak int board_early_init_f(void)
-{
- return 0;
-}
-
void board_init_f(ulong dummy)
{
struct udevice *dev;
int ret;
- board_early_init_f();
-
#if defined(CONFIG_DEBUG_UART) && defined(CONFIG_TPL_SERIAL_SUPPORT)
/*
* Debug UART can be used from here if required:
diff --git a/board/firefly/roc-pc-rk3399/Makefile
b/board/firefly/roc-pc-rk3399/Makefile
index 29c79b25d7..3a9c4c744d 100644
--- a/board/firefly/roc-pc-rk3399/Makefile
+++ b/board/firefly/roc-pc-rk3399/Makefile
@@ -4,4 +4,8 @@
# SPDX-License-Identifier: GPL-2.0+
#
+ifdef CONFIG_SPL_BUILD
+obj-y += spl.o
+else
obj-y += roc-pc-rk3399.o
+endif
diff --git a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
index 7c3a803654..581cdcd3b0 100644
--- a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
+++ b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
@@ -6,13 +6,8 @@
#include
#include
#include
-#include
#include
-#include
-#include
-#include
It will be better to use CONFIG_SPL_BUILD for SPL code in this file
instead of
add a new file.
Many other boards will follow up to add this new file, I don't think
this is a good idea.
Thanks,
- Kever
-#ifndef CONFIG_SPL_BUILD
int board_early_init_f(void)
{
struct udevice *regulator;
@@ -30,19 +25,3 @@ int board_early_init_f(void)
out:
return 0;
}
-#endif
-
-#if defined(CONFIG_TPL_BUILD)
-
-#define GPIO0_BASE 0xff72
-
-int board_early_init_f(void)
-{
- struct rockchip_gpio_regs * const gpio0 = (void *)GPIO0_BASE;
-
- /* Turn on red LED, indicating full power mode */
- spl_gpio_output(gpio0, GPIO(BANK_B, 5), 1);
-
- return 0;
-}
-#endif
diff --git a/board/firefly/roc-pc-rk3399/spl.c
b/board/firefly/roc-pc-rk3399/spl.c
new file mode 100644
index 00..a7664c6b86
--- /dev/null
+++ b/board/firefly/roc-pc-rk3399/spl.c
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2020 Amarula Solutions(India)
+ */
+
+#include
+#include
+#include
+
+#define GPIO0_BASE 0xff72
+
+static void led_setup(void)
+{
+ struct rockchip_gpio_regs * const gpio0 = (void *)GPIO0_BASE;
+
+ /* Turn on red LED, indicating full power mode */
+ spl_gpio_output(gpio0, GPIO(BANK_B, 5), 1);
+}
+
+void rk_spl_board_init(void)
+{
+ led_setup();
+}
diff --git a/configs/roc-pc-mezzanine-rk3399_defconfig
b/configs/roc-pc-mezzanine-rk3399_defconfig
index 595f052cb7..060b4bfecf 100644
--- a/configs/roc-pc-mezzanine-rk3399_defconfig
+++ b/configs/roc-pc-mezzanine-rk3399_defconfig
@@ -1,6 +1,7 @@
CONFIG_ARM=y
CONFIG_ARCH_ROCKCHIP=y
CONFIG_SYS_TEXT_BASE=0x0020
+CONFIG_SPL_GPIO_SUPPORT=y
CONFIG_ENV_SIZE=0x8000
CONFIG_ENV_OFFSET=0x3F8000
CONFIG_ENV_SECT_SIZE=0x1000
@@ -20,7 +21,6 @@ CONFIG_SPL_STACK_R=y
CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
CONFIG_SPL_SPI_LOAD=y
CONFIG_TPL=y
-CONFIG_TPL_GPIO_SUPPORT=y
CONFIG_CMD_BOOTZ=y
CONFIG_CMD_GPT=y
CONFIG_CMD_MMC=y
diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig
index 1c4db3443f..9897a52cd8 100644
--- a/configs/roc-pc-rk3399_defconfig
+++ b/configs/roc-pc-rk3399_defconfig
@@ -1,6 +1,7 @@
CONFIG_ARM=y
CONFIG_ARCH_ROCKCHIP=y
CONFIG_SYS_TEXT_BASE=0x0020
+CONFIG_SPL_GPIO_SUPPORT=y
CONFIG_ENV_SIZE=0x8000
CONFIG_ENV_OFFSET=0x3F8000
CONFIG_ENV_SECT_SIZE=0x1000
@@ -20,7 +21,6 @@ CONFIG_SPL_STACK_R=y
CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
CONFIG_SPL_SPI_LOAD=y
CONFIG_TPL=y
-CONFIG_TPL_GPIO_SUPPORT=y
CONFIG_CMD_BOOTZ=y
CONFIG_CMD_GPT=y
CONFIG_CMD_MMC=y
Re: [PATCH v4 2/5] rk3399: spl: Print SPL banner after relocation
Hi Jagan,
On 2020/6/18 下午11:39, Jagan Teki wrote:
Usually printing the SPL banner varies between architecture
or board codes.
- Some would print before relocation at the end board_init_f
for making sure all initialization prior to this would happen
properly. if at all there is a requirement for serial init,
that happens properly since it prints all after that.
- Some would print after relocation at the spl_board_init for
making sure all initialization prior to relocation would
happen properly. Also debug uart on these cases would be
available before relocation. So debug support is available
in before and after relocation.
Rockchip SPL is following formar step to print the banner at
the end of board_init_f.
To support various custom use cases in SPL like leds, environment,
board detections later options like printing the banner after
relocation would be a better option.
I don't agree, the banner is tell people we are in SPL now, we should
print it as soon as
possible, if any of step like led, env, relocate and etc fails, then
user can not see anything,
they don't event know if we have get into SPL. The update of leds and
env does not depends
on banner print.
Thanks,
- Kever
Printing banner would also
help to support debugging availability between relocation codes,
like debug uart available before relocation and banner availability
after relation.
By demonstrating all the above use cases, this patch is trying
to print the SPL banner after relocation.
Signed-off-by: Jagan Teki
Tested-by: Suniel Mahesh
---
Changes for v4:
- none
arch/arm/mach-rockchip/spl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
index d4c83a1119..6d5c058548 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -147,7 +147,6 @@ void board_init_f(ulong dummy)
gd->ram_top = gd->ram_base + get_effective_memsize();
gd->ram_top = board_get_usable_ram_top(gd->ram_size);
#endif
- preloader_console_init();
}
__weak void rk_spl_board_init(void)
@@ -158,6 +157,8 @@ void spl_board_init(void)
{
/* board specific spl init */
rk_spl_board_init();
+
+ preloader_console_init();
}
#ifdef CONFIG_SPL_LOAD_FIT
Re: [PATCH v4 1/5] rockchip: spl: Add spl_board_init
Hi Jagan,
On 2020/6/18 下午11:39, Jagan Teki wrote:
spl_board_init is a proper location and common practice
option to have a custom board initialization code after
relocation in SPL.
This patch add the feasibility to add the custom SPL board
initzlaization throughout rockchip platforms and adjust
existing the spl board code on respective boards.
You make this change because you want to add customize code for led, right?
I think led is a common feature for SBC bring up, could you make it
common instead
of custom for one board? eg. there is already "u-boot,boot-led", and led
class driver
for gpio led.
For the TPL/SPL framework, drop the code in TPL is necessary, but it
would be better
not to use too much layer in SPL board_init, and make it common for
common featrure.
Thanks,
- Kever
Signed-off-by: Jagan Teki
---
Changes for v4:
- new patch
arch/arm/Kconfig | 1 +
arch/arm/mach-rockchip/Kconfig| 2 -
arch/arm/mach-rockchip/rk3188/rk3188.c| 2 +-
arch/arm/mach-rockchip/rk3399/rk3399.c| 57 -
arch/arm/mach-rockchip/spl.c | 10 +++
board/firefly/firefly-rk3288/firefly-rk3288.c | 2 +-
board/phytec/phycore_rk3288/phycore-rk3288.c | 2 +-
.../puma_rk3399/puma-rk3399.c | 61 +++
8 files changed, 75 insertions(+), 62 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index edc9e38c6c..57ddf15cb3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1679,6 +1679,7 @@ config ARCH_ROCKCHIP
select ENABLE_ARM_SOC_BOOT0_HOOK
select OF_CONTROL
select SPI
+ select SPL_BOARD_INIT if SPL
select SPL_DM if SPL
select SYS_MALLOC_F
select SYS_THUMB_BUILD if !ARM64
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 0cb1f23d0f..b1008a5058 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -49,7 +49,6 @@ config ROCKCHIP_RK3128
config ROCKCHIP_RK3188
bool "Support Rockchip RK3188"
select CPU_V7A
- select SPL_BOARD_INIT if SPL
select SUPPORT_SPL
select SPL
select SPL_CLK
@@ -208,7 +207,6 @@ config ROCKCHIP_RK3399
select SPL
select SPL_ATF
select SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF
- select SPL_BOARD_INIT if SPL
select SPL_LOAD_FIT
select SPL_CLK if SPL
select SPL_PINCTRL if SPL
diff --git a/arch/arm/mach-rockchip/rk3188/rk3188.c
b/arch/arm/mach-rockchip/rk3188/rk3188.c
index ef57dfd761..0c0fe84ad5 100644
--- a/arch/arm/mach-rockchip/rk3188/rk3188.c
+++ b/arch/arm/mach-rockchip/rk3188/rk3188.c
@@ -111,7 +111,7 @@ static int setup_led(void)
return 0;
}
-void spl_board_init(void)
+void rk_spl_board_init(void)
{
int ret;
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c
index 4fda93b152..b53a111769 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -217,61 +217,4 @@ void spl_perform_fixups(struct spl_image_info *spl_image)
"u-boot,spl-boot-device", boot_ofpath);
}
-#if defined(SPL_GPIO_SUPPORT)
-static void rk3399_force_power_on_reset(void)
-{
- ofnode node;
- struct gpio_desc sysreset_gpio;
-
- debug("%s: trying to force a power-on reset\n", __func__);
-
- node = ofnode_path("/config");
- if (!ofnode_valid(node)) {
- debug("%s: no /config node?\n", __func__);
- return;
- }
-
- if (gpio_request_by_name_nodev(node, "sysreset-gpio", 0,
- &sysreset_gpio, GPIOD_IS_OUT)) {
- debug("%s: could not find a /config/sysreset-gpio\n", __func__);
- return;
- }
-
- dm_gpio_set_value(&sysreset_gpio, 1);
-}
-#endif
-
-void spl_board_init(void)
-{
-#if defined(SPL_GPIO_SUPPORT)
- struct rockchip_cru *cru = rockchip_get_cru();
-
- /*
-* The RK3399 resets only 'almost all logic' (see also in the TRM
-* "3.9.4 Global software reset"), when issuing a software reset.
-* This may cause issues during boot-up for some configurations of
-* the application software stack.
-*
-* To work around this, we test whether the last reset reason was
-* a power-on reset and (if not) issue an overtemp-reset to reset
-* the entire module.
-*
-* While this was previously fixed by modifying the various places
-* that could generate a software reset (e.g. U-Boot's sysreset
-* driver, the ATF or Linux), we now have it here to ensure that
-* we no longer have to track this through the various components.
-*/
- if (cru->glb_rst_st != 0)
- rk3399_force_power_on_reset();
-#endif
-
-#if defined(SPL_DM_REGULATOR)
- /*
-* Turning the eMMC an
Re: [PATCH v2 01/25] x86: mp_init: Switch to livetree
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote: > > Update this code to use livetree calls instead of flat-tree. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > (no changes since v1) > > arch/x86/cpu/mp_init.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 02/25] x86: Move MP code into mp_init
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote: > > At present the 'flight plan' for CPUs is passed into mp_init. But it is > always the same. Move it into the mp_init file so everything is in one > place. Also drop the SMI function since it does nothing. If we implement > SMIs, more refactoring will be needed anyway. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > (no changes since v1) > > arch/x86/cpu/i386/cpu.c | 24 +--- > arch/x86/cpu/mp_init.c| 22 ++ > arch/x86/include/asm/mp.h | 17 + > 3 files changed, 16 insertions(+), 47 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 04/25] x86: mp_init: Switch parameter names in start_aps()
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote: > > These parameters are named differently from elsewhere in this file. Switch > them to avoid confusion. > > Also add comments to this function. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add comments to explain what start_aps() does > > arch/x86/cpu/mp_init.c | 25 +++-- > 1 file changed, 19 insertions(+), 6 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 05/25] x86: mp_init: Drop the num_cpus static variable
Hi Simon,
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> This does not need to be global across all functions in this file. Pass a
> parameter instead.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> arch/x86/cpu/mp_init.c | 22 +++---
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/cpu/mp_init.c b/arch/x86/cpu/mp_init.c
> index 8b00d57c88..aebbca6618 100644
> --- a/arch/x86/cpu/mp_init.c
> +++ b/arch/x86/cpu/mp_init.c
> @@ -31,9 +31,6 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> -/* Total CPUs include BSP */
> -static int num_cpus;
> -
> /* This also needs to match the sipi.S assembly code for saved MSR encoding
> */
> struct saved_msr {
> uint32_t index;
> @@ -384,13 +381,23 @@ static int start_aps(int num_aps, atomic_t *ap_count)
> return 0;
> }
>
> -static int bsp_do_flight_plan(struct udevice *cpu, struct mp_flight_plan
> *plan)
> +/**
> + * bsp_do_flight_plan() - Do the flight plan on all CPUs
on the BSP
> + *
> + * This runs the flight plan on the main CPU used to boot U-Boot
> + *
> + * @cpu: Device for the main CPU
> + * @plan: Flight plan to run
> + * @num_aps: Number of APs (CPUs other than the BSP)
> + * @returns 0 on success, -ETIMEDOUT if an AP failed to come up
> + */
> +static int bsp_do_flight_plan(struct udevice *cpu, struct mp_flight_plan
> *plan,
> + int num_aps)
> {
> int i;
> int ret = 0;
> const int timeout_us = 10;
> const int step_us = 100;
> - int num_aps = num_cpus - 1;
>
> for (i = 0; i < plan->num_records; i++) {
> struct mp_flight_record *rec = &plan->records[i];
> @@ -410,6 +417,7 @@ static int bsp_do_flight_plan(struct udevice *cpu, struct
> mp_flight_plan *plan)
>
> release_barrier(&rec->barrier);
> }
> +
> return ret;
> }
>
> @@ -454,7 +462,7 @@ static struct mp_flight_record mp_steps[] = {
>
> int mp_init(void)
> {
> - int num_aps;
> + int num_aps, num_cpus;
> atomic_t *ap_count;
> struct udevice *cpu;
> int ret;
> @@ -516,7 +524,7 @@ int mp_init(void)
> }
>
> /* Walk the flight plan for the BSP */
> - ret = bsp_do_flight_plan(cpu, &mp_info);
> + ret = bsp_do_flight_plan(cpu, &mp_info, num_aps);
> if (ret) {
> debug("CPU init failed: err=%d\n", ret);
> return ret;
> --
Other than that,
Reviewed-by: Bin Meng
Regards,
Bin
Re: [PATCH v2 03/25] x86: mp_init: Avoid declarations in header files
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote: > > The functions used by the flight plan are declared in the header file but > are not used in any other file. > > Move the flight plan steps down to just above where it is used so that we > can make these function static. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > (no changes since v1) > > arch/x86/cpu/mp_init.c| 40 +++ > arch/x86/include/asm/mp.h | 3 --- > 2 files changed, 20 insertions(+), 23 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 06/25] x86: mtrr: Fix 'ensable' typo
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote: > > Fix a typo in the command help. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > (no changes since v1) > > cmd/x86/mtrr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 09/25] x86: cpu: Remove unnecessary #ifdefs
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote: > > Drop some #ifdefs that are not needed or can be converted to compile-time > checks. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > (no changes since v1) > > arch/x86/cpu/cpu.c | 58 - > arch/x86/cpu/i386/cpu.c | 2 -- > 2 files changed, 28 insertions(+), 32 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 10/25] x86: mp: Support APs waiting for instructions
Hi Simon,
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> At present the APs (non-boot CPUs) are inited once and then parked ready
> for the OS to use them. However in some cases we want to send new requests
> through, such as to change MTRRs and keep them consistent across CPUs.
>
> Change the last state of the flight plan to go into a wait loop, accepting
> instructions from the main CPU.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2:
> - Add more comments
>
> arch/x86/cpu/mp_init.c| 126 +++---
> arch/x86/include/asm/mp.h | 11
> 2 files changed, 128 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/cpu/mp_init.c b/arch/x86/cpu/mp_init.c
> index cd4cae559d..673fdc9628 100644
> --- a/arch/x86/cpu/mp_init.c
> +++ b/arch/x86/cpu/mp_init.c
> @@ -43,13 +43,38 @@ struct mp_flight_plan {
> struct mp_flight_record *records;
> };
>
> +/**
> + * struct mp_callback - Callback information for APs
> + *
> + * @func: Function to run
> + * @arg: Argument to pass to the function
> + * @logical_cpu_number: Either a CPU number (i.e. dev->req_seq) or a special
> + * value like MP_SELECT_BSP. It tells the AP whether it should process
> this
> + * callback
> + */
> +struct mp_callback {
> + /**
> +* func() - Function to call on the AP
> +*
> +* @arg: Argument to pass
> +*/
> + void (*func)(void *arg);
> + void *arg;
> + int logical_cpu_number;
> +};
> +
> static struct mp_flight_plan mp_info;
>
> -struct cpu_map {
> - struct udevice *dev;
> - int apic_id;
> - int err_code;
> -};
> +/*
> + * ap_callbacks - Callback mailbox array
> + *
> + * Array of callback, one entry for each available CPU, indexed by the CPU
> + * number, which is dev->req_seq. The entry for the main CPU is never used.
> + * When this is NULL, there is no pending work for the CPU to run. When
> + * non-NULL it points to the mp_callback structure. This is shared between
> all
> + * CPUs, so should only be written by the main CPU.
> + */
> +static struct mp_callback **ap_callbacks;
>
> static inline void barrier_wait(atomic_t *b)
> {
> @@ -147,11 +172,9 @@ static void ap_init(unsigned int cpu_index)
> debug("AP: slot %d apic_id %x, dev %s\n", cpu_index, apic_id,
> dev ? dev->name : "(apic_id not found)");
>
> - /* Walk the flight plan */
> + /* Walk the flight plan, which never returns */
> ap_do_flight_plan(dev);
> -
> - /* Park the AP */
> - debug("parking\n");
> + debug("Unexpected return\n");
> done:
> stop_this_cpu();
> }
> @@ -455,6 +478,86 @@ static int get_bsp(struct udevice **devp, int
> *cpu_countp)
> return dev->req_seq;
> }
>
> +/**
> + * read_callback() - Read the pointer in a callback slot
> + *
> + * This is called by APs to read their callback slow to see if there is a
> + * pointer to new instructions
> + *
> + * @slot: Pointer to the AP's callback slot
> + * @return value of that pointer
> + */
> +static struct mp_callback *read_callback(struct mp_callback **slot)
> +{
> + struct mp_callback *ret;
> +
> + asm volatile ("mov %1, %0\n"
> + : "=r" (ret)
> + : "m" (*slot)
> + : "memory"
> + );
Why do we need inline assembly here? Prevent compiler reordering the
codes ("memory")? Can we use C and additional memory barrier to do
this?
> + return ret;
> +}
> +
> +/**
> + * store_callback() - Store a pointer to the callback slot
> + *
> + * This is called by APs to write NULL into the callback slot when they have
> + * finished the work requested by the BSP.
> + *
> + * @slot: Pointer to the AP's callback slot
> + * @val: Value to write (e.g. NULL)
> + */
> +static void store_callback(struct mp_callback **slot, struct mp_callback
> *val)
> +{
> + asm volatile ("mov %1, %0\n"
> + : "=m" (*slot)
> + : "r" (val)
> + : "memory"
> + );
> +}
> +
> +/**
> + * ap_wait_for_instruction() - Wait for and process requests from the main
> CPU
> + *
> + * This is called by APs (here, everything other than the main boot CPU) to
> + * await instructions. They arrive in the form of a function call and
> argument,
> + * which is then called. This uses a simple mailbox with atomic read/set
> + *
> + * @cpu: CPU that is waiting
> + * @unused: Optional argument provided by struct mp_flight_record, not used
> here
> + * @return Does not return
> + */
> +static int ap_wait_for_instruction(struct udevice *cpu, void *unused)
> +{
> + struct mp_callback lcb;
> + struct mp_callback **per_cpu_slot;
> +
> + per_cpu_slot = &ap_callbacks[cpu->req_seq];
> +
> + while (1) {
> + struct mp_callback *cb = read_callback(per_cpu_slot);
> +
> + if (!cb) {
> + asm ("pause");
> + continue;
> + }
> +
> +
Re: [PATCH v2 07/25] x86: mp_init: Set up the CPU numbers at the start
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote: > > At present each CPU is given a number when it starts itself up. While this > saves a tiny amount of time by doing the device-tree read in parallel, it > is confusing that the numbering happens on the fly. > > Move this code into mp_init() and do it at the start. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > (no changes since v1) > > arch/x86/cpu/mp_init.c | 21 + > 1 file changed, 9 insertions(+), 12 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 08/25] x86: mp_init: Adjust bsp_init() to return more information
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> This function is misnamed since it does not actually init the BSP. Also
> it is convenient to adjust it to return a little more information.
>
> Rename and update the function, to allow it to return the BSP CPU device
> and number, as well as the total number of CPUs.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> Changes in v2:
> - Drop change to include/dm/uclass.h
> - Mention error return in get_bsp()
>
> arch/x86/cpu/mp_init.c | 35 ++-
> 1 file changed, 22 insertions(+), 13 deletions(-)
>
> diff --git a/arch/x86/cpu/mp_init.c b/arch/x86/cpu/mp_init.c
> index e0270e71db..cd4cae559d 100644
> --- a/arch/x86/cpu/mp_init.c
> +++ b/arch/x86/cpu/mp_init.c
> @@ -421,9 +421,17 @@ static int bsp_do_flight_plan(struct udevice *cpu,
> struct mp_flight_plan *plan,
> return ret;
> }
>
> -static int init_bsp(struct udevice **devp)
> +/**
> + * get_bsp() - Get information about the bootstrap processor
> + *
> + * @devp: If non-NULL, returns CPU device corresponding to the BSP
> + * @cpu_countp: If non-NULL, returns the total number of CPUs
> + * @return CPU number of the BSP, or -ve on error
The return value of BSP CPU number seems not useful in this patch. But
I see it will be used in future patches.
> + */
> +static int get_bsp(struct udevice **devp, int *cpu_countp)
> {
> char processor_name[CPU_MAX_NAME_LEN];
> + struct udevice *dev;
> int apic_id;
> int ret;
>
> @@ -431,13 +439,20 @@ static int init_bsp(struct udevice **devp)
> debug("CPU: %s\n", processor_name);
>
> apic_id = lapicid();
> - ret = find_cpu_by_apic_id(apic_id, devp);
> - if (ret) {
> + ret = find_cpu_by_apic_id(apic_id, &dev);
> + if (ret < 0) {
> printf("Cannot find boot CPU, APIC ID %d\n", apic_id);
> return ret;
> }
> + ret = cpu_get_count(dev);
> + if (ret < 0)
> + return log_msg_ret("count", ret);
> + if (devp)
> + *devp = dev;
> + if (cpu_countp)
> + *cpu_countp = ret;
>
> - return 0;
> + return dev->req_seq;
> }
>
> static int mp_init_cpu(struct udevice *cpu, void *unused)
> @@ -476,24 +491,18 @@ int mp_init(void)
> uclass_id_foreach_dev(UCLASS_CPU, cpu, uc)
> cpu->req_seq = dev_read_u32_default(cpu, "reg", -1);
>
> - ret = init_bsp(&cpu);
> - if (ret) {
> + ret = get_bsp(&cpu, &num_cpus);
> + if (ret < 0) {
> debug("Cannot init boot CPU: err=%d\n", ret);
> return ret;
> }
>
> - num_cpus = cpu_get_count(cpu);
> - if (num_cpus < 0) {
> - debug("Cannot get number of CPUs: err=%d\n", num_cpus);
> - return num_cpus;
> - }
> -
> if (num_cpus < 2)
> debug("Warning: Only 1 CPU is detected\n");
>
> ret = check_cpu_devices(num_cpus);
> if (ret)
> - debug("Warning: Device tree does not describe all CPUs. Extra
> ones will not be started correctly\n");
> + log_warning("Warning: Device tree does not describe all CPUs.
> Extra ones will not be started correctly\n");
>
> /* Copy needed parameters so that APs have a reference to the plan */
> mp_info.num_records = ARRAY_SIZE(mp_steps);
> --
Reviewed-by: Bin Meng
