Re: [PATCH v4 8/9] mtd: spi-nor-core: Add fixups for Cypress s25hl-t/s25hs-t
Hi Pratyush,
On 2/2/2021 4:22 AM, Pratyush Yadav wrote:
> On 28/01/21 01:37PM, tkuw584...@gmail.com wrote:
>> From: Takahiro Kuwano
>>
>> Add nor->setup() and fixup hooks to overwrite:
>> - volatile QE bit
>> - the ->ready() hook for dual/quad die package parts
>> - overlaid erase
>> - spi_nor_flash_parameter
>> - mtd_info
>>
>> Signed-off-by: Takahiro Kuwano
>> ---
>> drivers/mtd/spi/spi-nor-core.c | 108 +
>> 1 file changed, 108 insertions(+)
>>
>> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
>> index ef49328a28..3d8cb9c333 100644
>> --- a/drivers/mtd/spi/spi-nor-core.c
>> +++ b/drivers/mtd/spi/spi-nor-core.c
>> @@ -2648,8 +2648,116 @@ static int spi_nor_init(struct spi_nor *nor)
>> return 0;
>> }
>>
>> +#ifdef CONFIG_SPI_FLASH_SPANSION
>> +static int s25hx_t_mdp_ready(struct spi_nor *nor)
>> +{
>> +u32 addr;
>> +int ret;
>> +
>> +for (addr = 0; addr < nor->mtd.size; addr += SZ_128M) {
>> +ret = spansion_sr_ready(nor, addr, 0);
>> +if (ret != 1)
>> +return ret;
>> +}
>> +
>> +return 1;
>> +}
>> +
>> +static int s25hx_t_quad_enable(struct spi_nor *nor)
>> +{
>> +u32 addr;
>> +int ret;
>> +
>> +for (addr = 0; addr < nor->mtd.size; addr += SZ_128M) {
>> +ret = spansion_quad_enable_volatile(nor, addr, 0);
>
> So you need to set the QE bit on each die. Ok.
>
> Out of curiosity, what will happen if you only set the QE bit on the
> first die? Will reads from first die work in quad mode and rest in
> single mode?
>
If the host issues quad read command, only the first die works and rest
do not respond to the quad read command.
>> +if (ret)
>> +return ret;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static int s25hx_t_setup(struct spi_nor *nor, const struct flash_info *info,
>> + const struct spi_nor_flash_parameter *params,
>> + const struct spi_nor_hwcaps *hwcaps)
>> +{
>> +#ifdef CONFIG_SPI_FLASH_BAR
>> +return -ENOTSUPP; /* Bank Address Register is not supported */
>> +#endif
>> +/*
>> + * The Cypress Semper family has transparent ECC. To preserve
>> + * ECC enabled, multi-pass programming within the same 16-byte
>> + * ECC data unit needs to be avoided. Set writesize to the page
>> + * size and remove the MTD_BIT_WRITEABLE flag in mtd_info to
>> + * prevent multi-pass programming.
>> + */
>> +nor->mtd.writesize = params->page_size;
>
> The writesize should be set to 16. See [0][1][2].
>
>> +nor->mtd.flags &= ~MTD_BIT_WRITEABLE;
>
> Not needed. See discussions pointed to above.
>
OK, thank you for the information.
>> +
>> +/* Emulate uniform sector architecure by this erase hook*/
>> +nor->mtd._erase = spansion_overlaid_erase;
>> +
>> +/* For 2Gb (dual die) and 4Gb (quad die) parts */
>> +if (nor->mtd.size > SZ_128M)
>> +nor->ready = s25hx_t_mdp_ready;
>> +
>> +/* Enter 4-byte addressing mode for WRAR used in quad_enable */
>> +set_4byte(nor, info, true);
>> +
>> +return spi_nor_default_setup(nor, info, params, hwcaps);
>> +}
>> +
>> +static void s25hx_t_default_init(struct spi_nor *nor)
>> +{
>> +nor->setup = s25hx_t_setup;
>> +}
>> +
>> +static int s25hx_t_post_bfpt_fixup(struct spi_nor *nor,
>> + const struct sfdp_parameter_header *header,
>> + const struct sfdp_bfpt *bfpt,
>> + struct spi_nor_flash_parameter *params)
>> +{
>> +/* Default page size is 256-byte, but BFPT reports 512-byte */
>> +params->page_size = 256;
>
> Read the page size from the register, like it is done on Linux for S28
> flash family.
>
Will fix.
>> +/* Reset erase size in case it is set to 4K from BFPT */
>> +nor->mtd.erasesize = 0;
>
> What does erasesize of 0 mean? I would take that to mean that the flash
> does not support erases. I can't find any mention of 0 erase size in the
> documentation of struct mtd_info.
>
In this device, the erasesize is wrongly configured to 4K through BFPT
parse. I would reset it to 0 expecting the correct value is set in
spi_nor_select_erase() afterwards. But I should simply set correct value
in this fixup hook.
>> +
>> +return 0;
>> +}
>> +
>> +static void s25hx_t_post_sfdp_fixup(struct spi_nor *nor,
>> +struct spi_nor_flash_parameter *params)
>> +{
>> +/* READ_FAST_4B (0Ch) requires mode cycles*/
>> +params->reads[SNOR_CMD_READ_FAST].num_mode_clocks = 8;
>> +/* PP_1_1_4 is not supported */
>> +params->hwcaps.mask &= ~SNOR_HWCAPS_PP_1_1_4;
>> +/* Use volatile register to enable quad */
>> +params->quad_enable = s25hx_t_quad_enable;
>> +}
>> +
>> +static struct spi_nor_fixups s25hx_t_fixups = {
>> +.default_init = s25hx_t_default_init,
>> +.post_bfpt = s25hx_t_post_bfpt_fixup,
>> +
Re: [RFC RESEND 1/2] efi: Add ESRT to the EFI system table
On Fri, Feb 12, 2021 at 03:17:30PM +0100, Heinrich Schuchardt wrote: > On 29.01.21 06:26, AKASHI Takahiro wrote: > > First of all, one comment: > > It would be nice to have a list of what features are supported > > and what are not in this patch series. > > For example, with this patch, I suspect > > - FwVersion in ESRT entry will never be updated at capsule update > > According to the UEFI specification the ESRT should be updated > > * at EFI_EVENT_GROUP_READY_TO_BOOT > * when a device (with a Firmware Management Protocol) is added or removed > * after Update Capsule > * at EFI_EVENT_GROUP_EXIT_BOOT_SERVICES > > At each of these events we can call the same function collection the > information for a new ESRT by calling > EFI_FIRMWARE_MANAGEMENT_PROTOCOL.GetImageInfo() and freeing the memory > of the old instance. > > Monitoring EFI_EVENT_GROUP_READY_TO_BOOT and > EFI_EVENT_GROUP_EXIT_BOOT_SERVICESs seems redundant if we catch the > other two. > > > - LastAttemptVersion/LastAttemptStatus will not be sustained across reboots. > > This information is provided by the Firmware Management Protocol (see > 23.4.3 Mapping Firmware Management Protocol Descriptors to ESRT > Entries). Jose's patches can only use the information provided by the > code that Sughosh and you created. Right. I have forgot that. > If update status persistence is missing in the current implementation of > the firmware management protocol, what are your plans for adding it? No plan. Since there is no notion of "versioning" in the current U-Boot firmware, providing such information would be vendor-specific. Sughosh may have his own idea relating to A/B update and anti-rollback protection. -Takahiro Akashi > Best regards > > Heinrich > > > > > So I'm not sure that the proposed implementation is useful > > in a practical manner. > > >
Re: [PATCH v4 1/1] timer: imx-gpt: Add timer support for i.MX SoCs family
On 2/14/21 4:55 AM, Jesse wrote:
From: Jesse Taube
This timer driver is using GPT Timer (General Purpose Timer) available on
almost all i.MX SoCs family.
Since this driver is only meant to provide u-boot's timer and counter,
and most of the i.MX* SoCs use a 24Mhz crystal, let's only deal with that
specific source.
Still too many columns ^^^
Signed-off-by: Giulio Benetti
Signed-off-by: Jesse Taube
---
drivers/timer/Kconfig | 7 ++
drivers/timer/Makefile| 1 +
drivers/timer/imx-gpt-timer.c | 153 ++
3 files changed, 161 insertions(+)
create mode 100644 drivers/timer/imx-gpt-timer.c
diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index 80743a2551..ee81dfa776 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -227,4 +227,11 @@ config MCHP_PIT64B_TIMER
Select this to enable support for Microchip 64-bit periodic
interval timer.
+config IMX_GPT_TIMER
+ bool "NXP i.MX GPT timer support"
+ depends on TIMER
+ help
+ Select this to enable support for the timer found on
+ NXP i.MX devices.
+
endmenu
diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
index eb5c48cc6c..e214ba7268 100644
--- a/drivers/timer/Makefile
+++ b/drivers/timer/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_STM32_TIMER) += stm32_timer.o
obj-$(CONFIG_X86_TSC_TIMER) += tsc_timer.o
obj-$(CONFIG_MTK_TIMER) += mtk_timer.o
obj-$(CONFIG_MCHP_PIT64B_TIMER) += mchp-pit64b-timer.o
+obj-$(CONFIG_IMX_GPT_TIMER)+= imx-gpt-timer.o
diff --git a/drivers/timer/imx-gpt-timer.c b/drivers/timer/imx-gpt-timer.c
new file mode 100644
index 00..e7e46c8037
--- /dev/null
+++ b/drivers/timer/imx-gpt-timer.c
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020
+ * Author(s): Giulio Benetti
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define GPT_CR_SWR 0x8000
+#define GPT_CR_EN_24M 0x0400
Too any tabs
+#define GPT_CR_EN 0x0001
+#define GPT_PR_PRESCALER 0x0FFF
+
+#define GPT_CLKSRC_IPG_CLK (1 << 6)
+#define GPT_CLKSRC_IPG_CLK_24M (5 << 6)
Ditto ^^^
+
+struct imx_gpt_timer_regs {
+ u32 cr;
+ u32 pr;
+ u32 sr;
+ u32 ir;
+ u32 ocr1;
+ u32 ocr2;
+ u32 ocr3;
+ u32 icr1;
+ u32 icr2;
+ u32 cnt;
+};
+
+struct imx_gpt_timer_priv {
+ struct imx_gpt_timer_regs *base;
+};
+
+static u64 imx_gpt_timer_get_count(struct udevice *dev)
+{
+ struct imx_gpt_timer_priv *priv = dev_get_priv(dev);
+ struct imx_gpt_timer_regs *regs = priv->base;
+
+ return readl(>cnt);
+}
+
+static inline void imx_gpt_setup_24M(struct imx_gpt_timer_regs *regs)
+{
+ writel(GPT_CLKSRC_IPG_CLK_24M | GPT_CR_EN_24M, >cr);
+}
+
+static inline void imx_gpt_setup_per(struct imx_gpt_timer_regs *regs)
+{
+ writel(GPT_CLKSRC_IPG_CLK, >cr);
+}
+
+static inline void imx_gpt_sof_reset(struct imx_gpt_timer_regs *regs)
+{
+ /* Reset the timer */
+ setbits_le32(>cr, GPT_CR_SWR);
+
+ /* Wait for timer to finish reset */
+ while (readl(>cr) & GPT_CR_SWR)
+ ;
+}
+
+static int imx_gpt_setup(u32 rate, struct imx_gpt_timer_regs *regs)
+{
+ u32 prescaler;
+
+ imx_gpt_sof_reset(regs);
This function ^^^ can be avoided at the moment since it's called only
from here and it only set a bit and loop-check it.
+
+ /* Set timer frequency to 1MHz */
+ prescaler = (rate / CONFIG_SYS_HZ_CLOCK) - 1;
+
+ if (prescaler > GPT_PR_PRESCALER)
+ return -EINVAL;
+ /* We set timer prescaler to obtain a 1MHz timer counter frequency */
+ writel(prescaler, >pr);
Prescaler setting is specific to PER case and should go inside the two
functions imx_gpt_setup_per/24M().
+
+ if (rate != 2400UL)
+ imx_gpt_setup_per(regs);
... this ^^^
+ else
+ imx_gpt_setup_24M(regs);
...and this ^^^
Also, I've taken a look again at linux driver[1] and like here in u-boot
they set as prescaler to 8 for 24M to obtina 3Mhz. And that is for
compatibility with u-boot I think, so here I would try to set prescaler
for having timer frequency set to 3Mhz instead of 1Mhz. And this could
be true for the PER clock source, but of course you have to set 24M
prescaler(to 8) or PER prescaler(the one you use) the way already do.
[1]:
https://github.com/torvalds/linux/blob/master/drivers/clocksource/timer-imx-gpt.c#L301-L312
For the rest it looks good. On next iteration, patch should be ready to
be tested on my imxrt1050-evk.
Thank you
Best regards
--
Giulio Benetti
Benetti Engineering sas
+
+ /* Start timer */
+ setbits_le32(>cr,
Re: [PATCH v4 0/1] timer: imx-gpt: Add timer support for i.MX SoCs family
Hi Jesse, On 2/14/21 4:55 AM, Jesse wrote: From: Jesse Taube This timer driver is using GPT Timer (General Purpose Timer) available on almost all i.MX SoCs family. Since this driver is only meant to provide u-boot's timer and counter, and most of the i.MX* SoCs use a 24Mhz crystal, let's only deal with that specific source. Jesse Taube (1): timer: imx-gpt: Add timer support for i.MX SoCs family Since you're only sending a patch you should not include a cover letter. A cover letter should be included when your patches are more than one and they deal the same subject. So here you should only write a summary about it, like: ''' Subject: Add i.MX GPT timer support This pachset adds i.MX GPT timer support and a modify to dts for imxrt1050-ekv that enables you to check its functionality. ''' drivers/timer/Kconfig | 7 ++ drivers/timer/Makefile| 1 + drivers/timer/imx-gpt-timer.c | 153 ++ 3 files changed, 161 insertions(+) create mode 100644 drivers/timer/imx-gpt-timer.c --- V1->V2: * Fixed indentation * Fixed capitals * Made timer work on only 24MHz clock V2->V3: * Fixed indentation * Made implementation imatate the Linux kernel * Fix wrong definition V3->V4: * Fixed indentation * Made bit manipluation into its own function. --- You should move ^^^ these changes as they are in patch 1/1. Also take care that this patch is difficult to test alone since a defconfig(this is easy to enable) and a dts(this is really welcome) are missing, then you should also include at least the dts you were working at least. And that makes sense to have a patchset again then(because of 2 patches). -- Giulio Benetti Benetti Engineering sas
qemu arm: increasing log-level causes exception
Hello,
I wanted to observe some debug messages, so I increased the log level
from 6 to 7. Otherwise, my configuration matches 'qemu_arm_defconfig'.
This resulted in a PREFETCH fault. The backtrace is included below.
My u-boot version is v2021.01. My compiler is arm-none-eabi-gcc 7.3.1
from Debian. I tested qemu 3.1.0 (from Debian) and 5.1.0 (which I
built), invoked like this:
qemu-system-arm -machine virt -cpu cortex-a15 -m 2G -bios
u-boot/build.qemu_arm/u-boot.bin
I think this is happening because the code has been relocated and the
MMU enabled, but the functions pointed to by
gd->cur_serial_dev->driver->ops still point to the code in flash:
(gdb) p *((struct dm_serial_ops*)(gd->cur_serial_dev->driver->ops))
$3 = {setbrg = 0x4296c , getc = 0x42af0
, putc = 0x42b34 , pending =
0x42b68 , clear = 0x0 ,
getconfig = 0x0 , setconfig = 0x0
, getinfo = 0x0 }
I was able to workaround this behavior by adding
gd->cur_serial_dev = NULL;
in board_init_r before the post-relocation initialization sequence is
executed. Rearranging init_sequence_r so that log_init runs after
serial_initialize works too.
I would like to contribute a patch, but I require some guidance. Is
there a better way to indicate that log messages should not be output
until the driver has been reinitialized by board_init_r? Or is there a
better initialization order?
Thanks and best regards,
Zack Marvel
Backtrace:
#0 pl01x_serial_putc (dev=0x401fe180, ch=105 'i') at
../drivers/serial/serial_pl01x.c:316
#1 0xbff73504 in _serial_putc (dev=dev@entry=0x401fe180, ch=out>) at ../drivers/serial/serial-uclass.c:187
#2 0xbff736a8 in _serial_puts (str=0xbedf0a05 "nitcall: 00017180
(relocated to bff48180)\n", dev=0x401fe180) at
../drivers/serial/serial-uclass.c:194
#3 serial_puts (str=) at
../drivers/serial/serial-uclass.c:271
#4 0xbffb0e30 in printf (fmt=0xbffd0c6a "%s%s") at ../lib/vsprintf.c:805
#5 0xbff58f24 in log_console_emit (ldev=,
rec=0xbedf0c44) at ../common/log_console.c:39
#6 0xbff58cc4 in log_dispatch (rec=0xbedf0c3c) at ../common/log.c:218
#7 _log (cat=LOGC_NONE, level=LOGL_DEBUG, file=,
line=, func=0xbffbcdb1 "initcall_run_list",
fmt=0xbffc0ef3 "initcall: %p (relocated to %p)\n") at ../common/log.c:252
#8 0xbff48388 in initcall_run_list (init_sequence=0xbffe03a0) at
../include/initcall.h:39
#9 board_init_r (new_gd=, dest_addr=) at
../common/board_r.c:928
#10 0xbff327cc in ?? () at ../arch/arm/lib/crt0.S:167
[PATCH v2] sunxi: support boot console on uart1 for sun8i
The A23, A33, H3, H5, A83T, V3 and Sochip S3 sun8i SoCs can mux uart1 on
GPIOs PG6 and PG7. This patch adds support for using uart1 on those pins
as boot console.
Signed-off-by: Tobias Schramm
---
arch/arm/include/asm/arch-sunxi/gpio.h | 1 +
arch/arm/mach-sunxi/board.c| 5 +
2 files changed, 6 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index de77bf638e..2969a530ae 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -190,6 +190,7 @@ enum sunxi_gpio_number {
#define SUN5I_GPG_SDC1 2
#define SUN6I_GPG_SDC1 2
#define SUN8I_GPG_SDC1 2
+#define SUN8I_GPG_UART12
#define SUN6I_GPG_TWI3 2
#define SUN5I_GPG_UART14
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index ae6bc656d9..d25081c92f 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -144,6 +144,11 @@ static int gpio_init(void)
sunxi_gpio_set_cfgpin(SUNXI_GPL(2), SUN8I_GPL_R_UART);
sunxi_gpio_set_cfgpin(SUNXI_GPL(3), SUN8I_GPL_R_UART);
sunxi_gpio_set_pull(SUNXI_GPL(3), SUNXI_GPIO_PULL_UP);
+#elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUN8I) && \
+ !defined(CONFIG_MACH_SUN8I_R40)
+ sunxi_gpio_set_cfgpin(SUNXI_GPG(6), SUN8I_GPG_UART1);
+ sunxi_gpio_set_cfgpin(SUNXI_GPG(7), SUN8I_GPG_UART1);
+ sunxi_gpio_set_pull(SUNXI_GPG(7), SUNXI_GPIO_PULL_UP);
#else
#error Unsupported console port number. Please fix pin mux settings in board.c
#endif
--
2.30.0
Re: [PATCH 06/13] arm: goni: Disable CONFIG_REVISION_TAG
Hi Tom,
On 2/4/21 11:24 AM, Tom Rini wrote:
> Rather than provide an empty revision tag here, remove the code to
> generate an empty one and disable the feature.
>
> Cc: Robert Baldyga
> Signed-off-by: Tom Rini
> ---
> I do not know if this platform ever had to support an ATAG-based Linux
> kernel and if not, there is more cleanup that could be done here.
Sorry for late because of holidays. I will check whether it's ATAG-based Linux
kernel or not.
Best Regards,
Jaehoon Chung
> ---
> board/samsung/goni/goni.c | 5 -
> include/configs/s5p_goni.h | 1 -
> 2 files changed, 6 deletions(-)
>
> diff --git a/board/samsung/goni/goni.c b/board/samsung/goni/goni.c
> index 2f0ef22c4171..d13347c93ff5 100644
> --- a/board/samsung/goni/goni.c
> +++ b/board/samsung/goni/goni.c
> @@ -23,11 +23,6 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> -u32 get_board_rev(void)
> -{
> - return 0;
> -}
> -
> int board_init(void)
> {
> /* Set Initial global variables */
> diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
> index 9688bdc4c035..ca9edaa43855 100644
> --- a/include/configs/s5p_goni.h
> +++ b/include/configs/s5p_goni.h
> @@ -28,7 +28,6 @@
>
> #define CONFIG_SETUP_MEMORY_TAGS
> #define CONFIG_CMDLINE_TAG
> -#define CONFIG_REVISION_TAG
> #define CONFIG_INITRD_TAG
>
> /* Size of malloc() pool before and after relocation */
>
Re: [PATCH] cmd: mmc: add mmc partboot
Dear Grygorii,
On 2/12/21 7:32 PM, grygorii tertychnyi wrote:
> This patch allows to determine active boot partition in boot script:
>
> if mmc partboot ${mmcdev} 2; then
> echo "booted from eMMC boot1 partition"
> fi
I don't know what purpose this patch has.
Best Regards,
Jaehoon Chung
>
> Signed-off-by: Grygorii Tertychnyi
> ---
> cmd/mmc.c | 39 +++
> 1 file changed, 39 insertions(+)
>
> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index 1529a3e05ddd..010d6ab9aa19 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -771,6 +771,41 @@ static int do_mmc_boot_resize(struct cmd_tbl *cmdtp, int
> flag,
> return CMD_RET_SUCCESS;
> }
>
> +static int do_mmc_partboot(struct cmd_tbl *cmdtp, int flag,
> +int argc, char *const argv[])
> +{
> + int dev;
> + struct mmc *mmc;
> + u8 part_args, part_emmc;
> +
> + if (argc != 3)
> + return CMD_RET_USAGE;
> +
> + dev = simple_strtoul(argv[1], NULL, 10);
> +
> + mmc = init_mmc_device(dev, false);
> + if (!mmc)
> + return CMD_RET_FAILURE;
> +
> + if (IS_SD(mmc)) {
> + puts("PARTITION_CONFIG only exists on eMMC\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + if (mmc->part_config == MMCPART_NOAVAILABLE) {
> + printf("No part_config info for ver. 0x%x\n", mmc->version);
> + return CMD_RET_FAILURE;
> + }
> +
> + part_emmc = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> + part_args = simple_strtoul(argv[2], NULL, 10);
> +
> + if (part_emmc == part_args)
> + return CMD_RET_SUCCESS;
> + else
> + return CMD_RET_FAILURE;
> +}
> +
> static int mmc_partconf_print(struct mmc *mmc)
> {
> u8 ack, access, part;
> @@ -953,6 +988,7 @@ static struct cmd_tbl cmd_mmc[] = {
> #ifdef CONFIG_SUPPORT_EMMC_BOOT
> U_BOOT_CMD_MKENT(bootbus, 5, 0, do_mmc_bootbus, "", ""),
> U_BOOT_CMD_MKENT(bootpart-resize, 4, 0, do_mmc_boot_resize, "", ""),
> + U_BOOT_CMD_MKENT(partboot, 3, 0, do_mmc_partboot, "", ""),
> U_BOOT_CMD_MKENT(partconf, 5, 0, do_mmc_partconf, "", ""),
> U_BOOT_CMD_MKENT(rst-function, 3, 0, do_mmc_rst_func, "", ""),
> #endif
> @@ -1021,6 +1057,9 @@ U_BOOT_CMD(
> " - Set the BOOT_BUS_WIDTH field of the specified device\n"
> "mmc bootpart-resize \n"
> " - Change sizes of boot and RPMB partitions of specified device\n"
> + "mmc partboot dev boot_partition\n"
> + " - Return success if the given boot_partition value matches
> BOOT_PARTITION_ENABLE\n"
> + " bit field of the specified device\n"
> "mmc partconf dev [boot_ack boot_partition partition_access]\n"
> " - Show or change the bits of the PARTITION_CONFIG field of the
> specified device\n"
> "mmc rst-function dev value\n"
>
Re: [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
On Sun, Feb 14, 2021 at 08:12:16PM +0100, Daniel Schwierzeck wrote: > Am Sonntag, den 14.02.2021, 09:52 -0500 schrieb Tom Rini: > > ... > > > > > > > > > > > > > > > > Tom, do you know the situation here? > > > > > > > > > > > > So, I made a lack of DM_PCI migration be fatal and got a > > > > > > build done > > > > > > here: > > > > > > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348 > > > > > > > > > > > > Of note, MIPS malta fails, so I had to drop that from pytest > > > > > > to complete > > > > > > the world build. There's then a handful of ARM boards, > > > > > > another large > > > > > > chunk of PowerPC, and then a few others such as r7780mp. SH > > > > > > is the big > > > > > > what to do here to me, other than PowerPC, as other than > > > > > > r2dplus > > > > > > everything is missing the main "convert to DM" migration > > > > > > deadline as > > > > > > well. > > > > > > > > > > What should we do for this patch? > > > > > > > > > > If the plan is to drop all boards that are not converted to DM > > > > > PCI in > > > > > 2021.04, I can drop this revert patch in v2. > > > > > > > > I've posted the patch to drop the SH boards. Daniel, what about > > > > Malta? > > > > > > Malta should be fixed, since it's mips used in CI. > > > > There's also qemu_mips* in CI, so it depends on what Daniel thinks is > > the right overall answer here. > > > > Malta is the MIPS reference board physically as well as in Qemu. > qemu_mips is actually deprecated and is going to be removed from Qemu > sooner or later. That's why I added Malta to CI with the goal to remove > qemu_mips. > > The problem with MIPS and DM_PCI is that there are some generic issues > with memory mapping and CONFIG_SYS_SDRAM_BASE being used as virtual > address. Actually I have a pending patch queue from Paul Burton for > Malta for converting to DM_PCI, but that requires resolving the generic > issues with some refactoring for all MIPS boards. It's still on my TODO > list ;) > > Until I can spare enough time to resolve all issues, I could try to > disable the PCI driver in Malta defconfig and mark the driver as broken > in Kconfig. This way we can avoid removing the whole board. Thanks for explaining. Yes, lets go that route for now. -- Tom signature.asc Description: PGP signature
Re: [PATCH 09/17] fdtdec: Use CONFIG_IS_ENABLED in board_fdt_blob_setup()
On Sun, Feb 14, 2021 at 07:20:45PM +, Peter Robinson wrote: > On Sun, Feb 14, 2021 at 7:10 PM Tom Rini wrote: > > > > On Sun, Feb 14, 2021 at 02:08:08PM -0500, Tom Rini wrote: > > > On Sun, Feb 14, 2021 at 08:05:33PM +0100, Jesper Schmitz Mouridsen wrote: > > > > > > > > On 14.02.2021 19.50, Peter Robinson wrote: > > > > > Hi Simon, > > > > > > > > > > On Thu, Jan 28, 2021 at 11:59 PM Tom Rini wrote: > > > > > > On Wed, Jan 13, 2021 at 08:29:49PM -0700, Simon Glass wrote: > > > > > > > > > > > > > This setting may be different in SPL and TPL. Update the code to > > > > > > > check > > > > > > > the correct setting. > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > Applied to u-boot/master, thanks! > > > > > This breaks booting on at least rk3399 based devices for me with the > > > > > following error: > > > > > > > > > > U-Boot TPL 2021.04-rc1 (Feb 01 2021 - 00:00:00) > > > > > Missing DTB > > > > > ### ERROR ### Please RESET the board ### > > > > Also see > > > > https://lists.denx.de/pipermail/u-boot/2021-February/440263.html > > > > > > So we have two forms of bug. sunxi (your link above Jesper) needs > > > SPL_SEPARATE_BSS to be set I think. Peter's problem is that there is no > > > TPL_SEPARATE_BSS which is a harder problem to solve quickly. I'll post > > > a revert with you both Reported-by shortly, thanks. > > > > Er, wait. I'm a bit less clear on the why on sunxi at least. I'm going > > to post the revert shortly all the same. > > The sunxi bits seem OK with 2021.04-rc1 from my testing, at least for > this problem, to now in my testing it's only been the rockchip stuff > that's had issues but I'm still getting through all my devices. Yup. I need to fix my mental map of "pine* == sunxi", that was the confusion I had. -- Tom signature.asc Description: PGP signature
[PATCH] rockchip: rk3399: rock960: explicitly disable SPI flash
The Rock960 doesn't have SPI flash on-board, but the bits get enabled by default which means when booting we get some errors. Explicitly disable it to stop the errors. Signed-off-by: Peter Robinson --- configs/rock960-rk3399_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/rock960-rk3399_defconfig b/configs/rock960-rk3399_defconfig index 56ebaeb34e..b274e9 100644 --- a/configs/rock960-rk3399_defconfig +++ b/configs/rock960-rk3399_defconfig @@ -23,6 +23,7 @@ CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set +# CONFIG_CMD_SF is not set CONFIG_CMD_TIME=y CONFIG_CMD_PMIC=y CONFIG_CMD_REGULATOR=y -- 2.29.2
[PATCH] include: configs: rk3399: drop a dangling comment
Drop a irrelevent comment now the related configs have moved to the various config files. Signed-off-by: Peter Robinson --- include/configs/rk3399_common.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h index d0fc598319..b37ed5cce0 100644 --- a/include/configs/rk3399_common.h +++ b/include/configs/rk3399_common.h @@ -75,6 +75,4 @@ #endif -/* enable usb config for usb ether */ - #endif -- 2.29.2
Re: [PATCH 09/17] fdtdec: Use CONFIG_IS_ENABLED in board_fdt_blob_setup()
On Sun, Feb 14, 2021 at 7:10 PM Tom Rini wrote: > > On Sun, Feb 14, 2021 at 02:08:08PM -0500, Tom Rini wrote: > > On Sun, Feb 14, 2021 at 08:05:33PM +0100, Jesper Schmitz Mouridsen wrote: > > > > > > On 14.02.2021 19.50, Peter Robinson wrote: > > > > Hi Simon, > > > > > > > > On Thu, Jan 28, 2021 at 11:59 PM Tom Rini wrote: > > > > > On Wed, Jan 13, 2021 at 08:29:49PM -0700, Simon Glass wrote: > > > > > > > > > > > This setting may be different in SPL and TPL. Update the code to > > > > > > check > > > > > > the correct setting. > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > Applied to u-boot/master, thanks! > > > > This breaks booting on at least rk3399 based devices for me with the > > > > following error: > > > > > > > > U-Boot TPL 2021.04-rc1 (Feb 01 2021 - 00:00:00) > > > > Missing DTB > > > > ### ERROR ### Please RESET the board ### > > > Also see https://lists.denx.de/pipermail/u-boot/2021-February/440263.html > > > > So we have two forms of bug. sunxi (your link above Jesper) needs > > SPL_SEPARATE_BSS to be set I think. Peter's problem is that there is no > > TPL_SEPARATE_BSS which is a harder problem to solve quickly. I'll post > > a revert with you both Reported-by shortly, thanks. > > Er, wait. I'm a bit less clear on the why on sunxi at least. I'm going > to post the revert shortly all the same. The sunxi bits seem OK with 2021.04-rc1 from my testing, at least for this problem, to now in my testing it's only been the rockchip stuff that's had issues but I'm still getting through all my devices. Peter
[PATCH v2] doc: board: freescale: imx8mp_evk: update to newer versions and change ATF_LOAD_ADDR
Update imx-atf and firmware-imx to latest released versions. Update address of ATF_LOAD_ADDR that has changed to 0x97 in imx-atf commit 48733cb4e773a7584ced601de9d717efa3d73815. Add 'O=' to make and build in separate directory as one issue has been noticed where it was trouble building directly inside u-boot source dir. Restructure the workflow and copy binaries after defconfig to ensure that build directory is created. Signed-off-by: Peter Bergin Cc: Andrey Zhizhikin --- v2: - Corrected ATF_LOAD_ADDR in commit message - Changed workflow to copy binaries after build directory is created doc/board/freescale/imx8mp_evk.rst | 27 +-- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/doc/board/freescale/imx8mp_evk.rst b/doc/board/freescale/imx8mp_evk.rst index ccffcf7257..796a7611d0 100644 --- a/doc/board/freescale/imx8mp_evk.rst +++ b/doc/board/freescale/imx8mp_evk.rst @@ -16,27 +16,21 @@ Quick Start Get and Build the ARM Trusted firmware -- -Note: $(srctree) is the U-Boot source directory Get ATF from: https://source.codeaurora.org/external/imx/imx-atf -branch: imx_5.4.47_2.2.0 +branch: imx_5.4.70_2.3.0 .. code-block:: bash $ make PLAT=imx8mp bl31 - $ cp build/imx8mp/release/bl31.bin $(srctree) Get the ddr firmware .. code-block:: bash - $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.9.bin - $ chmod +x firmware-imx-8.9.bin - $ ./firmware-imx-8.9.bin - $ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_201904.bin $(srctree)/lpddr4_pmu_train_1d_dmem.bin - $ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_201904.bin $(srctree)/lpddr4_pmu_train_1d_imem.bin - $ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_201904.bin $(srctree)/lpddr4_pmu_train_2d_dmem.bin - $ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_201904.bin $(srctree)/lpddr4_pmu_train_2d_imem.bin + $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.10.bin + $ chmod +x firmware-imx-8.10.bin + $ ./firmware-imx-8.10.bin Build U-Boot @@ -44,15 +38,20 @@ Build U-Boot .. code-block:: bash $ export CROSS_COMPILE=aarch64-poky-linux- - $ make imx8mp_evk_defconfig - $ export ATF_LOAD_ADDR=0x96 - $ make flash.bin + $ make O=build imx8mp_evk_defconfig + $ cp ../imx-atf/build/imx8mp/release/bl31.bin ./build/bl31.bin + $ cp ../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_dmem_202006.bin ./build/lpddr4_pmu_train_1d_dmem.bin + $ cp ../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_1d_imem_202006.bin ./build/lpddr4_pmu_train_1d_imem.bin + $ cp ../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_dmem_202006.bin ./build/lpddr4_pmu_train_2d_dmem.bin + $ cp ../firmware-imx-8.10/firmware/ddr/synopsys/lpddr4_pmu_train_2d_imem_202006.bin ./build/lpddr4_pmu_train_2d_imem.bin + $ export ATF_LOAD_ADDR=0x97 + $ make O=build flash.bin Burn the flash.bin to the MicroSD card at offset 32KB: .. code-block:: bash - $sudo dd if=flash.bin of=/dev/sd[x] bs=1K seek=32 conv=notrunc; sync + $sudo dd if=build/flash.bin of=/dev/sd[x] bs=1K seek=32 conv=notrunc; sync Boot -- 2.25.1
Re: [PATCH] Revert "fdtdec: Use CONFIG_IS_ENABLED in board_fdt_blob_setup()"
On Sun, Feb 14, 2021 at 7:11 PM Tom Rini wrote: > > On Rockchip platforms we need this area of code in TPL, but there is no > TPL_SEPARATE_BSS symbol. > > This reverts commit 0a2aaab0b678fd1778ff2fc59d0770fc82995532. > > Reported-by: Jesper Schmitz Mouridsen > Reported-by: Peter Robinson > Signed-off-by: Tom Rini Tested-by: Peter Robinson > --- > lib/fdtdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/fdtdec.c b/lib/fdtdec.c > index e048fd62..9d833f6a5633 100644 > --- a/lib/fdtdec.c > +++ b/lib/fdtdec.c > @@ -1253,7 +1253,7 @@ __weak void *board_fdt_blob_setup(void) > void *fdt_blob = NULL; > #ifdef CONFIG_SPL_BUILD > /* FDT is at end of BSS unless it is in a different memory region */ > - if (CONFIG_IS_ENABLED(SEPARATE_BSS)) > + if (IS_ENABLED(CONFIG_SPL_SEPARATE_BSS)) > fdt_blob = (ulong *)&_image_binary_end; > else > fdt_blob = (ulong *)&__bss_end; > -- > 2.17.1 >
Re: [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
Am Sonntag, den 14.02.2021, 09:52 -0500 schrieb Tom Rini: ... > > > > > > > > > > > > > Tom, do you know the situation here? > > > > > > > > > > So, I made a lack of DM_PCI migration be fatal and got a > > > > > build done > > > > > here: > > > > > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348 > > > > > > > > > > Of note, MIPS malta fails, so I had to drop that from pytest > > > > > to complete > > > > > the world build. There's then a handful of ARM boards, > > > > > another large > > > > > chunk of PowerPC, and then a few others such as r7780mp. SH > > > > > is the big > > > > > what to do here to me, other than PowerPC, as other than > > > > > r2dplus > > > > > everything is missing the main "convert to DM" migration > > > > > deadline as > > > > > well. > > > > > > > > What should we do for this patch? > > > > > > > > If the plan is to drop all boards that are not converted to DM > > > > PCI in > > > > 2021.04, I can drop this revert patch in v2. > > > > > > I've posted the patch to drop the SH boards. Daniel, what about > > > Malta? > > > > Malta should be fixed, since it's mips used in CI. > > There's also qemu_mips* in CI, so it depends on what Daniel thinks is > the right overall answer here. > Malta is the MIPS reference board physically as well as in Qemu. qemu_mips is actually deprecated and is going to be removed from Qemu sooner or later. That's why I added Malta to CI with the goal to remove qemu_mips. The problem with MIPS and DM_PCI is that there are some generic issues with memory mapping and CONFIG_SYS_SDRAM_BASE being used as virtual address. Actually I have a pending patch queue from Paul Burton for Malta for converting to DM_PCI, but that requires resolving the generic issues with some refactoring for all MIPS boards. It's still on my TODO list ;) Until I can spare enough time to resolve all issues, I could try to disable the PCI driver in Malta defconfig and mark the driver as broken in Kconfig. This way we can avoid removing the whole board. -- - Daniel
[PATCH] Revert "fdtdec: Use CONFIG_IS_ENABLED in board_fdt_blob_setup()"
On Rockchip platforms we need this area of code in TPL, but there is no TPL_SEPARATE_BSS symbol. This reverts commit 0a2aaab0b678fd1778ff2fc59d0770fc82995532. Reported-by: Jesper Schmitz Mouridsen Reported-by: Peter Robinson Signed-off-by: Tom Rini --- lib/fdtdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/fdtdec.c b/lib/fdtdec.c index e048fd62..9d833f6a5633 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -1253,7 +1253,7 @@ __weak void *board_fdt_blob_setup(void) void *fdt_blob = NULL; #ifdef CONFIG_SPL_BUILD /* FDT is at end of BSS unless it is in a different memory region */ - if (CONFIG_IS_ENABLED(SEPARATE_BSS)) + if (IS_ENABLED(CONFIG_SPL_SEPARATE_BSS)) fdt_blob = (ulong *)&_image_binary_end; else fdt_blob = (ulong *)&__bss_end; -- 2.17.1
Re: [PATCH 09/17] fdtdec: Use CONFIG_IS_ENABLED in board_fdt_blob_setup()
On Sun, Feb 14, 2021 at 02:08:08PM -0500, Tom Rini wrote: > On Sun, Feb 14, 2021 at 08:05:33PM +0100, Jesper Schmitz Mouridsen wrote: > > > > On 14.02.2021 19.50, Peter Robinson wrote: > > > Hi Simon, > > > > > > On Thu, Jan 28, 2021 at 11:59 PM Tom Rini wrote: > > > > On Wed, Jan 13, 2021 at 08:29:49PM -0700, Simon Glass wrote: > > > > > > > > > This setting may be different in SPL and TPL. Update the code to check > > > > > the correct setting. > > > > > > > > > > Signed-off-by: Simon Glass > > > > Applied to u-boot/master, thanks! > > > This breaks booting on at least rk3399 based devices for me with the > > > following error: > > > > > > U-Boot TPL 2021.04-rc1 (Feb 01 2021 - 00:00:00) > > > Missing DTB > > > ### ERROR ### Please RESET the board ### > > Also see https://lists.denx.de/pipermail/u-boot/2021-February/440263.html > > So we have two forms of bug. sunxi (your link above Jesper) needs > SPL_SEPARATE_BSS to be set I think. Peter's problem is that there is no > TPL_SEPARATE_BSS which is a harder problem to solve quickly. I'll post > a revert with you both Reported-by shortly, thanks. Er, wait. I'm a bit less clear on the why on sunxi at least. I'm going to post the revert shortly all the same. -- Tom signature.asc Description: PGP signature
Re: [PATCH 09/17] fdtdec: Use CONFIG_IS_ENABLED in board_fdt_blob_setup()
On Sun, Feb 14, 2021 at 08:05:33PM +0100, Jesper Schmitz Mouridsen wrote: > > On 14.02.2021 19.50, Peter Robinson wrote: > > Hi Simon, > > > > On Thu, Jan 28, 2021 at 11:59 PM Tom Rini wrote: > > > On Wed, Jan 13, 2021 at 08:29:49PM -0700, Simon Glass wrote: > > > > > > > This setting may be different in SPL and TPL. Update the code to check > > > > the correct setting. > > > > > > > > Signed-off-by: Simon Glass > > > Applied to u-boot/master, thanks! > > This breaks booting on at least rk3399 based devices for me with the > > following error: > > > > U-Boot TPL 2021.04-rc1 (Feb 01 2021 - 00:00:00) > > Missing DTB > > ### ERROR ### Please RESET the board ### > Also see https://lists.denx.de/pipermail/u-boot/2021-February/440263.html So we have two forms of bug. sunxi (your link above Jesper) needs SPL_SEPARATE_BSS to be set I think. Peter's problem is that there is no TPL_SEPARATE_BSS which is a harder problem to solve quickly. I'll post a revert with you both Reported-by shortly, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/4] mx53loco: Convert to driver model
On Sun, Feb 14, 2021 at 11:26 AM Tom Rini wrote:
> Where is something missing for SATA support? With DM enabled, you can
> enable AHCI and BLK and DWC_AHSATA is already converted. Is there
> some i.MX specific work required still? Thanks!
I have added CONFIG_AHCI=y and added:
--- a/drivers/ata/dwc_ahsata.c
+++ b/drivers/ata/dwc_ahsata.c
@@ -1093,6 +1093,7 @@ struct ahci_ops dwc_ahsata_ahci_ops = {
static const struct udevice_id dwc_ahsata_ahci_ids[] = {
{ .compatible = "fsl,imx6q-ahci" },
+ { .compatible = "fsl,imx53-ahci" },
{ }
};
but after running the "sata" command I do get a data abort and the board resets.
I haven't gotten a chance to debug it further, but I was hoping to
proceed with the DM conversion without sata support for now and then
work on adding sata support for this board.
Regards,
Fabio Estevam
Re: [PATCH 09/17] fdtdec: Use CONFIG_IS_ENABLED in board_fdt_blob_setup()
Hi Simon, On Thu, Jan 28, 2021 at 11:59 PM Tom Rini wrote: > > On Wed, Jan 13, 2021 at 08:29:49PM -0700, Simon Glass wrote: > > > This setting may be different in SPL and TPL. Update the code to check > > the correct setting. > > > > Signed-off-by: Simon Glass > > Applied to u-boot/master, thanks! This breaks booting on at least rk3399 based devices for me with the following error: U-Boot TPL 2021.04-rc1 (Feb 01 2021 - 00:00:00) Missing DTB ### ERROR ### Please RESET the board ###
Re: Pull request for UEFI sub-system for efi-2021-04-rc2-2
On Sun, Feb 14, 2021 at 02:21:16PM +0100, Heinrich Schuchardt wrote: > Hello Tom, > > in the following pull request I have included a correction for binman > because without it Gitlab has a time out on the binman job. The binman > patch has been reviewed by Simon. > > See > https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/6381 > which passed and > https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/6379 > which timed out. > > > The following changes since commit 7c82e12cc4e9e25d7c89fe15bfeec4e9b0bb2b4d: > > Merge tag 'u-boot-atmel-fixes-2021.04-a' of > https://gitlab.denx.de/u-boot/custodians/u-boot-atmel (2021-02-12 > 09:09:10 -0500) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2021-04-rc2-2 > > for you to fetch changes up to fd434f47d4d008d41f4ee2fe5cb94791f780395c: > > buildman: 'Thread' object has no attribute 'isAlive' (2021-02-14 > 11:32:04 +0100) > > Gitlab shows no problem: > https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/6381 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCHv5 4/6] doc: describe the scp03 command
The Secure Channel Protocol 03 command sends control requests (enable/provision) to the TEE implementing the protocol between the processor and the secure element. Signed-off-by: Jorge Ramirez-Ortiz Reviewed-by: Simon Glass --- doc/usage/index.rst | 1 + doc/usage/scp03.rst | 33 + 2 files changed, 34 insertions(+) create mode 100644 doc/usage/scp03.rst diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 5754958d7e..fa1c4160b9 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -29,3 +29,4 @@ Shell commands pstore sbi true + scp03 diff --git a/doc/usage/scp03.rst b/doc/usage/scp03.rst new file mode 100644 index 00..7ff87ed85a --- /dev/null +++ b/doc/usage/scp03.rst @@ -0,0 +1,33 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +scp03 command += + +Synopsis + + +:: + +scp03 enable +scp03 provision + +Description +--- + +The *scp03* command calls into a Trusted Application executing in a +Trusted Execution Environment to enable (if present) the Secure +Channel Protocol 03 stablished between the processor and the secure +element. + +This protocol encrypts all the communication between the processor and +the secure element using a set of pre-defined keys. These keys can be +rotated (provisioned) using the *provision* request. + +See also + + +For some information on the internals implemented in the TEE, please +check the GlobalPlatform documentation on `Secure Channel Protocol '03'`_ + +.. _Secure Channel Protocol '03': + https://globalplatform.org/wp-content/uploads/2014/07/GPC_2.3_D_SCP03_v1.1.2_PublicRelease.pdf -- 2.30.0
[PATCHv5 3/6] drivers: tee: sandbox: SCP03 control emulator
Adds support for a working SCP03 emulation. Input parameters are
validated however the commands (enable, provision) executed by the TEE
are assumed to always succeed.
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Simon Glass
---
drivers/tee/optee/Kconfig | 6 +
drivers/tee/sandbox.c | 57 +--
2 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
index d489834df9..98988c38f0 100644
--- a/drivers/tee/optee/Kconfig
+++ b/drivers/tee/optee/Kconfig
@@ -22,6 +22,12 @@ config OPTEE_TA_AVB
The TA can support the "avb" subcommands "read_rb", "write"rb"
and "is_unlocked".
+config OPTEE_TA_SCP03
+ bool "Support SCP03 TA"
+ default y
+ help
+ Enables support for controlling (enabling, provisioning) the
+ Secure Channel Protocol 03 operation in the OP-TEE SCP03 TA.
endmenu
endif
diff --git a/drivers/tee/sandbox.c b/drivers/tee/sandbox.c
index e1ba027fd6..f25cdd47e4 100644
--- a/drivers/tee/sandbox.c
+++ b/drivers/tee/sandbox.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
/*
* The sandbox tee driver tries to emulate a generic Trusted Exectution
@@ -32,7 +33,7 @@ struct ta_entry {
struct tee_param *params);
};
-#ifdef CONFIG_OPTEE_TA_AVB
+#if defined(CONFIG_OPTEE_TA_SCP03) || defined(CONFIG_OPTEE_TA_AVB)
static u32 get_attr(uint n, uint num_params, struct tee_param *params)
{
if (n >= num_params)
@@ -44,7 +45,7 @@ static u32 get_attr(uint n, uint num_params, struct tee_param
*params)
static u32 check_params(u8 p0, u8 p1, u8 p2, u8 p3, uint num_params,
struct tee_param *params)
{
- u8 p[] = { p0, p1, p2, p3};
+ u8 p[] = { p0, p1, p2, p3 };
uint n;
for (n = 0; n < ARRAY_SIZE(p); n++)
@@ -62,6 +63,52 @@ bad_params:
return TEE_ERROR_BAD_PARAMETERS;
}
+#endif
+
+#ifdef CONFIG_OPTEE_TA_SCP03
+static u32 pta_scp03_open_session(struct udevice *dev, uint num_params,
+ struct tee_param *params)
+{
+ /*
+* We don't expect additional parameters when opening a session to
+* this TA.
+*/
+ return check_params(TEE_PARAM_ATTR_TYPE_NONE, TEE_PARAM_ATTR_TYPE_NONE,
+ TEE_PARAM_ATTR_TYPE_NONE, TEE_PARAM_ATTR_TYPE_NONE,
+ num_params, params);
+}
+
+static u32 pta_scp03_invoke_func(struct udevice *dev, u32 func, uint
num_params,
+struct tee_param *params)
+{
+ u32 res;
+ static bool enabled;
+
+ switch (func) {
+ case PTA_CMD_ENABLE_SCP03:
+ res = check_params(TEE_PARAM_ATTR_TYPE_VALUE_INPUT,
+ TEE_PARAM_ATTR_TYPE_NONE,
+ TEE_PARAM_ATTR_TYPE_NONE,
+ TEE_PARAM_ATTR_TYPE_NONE,
+ num_params, params);
+ if (res)
+ return res;
+
+ if (!enabled) {
+ enabled = true;
+ } else {
+ }
+
+ if (params[0].u.value.a)
+
+ return TEE_SUCCESS;
+ default:
+ return TEE_ERROR_NOT_SUPPORTED;
+ }
+}
+#endif
+
+#ifdef CONFIG_OPTEE_TA_AVB
static u32 ta_avb_open_session(struct udevice *dev, uint num_params,
struct tee_param *params)
@@ -223,6 +270,12 @@ static const struct ta_entry ta_entries[] = {
.invoke_func = ta_avb_invoke_func,
},
#endif
+#ifdef CONFIG_OPTEE_TA_SCP03
+ { .uuid = PTA_SCP03_UUID,
+ .open_session = pta_scp03_open_session,
+ .invoke_func = pta_scp03_invoke_func,
+ },
+#endif
};
static void sandbox_tee_get_version(struct udevice *dev,
--
2.30.0
[PATCHv5 6/6] test: py: add initial coverage for scp03 cmd
From: Igor Opaniuk
Add initial test coverage for SCP03 command.
Signed-off-by: Igor Opaniuk
Reviewed-by: Simon Glass
---
test/py/tests/test_scp03.py | 27 +++
1 file changed, 27 insertions(+)
create mode 100644 test/py/tests/test_scp03.py
diff --git a/test/py/tests/test_scp03.py b/test/py/tests/test_scp03.py
new file mode 100644
index 00..1f689252dd
--- /dev/null
+++ b/test/py/tests/test_scp03.py
@@ -0,0 +1,27 @@
+# Copyright (c) 2021 Foundries.io Ltd
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+# SCP03 command test
+
+"""
+This tests SCP03 command in U-boot.
+
+For additional details check doc/usage/scp03.rst
+"""
+
+import pytest
+import u_boot_utils as util
+
+@pytest.mark.buildconfigspec('cmd_scp03')
+def test_scp03(u_boot_console):
+"""Enable and provision keys with SCP03
+"""
+
+success_str1 = "SCP03 is enabled"
+success_str2 = "SCP03 is provisioned"
+
+response = u_boot_console.run_command('scp03 enable')
+assert success_str1 in response
+response = u_boot_console.run_command('scp03 provision')
+assert success_str2 in response
--
2.30.0
[PATCHv5 5/6] sandbox: imply SCP03 and CMD_SCP03
From: Igor Opaniuk Enable by default SCP_03/CMD_SCP03 for sandbox target. Signed-off-by: Igor Opaniuk Reviewed-by: Simon Glass --- arch/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/Kconfig b/arch/Kconfig index 27843cd79c..7023223927 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -142,6 +142,8 @@ config SANDBOX imply AVB_VERIFY imply LIBAVB imply CMD_AVB + imply SCP03 + imply CMD_SCP03 imply UDP_FUNCTION_FASTBOOT imply VIRTIO_MMIO imply VIRTIO_PCI -- 2.30.0
[PATCHv5 2/6] cmd: SCP03: enable and provision command
Enable and provision the SCP03 keys on a TEE controlled secured elemt
from the U-Boot shell.
Executing this command will generate and program new SCP03 encryption
keys on the secure element NVM.
Depending on the TEE implementation, the keys would then be stored in
some persistent storage or better derived from some platform secret
(so they can't be lost).
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Simon Glass
---
cmd/Kconfig | 8
cmd/Makefile | 3 +++
cmd/scp03.c | 52
3 files changed, 63 insertions(+)
create mode 100644 cmd/scp03.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 928a2a0a2d..6327374f2c 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2021,6 +2021,14 @@ config HASH_VERIFY
help
Add -v option to verify data against a hash.
+config CMD_SCP03
+ bool "scp03 - SCP03 enable and rotate/provision operations"
+ depends on SCP03
+ help
+ This command provides access to a Trusted Application
+ running in a TEE to request Secure Channel Protocol 03
+ (SCP03) enablement and/or rotation of its SCP03 keys.
+
config CMD_TPM_V1
bool
diff --git a/cmd/Makefile b/cmd/Makefile
index 176bf925fd..a7017e8452 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -193,6 +193,9 @@ obj-$(CONFIG_CMD_BLOB) += blob.o
# Android Verified Boot 2.0
obj-$(CONFIG_CMD_AVB) += avb.o
+# Foundries.IO SCP03
+obj-$(CONFIG_CMD_SCP03) += scp03.o
+
obj-$(CONFIG_ARM) += arm/
obj-$(CONFIG_RISCV) += riscv/
obj-$(CONFIG_SANDBOX) += sandbox/
diff --git a/cmd/scp03.c b/cmd/scp03.c
new file mode 100644
index 00..655e0bba08
--- /dev/null
+++ b/cmd/scp03.c
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021, Foundries.IO
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+int do_scp03_enable(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ if (argc != 1)
+ return CMD_RET_USAGE;
+
+ if (tee_enable_scp03()) {
+ printf("TEE failed to enable SCP03\n");
+ return CMD_RET_FAILURE;
+ }
+
+ printf("SCP03 is enabled\n");
+
+ return CMD_RET_SUCCESS;
+}
+
+int do_scp03_provision(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ if (argc != 1)
+ return CMD_RET_USAGE;
+
+ if (tee_provision_scp03()) {
+ printf("TEE failed to provision SCP03 keys\n");
+ return CMD_RET_FAILURE;
+ }
+
+ printf("SCP03 is provisioned\n");
+
+ return CMD_RET_SUCCESS;
+}
+
+static char text[] =
+ "provides a command to enable SCP03 and provision the SCP03 keys\n"
+ " enable- enable SCP03 on the TEE\n"
+ " provision - provision SCP03 on the TEE\n";
+
+U_BOOT_CMD_WITH_SUBCMDS(scp03, "Secure Channel Protocol 03 control", text,
+ U_BOOT_SUBCMD_MKENT(enable, 1, 1, do_scp03_enable),
+ U_BOOT_SUBCMD_MKENT(provision, 1, 1, do_scp03_provision));
+
--
2.30.0
[PATCHv5 1/6] common: SCP03 control (enable and provision of keys)
This Trusted Application allows enabling SCP03 as well as provisioning
the keys on TEE controlled secure element (ie, NXP SE050).
All the information flowing on buses (ie I2C) between the processor
and the secure element must be encrypted. Secure elements are
pre-provisioned with a set of keys known to the user so that the
secure channel protocol (encryption) can be enforced on the first
boot. This situation is however unsafe since the keys are publically
available.
For example, in the case of the NXP SE050, these keys would be
available in the OP-TEE source tree [2] and of course in the
documentation corresponding to the part.
To address that, users are required to rotate/provision those keys
(ie, generate new keys and write them in the secure element's
persistent memory).
For information on SCP03, check the Global Platform HomePage and
google for that term [1]
[1] globalplatform.org
[2] https://github.com/OP-TEE/optee_os/
check:
core/drivers/crypto/se050/adaptors/utils/scp_config.c
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Simon Glass
---
common/Kconfig | 8 ++
common/Makefile | 1 +
common/scp03.c | 53
include/scp03.h | 21 ++
include/tee/optee_ta_scp03.h | 21 ++
5 files changed, 104 insertions(+)
create mode 100644 common/scp03.c
create mode 100644 include/scp03.h
create mode 100644 include/tee/optee_ta_scp03.h
diff --git a/common/Kconfig b/common/Kconfig
index 2bb3798f80..482f123534 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -588,6 +588,14 @@ config AVB_BUF_SIZE
endif # AVB_VERIFY
+config SCP03
+ bool "Build SCP03 - Secure Channel Protocol O3 - controls"
+ depends on OPTEE || SANDBOX
+ depends on TEE
+ help
+ This option allows U-Boot to enable and or provision SCP03 on an OPTEE
+ controlled Secured Element.
+
config SPL_HASH
bool # "Support hashing API (SHA1, SHA256, etc.)"
help
diff --git a/common/Makefile b/common/Makefile
index daeea67cf2..215b8b26fd 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -137,3 +137,4 @@ obj-$(CONFIG_CMD_LOADB) += xyzModem.o
obj-$(CONFIG_$(SPL_TPL_)YMODEM_SUPPORT) += xyzModem.o
obj-$(CONFIG_AVB_VERIFY) += avb_verify.o
+obj-$(CONFIG_SCP03) += scp03.o
diff --git a/common/scp03.c b/common/scp03.c
new file mode 100644
index 00..09ef7b5ba3
--- /dev/null
+++ b/common/scp03.c
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021, Foundries.IO
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+static int scp03_enable(bool provision)
+{
+ const struct tee_optee_ta_uuid uuid = PTA_SCP03_UUID;
+ struct tee_open_session_arg session;
+ struct tee_invoke_arg invoke;
+ struct tee_param param;
+ struct udevice *tee = NULL;
+
+ tee = tee_find_device(tee, NULL, NULL, NULL);
+ if (!tee)
+ return -ENODEV;
+
+ memset(, 0, sizeof(session));
+ tee_optee_ta_uuid_to_octets(session.uuid, );
+ if (tee_open_session(tee, , 0, NULL))
+ return -ENXIO;
+
+ memset(, 0, sizeof(param));
+ param.attr = TEE_PARAM_ATTR_TYPE_VALUE_INPUT;
+ param.u.value.a = provision;
+
+ memset(, 0, sizeof(invoke));
+ invoke.func = PTA_CMD_ENABLE_SCP03;
+ invoke.session = session.session;
+
+ if (tee_invoke_func(tee, , 1, ))
+ return -EIO;
+
+ tee_close_session(tee, session.session);
+
+ return 0;
+}
+
+int tee_enable_scp03(void)
+{
+ return scp03_enable(false);
+}
+
+int tee_provision_scp03(void)
+{
+ return scp03_enable(true);
+}
diff --git a/include/scp03.h b/include/scp03.h
new file mode 100644
index 00..729667ccd1
--- /dev/null
+++ b/include/scp03.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * (C) Copyright 2021, Foundries.IO
+ *
+ */
+
+#ifndef _SCP03_H
+#define _SCP03_H
+
+/*
+ * Requests to OPTEE to enable or provision the Secure Channel Protocol on its
+ * Secure Element
+ *
+ * If key provisioning is requested, OPTEE shall generate new SCP03 keys and
+ * write them to the Secure Element.
+ *
+ * Both functions return < 0 on error else 0.
+ */
+int tee_enable_scp03(void);
+int tee_provision_scp03(void);
+#endif /* _SCP03_H */
diff --git a/include/tee/optee_ta_scp03.h b/include/tee/optee_ta_scp03.h
new file mode 100644
index 00..13f9956d98
--- /dev/null
+++ b/include/tee/optee_ta_scp03.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: BSD-3-Clause */
+/*
+ * (C) Copyright 2021, Foundries.IO
+ *
+ */
+#ifndef __TA_SCP03_H
+#define __TA_SCP03_H
+
+#define PTA_SCP03_UUID { 0xbe0e5821, 0xe718, 0x4f77, \
+ { 0xab, 0x3e, 0x8e, 0x6c, 0x73, 0xa9, 0xc7, 0x35 } }
+
+/*
+ * Enable Secure Channel Protocol functionality (SCP03) on the Secure Element.
+ * Setting the operation value to something different than NULL will trigger
+ *
[PATCHv5 0/6] SCP03 control, documentation and tests.
Simply adding the reviewed-by tags to the v5 series. Igor Opaniuk (2): sandbox: imply SCP03 and CMD_SCP03 test: py: add initial coverage for scp03 cmd Jorge Ramirez-Ortiz (4): common: SCP03 control (enable and provision of keys) cmd: SCP03: enable and provision command drivers: tee: sandbox: SCP03 control emulator doc: describe the scp03 command arch/Kconfig | 2 ++ cmd/Kconfig | 8 + cmd/Makefile | 3 ++ cmd/scp03.c | 52 common/Kconfig | 8 + common/Makefile | 1 + common/scp03.c | 53 + doc/usage/index.rst | 1 + doc/usage/scp03.rst | 33 + drivers/tee/optee/Kconfig| 6 drivers/tee/sandbox.c| 57 ++-- include/scp03.h | 21 + include/tee/optee_ta_scp03.h | 21 + test/py/tests/test_scp03.py | 27 + 14 files changed, 291 insertions(+), 2 deletions(-) create mode 100644 cmd/scp03.c create mode 100644 common/scp03.c create mode 100644 doc/usage/scp03.rst create mode 100644 include/scp03.h create mode 100644 include/tee/optee_ta_scp03.h create mode 100644 test/py/tests/test_scp03.py -- 2.30.0
[PATCHv5 2/6] cmd: SCP03: enable and provision command
Enable and provision the SCP03 keys on a TEE controlled secured elemt
from the U-Boot shell.
Executing this command will generate and program new SCP03 encryption
keys on the secure element NVM.
Depending on the TEE implementation, the keys would then be stored in
some persistent storage or better derived from some platform secret
(so they can't be lost).
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Simon Glass
---
cmd/Kconfig | 8
cmd/Makefile | 3 +++
cmd/scp03.c | 52
3 files changed, 63 insertions(+)
create mode 100644 cmd/scp03.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 928a2a0a2d..6327374f2c 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2021,6 +2021,14 @@ config HASH_VERIFY
help
Add -v option to verify data against a hash.
+config CMD_SCP03
+ bool "scp03 - SCP03 enable and rotate/provision operations"
+ depends on SCP03
+ help
+ This command provides access to a Trusted Application
+ running in a TEE to request Secure Channel Protocol 03
+ (SCP03) enablement and/or rotation of its SCP03 keys.
+
config CMD_TPM_V1
bool
diff --git a/cmd/Makefile b/cmd/Makefile
index 176bf925fd..a7017e8452 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -193,6 +193,9 @@ obj-$(CONFIG_CMD_BLOB) += blob.o
# Android Verified Boot 2.0
obj-$(CONFIG_CMD_AVB) += avb.o
+# Foundries.IO SCP03
+obj-$(CONFIG_CMD_SCP03) += scp03.o
+
obj-$(CONFIG_ARM) += arm/
obj-$(CONFIG_RISCV) += riscv/
obj-$(CONFIG_SANDBOX) += sandbox/
diff --git a/cmd/scp03.c b/cmd/scp03.c
new file mode 100644
index 00..655e0bba08
--- /dev/null
+++ b/cmd/scp03.c
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021, Foundries.IO
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+int do_scp03_enable(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ if (argc != 1)
+ return CMD_RET_USAGE;
+
+ if (tee_enable_scp03()) {
+ printf("TEE failed to enable SCP03\n");
+ return CMD_RET_FAILURE;
+ }
+
+ printf("SCP03 is enabled\n");
+
+ return CMD_RET_SUCCESS;
+}
+
+int do_scp03_provision(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ if (argc != 1)
+ return CMD_RET_USAGE;
+
+ if (tee_provision_scp03()) {
+ printf("TEE failed to provision SCP03 keys\n");
+ return CMD_RET_FAILURE;
+ }
+
+ printf("SCP03 is provisioned\n");
+
+ return CMD_RET_SUCCESS;
+}
+
+static char text[] =
+ "provides a command to enable SCP03 and provision the SCP03 keys\n"
+ " enable- enable SCP03 on the TEE\n"
+ " provision - provision SCP03 on the TEE\n";
+
+U_BOOT_CMD_WITH_SUBCMDS(scp03, "Secure Channel Protocol 03 control", text,
+ U_BOOT_SUBCMD_MKENT(enable, 1, 1, do_scp03_enable),
+ U_BOOT_SUBCMD_MKENT(provision, 1, 1, do_scp03_provision));
+
--
2.30.0
Re: [PATCH] odroid-go2: remove setting SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
On Sun, Feb 14, 2021 at 08:25:27AM +0100, Roger Pau Monné wrote:
> On Sat, Feb 13, 2021 at 11:45:50PM +0100, Heiko Stuebner wrote:
> > Hi Roger,
> >
> > Am Samstag, 13. Februar 2021, 16:59:01 CET schrieb Roger Pau Monne:
> > > From: Roger Pau Monné
> > >
> > > Using a non-default SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR setting makes the
> > > resulting u-boot-rockchip.bin unbootable, as it gets stuck after SPL.
> > > Removing the setting from the defconfig allows U-Boot to load
> > > successfully.
> >
> > Hmm, I'd disagree slightly.
> >
> > In the rockchip-common.h the CONFIG_SPL_PAD_TO is defined as
> >
> > /* ((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512) */
> > #define CONFIG_SPL_PAD_TO 8355840
> >
> > so it's a static value but based on the MMCSD_RAW_MODE... config option.
> >
> > So instead of mandating one specific MMCSD_RAW_MODE... value
> > that CONFIG_SPL_PAD_TO should be defined based on the the
> > actual config value of CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
> > and not some static number that then gets enforced for all boards.
>
> Sure, I can fix CONFIG_SPL_PAD_TO to be calculated based on
> MMCSD_RAW_MODE...
So that's easier said that done. CONFIG_SPL_PAD_TO ends up being used
by the call to objcopy, so using an expression instead of an absolute
number leads to:
aarch64-none-elf-objcopy --gap-fill=0xff -j .text -j .secure_text -j
.secure_data -j .rodata -j .data -j .u_boot_list -j .rela.dyn -j .got -j
.got.plt -j .binman_sym_table -j .text_rest -j .dtb.i
nit.rodata -I binary -O binary
--pad-to="((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512)"
--gap-fill=0xff idbloader.img u-boot-rockchip.bin && cat u-boot.itb >>
u-boot-rockchip.bin || { rm -
f u-boot-rockchip.bin; false; }
aarch64-none-elf-objcopy: --pad-to: bad number:
((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512)
And fixing this seems like a much bigger issue to tackle than the
original patch. The current way to propagate CONFIG_ values to
Makefiles is by the output of `cc -E -dM`, which won't perform the
arithmetic.
We could create a small tool using HOSTCC to print the values of the
macros, but as said above that's not trivial IMO.
Thanks, Roger.
Re: [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
On Sun, Feb 14, 2021 at 03:44:26PM +0100, Marek Vasut wrote:
> On 2/14/21 3:35 PM, Tom Rini wrote:
> > On Sun, Feb 14, 2021 at 12:53:29PM +0800, Bin Meng wrote:
> > > Hi Tom,
> > >
> > > On Wed, Feb 10, 2021 at 10:13 PM Tom Rini wrote:
> > > >
> > > > On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
> > > > > Hi Simon,
> > > > >
> > > > > On Sun, Feb 7, 2021 at 11:34 PM Simon Glass wrote:
> > > > > >
> > > > > > Hi Bin,
> > > > > >
> > > > > > On Sun, 7 Feb 2021 at 08:11, Bin Meng wrote:
> > > > > > >
> > > > > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> > > > > > >
> > > > > > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the
> > > > > > > PCI regions")
> > > > > > > changes 'struct pci_controller'.regions from pre-allocated array
> > > > > > > of
> > > > > > > regions to dynamically allocated, which unfortunately broken lots
> > > > > > > of
> > > > > > > boards that still use the non-DM PCI driver.
> > > > > > >
> > > > > > > We may update every non-DM PCI board codes to do the dynamical
> > > > > > > allocation of PCI regions but that's a lot of work (e.g.: almost
> > > > > > > all Freescale PowerPC boards are broken now and need to be fixed).
> > > > > > > Let's do the easy way.
> > > > > >
> > > > > > No one has noticed since July, apparently. I think it would be
> > > > > > better
> > > > > > to disable PCI on these boards, until either someone migrates them
> > > > > > or
> > > > > > they are removed. The PCI deadline was about 18 months ago.
> > > > > >
> > > > >
> > > > > Yep, but I'd like to keep this revert instead of just fixing the
> > > > > qemu-ppce500 here, to give people a chance to test their original
> > > > > non-DM version of PCI driver before the DM conversion.
> > > > >
> > > > > Once all boards have converted to DM PCI, we can revert this revert
> > > > > patch again.
> > > > >
> > > > > > Tom, do you know the situation here?
> > > >
> > > > So, I made a lack of DM_PCI migration be fatal and got a build done
> > > > here:
> > > > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
> > > >
> > > > Of note, MIPS malta fails, so I had to drop that from pytest to complete
> > > > the world build. There's then a handful of ARM boards, another large
> > > > chunk of PowerPC, and then a few others such as r7780mp. SH is the big
> > > > what to do here to me, other than PowerPC, as other than r2dplus
> > > > everything is missing the main "convert to DM" migration deadline as
> > > > well.
> > >
> > > What should we do for this patch?
> > >
> > > If the plan is to drop all boards that are not converted to DM PCI in
> > > 2021.04, I can drop this revert patch in v2.
> >
> > I've posted the patch to drop the SH boards. Daniel, what about Malta?
>
> Malta should be fixed, since it's mips used in CI.
There's also qemu_mips* in CI, so it depends on what Daniel thinks is
the right overall answer here.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
On 2/14/21 3:35 PM, Tom Rini wrote:
On Sun, Feb 14, 2021 at 12:53:29PM +0800, Bin Meng wrote:
Hi Tom,
On Wed, Feb 10, 2021 at 10:13 PM Tom Rini wrote:
On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
Hi Simon,
On Sun, Feb 7, 2021 at 11:34 PM Simon Glass wrote:
Hi Bin,
On Sun, 7 Feb 2021 at 08:11, Bin Meng wrote:
This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
changes 'struct pci_controller'.regions from pre-allocated array of
regions to dynamically allocated, which unfortunately broken lots of
boards that still use the non-DM PCI driver.
We may update every non-DM PCI board codes to do the dynamical
allocation of PCI regions but that's a lot of work (e.g.: almost
all Freescale PowerPC boards are broken now and need to be fixed).
Let's do the easy way.
No one has noticed since July, apparently. I think it would be better
to disable PCI on these boards, until either someone migrates them or
they are removed. The PCI deadline was about 18 months ago.
Yep, but I'd like to keep this revert instead of just fixing the
qemu-ppce500 here, to give people a chance to test their original
non-DM version of PCI driver before the DM conversion.
Once all boards have converted to DM PCI, we can revert this revert patch again.
Tom, do you know the situation here?
So, I made a lack of DM_PCI migration be fatal and got a build done
here:
https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
Of note, MIPS malta fails, so I had to drop that from pytest to complete
the world build. There's then a handful of ARM boards, another large
chunk of PowerPC, and then a few others such as r7780mp. SH is the big
what to do here to me, other than PowerPC, as other than r2dplus
everything is missing the main "convert to DM" migration deadline as
well.
What should we do for this patch?
If the plan is to drop all boards that are not converted to DM PCI in
2021.04, I can drop this revert patch in v2.
I've posted the patch to drop the SH boards. Daniel, what about Malta?
Malta should be fixed, since it's mips used in CI.
I guess maybe the next steps are I need to pull in the already acked
board removal patches I've posted and then do another posting of "remove
these boards now" and see what shakes out.
Yeah
Re: [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
On Sun, Feb 14, 2021 at 12:53:29PM +0800, Bin Meng wrote:
> Hi Tom,
>
> On Wed, Feb 10, 2021 at 10:13 PM Tom Rini wrote:
> >
> > On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
> > > Hi Simon,
> > >
> > > On Sun, Feb 7, 2021 at 11:34 PM Simon Glass wrote:
> > > >
> > > > Hi Bin,
> > > >
> > > > On Sun, 7 Feb 2021 at 08:11, Bin Meng wrote:
> > > > >
> > > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> > > > >
> > > > > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI
> > > > > regions")
> > > > > changes 'struct pci_controller'.regions from pre-allocated array of
> > > > > regions to dynamically allocated, which unfortunately broken lots of
> > > > > boards that still use the non-DM PCI driver.
> > > > >
> > > > > We may update every non-DM PCI board codes to do the dynamical
> > > > > allocation of PCI regions but that's a lot of work (e.g.: almost
> > > > > all Freescale PowerPC boards are broken now and need to be fixed).
> > > > > Let's do the easy way.
> > > >
> > > > No one has noticed since July, apparently. I think it would be better
> > > > to disable PCI on these boards, until either someone migrates them or
> > > > they are removed. The PCI deadline was about 18 months ago.
> > > >
> > >
> > > Yep, but I'd like to keep this revert instead of just fixing the
> > > qemu-ppce500 here, to give people a chance to test their original
> > > non-DM version of PCI driver before the DM conversion.
> > >
> > > Once all boards have converted to DM PCI, we can revert this revert patch
> > > again.
> > >
> > > > Tom, do you know the situation here?
> >
> > So, I made a lack of DM_PCI migration be fatal and got a build done
> > here:
> > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
> >
> > Of note, MIPS malta fails, so I had to drop that from pytest to complete
> > the world build. There's then a handful of ARM boards, another large
> > chunk of PowerPC, and then a few others such as r7780mp. SH is the big
> > what to do here to me, other than PowerPC, as other than r2dplus
> > everything is missing the main "convert to DM" migration deadline as
> > well.
>
> What should we do for this patch?
>
> If the plan is to drop all boards that are not converted to DM PCI in
> 2021.04, I can drop this revert patch in v2.
I've posted the patch to drop the SH boards. Daniel, what about Malta?
I guess maybe the next steps are I need to pull in the already acked
board removal patches I've posted and then do another posting of "remove
these boards now" and see what shakes out.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] fdt/sunxi: Remove OF_STDOUT_PATH
On Sun, Feb 14, 2021 at 12:33:58PM +, Andre Przywara wrote: > OF_STDOUT_PATH was meant to hold the devicetree path to the serial > console, to be put into the linux,stdout-path property of the chosen node. > > The only user of that was sunxi, and it was actually wrong for years > there: the paths hardcoded in sunxi_common.h were not matching the DTs, > evident by the leading 0's in nodenames, which have been removed years > ago. > > On top of that, "linux,stdout-path" is now deprecated for a while (Linux > commit 2a9d832cc9aae from November 2014), and also all modern DTs > (including those included in U-Boot) carry a "stdout-path" property > already. > > So remove the stanza from sunxi_common.h, and, since this was the last > user, also remove the associated bits from the rest of U-Boot. > > Signed-off-by: Andre Przywara Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/4] mx53loco: Convert to driver model
On Sat, Feb 13, 2021 at 10:49:52PM -0300, Fabio Estevam wrote: > Make the conversion to driver model as it is mandatory. > > Remove the SATA support for now as the i.MX53 support has not > been added yet. > > Signed-off-by: Fabio Estevam Where is something missing for SATA support? With DM enabled, you can enable AHCI and BLK and DWC_AHSATA is already converted. Is there some i.MX specific work required still? Thanks! -- Tom signature.asc Description: PGP signature
[RESEND PATCH 2/2] arch: sandbox: fix typo in clk.h
Fix the 'devivce' typo in arch/sandbox/include/asm/clk.h. Signed-off-by: Dario Binacchi Reviewed-by: Simon Glass --- arch/sandbox/include/asm/clk.h | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/arch/sandbox/include/asm/clk.h b/arch/sandbox/include/asm/clk.h index 0294baee27..68a8687f57 100644 --- a/arch/sandbox/include/asm/clk.h +++ b/arch/sandbox/include/asm/clk.h @@ -74,7 +74,7 @@ int sandbox_clk_query_requested(struct udevice *dev, int id); * sandbox_clk_test_get - Ask the sandbox clock test device to request its * clocks. * - * @dev: The sandbox clock test (client) devivce. + * @dev: The sandbox clock test (client) device. * @return:0 if OK, or a negative error code. */ int sandbox_clk_test_get(struct udevice *dev); @@ -83,7 +83,7 @@ int sandbox_clk_test_get(struct udevice *dev); * sandbox_clk_test_devm_get - Ask the sandbox clock test device to request its * clocks using the managed API. * - * @dev: The sandbox clock test (client) devivce. + * @dev: The sandbox clock test (client) device. * @return:0 if OK, or a negative error code. */ int sandbox_clk_test_devm_get(struct udevice *dev); @@ -92,7 +92,7 @@ int sandbox_clk_test_devm_get(struct udevice *dev); * sandbox_clk_test_get_bulk - Ask the sandbox clock test device to request its * clocks with the bulk clk API. * - * @dev: The sandbox clock test (client) devivce. + * @dev: The sandbox clock test (client) device. * @return:0 if OK, or a negative error code. */ int sandbox_clk_test_get_bulk(struct udevice *dev); @@ -100,7 +100,7 @@ int sandbox_clk_test_get_bulk(struct udevice *dev); * sandbox_clk_test_get_rate - Ask the sandbox clock test device to query a * clock's rate. * - * @dev: The sandbox clock test (client) devivce. + * @dev: The sandbox clock test (client) device. * @id:The test device's clock ID to query. * @return:The rate of the clock. */ @@ -118,7 +118,7 @@ ulong sandbox_clk_test_round_rate(struct udevice *dev, int id, ulong rate); * sandbox_clk_test_set_rate - Ask the sandbox clock test device to set a * clock's rate. * - * @dev: The sandbox clock test (client) devivce. + * @dev: The sandbox clock test (client) device. * @id:The test device's clock ID to configure. * @return:The new rate of the clock. */ @@ -127,7 +127,7 @@ ulong sandbox_clk_test_set_rate(struct udevice *dev, int id, ulong rate); * sandbox_clk_test_enable - Ask the sandbox clock test device to enable a * clock. * - * @dev: The sandbox clock test (client) devivce. + * @dev: The sandbox clock test (client) device. * @id:The test device's clock ID to configure. * @return:0 if OK, or a negative error code. */ @@ -136,7 +136,7 @@ int sandbox_clk_test_enable(struct udevice *dev, int id); * sandbox_clk_test_enable_bulk - Ask the sandbox clock test device to enable * all clocks in it's clock bulk struct. * - * @dev: The sandbox clock test (client) devivce. + * @dev: The sandbox clock test (client) device. * @return:0 if OK, or a negative error code. */ int sandbox_clk_test_enable_bulk(struct udevice *dev); @@ -144,7 +144,7 @@ int sandbox_clk_test_enable_bulk(struct udevice *dev); * sandbox_clk_test_disable - Ask the sandbox clock test device to disable a * clock. * - * @dev: The sandbox clock test (client) devivce. + * @dev: The sandbox clock test (client) device. * @id:The test device's clock ID to configure. * @return:0 if OK, or a negative error code. */ @@ -153,7 +153,7 @@ int sandbox_clk_test_disable(struct udevice *dev, int id); * sandbox_clk_test_disable_bulk - Ask the sandbox clock test device to disable * all clocks in it's clock bulk struct. * - * @dev: The sandbox clock test (client) devivce. + * @dev: The sandbox clock test (client) device. * @return:0 if OK, or a negative error code. */ int sandbox_clk_test_disable_bulk(struct udevice *dev); @@ -161,7 +161,7 @@ int sandbox_clk_test_disable_bulk(struct udevice *dev); * sandbox_clk_test_free - Ask the sandbox clock test device to free its * clocks. * - * @dev: The sandbox clock test (client) devivce. + * @dev: The sandbox clock test (client) device. * @return:0 if OK, or a negative error code. */ int sandbox_clk_test_free(struct udevice *dev); @@ -169,7 +169,7 @@ int sandbox_clk_test_free(struct udevice *dev); * sandbox_clk_test_release_bulk - Ask the sandbox clock test device to release * all clocks in it's clock bulk struct. * - * @dev: The sandbox clock test (client) devivce. + * @dev: The sandbox clock test (client) device. * @return:0 if OK, or a negative error code. */ int sandbox_clk_test_release_bulk(struct udevice *dev); @@ -177,7 +177,7 @@ int sandbox_clk_test_release_bulk(struct udevice
[RESEND PATCH 1/2] clk: remove a redundant header
The linux/err.h header file was included twice. Signed-off-by: Dario Binacchi Reviewed-by: Simon Glass --- include/linux/clk-provider.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h index c871ea646d..cc9c430512 100644 --- a/include/linux/clk-provider.h +++ b/include/linux/clk-provider.h @@ -12,7 +12,6 @@ #include #include #include -#include struct udevice; -- 2.17.1
[RESEND PATCH 0/2] clk patches from 'Add DM support for omap PWM backlight' series
As suggested by Grygorii Strashko I have removed these patches from the 'Add DM support for omap PWM backlight' series and grouped them into this one. The patches have already been reviewed by Simon Glass. Dario Binacchi (2): clk: remove a redundant header arch: sandbox: fix typo in clk.h arch/sandbox/include/asm/clk.h | 26 +- include/linux/clk-provider.h | 1 - 2 files changed, 13 insertions(+), 14 deletions(-) -- 2.17.1
Re: [PATCH] sunxi: Remove dead ifdefs in sunxi-common.h
On Mon, 8 Feb 2021 00:04:57 -0600 Samuel Holland wrote: Hi, > As variables were moved to Kconfig, some of the surrounding ifdefs were > left around, even though they were empty. Clean them up. > > Signed-off-by: Samuel Holland Indeed, thanks for the cleanup! Reviewed-by: Andre Przywara Cheers, Andre > --- > include/configs/sunxi-common.h | 15 --- > 1 file changed, 15 deletions(-) > > diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h > index 000f3864702..64a70f9375c 100644 > --- a/include/configs/sunxi-common.h > +++ b/include/configs/sunxi-common.h > @@ -134,11 +134,6 @@ > #define CONFIG_BOARD_SIZE_LIMIT 0x7e000 > #endif > > -#if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1 > -/* If we have two devices (most likely eMMC + MMC), favour the eMMC */ > -#else > -/* Otherwise, use the only device we have */ > -#endif > #define CONFIG_SYS_MMC_MAX_DEVICE4 > #endif > > @@ -199,10 +194,6 @@ > > > /* I2C */ > -#if defined CONFIG_AXP152_POWER || defined CONFIG_AXP209_POWER || \ > -defined CONFIG_SY8106A_POWER > -#endif > - > #if defined CONFIG_I2C0_ENABLE || defined CONFIG_I2C1_ENABLE || \ > defined CONFIG_I2C2_ENABLE || defined CONFIG_I2C3_ENABLE || \ > defined CONFIG_I2C4_ENABLE || defined CONFIG_R_I2C_ENABLE > @@ -232,12 +223,6 @@ extern int soft_i2c_gpio_scl; > #define CONFIG_VIDEO_LCD_I2C_BUS -1 /* NA, but necessary to compile */ > #endif > > -/* PMU */ > -#if defined CONFIG_AXP152_POWER || defined CONFIG_AXP209_POWER || \ > -defined CONFIG_AXP221_POWER || defined CONFIG_AXP818_POWER || \ > -defined CONFIG_SY8106A_POWER > -#endif > - > #ifdef CONFIG_REQUIRE_SERIAL_CONSOLE > #if CONFIG_CONS_INDEX == 1 > #ifdef CONFIG_MACH_SUN9I
Pull request for UEFI sub-system for efi-2021-04-rc2-2
Hello Tom, in the following pull request I have included a correction for binman because without it Gitlab has a time out on the binman job. The binman patch has been reviewed by Simon. See https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/6381 which passed and https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/6379 which timed out. The following changes since commit 7c82e12cc4e9e25d7c89fe15bfeec4e9b0bb2b4d: Merge tag 'u-boot-atmel-fixes-2021.04-a' of https://gitlab.denx.de/u-boot/custodians/u-boot-atmel (2021-02-12 09:09:10 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2021-04-rc2-2 for you to fetch changes up to fd434f47d4d008d41f4ee2fe5cb94791f780395c: buildman: 'Thread' object has no attribute 'isAlive' (2021-02-14 11:32:04 +0100) Gitlab shows no problem: https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/6381 Pull request for UEFI sub-system for efi-2021-04-rc2-2 Bug fixes: * fix stack smashing in UEFI capsule updates * correct loading of UEFI binaries where Virtual size is not a multiple of FileAlignment * simplify detection of capsule files. * buildman: use threading.is_alive() instead of removed method IsAlive() Asherah Connor (1): efi_loader: don't load beyond VirtualSize Heinrich Schuchardt (3): efi_loader: '.' and '..' are directories efi_loader: fix get_last_capsule() buildman: 'Thread' object has no attribute 'isAlive' lib/efi_loader/efi_capsule.c | 22 ++ lib/efi_loader/efi_image_loader.c | 2 +- tools/buildman/builder.py | 2 +- 3 files changed, 16 insertions(+), 10 deletions(-)
[PATCH] fdt/sunxi: Remove OF_STDOUT_PATH
OF_STDOUT_PATH was meant to hold the devicetree path to the serial
console, to be put into the linux,stdout-path property of the chosen node.
The only user of that was sunxi, and it was actually wrong for years
there: the paths hardcoded in sunxi_common.h were not matching the DTs,
evident by the leading 0's in nodenames, which have been removed years
ago.
On top of that, "linux,stdout-path" is now deprecated for a while (Linux
commit 2a9d832cc9aae from November 2014), and also all modern DTs
(including those included in U-Boot) carry a "stdout-path" property
already.
So remove the stanza from sunxi_common.h, and, since this was the last
user, also remove the associated bits from the rest of U-Boot.
Signed-off-by: Andre Przywara
---
README | 1 -
common/fdt_support.c | 9 +
include/configs/sunxi-common.h | 18 --
scripts/config_whitelist.txt | 1 -
4 files changed, 1 insertion(+), 28 deletions(-)
diff --git a/README b/README
index f7f9aa56196..b962ba7c2f7 100644
--- a/README
+++ b/README
@@ -575,7 +575,6 @@ The following options need to be configured:
* The bootm command automatically updates the fdt
OF_TBCLK - The timebase frequency.
- OF_STDOUT_PATH - The path to the console device
boards with QUICC Engines require OF_QE to set UCC MAC
addresses
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 638eca983e8..4fa1e9f1aee 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -127,14 +127,7 @@ int fdt_find_or_add_subnode(void *fdt, int parentoffset,
const char *name)
return offset;
}
-/* rename to CONFIG_OF_STDOUT_PATH ? */
-#if defined(OF_STDOUT_PATH)
-static int fdt_fixup_stdout(void *fdt, int chosenoff)
-{
- return fdt_setprop(fdt, chosenoff, "linux,stdout-path",
- OF_STDOUT_PATH, strlen(OF_STDOUT_PATH) + 1);
-}
-#elif defined(CONFIG_OF_STDOUT_VIA_ALIAS) && defined(CONFIG_CONS_INDEX)
+#if defined(CONFIG_OF_STDOUT_VIA_ALIAS) && defined(CONFIG_CONS_INDEX)
static int fdt_fixup_stdout(void *fdt, int chosenoff)
{
int err;
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 000f3864702..8c1fce9929a 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -238,24 +238,6 @@ extern int soft_i2c_gpio_scl;
defined CONFIG_SY8106A_POWER
#endif
-#ifdef CONFIG_REQUIRE_SERIAL_CONSOLE
-#if CONFIG_CONS_INDEX == 1
-#ifdef CONFIG_MACH_SUN9I
-#define OF_STDOUT_PATH "/soc/serial@0700:115200"
-#else
-#define OF_STDOUT_PATH "/soc@01c0/serial@01c28000:115200"
-#endif
-#elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUN5I)
-#define OF_STDOUT_PATH "/soc@01c0/serial@01c28400:115200"
-#elif CONFIG_CONS_INDEX == 3 && defined(CONFIG_MACH_SUN8I)
-#define OF_STDOUT_PATH "/soc@01c0/serial@01c28800:115200"
-#elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN8I)
-#define OF_STDOUT_PATH "/soc@01c0/serial@01f02800:115200"
-#else
-#error Unsupported console port nr. Please fix stdout-path in sunxi-common.h.
-#endif
-#endif /* ifdef CONFIG_REQUIRE_SERIAL_CONSOLE */
-
#ifdef CONFIG_VIDEO_SUNXI
/*
* The amount of RAM to keep free at the top of RAM when relocating u-boot,
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index c6a83124956..b39cdab96c1 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -1182,7 +1182,6 @@ CONFIG_NUM_PAMU
CONFIG_ODROID_REV_AIN
CONFIG_OFF_PADCONF
CONFIG_OF_
-CONFIG_OF_STDOUT_PATH
CONFIG_OMAP_EHCI_PHY1_RESET_GPIO
CONFIG_OMAP_EHCI_PHY2_RESET_GPIO
CONFIG_OMAP_EHCI_PHY3_RESET_GPIO
--
2.17.5
Re: [PATCH v2] serial: s5p: Allow independent selection
Am Fri, Feb 12, 2021 at 11:22:18PM +0100 schrieb Mark Kettenis: > Currently support for the Samsung serial port driver is part > of CONFIG_S5P which controls selection of several drivers for > the S5P family. Give it its own config option such that we > can use it on other SoCs as well. > > Signed-off-by: Mark Kettenis Reviewed-by: Patrick Wildt > --- > > v2: fix Kconfig > > drivers/serial/Kconfig | 7 +++ > drivers/serial/Makefile | 2 +- > 2 files changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig > index 9db4cae1df..2ada150526 100644 > --- a/drivers/serial/Kconfig > +++ b/drivers/serial/Kconfig > @@ -722,6 +722,13 @@ config ROCKCHIP_SERIAL > This uses the ns16550 driver, converting the platdata from of-platdata > to the ns16550 format. > > +config S5P_SERIAL > + bool "Support for Samsung S5P UART" > + depends on ARCH_EXYNOS || ARCH_S5PC1XX > + default y > + help > + Select this to enable Samsung S5P UART support. > + > config SANDBOX_SERIAL > bool "Sandbox UART support" > depends on SANDBOX > diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile > index 0c3810f5d5..92bcb30b85 100644 > --- a/drivers/serial/Makefile > +++ b/drivers/serial/Makefile > @@ -41,7 +41,7 @@ obj-$(CONFIG_EFI_APP) += serial_efi.o > obj-$(CONFIG_LPC32XX_HSUART) += lpc32xx_hsuart.o > obj-$(CONFIG_MCFUART) += serial_mcf.o > obj-$(CONFIG_SYS_NS16550) += ns16550.o > -obj-$(CONFIG_S5P) += serial_s5p.o > +obj-$(CONFIG_S5P_SERIAL) += serial_s5p.o > obj-$(CONFIG_MXC_UART) += serial_mxc.o > obj-$(CONFIG_PXA_SERIAL) += serial_pxa.o > obj-$(CONFIG_MESON_SERIAL) += serial_meson.o > -- > 2.30.0 >
