Re: [PATCH 1/3] Dockerfile: Install riscv32 toolchain from kernel.org
On Tue, Mar 31, 2020 at 11:15 PM Tom Rini wrote: > > On Sat, Mar 28, 2020 at 07:55:37AM +0800, Bin Meng wrote: > > Hi Tom, > > > > On Fri, Mar 27, 2020 at 11:25 PM Tom Rini wrote: > > > > > > On Fri, Mar 27, 2020 at 02:05:55PM +0800, Bin Meng wrote: > > > > Hi Tom, > > > > > > > > On Fri, Mar 27, 2020 at 10:00 AM Tom Rini wrote: > > > > > > > > > > On Fri, Mar 27, 2020 at 09:57:47AM +0800, Bin Meng wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Fri, Mar 27, 2020 at 12:14 AM Tom Rini > > > > > > wrote: > > > > > > > > > > > > > > On Thu, Mar 26, 2020 at 09:04:52AM -0700, Bin Meng wrote: > > > > > > > > > > > > > > > This is required to build GRUB UEFI target for RISC-V 32-bit. > > > > > > > > > > > > > > > > Signed-off-by: Bin Meng > > > > > > > > > > > > > > Since we can use the 64bit toolchain for 32bit U-Boot, can we not > > > > > > > pass > > > > > > > GRUB the right flags to use the same toolchain? Thanks! > > > > > > > > > > > > The 32-bit GRUB won't build with the 64-bit toolchain as of the > > > > > > grub-2.04 branch we are using. > > > > > > > > > > Is that something that upstream has fixed or will fix / can be fixed > > > > > and > > > > > we can bump the tag we're using for? > > > > > > > > I tried the latest upstream GRUB, and it still cannot be built using > > > > riscv64 toolchain from kernel.org. > > > > > > Can that be fixed? Would that be accepted? Thanks! > > > > > > > I reported this issue to the grub mailing list. For now I believe we > > should stick to current 2.04 until upstream has a solution for it. > > Has upstream said anything here? Thanks! There are some comments but no help. So far I think we should go with current solution and wait grub upstream for the solution. Regards, Bin
Re: [PATCH 3/4] cmd: mmc: display write protect state of boot partition
Hi,
On 3/30/20 2:24 PM, Heinrich Schuchardt wrote:
> Boot partitions of eMMC devices can be power on or permanently write
> protected. Let the 'mmc info' command display the protection state.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> cmd/mmc.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index 6f3cb85cc0..d62c85e439 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -54,6 +54,8 @@ static void print_mmcinfo(struct mmc *mmc)
> if (!IS_SD(mmc) && mmc->version >= MMC_VERSION_4_41) {
> bool has_enh = (mmc->part_support & ENHNCD_SUPPORT) != 0;
> bool usr_enh = has_enh && (mmc->part_attr & EXT_CSD_ENH_USR);
> + u8 wp, ext_csd[MMC_MAX_BLOCK_LEN];
> + int ret;
>
> #if CONFIG_IS_ENABLED(MMC_HW_PARTITIONING)
> puts("HC WP Group Size: ");
> @@ -90,6 +92,28 @@ static void print_mmcinfo(struct mmc *mmc)
> putc('\n');
> }
> }
> + ret = mmc_send_ext_csd(mmc, ext_csd);
> + if (ret)
> + return;
Is it really needed to call mmc_send_ext_csd() at here.
ext_csd register value was already read somewhere.
Best Regards,
Jaehoon Chung
> + wp = ext_csd[EXT_CSD_BOOT_WP_STATUS];
> + for (i = 0; i < 2; ++i) {
> + printf("Boot area %d is ", i);
> + switch (wp & 3) {
> + case 0:
> + printf("not write protected\n");
> + break;
> + case 1:
> + printf("power on protected\n");
> + break;
> + case 2:
> + printf("permanently protected\n");
> + break;
> + default:
> + printf("in reserved protection state\n");
> + break;
> + }
> + wp >>= 2;
> + }
> }
> }
> static struct mmc *init_mmc_device(int dev, bool force_init)
> --
> 2.25.1
>
>
>
[PATCH] i2c: muxes: pca954x: add PCA9546 variant
This adds the PCA9546 4-channel i2c bus switch.
Signed-off-by: Chris Packham
---
U-boot already supports the PCA9646 which is a pin-compatible (and
mostly register compatible) replacement. I still think it's worth making
the distinction and Linux actually supports the 9546 instead of the 9646
so u-boot will likely encounter dtses with 9546 in the compatible
string.
drivers/i2c/muxes/Kconfig | 4 ++--
drivers/i2c/muxes/pca954x.c | 6 ++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 68f15261be77..39683fc43b49 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -33,8 +33,8 @@ config I2C_MUX_PCA954x
devices. It is x width I2C multiplexer which enables to partitioning
I2C bus and connect multiple devices with the same address to the same
I2C controller where driver handles proper routing to target i2c
- device. Supported chips are PCA9543, PCA9544, PCA9547, PCA9548 and
- PCA9646.
+ device. Supported chips are PCA9543, PCA9544, PCA9546, PCA9547,
+ PCA9548 and PCA9646.
config I2C_MUX_GPIO
tristate "GPIO-based I2C multiplexer"
diff --git a/drivers/i2c/muxes/pca954x.c b/drivers/i2c/muxes/pca954x.c
index be90a7b24a8e..cc8afc93b5e1 100644
--- a/drivers/i2c/muxes/pca954x.c
+++ b/drivers/i2c/muxes/pca954x.c
@@ -18,6 +18,7 @@ DECLARE_GLOBAL_DATA_PTR;
enum pca_type {
PCA9543,
PCA9544,
+ PCA9546,
PCA9547,
PCA9548,
PCA9646
@@ -48,6 +49,10 @@ static const struct chip_desc chips[] = {
.muxtype = pca954x_ismux,
.width = 4,
},
+ [PCA9546] = {
+ .muxtype = pca954x_isswi,
+ .width = 4,
+ },
[PCA9547] = {
.enable = 0x8,
.muxtype = pca954x_ismux,
@@ -95,6 +100,7 @@ static const struct i2c_mux_ops pca954x_ops = {
static const struct udevice_id pca954x_ids[] = {
{ .compatible = "nxp,pca9543", .data = PCA9543 },
{ .compatible = "nxp,pca9544", .data = PCA9544 },
+ { .compatible = "nxp,pca9546", .data = PCA9546 },
{ .compatible = "nxp,pca9547", .data = PCA9547 },
{ .compatible = "nxp,pca9548", .data = PCA9548 },
{ .compatible = "nxp,pca9646", .data = PCA9646 },
--
2.25.1
RE: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function
> Hi Marek, > > On Wed, 11 Mar 2020 at 05:55, Marek Vasut wrote: > > > > On 3/11/20 12:50 PM, Simon Glass wrote: > > > Hi, > > > > Hi, > > > > > On Mon, 9 Mar 2020 at 02:22, wrote: > > >> > > >> From: Chee Hong Ang > > >> > > >> This commit (82de42fa14682d408da935adfb0f935354c5008f) calls > > >> child's > > >> ofdata_to_platdata() method before the parent is probed in dm core. > > >> This has caused the driver no longer able to get the correct parent > > >> clock's register base in the ofdata_to_platdata() method because > > >> the parent clocks will only be probed after the child's > > >> ofdata_to_platdata(). > > >> To resolve this, the clock parent's register base will only be > > >> retrieved by the child in probe() method instead of ofdata_to_platdata(). > > > > > > I think one thing that is going on here is that DM allows ofdata to > > > be read for a device before its parent devices have been read, but > > > it requires that parent devices be probed before their children. > > > > This seems wrong. The clock driver should be able to instantiate > > devices and read their ofdata without probing them. That is one of the > > core design principles of the DM. > > That's a different question. Yes you can read ofdata without probing a device. > That's why we have two methods. > > The point I am making is that at present there is no requirement that a > parent's > ofdata be read before a child's ofdata is read. But there is a requirement > that a > parent be probed before a child is probed. > > > > > > The idea is that it should be possible to read the ofdata for a node > > > without needing to have done so for parents. But perhaps this > > > assumption is too brave? > > > > Why is it brave ? That's how it always was, the DT is already there, > > so why wouldn't you be able to read it. > > That was my thinking too. But we are finding in a few situations that the > child's > ofdata depends on the parent's. For example, the parent may have a base > address, or a range mapping, or something else that is needed for the child to > correctly get its base address, etc. > > > > > > I suspect we could change this, so that device_ofdata_to_platdata() > > > first calls itself on its parent. > > > > > > I can think of various reasons why this change might be desirable. > > > > I think this is how it worked before already. > > Well effectively, yes, because ofdata and probe were joined together. > > Regards, > Simon Simon, do you have plan to fix this DM core issue ?
Re: [PATCH 15/16] efi_loader: enable UEFI variables at runtime
On Tue, Mar 31, 2020 at 08:05:40AM +0200, Heinrich Schuchardt wrote:
> Enable UEFI variables at runtime.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_runtime.c | 6 +-
> lib/efi_loader/efi_variable.c | 23 +--
> 2 files changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
> index 664a0422e2..acd644202d 100644
> --- a/lib/efi_loader/efi_runtime.c
> +++ b/lib/efi_loader/efi_runtime.c
> @@ -120,8 +120,12 @@ efi_status_t efi_init_runtime_supported(void)
> rt_table->version = EFI_RT_PROPERTIES_TABLE_VERSION;
> rt_table->length = sizeof(struct efi_rt_properties_table);
> rt_table->runtime_services_supported =
> + EFI_RT_SUPPORTED_GET_VARIABLE |
> + EFI_RT_SUPPORTED_GET_NEXT_VARIABLE_NAME |
> + EFI_RT_SUPPORTED_SET_VARIABLE |
> EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP |
> - EFI_RT_SUPPORTED_CONVERT_POINTER;
> + EFI_RT_SUPPORTED_CONVERT_POINTER |
> + EFI_RT_SUPPORTED_QUERY_VARIABLE_INFO;
>
> /*
>* This value must be synced with efi_runtime_detach_list
> diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
> index 7c39542968..cf8b44c535 100644
> --- a/lib/efi_loader/efi_variable.c
> +++ b/lib/efi_loader/efi_variable.c
> @@ -326,15 +326,13 @@ efi_status_t __efi_runtime EFIAPI
> efi_query_variable_info(
> u64 *remaining_variable_storage_size,
> u64 *maximum_variable_size)
> {
> - /*
> *maximum_variable_storage_size = EFI_VAR_BUF_SIZE -
>sizeof(struct efi_var_file);
> *remaining_variable_storage_size = efi_var_mem_free();
> *maximum_variable_size = EFI_VAR_BUF_SIZE -
>sizeof(struct efi_var_file) -
>sizeof(struct efi_var_entry);
> - */
> - return EFI_UNSUPPORTED;
> + return EFI_SUCCESS;
> }
>
> /**
> @@ -351,7 +349,8 @@ static efi_status_t __efi_runtime EFIAPI
> efi_get_variable_runtime(u16 *variable_name, const efi_guid_t *vendor,
>u32 *attributes, efi_uintn_t *data_size, void *data)
> {
> - return EFI_UNSUPPORTED;
> + return efi_get_variable_int(variable_name, vendor, attributes,
> + data_size, data);
> }
>
> /**
> @@ -367,7 +366,8 @@ static efi_status_t __efi_runtime EFIAPI
> efi_get_next_variable_name_runtime(efi_uintn_t *variable_name_size,
> u16 *variable_name, efi_guid_t *vendor)
> {
> - return EFI_UNSUPPORTED;
> + return efi_get_next_variable_name_int(variable_name_size, variable_name,
> + vendor);
> }
>
> /**
> @@ -385,7 +385,18 @@ efi_set_variable_runtime(u16 *variable_name, const
> efi_guid_t *vendor,
>u32 attributes, efi_uintn_t data_size,
>const void *data)
> {
> - return EFI_UNSUPPORTED;
> + const u32 required_attributes = EFI_VARIABLE_NON_VOLATILE |
> + EFI_VARIABLE_BOOTSERVICE_ACCESS |
> + EFI_VARIABLE_RUNTIME_ACCESS;
> +
Why not support APPEND_WRITE?
> + if (attributes &&
> + (attributes & required_attributes) != required_attributes)
> + return EFI_INVALID_PARAMETER;
UEFI specification says,
===8<
Variables that have runtime access but that are not nonvolatile are read-
only data variables once ExitBootServices() is performed.
[snip]
EFI_WRITE_PROTECTED The variable in question is read-only.
===>8===
So in this case, we should return WRITE_PROTECTED instead of
INVALID_PARAMETER.
> + if ((attributes & ~(u32)EFI_VARIABLE_MASK))
> + return EFI_INVALID_PARAMETER;
> +
> + return efi_set_variable_rt_int(variable_name, vendor, attributes,
> +data_size, data);
I didn't follow detailed logic of this function, but
does it really return UNSUPPORTED if !FAT_WRITE?
-Takahiro Akashi
> }
>
> /**
> --
> 2.25.1
>
Re: [PATCH 09/16] efi_loader: imply FAT, FAT_WRITE
On Wed, Apr 01, 2020 at 08:57:33AM +0900, AKASHI Takahiro wrote: > On Tue, Mar 31, 2020 at 03:08:06PM +0200, Heinrich Schuchardt wrote: > > On 2020-03-31 09:44, AKASHI Takahiro wrote: > > > On Tue, Mar 31, 2020 at 08:44:02AM +0200, Heinrich Schuchardt wrote: > > >> On March 31, 2020, 5:28 a.m. UTC Takahiro Akashi wrote: > > >>> On Fri, Mar 27, 2020 at 06:27:53AM +0100, Heinrich Schuchardt wrote: > > The UEFI spec requires support for the FAT file system. > > > > Signed-off-by: Heinrich Schuchardt > > --- > > lib/efi_loader/Kconfig | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > index 9890144d41..e10ca05549 100644 > > --- a/lib/efi_loader/Kconfig > > +++ b/lib/efi_loader/Kconfig > > @@ -15,6 +15,8 @@ config EFI_LOADER > > select HAVE_BLOCK_DEVICE > > select REGEX > > imply CFB_CONSOLE_ANSI > > + imply FAT > > + imply FAT_WRITE > > >>> > > >>> Obviously, this *imply* doesn't enforce enabling FAT. > > >>> If it is absolutely necessary, another measure should be taken. > > >> > > >> If somebody wants to minimize the U-Boot size it might be necessary to > > >> do without FAT_WRITE or FAT support. > > > > > > If so, Get/SetVariable won't be supported even in boot time > > > with your patch applied. It is not practical for almost all users. > > > > Hello Akashi, > > > > without FAT_WRITE we will not have persistence for variables. > > SetVariable and GetVariable are still usable. > > How about CONFIG_FAT? (=> What if !CONFIG_FAT) More fundamentally, Why do you want to use a file as storage device for variables? why not raw partition (or just part of partition) on, say, NOR or eMMC? As you know, EDK2 saves variables directly on NOR (or block device? probably). -Takahiro Akashi > -Takahiro Akashi > > > Best regards > > > > Heinrich > > > > > > > >>> > > >>> In addition, why do you treat FAT specifically here? > > >>> I remember that you insisted that other file system should be > > >>> allowed on U-Boot when I posted some patch. > > >> > > >> An EFI system partition is always FAT formatted. So if we want to safe > > >> U-Boot variables to the EFI system partition we require FAT. > > > > > > As system partition is required to be in FAT, file system used on > > > other partitions must also be in FAT since, as I said before, > > > UEFI specification clearly defines its file system format based on FAT. > > > See section 13.3. > > > > > > So, > > > > > >>> I remember that you insisted that other file system should be > > >>> allowed on U-Boot when I posted some patch. > > > > > > You reverted your statement above here. > > > That is my point. > > > > > > -Takahiro Akashi > > > > > >> Best regards > > >> > > >> Heinrich > > >> > > >>> > > >>> -Takahiro Akashi > > >>> > > >>> > > imply USB_KEYBOARD_FN_KEYS > > imply VIDEO_ANSI > > help > > -- > > 2.25.1 > >
Re: [PATCH 4/5] rockchip: rk3399: Enable CONFIG_RNG_ROCKCHIP
Hi Peter, On 2020/3/31 下午10:37, Peter Robinson wrote: On Tue, Mar 31, 2020 at 12:36 PM Lin Jinhan wrote: CONFIG_RNG_ROCKCHIP/CONFIG_DM_RNG is enabled. This should be universally available by default on all rk3399 devices shouldn't it or does it need external regulators or something that is per device? If so shouldn't we just enable it by default for the SoC? This rng is a internal module, only need available clock and nothing to do with regulator, it could default enable, but I'm not sure all the boards want to enable it, the U-Boot size is already too big for me now. Thanks, - Kever Signed-off-by: Lin Jinhan --- configs/evb-rk3399_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig index 3f74be3b3c..7f14e18b1b 100644 --- a/configs/evb-rk3399_defconfig +++ b/configs/evb-rk3399_defconfig @@ -39,6 +39,8 @@ CONFIG_PMIC_RK8XX=y CONFIG_REGULATOR_PWM=y CONFIG_REGULATOR_RK8XX=y CONFIG_PWM_ROCKCHIP=y +CONFIG_DM_RNG=y +CONFIG_RNG_ROCKCHIP=y CONFIG_BAUDRATE=150 CONFIG_DEBUG_UART_SHIFT=2 CONFIG_SYSRESET=y -- 2.17.1
RE: [PATCH 1/1] mmc: adjust Kconfig for mmc sub-commands
> Subject: [PATCH 1/1] mmc: adjust Kconfig for mmc sub-commands > > All sub-commands of the mmc command should be shown in the Kconfig menu > next to the mmc command. This includes: > > * mmc bkops > * mmc rpmb > * mmc swrite > > The mmc rpmb sub-command is not usable without > CONFIG_SUPPORT_EMMC_RPMB. > Add the missing dependency. > > Signed-off-by: Heinrich Schuchardt > --- > cmd/Kconfig | 26 +++--- > 1 file changed, 15 insertions(+), 11 deletions(-) > > diff --git a/cmd/Kconfig b/cmd/Kconfig > index 6403bc45a5..22ba385141 100644 > --- a/cmd/Kconfig > +++ b/cmd/Kconfig > @@ -1052,21 +1052,34 @@ config CMD_MMC > help > MMC memory mapped support. > > +if CMD_MMC > + > +config CMD_BKOPS_ENABLE > + bool "mmc bkops enable" > + depends on CMD_MMC > + default n > + help > + Enable command for setting manual background operations > handshake > + on a eMMC device. The feature is optionally available on eMMC > devices > + conforming to standard >= 4.41. > + > config CMD_MMC_RPMB > bool "Enable support for RPMB in the mmc command" > - depends on CMD_MMC > + depends on SUPPORT_EMMC_RPMB > help > Enable the commands for reading, writing and programming the > key for the Replay Protection Memory Block partition in eMMC. > > config CMD_MMC_SWRITE > bool "mmc swrite" > - depends on CMD_MMC && MMC_WRITE > + depends on MMC_WRITE > select IMAGE_SPARSE > help > Enable support for the "mmc swrite" command to write Android > sparse > images to eMMC. > > +endif > + > config CMD_MTD > bool "mtd" > depends on MTD > @@ -1599,15 +1612,6 @@ config CMD_BSP > option provides a way to control this. The commands that are enabled > vary depending on the board. > > -config CMD_BKOPS_ENABLE > - bool "mmc bkops enable" > - depends on CMD_MMC > - default n > - help > - Enable command for setting manual background operations > handshake > - on a eMMC device. The feature is optionally available on eMMC > devices > - conforming to standard >= 4.41. > - > config CMD_BLOCK_CACHE > bool "blkcache - control and stats for block cache" > depends on BLOCK_CACHE Reviewed-by: Peng Fan > -- > 2.20.1
Re: [PATCH 16/16] efi_selftest: adjust runtime test for variables
On Tue, Mar 31, 2020 at 08:07:39AM +0200, Heinrich Schuchardt wrote:
> As variable services are available at runtime we have to expect EFI_SUCCESS
> when calling the services.
Why not run variables test *after* ExitBootServices as well as
*before* that event?
Then we should have more test cases.
> Check the SetVariable() only succeeds with EFI_VARIABLE_RUNTIME_ACCESS and
> EFI_VARIABLE_NON_VOLATILE set.
I'm not sure if this claim(check) is true.
At least, you need provide more description about specific test conditions.
-Takahiro Akashi
>
> Signed-off-by: Heinrich Schuchardt
> ---
> .../efi_selftest_variables_runtime.c | 47 +++
> 1 file changed, 39 insertions(+), 8 deletions(-)
>
> diff --git a/lib/efi_selftest/efi_selftest_variables_runtime.c
> b/lib/efi_selftest/efi_selftest_variables_runtime.c
> index b3b40ad2cf..c6005eeeaf 100644
> --- a/lib/efi_selftest/efi_selftest_variables_runtime.c
> +++ b/lib/efi_selftest/efi_selftest_variables_runtime.c
> @@ -20,8 +20,8 @@ static const efi_guid_t guid_vendor0 =
> EFI_GUID(0x67029eb5, 0x0af2, 0xf6b1,
>0xda, 0x53, 0xfc, 0xb5, 0x66, 0xdd, 0x1c, 0xe6);
>
> -/*
> - * Setup unit test.
> +/**
> + * setup() - set up unit test.
> *
> * @handle handle of the loaded image
> * @systable system table
> @@ -38,7 +38,7 @@ static int setup(const efi_handle_t img_handle,
> /**
> * execute() - execute unit test
> *
> - * As runtime support is not implmented expect EFI_UNSUPPORTED to be
> returned.
> + * Test variable services at runtime.
> */
> static int execute(void)
> {
> @@ -52,37 +52,68 @@ static int execute(void)
> efi_guid_t guid;
> u64 max_storage, rem_storage, max_size;
>
> - ret = runtime->query_variable_info(EFI_VARIABLE_BOOTSERVICE_ACCESS,
> + ret = runtime->query_variable_info(EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +EFI_VARIABLE_RUNTIME_ACCESS |
> +EFI_VARIABLE_NON_VOLATILE,
> _storage, _storage,
> _size);
> - if (ret != EFI_UNSUPPORTED) {
> + if (ret != EFI_SUCCESS) {
> efi_st_error("QueryVariableInfo failed\n");
> return EFI_ST_FAILURE;
> }
>
> + ret = runtime->set_variable(L"efi_st_var0", _vendor0,
> + EFI_VARIABLE_BOOTSERVICE_ACCESS |
> + EFI_VARIABLE_NON_VOLATILE,
> + 3, v + 4);
> + if (ret != EFI_INVALID_PARAMETER) {
> + efi_st_error("SetVariable succeeded w/o
> EFI_VARIABLE_RUNTIME_ACCESS\n");
> + return EFI_ST_FAILURE;
> + }
> +
> ret = runtime->set_variable(L"efi_st_var0", _vendor0,
> EFI_VARIABLE_BOOTSERVICE_ACCESS |
> EFI_VARIABLE_RUNTIME_ACCESS,
> 3, v + 4);
> - if (ret != EFI_UNSUPPORTED) {
> + if (ret != EFI_INVALID_PARAMETER) {
> + efi_st_error("SetVariable succeeded w/o
> EFI_VARIABLE_NON_VOLATILE\n");
> + return EFI_ST_FAILURE;
> + }
> +
> + ret = runtime->set_variable(L"efi_st_var0", _vendor0,
> + EFI_VARIABLE_BOOTSERVICE_ACCESS |
> + EFI_VARIABLE_RUNTIME_ACCESS |
> + EFI_VARIABLE_NON_VOLATILE,
> + 3, v + 4);
> + if (ret != EFI_SUCCESS) {
> efi_st_error("SetVariable failed\n");
> return EFI_ST_FAILURE;
> }
> +
> len = 3;
> ret = runtime->get_variable(L"efi_st_var0", _vendor0,
> , , data);
> - if (ret != EFI_UNSUPPORTED) {
> + if (ret != EFI_SUCCESS) {
> efi_st_error("GetVariable failed\n");
> return EFI_ST_FAILURE;
> }
> +
> memset(, 0, 16);
> *varname = 0;
> + len = EFI_ST_MAX_VARNAME_SIZE * sizeof(u16);
> ret = runtime->get_next_variable_name(, varname, );
> - if (ret != EFI_UNSUPPORTED) {
> + if (ret != EFI_SUCCESS) {
> efi_st_error("GetNextVariableName failed\n");
> return EFI_ST_FAILURE;
> }
>
> + ret = runtime->set_variable(L"efi_st_var0", _vendor0, 0,
> + 3, v + 4);
> + if (ret != EFI_SUCCESS) {
> + efi_st_error("Variable deletion failed\n");
> + return EFI_ST_FAILURE;
> + }
> +
> return EFI_ST_SUCCESS;
> }
>
> --
> 2.25.1
>
Re: [PATCH 09/16] efi_loader: imply FAT, FAT_WRITE
On Tue, Mar 31, 2020 at 10:20:17AM +0200, Mark Kettenis wrote: > > Date: Tue, 31 Mar 2020 16:44:34 +0900 > > From: AKASHI Takahiro > > > > On Tue, Mar 31, 2020 at 08:44:02AM +0200, Heinrich Schuchardt wrote: > > > On March 31, 2020, 5:28 a.m. UTC Takahiro Akashi wrote: > > > > On Fri, Mar 27, 2020 at 06:27:53AM +0100, Heinrich Schuchardt wrote: > > > > > The UEFI spec requires support for the FAT file system. > > > > > > > > > > Signed-off-by: Heinrich Schuchardt > > > > > --- > > > > > lib/efi_loader/Kconfig | 2 ++ > > > > > 1 file changed, 2 insertions(+) > > > > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > > index 9890144d41..e10ca05549 100644 > > > > > --- a/lib/efi_loader/Kconfig > > > > > +++ b/lib/efi_loader/Kconfig > > > > > @@ -15,6 +15,8 @@ config EFI_LOADER > > > > > select HAVE_BLOCK_DEVICE > > > > > select REGEX > > > > > imply CFB_CONSOLE_ANSI > > > > > + imply FAT > > > > > + imply FAT_WRITE > > > > > > > > Obviously, this *imply* doesn't enforce enabling FAT. > > > > If it is absolutely necessary, another measure should be taken. > > > > > > If somebody wants to minimize the U-Boot size it might be necessary to > > > do without FAT_WRITE or FAT support. > > > > If so, Get/SetVariable won't be supported even in boot time > > with your patch applied. It is not practical for almost all users. > > I *strongly* disagree with that statement. Most users don't care > about U-Boot providing a full EFI implementation. They just want to > boot their OS. The basic EFI support in U-Boot is good enough for > that and for OpenBSD and some Linux distros on arm/arm64 this is the > only bootpath that works. If adding more code leads to board > maintainers disabling EFI support this isn't helpful. Okay, so can you please describe the minimum set of functionality for you? Without that, the discussion will not be fair. Anyhow, using "imply" to customize UEFI functionality would be poor. Instead, we should introduce explicit configuration, say, config EFI_CUSTOMIZE_RUNTIME_SERVICES if EFI_CUSTOMIZE_RUNTIME_SERVICES config EFI_RUNTIME_GET_VARIABLE select FAT config EFI_RUNTIME_SET_VARIABLE depends on EFI_RUNTIME_GET_VARIABLE select FAT_WRITE ... I proposed similar idea before, but it was not accepted. It is time to do that. Thanks, -Takahiro Akashi
RE: [PATCH 3/3] ARM: tegra: p2371-2180: add I2C nodes to DT
-Original Message-
From: Peter Robinson
Sent: Tuesday, March 31, 2020 3:54 AM
To: tomcwarren3...@gmail.com
Cc: u-boot@lists.denx.de; Stephen Warren ; Thierry Reding
; Jonathan Hunter ; Tom Warren
; Vishruth Jain
Subject: Re: [PATCH 3/3] ARM: tegra: p2371-2180: add I2C nodes to DT
External email: Use caution opening links or attachments
> From: Stephen Warren
>
> This adds to the DT the I2C controllers that connect to the board ID
> EEPROM, camera board EEPROM, etc. With this change, you can now probe
> all I2C devices on a TX1 board.
>
> Signed-off-by: Tom Warren
> ---
> arch/arm/dts/tegra210-p2371-2180.dts | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/dts/tegra210-p2371-2180.dts
> b/arch/arm/dts/tegra210-p2371-2180.dts
> index c2f497c..d982b5f 100644
> --- a/arch/arm/dts/tegra210-p2371-2180.dts
> +++ b/arch/arm/dts/tegra210-p2371-2180.dts
> @@ -12,6 +12,9 @@
>
> aliases {
> i2c0 = "/i2c@7000d000";
> + i2c2 = "/i2c@7000c400";
> + i2c3 = "/i2c@7000c500";
> + i2c5 = "/i2c@546c0c00";
I don't think this is correct, it doesn't show up in U-Boot with the "i2c bus"
command where the others do, looking in the tegra210.dtsi it looks like it
should be i2c@546c?
[Tom] That I2C address is working in downstream (L4T) TX1 U-Boot. The VI_I2C
controller is a little weird, it's normal I2C registers are offset from base by
0xC00. A different driver is needed, but I haven't posted it yet upstream. I
should probably drop if from the DTS for now until I post the VI_I2C driver.
--nvpublic
> mmc0 = "/sdhci@700b0600";
> mmc1 = "/sdhci@700b";
> usb0 = "/usb@7d00"; @@ -33,6 +36,11 @@
> };
> };
>
> + i2c@546c0c00 {
> + status = "okay";
> + clock-frequency = <40>;
> + };
> +
> padctl@7009f000 {
> pinctrl-0 = <_default>;
> pinctrl-names = "default"; @@ -85,6 +93,16 @@
> non-removable;
> };
>
> + i2c@7000c400 {
> + status = "okay";
> + clock-frequency = <40>;
> + };
> +
> + i2c@7000c500 {
> + status = "okay";
> + clock-frequency = <40>;
> + };
> +
> i2c@7000d000 {
> status = "okay";
> clock-frequency = <40>;
> --
> 1.8.2.1.610.g562af5b
>
>
> --
> - This email message is for the sole use of the intended
> recipient(s) and may contain confidential information. Any
> unauthorized review, use, disclosure or distribution is prohibited.
> If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.
> --
> -
RE: [PATCH] mtd: spi: Add Macronix MX25U3235F device
-Original Message-
From: Peter Robinson
Sent: Tuesday, March 31, 2020 3:00 AM
To: tomcwarren3...@gmail.com
Cc: u-boot@lists.denx.de; Stephen Warren ; Thierry Reding
; Jonathan Hunter ; Tom Warren
; ja...@amarulasolutions.com
Subject: Re: [PATCH] mtd: spi: Add Macronix MX25U3235F device
External email: Use caution opening links or attachments
On Thu, Mar 26, 2020 at 9:59 PM wrote:
>
> From: Tom Warren
>
> Add Macronix MX25U3235F flash device description.
> This is a 4MiB part.
Is there potentially more than one part used on the Jetson nano as I get the
following on mine:
Loading Environment from SPI Flash... unrecognized JEDEC id bytes: 00, 40, ff
[Tom] No, just the Macronix 4MB part. You probably need the VI_I2C fix, there
was a problem with the index of the internal_id table. The Macronix part is
JEDEC C2, 25, 36 IIRC.
See "i2c: t210: Add VI_I2C clock source support", just posted a few days ago,
should be in tegra-next.
--nvpublic
> Signed-off-by: Tom Warren
> ---
> drivers/mtd/spi/spi-nor-ids.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mtd/spi/spi-nor-ids.c
> b/drivers/mtd/spi/spi-nor-ids.c index 973b6f8..abdf560 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -147,6 +147,7 @@ const struct flash_info spi_nor_ids[] = {
> { INFO("mx25l6405d", 0xc22017, 0, 64 * 1024, 128, SECT_4K) },
> { INFO("mx25u2033e", 0xc22532, 0, 64 * 1024, 4, SECT_4K) },
> { INFO("mx25u1635e", 0xc22535, 0, 64 * 1024, 32, SECT_4K) },
> + { INFO("mx25u3235f", 0xc22536, 0, 4 * 1024, 1024, SECT_4K)
> + },
> { INFO("mx25u6435f", 0xc22537, 0, 64 * 1024, 128, SECT_4K) },
> { INFO("mx25l12805d", 0xc22018, 0, 64 * 1024, 256, 0) },
> { INFO("mx25l12855e", 0xc22618, 0, 64 * 1024, 256, 0) },
> --
> 1.8.2.1.610.g562af5b
>
>
> --
> - This email message is for the sole use of the intended
> recipient(s) and may contain confidential information. Any
> unauthorized review, use, disclosure or distribution is prohibited.
> If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.
> --
> -
Re: [PATCH 09/16] efi_loader: imply FAT, FAT_WRITE
On Tue, Mar 31, 2020 at 03:08:06PM +0200, Heinrich Schuchardt wrote: > On 2020-03-31 09:44, AKASHI Takahiro wrote: > > On Tue, Mar 31, 2020 at 08:44:02AM +0200, Heinrich Schuchardt wrote: > >> On March 31, 2020, 5:28 a.m. UTC Takahiro Akashi wrote: > >>> On Fri, Mar 27, 2020 at 06:27:53AM +0100, Heinrich Schuchardt wrote: > The UEFI spec requires support for the FAT file system. > > Signed-off-by: Heinrich Schuchardt > --- > lib/efi_loader/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > index 9890144d41..e10ca05549 100644 > --- a/lib/efi_loader/Kconfig > +++ b/lib/efi_loader/Kconfig > @@ -15,6 +15,8 @@ config EFI_LOADER > select HAVE_BLOCK_DEVICE > select REGEX > imply CFB_CONSOLE_ANSI > +imply FAT > +imply FAT_WRITE > >>> > >>> Obviously, this *imply* doesn't enforce enabling FAT. > >>> If it is absolutely necessary, another measure should be taken. > >> > >> If somebody wants to minimize the U-Boot size it might be necessary to > >> do without FAT_WRITE or FAT support. > > > > If so, Get/SetVariable won't be supported even in boot time > > with your patch applied. It is not practical for almost all users. > > Hello Akashi, > > without FAT_WRITE we will not have persistence for variables. > SetVariable and GetVariable are still usable. How about CONFIG_FAT? -Takahiro Akashi > Best regards > > Heinrich > > > > >>> > >>> In addition, why do you treat FAT specifically here? > >>> I remember that you insisted that other file system should be > >>> allowed on U-Boot when I posted some patch. > >> > >> An EFI system partition is always FAT formatted. So if we want to safe > >> U-Boot variables to the EFI system partition we require FAT. > > > > As system partition is required to be in FAT, file system used on > > other partitions must also be in FAT since, as I said before, > > UEFI specification clearly defines its file system format based on FAT. > > See section 13.3. > > > > So, > > > >>> I remember that you insisted that other file system should be > >>> allowed on U-Boot when I posted some patch. > > > > You reverted your statement above here. > > That is my point. > > > > -Takahiro Akashi > > > >> Best regards > >> > >> Heinrich > >> > >>> > >>> -Takahiro Akashi > >>> > >>> > imply USB_KEYBOARD_FN_KEYS > imply VIDEO_ANSI > help > -- > 2.25.1 >
[PATCH 3/4] [RFC] ARM: dts: stm32: Rework DDR DT inclusion
Adjust the DDR configuration dtsi such that they only generate the
DRAM configuration node, the DDR controller node is moved into the
stm32mp157-u-boot.dtsi itself. This permits including multiple DDR
configuration dtsi files in board DT.
Signed-off-by: Marek Vasut
Cc: Manivannan Sadhasivam
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
arch/arm/dts/stm32mp15-ddr.dtsi | 357 +++---
.../dts/stm32mp15-ddr3-1x4Gb-1066-binG.dtsi | 1 +
.../dts/stm32mp15-ddr3-2x4Gb-1066-binG.dtsi | 1 +
arch/arm/dts/stm32mp157-u-boot.dtsi | 25 ++
4 files changed, 246 insertions(+), 138 deletions(-)
diff --git a/arch/arm/dts/stm32mp15-ddr.dtsi b/arch/arm/dts/stm32mp15-ddr.dtsi
index 38f29bb789..50ca7092c4 100644
--- a/arch/arm/dts/stm32mp15-ddr.dtsi
+++ b/arch/arm/dts/stm32mp15-ddr.dtsi
@@ -3,152 +3,233 @@
* Copyright : STMicroelectronics 2018
*/
-/ {
- soc {
- ddr: ddr@5a003000 {
- u-boot,dm-pre-reloc;
+ {
+ config@DDR_MEM_LABEL {
+ u-boot,dm-pre-reloc;
- compatible = "st,stm32mp1-ddr";
+ st,mem-name = DDR_MEM_NAME;
+ st,mem-speed = ;
+ st,mem-size = ;
- reg = <0x5A003000 0x550
- 0x5A004000 0x234>;
+ st,ctl-reg = <
+ DDR_MSTR
+ DDR_MRCTRL0
+ DDR_MRCTRL1
+ DDR_DERATEEN
+ DDR_DERATEINT
+ DDR_PWRCTL
+ DDR_PWRTMG
+ DDR_HWLPCTL
+ DDR_RFSHCTL0
+ DDR_RFSHCTL3
+ DDR_CRCPARCTL0
+ DDR_ZQCTL0
+ DDR_DFITMG0
+ DDR_DFITMG1
+ DDR_DFILPCFG0
+ DDR_DFIUPD0
+ DDR_DFIUPD1
+ DDR_DFIUPD2
+ DDR_DFIPHYMSTR
+ DDR_ODTMAP
+ DDR_DBG0
+ DDR_DBG1
+ DDR_DBGCMD
+ DDR_POISONCFG
+ DDR_PCCFG
+ >;
- clocks = < AXIDCG>,
-< DDRC1>,
-< DDRC2>,
-< DDRPHYC>,
-< DDRCAPB>,
-< DDRPHYCAPB>;
+ st,ctl-timing = <
+ DDR_RFSHTMG
+ DDR_DRAMTMG0
+ DDR_DRAMTMG1
+ DDR_DRAMTMG2
+ DDR_DRAMTMG3
+ DDR_DRAMTMG4
+ DDR_DRAMTMG5
+ DDR_DRAMTMG6
+ DDR_DRAMTMG7
+ DDR_DRAMTMG8
+ DDR_DRAMTMG14
+ DDR_ODTCFG
+ >;
- clock-names = "axidcg",
- "ddrc1",
- "ddrc2",
- "ddrphyc",
- "ddrcapb",
- "ddrphycapb";
+ st,ctl-map = <
+ DDR_ADDRMAP1
+ DDR_ADDRMAP2
+ DDR_ADDRMAP3
+ DDR_ADDRMAP4
+ DDR_ADDRMAP5
+ DDR_ADDRMAP6
+ DDR_ADDRMAP9
+ DDR_ADDRMAP10
+ DDR_ADDRMAP11
+ >;
- st,mem-name = DDR_MEM_NAME;
- st,mem-speed = ;
- st,mem-size = ;
+ st,ctl-perf = <
+ DDR_SCHED
+ DDR_SCHED1
+ DDR_PERFHPR1
+ DDR_PERFLPR1
+ DDR_PERFWR1
+ DDR_PCFGR_0
+ DDR_PCFGW_0
+ DDR_PCFGQOS0_0
+ DDR_PCFGQOS1_0
+ DDR_PCFGWQOS0_0
+ DDR_PCFGWQOS1_0
+ DDR_PCFGR_1
+ DDR_PCFGW_1
+ DDR_PCFGQOS0_1
+ DDR_PCFGQOS1_1
+ DDR_PCFGWQOS0_1
+ DDR_PCFGWQOS1_1
+ >;
- st,ctl-reg = <
- DDR_MSTR
- DDR_MRCTRL0
- DDR_MRCTRL1
- DDR_DERATEEN
- DDR_DERATEINT
- DDR_PWRCTL
- DDR_PWRTMG
- DDR_HWLPCTL
- DDR_RFSHCTL0
-
[PATCH 1/4] [RFC] ARM: stm32: Implement board coding on AV96
The AV96 board does exist in multiple variants. To cater for all of
them, implement board code handling. There are two GPIOs which code
the type of the board, read them out and use the value to pick the
correct device tree from an fitImage.
Signed-off-by: Marek Vasut
Cc: Manivannan Sadhasivam
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi | 9 +++
arch/arm/mach-stm32mp/spl.c| 2 +-
board/dhelectronics/dh_stm32mp1/board.c| 84 ++
board/dhelectronics/dh_stm32mp1/u-boot.its | 39 ++
configs/stm32mp15_dhcor_basic_defconfig| 3 +
5 files changed, 136 insertions(+), 1 deletion(-)
create mode 100644 board/dhelectronics/dh_stm32mp1/u-boot.its
diff --git a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
index 02dad81b0b..17a23ae21c 100644
--- a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
@@ -11,6 +11,15 @@
#include "stm32mp157-u-boot.dtsi"
#include "stm32mp15-ddr3-2x4Gb-1066-binG.dtsi"
+/ {
+ u-boot,dm-pre-reloc;
+ config {
+ u-boot,dm-pre-reloc;
+ #gpio-cells = <2>;
+ dh,som-coding-gpios = < 7 0>, < 3 0>;
+ };
+};
+
{
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/mach-stm32mp/spl.c b/arch/arm/mach-stm32mp/spl.c
index ca4231cd0d..5461572090 100644
--- a/arch/arm/mach-stm32mp/spl.c
+++ b/arch/arm/mach-stm32mp/spl.c
@@ -76,7 +76,7 @@ void spl_display_print(void)
}
#endif
-void board_init_f(ulong dummy)
+__weak void board_init_f(ulong dummy)
{
struct udevice *dev;
int ret;
diff --git a/board/dhelectronics/dh_stm32mp1/board.c
b/board/dhelectronics/dh_stm32mp1/board.c
index a3458a2623..36b8652521 100644
--- a/board/dhelectronics/dh_stm32mp1/board.c
+++ b/board/dhelectronics/dh_stm32mp1/board.c
@@ -133,6 +133,90 @@ int checkboard(void)
return 0;
}
+#ifdef CONFIG_SPL_BUILD
+static u8 somcode __section("data");
+
+static void board_get_coding_straps(void)
+{
+ struct gpio_desc gpio;
+ ofnode node;
+ int i, ret;
+
+ node = ofnode_path("/config");
+ if (!ofnode_valid(node)) {
+ printf("%s: no /config node?\n", __func__);
+ return;
+ }
+
+ for (i = 0; i < 2; i++) {
+ ret = gpio_request_by_name_nodev(node, "dh,som-coding-gpios",
+i, , GPIOD_IS_IN);
+ if (ret) {
+ printf("%s: could not find a
/config/dh,som-coding-gpios[%i]\n",
+ __func__, i);
+ return;
+ }
+
+ somcode |= !!dm_gpio_get_value() << i;
+ }
+
+ printf("Code: SoM:%x\n", somcode);
+}
+
+void board_init_f(ulong dummy)
+{
+ struct udevice *dev;
+ int ret;
+
+ arch_cpu_init();
+
+ ret = spl_early_init();
+ if (ret) {
+ debug("spl_early_init() failed: %d\n", ret);
+ hang();
+ }
+
+ ret = uclass_get_device(UCLASS_CLK, 0, );
+ if (ret) {
+ debug("Clock init failed: %d\n", ret);
+ return;
+ }
+
+ ret = uclass_get_device(UCLASS_RESET, 0, );
+ if (ret) {
+ debug("Reset init failed: %d\n", ret);
+ return;
+ }
+
+ ret = uclass_get_device(UCLASS_PINCTRL, 0, );
+ if (ret) {
+ debug("%s: Cannot find pinctrl device\n", __func__);
+ return;
+ }
+
+ /* enable console uart printing */
+ preloader_console_init();
+
+ board_get_coding_straps();
+
+ ret = uclass_get_device(UCLASS_RAM, 0, );
+ if (ret) {
+ printf("DRAM init failed: %d\n", ret);
+ hang();
+ }
+}
+
+#ifdef CONFIG_SPL_LOAD_FIT
+int board_fit_config_name_match(const char *name)
+{
+ if (somcode == 0 && !strcmp(name, "586-100"))
+ return 0;
+
+ return -EINVAL;
+}
+#endif
+#endif
+
static void board_key_check(void)
{
#if defined(CONFIG_FASTBOOT) || defined(CONFIG_CMD_STM32PROG)
diff --git a/board/dhelectronics/dh_stm32mp1/u-boot.its
b/board/dhelectronics/dh_stm32mp1/u-boot.its
new file mode 100644
index 00..3ca3036f7e
--- /dev/null
+++ b/board/dhelectronics/dh_stm32mp1/u-boot.its
@@ -0,0 +1,39 @@
+/dts-v1/;
+
+/ {
+ description = "U-Boot mainline";
+ #address-cells = <1>;
+
+ images {
+ uboot {
+ description = "U-Boot (32-bit)";
+ data = /incbin/("../../../u-boot-nodtb.bin");
+ type = "standalone";
+ os = "U-Boot";
+ arch = "arm";
+ compression = "none";
+ load = <0xc010>;
+ entry = <0xc010>;
+ };
+
+ fdt-1 {
+
[PATCH 4/4] [RFC] ARM: stm32: Implement DDR3 coding on DHCOR SoM
The DHCOR board does exist in multiple variants with different DDR3
DRAM sizes. To cater for all of them, implement DDR3 code handling.
There are two GPIOs which code the DRAM size populated on the SoM,
read them out and use the value to pick the correct DDR3 config.
Signed-off-by: Marek Vasut
Cc: Manivannan Sadhasivam
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi | 2 ++
board/dhelectronics/dh_stm32mp1/board.c| 26 +-
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
index 17a23ae21c..6db4ac37e1 100644
--- a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
@@ -9,6 +9,7 @@
#include
#include "stm32mp157-u-boot.dtsi"
+#include "stm32mp15-ddr3-1x4Gb-1066-binG.dtsi"
#include "stm32mp15-ddr3-2x4Gb-1066-binG.dtsi"
/ {
@@ -16,6 +17,7 @@
config {
u-boot,dm-pre-reloc;
#gpio-cells = <2>;
+ dh,ddr3-coding-gpios = < 0 0>, < 1 0>;
dh,som-coding-gpios = < 7 0>, < 3 0>;
};
};
diff --git a/board/dhelectronics/dh_stm32mp1/board.c
b/board/dhelectronics/dh_stm32mp1/board.c
index 36b8652521..a081a3f86b 100644
--- a/board/dhelectronics/dh_stm32mp1/board.c
+++ b/board/dhelectronics/dh_stm32mp1/board.c
@@ -134,6 +134,7 @@ int checkboard(void)
}
#ifdef CONFIG_SPL_BUILD
+static u8 ddr3code __section("data");
static u8 somcode __section("data");
static void board_get_coding_straps(void)
@@ -149,6 +150,16 @@ static void board_get_coding_straps(void)
}
for (i = 0; i < 2; i++) {
+ ret = gpio_request_by_name_nodev(node, "dh,ddr3-coding-gpios",
+i, , GPIOD_IS_IN);
+ if (ret) {
+ printf("%s: could not find a
/config/dh,ddr3-coding-gpios[%i]\n",
+ __func__, i);
+ return;
+ }
+
+ ddr3code |= !!dm_gpio_get_value() << i;
+
ret = gpio_request_by_name_nodev(node, "dh,som-coding-gpios",
i, , GPIOD_IS_IN);
if (ret) {
@@ -160,7 +171,7 @@ static void board_get_coding_straps(void)
somcode |= !!dm_gpio_get_value() << i;
}
- printf("Code: SoM:%x\n", somcode);
+ printf("Code: DDR3:%x SoM:%x\n", ddr3code, somcode);
}
void board_init_f(ulong dummy)
@@ -206,6 +217,19 @@ void board_init_f(ulong dummy)
}
}
+int board_stm32mp1_ddr_config_name_match(struct udevice *dev,
+const char *name)
+{
+ if (ddr3code == 2 &&
+ !strcmp(name, "config@ddr3-1066-888-bin-g-1x4gb-533mhz"))
+
+ if (ddr3code == 3 &&
+ !strcmp(name, "config@ddr3-1066-888-bin-g-2x4gb-533mhz"))
+ return 0;
+
+ return -EINVAL;
+}
+
#ifdef CONFIG_SPL_LOAD_FIT
int board_fit_config_name_match(const char *name)
{
--
2.25.1
[PATCH 2/4] [RFC] ram: stm32mp1: Add support for multiple configs
Add support for multiple DRAM configuration subnodes, while retaining
the support for a single flat DRAM configuration node. This is useful
on systems which can be manufactured in multiple configurations and
where the DRAM configuration can be determined at runtime.
The code is augmented by a function which can be overridden on board
level, allowing a match on the configuration node name, very much like
the fitImage configuration node name matching works. The default match
is on the single top-level DRAM configuration, if matching on subnodes
is required, then this board_stm32mp1_ddr_config_name_match() must be
overridden.
Signed-off-by: Marek Vasut
Cc: Manivannan Sadhasivam
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
drivers/ram/stm32mp1/stm32mp1_ram.c | 36 +
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/ram/stm32mp1/stm32mp1_ram.c
b/drivers/ram/stm32mp1/stm32mp1_ram.c
index eb78f1198d..d6821eacd7 100644
--- a/drivers/ram/stm32mp1/stm32mp1_ram.c
+++ b/drivers/ram/stm32mp1/stm32mp1_ram.c
@@ -57,6 +57,33 @@ int stm32mp1_ddr_clk_enable(struct ddr_info *priv, uint32_t
mem_speed)
return 0;
}
+__weak int board_stm32mp1_ddr_config_name_match(struct udevice *dev,
+ const char *name)
+{
+ return 0; /* Always match */
+}
+
+static ofnode stm32mp1_ddr_get_ofnode(struct udevice *dev)
+{
+ const char *name;
+ ofnode node;
+
+ node = dev_ofnode(dev);
+ name = ofnode_get_name(node);
+
+ if (!board_stm32mp1_ddr_config_name_match(dev, name))
+ return node;
+
+ dev_for_each_subnode(node, dev) {
+ name = ofnode_get_name(node);
+
+ if (!board_stm32mp1_ddr_config_name_match(dev, name))
+ return node;
+ }
+
+ return ofnode_null();
+}
+
static __maybe_unused int stm32mp1_ddr_setup(struct udevice *dev)
{
struct ddr_info *priv = dev_get_priv(dev);
@@ -64,6 +91,7 @@ static __maybe_unused int stm32mp1_ddr_setup(struct udevice
*dev)
unsigned int idx;
struct clk axidcg;
struct stm32mp1_ddr_config config;
+ ofnode node = stm32mp1_ddr_get_ofnode(dev);
#define PARAM(x, y) \
{ x,\
@@ -87,9 +115,9 @@ static __maybe_unused int stm32mp1_ddr_setup(struct udevice
*dev)
PHY_PARAM(cal)
};
- config.info.speed = dev_read_u32_default(dev, "st,mem-speed", 0);
- config.info.size = dev_read_u32_default(dev, "st,mem-size", 0);
- config.info.name = dev_read_string(dev, "st,mem-name");
+ config.info.speed = ofnode_read_u32_default(node, "st,mem-speed", 0);
+ config.info.size = ofnode_read_u32_default(node, "st,mem-size", 0);
+ config.info.name = ofnode_read_string(node, "st,mem-name");
if (!config.info.name) {
debug("%s: no st,mem-name\n", __func__);
return -EINVAL;
@@ -97,7 +125,7 @@ static __maybe_unused int stm32mp1_ddr_setup(struct udevice
*dev)
printf("RAM: %s\n", config.info.name);
for (idx = 0; idx < ARRAY_SIZE(param); idx++) {
- ret = dev_read_u32_array(dev, param[idx].name,
+ ret = ofnode_read_u32_array(node, param[idx].name,
(void *)((u32) +
param[idx].offset),
param[idx].size);
--
2.25.1
U-Boot is broken on real N900 HW (Was: Re: [PATCH 00/11] Fixes for Nokia RX-51)
On Wednesday 01 April 2020 00:35:07 Pali Rohár wrote: > This patch series contain fixes for Nokia RX-51 board (aka N900). > After these changes it is possible to run U-Boot in qemu emulator again. > And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without > problem. But on real Nokia N900 device is U-Boot crashing in reboot loop. I do not have serial console for Nokia N900 to debug this issue, but seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is that there is no crash and even no error in qemu emulator so I cannot debug this issue. First problem is around /* reset lp5523 led */ code in rx51.c. On real N900 device it generates repeating messages: Check if pads/pull-ups of bus are properly configured Timed out in wait_for_event: status= When I commented that few lines all these messages disappeared. So problem is with OMAP I2C. Second problem happen after misc_init_r() function finishes. U-Boot just prints on N900 screen message "data abort" and reboots. As I do not have serial console it is hard to debug. but I figured out that problem is in mmc_set_ios() function in mmc.c file. In function mmc_set_clock() I put debug info prior to mmc_set_ios() call and after it, and debug info prior was printed, not after. I remember that somebody had serial jig for Nokia N900, could somebody look at this reboot loop problem? And any idea how should be OMAP I2C configured in U-Boot to correctly work? Maybe I will try to find some time to git bisect which change broke U-Boot on real N900 hardware.
[PATCH 10/11] Nokia RX-51: Update README.nokia_rx51
Fix some typos, add information about setup_omap_atag, remove old suff
about ONENAND_SUPPORT and update guide for UBIFS.
Signed-off-by: Pali Rohár
---
doc/README.nokia_rx51 | 32 +++-
1 file changed, 15 insertions(+), 17 deletions(-)
diff --git a/doc/README.nokia_rx51 b/doc/README.nokia_rx51
index 586ed7c1cc..33c275b416 100644
--- a/doc/README.nokia_rx51
+++ b/doc/README.nokia_rx51
@@ -19,7 +19,7 @@ stored ATAGs (see boot order).
There is support for hardware watchdog. Hardware watchdog is started by
NOLO so u-boot must kick watchdog to prevent reboot device (but not very
often, max every 2 seconds). There is also support for framebuffer display
-output with ANSI espace codes and the N900 HW keyboard input. USB tty works
+output with ANSI escape codes and the N900 HW keyboard input. USB tty works
but is disabled because it prevents the current Maemo kernel from booting.
When U-Boot is starting it enable IBE bit in Auxiliary Control Register,
@@ -36,7 +36,7 @@ Boot from SD or eMMC in this order:
* 1.
* 1.1 find boot.scr on first fat partition
- * 1.2 find uImage on first fat parition
+ * 1.2 find uImage on first fat partition
* 1.3 same order for 2. - 4. fat partition
* 2. same as 1. but for ext2/3 partition
* 3. same as 1. but for ext4 partition
@@ -62,21 +62,26 @@ Available additional commands/variables:
* run trymmcscriptboot - Try to load and boot script ${mmcscriptfile}
* run trymmckernboot - Try to load and boot kernel image ${mmckernfile}
* run trymmckerninitrdboot - Try to load and boot kernel image ${mmckernfile}
- with initrd image ${mmcinitrdfile}
+ with initrd image ${mmcinitrdfile}
Additional variables for loading files from mmc:
* mmc ${mmcnum} (0 - external, 1 - internal)
* partition number ${mmcpart} (1 - 4)
- * parition type ${mmctype} (fat, ext2)
+ * parition type ${mmctype} (fat, ext2, ext4)
-Additional varuables for booting kernel:
+Additional variables for booting kernel:
* setup_omap_atag - Add OMAP table into atags structure (needs maemo kernel)
* setup_console_atag - Enable serial console in OMAP table
* setup_boot_reason_atag - Change boot reason in OMAP table
* setup_boot_mode_atag - Change boot mode in OMAP table
+ Variable setup_omap_atag is automatically set when booting attached kernel.
+ When variable setup_omap_atag is set, variable setup_console_atag is unset
+ and u-boot standard output is set to serial then setup_console_atag is
+ automatically set to 1. So output from Maemo kernel would go to serial port.
+
USB TTY:
Maemo kernel 2.6.28 will crash if u-boot enable usb tty. So USB TTY is
disabled.
@@ -85,20 +90,13 @@ USB TTY:
#define CONFIG_USB_TTY
-ONENAND support:
-
- ONENAND support is disabled because not working yet and cause linux kernel to
- crash or no access to mtd. For enabling ONENAND support add this line at begin
- of file include/configs/nokia_rx51.h
-
- #define ONENAND_SUPPORT
-
-
UBIFS support:
UBIFS support is disabled, because U-Boot image is too big and cannot be
flashed with attached zImage to RX-51 kernel nand area. For enabling UBIFS
- support first enable ONENAND support and then add this line at begin of file
- include/configs/nokia_rx51.h
+ support add following lines into file configs/nokia_rx51_defconfig
- #define UBIFS_SUPPORT
+ CONFIG_CMD_UBI=y
+ CONFIG_CMD_UBIFS=y
+ CONFIG_MTD_UBI_FASTMAP=y
+ CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT=1
--
2.20.1
[PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu
This patch contains a script which automatically download and compile all
needed tools to build a simple MTD images for booting Maemo kernel image by
U-Boot from RAM, eMMC and OneNAND. MTD images are then run in virtual n900
machine provided by qemu-linaro project.
It can be used to check that U-Boot for Nokia N900 is not broken and can be
successfully booted in emulator.
Script is registered in to .travis.yml so it would be automatically run on
Travi CI service.
Signed-off-by: Pali Rohár
---
.travis.yml | 10 +++
test/rx51_test.sh | 208 ++
2 files changed, 218 insertions(+)
create mode 100755 test/rx51_test.sh
diff --git a/.travis.yml b/.travis.yml
index c59bd7790b..d96811473c 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -40,6 +40,8 @@ addons:
- clang-7
- srecord
- graphviz
+- mtools
+- mtd-utils
install:
# Clone uboot-test-hooks
@@ -116,6 +118,11 @@ script:
# Comments must be outside the command strings below, or the Travis parser
# will get confused.
#
+ # Run tests for Nokia RX-51 (aka N900)
+ - if [[ -n "${NOKIA_RX51}" ]]; then
+ test/rx51_test.sh
+ exit $?;
+ fi
# From buildman, exit code 129 means warnings only. If we've been asked to
# use clang only do one configuration.
- if [[ "${BUILDMAN}" != "" ]]; then
@@ -160,6 +167,9 @@ matrix:
include:
# we need to build by vendor due to 50min time limit for builds
# each env setting here is a dedicated build
+- name: "nokia rx51"
+ env:
+- NOKIA_RX51=1
- name: "buildman arc"
env:
- BUILDMAN="arc"
diff --git a/test/rx51_test.sh b/test/rx51_test.sh
new file mode 100755
index 00..43ecc07c08
--- /dev/null
+++ b/test/rx51_test.sh
@@ -0,0 +1,208 @@
+#!/bin/sh -e
+# SPDX-License-Identifier: GPL-2.0+
+# (C) 2020 Pali Rohár
+
+# This test script depends on external tools:
+# wget git truncate tar dpkg dd mcopy (from mtools) mkfs.ubifs (from
mtd-utils) ubinize (from mtd-utils)
+
+# Download and compile linaro version qemu which has support for n900 machine
+# Last working commit is 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1
+if ! test -f qemu-system-arm; then
+ test -d qemu-linaro || git clone
https://git.linaro.org/qemu/qemu-linaro.git
+ cd qemu-linaro
+ git checkout 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1
+ ./configure --enable-system --target-list=arm-softmmu --disable-sdl
--disable-gtk --disable-curses --audio-drv-list=pa,alsa --audio-card-list=
--disable-werror --disable-xen --disable-xen-pci-passthrough --disable-brlapi
--disable-vnc --disable-curl --disable-slirp --disable-kvm --disable-user
--disable-linux-user --disable-bsd-user --disable-guest-base --disable-uuid
--disable-vde --disable-linux-aio --disable-cap-ng --disable-attr
--disable-blobs --disable-docs --disable-spice --disable-libiscsi
--disable-smartcard-nss --disable-usb-redir --disable-guest-agent
--disable-seccomp --disable-glusterfs --disable-nptl --disable-fdt
+ make -j4
+ cd ..
+ ln -s qemu-linaro/arm-softmmu/qemu-system-arm .
+fi
+
+# Download and compile dosfstools with mbr support
+# Currently this support is in open pull request 95
+if ! test -f mkfs.fat; then
+ test -d dosfstools || git clone
https://github.com/dosfstools/dosfstools.git
+ cd dosfstools
+ git fetch origin refs/pull/95/head
+ git checkout FETCH_HEAD
+ ./autogen.sh
+ ./configure
+ make -j4
+ cd ..
+ ln -s dosfstools/src/mkfs.fat .
+fi
+
+# Download qflasher and nolo images
+# This is proprietary qemu flasher tool with first stage images, but license
allows non-commercial redistribution
+wget -c http://repository.maemo.org/qemu-n900/qemu-n900.tar.gz
+tar -xf qemu-n900.tar.gz
+
+# Download Maemo script u-boot-gen-combined
+if ! test -f u-boot-gen-combined; then
+ test -d u-boot-maemo || git clone
https://github.com/pali/u-boot-maemo.git
+ chmod +x u-boot-maemo/debian/u-boot-gen-combined
+ ln -s u-boot-maemo/debian/u-boot-gen-combined .
+fi
+
+# Download Maemo fiasco kernel
+wget -c
http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb
+dpkg -x kernel_2.6.28-20103103+0m5_armel.deb kernel_2.6.28
+
+# Download Maemo libc
+wget -c
http://repository.maemo.org/pool/maemo5.0/free/g/glibc/libc6_2.5.1-1eglibc27+0m5_armel.deb
+dpkg -x libc6_2.5.1-1eglibc27+0m5_armel.deb libc6_2.5.1
+
+# Download Maemo busybox
+wget -c
http://repository.maemo.org/pool/maemo5.0/free/b/busybox/busybox_1.10.2.legal-1osso30+0m5_armel.deb
+dpkg -x busybox_1.10.2.legal-1osso30+0m5_armel.deb busybox_1.10.2
+
+# Generate rootfs directory
+# WARNING: there is "sudo mknod" call for /dev/console
+mkdir -p rootfs
+mkdir -p rootfs/dev/
+mkdir -p rootfs/bin/
+mkdir -p rootfs/sbin/
+mkdir -p rootfs/lib/
+test -c rootfs/dev/console || sudo mknod rootfs/dev/console c 5 1
+cp -a busybox_1.10.2/bin/busybox rootfs/bin/
+cp -a
[PATCH 01/11] Nokia RX-51: Update my email address
I'm using a new email address, so reflect this state also in U-Boot.
Signed-off-by: Pali Rohár
---
board/nokia/rx51/MAINTAINERS | 2 +-
board/nokia/rx51/lowlevel_init.S | 2 +-
board/nokia/rx51/rx51.c | 2 +-
board/nokia/rx51/rx51.h | 2 +-
board/nokia/rx51/tag_omap.h | 4 ++--
cmd/bootmenu.c | 2 +-
doc/README.bootmenu | 2 +-
include/ansi.h | 2 +-
include/configs/nokia_rx51.h | 2 +-
9 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/board/nokia/rx51/MAINTAINERS b/board/nokia/rx51/MAINTAINERS
index 8bdddc1d83..4cf3dcce2e 100644
--- a/board/nokia/rx51/MAINTAINERS
+++ b/board/nokia/rx51/MAINTAINERS
@@ -1,5 +1,5 @@
RX51 BOARD
-M: Pali Rohár
+M: Pali Rohár
S: Maintained
F: board/nokia/rx51/
F: include/configs/nokia_rx51.h
diff --git a/board/nokia/rx51/lowlevel_init.S b/board/nokia/rx51/lowlevel_init.S
index 6871a5a74f..7b1e50d9bc 100644
--- a/board/nokia/rx51/lowlevel_init.S
+++ b/board/nokia/rx51/lowlevel_init.S
@@ -1,7 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
* (C) Copyright 2011-2012
- * Pali Rohár
+ * Pali Rohár
*/
#include
diff --git a/board/nokia/rx51/rx51.c b/board/nokia/rx51/rx51.c
index 71ca79deab..80a0fc2696 100644
--- a/board/nokia/rx51/rx51.c
+++ b/board/nokia/rx51/rx51.c
@@ -4,7 +4,7 @@
* Ивайло Димитров
*
* (C) Copyright 2011-2012
- * Pali Rohár
+ * Pali Rohár
*
* (C) Copyright 2010
* Alistair Buxton
diff --git a/board/nokia/rx51/rx51.h b/board/nokia/rx51/rx51.h
index fc336ee819..fa1b42bf21 100644
--- a/board/nokia/rx51/rx51.h
+++ b/board/nokia/rx51/rx51.h
@@ -4,7 +4,7 @@
* Ивайло Димитров
*
* (C) Copyright 2011-2012
- * Pali Rohár
+ * Pali Rohár
*
* (C) Copyright 2008
* Dirk Behme
diff --git a/board/nokia/rx51/tag_omap.h b/board/nokia/rx51/tag_omap.h
index c445aafde0..b99d6b7de1 100644
--- a/board/nokia/rx51/tag_omap.h
+++ b/board/nokia/rx51/tag_omap.h
@@ -1,7 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
* (C) Copyright 2011-2012
- * Pali Rohár
+ * Pali Rohár
*
* (C) Copyright 2011
* mar...@mesa.nl, Mesa Consulting B.V.
@@ -182,7 +182,7 @@ struct omap_em_asic_bb5_config {
* processing omap tag structures
*
* Copyright (C) 2011 mar...@mesa.nl, Mesa Consulting B.V.
- * Copyright (C) 2012 Pali Rohár
+ * Copyright (C) 2012 Pali Rohár
*/
/* TI OMAP specific information */
diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index 3dc2c854ac..2f20bb88f3 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * (C) Copyright 2011-2013 Pali Rohár
+ * (C) Copyright 2011-2013 Pali Rohár
*/
#include
diff --git a/doc/README.bootmenu b/doc/README.bootmenu
index ca5099089e..9ff89f2e55 100644
--- a/doc/README.bootmenu
+++ b/doc/README.bootmenu
@@ -1,6 +1,6 @@
SPDX-License-Identifier: GPL-2.0+
/*
- * (C) Copyright 2011-2012 Pali Rohár
+ * (C) Copyright 2011-2012 Pali Rohár
*/
ANSI terminal bootmenu command
diff --git a/include/ansi.h b/include/ansi.h
index e90a697eaf..af1a3712c8 100644
--- a/include/ansi.h
+++ b/include/ansi.h
@@ -1,7 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
* (C) Copyright 2012
- * Pali Rohár
+ * Pali Rohár
*/
/*
diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h
index fd755bbcea..d2cafb0a8b 100644
--- a/include/configs/nokia_rx51.h
+++ b/include/configs/nokia_rx51.h
@@ -1,7 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
* (C) Copyright 2011-2012
- * Pali Rohár
+ * Pali Rohár
*
* (C) Copyright 2010
* Alistair Buxton
--
2.20.1
[PATCH 09/11] Nokia RX-51: Disable some unused features to decrease size of u-boot binary
Maximal allowed size of U-Boot binary for Nokia N900 is just 262144 bytes. Signed-off-by: Pali Rohár --- configs/nokia_rx51_defconfig | 16 1 file changed, 16 insertions(+) diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig index fc92c3affc..41722725e6 100644 --- a/configs/nokia_rx51_defconfig +++ b/configs/nokia_rx51_defconfig @@ -26,6 +26,7 @@ CONFIG_CMD_FAT=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y # CONFIG_NET is not set CONFIG_TWL4030_LED=y +# CONFIG_MMC_HW_PARTITIONING is not set CONFIG_MMC_OMAP_HS=y CONFIG_CONS_INDEX=3 CONFIG_SYS_NS16550=y @@ -46,3 +47,18 @@ CONFIG_MTD_PARTITIONS=y # CONFIG_MTD_RAW_NAND is not set CONFIG_CMD_MTD=y CONFIG_CMD_ONENAND=y +# CONFIG_BOOTM_NETBSD is not set +# CONFIG_BOOTM_PLAN9 is not set +# CONFIG_BOOTM_RTEMS is not set +# CONFIG_BOOTM_VXWORKS is not set +# CONFIG_GZIP is not set +# CONFIG_FIT is not set +# CONFIG_CMD_ELF is not set +# CONFIG_CMD_BDI is not set +# CONFIG_CMD_BOOTD is not set +# CONFIG_CMD_XIMG is not set +# CONFIG_CMD_EXPORTENV is not set +# CONFIG_CMD_IMPORTENV is not set +# CONFIG_CMD_EDITENV is not set +# CONFIG_CMD_ENV_EXISTS is not set +# CONFIG_CMD_FLASH is not set -- 2.20.1
[PATCH 06/11] Nokia RX-51: Remove PART* macros
Now when code for defining partitions is duplicated at two locations
(option CONFIG_MTDPARTS_DEFAULT in nokia_rx51_defconfig file and macro
OMAP_TAG_PARTITION_CONFIG in rx51.c file) there is no need to have common
macros. Lets inline PART* macros to rx51.c file.
Signed-off-by: Pali Rohár
---
board/nokia/rx51/rx51.c | 18 ++--
include/configs/nokia_rx51.h | 42
2 files changed, 6 insertions(+), 54 deletions(-)
diff --git a/board/nokia/rx51/rx51.c b/board/nokia/rx51/rx51.c
index 80a0fc2696..c8ef26f940 100644
--- a/board/nokia/rx51/rx51.c
+++ b/board/nokia/rx51/rx51.c
@@ -69,18 +69,12 @@ static struct tag_omap omap[] = {
OMAP_TAG_GPIO_SWITCH_CONFIG("sleep_ind", 0xa2, 0x2, 0x2, 0x0),
OMAP_TAG_GPIO_SWITCH_CONFIG("slide", GPIO_SLIDE, 0x0, 0x0, 0x0),
OMAP_TAG_WLAN_CX3110X_CONFIG(0x25, 0xff, 87, 42, -1),
- OMAP_TAG_PARTITION_CONFIG(PART1_NAME, PART1_SIZE * PART1_MULL,
- PART1_OFFS, PART1_MASK),
- OMAP_TAG_PARTITION_CONFIG(PART2_NAME, PART2_SIZE * PART2_MULL,
- PART2_OFFS, PART2_MASK),
- OMAP_TAG_PARTITION_CONFIG(PART3_NAME, PART3_SIZE * PART3_MULL,
- PART3_OFFS, PART3_MASK),
- OMAP_TAG_PARTITION_CONFIG(PART4_NAME, PART4_SIZE * PART4_MULL,
- PART4_OFFS, PART4_MASK),
- OMAP_TAG_PARTITION_CONFIG(PART5_NAME, PART5_SIZE * PART5_MULL,
- PART5_OFFS, PART5_MASK),
- OMAP_TAG_PARTITION_CONFIG(PART6_NAME, PART6_SIZE * PART6_MULL,
- PART6_OFFS, PART6_MASK),
+ OMAP_TAG_PARTITION_CONFIG("bootloader", 128 * 1024, 0x,
0x0003),
+ OMAP_TAG_PARTITION_CONFIG("config", 384 * 1024, 0x0002, 0x),
+ OMAP_TAG_PARTITION_CONFIG("log", 256 * 1024, 0x0008, 0x),
+ OMAP_TAG_PARTITION_CONFIG("kernel", 2 * 1024*1024, 0x000c,
0x),
+ OMAP_TAG_PARTITION_CONFIG("initfs", 2 * 1024*1024, 0x002c,
0x),
+ OMAP_TAG_PARTITION_CONFIG("rootfs", 257280 * 1024, 0x004c,
0x),
OMAP_TAG_BOOT_REASON_CONFIG("pwr_key"),
OMAP_TAG_VERSION_STR_CONFIG("product", "RX-51"),
OMAP_TAG_VERSION_STR_CONFIG("hw-build", "2101"),
diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h
index cfc4d0c1e5..a33b0a7ac8 100644
--- a/include/configs/nokia_rx51.h
+++ b/include/configs/nokia_rx51.h
@@ -91,48 +91,6 @@
* Board ONENAND Info.
*/
-#define PART1_NAME "bootloader"
-#define PART1_SIZE 128
-#define PART1_MULL 1024
-#define PART1_SUFF "k"
-#define PART1_OFFS 0x
-#define PART1_MASK 0x0003
-
-#define PART2_NAME "config"
-#define PART2_SIZE 384
-#define PART2_MULL 1024
-#define PART2_SUFF "k"
-#define PART2_OFFS 0x0002
-#define PART2_MASK 0x
-
-#define PART3_NAME "log"
-#define PART3_SIZE 256
-#define PART3_MULL 1024
-#define PART3_SUFF "k"
-#define PART3_OFFS 0x0008
-#define PART3_MASK 0x
-
-#define PART4_NAME "kernel"
-#define PART4_SIZE 2
-#define PART4_MULL 1024*1024
-#define PART4_SUFF "m"
-#define PART4_OFFS 0x000c
-#define PART4_MASK 0x
-
-#define PART5_NAME "initfs"
-#define PART5_SIZE 2
-#define PART5_MULL 1024*1024
-#define PART5_SUFF "m"
-#define PART5_OFFS 0x002c
-#define PART5_MASK 0x
-
-#define PART6_NAME "rootfs"
-#define PART6_SIZE 257280
-#define PART6_MULL 1024
-#define PART6_SUFF "k"
-#define PART6_OFFS 0x004c
-#define PART6_MASK 0x
-
#define CONFIG_SYS_ONENAND_BASEONENAND_MAP
/* Watchdog support */
--
2.20.1
[PATCH 08/11] Nokia RX-51: Enable CONFIG_CONSOLE_MUX
After this change both device display and serial console would contain
U-Boto output automatically without any future configuration. This would
allow easier debugging on real device as access to serial console is hard
and also in qemu emulator where it is easier to copy+paste from serial
console as from SDL framebuffer.
Signed-off-by: Pali Rohár
---
configs/nokia_rx51_defconfig | 2 +-
include/configs/nokia_rx51.h | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
index 13bb6d07b7..fc92c3affc 100644
--- a/configs/nokia_rx51_defconfig
+++ b/configs/nokia_rx51_defconfig
@@ -7,7 +7,7 @@ CONFIG_NR_DRAM_BANKS=2
CONFIG_BOOTDELAY=30
CONFIG_USE_PREBOOT=y
CONFIG_PREBOOT="run preboot"
-# CONFIG_CONSOLE_MUX is not set
+CONFIG_CONSOLE_MUX=y
CONFIG_SYS_CONSOLE_IS_IN_ENV=y
CONFIG_HUSH_PARSER=y
CONFIG_SYS_PROMPT="Nokia RX-51 # "
diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h
index a33b0a7ac8..4014dca54c 100644
--- a/include/configs/nokia_rx51.h
+++ b/include/configs/nokia_rx51.h
@@ -119,9 +119,9 @@ int rx51_kp_getc(struct stdio_dev *sdev);
/* Environment information */
#define CONFIG_EXTRA_ENV_SETTINGS \
"usbtty=cdc_acm\0" \
- "stdin=vga\0" \
- "stdout=vga\0" \
- "stderr=vga\0" \
+ "stdin=serial,vga\0" \
+ "stdout=serial,vga\0" \
+ "stderr=serial,vga\0" \
"setcon=setenv stdin ${con};" \
"setenv stdout ${con};" \
"setenv stderr ${con}\0" \
--
2.20.1
[PATCH 05/11] Nokia RX-51: Revert back onenand defitions
In commit commit 43ede0bca7fc ("Kconfig: Migrate MTDIDS_DEFAULT /
MTDPARTS_DEFAULT") were removed definitions for onenand partitions.
Revert them back and enable needed options for onenand support.
Signed-off-by: Pali Rohár
---
configs/nokia_rx51_defconfig | 7 +++
include/configs/nokia_rx51.h | 10 --
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
index 5ba9768d02..13bb6d07b7 100644
--- a/configs/nokia_rx51_defconfig
+++ b/configs/nokia_rx51_defconfig
@@ -39,3 +39,10 @@ CONFIG_TWL4030_USB=y
CONFIG_VIDEO=y
CONFIG_CFB_CONSOLE_ANSI=y
# CONFIG_VGA_AS_SINGLE_DEVICE is not set
+CONFIG_MTD=y
+CONFIG_MTDIDS_DEFAULT="onenand0=onenand"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=onenand:128k(bootloader)ro,384k(config),256k(log),2m(kernel),2m(initfs),-(rootfs)"
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_RAW_NAND is not set
+CONFIG_CMD_MTD=y
+CONFIG_CMD_ONENAND=y
diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h
index 57bcbbaae1..cfc4d0c1e5 100644
--- a/include/configs/nokia_rx51.h
+++ b/include/configs/nokia_rx51.h
@@ -133,12 +133,8 @@
#define PART6_OFFS 0x004c
#define PART6_MASK 0x
-#ifdef ONENAND_SUPPORT
-
#define CONFIG_SYS_ONENAND_BASEONENAND_MAP
-#endif
-
/* Watchdog support */
#define CONFIG_HW_WATCHDOG
@@ -163,13 +159,7 @@ int rx51_kp_getc(struct stdio_dev *sdev);
#endif
/* Environment information */
-#ifdef CONFIG_MTDPARTS_DEFAULT
-#define MTDPARTS "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0"
-#else
-#define MTDPARTS
-#endif
#define CONFIG_EXTRA_ENV_SETTINGS \
- MTDPARTS \
"usbtty=cdc_acm\0" \
"stdin=vga\0" \
"stdout=vga\0" \
--
2.20.1
[PATCH 04/11] Nokia RX-51: Move code from defconfig back to C header file
In commit commit 37304aaf60bf ("Convert CONFIG_USE_PREBOOT and
CONFIG_PREBOOT to Kconfig") was moved complicated multiline script code
from C header to oneliner in defconfig. After this change multiline to wide
oneliner it is hard to read this code and even harder to debug. Moreover
this script code should be at place where are other scripts, so move it
back to C header file.
Define new env variable preboot which stores this script and in option
CONFIG_PREBOOT calls this preboot variable.
Signed-off-by: Pali Rohár
---
configs/nokia_rx51_defconfig | 2 +-
include/configs/nokia_rx51.h | 22 ++
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig
index f9e5b0e123..5ba9768d02 100644
--- a/configs/nokia_rx51_defconfig
+++ b/configs/nokia_rx51_defconfig
@@ -6,7 +6,7 @@ CONFIG_TARGET_NOKIA_RX51=y
CONFIG_NR_DRAM_BANKS=2
CONFIG_BOOTDELAY=30
CONFIG_USE_PREBOOT=y
-CONFIG_PREBOOT="setenv mmcnum 1; setenv mmcpart 1;setenv mmcscriptfile
bootmenu.scr;if run switchmmc; then setenv mmcdone true;setenv mmctype fat;if
run scriptload; then true; else setenv mmctype ext2;if run scriptload; then
true; else setenv mmctype ext4;if run scriptload; then true; else setenv
mmcdone false;fi;fi;fi;if ${mmcdone}; then run scriptboot;fi;fi;if run slide;
then true; else setenv bootmenu_delay 0;setenv bootdelay 0;fi"
+CONFIG_PREBOOT="run preboot"
# CONFIG_CONSOLE_MUX is not set
CONFIG_SYS_CONSOLE_IS_IN_ENV=y
CONFIG_HUSH_PARSER=y
diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h
index 858951ccf2..57bcbbaae1 100644
--- a/include/configs/nokia_rx51.h
+++ b/include/configs/nokia_rx51.h
@@ -239,6 +239,28 @@ int rx51_kp_getc(struct stdio_dev *sdev);
"fi\0" \
"emmcboot=setenv mmcnum 1; run trymmcboot\0" \
"sdboot=setenv mmcnum 0; run trymmcboot\0" \
+ "preboot=setenv mmcnum 1; setenv mmcpart 1;" \
+ "setenv mmcscriptfile bootmenu.scr;" \
+ "if run switchmmc; then " \
+ "setenv mmcdone true;" \
+ "setenv mmctype fat;" \
+ "if run scriptload; then true; else " \
+ "setenv mmctype ext2;" \
+ "if run scriptload; then true; else " \
+ "setenv mmctype ext4;" \
+ "if run scriptload; then true; else " \
+ "setenv mmcdone false;" \
+ "fi;" \
+ "fi;" \
+ "fi;" \
+ "if ${mmcdone}; then " \
+ "run scriptboot;" \
+ "fi;" \
+ "fi;" \
+ "if run slide; then true; else " \
+ "setenv bootmenu_delay 0;" \
+ "setenv bootdelay 0;" \
+ "fi\0" \
"menucmd=bootmenu\0" \
"bootmenu_0=Attached kernel=run attachboot\0" \
"bootmenu_1=Internal eMMC=run emmcboot\0" \
--
2.20.1
[PATCH 03/11] Nokia RX-51: Move comment about CONFIG_SYS_TEXT_BASE to correct place
In commit commit 278b90ce786f ("configs: Migrate CONFIG_SYS_TEXT_BASE") was
moved definition for CONFIG_SYS_TEXT_BASE option but author probably forgot
to move also comment for lines which are moving. So do it now!
Signed-off-by: Pali Rohár
---
board/nokia/rx51/lowlevel_init.S | 9 -
include/configs/nokia_rx51.h | 6 --
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/board/nokia/rx51/lowlevel_init.S b/board/nokia/rx51/lowlevel_init.S
index 7b1e50d9bc..1466d976fc 100644
--- a/board/nokia/rx51/lowlevel_init.S
+++ b/board/nokia/rx51/lowlevel_init.S
@@ -155,7 +155,14 @@ copy_code_end:
mov pc, r2
-/* Copy u-boot to address CONFIG_SYS_TEXT_BASE */
+/*
+ * Copy u-boot to address CONFIG_SYS_TEXT_BASE
+ *
+ * Nokia X-Loader loading secondary image to address 0x8040
+ * NOLO loading boot image to random place, so it doesn't really
+ * matter what is set in CONFIG_SYS_TEXT_BASE. We have to copy
+ * u-boot to CONFIG_SYS_TEXT_BASE address.
+ */
copy_uboot_start:
/* r0 - start of u-boot before */
diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h
index d2cafb0a8b..858951ccf2 100644
--- a/include/configs/nokia_rx51.h
+++ b/include/configs/nokia_rx51.h
@@ -25,12 +25,6 @@
#define CONFIG_MACH_TYPE MACH_TYPE_NOKIA_RX51
-/*
- * Nokia X-Loader loading secondary image to address 0x8040
- * NOLO loading boot image to random place, so it doesn't really
- * matter what we set this to. We have to copy u-boot to this address
- */
-
#include /* get chip and board defs */
#include
#include
--
2.20.1
[PATCH 07/11] Nokia RX-51: Remember setup_console_atag option
When variable setup_console_atag is unset then read default value from OMAP
atags which passed NOLO bootloader to U-Boot.
This would allow to boot Maemo Linux kernel from U-Boot with serial console
settings configured in NOLO bootloader (which loads U-Boot).
So serial console needs to be enabled only at one place, globally in NOLO.
Signed-off-by: Pali Rohár
---
board/nokia/rx51/rx51.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/board/nokia/rx51/rx51.c b/board/nokia/rx51/rx51.c
index c8ef26f940..a282fe68a6 100644
--- a/board/nokia/rx51/rx51.c
+++ b/board/nokia/rx51/rx51.c
@@ -87,6 +87,7 @@ static char *boot_reason_ptr;
static char *hw_build_ptr;
static char *nolo_version_ptr;
static char *boot_mode_ptr;
+static int serial_was_console_enabled;
/*
* Routine: init_omap_tags
@@ -143,6 +144,13 @@ static void reuse_omap_atags(struct tag_omap *t)
strcpy(boot_mode_ptr, version);
}
break;
+ case OMAP_TAG_UART:
+ if (!t->u.uart.enabled_uarts)
+ serial_was_console_enabled = 1;
+ break;
+ case OMAP_TAG_SERIAL_CONSOLE:
+ serial_was_console_enabled = 1;
+ break;
default:
break;
}
@@ -233,10 +241,17 @@ void setup_board_tags(struct tag **in_params)
return;
str = env_get("setup_console_atag");
- if (str && str[0] == '1')
- setup_console_atag = 1;
- else
- setup_console_atag = 0;
+ if (str && str[0]) {
+ if (str[0] == '1')
+ setup_console_atag = 1;
+ else
+ setup_console_atag = 0;
+ } else {
+ if (serial_was_console_enabled)
+ setup_console_atag = 1;
+ else
+ setup_console_atag = 0;
+ }
setup_boot_reason_atag = env_get("setup_boot_reason_atag");
setup_boot_mode_atag = env_get("setup_boot_mode_atag");
--
2.20.1
[PATCH 02/11] Nokia RX-51: Add README.nokia_rx51 file to MAINTAINERS
This entry was missing in MAINTAINERS file. Signed-off-by: Pali Rohár --- board/nokia/rx51/MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/board/nokia/rx51/MAINTAINERS b/board/nokia/rx51/MAINTAINERS index 4cf3dcce2e..f2a712620b 100644 --- a/board/nokia/rx51/MAINTAINERS +++ b/board/nokia/rx51/MAINTAINERS @@ -4,3 +4,4 @@ S: Maintained F: board/nokia/rx51/ F: include/configs/nokia_rx51.h F: configs/nokia_rx51_defconfig +F: doc/README.nokia_rx51 -- 2.20.1
[PATCH 00/11] Fixes for Nokia RX-51
This patch series contain fixes for Nokia RX-51 board (aka N900). After these changes it is possible to run U-Boot in qemu emulator again. And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without problem. Pali Rohár (11): Nokia RX-51: Update my email address Nokia RX-51: Add README.nokia_rx51 file to MAINTAINERS Nokia RX-51: Move comment about CONFIG_SYS_TEXT_BASE to correct place Nokia RX-51: Move code from defconfig back to C header file Nokia RX-51: Revert back onenand defitions Nokia RX-51: Remove PART* macros Nokia RX-51: Remember setup_console_atag option Nokia RX-51: Enable CONFIG_CONSOLE_MUX Nokia RX-51: Disable some unused features to decrease size of u-boot binary Nokia RX-51: Update README.nokia_rx51 Nokia RX-51: Add automated test for running RX-51 build in qemu .travis.yml | 10 ++ board/nokia/rx51/MAINTAINERS | 3 +- board/nokia/rx51/lowlevel_init.S | 11 +- board/nokia/rx51/rx51.c | 43 --- board/nokia/rx51/rx51.h | 2 +- board/nokia/rx51/tag_omap.h | 4 +- cmd/bootmenu.c | 2 +- configs/nokia_rx51_defconfig | 27 +++- doc/README.bootmenu | 2 +- doc/README.nokia_rx51| 32 +++-- include/ansi.h | 2 +- include/configs/nokia_rx51.h | 88 - test/rx51_test.sh| 208 +++ 13 files changed, 327 insertions(+), 107 deletions(-) create mode 100755 test/rx51_test.sh -- 2.20.1
buildman summary quesiton
I start off with the following build: $ buildman -o arm926ejs and it tells me that there are 137 boards to build. At the end I can see: 23 1140 /137 Now I want a summary: $ buildman -o arm926ejs -s but all it prints out are the 114 boards that had warnings. Is there not a way to get "buildman -s" to also print the list of the 23 boards that succeeded?
Antwort: [PATCH v3 20/29] acpi: Add support for DMAR
Hi Simon, -"Simon Glass" schrieb: - >Betreff: [PATCH v3 20/29] acpi: Add support for DMAR > >The DMA Remapping Reporting (DMAR) table contains information about >DMA >remapping. > >Add a version simple version of this table with only the minimum >fields >filled out. i.e. no entries. > >Reviewed-by: Bin Meng >Signed-off-by: Simon Glass >--- > >Changes in v3: >- Add missing error check in acpi_create_dmar() >- Drop duplicate assert >- Fix DMA_ typo >- Make use of BIT() > >Changes in v2: >- Drop two unnecessary __packed >- Move __packed to after struct > > include/acpi/acpi_table.h | 57 >+++ > lib/acpi/acpi_table.c | 28 +++ > test/dm/acpi.c| 13 + > 3 files changed, 98 insertions(+) Reviewed-by: Wolfgang Wallner
Antwort: [PATCH v3 19/29] acpi: Add a central location for table version numbers
Hi Simon,
-"Simon Glass" schrieb: -
>Betreff: [PATCH v3 19/29] acpi: Add a central location for table
>version numbers
>
>Each ACPI table has its own version number. Add the version numbers
>in a
>single function so we can keep them consistent and easily see what
>versions are supported.
>
>Start a new acpi_table file in a generic directory to house this
>function.
>We can move things over to this file from x86 as needed.
>
>Signed-off-by: Simon Glass
>---
>
>Changes in v3:
>- Fix a few typos
>- Fix file comment for acpi_table.c
>
>Changes in v2:
>- Move the sandbox acpi_table.h header file to an earlier patch
>- Use #defines for MADT and MCFG version numbers
>
> include/acpi/acpi_table.h | 61
>+++
> lib/Makefile | 1 +
> lib/acpi/Makefile | 4 +++
> lib/acpi/acpi_table.c | 60
>++
> test/dm/acpi.c| 14 +
> 5 files changed, 140 insertions(+)
> create mode 100644 lib/acpi/Makefile
> create mode 100644 lib/acpi/acpi_table.c
>
>diff --git a/include/acpi/acpi_table.h b/include/acpi/acpi_table.h
>index dd748958136..ccf6fa04dbe 100644
>--- a/include/acpi/acpi_table.h
>+++ b/include/acpi/acpi_table.h
>@@ -202,6 +202,26 @@ struct __packed acpi_fadt {
> struct acpi_gen_regaddr x_gpe1_blk;
> };
>
[snip]
> #include
>diff --git a/lib/Makefile b/lib/Makefile
>index 15259d0473c..f737eb559fc 100644
>--- a/lib/Makefile
>+++ b/lib/Makefile
>@@ -5,6 +5,7 @@
>
> ifndef CONFIG_SPL_BUILD
>
>+obj-$(CONFIG_$(SPL_)ACPIGEN) += acpi/
Could you please help me understand why $(SPL_) is used here?
You have mentioned in your answer of the v2 patch explicitly that you should
use $SPL_ here and have changed the patch accordingly in v3, so I trust that
it makes sense. But I fail to understand how this works. The newly added line
is within "ifndef CONFIG_SPL_BUILD", in which case $SPL_ should alwys be empty
anyway. At least that is how I understood the assigment to SPL_ in Makefile.spl.
> obj-$(CONFIG_EFI) += efi/
> obj-$(CONFIG_EFI_LOADER) += efi_driver/
> obj-$(CONFIG_EFI_LOADER) += efi_loader/
[snip]
Reviewed-by: Wolfgang Wallner
Antwort: [PATCH v3 13/29] dts: Add a binding for hid-over-i2c
Hi Simon,
-"Simon Glass" schrieb: -
>An: u-boot@lists.denx.de
>Von: "Simon Glass"
>Datum: 31.03.2020 01:14
>Kopie: "Andy Shevchenko" ,
>"Wolfgang Wallner" , "Leif
>Lindholm" , "Simon Glass"
>Betreff: [PATCH v3 14/29] acpi: Add a binding for ACPI settings in
>the device tree
>
> Devices need to report various identifiers in the ACPI tables. Rather than
> hard-coding these in drivers it is typically better to put them in the
> device tree.
>
> Add a binding file to describe this.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v3:
> - Add a pointer to information about acpi,compatible
> - Change the example to ELAN
> - Correct description of acpi,probed
> - Drop hid-descr-addr
> - Drop mention of PRIC
I understand now where the term "PRIC" came from.
The property "acpi,has-power-resource" triggers the function
acpi_device_add_power_res(), which writes a PowerResource ('PowerResource'
as specified in section 7.2 of ACPI 6.3). This function comes from Coreboot,
and that implementation uses "PRIC" as the hardcoded device name. That's it,
it is an arbitrary chosen device name (probably meaning "power IC" ... ?).
Anyway, dropping the term "PRIC" makes the description easier to understand.
The important information is that "acpi,has-power-resource" leads to the
addition of a PowerResource entry.
> - Just add the device.txt binding file in this patch
> - Rename acpi,desc to acpi,ddn
>
> Changes in v2:
> - Add the hid-over-i2c binding document
> - Fix definition of HID
> - Infer hid-over-i2c CID value
>
> doc/device-tree-bindings/device.txt | 37 +
> 1 file changed, 37 insertions(+)
> create mode 100644 doc/device-tree-bindings/device.txt
>
> diff --git a/doc/device-tree-bindings/device.txt
> b/doc/device-tree-bindings/device.txt
> new file mode 100644
> index 000..06c2b84b6d5
> --- /dev/null
> +++ b/doc/device-tree-bindings/device.txt
> @@ -0,0 +1,37 @@
> +Devices
> +===
> +
> +Device bindings are described by their own individual binding files.
> +
> +U-Boot provides for some optional properties which are documented here. See
> +also hid-over-i2c.txt which describes HID devices. See also
> +Documentation/firmware-guide/acpi/enumeration.rst in the Linux kernel for
> +the acpi,compatible property.
> +
> + - acpi,has-power-resource : (boolean) true if this device has a power
> resource.
> +This causes an ACPI PowerResource to be written containing the properties
> +provided by this binding, to describe how to handle powering the device
> up
> +and down using GPIOs
> + - acpi,compatible : compatible string to report
I still don't see a use case for a new "acpi,compatible" property.
I will take a step back, and explain my understanding of the involved pieces
and why I think adding "acpi,compatible" is of no benefit.
Summary:
As far as I understand the proposed "acpi, compatible" property, the following
would happen:
We have "acpi,compatible" in Devicetree, which results in a "compatible"-entry
in ACPI's _DSD method, which is then again interpreted as the
"compatible"-property of Devicetree. IMHO it would be strange for "compatible"
and "acpi,compatible" to be different, so we could drop "acpi,compatible" and
use the existing "compatible" instead.
The _DSD-method for "PRP0001"-devices in ACPI allows to use Devicetree
properties inside ACPI, especially it allows to re-use Devicetree's
"compatible"-property. But this is for a different use case (using Devicetree
properties inside ACPI, not add ACPI properties in Devicetree).
Detailed explanation:
1) ACPI Constraint: Devices need to have either _HID or _ADR
ACPI puts constraints on what properties a device ("device" here means a
"Device()" entry in ASL code (DSDT or SSDT)) has to have. It has to have
either an _HID or an _ADR property depending on whether it is on an
enumerable bus:
* if it is on an enumerable bus, it has to have an _ADR (address)
property (e.g. a PCI device on a PCI bus)
* if it is not on an enumerable bus, it has to have a _HID (hardware ID)
property (e.g. the GPIO controllers on the Apollo Lake SoC). The legal
values for _HID are specified and allow the type of the device to be
identified (a similar concept as the "compatible" property in devicetree)
These contraints are specified in section 6.1 of ACPI 6.3 [1].
2) ACPI's _DSD Method
The Device Specific Data (_DSD) method provides a way to provide additional
device properties to device drivers. It returns a package of "Device Data
Descriptors", each consisting of a UUID and a package in a format defined
by the provided UUID.
The details are specified in section 6.2.5 of ACPI 6.3 [1].
3) Special UUID value for _DSD: daffd814-...
The document "Device Properties UUID For _DSD" [2] specifies a special UUID
value:daffd814-6eba-4d8c-8a91-bc9bbf4aa301
When this UUID is used in the package returned by in a _DSD method,
it means the
Re: [U-Boot] Please pull last-minute fixes for ARC
On Tue, Mar 31, 2020 at 04:08:59PM +, Alexey Brodkin wrote: > Hi Tom, > > The following changes since commit 93330d4ce416208fe202e304e5a18166c57ac569: > > Prepare v2020.04-rc4 (2020-03-30 19:29:27 -0400) > > are available in the Git repository at: > > g...@gitlab.denx.de:u-boot/custodians/u-boot-arc.git > tags/arc-last-minute-fixes-for-2020.04 > > for you to fetch changes up to 45bd649511155b5b5a40851ca96036636cb95e23: > > ARC: IO: add MB for __raw_* memory accessors (2020-03-31 18:31:53 +0300) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] image-fit: Allow loading FIT image for VxWorks
On Wed, Mar 18, 2020 at 07:32:07AM -0700, Bin Meng wrote: > From: Lihua Zhao > > This adds the check against IH_OS_VXWORKS during FIT image load, > to allow loading FIT image for VxWorks. > > Signed-off-by: Lihua Zhao > Signed-off-by: Bin Meng > Reviewed-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH resend 5/5] mpc8xxx_spi: implement real ->set_speed
On Tue, Feb 11, 2020 at 03:20:25PM +, Rasmus Villemoes wrote: > Not all boards have the same CSB frequency, nor do every SPI slave > necessarily support running at 16.7 MHz. So implement ->set_speed; > that also allows using a smaller PM (i.e., 0) for slaves that do > support a higher speed. > > Based on work by Klaus H. Sørensen. > > Cc: Klaus H. Sorensen > Signed-off-by: Rasmus Villemoes Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] cmd: mmc: fix typo 'a EMMC'
On Sun, Mar 29, 2020 at 07:26:57PM +, Heinrich Schuchardt wrote: > %s/a EMMC/an eMMC/g > > Signed-off-by: Heinrich Schuchardt > Reviewed-by: Jaehoon Chung Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH resend 4/5] mpc8xxx_spi: always use 8-bit characters, don't read or write garbage
On Tue, Feb 11, 2020 at 03:20:25PM +, Rasmus Villemoes wrote: > There are a few problems with the current driver. > > First, it unconditionally reads from dout/writes to din whether or not > those pointers are NULL. So for example a simple "sf probe" ends up > writing four bytes at address 0: > > => md.l 0x0 8 > : 45454545 45454545 05050505 05050505 > 0010: 07070707 07070707 > => sf probe 0 > mpc8xxx_spi_xfer: slave spi@7000:0 dout 0FB53618 din bitlen 8 > mpc8xxx_spi_xfer: slave spi@7000:0 dout din 0FB536B8 bitlen 48 > SF: Detected s25sl032p with page size 256 Bytes, erase size 64 KiB, total 4 > MiB > => md.l 0x0 8 > : ff00 45454545 05050505 05050505 > 0010: 07070707 07070707 > > (here I've change the first debug statement to a printf, and made it > print the din/dout pointers rather than the uints they point at). > > Second, as we can also see above, it always writes a full 32 bits, > even if a smaller amount was requested. So for example > > => mw.l $loadaddr 0xaabbccdd 8 > => md.l $loadaddr 8 > 0200: aabbccdd aabbccdd aabbccdd aabbccdd > 0210: aabbccdd aabbccdd aabbccdd aabbccdd > => sf read $loadaddr 0x400 6 > device 0 offset 0x400, size 0x6 > mpc8xxx_spi_xfer: slave spi@7000:0 dout 0FB536E8 din bitlen 40 > mpc8xxx_spi_xfer: slave spi@7000:0 dout din 0200 bitlen 48 > SF: 6 bytes @ 0x400 Read: OK > => sf read 0x0210 0x400 8 > device 0 offset 0x400, size 0x8 > mpc8xxx_spi_xfer: slave spi@7000:0 dout 0FB53848 din bitlen 40 > mpc8xxx_spi_xfer: slave spi@7000:0 dout din 0210 bitlen 64 > SF: 8 bytes @ 0x400 Read: OK > => md.l $loadaddr 8 > 0200: 45454545 4545 aabbccdd aabbccddEE.. > 0210: 45454545 45454545 aabbccdd aabbccdd > > Finally, when the bitlen is 24 mod 32 (e.g. requesting to read 3 or 7 > bytes), the last three bytes and up being the wrong ones, since the > driver does a full 32 bit read and then shifts the wrong byte out: > > => mw.l $loadaddr 0xaabbccdd 4 > => md.l $loadaddr 4 > 0200: aabbccdd aabbccdd aabbccdd aabbccdd > => sf read $loadaddr 0x444 10 > device 0 offset 0x444, size 0x10 > mpc8xxx_spi_xfer: slave spi@7000:0 dout 0FB536E8 din bitlen 40 > mpc8xxx_spi_xfer: slave spi@7000:0 dout din 0200 bitlen 128 > SF: 16 bytes @ 0x444 Read: OK > => md.l $loadaddr 4 > 0200: 552d426f 6f742032 3031392e 30342d30U-Boot 2019.04-0 > => mw.l $loadaddr 0xaabbccdd 4 > => sf read $loadaddr 0x444 0xb > device 0 offset 0x444, size 0xb > mpc8xxx_spi_xfer: slave spi@7000:0 dout 0FB536E8 din bitlen 40 > mpc8xxx_spi_xfer: slave spi@7000:0 dout din 0200 bitlen 88 > SF: 11 bytes @ 0x444 Read: OK > => md.l $loadaddr 4 > 0200: 552d426f 6f742032 31392e00 aabbccddU-Boot 219.. > > Fix all of that by always using a character size of 8, and reject > transfers that are not a whole number of bytes. While it ends being > more work for the CPU, we're mostly bounded by the speed of the SPI > bus, and we avoid writing to the mode register in every loop. > > Based on work by Klaus H. Sørensen. > > Cc: Klaus H. Sorensen > Signed-off-by: Rasmus Villemoes Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] net: macb: Fix incorrect write function name when MACB_ZYNQ is enabled.
On Thu, Mar 26, 2020 at 03:01:29PM +0100, Michal Simek wrote:
> When MACB_ZYNQ is enabled there is compilation warnings
> drivers/net/macb.c: In function ‘_macb_init’:
> drivers/net/macb.h:675:33: error: ‘MACB_DMACFG’ undeclared (first use in this
> function);
> did you mean ‘MACB_MCF’?
> writel((value), (port)->regs + MACB_##reg)
> ^
>
> It has been caused by changing macros name by commit below.
>
> Fixes: 6c636514d499 ("net: macb: sync header definitions as taken from Linux")
> Signed-off-by: Michal Simek
> Acked-by: Joe Hershberger
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH resend 1/5] gpio/mpc83xx_spisel_boot.c: gpio driver for SPISEL_BOOT signal
On Tue, Feb 11, 2020 at 03:20:22PM +, Rasmus Villemoes wrote: > From: "Klaus H. Sorensen" > > Some SoCs in the mpc83xx family, e.g. mpc8309, have a dedicated spi > chip select, SPISEL_BOOT, that is used by the boot code to boot from > flash. > > This chip select will typically be used to select a SPI boot > flash. The SPISEL_BOOT signal is controlled by a single bit in the > SPI_CS register. > > Implement a gpio driver for the spi chip select register. This allows a > spi driver capable of using gpios as chip select, to bind a chip select > to SPISEL_BOOT. > > It may be a little odd to do this as a GPIO driver, since the signal > is neither GP or I, but it is quite convenient to present it to the > spi driver that way. The alternative it to teach mpc8xxx_spi to handle > the SPISEL_BOOT signal itself (that is how it's done in the linux > kernel, see commit 69b921acae8a) > > Signed-off-by: Klaus H. Sorensen > Signed-off-by: Rasmus Villemoes Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH resend 3/5] mpc8xxx_spi: put max_cs to use
On Tue, Feb 11, 2020 at 03:20:24PM +, Rasmus Villemoes wrote: > Currently, max_cs is write-only; it's just set in > mpc8xxx_spi_ofdata_to_platdata and not otherwise used. > > My mpc8309 was always resetting during an "sf probe 0". It turns out > dm_gpio_set_dir_flags() was being called with garbage, since nothing > had initialized priv->gpios[0] - our device tree used "cs-gpios" > rather than "gpios", so gpio_request_list_by_name() had returned 0. > > That would have been a lot easier to figure out if the chip select > index was sanity checked, so rename max_cs to cs_count, and reject a > xfer with a too large cs index. > > Signed-off-by: Rasmus Villemoes Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-socfpga/master
On Tue, Mar 31, 2020 at 05:24:57AM +0200, Marek Vasut wrote: > The following changes since commit 93330d4ce416208fe202e304e5a18166c57ac569: > > Prepare v2020.04-rc4 (2020-03-30 19:29:27 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-socfpga.git master > > for you to fetch changes up to df8e15af2bed62a5a93c5783ec9e32b9029bb010: > > arm: dts: agilex: Enable QSPI (2020-03-31 02:52:38 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH resend 2/5] gazerbeam: add clocks property to SPI node
On Tue, Feb 11, 2020 at 03:20:23PM +, Rasmus Villemoes wrote: > Prepare for supporting setting different speeds in mpc8xxx_spi.c. > > Signed-off-by: Rasmus Villemoes Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH resend 2/2] gpio: mpc8xxx: don't do RMW on gpdat register when setting value
On Tue, Jan 28, 2020 at 12:04:34PM +, Rasmus Villemoes wrote: > The driver correctly handles reading back the value of an output gpio > by reading from the shadow register for output, and from gpdat for > inputs. > > Unfortunately, when setting the value of some gpio, we do a RMW cycle > on the gpdat register without taking the shadow register into account, > thus accidentally setting other output gpios (at least those whose > value cannot be read back) to 0 at the same time. > > When changing a gpio from input to output, we still need to make sure > it initially has the requested value. So, the procedure is > > - update the shadow register > - compute the new gpdir register > - write the bitwise and of the shadow and new gpdir register to gpdat > - write the new gpdir register > > Signed-off-by: Rasmus Villemoes Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-sh/master
On Mon, Mar 30, 2020 at 04:59:55PM +0200, Marek Vasut wrote: > The following changes since commit 350c44dfb99017e9147ee07d37a40626bde62250: > > Merge branch '2020-03-27-master-imports' (2020-03-27 17:54:38 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-sh.git master > > for you to fetch changes up to 264398b2ec5dd5ee045939e11e14caeece4c8dde: > > ARM: rmobile: Only register ethernet on V2H Blanche if not DM_ETH > (2020-03-30 11:35:23 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH resend 1/2] gpio: mpc8xxx: don't modify gpdat when setting gpio as input
On Tue, Jan 28, 2020 at 12:04:33PM +, Rasmus Villemoes wrote: > Since some chips don't support reading back the value of output gpios > from the gpdat register, we should not do a RMW cycle (i.e., the > clrbits_be32) on the gpdat register when setting a gpio as input, as > that might accidentally change the value of some other (still > configured as output) gpio. > > The extra indirection through mpc8xxx_gpio_set_in() does not help > readability, so just fold the gpdir update into > mpc8xxx_gpio_direction_input(). > > Signed-off-by: Rasmus Villemoes Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request for UEFI sub-system for efi-2020-04-rc5
On Tue, Mar 31, 2020 at 08:20:16AM +0200, Heinrich Schuchardt wrote: > Hello Tom, > > this replaces the efi-2020-04-rc4-6 pull request. > > I have added another patch for checking OF_CONTROL as a prerequisite for > a Python test. > > Gitlab CI and Travis CI showed no problems: > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi/pipelines/2568 > https://travis-ci.org/github/xypron2/u-boot/builds/668892252 > > Best regards > > Heinrich > > > > The following changes since commit 350c44dfb99017e9147ee07d37a40626bde62250: > > Merge branch '2020-03-27-master-imports' (2020-03-27 17:54:38 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2020-04-rc5 > > for you to fetch changes up to 67357553ad59eb9b4f412412252e02868ceb16dc: > > test/py: test_efi_grub_net() requires OF_CONTROL (2020-03-30 20:27:42 > +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 29/29] acpi: Add an acpi command
On Mon, Mar 30, 2020 at 17:13:05 -0600, Simon Glass wrote:
> It is useful to dump ACPI tables in U-Boot to see what has been generated.
> Add a command to handle this.
>
> To allow the command to find the tables, add a position into the global
> data.
>
> Support subcommands to list and dump the tables.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> arch/sandbox/include/asm/global_data.h | 1 +
> arch/x86/include/asm/global_data.h | 1 +
> cmd/Kconfig| 14 ++
> cmd/Makefile | 1 +
> cmd/acpi.c | 179 +
> lib/acpi/acpi_table.c | 1 +
> test/dm/acpi.c | 73 ++
> 7 files changed, 270 insertions(+)
> create mode 100644 cmd/acpi.c
>
> diff --git a/arch/sandbox/include/asm/global_data.h
> b/arch/sandbox/include/asm/global_data.h
> index f4ce72d5660..f95ddb058a2 100644
> --- a/arch/sandbox/include/asm/global_data.h
> +++ b/arch/sandbox/include/asm/global_data.h
> @@ -13,6 +13,7 @@
> struct arch_global_data {
> uint8_t *ram_buf; /* emulated RAM buffer */
> void*text_base; /* pointer to base of text region */
> + ulong acpi_start; /* Start address of ACPI tables */
> };
>
> #include
> diff --git a/arch/x86/include/asm/global_data.h
> b/arch/x86/include/asm/global_data.h
> index f4c1839104e..4aee2f3e8c4 100644
> --- a/arch/x86/include/asm/global_data.h
> +++ b/arch/x86/include/asm/global_data.h
> @@ -123,6 +123,7 @@ struct arch_global_data {
> #ifdef CONFIG_FSP_VERSION2
> struct fsp_header *fsp_s_hdr; /* Pointer to FSP-S header */
> #endif
> + ulong acpi_start; /* Start address of ACPI tables */
> };
>
> #endif
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 6403bc45a5e..2d3bfe0ab91 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -190,6 +190,20 @@ comment "Commands"
>
> menu "Info commands"
>
> +config CMD_ACPI
> + bool "acpi"
> + default y if ACPIGEN
> + help
> + List and dump ACPI tables. ACPI (Advanced Configuration and Power
> + Interface) is used mostly on x86 for providing information to the
> + Operating System about devices in the system. The tables are set up
> + by the firmware, typically U-Boot but possibly an earlier firmware
> + module, if U-Boot is chain-loaded from something else. ACPI tables
> + can also include code, to perform hardware-specific tasks required
> + by the Operating Systems. This allows some amount of separation
> + between the firmware and OS, and is particularly useful when you
> + want to make hardware changes without the OS needing to be adjusted.
> +
> config CMD_BDI
> bool "bdinfo"
> default y
> diff --git a/cmd/Makefile b/cmd/Makefile
> index f1dd513a4b4..15a9693ed0e 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -11,6 +11,7 @@ obj-y += help.o
> obj-y += version.o
>
> # command
> +obj-$(CONFIG_CMD_ACPI) += acpi.o
> obj-$(CONFIG_CMD_AES) += aes.o
> obj-$(CONFIG_CMD_AB_SELECT) += ab_select.o
> obj-$(CONFIG_CMD_ADC) += adc.o
> diff --git a/cmd/acpi.c b/cmd/acpi.c
> new file mode 100644
> index 000..8a320435736
> --- /dev/null
> +++ b/cmd/acpi.c
> @@ -0,0 +1,179 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019 Google LLC
> + * Written by Simon Glass
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static void dump_hdr(struct acpi_table_header *hdr)
> +{
> + bool has_hdr = memcmp(hdr->signature, "FACS", ACPI_NAME_LEN);
> +
> + printf("%.*s %08lx %06x", ACPI_NAME_LEN, hdr->signature,
> +(ulong)map_to_sysmem(hdr), hdr->length);
> + if (has_hdr) {
> + printf(" (v%02d %.6s %.8s %u %.4s %d)\n", hdr->revision,
> +hdr->oem_id, hdr->oem_table_id, hdr->oem_revision,
> +hdr->aslc_id, hdr->aslc_revision);
> + } else {
> + printf("\n");
> + }
> +}
> +
> +/**
> + * find_table() - Look up an ACPI table
> + *
> + * @sig: Signature of table (4 characters, upper case)
> + * @return pointer to table header, or NULL if not found
> + */
> +struct acpi_table_header *find_table(const char *sig)
> +{
> + struct acpi_rsdp *rsdp;
> + struct acpi_rsdt *rsdt;
> + int len, i, count;
> +
> + rsdp = map_sysmem(gd->arch.acpi_start, 0);
> + if (!rsdp)
> + return NULL;
> + rsdt = map_sysmem(rsdp->rsdt_address, 0);
> + len = rsdt->header.length - sizeof(rsdt->header);
> + count = len / sizeof(u32);
> + for (i = 0; i < count; i++) {
> + struct acpi_table_header *hdr;
> +
> + hdr = map_sysmem(rsdt->entry[i], 0);
> + if (!memcmp(hdr->signature, sig, ACPI_NAME_LEN))
> +
[PATCH V3 13/14] ARM: dts: stm32: Adjust PLL4 settings on AV96
The PLL4 is supplying SDMMC12, SDMMC3 and SPDIF with 120 MHz and
FDCAN with 96 MHz. This isn't good for the SDMMC interfaces, which
can not easily divide the clock down to e.g. 50 MHz for high speed
SD and eMMC devices, so those devices end up running at 30 MHz as
that is 120 MHz / 4. Adjust the PLL4 settings such that both PLL4P
and PLL4R run at 100 MHz instead, which is easy to divide to 50MHz
for optimal operation of both SD and eMMC, SPDIF clock are not that
much slower and FDCAN is also unaffected.
Reviewed-by: Patrice Chotard
Reviewed-by: Patrick Delaunay
Signed-off-by: Marek Vasut
Cc: Manivannan Sadhasivam
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
V2: Move this patch before the split of AV96 into SoM and carrier
V3: No change
---
arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
index 2c7dc509a3..320132a01e 100644
--- a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
@@ -130,11 +130,11 @@
u-boot,dm-pre-reloc;
};
- /* VCO = 480.0 MHz => P = 120, Q = 40, R = 96 */
+ /* VCO = 600.0 MHz => P = 100, Q = 50, R = 100 */
pll4: st,pll@3 {
compatible = "st,stm32mp1-pll";
reg = <3>;
- cfg = < 1 39 3 11 4 PQR(1,1,1) >;
+ cfg = < 1 49 5 11 5 PQR(1,1,1) >;
u-boot,dm-pre-reloc;
};
};
--
2.25.1
[PATCH V3 14/14] ARM: dts: stm32: Split AV96 into DHCOR SoM and AV96 board
The AV96 is in fact an assembly of DH Electronics DHCOR SoM on top
of an AV96 reference board. Split the DTs to reflect that and make
sure to DHCOR SoM can be reused on other boards easily.
It is also highly recommended to configure the board for the DHCOM
make stm32mp15_dhcom_basic_defconfig
make DEVICE_TREE=stm32mp15xx-dhcor-avenger96
as that permits reusing the board code for the DH components, like
accessing and reading out the ethernet MAC from EEPROM.
Signed-off-by: Marek Vasut
Cc: Manivannan Sadhasivam
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
V2: No change
V3: No change
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/stm32mp157a-avenger96.dts| 421 +-
.../stm32mp15xx-dhcor-avenger96-u-boot.dtsi | 80
arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts | 211 +
...oot.dtsi => stm32mp15xx-dhcor-u-boot.dtsi} | 79 +---
arch/arm/dts/stm32mp15xx-dhcor.dtsi | 231 ++
doc/board/st/stm32mp1.rst | 8 +-
7 files changed, 535 insertions(+), 498 deletions(-)
create mode 100644 arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi
create mode 100644 arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts
rename arch/arm/dts/{stm32mp157a-avenger96-u-boot.dtsi =>
stm32mp15xx-dhcor-u-boot.dtsi} (75%)
create mode 100644 arch/arm/dts/stm32mp15xx-dhcor.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9c593b2c98..2564f790de 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -884,7 +884,8 @@ dtb-$(CONFIG_STM32MP15x) += \
stm32mp157c-dk2.dtb \
stm32mp157c-ed1.dtb \
stm32mp157c-ev1.dtb \
- stm32mp15xx-dhcom-pdk2.dtb
+ stm32mp15xx-dhcom-pdk2.dtb \
+ stm32mp15xx-dhcor-avenger96.dtb
dtb-$(CONFIG_SOC_K3_AM6) += k3-am654-base-board.dtb k3-am654-r5-base-board.dtb
dtb-$(CONFIG_SOC_K3_J721E) += k3-j721e-common-proc-board.dtb \
diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts
b/arch/arm/dts/stm32mp157a-avenger96.dts
index 97ff40144e..9c165104fb 100644
--- a/arch/arm/dts/stm32mp157a-avenger96.dts
+++ b/arch/arm/dts/stm32mp157a-avenger96.dts
@@ -4,422 +4,5 @@
* Author: Manivannan Sadhasivam
*/
-/dts-v1/;
-
-#include "stm32mp157c.dtsi"
-#include "stm32mp157xac-pinctrl.dtsi"
-#include
-#include
-
-/ {
- model = "Arrow Electronics STM32MP157A Avenger96 board";
- compatible = "arrow,stm32mp157a-avenger96", "st,stm32mp157";
-
- aliases {
- ethernet0 =
- mmc0 =
- serial0 =
- serial1 =
- spi0 =
- };
-
- chosen {
- stdout-path = "serial0:115200n8";
- };
-
- memory@c000 {
- device_type = "memory";
- reg = <0xc000 0x4000>;
- };
-
- led {
- compatible = "gpio-leds";
- led1 {
- label = "green:user1";
- gpios = < 7 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "heartbeat";
- default-state = "off";
- };
-
- led2 {
- label = "green:user2";
- gpios = < 3 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "mmc0";
- default-state = "off";
- };
-
- led3 {
- label = "green:user3";
- gpios = < 0 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "mmc1";
- default-state = "off";
- };
-
- led4 {
- label = "green:user3";
- gpios = < 1 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "none";
- default-state = "off";
- panic-indicator;
- };
-
- led5 {
- label = "yellow:wifi";
- gpios = < 3 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "phy0tx";
- default-state = "off";
- };
-
- led6 {
- label = "blue:bt";
- gpios = < 6 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "bluetooth-power";
- default-state = "off";
- };
- };
-
- sd_switch: regulator-sd_switch {
- compatible = "regulator-gpio";
- regulator-name = "sd_switch";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <290>;
- regulator-type = "voltage";
- regulator-always-on;
-
- gpios = < 5 GPIO_ACTIVE_HIGH>;
- gpios-states = <0>;
- states = <180 0x1>,
-<290 0x0>;
- };
-
- /* Enpirion EP3A8LQI U2 on the DHCOR */
- vdd_io:
[PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96
The core and vdd PMIC buck regulators were misconfigured, which caused
instability of the board and malfunction of high-speed interfaces, like
the RGMII. Configure the PMIC correctly to repair these problems. Also,
model the missing Enpirion EP53A8LQI on the DHCOR SoM as a fixed regulator.
Reviewed-by: Patrice Chotard
Signed-off-by: Marek Vasut
Cc: Manivannan Sadhasivam
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
V2: - Model the Enpirion EP53A8LQI on the DHCOR SoM as a fixed regulator
- Adjust the PMIC voltages further
V3: No change
---
arch/arm/dts/stm32mp157a-avenger96.dts | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts
b/arch/arm/dts/stm32mp157a-avenger96.dts
index 8181d1fa05..97ff40144e 100644
--- a/arch/arm/dts/stm32mp157a-avenger96.dts
+++ b/arch/arm/dts/stm32mp157a-avenger96.dts
@@ -91,6 +91,17 @@
states = <180 0x1>,
<290 0x0>;
};
+
+ /* Enpirion EP3A8LQI U2 on the DHCOR */
+ vdd_io: regulator-buck-io {
+ compatible = "regulator-fixed";
+ regulator-name = "buck-io";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <>;
+ };
};
{
@@ -167,7 +178,7 @@
vddcore: buck1 {
regulator-name = "vddcore";
- regulator-min-microvolt = <120>;
+ regulator-min-microvolt = <80>;
regulator-max-microvolt = <135>;
regulator-always-on;
regulator-initial-mode = <0>;
@@ -185,8 +196,8 @@
vdd: buck3 {
regulator-name = "vdd";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
+ regulator-min-microvolt = <290>;
+ regulator-max-microvolt = <290>;
regulator-always-on;
st,mask_reset;
regulator-initial-mode = <0>;
@@ -268,6 +279,7 @@
regulator-name = "vbus_otg";
interrupts = ;
interrupt-parent = <>;
+ regulator-active-discharge = <1>;
};
vbus_sw: pwr_sw2 {
@@ -304,7 +316,7 @@
};
_regulators {
- vdd-supply = <>;
+ vdd-supply = <_io>;
vdd_3v3_usbfs-supply = <_usb>;
};
--
2.25.1
[PATCH V3 11/14] ARM: dts: stm32: Add missing ethernet PHY reset on AV96
Add PHY reset GPIO on AV96 ethernet PHY.
Signed-off-by: Marek Vasut
Cc: Manivannan Sadhasivam
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
V2: No change
V3: No change
---
arch/arm/dts/stm32mp157a-avenger96.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts
b/arch/arm/dts/stm32mp157a-avenger96.dts
index 88537e6769..8181d1fa05 100644
--- a/arch/arm/dts/stm32mp157a-avenger96.dts
+++ b/arch/arm/dts/stm32mp157a-avenger96.dts
@@ -101,6 +101,7 @@
phy-mode = "rgmii";
max-speed = <1000>;
phy-handle = <>;
+ phy-reset-gpios = < 2 GPIO_ACTIVE_LOW>;
mdio0 {
#address-cells = <1>;
--
2.25.1
[PATCH V3 10/14] ARM: dts: stm32: Repair ethernet operation on AV96
The AV96 RGMII uses different pinmux for ETH_RGMII_TXD0, ETH_RGMII_RXD2
and ETH_RGMII_TX_CTL. Use the correct pinmux to make ethernet operational.
Reviewed-by: Patrice Chotard
Reviewed-by: Patrick Delaunay
Signed-off-by: Marek Vasut
Cc: Manivannan Sadhasivam
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
V2: No change
V3: No change
---
arch/arm/dts/stm32mp157a-avenger96.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts
b/arch/arm/dts/stm32mp157a-avenger96.dts
index 5c7a326c12..88537e6769 100644
--- a/arch/arm/dts/stm32mp157a-avenger96.dts
+++ b/arch/arm/dts/stm32mp157a-avenger96.dts
@@ -95,8 +95,8 @@
{
status = "okay";
- pinctrl-0 = <_rgmii_pins_a>;
- pinctrl-1 = <_rgmii_pins_sleep_a>;
+ pinctrl-0 = <_rgmii_pins_b>;
+ pinctrl-1 = <_rgmii_pins_sleep_b>;
pinctrl-names = "default", "sleep";
phy-mode = "rgmii";
max-speed = <1000>;
--
2.25.1
[PATCH V3 07/14] ARM: dts: stm32: Use DT alias for the configuration EEPROM
Use DT /aliases node to establish a stable phandle to the configuration
EEPROM. This permits the configuration EEPROM to be moved e.g. to a
different address or a different bus. Adjust the board code to handle
new phandle lookup.
Reviewed-by: Patrice Chotard
Reviewed-by: Patrick Delaunay
Signed-off-by: Marek Vasut
Cc: Manivannan Sadhasivam
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
V2: No change
V3: No change
---
arch/arm/dts/stm32mp15xx-dhcom.dtsi | 6 +-
board/dhelectronics/dh_stm32mp1/board.c | 15 +++
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/arm/dts/stm32mp15xx-dhcom.dtsi
b/arch/arm/dts/stm32mp15xx-dhcom.dtsi
index bed69c97b6..e5be0a79ac 100644
--- a/arch/arm/dts/stm32mp15xx-dhcom.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcom.dtsi
@@ -10,6 +10,10 @@
#include
/ {
+ aliases {
+ eeprom0 =
+ };
+
memory@c000 {
device_type = "memory";
reg = <0xC000 0x4000>;
@@ -187,7 +191,7 @@
};
};
- eeprom@50 {
+ eeprom0: eeprom@50 {
compatible = "atmel,24c02";
reg = <0x50>;
pagesize = <16>;
diff --git a/board/dhelectronics/dh_stm32mp1/board.c
b/board/dhelectronics/dh_stm32mp1/board.c
index 109d9ec935..a3458a2623 100644
--- a/board/dhelectronics/dh_stm32mp1/board.c
+++ b/board/dhelectronics/dh_stm32mp1/board.c
@@ -78,22 +78,21 @@ DECLARE_GLOBAL_DATA_PTR;
int setup_mac_address(void)
{
- struct udevice *dev;
- ofnode eeprom;
unsigned char enetaddr[6];
- int ret;
+ struct udevice *dev;
+ int off, ret;
ret = eth_env_get_enetaddr("ethaddr", enetaddr);
if (ret)/* ethaddr is already set */
return 0;
- eeprom = ofnode_path("/soc/i2c@5c002000/eeprom@50");
- if (!ofnode_valid(eeprom)) {
- printf("Invalid hardware path to EEPROM!\n");
- return -ENODEV;
+ off = fdt_path_offset(gd->fdt_blob, "eeprom0");
+ if (off < 0) {
+ printf("%s: No eeprom0 path offset\n", __func__);
+ return off;
}
- ret = uclass_get_device_by_ofnode(UCLASS_I2C_EEPROM, eeprom, );
+ ret = uclass_get_device_by_of_offset(UCLASS_I2C_EEPROM, off, );
if (ret) {
printf("Cannot find EEPROM!\n");
return ret;
--
2.25.1
[PATCH V3 06/14] ARM: dts: stm32: Add QSPI NOR on AV96
The DH Electronics DHCOR SOM has QSPI NOR on the SoM itself, add it
into the DT.
Signed-off-by: Marek Vasut
Cc: Manivannan Sadhasivam
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
V2: Drop the explicit flash type in DT node, use spi-flash
V3: Reduce the SPI NOR window to 2 MiB
---
arch/arm/dts/stm32mp157a-avenger96.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts
b/arch/arm/dts/stm32mp157a-avenger96.dts
index 3fca1ed56d..023390a662 100644
--- a/arch/arm/dts/stm32mp157a-avenger96.dts
+++ b/arch/arm/dts/stm32mp157a-avenger96.dts
@@ -20,6 +20,7 @@
mmc0 =
serial0 =
serial1 =
+ spi0 =
};
chosen {
@@ -300,6 +301,25 @@
vdd_3v3_usbfs-supply = <_usb>;
};
+ {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <_clk_pins_a _bk1_pins_a>;
+ pinctrl-1 = <_clk_sleep_pins_a _bk1_sleep_pins_a>;
+ reg = <0x58003000 0x1000>, <0x7000 0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ flash0: spi-flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-rx-bus-width = <4>;
+ spi-max-frequency = <10800>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+};
+
{
status = "okay";
};
--
2.25.1
[PATCH V3 08/14] ARM: dts: stm32: Add configuration EEPROM on AV96
The board has an EEPROM on the same I2C bus as PMIC, at address 0x53.
The EEPROM contains the board MAC address.
Reviewed-by: Patrice Chotard
Reviewed-by: Patrick Delaunay
Signed-off-by: Marek Vasut
Cc: Manivannan Sadhasivam
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
V2: No change
V3: No change
---
arch/arm/dts/stm32mp157a-avenger96.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts
b/arch/arm/dts/stm32mp157a-avenger96.dts
index 023390a662..5c7a326c12 100644
--- a/arch/arm/dts/stm32mp157a-avenger96.dts
+++ b/arch/arm/dts/stm32mp157a-avenger96.dts
@@ -289,6 +289,12 @@
status = "disabled";
};
};
+
+ eeprom@53 {
+ compatible = "atmel,24c02";
+ reg = <0x53>;
+ pagesize = <16>;
+ };
};
{
--
2.25.1
[PATCH V3 05/14] ARM: dts: stm32: Repair SDMMC2 operation
The eMMC uses different pinmux for the top four data lines, use such
a pinmux, otherwise it takes a very long time until the test for 8bit
operation times out. And this is the correct pinmux per schematic too.
Reviewed-by: Patrice Chotard
Reviewed-by: Patrick Delaunay
Signed-off-by: Marek Vasut
Cc: Manivannan Sadhasivam
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
V2: Update also the -u-boot.dtsi to match this change
V3: No change
---
arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 2 +-
arch/arm/dts/stm32mp157a-avenger96.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
index 47bfbb8d77..2c7dc509a3 100644
--- a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
@@ -174,7 +174,7 @@
};
};
-_d47_pins_a {
+_d47_pins_b {
u-boot,dm-spl;
pins {
u-boot,dm-spl;
diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts
b/arch/arm/dts/stm32mp157a-avenger96.dts
index 1e9b45b69d..3fca1ed56d 100644
--- a/arch/arm/dts/stm32mp157a-avenger96.dts
+++ b/arch/arm/dts/stm32mp157a-avenger96.dts
@@ -327,7 +327,7 @@
{
pinctrl-names = "default";
- pinctrl-0 = <_b4_pins_a _d47_pins_a>;
+ pinctrl-0 = <_b4_pins_a _d47_pins_b>;
non-removable;
no-sd;
no-sdio;
--
2.25.1
[PATCH V3 04/14] ARM: dts: stm32: Add alternate pinmux for SDMMC2 pins 4-7
Add another mux option for SDMMC2 pins 4..7, this is used on AV96 board.
Reviewed-by: Patrice Chotard
Reviewed-by: Patrick Delaunay
Signed-off-by: Marek Vasut
Cc: Manivannan Sadhasivam
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
V2: Use correct pin AFs
V3: No change
---
arch/arm/dts/stm32mp157-pinctrl.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/dts/stm32mp157-pinctrl.dtsi
b/arch/arm/dts/stm32mp157-pinctrl.dtsi
index 6842d4cdca..964e4910ec 100644
--- a/arch/arm/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp157-pinctrl.dtsi
@@ -931,6 +931,27 @@
};
};
+ sdmmc2_d47_pins_b: sdmmc2-d47-1 {
+ pins {
+ pinmux = ,
/* SDMMC2_D4 */
+,
/* SDMMC2_D5 */
+,
/* SDMMC2_D6 */
+;
/* SDMMC2_D7 */
+ slew-rate = <1>;
+ drive-push-pull;
+ bias-pull-up;
+ };
+ };
+
+ sdmmc2_d47_sleep_pins_b: sdmmc2-d47-sleep-1 {
+ pins {
+ pinmux = , /* SDMMC2_D4 */
+, /* SDMMC2_D5 */
+, /* SDMMC2_D6 */
+; /* SDMMC2_D7 */
+ };
+ };
+
spdifrx_pins_a: spdifrx-0 {
pins {
pinmux = ;
/* SPDIF_IN1 */
--
2.25.1
[PATCH V3 09/14] ARM: dts: stm32: Add alternate pinmux for ethernet RGMII
Add another mux option for DWMAC RGMII, this is used on AV96 board.
Reviewed-by: Patrice Chotard
Reviewed-by: Patrick Delaunay
Signed-off-by: Marek Vasut
Cc: Manivannan Sadhasivam
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
V2: No change
V3: No change
---
arch/arm/dts/stm32mp157-pinctrl.dtsi | 51
1 file changed, 51 insertions(+)
diff --git a/arch/arm/dts/stm32mp157-pinctrl.dtsi
b/arch/arm/dts/stm32mp157-pinctrl.dtsi
index 964e4910ec..422dad1ddd 100644
--- a/arch/arm/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp157-pinctrl.dtsi
@@ -288,6 +288,57 @@
};
};
+ ethernet0_rgmii_pins_b: rgmii-1 {
+ pins1 {
+ pinmux = ,
/* ETH_RGMII_CLK125 */
+,
/* ETH_RGMII_GTX_CLK */
+,
/* ETH_RGMII_TXD0 */
+,
/* ETH_RGMII_TXD1 */
+,
/* ETH_RGMII_TXD2 */
+,
/* ETH_RGMII_TXD3 */
+,
/* ETH_RGMII_TX_CTL */
+;
/* ETH_MDC */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <2>;
+ };
+ pins2 {
+ pinmux = ;
/* ETH_MDIO */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins3 {
+ pinmux = ,
/* ETH_RGMII_RXD0 */
+,
/* ETH_RGMII_RXD1 */
+,
/* ETH_RGMII_RXD2 */
+,
/* ETH_RGMII_RXD3 */
+,
/* ETH_RGMII_RX_CLK */
+;
/* ETH_RGMII_RX_CTL */
+ bias-disable;
+ };
+ };
+
+ ethernet0_rgmii_pins_sleep_b: rgmii-sleep-1 {
+ pins1 {
+ pinmux = , /* ETH_RGMII_CLK125 */
+, /* ETH_RGMII_GTX_CLK */
+, /* ETH_RGMII_TXD0 */
+, /* ETH_RGMII_TXD1 */
+, /* ETH_RGMII_TXD2 */
+, /* ETH_RGMII_TXD3 */
+, /* ETH_RGMII_TX_CTL */
+, /* ETH_MDIO */
+, /* ETH_MDC */
+, /* ETH_RGMII_RXD0 */
+, /* ETH_RGMII_RXD1 */
+, /* ETH_RGMII_RXD2 */
+, /* ETH_RGMII_RXD3 */
+, /* ETH_RGMII_RX_CLK */
+; /* ETH_RGMII_RX_CTL */
+ };
+ };
+
fmc_pins_a: fmc-0 {
pins1 {
pinmux = ,
/* FMC_NOE */
--
2.25.1
[PATCH V3 03/14] ARM: dts: stm32: Repair SDMMC1 operation on AV96
The SD uses different pinmux for the D123DIRline, use such a pinmux,
otherwise there is a pinmux collision on the AV96. Add missing SD
voltage regulator switch and enable SDR104 operation.
Reviewed-by: Patrice Chotard
Reviewed-by: Patrick Delaunay
Signed-off-by: Marek Vasut
Cc: Manivannan Sadhasivam
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
V2: New patch
V3: No change
---
.../arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 2 +-
arch/arm/dts/stm32mp157a-avenger96.dts| 25 ---
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
index 8dcd8866e8..47bfbb8d77 100644
--- a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
@@ -150,7 +150,7 @@
};
};
-_dir_pins_a {
+_dir_pins_b {
u-boot,dm-spl;
pins1 {
u-boot,dm-spl;
diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts
b/arch/arm/dts/stm32mp157a-avenger96.dts
index 3065593bf2..1e9b45b69d 100644
--- a/arch/arm/dts/stm32mp157a-avenger96.dts
+++ b/arch/arm/dts/stm32mp157a-avenger96.dts
@@ -76,6 +76,20 @@
default-state = "off";
};
};
+
+ sd_switch: regulator-sd_switch {
+ compatible = "regulator-gpio";
+ regulator-name = "sd_switch";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <290>;
+ regulator-type = "voltage";
+ regulator-always-on;
+
+ gpios = < 5 GPIO_ACTIVE_HIGH>;
+ gpios-states = <0>;
+ states = <180 0x1>,
+<290 0x0>;
+ };
};
{
@@ -296,15 +310,18 @@
{
pinctrl-names = "default", "opendrain", "sleep";
- pinctrl-0 = <_b4_pins_a _dir_pins_a>;
- pinctrl-1 = <_b4_od_pins_a>;
- pinctrl-2 = <_b4_sleep_pins_a>;
- broken-cd;
+ pinctrl-0 = <_b4_pins_a _dir_pins_b>;
+ pinctrl-1 = <_b4_od_pins_a _dir_pins_b>;
+ pinctrl-2 = <_b4_sleep_pins_a _dir_sleep_pins_b>;
+ cd-gpios = < 8 GPIO_ACTIVE_LOW>;
+ disable-wp;
st,sig-dir;
st,neg-edge;
st,use-ckin;
+ sd-uhs-sdr104;
bus-width = <4>;
vmmc-supply = <_sd>;
+ vqmmc-supply = <_switch>;
status = "okay";
};
--
2.25.1
[PATCH V3 02/14] ARM: dts: stm32: Add alternate pinmux for SDMMC1 direction pins
Add another mux option for SDMMC1 direction pins, in particular
SDMMC1_D123DIR, this is used on AV96 board.
Reviewed-by: Patrice Chotard
Reviewed-by: Patrick Delaunay
Signed-off-by: Marek Vasut
Cc: Manivannan Sadhasivam
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
V2: New patch
V3: No change
---
arch/arm/dts/stm32mp157-pinctrl.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/dts/stm32mp157-pinctrl.dtsi
b/arch/arm/dts/stm32mp157-pinctrl.dtsi
index 81a363d93d..6842d4cdca 100644
--- a/arch/arm/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp157-pinctrl.dtsi
@@ -832,6 +832,30 @@
};
};
+ sdmmc1_dir_pins_b: sdmmc1-dir-1 {
+ pins1 {
+ pinmux = ,
/* SDMMC1_D0DIR */
+,
/* SDMMC1_D123DIR */
+;
/* SDMMC1_CDIR */
+ slew-rate = <1>;
+ drive-push-pull;
+ bias-pull-up;
+ };
+ pins2{
+ pinmux = ;
/* SDMMC1_CKIN */
+ bias-pull-up;
+ };
+ };
+
+ sdmmc1_dir_sleep_pins_b: sdmmc1-dir-sleep-1 {
+ pins {
+ pinmux = , /* SDMMC1_D0DIR */
+, /* SDMMC1_D123DIR */
+, /* SDMMC1_CDIR */
+; /* SDMMC1_CKIN */
+ };
+ };
+
sdmmc2_b4_pins_a: sdmmc2-b4-0 {
pins1 {
pinmux = ,
/* SDMMC2_D0 */
--
2.25.1
[PATCH V3 00/14] ARM: stm32: Fix Avenger96
This series fixes the Avenger96 board. Since there are way too many patches
floating around on the ML and because I found various other details that
needed fixing, I decided to bundle the whole set of fixes into this series.
This should go into current release, otherwise the board doesn't even boot.
This V2 is also roughly synchronized with the Linux V2 series fixing very
much the same issues.
Marek Vasut (14):
ARM: dts: stm32: Repair SD1 pre-reloc pinmux DT node on AV96
ARM: dts: stm32: Add alternate pinmux for SDMMC1 direction pins
ARM: dts: stm32: Repair SDMMC1 operation on AV96
ARM: dts: stm32: Add alternate pinmux for SDMMC2 pins 4-7
ARM: dts: stm32: Repair SDMMC2 operation
ARM: dts: stm32: Add QSPI NOR on AV96
ARM: dts: stm32: Use DT alias for the configuration EEPROM
ARM: dts: stm32: Add configuration EEPROM on AV96
ARM: dts: stm32: Add alternate pinmux for ethernet RGMII
ARM: dts: stm32: Repair ethernet operation on AV96
ARM: dts: stm32: Add missing ethernet PHY reset on AV96
ARM: dts: stm32: Repair PMIC configuration on AV96
ARM: dts: stm32: Adjust PLL4 settings on AV96
ARM: dts: stm32: Split AV96 into DHCOR SoM and AV96 board
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/stm32mp157-pinctrl.dtsi | 96 +
arch/arm/dts/stm32mp157a-avenger96.dts| 365 +-
arch/arm/dts/stm32mp15xx-dhcom.dtsi | 6 +-
.../stm32mp15xx-dhcor-avenger96-u-boot.dtsi | 80
arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts | 211 ++
...oot.dtsi => stm32mp15xx-dhcor-u-boot.dtsi} | 80 +---
arch/arm/dts/stm32mp15xx-dhcor.dtsi | 231 +++
board/dhelectronics/dh_stm32mp1/board.c | 15 +-
doc/board/st/stm32mp1.rst | 8 +-
10 files changed, 645 insertions(+), 450 deletions(-)
create mode 100644 arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi
create mode 100644 arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts
rename arch/arm/dts/{stm32mp157a-avenger96-u-boot.dtsi =>
stm32mp15xx-dhcor-u-boot.dtsi} (73%)
create mode 100644 arch/arm/dts/stm32mp15xx-dhcor.dtsi
Cc: Manivannan Sadhasivam
Cc: Patrick Delaunay
Cc: Patrice Chotard
--
2.25.1
[PATCH V3 01/14] ARM: dts: stm32: Repair SD1 pre-reloc pinmux DT node on AV96
The sdmmc1_dir_pins_a: sdmmc1-dir-0 layout changed in commit 35a54d41d9d4
("ARM: dts: stm32mp1: sync device tree with v5.2-rc4") such that pins{};
became pins1{};pins2{};, however the SPL extras were not updated to reflect
that change. Fix this.
This fixes booting from SD1 X9 slot on the AV96 board.
Reviewed-by: Patrice Chotard
Reviewed-by: Patrick Delaunay
Fixes: 35a54d41d9d4 ("ARM: dts: stm32mp1: sync device tree with v5.2-rc4")
Signed-off-by: Marek Vasut
Cc: Manivannan Sadhasivam
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
V2: Adjust patch subject
V3: No change
---
arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
index d6dc746365..8dcd8866e8 100644
--- a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
@@ -152,7 +152,10 @@
_dir_pins_a {
u-boot,dm-spl;
- pins {
+ pins1 {
+ u-boot,dm-spl;
+ };
+ pins2 {
u-boot,dm-spl;
};
};
--
2.25.1
[PATCH] rockchip: sdram: fix DRAM bank declaration around OP-TEE
If OP-TEE is configured, it makes sense to use CONFIG_OPTEE_TZDRAM_BASE
and CONFIG_OPTEE_TZDRAM_SIZE to declare the boundaries of the TrustZone
memory reserved for OP-TEE instead of assuming that a 32MB reservation is
always in place.
In this case, the following calculations may be used to determine the
boundaries of DRAM bank 0 and 1 which surround the TrustZone reservation:
[DRAM bank 0]
base = CONFIG_SYS_DRAM_BASE
size = CONFIG_OPTEE_TZDRAM_BASE - CONFIG_SYS_SDRAM_BASE
[DRAM bank 1]
base = CONFIG_OPTEE_TZDRAM_BASE + CONFIG_OPTEE_TZDRAM_SIZE
size = top of memory - base of DRAM bank 1
Signed-off-by: Justin Swartz
---
arch/arm/mach-rockchip/sdram.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-rockchip/sdram.c b/arch/arm/mach-rockchip/sdram.c
index 530644c043..def2c23294 100644
--- a/arch/arm/mach-rockchip/sdram.c
+++ b/arch/arm/mach-rockchip/sdram.c
@@ -55,16 +55,14 @@ int dram_init_banksize(void)
- CONFIG_SYS_SDRAM_BASE;
gd->bd->bi_dram[1].start = tos_parameter->tee_mem.phy_addr +
tos_parameter->tee_mem.size;
- gd->bd->bi_dram[1].size = gd->bd->bi_dram[0].start
- + top - gd->bd->bi_dram[1].start;
+ gd->bd->bi_dram[1].size = top - gd->bd->bi_dram[1].start;
} else {
gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
- gd->bd->bi_dram[0].size = 0x840;
- /* Reserve 32M for OPTEE with TA */
- gd->bd->bi_dram[1].start = CONFIG_SYS_SDRAM_BASE
- + gd->bd->bi_dram[0].size + 0x200;
- gd->bd->bi_dram[1].size = gd->bd->bi_dram[0].start
- + top - gd->bd->bi_dram[1].start;
+ gd->bd->bi_dram[0].size = CONFIG_OPTEE_TZDRAM_BASE
+ - CONFIG_SYS_SDRAM_BASE;
+ gd->bd->bi_dram[1].start = CONFIG_OPTEE_TZDRAM_BASE
+ + CONFIG_OPTEE_TZDRAM_SIZE;
+ gd->bd->bi_dram[1].size = top - gd->bd->bi_dram[1].start;
}
#else
gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
--
2.11.0
[PATCH 1/1] mmc: adjust Kconfig for mmc sub-commands
All sub-commands of the mmc command should be shown in the Kconfig menu next to the mmc command. This includes: * mmc bkops * mmc rpmb * mmc swrite The mmc rpmb sub-command is not usable without CONFIG_SUPPORT_EMMC_RPMB. Add the missing dependency. Signed-off-by: Heinrich Schuchardt --- cmd/Kconfig | 26 +++--- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index 6403bc45a5..22ba385141 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -1052,21 +1052,34 @@ config CMD_MMC help MMC memory mapped support. +if CMD_MMC + +config CMD_BKOPS_ENABLE + bool "mmc bkops enable" + depends on CMD_MMC + default n + help + Enable command for setting manual background operations handshake + on a eMMC device. The feature is optionally available on eMMC devices + conforming to standard >= 4.41. + config CMD_MMC_RPMB bool "Enable support for RPMB in the mmc command" - depends on CMD_MMC + depends on SUPPORT_EMMC_RPMB help Enable the commands for reading, writing and programming the key for the Replay Protection Memory Block partition in eMMC. config CMD_MMC_SWRITE bool "mmc swrite" - depends on CMD_MMC && MMC_WRITE + depends on MMC_WRITE select IMAGE_SPARSE help Enable support for the "mmc swrite" command to write Android sparse images to eMMC. +endif + config CMD_MTD bool "mtd" depends on MTD @@ -1599,15 +1612,6 @@ config CMD_BSP option provides a way to control this. The commands that are enabled vary depending on the board. -config CMD_BKOPS_ENABLE - bool "mmc bkops enable" - depends on CMD_MMC - default n - help - Enable command for setting manual background operations handshake - on a eMMC device. The feature is optionally available on eMMC devices - conforming to standard >= 4.41. - config CMD_BLOCK_CACHE bool "blkcache - control and stats for block cache" depends on BLOCK_CACHE -- 2.20.1
Re: [PATCH V2 11/14] ARM: dts: stm32: Add missing ethernet PHY reset on AV96
On 3/31/20 4:06 PM, Patrick DELAUNAY wrote: > Hi Marek, > >> From: Marek Vasut >> Sent: mardi 31 mars 2020 02:49 >> >> Add PHY reset GPIO on AV96 ethernet PHY. >> >> Signed-off-by: Marek Vasut >> Cc: Patrick Delaunay >> Cc: Patrice Chotard >> --- >> V2: No change >> --- >> arch/arm/dts/stm32mp157a-avenger96.dts | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts >> b/arch/arm/dts/stm32mp157a-avenger96.dts >> index fb8f0021b3..7a4b6e6a2c 100644 >> --- a/arch/arm/dts/stm32mp157a-avenger96.dts >> +++ b/arch/arm/dts/stm32mp157a-avenger96.dts >> @@ -101,6 +101,7 @@ >> phy-mode = "rgmii"; >> max-speed = <1000>; >> phy-handle = <>; >> +phy-reset-gpios = < 2 GPIO_ACTIVE_LOW>; > > This obsolete binding is (and won't be) supported for STM32MP15x variant of > dwc_eth_qos driver. > > I am currenty upstream the support in U-boot of the support of the final > binding > aligned with Kernel one. > > "net: dwc_eth_qos: implement reset-gpios for stm32" > http://patchwork.ozlabs.org/patch/1257377/ That's probably gonna go in the next cycle, right? So you likely want to grab this for this cycle to fix the ethernet here and then in next cycle rework the bindings. btw you also want to look at this series: [PATCH 1/6] net: dwc_eth_qos: Fully rewrite RX descriptor field 3
Re: [PATCH V2 00/14] ARM: stm32: Fix Avenger96
On 3/31/20 5:22 PM, Patrick DELAUNAY wrote: > Hi Marek, Hi, >> From: Marek Vasut >> Sent: mardi 31 mars 2020 02:49 >> >> This series fixes the Avenger96 board. Since there are way too many patches >> floating around on the ML and because I found various other details that >> needed >> fixing, I decided to bundle the whole set of fixes into this series. >> >> This should go into current release, otherwise the board doesn't even boot. >> This V2 is also roughly synchronized with the Linux V2 series fixing very >> much >> the same issues. > > Do you expect all these paches in v2020.04 ? so in 5 days. Yes, the timing is bad, but this is fixing real bugs and is isolated to one (two) boards. > I think I can prepare a pull request with bugfix to solve regression, but it > seems late for all the serie. > > For me: >> ARM: dts: stm32: Repair SD1 pre-reloc pinmux DT node on AV96 > > It is clearly a regression since u-boot-stm32-20190717 / v2020.01-rc1 ! > > The next 4 patches of the serie could be also applied without issue >> ARM: dts: stm32: Add alternate pinmux for SDMMC1 direction pins >> ARM: dts: stm32: Repair SDMMC1 operation on AV96 >> ARM: dts: stm32: Add alternate pinmux for SDMMC2 pins 4-7 >> ARM: dts: stm32: Repair SDMMC2 operation > > But for the rest of the serie, I prefer wait v2020.04 merge window and end of > reviews > (on U-Boot side and on Linux kernel side). > >> ARM: dts: stm32: Add QSPI NOR on AV96 This one you need to have working env storage. >> ARM: dts: stm32: Use DT alias for the configuration EEPROM >> ARM: dts: stm32: Add configuration EEPROM on AV96 This one you need , otherwise ethernet MAC doesn't get correct MAC address. >> ARM: dts: stm32: Add alternate pinmux for ethernet RGMII >> ARM: dts: stm32: Repair ethernet operation on AV96 This actually fixes ethernet. >> ARM: dts: stm32: Add missing ethernet PHY reset on AV96 >> ARM: dts: stm32: Repair PMIC configuration on AV96 This fixes PMIC settings, so you do want this, otherwise the board is unstable. >> ARM: dts: stm32: Adjust PLL4 settings on AV96 This one can probably wait, although it would make sense to put it in. >> ARM: dts: stm32: Split AV96 into DHCOR SoM and AV96 board This one can wait for next. [...]
Re: [PATCH V2 14/14] ARM: dts: stm32: Split AV96 into DHCOR SoM and AV96 board
On 3/31/20 4:59 PM, Patrick DELAUNAY wrote:
> Hi,
Hi,
>> It is also highly recommended to configure the board for the DHCOM make
>> stm32mp15_dhcom_basic_defconfig make DEVICE_TREE=stm32mp15xx-dhcor-
>> avenger96
>> as that permits reusing the board code for the DH components, like accessing
>> and
>> reading out the ethernet MAC from EEPROM.
>
> Recommended or mandatory...
Both work, the later provides more complete solution.
> For my point of view
>
> - board/st/stm32mp1 manage the ST board (STM32MP15x-DKX and STM32MP15x-EV1)
> Can be used as starting point for customer
> new board
>
> - board/dhelectronics/dh_stm32mp1 manage the board based on DHCOR SoM or can
> be a starting point of SoM user
>
> For AV96, the first upstream was directly based on ST board, but I agree : it
> is clearly not a perfect solution (MAC address issue for example)
Yes indeed.
> => support on this board should be in dh_stm32mp1 board or create a new board
> AV96 based on it.
>
> And I need to continue to move in st/common the part common for all the
> STM32MP157 boards
[...]
>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
>> 9c593b2c98..2564f790de 100644
>> --- a/arch/arm/dts/Makefile
>> +++ b/arch/arm/dts/Makefile
>> @@ -884,7 +884,8 @@ dtb-$(CONFIG_STM32MP15x) += \
>> stm32mp157c-dk2.dtb \
>> stm32mp157c-ed1.dtb \
>> stm32mp157c-ev1.dtb \
>> -stm32mp15xx-dhcom-pdk2.dtb
>> +stm32mp15xx-dhcom-pdk2.dtb \
>> +stm32mp15xx-dhcor-avenger96.dtb
>
> Force device tree support for each target ?
> Avoid to mix incompatible device tree and defconfig
>
> dtb-$(TARGET_ST_STM32MP15x) += \
> stm32mp157a-dk1.dtb \
> stm32mp157c-dk2.dtb \
> stm32mp157c-ed1.dtb \
> stm32mp157c-ev1.dtb
>
> dtb-$(TARGET_DH_STM32MP1_PDK2) += \
> stm32mp15xx-dhcom-pdk2.dtb \
> stm32mp15xx-dhcor-avenger96.dtb
You probably want to build all DTs for STM32MP1 when building STM32MP1
platforms ?
[...]
(please, learn to trim the responses in email)
>> - {
>> -status = "okay";
>> -};
>> -
>> -_port0 {
>> -phy-supply = <_usb>;
>> -};
>> -
>> -_port1 {
>> -phy-supply = <_usb>;
>> -};
>
> When this file will be removed ? why kept this file.
> I propose to completely remove this file (no device tree for same board)
Backward compatibility, I'd keep it in for a release or two.
But if removing it is fine, then so be it.
>> +/* This is kept for backward compatibility and will be removed */
>> +#include "stm32mp15xx-dhcor-avenger96.dts"
>
> Missing u-boot file to avoid issue..
>
> +#include " stm32mp15xx-dhcor-avenger96-u-boot.dtsi"
That's actually included via the avenger96.dts, so should be OK.
Although I am not real happy with that.
[...]
>> Build Procedure
>> ---
>> @@ -229,7 +229,7 @@ Build Procedure
>>
>> # export KBUILD_OUTPUT=stm32mp15_basic
>> # make stm32mp15_basic_defconfig
>> - # make DEVICE_TREE=stm32mp157a-avenger96 all
>> + # make DEVICE_TREE=stm32mp15xx-dhcor-avenger96 all
>>
>> 6. Output files
>
> Reference could be removed if support if done by
> stm32mp15_dhcom_basic_defconfig / dh_stm32mp1 board
See my first question about the defconfig.
Re: [PATCH V2 06/14] ARM: dts: stm32: Add QSPI NOR on AV96
On 3/31/20 3:39 PM, Patrick DELAUNAY wrote:
> Hi Marek,
>
>> From: Marek Vasut
>> Sent: mardi 31 mars 2020 02:49
>>
>> The DH Electronics DHCOR SOM has QSPI NOR on the SoM itself, add it into the
>> DT.
>>
>> Signed-off-by: Marek Vasut
>> Cc: Patrick Delaunay
>> Cc: Patrice Chotard
>> ---
>> V2: Drop the explicit flash type in DT node, use spi-flash
>> ---
>> arch/arm/dts/stm32mp157a-avenger96.dts | 20
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts
>> b/arch/arm/dts/stm32mp157a-avenger96.dts
>> index 3fca1ed56d..512ef5f7bb 100644
>> --- a/arch/arm/dts/stm32mp157a-avenger96.dts
>> +++ b/arch/arm/dts/stm32mp157a-avenger96.dts
>> @@ -20,6 +20,7 @@
>> mmc0 =
>> serial0 =
>> serial1 =
>> +spi0 =
>> };
>>
>> chosen {
>> @@ -300,6 +301,25 @@
>> vdd_3v3_usbfs-supply = <_usb>;
>> };
>>
>> + {
>> +pinctrl-names = "default", "sleep";
>> +pinctrl-0 = <_clk_pins_a _bk1_pins_a>;
>> +pinctrl-1 = <_clk_sleep_pins_a _bk1_sleep_pins_a>;
>> +reg = <0x58003000 0x1000>, <0x7000 0x400>;
>
> In
> https://www.dh-electronics.com/en/products/dhsom-system-on-modules/dhcor-stm32mp1
>
>
> SPI NOR flash => 2 Mbyte boot flash
>
> So I think that memory mapped register should be limited to 2Mbyte = 0x20
> and not 64MBytes
>
> reg = <0x58003000 0x1000>, <0x7000 0x20>;
Fixed
RE: [U-Boot] [PATCH v1 2/2] gpio: stm32f7: Fix SPL code size
Hi Simon and Marek,
> From: Simon Glass
> Sent: mardi 31 mars 2020 18:08
>
> Hi,
>
> On Mon, 30 Mar 2020 at 20:51, Marek Vasut wrote:
> >
> > On 1/4/19 10:55 AM, Patrice Chotard wrote:
> >
> > Hi,
> >
> > > @@ -215,7 +220,9 @@ U_BOOT_DRIVER(gpio_stm32) = {
> > > .id = UCLASS_GPIO,
> > > .of_match = stm32_gpio_ids,
> > > .probe = gpio_stm32_probe,
> > > +#ifndef CONFIG_SPL_BUILD
> > > .ops= _stm32_ops,
> > > +#endif
> > > .flags = DM_UC_FLAG_SEQ_ALIAS,
> > > .priv_auto_alloc_size = sizeof(struct stm32_gpio_priv),
> > > };
> >
> > The U-Boot DM GPIO uclass code assumes the .ops is always non-NULL.
> > Hence, this patch breaks all GPIO access (actually crashes SPL) on
> > STM32 in SPL.
>
> Right. You are not allowed to have a driver without operations unless the
> uclass
> defines none.
Agree,
it was a dirty patch to reduce the SPL size for one MCU board stm32f7...
It is no more needed today: all MCU board compile without this patch.
Moreover, this patch can cause issues for stm32mp1 (crashes).
For example on STM32MP157-EV1, when SD card detect is added
in device tree, this opt is required (and it should be the case after the next
device tree allignment).
A patch to reactivate this opts was in my backlog to prepare this DT update,
I sent it today to solve the issue:
"[13/16] gpio: stm32: support gpio ops in SPL"
http://patchwork.ozlabs.org/patch/1264836/
regards
Patrick
Re: [U-Boot] [PATCH v1 2/2] gpio: stm32f7: Fix SPL code size
On 3/31/20 4:10 PM, Patrice CHOTARD wrote:
>
> On 3/31/20 1:22 PM, Marek Vasut wrote:
>> On 3/31/20 10:12 AM, Patrice CHOTARD wrote:
>>> Hi Marek
>> Hi,
>>
>>> On 3/31/20 4:51 AM, Marek Vasut wrote:
On 1/4/19 10:55 AM, Patrice Chotard wrote:
Hi,
> @@ -215,7 +220,9 @@ U_BOOT_DRIVER(gpio_stm32) = {
> .id = UCLASS_GPIO,
> .of_match = stm32_gpio_ids,
> .probe = gpio_stm32_probe,
> +#ifndef CONFIG_SPL_BUILD
> .ops= _stm32_ops,
> +#endif
> .flags = DM_UC_FLAG_SEQ_ALIAS,
> .priv_auto_alloc_size = sizeof(struct stm32_gpio_priv),
> };
The U-Boot DM GPIO uclass code assumes the .ops is always non-NULL.
Hence, this patch breaks all GPIO access (actually crashes SPL) on STM32
in SPL.
>>> I suppose it breaks AV96 boot ?
>> No, it does not. I was trying to read GPIO value in SPL and found this.
>>
>>> On my side i have checked on v2020-04-rc4 U-boot release, by reverting
>>> "gpio: stm32f7: Fix SPL code size"
>>>
>>> the stm32f7 SPL code size is below the 32Kb limit.
>>>
>>> I will send a patch to revert it.
>> OK sure, does that apply to all the STM32 systems ?
> Yes, all STM32 based platforms (F4/F7/H7 and MP1) are using this gpio driver.
What I wanted to ask about is whether you're sure they don't overflow in
SPL. But I suspect CI would tell you by now.
[U-Boot] Please pull last-minute fixes for ARC
Hi Tom,
The following changes since commit 93330d4ce416208fe202e304e5a18166c57ac569:
Prepare v2020.04-rc4 (2020-03-30 19:29:27 -0400)
are available in the Git repository at:
g...@gitlab.denx.de:u-boot/custodians/u-boot-arc.git
tags/arc-last-minute-fixes-for-2020.04
for you to fetch changes up to 45bd649511155b5b5a40851ca96036636cb95e23:
ARC: IO: add MB for __raw_* memory accessors (2020-03-31 18:31:53 +0300)
This last minute pull-request is intended to fix some drivers
when used on ARC boards. The problem was introduced by
https://gitlab.denx.de/u-boot/u-boot/-/commit/07906b3dad157bd58411664bcc6a2a7976d5e0a9
What happened while doing one pretty simple improvement to make
U-Boot port more flexible and portable (by switching accessors from
assembly-written to plain C version) we implicitly added 2 problems:
1. Downgraded accessors from being volatile which signalled to
the compiler that it's now possible to do all kinds of optimizations
which may easily include merge of subsequent byte reads/writes into
word operations. Which is OK for accessing mormal memory but
breaks operation of peripherals if we access its memory-mapped regs
in such a "creative" manner.
2. As a part of assembly-written implementation we had compiler barriers
in form of the following construction 'asm volatile("" : : : "memory")',
and we dropped it in C implemntation. This in its turn enabled compiler
to mess with instruction ordering. Guess what it gives us in the end :)
So with all that we had in some corner-cases veeery funny instruction flows
generated. And in particular it broke DW SPI functionality when we were
writing large amount of data. Funny enough our tests which were writing
small amount of data still worked and only by the chance we caught that
breakage and unrolled that quite interesting loop of unexpected
problems.
The road to hell is paved with good intentions. Amen :)
Eugeniy Paltsev (3):
ARC: IO: add volatile to accessors
ARC: IO: add compiler barriers to IO accessors
ARC: IO: add MB for __raw_* memory accessors
arch/arc/include/asm/io.h | 92
+++-
1 file changed, 59 insertions(+), 33 deletions(-)
Regards,
Alexey
Re: [U-Boot] [PATCH v1 2/2] gpio: stm32f7: Fix SPL code size
Hi,
On Mon, 30 Mar 2020 at 20:51, Marek Vasut wrote:
>
> On 1/4/19 10:55 AM, Patrice Chotard wrote:
>
> Hi,
>
> > @@ -215,7 +220,9 @@ U_BOOT_DRIVER(gpio_stm32) = {
> > .id = UCLASS_GPIO,
> > .of_match = stm32_gpio_ids,
> > .probe = gpio_stm32_probe,
> > +#ifndef CONFIG_SPL_BUILD
> > .ops= _stm32_ops,
> > +#endif
> > .flags = DM_UC_FLAG_SEQ_ALIAS,
> > .priv_auto_alloc_size = sizeof(struct stm32_gpio_priv),
> > };
>
> The U-Boot DM GPIO uclass code assumes the .ops is always non-NULL.
> Hence, this patch breaks all GPIO access (actually crashes SPL) on STM32
> in SPL.
Right. You are not allowed to have a driver without operations unless
the uclass defines none.
Regards,
Simon
[PATCH 13/16] gpio: stm32: support gpio ops in SPL
The GPIO support is needed in SPL to managed the SD cart detect
used on stm32mp157c-ev1 and dk2 board.
So this patch activates the associated code in stm32_gpio.c.
Signed-off-by: Patrick Delaunay
---
drivers/gpio/stm32_gpio.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpio/stm32_gpio.c b/drivers/gpio/stm32_gpio.c
index f55f834e7d..37a8cfa47a 100644
--- a/drivers/gpio/stm32_gpio.c
+++ b/drivers/gpio/stm32_gpio.c
@@ -20,7 +20,6 @@
#define MODE_BITS_MASK 3
#define BSRR_BIT(gpio_pin, value) BIT(gpio_pin + (value ? 0 : 16))
-#ifndef CONFIG_SPL_BUILD
/*
* convert gpio offset to gpio index taking into account gpio holes
* into gpio bank
@@ -147,7 +146,6 @@ static const struct dm_gpio_ops gpio_stm32_ops = {
.set_value = stm32_gpio_set_value,
.get_function = stm32_gpio_get_function,
};
-#endif
static int gpio_stm32_probe(struct udevice *dev)
{
@@ -162,7 +160,6 @@ static int gpio_stm32_probe(struct udevice *dev)
priv->regs = (struct stm32_gpio_regs *)addr;
-#ifndef CONFIG_SPL_BUILD
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
struct ofnode_phandle_args args;
const char *name;
@@ -195,7 +192,7 @@ static int gpio_stm32_probe(struct udevice *dev)
dev_dbg(dev, "addr = 0x%p bank_name = %s gpio_count = %d gpio_range =
0x%x\n",
(u32 *)priv->regs, uc_priv->bank_name, uc_priv->gpio_count,
priv->gpio_range);
-#endif
+
ret = clk_get_by_index(dev, 0, );
if (ret < 0)
return ret;
@@ -215,9 +212,7 @@ U_BOOT_DRIVER(gpio_stm32) = {
.name = "gpio_stm32",
.id = UCLASS_GPIO,
.probe = gpio_stm32_probe,
-#ifndef CONFIG_SPL_BUILD
.ops= _stm32_ops,
-#endif
.flags = DM_UC_FLAG_SEQ_ALIAS,
.priv_auto_alloc_size = sizeof(struct stm32_gpio_priv),
};
--
2.17.1
[PATCH 15/16] configs: stm32mp1: activate Ethernet PHY Realtek
From: Christophe Roullier Need Realtek driver to manage in RTL8211F the configuration of the LED. Initialize LCR (LED Control Register) to configure green LED for Link, yellow LED for Active Signed-off-by: Christophe Roullier Signed-off-by: Patrick Delaunay --- configs/stm32mp15_basic_defconfig | 1 + configs/stm32mp15_trusted_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/stm32mp15_basic_defconfig b/configs/stm32mp15_basic_defconfig index 6d82365348..30cfb8d8e1 100644 --- a/configs/stm32mp15_basic_defconfig +++ b/configs/stm32mp15_basic_defconfig @@ -101,6 +101,7 @@ CONFIG_SPI_FLASH_WINBOND=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_SPI_FLASH_MTD=y CONFIG_SPL_SPI_FLASH_MTD=y +CONFIG_PHY_REALTEK=y CONFIG_DM_ETH=y CONFIG_DWC_ETH_QOS=y CONFIG_PHY=y diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig index 6928e9a65c..aefad2b109 100644 --- a/configs/stm32mp15_trusted_defconfig +++ b/configs/stm32mp15_trusted_defconfig @@ -86,6 +86,7 @@ CONFIG_SPI_FLASH_STMICRO=y CONFIG_SPI_FLASH_WINBOND=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_SPI_FLASH_MTD=y +CONFIG_PHY_REALTEK=y CONFIG_DM_ETH=y CONFIG_DWC_ETH_QOS=y CONFIG_PHY=y -- 2.17.1
[PATCH 14/16] ARM: dts: stm32mp15: use DDR3 files generated by STM32CubeMX
Use the DDR3 dtsi files generated by STM32CubeMX 5.6.0 Speed Bin Grade = using DDR3-1066G / 8-8-8 and all others parameters at default value. Signed-off-by: Patrick Delaunay --- .../dts/stm32mp15-ddr3-1x4Gb-1066-binG.dtsi | 49 +-- .../dts/stm32mp15-ddr3-2x4Gb-1066-binG.dtsi | 49 +-- 2 files changed, 48 insertions(+), 50 deletions(-) diff --git a/arch/arm/dts/stm32mp15-ddr3-1x4Gb-1066-binG.dtsi b/arch/arm/dts/stm32mp15-ddr3-1x4Gb-1066-binG.dtsi index 11e8f2bef6..c0fc1f772e 100644 --- a/arch/arm/dts/stm32mp15-ddr3-1x4Gb-1066-binG.dtsi +++ b/arch/arm/dts/stm32mp15-ddr3-1x4Gb-1066-binG.dtsi @@ -1,24 +1,23 @@ // SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause /* * Copyright (C) 2018, STMicroelectronics - All Rights Reserved + */ + +/* + * File generated by STMicroelectronics STM32CubeMX DDR Tool for MPUs + * DDR type: DDR3 / DDR3L + * DDR width: 16bits + * DDR density: 4Gb + * System frequency: 533000Khz + * Relaxed Timing Mode: false + * Address mapping type: RBC * - * STM32MP157C DK1/DK2 BOARD configuration - * 1x DDR3L 4Gb, 16-bit, 533MHz. - * Reference used NT5CC256M16DP-DI from NANYA - * - * DDR type / Platform DDR3/3L - * freq533MHz - * width 16 - * datasheet 0 = MT41J256M16-187 / DDR3-1066 bin G - * DDR density 4 - * timing mode optimized - * Scheduling/QoS options : type = 2 - * address mapping : RBC - * Tc > + 85C : N + * Save Date: 2020.02.20, save Time: 18:45:20 */ -#define DDR_MEM_NAME "DDR3-1066/888 bin G 1x4Gb 533MHz v1.45" -#define DDR_MEM_SPEED 533000 -#define DDR_MEM_SIZE 0x2000 + +#define DDR_MEM_NAME "DDR3-DDR3L 16bits 533000Khz" +#define DDR_MEM_SPEED 533000 +#define DDR_MEM_SIZE 0x2000 #define DDR_MSTR 0x00041401 #define DDR_MRCTRL0 0x0010 @@ -50,15 +49,6 @@ #define DDR_DFIUPD1 0x #define DDR_DFIUPD2 0x #define DDR_DFIPHYMSTR 0x -#define DDR_ADDRMAP1 0x00070707 -#define DDR_ADDRMAP2 0x -#define DDR_ADDRMAP3 0x1F00 -#define DDR_ADDRMAP4 0x1F1F -#define DDR_ADDRMAP5 0x06060606 -#define DDR_ADDRMAP6 0x0F060606 -#define DDR_ADDRMAP9 0x -#define DDR_ADDRMAP10 0x -#define DDR_ADDRMAP11 0x #define DDR_ODTCFG 0x06000600 #define DDR_ODTMAP 0x0001 #define DDR_SCHED 0x0C01 @@ -83,6 +73,15 @@ #define DDR_PCFGQOS1_1 0x00800040 #define DDR_PCFGWQOS0_1 0x01100C03 #define DDR_PCFGWQOS1_1 0x01000200 +#define DDR_ADDRMAP1 0x00070707 +#define DDR_ADDRMAP2 0x +#define DDR_ADDRMAP3 0x1F00 +#define DDR_ADDRMAP4 0x1F1F +#define DDR_ADDRMAP5 0x06060606 +#define DDR_ADDRMAP6 0x0F060606 +#define DDR_ADDRMAP9 0x +#define DDR_ADDRMAP10 0x +#define DDR_ADDRMAP11 0x #define DDR_PGCR 0x01442E02 #define DDR_PTR0 0x0022AA5B #define DDR_PTR1 0x04841104 diff --git a/arch/arm/dts/stm32mp15-ddr3-2x4Gb-1066-binG.dtsi b/arch/arm/dts/stm32mp15-ddr3-2x4Gb-1066-binG.dtsi index 4b70b60554..fc226d2544 100644 --- a/arch/arm/dts/stm32mp15-ddr3-2x4Gb-1066-binG.dtsi +++ b/arch/arm/dts/stm32mp15-ddr3-2x4Gb-1066-binG.dtsi @@ -1,24 +1,23 @@ // SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause /* * Copyright (C) 2018, STMicroelectronics - All Rights Reserved + */ + +/* + * File generated by STMicroelectronics STM32CubeMX DDR Tool for MPUs + * DDR type: DDR3 / DDR3L + * DDR width: 32bits + * DDR density: 8Gb + * System frequency: 533000Khz + * Relaxed Timing Mode: false + * Address mapping type: RBC * - * STM32MP157C ED1 BOARD configuration - * 2x DDR3L 4Gb each, 16-bit, 533MHz, Single Die Package in flyby topology. - * Reference used NT5CC256M16DP-DI from NANYA - * - * DDR type / Platform DDR3/3L - * freq533MHz - * width 32 - * datasheet 0 = MT41J256M16-187 / DDR3-1066 bin G - * DDR density 8 - * timing mode optimized - * Scheduling/QoS options : type = 2 - * address mapping : RBC - * Tc > + 85C : N + * Save Date: 2020.02.20, save Time: 18:49:33 */ -#define DDR_MEM_NAME "DDR3-1066/888 bin G 2x4Gb 533MHz v1.45" -#define DDR_MEM_SPEED 533000 -#define DDR_MEM_SIZE 0x4000 + +#define DDR_MEM_NAME "DDR3-DDR3L 32bits 533000Khz" +#define DDR_MEM_SPEED 533000 +#define DDR_MEM_SIZE 0x4000 #define DDR_MSTR 0x00040401 #define DDR_MRCTRL0 0x0010 @@ -50,15 +49,6 @@ #define DDR_DFIUPD1 0x #define DDR_DFIUPD2 0x #define DDR_DFIPHYMSTR 0x -#define DDR_ADDRMAP1 0x00080808 -#define DDR_ADDRMAP2 0x -#define DDR_ADDRMAP3 0x -#define DDR_ADDRMAP4 0x1F1F -#define DDR_ADDRMAP5 0x07070707 -#define DDR_ADDRMAP6 0x0F070707 -#define DDR_ADDRMAP9 0x -#define DDR_ADDRMAP10 0x -#define DDR_ADDRMAP11 0x #define DDR_ODTCFG 0x06000600 #define DDR_ODTMAP 0x0001 #define DDR_SCHED 0x0C01 @@ -83,6 +73,15 @@ #define DDR_PCFGQOS1_1 0x00800040 #define DDR_PCFGWQOS0_1 0x01100C03 #define DDR_PCFGWQOS1_1 0x01000200 +#define DDR_ADDRMAP1 0x00080808 +#define DDR_ADDRMAP2 0x +#define DDR_ADDRMAP3 0x +#define
Re: [PATCH 5/8] xhci: mediatek: Add support for MTK xHCI host controller
On 3/31/20 4:16 PM, Simon Glass wrote: > HI Marek, Hi, [...] > OK I have updated the coding style page with all of this. Which page ? >>> >>> https://www.denx.de/wiki/U-Boot/CodingStyle >> >> " U-Boot typically uses a C structure to map out the registers in an I/O >> region, rather than offsets. The reasons for this are: " is misleading >> and suggests that using structures is the best practice. This should be >> reworded to make it clear both options are equally valid. > > I'd like to see a preference to use struct where it makes sense and > not use it when it doesn't, with the different tradeoffs clearly > written. Are asking that we say nothing about which is better in each > situation? Correct, because I don't see a clear agreement on which one is better and should be preferred. >>> Separately, I sent a patch a while back which updated checkpatch for >>> U-Boot. I got some pushback >> >> Link ? >> > > http://patchwork.ozlabs.org/patch/999510/ OK, this has nothing to do with structs, right ? >> I am very much opposed to this struct-based approach, so there is my >> pushback too. I think we should NOT do it. > > Right, but there are arguments on both sides. I strongly prefer it > where it makes sense, for reasons that we've already discussed. Your preference does not mean it is also the project preference though. If you want to decide on that, make sure there is some agreement first.
[PATCH 12/16] board: stm32mp1: add timeout for I/O compensation ready
This patch avoids infinite loop when I/O compensation failed,
it adds a 1s timeout to detect error.
Signed-off-by: Patrick Delaunay
---
board/st/stm32mp1/stm32mp1.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index fff4cef2c2..75aac6d66c 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -473,10 +474,10 @@ static void sysconf_init(void)
struct udevice *pwr_dev;
struct udevice *pwr_reg;
struct udevice *dev;
- int ret;
u32 otp = 0;
#endif
- u32 bootr;
+ int ret;
+ u32 bootr, val;
syscfg = (u8 *)syscon_get_first_range(STM32MP_SYSCON_SYSCFG);
@@ -553,8 +554,15 @@ static void sysconf_init(void)
*/
writel(SYSCFG_CMPENSETR_MPU_EN, syscfg + SYSCFG_CMPENSETR);
- while (!(readl(syscfg + SYSCFG_CMPCR) & SYSCFG_CMPCR_READY))
- ;
+ /* poll until ready (1s timeout) */
+ ret = readl_poll_timeout(syscfg + SYSCFG_CMPCR, val,
+val & SYSCFG_CMPCR_READY,
+100);
+ if (ret) {
+ pr_err("SYSCFG: I/O compensation failed, timeout.\n");
+ led_error_blink(10);
+ }
+
clrbits_le32(syscfg + SYSCFG_CMPCR, SYSCFG_CMPCR_SW_CTRL);
#endif
}
--
2.17.1
[PATCH 16/16] configs: stm32mp1: activate CONFIG_ERRNO_STR
Add support of errno_str, used in command pmic and regulator. Signed-off-by: Patrick Delaunay --- configs/stm32mp15_basic_defconfig | 1 + configs/stm32mp15_trusted_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/stm32mp15_basic_defconfig b/configs/stm32mp15_basic_defconfig index 30cfb8d8e1..8a6201bc48 100644 --- a/configs/stm32mp15_basic_defconfig +++ b/configs/stm32mp15_basic_defconfig @@ -144,4 +144,5 @@ CONFIG_VIDEO_STM32=y CONFIG_VIDEO_STM32_DSI=y CONFIG_VIDEO_STM32_MAX_XRES=1280 CONFIG_VIDEO_STM32_MAX_YRES=800 +CONFIG_ERRNO_STR=y CONFIG_FDT_FIXUP_PARTITIONS=y diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig index aefad2b109..394df39d0a 100644 --- a/configs/stm32mp15_trusted_defconfig +++ b/configs/stm32mp15_trusted_defconfig @@ -127,4 +127,5 @@ CONFIG_VIDEO_STM32=y CONFIG_VIDEO_STM32_DSI=y CONFIG_VIDEO_STM32_MAX_XRES=1280 CONFIG_VIDEO_STM32_MAX_YRES=800 +CONFIG_ERRNO_STR=y CONFIG_FDT_FIXUP_PARTITIONS=y -- 2.17.1
[PATCH 10/16] board: stm32mp1: set environment variable fdtfile
For booting Linux in the generic distro mechanism and support of
FDTDIR in extlinux.conf , cmd/pxe.c retrieves the FDT file name
from "fdtfile" environment variable.
Dynamically build this variable with compatible of STMicroelectronics
boards.
Signed-off-by: Patrick Delaunay
---
board/st/stm32mp1/stm32mp1.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 52881adef7..89a088cd28 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -715,10 +715,19 @@ int board_late_init(void)
fdt_compat = fdt_getprop(gd->fdt_blob, 0, "compatible",
_compat_len);
if (fdt_compat && fdt_compat_len) {
- if (strncmp(fdt_compat, "st,", 3) != 0)
+ if (strncmp(fdt_compat, "st,", 3) != 0) {
env_set("board_name", fdt_compat);
- else
+ } else {
+ char dtb_name[256];
+ int buf_len = sizeof(dtb_name);
+
env_set("board_name", fdt_compat + 3);
+
+ strncpy(dtb_name, fdt_compat + 3, buf_len);
+ buf_len -= strlen(fdt_compat + 3);
+ strncat(dtb_name, ".dtb", buf_len);
+ env_set("fdtfile", dtb_name);
+ }
}
ret = uclass_get_device_by_driver(UCLASS_MISC,
DM_GET_DRIVER(stm32mp_bsec),
--
2.17.1
[PATCH 09/16] board: stm32mp1: gt9147 IRQ before reset on EV1
Software workaround for I2C issue on EV1 board,
configure the IRQ line for touchscreen before LCD reset
to fix the used I2C address.
Signed-off-by: Patrick Delaunay
---
board/st/stm32mp1/stm32mp1.c | 41
1 file changed, 41 insertions(+)
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 6ca47509b3..52881adef7 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -626,6 +626,44 @@ static bool board_is_dk2(void)
}
#endif
+static bool board_is_ev1(void)
+{
+ if (CONFIG_IS_ENABLED(TARGET_ST_STM32MP15x) &&
+ (of_machine_is_compatible("st,stm32mp157a-ev1") ||
+of_machine_is_compatible("st,stm32mp157c-ev1") ||
+of_machine_is_compatible("st,stm32mp157d-ev1") ||
+of_machine_is_compatible("st,stm32mp157f-ev1")))
+ return true;
+
+ return false;
+}
+
+/* touchscreen driver: only used for pincontrol configuration */
+static const struct udevice_id goodix_ids[] = {
+ { .compatible = "goodix,gt9147", },
+ { }
+};
+
+U_BOOT_DRIVER(goodix) = {
+ .name = "goodix",
+ .id = UCLASS_NOP,
+ .of_match = goodix_ids,
+};
+
+static int board_ev1_init(void)
+{
+ struct udevice *dev;
+ int ret;
+
+ /* configure IRQ line on EV1 for touchscreen before LCD reset */
+ ret = uclass_get_device_by_driver(UCLASS_NOP, DM_GET_DRIVER(goodix),
+ );
+ if (ret)
+ debug("goodix init failed: %d\n", ret);
+
+ return ret;
+}
+
/* board dependent setup after realloc */
int board_init(void)
{
@@ -643,6 +681,9 @@ int board_init(void)
board_key_check();
+ if (board_is_ev1())
+ board_ev1_init();
+
#ifdef CONFIG_DM_REGULATOR
if (board_is_dk2())
dk2_i2c1_fix();
--
2.17.1
[PATCH 11/16] board: stm32mp1: check env_get result in board_late_init
This patch avoids crash in strcmp when the boot_device is not
present in environment (this case should be never occur)
Signed-off-by: Patrick Delaunay
---
board/st/stm32mp1/stm32mp1.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 89a088cd28..fff4cef2c2 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -753,7 +753,8 @@ int board_late_init(void)
/* Check the boot-source to disable bootdelay */
boot_device = env_get("boot_device");
- if (!strcmp(boot_device, "serial") || !strcmp(boot_device, "usb"))
+ if (boot_device &&
+ (!strcmp(boot_device, "serial") || !strcmp(boot_device, "usb")))
env_set("bootdelay", "0");
return 0;
--
2.17.1
[PATCH 08/16] board: stm32mp1: update management of boot-led
Force boot-led ON and no more rely on default-state.
This patch avoid device-tree modification for U-Boot.
Signed-off-by: Patrick Delaunay
---
arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 4
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 4
board/st/stm32mp1/stm32mp1.c | 10 --
3 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
index 5844d41c53..c52abeb1e7 100644
--- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
@@ -27,10 +27,6 @@
default-state = "off";
status = "okay";
};
-
- blue {
- default-state = "on";
- };
};
};
diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
index ed2f024be9..84af7fa47b 100644
--- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
@@ -28,10 +28,6 @@
default-state = "off";
status = "okay";
};
-
- blue {
- default-state = "on";
- };
};
};
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 8ed09ae24a..6ca47509b3 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -280,9 +280,11 @@ static int get_led(struct udevice **dev, char *led_string)
return 0;
}
+#endif
static int setup_led(enum led_state_t cmd)
{
+#ifdef CONFIG_LED
struct udevice *dev;
int ret;
@@ -292,8 +294,10 @@ static int setup_led(enum led_state_t cmd)
ret = led_set_state(dev, cmd);
return ret;
-}
+#else
+ return 0;
#endif
+}
static void __maybe_unused led_error_blink(u32 nb_blink)
{
@@ -648,8 +652,10 @@ int board_init(void)
sysconf_init();
- if (CONFIG_IS_ENABLED(CONFIG_LED))
+ if (CONFIG_IS_ENABLED(CONFIG_LED)) {
led_default_state();
+ setup_led(LEDST_ON);
+ }
return 0;
}
--
2.17.1
[PATCH 05/16] arm: stm32mp: spl: add bsec driver in SPL
Add the bsec driver in SPL, as it is needed by SOC part number detection.
Signed-off-by: Patrick Delaunay
---
arch/arm/dts/stm32mp15-u-boot.dtsi | 2 +-
arch/arm/mach-stm32mp/Makefile | 2 +-
arch/arm/mach-stm32mp/bsec.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/stm32mp15-u-boot.dtsi
b/arch/arm/dts/stm32mp15-u-boot.dtsi
index 8f9535a4db..e0b1223de8 100644
--- a/arch/arm/dts/stm32mp15-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp15-u-boot.dtsi
@@ -40,7 +40,7 @@
};
{
- u-boot,dm-pre-proper;
+ u-boot,dm-pre-reloc;
};
_csi {
diff --git a/arch/arm/mach-stm32mp/Makefile b/arch/arm/mach-stm32mp/Makefile
index eee39c27c3..f29d6f795f 100644
--- a/arch/arm/mach-stm32mp/Makefile
+++ b/arch/arm/mach-stm32mp/Makefile
@@ -6,11 +6,11 @@
obj-y += cpu.o
obj-y += dram_init.o
obj-y += syscon.o
+obj-y += bsec.o
ifdef CONFIG_SPL_BUILD
obj-y += spl.o
else
-obj-y += bsec.o
obj-$(CONFIG_CMD_STM32KEY) += cmd_stm32key.o
obj-$(CONFIG_ARMV7_PSCI) += psci.o
endif
diff --git a/arch/arm/mach-stm32mp/bsec.c b/arch/arm/mach-stm32mp/bsec.c
index 3b923f088e..1bd287e8bf 100644
--- a/arch/arm/mach-stm32mp/bsec.c
+++ b/arch/arm/mach-stm32mp/bsec.c
@@ -473,7 +473,7 @@ static int stm32mp_bsec_ofdata_to_platdata(struct udevice
*dev)
return 0;
}
-#ifndef CONFIG_STM32MP1_TRUSTED
+#if !defined(CONFIG_STM32MP1_TRUSTED) && !defined(CONFIG_SPL_BUILD)
static int stm32mp_bsec_probe(struct udevice *dev)
{
int otp;
@@ -500,7 +500,7 @@ U_BOOT_DRIVER(stm32mp_bsec) = {
.ofdata_to_platdata = stm32mp_bsec_ofdata_to_platdata,
.platdata_auto_alloc_size = sizeof(struct stm32mp_bsec_platdata),
.ops = _bsec_ops,
-#ifndef CONFIG_STM32MP1_TRUSTED
+#if !defined(CONFIG_STM32MP1_TRUSTED) && !defined(CONFIG_SPL_BUILD)
.probe = stm32mp_bsec_probe,
#endif
};
--
2.17.1
[PATCH 06/16] arm: stm32mp: spl: display error in board_init_f
Update board_init_f and try to display error message
when console is available.
This patch adds trace to debug a spl boot issue when DEBUG
and DEBUG_UART is not activated, after uart probe.
Signed-off-by: Patrick Delaunay
---
arch/arm/mach-stm32mp/spl.c | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-stm32mp/spl.c b/arch/arm/mach-stm32mp/spl.c
index ca4231cd0d..dfdb5bb7e9 100644
--- a/arch/arm/mach-stm32mp/spl.c
+++ b/arch/arm/mach-stm32mp/spl.c
@@ -79,37 +79,36 @@ void spl_display_print(void)
void board_init_f(ulong dummy)
{
struct udevice *dev;
- int ret;
+ int ret, clk, reset, pinctrl;
arch_cpu_init();
ret = spl_early_init();
if (ret) {
- debug("spl_early_init() failed: %d\n", ret);
+ debug("%s: spl_early_init() failed: %d\n", __func__, ret);
hang();
}
- ret = uclass_get_device(UCLASS_CLK, 0, );
- if (ret) {
- debug("Clock init failed: %d\n", ret);
- return;
- }
+ clk = uclass_get_device(UCLASS_CLK, 0, );
+ if (clk)
+ debug("%s: Clock init failed: %d\n", __func__, clk);
- ret = uclass_get_device(UCLASS_RESET, 0, );
- if (ret) {
- debug("Reset init failed: %d\n", ret);
- return;
- }
+ reset = uclass_get_device(UCLASS_RESET, 0, );
+ if (reset)
+ debug("%s: Reset init failed: %d\n", __func__, reset);
- ret = uclass_get_device(UCLASS_PINCTRL, 0, );
- if (ret) {
- debug("%s: Cannot find pinctrl device\n", __func__);
- return;
- }
+ pinctrl = uclass_get_device(UCLASS_PINCTRL, 0, );
+ if (pinctrl)
+ debug("%s: Cannot find pinctrl device: %d\n",
+ __func__, pinctrl);
/* enable console uart printing */
preloader_console_init();
+ if (clk || reset || pinctrl)
+ printf("%s: probe failed clk=%d reset=%d pinctrl=%d\n",
+ __func__, clk, reset, pinctrl);
+
ret = uclass_get_device(UCLASS_RAM, 0, );
if (ret) {
printf("DRAM init failed: %d\n", ret);
--
2.17.1
[PATCH 07/16] board: stm32mp1: Keep error led ON in case of low power detection
From: Patrice Chotard
Since commit commit dd2810851eb1 ("stm32mp1: board: support of
error led on ed1/ev1 board") the attended behavior was no more
respected in case of low power source detection on DK2.
The expected behavior is either the error LED keeps blinking for ever,
or blinks 2 or 3 times and must stay ON.
Signed-off-by: Patrice Chotard
Signed-off-by: Patrick Delaunay
---
board/st/stm32mp1/stm32mp1.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 07f5344ec9..8ed09ae24a 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -316,6 +316,7 @@ static void __maybe_unused led_error_blink(u32 nb_blink)
mdelay(125);
WATCHDOG_RESET();
}
+ led_set_state(led, LEDST_ON);
}
#endif
--
2.17.1
[PATCH 04/16] arm: stm32mp: detect U-Boot version used to save environment
Imply CONFIG_VERSION_VARIABLE for stm32mp1 target
and test U-Boot version ($env_ver) when the environment was
saved for the last time and to display warning trace.
Signed-off-by: Patrick Delaunay
---
arch/arm/mach-stm32mp/Kconfig | 1 +
include/configs/stm32mp1.h| 11 ---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
index 032facff31..a86288cb76 100644
--- a/arch/arm/mach-stm32mp/Kconfig
+++ b/arch/arm/mach-stm32mp/Kconfig
@@ -67,6 +67,7 @@ config TARGET_ST_STM32MP15x
imply DISABLE_CONSOLE
imply PRE_CONSOLE_BUFFER
imply SILENT_CONSOLE
+ imply VERSION_VARIABLE
help
target the STMicroelectronics board with SOC STM32MP15x
managed by board/st/stm32mp1:
diff --git a/include/configs/stm32mp1.h b/include/configs/stm32mp1.h
index 42717c167e..ae060fbc4b 100644
--- a/include/configs/stm32mp1.h
+++ b/include/configs/stm32mp1.h
@@ -222,9 +222,14 @@
"splashimage=0xc430\0" \
"ramdisk_addr_r=0xc440\0" \
"altbootcmd=run bootcmd\0" \
- "env_default=1\0" \
- "env_check=if test $env_default -eq 1;"\
- " then env set env_default 0;env save;fi\0" \
+ "env_check=" \
+ "env exists env_ver || env set env_ver ${ver};" \
+ "if env info -p -d -q; then env save; fi;" \
+ "if test \"$env_ver\" != \"$ver\"; then" \
+ " echo \"*** Warning: old environment ${env_ver}\";" \
+ " echo '* set default: env default -a; env save; reset';" \
+ " echo '* update current: env set env_ver ${ver}; env save';" \
+ "fi;\0" \
STM32MP_BOOTCMD \
STM32MP_MTDPARTS \
STM32MP_DFU_ALT_RAM \
--
2.17.1
[PATCH 01/16] arm: stm32mp: update dependency for STM32_ETZPC
Correct the dependency for STM32 ETZPC protection, linked to SOC
STM32MP identified by CONFIG_STM32MP15x and not linked to
CONFIG_TARGET_STM32MP1 (no more existing).
This patch fix an issue introduced by commit 846254888e2e ("stm32mp1:
split board and SOC support for STM32MP15x family").
Signed-off-by: Patrick Delaunay
Acked-by: Patrice Chotard
---
arch/arm/mach-stm32mp/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
index e4d621dee8..96153693a7 100644
--- a/arch/arm/mach-stm32mp/Kconfig
+++ b/arch/arm/mach-stm32mp/Kconfig
@@ -119,7 +119,7 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_MMC2
config STM32_ETZPC
bool "STM32 Extended TrustZone Protection"
- depends on TARGET_STM32MP1
+ depends on STM32MP15x
default y
help
Say y to enable STM32 Extended TrustZone Protection
--
2.17.1
[PATCH 03/16] arm: stm32mp: reset to default environment when serial# change
Serial number is first checked and, in case of mismatch, all
environment variables are reset to their default value.
This patch allows to detect that environment is saved in a removable
device, as a SD card, and reused on a other board, potentially with
incompatible variables.
Signed-off-by: Patrick Delaunay
---
arch/arm/mach-stm32mp/cpu.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
index 9aa5794334..365c2aa4f7 100644
--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -511,8 +511,9 @@ __weak int setup_mac_address(void)
return -EINVAL;
}
pr_debug("OTP MAC address = %pM\n", enetaddr);
- ret = !eth_env_set_enetaddr("ethaddr", enetaddr);
- if (!ret)
+
+ ret = eth_env_set_enetaddr("ethaddr", enetaddr);
+ if (ret)
pr_err("Failed to set mac address %pM from OTP: %d\n",
enetaddr, ret);
#endif
@@ -522,13 +523,13 @@ __weak int setup_mac_address(void)
static int setup_serial_number(void)
{
+ char *serial_env;
char serial_string[25];
u32 otp[3] = {0, 0, 0 };
struct udevice *dev;
int ret;
- if (env_get("serial#"))
- return 0;
+ serial_env = env_get("serial#");
ret = uclass_get_device_by_driver(UCLASS_MISC,
DM_GET_DRIVER(stm32mp_bsec),
@@ -542,6 +543,15 @@ static int setup_serial_number(void)
return ret;
sprintf(serial_string, "%08X%08X%08X", otp[0], otp[1], otp[2]);
+
+ if (serial_env) {
+ if (!strcmp(serial_string, serial_env))
+ return 0;
+ /* For invalid enviromnent (serial# change), reset to default */
+ env_set_default("serial number mismatch", 0);
+ }
+
+ /* save serial number */
env_set("serial#", serial_string);
return 0;
@@ -549,9 +559,9 @@ static int setup_serial_number(void)
int arch_misc_init(void)
{
+ setup_serial_number();
setup_boot_mode();
setup_mac_address();
- setup_serial_number();
return 0;
}
--
2.17.1
[PATCH 02/16] arm: stm32mp: remove dependency for STM32KEY
This command is not more depending on fuse command, but have direct access to BSEC misc driver, so the dependency wuth can be removed CMD_FUSE Signed-off-by: Patrick Delaunay --- arch/arm/mach-stm32mp/Kconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig index 96153693a7..032facff31 100644 --- a/arch/arm/mach-stm32mp/Kconfig +++ b/arch/arm/mach-stm32mp/Kconfig @@ -127,12 +127,10 @@ config STM32_ETZPC config CMD_STM32KEY bool "command stm32key to fuse public key hash" default y - depends on CMD_FUSE help fuse public key hash in corresponding fuse used to authenticate binary. - config PRE_CON_BUF_ADDR default 0xC02FF000 -- 2.17.1
RE: [PATCH V2 00/14] ARM: stm32: Fix Avenger96
Hi Marek,
> From: Marek Vasut
> Sent: mardi 31 mars 2020 02:49
>
> This series fixes the Avenger96 board. Since there are way too many patches
> floating around on the ML and because I found various other details that
> needed
> fixing, I decided to bundle the whole set of fixes into this series.
>
> This should go into current release, otherwise the board doesn't even boot.
> This V2 is also roughly synchronized with the Linux V2 series fixing very much
> the same issues.
Do you expect all these paches in v2020.04 ? so in 5 days.
I think I can prepare a pull request with bugfix to solve regression, but it
seems late for all the serie.
For me:
> ARM: dts: stm32: Repair SD1 pre-reloc pinmux DT node on AV96
It is clearly a regression since u-boot-stm32-20190717 / v2020.01-rc1 !
The next 4 patches of the serie could be also applied without issue
> ARM: dts: stm32: Add alternate pinmux for SDMMC1 direction pins
> ARM: dts: stm32: Repair SDMMC1 operation on AV96
> ARM: dts: stm32: Add alternate pinmux for SDMMC2 pins 4-7
> ARM: dts: stm32: Repair SDMMC2 operation
But for the rest of the serie, I prefer wait v2020.04 merge window and end of
reviews
(on U-Boot side and on Linux kernel side).
> ARM: dts: stm32: Add QSPI NOR on AV96
> ARM: dts: stm32: Use DT alias for the configuration EEPROM
> ARM: dts: stm32: Add configuration EEPROM on AV96
> ARM: dts: stm32: Add alternate pinmux for ethernet RGMII
> ARM: dts: stm32: Repair ethernet operation on AV96
> ARM: dts: stm32: Add missing ethernet PHY reset on AV96
> ARM: dts: stm32: Repair PMIC configuration on AV96
> ARM: dts: stm32: Adjust PLL4 settings on AV96
> ARM: dts: stm32: Split AV96 into DHCOR SoM and AV96 board
>
> arch/arm/dts/Makefile | 3 +-
> arch/arm/dts/stm32mp157-pinctrl.dtsi | 96 +
> arch/arm/dts/stm32mp157a-avenger96.dts| 365 +-
> arch/arm/dts/stm32mp15xx-dhcom.dtsi | 6 +-
> .../stm32mp15xx-dhcor-avenger96-u-boot.dtsi | 80
> arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts | 211 ++ ...oot.dtsi
> => stm32mp15xx-dhcor-u-boot.dtsi} | 80 +---
> arch/arm/dts/stm32mp15xx-dhcor.dtsi | 231 +++
> board/dhelectronics/dh_stm32mp1/board.c | 15 +-
> doc/board/st/stm32mp1.rst | 8 +-
> 10 files changed, 645 insertions(+), 450 deletions(-) create mode 100644
> arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi
> create mode 100644 arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts
> rename arch/arm/dts/{stm32mp157a-avenger96-u-boot.dtsi => stm32mp15xx-
> dhcor-u-boot.dtsi} (73%) create mode 100644 arch/arm/dts/stm32mp15xx-
> dhcor.dtsi
>
> Cc: Patrick Delaunay
> Cc: Patrice Chotard
Regards
> --
> 2.25.1
Re: [PATCH 1/3] Dockerfile: Install riscv32 toolchain from kernel.org
On Sat, Mar 28, 2020 at 07:55:37AM +0800, Bin Meng wrote: > Hi Tom, > > On Fri, Mar 27, 2020 at 11:25 PM Tom Rini wrote: > > > > On Fri, Mar 27, 2020 at 02:05:55PM +0800, Bin Meng wrote: > > > Hi Tom, > > > > > > On Fri, Mar 27, 2020 at 10:00 AM Tom Rini wrote: > > > > > > > > On Fri, Mar 27, 2020 at 09:57:47AM +0800, Bin Meng wrote: > > > > > Hi Tom, > > > > > > > > > > On Fri, Mar 27, 2020 at 12:14 AM Tom Rini wrote: > > > > > > > > > > > > On Thu, Mar 26, 2020 at 09:04:52AM -0700, Bin Meng wrote: > > > > > > > > > > > > > This is required to build GRUB UEFI target for RISC-V 32-bit. > > > > > > > > > > > > > > Signed-off-by: Bin Meng > > > > > > > > > > > > Since we can use the 64bit toolchain for 32bit U-Boot, can we not > > > > > > pass > > > > > > GRUB the right flags to use the same toolchain? Thanks! > > > > > > > > > > The 32-bit GRUB won't build with the 64-bit toolchain as of the > > > > > grub-2.04 branch we are using. > > > > > > > > Is that something that upstream has fixed or will fix / can be fixed and > > > > we can bump the tag we're using for? > > > > > > I tried the latest upstream GRUB, and it still cannot be built using > > > riscv64 toolchain from kernel.org. > > > > Can that be fixed? Would that be accepted? Thanks! > > > > I reported this issue to the grub mailing list. For now I believe we > should stick to current 2.04 until upstream has a solution for it. Has upstream said anything here? Thanks! -- Tom signature.asc Description: PGP signature
RE: [PATCH V2 14/14] ARM: dts: stm32: Split AV96 into DHCOR SoM and AV96 board
Hi,
> From: Marek Vasut
> Sent: mardi 31 mars 2020 02:49
>
> The AV96 is in fact an assembly of DH Electronics DHCOR SoM on top of an
> AV96 reference board. Split the DTs to reflect that and make sure to DHCOR SoM
> can be reused on other boards easily.
>
> It is also highly recommended to configure the board for the DHCOM make
> stm32mp15_dhcom_basic_defconfig make DEVICE_TREE=stm32mp15xx-dhcor-
> avenger96
> as that permits reusing the board code for the DH components, like accessing
> and
> reading out the ethernet MAC from EEPROM.
Recommended or mandatory...
For my point of view
- board/st/stm32mp1 manage the ST board (STM32MP15x-DKX and STM32MP15x-EV1)
Can be used as starting point for customer new
board
- board/dhelectronics/dh_stm32mp1 manage the board based on DHCOR SoM or can be
a starting point of SoM user
For AV96, the first upstream was directly based on ST board, but I agree : it
is clearly not a perfect solution (MAC address issue for example)
=> support on this board should be in dh_stm32mp1 board or create a new board
AV96 based on it.
And I need to continue to move in st/common the part common for all the
STM32MP157 boards
> Signed-off-by: Marek Vasut
> Cc: Patrick Delaunay
> Cc: Patrice Chotard
> ---
> V2: No change
> ---
> arch/arm/dts/Makefile | 3 +-
> arch/arm/dts/stm32mp157a-avenger96.dts| 421 +-
> .../stm32mp15xx-dhcor-avenger96-u-boot.dtsi | 80
> arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts | 211 + ...oot.dtsi =>
> stm32mp15xx-dhcor-u-boot.dtsi} | 79 +---
> arch/arm/dts/stm32mp15xx-dhcor.dtsi | 231 ++
> doc/board/st/stm32mp1.rst | 8 +-
> 7 files changed, 535 insertions(+), 498 deletions(-) create mode 100644
> arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi
> create mode 100644 arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts
> rename arch/arm/dts/{stm32mp157a-avenger96-u-boot.dtsi => stm32mp15xx-
> dhcor-u-boot.dtsi} (75%) create mode 100644 arch/arm/dts/stm32mp15xx-
> dhcor.dtsi
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
> 9c593b2c98..2564f790de 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -884,7 +884,8 @@ dtb-$(CONFIG_STM32MP15x) += \
> stm32mp157c-dk2.dtb \
> stm32mp157c-ed1.dtb \
> stm32mp157c-ev1.dtb \
> - stm32mp15xx-dhcom-pdk2.dtb
> + stm32mp15xx-dhcom-pdk2.dtb \
> + stm32mp15xx-dhcor-avenger96.dtb
Force device tree support for each target ?
Avoid to mix incompatible device tree and defconfig
dtb-$(TARGET_ST_STM32MP15x) += \
stm32mp157a-dk1.dtb \
stm32mp157c-dk2.dtb \
stm32mp157c-ed1.dtb \
stm32mp157c-ev1.dtb
dtb-$(TARGET_DH_STM32MP1_PDK2) += \
stm32mp15xx-dhcom-pdk2.dtb \
stm32mp15xx-dhcor-avenger96.dtb
> dtb-$(CONFIG_SOC_K3_AM6) += k3-am654-base-board.dtb k3-am654-r5-base-
> board.dtb
> dtb-$(CONFIG_SOC_K3_J721E) += k3-j721e-common-proc-board.dtb \ diff --git
> a/arch/arm/dts/stm32mp157a-avenger96.dts b/arch/arm/dts/stm32mp157a-
> avenger96.dts
> index 4fa20bc31d..9c165104fb 100644
> --- a/arch/arm/dts/stm32mp157a-avenger96.dts
> +++ b/arch/arm/dts/stm32mp157a-avenger96.dts
> @@ -4,422 +4,5 @@
> * Author: Manivannan Sadhasivam
> */
>
> -/dts-v1/;
> -
> -#include "stm32mp157c.dtsi"
> -#include "stm32mp157xac-pinctrl.dtsi"
> -#include
> -#include
> -
> -/ {
> - model = "Arrow Electronics STM32MP157A Avenger96 board";
> - compatible = "arrow,stm32mp157a-avenger96", "st,stm32mp157";
> -
> - aliases {
> - ethernet0 =
> - mmc0 =
> - serial0 =
> - serial1 =
> - spi0 =
> - };
> -
> - chosen {
> - stdout-path = "serial0:115200n8";
> - };
> -
> - memory@c000 {
> - device_type = "memory";
> - reg = <0xc000 0x4000>;
> - };
> -
> - led {
> - compatible = "gpio-leds";
> - led1 {
> - label = "green:user1";
> - gpios = < 7 GPIO_ACTIVE_HIGH>;
> - linux,default-trigger = "heartbeat";
> - default-state = "off";
> - };
> -
> - led2 {
> - label = "green:user2";
> - gpios = < 3 GPIO_ACTIVE_HIGH>;
> - linux,default-trigger = "mmc0";
> - default-state = "off";
> - };
> -
> - led3 {
> - label = "green:user3";
> - gpios = < 0 GPIO_ACTIVE_HIGH>;
> - linux,default-trigger = "mmc1";
> - default-state = "off";
> - };
> -
> - led4 {
> - label = "green:user3";
> - gpios = < 1 GPIO_ACTIVE_HIGH>;
> - linux,default-trigger = "none";
> -
Re: [RFC PATCH 6/9] mkimage_fit_atf.sh: produce working binaries by default
On Mon, Mar 23, 2020 at 04:24:15PM +0100, Petr Štetiar wrote: > Michal Simek [2020-03-23 14:58:55]: > > Hi, > > > Plan is to merge all of these to one shell script because most of the > > content in that script is very similar. > > to me it all just seems as values and templates hidden inside shell script > called generator. Each of this generators uses/references 1-N variables, 1-N > out-of-tree dependencies and 1-N DT sections. > > So instead of cooking custom shell templating engine I took different > approach[1] and simply removed the shell script generator in favor of Python > based templating engine, allowing for ITS dependency tracking and values > directly in Make. > > Lets see what is preferred. An example of one is never enough to see if something is generic enough for everyone. Even if you can't functional-test other platforms an initial conversion will help and allow others to test. And it'll help show if the idea is or is not cleaner. > > The issue which I see is that patch above is changing current behavior > > which means when this is applied all travis/gitlab/azure jobs will fail > > because none has setup this config option. > > If that is desired, then in order to keep the current behavior, I see > following options: > > 1. Disable building of boards having out-of-tree dependencies on build bot/CI > 2. Enable BUILDBOT_BROKEN_BINARIES=y by default > 3. Add detection of various build bot/CI platforms and enable > BUILDBOT_BROKEN_BINARIES=y by default, which then could cause further > issues > when one would actually run test the binaries from build bot/CI > 4. Include the out-of-tree dependencies (unlikely) Cycling back here, sorry for the delay. First, you need to make CI still work. And we can't remove boards that require something else from CI as that means basically dropping all of arm64. > What is your suggestion? There's two sides to this. First, the problem of "all of these similar but not quite the same tools" needs a generic solution. A template based tool is probably the right direction here, yes. But second, what would it take to modify the CI jobs to pass in an empty file or whatever so they link but not function. So that a real user would have to provide a file too. And whichever of Azure, GitLab or Travis is easier for you to test / adapt for this, I can update the others once it looks clean. Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 4/5] rockchip: rk3399: Enable CONFIG_RNG_ROCKCHIP
On Tue, Mar 31, 2020 at 12:36 PM Lin Jinhan wrote: > > CONFIG_RNG_ROCKCHIP/CONFIG_DM_RNG is enabled. This should be universally available by default on all rk3399 devices shouldn't it or does it need external regulators or something that is per device? If so shouldn't we just enable it by default for the SoC? > Signed-off-by: Lin Jinhan > --- > configs/evb-rk3399_defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig > index 3f74be3b3c..7f14e18b1b 100644 > --- a/configs/evb-rk3399_defconfig > +++ b/configs/evb-rk3399_defconfig > @@ -39,6 +39,8 @@ CONFIG_PMIC_RK8XX=y > CONFIG_REGULATOR_PWM=y > CONFIG_REGULATOR_RK8XX=y > CONFIG_PWM_ROCKCHIP=y > +CONFIG_DM_RNG=y > +CONFIG_RNG_ROCKCHIP=y > CONFIG_BAUDRATE=150 > CONFIG_DEBUG_UART_SHIFT=2 > CONFIG_SYSRESET=y > -- > 2.17.1 > > >
RE: [PATCH V2 13/14] ARM: dts: stm32: Adjust PLL4 settings on AV96
Hi Marek, > From: Marek Vasut > Sent: mardi 31 mars 2020 02:49 > > The PLL4 is supplying SDMMC12, SDMMC3 and SPDIF with 120 MHz and > FDCAN with 96 MHz. This isn't good for the SDMMC interfaces, which can not > easily divide the clock down to e.g. 50 MHz for high speed SD and eMMC > devices, so those devices end up running at 30 MHz as that is 120 MHz / 4. > Adjust the PLL4 settings such that both PLL4P and PLL4R run at 100 MHz > instead, which is easy to divide to 50MHz for optimal operation of both SD and > eMMC, SPDIF clock are not that much slower and FDCAN is also unaffected. > > Signed-off-by: Marek Vasut > Cc: Patrick Delaunay > Cc: Patrice Chotard > --- > V2: Move this patch before the split of AV96 into SoM and carrier > --- Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH v2 0/3] ARC: IO: rework IO accessors
On Mon, Mar 30, 2020 at 09:30:37PM +, Alexey Brodkin wrote:
> Hi Tom,
>
> > -Original Message-
> > From: Eugeniy Paltsev
> > Sent: Monday, March 30, 2020 10:45 PM
> > To: uboot-snps-...@synopsys.com; Alexey Brodkin
> > Cc: u-boot@lists.denx.de; Eugeniy Paltsev
> > Subject: [PATCH v2 0/3] ARC: IO: rework IO accessors
> >
> > Fixing of DW SPI which was broken by
> > commit 07906b3dad15 ("ARC: Switch to generic accessors")
> > lead me to several fixes in ARC IO accessors code.
> >
> > Eugeniy Paltsev (3):
> > ARC: IO: add volatile to accessors
> > ARC: IO: add compiler barriers to IO accessors
> > ARC: IO: add MB for __raw_* memory accessors
> >
> > arch/arc/include/asm/io.h | 93 +--
> > 1 file changed, 60 insertions(+), 33 deletions(-)
>
> Just a heads-up: that's an important last-minute fix which we need to get
> some peripherals working on our boards.
>
> So given we're 6 days before release and this is as usual only
> touching ARC code I'm going to pull this series in ASAP
> and then send you my pull-request if you don't mind.
That's fine, thanks for the heads-up!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 5/8] xhci: mediatek: Add support for MTK xHCI host controller
HI Marek, On Tue, 31 Mar 2020 at 07:29, Marek Vasut wrote: > > On 3/31/20 3:24 PM, Simon Glass wrote: > > Hi Marek, > > > > On Mon, 30 Mar 2020 at 18:39, Marek Vasut wrote: > >> > >> On 3/31/20 1:31 AM, Simon Glass wrote: > >>> Hi Marek, > >> > >> Hi, > >> > >>> On Sun, 22 Mar 2020 at 09:34, Marek Vasut wrote: > > On 3/22/20 4:17 PM, Simon Glass wrote: > > Hi Marek, > > Hi, > > > On Sat, 21 Mar 2020 at 20:15, Marek Vasut wrote: > >> > >> On 3/22/20 3:08 AM, Simon Glass wrote: > >>> Hi Marek, > >> > >> Hi, > >> > >>> I think at this point we've covered all the ground and mentioned the > >>> pros and cons of each method, so I'll leave the discussion where it > >>> is. > >> > >> Great, so let's remove the struct-based access from the driver and use > >> regular #define REGISTER 0xoffset. > > > > I think any individual decision depends on the pros and cons we > > outlined in our discussion. I don't have any information to suggest > > that the Mediatek XHCI driver has any of the variations you talked > > about in your worst-case scenarios, so I can't comment on that. I am > > more concerned about this as a general rule as I feel that the > > struct-based approach is generally best for U-Boot, except for the > > cases you highlighted: > > > > - where the registers appear at different offsets in different > > hardware revisions served by the same driver > > - where the driver only uses a small subset of the registers and it is > > not worth defining a struct to cover them all, with associated empty > > regions, etc. > > > > Anything else? > > It's also very difficult to easily figure out the address of a register > that's buried somewhere down in a long structure, possibly with embedded > sub-structures. > >>> > >>> OK I have updated the coding style page with all of this. > >> > >> Which page ? > > > > https://www.denx.de/wiki/U-Boot/CodingStyle > > " U-Boot typically uses a C structure to map out the registers in an I/O > region, rather than offsets. The reasons for this are: " is misleading > and suggests that using structures is the best practice. This should be > reworded to make it clear both options are equally valid. I'd like to see a preference to use struct where it makes sense and not use it when it doesn't, with the different tradeoffs clearly written. Are asking that we say nothing about which is better in each situation? > > > Separately, I sent a patch a while back which updated checkpatch for > > U-Boot. I got some pushback > > Link ? > http://patchwork.ozlabs.org/patch/999510/ > I am very much opposed to this struct-based approach, so there is my > pushback too. I think we should NOT do it. Right, but there are arguments on both sides. I strongly prefer it where it makes sense, for reasons that we've already discussed. > > >, but I think that was wrong and we should > > do it. For example I am saying many of the same things in code reviews > > and many of them could be caught by the script. Examples include using > > if() instead of #if where possible. > > > > Regards, > > Simon > > Regards, Simon
Re: [U-Boot] [PATCH v1 2/2] gpio: stm32f7: Fix SPL code size
On 3/31/20 1:22 PM, Marek Vasut wrote:
> On 3/31/20 10:12 AM, Patrice CHOTARD wrote:
>> Hi Marek
> Hi,
>
>> On 3/31/20 4:51 AM, Marek Vasut wrote:
>>> On 1/4/19 10:55 AM, Patrice Chotard wrote:
>>>
>>> Hi,
>>>
@@ -215,7 +220,9 @@ U_BOOT_DRIVER(gpio_stm32) = {
.id = UCLASS_GPIO,
.of_match = stm32_gpio_ids,
.probe = gpio_stm32_probe,
+#ifndef CONFIG_SPL_BUILD
.ops= _stm32_ops,
+#endif
.flags = DM_UC_FLAG_SEQ_ALIAS,
.priv_auto_alloc_size = sizeof(struct stm32_gpio_priv),
};
>>> The U-Boot DM GPIO uclass code assumes the .ops is always non-NULL.
>>> Hence, this patch breaks all GPIO access (actually crashes SPL) on STM32
>>> in SPL.
>> I suppose it breaks AV96 boot ?
> No, it does not. I was trying to read GPIO value in SPL and found this.
>
>> On my side i have checked on v2020-04-rc4 U-boot release, by reverting
>> "gpio: stm32f7: Fix SPL code size"
>>
>> the stm32f7 SPL code size is below the 32Kb limit.
>>
>> I will send a patch to revert it.
> OK sure, does that apply to all the STM32 systems ?
Yes, all STM32 based platforms (F4/F7/H7 and MP1) are using this gpio driver.
>
