Re: [PATCH v3 6/6] rockchip: Enable PCIe/M.2 on rock960 board
Hi Kever,
On Fri, May 22, 2020 at 8:45 AM Kever Yang wrote:
>
> Hi Jagan,
>
> On 2020/5/10 上午12:56, Jagan Teki wrote:
> > Due to board limitation some SSD's would work
> > on rock960 PCIe M.2 only with 1.8V IO domain.
> >
> > So, this patch enables grf io_sel explicitly to
> > make PCIe/M.2 to work.
> >
> > Cc: Tom Cubie
> > Signed-off-by: Jagan Teki
> > Acked-by: Manivannan Sadhasivam
> > ---
> > Changes for v3:
> > - collect mani a-b
> > - add comments
> >
> > board/vamrs/rock960_rk3399/rock960-rk3399.c | 23 +
> > configs/rock960-rk3399_defconfig| 5 +
> > 2 files changed, 28 insertions(+)
> >
> > diff --git a/board/vamrs/rock960_rk3399/rock960-rk3399.c
> > b/board/vamrs/rock960_rk3399/rock960-rk3399.c
> > index 68a127b9ac..ef1eb2d0b7 100644
> > --- a/board/vamrs/rock960_rk3399/rock960-rk3399.c
> > +++ b/board/vamrs/rock960_rk3399/rock960-rk3399.c
> > @@ -2,3 +2,26 @@
> > /*
> >* Copyright (C) 2018 Manivannan Sadhasivam
> >
> >*/
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#ifdef CONFIG_MISC_INIT_R
> > +int misc_init_r(void)
> > +{
> > + struct rk3399_grf_regs *grf =
> > + syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
> > +
> > + /**
> > + * Some SSD's to work on rock960 would require explicit
> > + * domain voltage change, so BT565 is in 1.8v domain
> > + */
> > + rk_setreg(&grf->io_vsel, BIT(0));
> + rk_setreg(&grf->io_vsel, BIT(0));
> + ^
> +arch/arm/include/asm/io.h:118:34: note: in definition of macro ‘writel’
> + #define writel(v,c) ({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v; })
> + ^
> +board/vamrs/rock960_rk3399/rock960-rk3399.c:23:2: note: in expansion of
> macro ‘rk_setreg’
> + ^
> +board/vamrs/rock960_rk3399/built-in.o: In function `misc_init_r':
> +board/vamrs/rock960_rk3399/rock960-rk3399.c:23: undefined reference to
> `BIT'
> +make[1]: *** [u-boot] Error 139
>
>
> Did you get this error when build the code?
Sorry, I have forgotten to commit bitops header, will send this patch
alone for the next version.
Jagan.
[PATCH v4 6/6] rockchip: Enable PCIe/M.2 on rock960 board
Due to board limitation some SSD's would work
on rock960 PCIe M.2 only with 1.8V IO domain.
So, this patch enables grf io_sel explicitly to
make PCIe/M.2 to work.
Cc: Tom Cubie
Acked-by: Manivannan Sadhasivam
Signed-off-by: Jagan Teki
---
Changes for v4:
- Add missing header bitops.h
board/vamrs/rock960_rk3399/rock960-rk3399.c | 24 +
configs/rock960-rk3399_defconfig| 5 +
2 files changed, 29 insertions(+)
diff --git a/board/vamrs/rock960_rk3399/rock960-rk3399.c
b/board/vamrs/rock960_rk3399/rock960-rk3399.c
index 68a127b9ac..a7fc38d42f 100644
--- a/board/vamrs/rock960_rk3399/rock960-rk3399.c
+++ b/board/vamrs/rock960_rk3399/rock960-rk3399.c
@@ -2,3 +2,27 @@
/*
* Copyright (C) 2018 Manivannan Sadhasivam
*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_MISC_INIT_R
+int misc_init_r(void)
+{
+ struct rk3399_grf_regs *grf =
+ syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+
+ /**
+* Some SSD's to work on rock960 would require explicit
+* domain voltage change, so BT565 is in 1.8v domain
+*/
+ rk_setreg(&grf->io_vsel, BIT(0));
+
+ return 0;
+}
+#endif
diff --git a/configs/rock960-rk3399_defconfig b/configs/rock960-rk3399_defconfig
index 045d989a19..64517f9623 100644
--- a/configs/rock960-rk3399_defconfig
+++ b/configs/rock960-rk3399_defconfig
@@ -9,6 +9,7 @@ CONFIG_DEBUG_UART_BASE=0xFF1A
CONFIG_DEBUG_UART_CLOCK=2400
CONFIG_DEBUG_UART=y
CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rock960.dtb"
+CONFIG_MISC_INIT_R=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
CONFIG_SPL_STACK_R=y
@@ -19,6 +20,7 @@ CONFIG_CMD_BOOTZ=y
CONFIG_CMD_GPT=y
CONFIG_CMD_MMC=y
CONFIG_CMD_USB=y
+CONFIG_CMD_PCI=y
# CONFIG_CMD_SETEXPR is not set
CONFIG_CMD_TIME=y
CONFIG_CMD_PMIC=y
@@ -36,10 +38,13 @@ CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_SDMA=y
CONFIG_MMC_SDHCI_ROCKCHIP=y
CONFIG_DM_ETH=y
+CONFIG_NVME=y
+CONFIG_PCI=y
CONFIG_PMIC_RK8XX=y
CONFIG_REGULATOR_PWM=y
CONFIG_REGULATOR_RK8XX=y
CONFIG_PWM_ROCKCHIP=y
+CONFIG_DM_RESET=y
CONFIG_BAUDRATE=150
CONFIG_DEBUG_UART_SHIFT=2
CONFIG_SYSRESET=y
--
2.20.1
Re: [PATCH v5 1/2] usb: provide a device tree node to USB devices
Hi Simon,
Am 2020-05-22 04:34, schrieb Simon Glass:
Hi Michael,
On Thu, 21 May 2020 at 17:28, Michael Walle wrote:
Am 2020-05-21 16:13, schrieb Bin Meng:
> On Thu, May 21, 2020 at 12:40 AM Michael Walle
> wrote:
>>
>> It is possible to specify a device tree node for an USB device. This
>> is
>> useful if you have a static USB setup and want to use aliases which
>> point to these nodes, like on the Raspberry Pi.
>> The nodes are matched against their hub port number, the compatible
>> strings are not matched for now.
>>
>> Signed-off-by: Michael Walle
>> ---
>> This is a new patch in v5:
>> Fixes the ethernet0 alias on Raspberry Pis. This has never been
>> working, but wasn't a problem until recently. Patch 2/2 changes
>> the allocation of the numbers and reserves possible aliases.
>>
>> drivers/usb/host/usb-uclass.c | 41
>> ++-
>> 1 file changed, 36 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/usb/host/usb-uclass.c
>> b/drivers/usb/host/usb-uclass.c
>> index cb79dfbbd5..f42c0625cb 100644
>> --- a/drivers/usb/host/usb-uclass.c
>> +++ b/drivers/usb/host/usb-uclass.c
>> @@ -494,6 +494,35 @@ static int usb_match_one_id(struct
>> usb_device_descriptor *desc,
>> return usb_match_one_id_intf(desc, int_desc, id);
>> }
>>
>> +static ofnode usb_get_ofnode(struct udevice *hub, int port)
>> +{
>> + ofnode node;
>> + u32 reg;
>> +
>> + if (!dev_has_of_node(hub))
>> + return ofnode_null();
>> +
>> + /*
>> +* The USB controller and its USB hub are two different
>> udevices,
>> +* but the device tree has only one node for both. Thus we are
>> +* assigning this node to both udevices.
>> +* If port is zero, the controller scans its root hub, thus we
>> +* are using the same ofnode as the controller here.
>> +*/
>> + if (!port)
>> + return dev_ofnode(hub);
>> +
>> + ofnode_for_each_subnode(node, dev_ofnode(hub)) {
>> + if (ofnode_read_u32(node, "reg", ®))
>> + continue;
>> +
>> + if (reg == port)
>> + return node;
>> + }
>> +
>> + return ofnode_null();
>> +}
>> +
>> /**
>> * usb_find_and_bind_driver() - Find and bind the right USB driver
>> *
>> @@ -502,13 +531,14 @@ static int usb_match_one_id(struct
>> usb_device_descriptor *desc,
>> static int usb_find_and_bind_driver(struct udevice *parent,
>> struct usb_device_descriptor
>> *desc,
>> struct usb_interface_descriptor
>> *iface,
>> - int bus_seq, int devnum,
>> + int bus_seq, int devnum, int port,
>> struct udevice **devp)
>> {
>> struct usb_driver_entry *start, *entry;
>> int n_ents;
>> int ret;
>> char name[30], *str;
>> + ofnode node = usb_get_ofnode(parent, port);
>>
>> *devp = NULL;
>> debug("%s: Searching for driver\n", __func__);
>> @@ -533,8 +563,8 @@ static int usb_find_and_bind_driver(struct udevice
>> *parent,
>> * find another driver. For now this doesn't
>> seem
>> * necesssary, so just bind the first match.
>> */
>> - ret = device_bind(parent, drv, drv->name,
>> NULL, -1,
>> - &dev);
>> + ret = device_bind_ofnode(parent, drv,
>> drv->name, NULL,
>> +node, &dev);
>> if (ret)
>> goto error;
>> debug("%s: Match found: %s\n", __func__,
>> drv->name);
>> @@ -651,9 +681,10 @@ int usb_scan_device(struct udevice *parent, int
>> port,
>> if (ret) {
>> if (ret != -ENOENT)
>> return ret;
>> - ret = usb_find_and_bind_driver(parent,
>> &udev->descriptor, iface,
>> + ret = usb_find_and_bind_driver(parent,
>> &udev->descriptor,
>> + iface,
>>
>> udev->controller_dev->seq,
>> - udev->devnum, &dev);
>> + udev->devnum, port,
>> &dev);
>> if (ret)
>> return ret;
>> created = true;
>> --
>
> Do we have tests added ?
Adding tests for this isn't straight forward. Mostly because the
device
tree
is used to add the emulated USB devices. OTOH we try to match the
device
tree
to the scanned devices. To make things worse, the hierarchy of the USB
hubs
and usb devices doesn't seem to fit a "normal" device tree.
This is described in usb-info.rst
Eg. in sandbox/dts/test.dts it is:
usb@1 {
/* this is the controller */
hub {
/* I don't
[PATCH] spi: cadence_spi: Add octal and quad write support
In Commit d64077202158 ("spi: cadence_qspi: Move to spi-mem framework")
it removes setting to quad write bit by accident. This commit restores
it back and also adding checking for octal support.
Fixes: d64077202158 ("spi: cadence_qspi: Move to spi-mem framework")
Signed-off-by: Ley Foon Tan
---
drivers/spi/cadence_qspi_apb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index f9675f75a401..aaf5f600c6dc 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -689,6 +689,12 @@ int cadence_qspi_apb_write_setup(struct
cadence_spi_platdata *plat,
/* Configure the opcode */
reg = op->cmd.opcode << CQSPI_REG_WR_INSTR_OPCODE_LSB;
+
+ if (op->data.buswidth == 8)
+ reg |= CQSPI_INST_TYPE_OCTAL <<
CQSPI_REG_WR_INSTR_TYPE_DATA_LSB;
+ else if (op->data.buswidth == 4)
+ reg |= CQSPI_INST_TYPE_QUAD << CQSPI_REG_WR_INSTR_TYPE_DATA_LSB;
+
writel(reg, plat->regbase + CQSPI_REG_WR_INSTR);
writel(op->addr.val, plat->regbase + CQSPI_REG_INDIRECTWRSTARTADDR);
--
2.19.0
Re: [PATCH] arm: mach-k3: j721e_init: Add support for backup boot modes
On 16/05/20 9:05 pm, Faiz Abbas wrote:
> From: Andreas Dannenberg
>
> When the boot of J721E devices using the primary bootmode (configured
> via device pins) fails a boot using the configured backup bootmode is
> attempted. To take advantage of the backup boot mode feature go ahead
> and add support to the J721E init code to determine whether the ROM code
> performed the boot using the primary or backup boot mode, and if booted
> from the backup boot mode, decode the bootmode settings into the
> appropriate U-Boot mode accordingly so that the boot can proceed.
>
> Signed-off-by: Andreas Dannenberg
> Signed-off-by: Faiz Abbas
> ---
> .../arm/mach-k3/include/mach/j721e_hardware.h | 2 ++
> arch/arm/mach-k3/include/mach/j721e_spl.h | 12 +++
> arch/arm/mach-k3/j721e_init.c | 35 +--
> 3 files changed, 47 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-k3/include/mach/j721e_hardware.h
> b/arch/arm/mach-k3/include/mach/j721e_hardware.h
> index ead136ed63..2efa911a9a 100644
> --- a/arch/arm/mach-k3/include/mach/j721e_hardware.h
> +++ b/arch/arm/mach-k3/include/mach/j721e_hardware.h
> @@ -18,6 +18,8 @@
> #define MAIN_DEVSTAT_BKUP_BOOTMODE_SHIFT 1
> #define MAIN_DEVSTAT_PRIM_BOOTMODE_MMC_PORT_MASK BIT(6)
> #define MAIN_DEVSTAT_PRIM_BOOTMODE_PORT_SHIFT6
> +#define MAIN_DEVSTAT_BKUP_MMC_PORT_MASK BIT(7)
> +#define MAIN_DEVSTAT_BKUP_MMC_PORT_SHIFT 7
>
> #define WKUP_CTRL_MMR0_BASE 0x4300
> #define MCU_CTRL_MMR0_BASE 0x40f0
> diff --git a/arch/arm/mach-k3/include/mach/j721e_spl.h
> b/arch/arm/mach-k3/include/mach/j721e_spl.h
> index 475278bd04..1cabc01dc4 100644
> --- a/arch/arm/mach-k3/include/mach/j721e_spl.h
> +++ b/arch/arm/mach-k3/include/mach/j721e_spl.h
> @@ -25,7 +25,19 @@
> #define BOOT_DEVICE_MMC2_2 0x16
> #define BOOT_DEVICE_RAM 0x17
>
> +/* Backup boot modes with MCU Only = 0 */
> +#define BACKUP_BOOT_DEVICE_RAM 0x0
> +#define BACKUP_BOOT_DEVICE_USB 0x1
Please use BACKUP_BOOT_DEVICE_DFU instead like how BOOT_DEVICE_DFU is
used for primary boot mode.
BOOT_DEVICE_USB is usually used with host mode so using that for DFU
would be confusing.
BTW, for my information, have you verified all backup boot media?
Regards
Vignesh
> +#define BACKUP_BOOT_DEVICE_UART 0x3
> +#define BACKUP_BOOT_DEVICE_ETHERNET 0x4
> +#define BACKUP_BOOT_DEVICE_MMC2 0x5
> +#define BACKUP_BOOT_DEVICE_SPI 0x6
> +#define BACKUP_BOOT_DEVICE_I2C 0x7
> +
> #define BOOT_MODE_B_SHIFT4
> #define BOOT_MODE_B_MASK BIT(4)
>
> +#define K3_PRIMARY_BOOTMODE 0x0
> +#define K3_BACKUP_BOOTMODE 0x1
> +
> #endif
> diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
> index 71fc20c30b..18a3c1c052 100644
> --- a/arch/arm/mach-k3/j721e_init.c
> +++ b/arch/arm/mach-k3/j721e_init.c
> @@ -235,6 +235,35 @@ u32 spl_mmc_boot_mode(const u32 boot_device)
> }
> }
>
> +static u32 __get_backup_bootmedia(u32 main_devstat)
> +{
> + u32 bkup_boot = (main_devstat & MAIN_DEVSTAT_BKUP_BOOTMODE_MASK) >>
> + MAIN_DEVSTAT_BKUP_BOOTMODE_SHIFT;
> +
> + switch (bkup_boot) {
> + case BACKUP_BOOT_DEVICE_USB:
> + return BOOT_DEVICE_DFU;
> + case BACKUP_BOOT_DEVICE_UART:
> + return BOOT_DEVICE_UART;
> + case BACKUP_BOOT_DEVICE_ETHERNET:
> + return BOOT_DEVICE_ETHERNET;
> + case BACKUP_BOOT_DEVICE_MMC2:
> + {
> + u32 port = (main_devstat & MAIN_DEVSTAT_BKUP_MMC_PORT_MASK) >>
> + MAIN_DEVSTAT_BKUP_MMC_PORT_SHIFT;
> + if (port == 0x0)
> + return BOOT_DEVICE_MMC1;
> + return BOOT_DEVICE_MMC2;
> + }
> + case BACKUP_BOOT_DEVICE_SPI:
> + return BOOT_DEVICE_SPI;
> + case BACKUP_BOOT_DEVICE_I2C:
> + return BOOT_DEVICE_I2C;
> + }
> +
> + return BOOT_DEVICE_RAM;
> +}
> +
> static u32 __get_primary_bootmedia(u32 main_devstat, u32 wkup_devstat)
> {
>
> @@ -271,8 +300,10 @@ u32 spl_boot_device(void)
> /* MAIN CTRL MMR can only be read if MCU ONLY is 0 */
> main_devstat = readl(CTRLMMR_MAIN_DEVSTAT);
>
> - /* ToDo: Add support for backup boot media */
> - return __get_primary_bootmedia(main_devstat, wkup_devstat);
> + if (bootindex == K3_PRIMARY_BOOTMODE)
> + return __get_primary_bootmedia(main_devstat, wkup_devstat);
> + else
> + return __get_backup_bootmedia(main_devstat);
> }
> #endif
>
>
[PATCH v6 0/3] gpio: add possibility to search for gpio label name
search for gpio label if gpio name from bankname is not found. This makes sense on boards with different hardware verions. You can now search for the gpio label name, and can give the gpio a unique name. The real gpio pin number is not needed in board code anymore. while at it add basic gpio hog test functions in seperate patch. Travis: https://travis-ci.org/github/hsdenx/u-boot-test/builds/689908393 Changes in v6: - add reviewed by from Patrick and Fixes tag - add Reviewed-by tag from Simon - add additional comments from Simon: - remove "default n" in Kconfig for SPL_DM_GPIO_LOOKUP_LABEL - type of function in same line as the function - add negativ test, where label is not found Changes in v5: - add comment from patrick, update the descriptor flags in _dm_gpio_set_dir_flags() if setting direction was OK. - add Reviewed-by tag from Simon Changes in v4: - new in version 4 - rebased to current master ac14bc4169 - rebased to current master ac14bc4169 Changes in v3: - add comment from Simon Glass make this new function configurable through Kconfig option DM_GPIO_LOOKUP_LABEL Changes in v2: - add basic gpio hog test functions - add comment from Simon Glass move code into seperate function dm_gpio_lookup_label() add test if dm_gpio_lookup_label() works Heiko Schocher (3): gpio-uclass.c: save the GPIOD flags also in the gpio descriptor sandbox, test: add test for GPIO_HOG function gpio: search for gpio label if gpio is not found through bank name arch/sandbox/dts/test.dts | 20 +++ configs/sandbox64_defconfig| 1 + configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 + configs/sandbox_spl_defconfig | 1 + drivers/gpio/Kconfig | 21 drivers/gpio/gpio-uclass.c | 54 +++--- test/dm/gpio.c | 32 ++ 8 files changed, 127 insertions(+), 4 deletions(-) -- 2.24.1
[PATCH v6 1/3] gpio-uclass.c: save the GPIOD flags also in the gpio descriptor
save the GPIOD_ flags also in the gpio descriptor.
Signed-off-by: Heiko Schocher
Reviewed-by: Patrick Delaunay
Fixes: 788ea834124b ("gpio: add function _dm_gpio_set_dir_flags")
---
Changes in v6:
- add reviewed by from Patrick and Fixes tag
Changes in v5:
- add comment from patrick, update the descriptor flags
in _dm_gpio_set_dir_flags() if setting direction was OK.
Changes in v4:
- new in version 4
Changes in v3: None
Changes in v2: None
drivers/gpio/gpio-uclass.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index 9eeab22eef..f016532354 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -600,6 +600,10 @@ static int _dm_gpio_set_dir_flags(struct gpio_desc *desc,
ulong flags)
}
}
+ /* save the flags also in descriptor */
+ if (!ret)
+ desc->flags = flags;
+
return ret;
}
@@ -615,10 +619,6 @@ int dm_gpio_set_dir_flags(struct gpio_desc *desc, ulong
flags)
flags |= desc->flags;
ret = _dm_gpio_set_dir_flags(desc, flags);
- /* update the descriptor flags */
- if (ret)
- desc->flags = flags;
-
return ret;
}
--
2.24.1
[PATCH v6 3/3] gpio: search for gpio label if gpio is not found through bank name
dm_gpio_lookup_name() searches for a gpio through
the bank name. But we have also gpio labels, and it
makes sense to search for a gpio also in the labels
we have defined, if no gpio is found through the
bank name definition.
This is useful for example if you have a wp pin on
different gpios on different board versions.
If dm_gpio_lookup_name() searches also for the gpio labels,
you can give the gpio an unique label name and search
for this label, and do not need to differ between
board revisions.
Signed-off-by: Heiko Schocher
Reviewed-by: Simon Glass
---
Example on the aristainetos board:
=> gpio clear wp_spi_nor.gpio-hog
gpio: pin wp_spi_nor.gpio-hog (gpio 47) value is 0
=>
before this patch, you need to know where your
pin is:
=> gpio clear GPIO2_15
gpio: pin GPIO2_15 (gpio 47) value is 0
=>
travis build:
Changes in v6:
- add Reviewed-by tag from Simon
- add additional comments from Simon:
- remove "default n" in Kconfig for SPL_DM_GPIO_LOOKUP_LABEL
- type of function in same line as the function
- add negativ test, where label is not found
Changes in v5: None
Changes in v4:
- rebased to current master ac14bc4169
Changes in v3:
- add comment from Simon Glass
make this new function configurable through Kconfig
option DM_GPIO_LOOKUP_LABEL
Changes in v2:
- add comment from Simon Glass
move code into seperate function dm_gpio_lookup_label()
add test if dm_gpio_lookup_label() works
drivers/gpio/Kconfig | 21 +
drivers/gpio/gpio-uclass.c | 46 ++
test/dm/gpio.c | 9
3 files changed, 76 insertions(+)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index d87f6cc105..829c68eda1 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -46,6 +46,27 @@ config GPIO_HOG
is a mechanism providing automatic GPIO request and config-
uration as part of the gpio-controller's driver probe function.
+config DM_GPIO_LOOKUP_LABEL
+ bool "Enable searching for gpio labelnames"
+ depends on DM_GPIO
+ default y
+ help
+ This option enables searching for gpio names in
+ the defined gpio labels, if the search for the
+ gpio bank name failed. This makes sense if you use
+ different gpios on different hardware versions
+ for the same functionality in board code.
+
+config SPL_DM_GPIO_LOOKUP_LABEL
+ bool "Enable searching for gpio labelnames"
+ depends on DM_GPIO && SPL_DM && SPL_GPIO_SUPPORT
+ help
+ This option enables searching for gpio names in
+ the defined gpio labels, if the search for the
+ gpio bank name failed. This makes sense if you use
+ different gpios on different hardware versions
+ for the same functionality in board code.
+
config ALTERA_PIO
bool "Altera PIO driver"
depends on DM_GPIO
diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index f016532354..ab17fa8a5d 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -68,6 +68,45 @@ static int gpio_to_device(unsigned int gpio, struct
gpio_desc *desc)
return ret ? ret : -ENOENT;
}
+#if CONFIG_IS_ENABLED(DM_GPIO_LOOKUP_LABEL)
+/**
+ * dm_gpio_lookup_label() - look for name in gpio device
+ *
+ * search in uc_priv, if there is a gpio with labelname same
+ * as name.
+ *
+ * @name: name which is searched
+ * @uc_priv: gpio_dev_priv pointer.
+ * @offset:gpio offset within the device
+ * @return:0 if found, -ENOENT if not.
+ */
+static int dm_gpio_lookup_label(const char *name,
+ struct gpio_dev_priv *uc_priv, ulong *offset)
+{
+ int len;
+ int i;
+
+ *offset = -1;
+ len = strlen(name);
+ for (i = 0; i < uc_priv->gpio_count; i++) {
+ if (!uc_priv->name[i])
+ continue;
+ if (!strncmp(name, uc_priv->name[i], len)) {
+ *offset = i;
+ return 0;
+ }
+ }
+ return -ENOENT;
+}
+#else
+static int
+dm_gpio_lookup_label(const char *name, struct gpio_dev_priv *uc_priv,
+ulong *offset)
+{
+ return -ENOENT;
+}
+#endif
+
int dm_gpio_lookup_name(const char *name, struct gpio_desc *desc)
{
struct gpio_dev_priv *uc_priv = NULL;
@@ -96,6 +135,13 @@ int dm_gpio_lookup_name(const char *name, struct gpio_desc
*desc)
if (!strict_strtoul(name + len, 10, &offset))
break;
}
+
+ /*
+* if we did not found a gpio through its bank
+* name, we search for a valid gpio label.
+*/
+ if (!dm_gpio_lookup_label(name, uc_priv, &offset))
+ break;
}
if (!dev)
diff --git a/test/dm/gpio.c b/test/dm/gpio.c
index ecba566983..fcee1fe598 100644
--- a/test/dm/gpio.c
+++ b/test
[PATCH v6 2/3] sandbox, test: add test for GPIO_HOG function
currently gpio hog function is not tested with "ut dm gpio"
so add some basic tests for gpio hog functionality.
For this enable GPIO_HOG in sandbox_defconfig, add
in DTS some gpio hog entries, and add testcase in
"ut dm gpio" command.
Signed-off-by: Heiko Schocher
Reviewed-by: Simon Glass
---
Changes in v6: None
Changes in v5:
- add Reviewed-by tag from Simon
Changes in v4:
- rebased to current master ac14bc4169
Changes in v3: None
Changes in v2:
- add basic gpio hog test functions
arch/sandbox/dts/test.dts | 20
configs/sandbox64_defconfig| 1 +
configs/sandbox_defconfig | 1 +
configs/sandbox_flattree_defconfig | 1 +
configs/sandbox_spl_defconfig | 1 +
test/dm/gpio.c | 23 +++
6 files changed, 47 insertions(+)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 5ce5e28476..24bb3ce36f 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -343,6 +343,26 @@
#gpio-cells = <1>;
gpio-bank-name = "a";
sandbox,gpio-count = <20>;
+ hog_input_active_low {
+ gpio-hog;
+ input;
+ gpios = <0 GPIO_ACTIVE_LOW>;
+ };
+ hog_input_active_high {
+ gpio-hog;
+ input;
+ gpios = <1 GPIO_ACTIVE_HIGH>;
+ };
+ hog_output_low {
+ gpio-hog;
+ output-low;
+ gpios = <2 GPIO_ACTIVE_HIGH>;
+ };
+ hog_output_high {
+ gpio-hog;
+ output-high;
+ gpios = <3 GPIO_ACTIVE_HIGH>;
+ };
};
gpio_b: extra-gpios {
diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index c1237ea296..39dc3dc687 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -98,6 +98,7 @@ CONFIG_DM_DEMO_SIMPLE=y
CONFIG_DM_DEMO_SHAPE=y
CONFIG_BOARD=y
CONFIG_BOARD_SANDBOX=y
+CONFIG_GPIO_HOG=y
CONFIG_PM8916_GPIO=y
CONFIG_SANDBOX_GPIO=y
CONFIG_I2C_CROS_EC_TUNNEL=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 9445d78118..9015458070 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -115,6 +115,7 @@ CONFIG_BOARD_SANDBOX=y
CONFIG_DMA=y
CONFIG_DMA_CHANNELS=y
CONFIG_SANDBOX_DMA=y
+CONFIG_GPIO_HOG=y
CONFIG_PM8916_GPIO=y
CONFIG_SANDBOX_GPIO=y
CONFIG_DM_HWSPINLOCK=y
diff --git a/configs/sandbox_flattree_defconfig
b/configs/sandbox_flattree_defconfig
index a4a7ae8379..b5a85e1278 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -83,6 +83,7 @@ CONFIG_DM_DEMO_SIMPLE=y
CONFIG_DM_DEMO_SHAPE=y
CONFIG_BOARD=y
CONFIG_BOARD_SANDBOX=y
+CONFIG_GPIO_HOG=y
CONFIG_PM8916_GPIO=y
CONFIG_SANDBOX_GPIO=y
CONFIG_I2C_CROS_EC_TUNNEL=y
diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig
index 945fe54d20..7341fa3221 100644
--- a/configs/sandbox_spl_defconfig
+++ b/configs/sandbox_spl_defconfig
@@ -102,6 +102,7 @@ CONFIG_DM_DEMO_SHAPE=y
CONFIG_BOARD=y
CONFIG_BOARD_SANDBOX=y
CONFIG_SPL_FIRMWARE=y
+CONFIG_GPIO_HOG=y
CONFIG_PM8916_GPIO=y
CONFIG_SANDBOX_GPIO=y
CONFIG_I2C_CROS_EC_TUNNEL=y
diff --git a/test/dm/gpio.c b/test/dm/gpio.c
index b5ee4e4f87..ecba566983 100644
--- a/test/dm/gpio.c
+++ b/test/dm/gpio.c
@@ -20,6 +20,7 @@ static int dm_test_gpio(struct unit_test_state *uts)
unsigned int offset, gpio;
struct dm_gpio_ops *ops;
struct udevice *dev;
+ struct gpio_desc *desc;
const char *name;
int offset_count;
char buf[80];
@@ -109,6 +110,28 @@ static int dm_test_gpio(struct unit_test_state *uts)
ut_asserteq_str("a", name);
ut_asserteq(20, offset_count);
+ /* add gpio hog tests */
+ ut_assertok(gpio_hog_lookup_name("hog_input_active_low", &desc));
+ ut_asserteq(GPIOD_IS_IN | GPIOD_ACTIVE_LOW, desc->flags);
+ ut_asserteq(0, desc->offset);
+ ut_asserteq(1, dm_gpio_get_value(desc));
+ ut_assertok(gpio_hog_lookup_name("hog_input_active_high", &desc));
+ ut_asserteq(GPIOD_IS_IN, desc->flags);
+ ut_asserteq(1, desc->offset);
+ ut_asserteq(0, dm_gpio_get_value(desc));
+ ut_assertok(gpio_hog_lookup_name("hog_output_low", &desc));
+ ut_asserteq(GPIOD_IS_OUT, desc->flags);
+ ut_asserteq(2, desc->offset);
+ ut_asserteq(0, dm_gpio_get_value(desc));
+ ut_assertok(dm_gpio_set_value(desc, 1));
+ ut_asserteq(1, dm_gpio_get_value(desc));
+ ut_assertok(gpio_hog_lookup_name("hog_output_high", &desc));
+ ut
Re: [PATCH v1 1/3] board: ns3: add optee based bnxt fw load driver
On Wed, May 20, 2020 at 7:45 AM Thomas Fitzsimmons wrote: > > Hi Rayagonda and Vikas, > > Rayagonda Kokatanur writes: > > > From: Vikas Gupta > > > > Add optee based bnxt fw load driver. > > What is "bnxt"? Maybe you could add a comment explaining what it is, or > at least expanding it if it's an acronym? bnxt is Broadcom NetXtreme controller ethernet cards. I will expand it in the commit message. > > Thanks, > Thomas
Re: [PATCH v1 1/3] board: ns3: add optee based bnxt fw load driver
Hi Simon, On Fri, May 22, 2020 at 12:51 AM Simon Glass wrote: > > Hi, > > On Tue, 19 May 2020 at 20:15, Thomas Fitzsimmons wrote: > > > > Hi Rayagonda and Vikas, > > > > Rayagonda Kokatanur writes: > > > > > From: Vikas Gupta > > > > > > Add optee based bnxt fw load driver. > > > > What is "bnxt"? Maybe you could add a comment explaining what it is, or > > at least expanding it if it's an acronym? > > > Also how about putting it in drivers/ ? Okay, I will move the driver file to drivers/tee/broadcom and header file to include/broadcom/. > > Also are there docs somewhere on how an image is put together? We do not have any docs on how the bnxt( Broadcom NetXtreme controller) binary is created. We receive it as a binary and using OpTEE we load the binary to bnxt. > > > - Simon
Re: [PATCH v2] drivers: crypto: mod_exp_sw: Re-add DM_FLAG_PRE_RELOC
On 5/20/20 2:22 PM, Tom Rini wrote:
> On Thu, May 07, 2020 at 08:36:03PM +0200, Jan Kiszka wrote:
>
>> From: Jan Kiszka
>>
>> This driver is safe to use in SPL without relocation. Denying
>> DM_FLAG_PRE_RELOC prevents its usability for verifying the main U-Boot
>> or other artifacts from the SPL unless needless enabling the full driver
>> set (SPL_OF_PLATDATA).
>>
>> Fixes: 17e117408571 ("drivers: crypto: rsa_mod_exp: avoid DM_FLAG_PRE_RELOC")
>> CC: Heinrich Schuchardt
>> CC: Marek Vasut
>> Signed-off-by: Jan Kiszka
>
> Applied to u-boot/master, thanks!
>
With this patch applied pine64-lts_defconfig with CONFIG_RSA=y does not
boot anymore. See the output below. So something is wrong with this driver.
Do you have an idea how to analyze what is wrong? Unfortunately there is
no DEBUG_UART available on the Pine A64 LTS board.
Best regards
Heinrich
U-Boot SPL 2020.07-rc2-00070-g2fa581ba91 (May 22 2020 - 10:29:30 +)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE: BL31: v2.2():v2.2-1138-g78460ced4
NOTICE: BL31: Built : 05:50:47, Apr 7 2020
NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE: BL31: Found U-Boot DTB at 0x4091998, model: Pine64 LTS
INFO:ARM GICv2 driver initialized
INFO:Configuring SPC Controller
INFO:PMIC: Probing AXP803 on RSB
INFO:PMIC: dcdc1 voltage: 3.300V
INFO:PMIC: dcdc5 voltage: 1.200V
INFO:PMIC: dcdc6 voltage: 1.100V
INFO:PMIC: dldo1 voltage: 3.300V
INFO:PMIC: Enabling DC SW
INFO:BL31: Platform setup done
INFO:BL31: Initializing runtime services
INFO:BL31: cortex_a53: CPU workaround for 843419 was applied
INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
NOTICE: PSCI: System suspend is unavailable
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x4a00
INFO:SPSR = 0x3c9
U-Boot SPL 2020.07-rc2-00070-g2fa581ba91 (May 22 2020 - 10:29:30 +)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE: BL31: v2.2():v2.2-1138-g78460ced4
NOTICE: BL31: Built : 05:50:47, Apr 7 2020
NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE: BL31: Found U-Boot DTB at 0x4091998, model: Pine64 LTS
INFO:ARM GICv2 driver initialized
INFO:Configuring SPC Controller
INFO:PMIC: Probing AXP803 on RSB
INFO:PMIC: dcdc1 voltage: 3.300V
INFO:PMIC: dcdc5 voltage: 1.200V
INFO:PMIC: dcdc6 voltage: 1.100V
INFO:PMIC: dldo1 voltage: 3.300V
INFO:PMIC: Enabling DC SW
INFO:BL31: Platform setup done
INFO:BL31: Initializing runtime services
INFO:BL31: cortex_a53: CPU workaround for 843419 was applied
INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
NOTICE: PSCI: System suspend is unavailable
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x4a00
INFO:SPSR = 0x3c9
U-Boot SPL 2020.07-rc2-00070-g2fa581ba91 (May 22 2020 - 10:29:30 +)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE: BL31: v2.2():v2.2-1138-g78460ced4
NOTICE: BL31: Built : 05:50:47, Apr 7 2020
NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE: BL31: Found U-Boot DTB at 0x4091998, model: Pine64 LTS
INFO:ARM GICv2 driver initialized
INFO:Configuring SPC Controller
INFO:PMIC: Probing AXP803 on RSB
INFO:PMIC: dcdc1 voltage: 3.300V
INFO:PMIC: dcdc5 voltage: 1.200V
INFO:PMIC: dcdc6 voltage: 1.100V
INFO:PMIC: dldo1 voltage: 3.300V
INFO:PMIC: Enabling DC SW
INFO:BL31: Platform setup done
INFO:BL31: Initializing runtime services
INFO:BL31: cortex_a53: CPU workaround for 843419 was applied
INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
NOTICE: PSCI: System suspend is unavailable
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x4a00
INFO:SPSR = 0x3c9
[PATCH 0/7] mmc: zynqmp_sdhci: Add support for Tap delay
Hi, this patchset adding support for Tap delay programming for ZynqMP and Versal. Based on mainline discussion also DT properties have been introduced which are documented here. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/devicetree/bindings/mmc/mmc-controller.yaml?h=v5.7-rc6&id=fec81c5bca2499b4a263667860018c2ce47f4f51 The patchset is using these DT properties which are optional. Default values are also listed. The patchset is based on: https://lists.denx.de/pipermail/u-boot/2020-May/410326.html Also new code is adding checking for SOCs which are not needed at that time when patch is applied (For example "mmc: zynq_sdhci: Read clock phase delays from dt" and IS_ENABLED(CONFIG_ARCH_ZYNQMP)... But I kept it there for more cleaner patches built on the top. Thanks, Michal Ashok Reddy Soma (5): Revert "mmc: zynq: parse dt when probing" mmc: zynq_sdhci: Define timing macro's mmc: zynq_sdhci: Set tapdelays based on clk phase delays mmc: zynq_sdhci: Add clock phase delays for Versal mmc: zynq_sdhci: Extend UHS timings till hs200 Michal Simek (2): mmc: zynq_sdhci: Move macro to the top mmc: zynq_sdhci: Read clock phase delays from dt drivers/mmc/sdhci.c | 3 +- drivers/mmc/zynq_sdhci.c | 406 --- include/mmc.h| 13 ++ include/sdhci.h | 1 + 4 files changed, 398 insertions(+), 25 deletions(-) -- 2.26.2
[PATCH 1/7] Revert "mmc: zynq: parse dt when probing"
From: Ashok Reddy Soma
This reverts commit 942b5fc03218d1c94468fc658e7dec65dabcc830.
This is partial revert of the above commit.
mmc_of_parse() is reading no-1-8-v from device tree and if set,
it is clearing the UHS speed capabilities of cfg->host_caps.
cfg->host_caps &= ~(UHS_CAPS | MMC_MODE_HS200 |
MMC_MODE_HS400 | MMC_MODE_HS400_ES);
This is still missing to clear UHS speeds like SDHCI_SUPPORT_SDR104,
SDHCI_SUPPORT_SDR50 and SDHCI_SUPPORT_DDR50.
Even if we clear the flags SDHCI_SUPPORT_XXX in mmc_of_parse(),
these speed flags are getting set again in cfg->host_caps in
sdhci_setup_cfg().
The reason for this is, SDHCI_SUPPORT_XXX flags are cleared
only if controller is not capable of supporting MMC_VDD_165_195 volts.
if (caps & SDHCI_CAN_VDD_180)
cfg->voltages |= MMC_VDD_165_195;
if (!(cfg->voltages & MMC_VDD_165_195))
caps_1 &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
SDHCI_SUPPORT_DDR50);
It means "no-1-8-v", which is read from DT is not coming in to effect.
So it is better we keep the host quirks(SDHCI_QUIRK_NO_1_8_V) to
clear UHS speeds based on no-1-8-v from device tree.
Hence revert the functionality related to no-1-8-v only, rest is fine
in the patch.
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Michal Simek
---
drivers/mmc/sdhci.c | 3 ++-
drivers/mmc/zynq_sdhci.c | 5 +
include/sdhci.h | 1 +
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 92cc8434af24..099a007984a8 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -844,7 +844,8 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct
sdhci_host *host,
cfg->host_caps &= ~MMC_MODE_HS_52MHz;
}
- if (!(cfg->voltages & MMC_VDD_165_195))
+ if (!(cfg->voltages & MMC_VDD_165_195) ||
+ (host->quirks & SDHCI_QUIRK_NO_1_8_V))
caps_1 &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
SDHCI_SUPPORT_DDR50);
diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 43b9f215229a..94c69cf1c1bd 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -28,6 +28,7 @@ struct arasan_sdhci_priv {
struct sdhci_host *host;
u8 deviceid;
u8 bank;
+ u8 no_1p8;
};
#if defined(CONFIG_ARCH_ZYNQMP)
@@ -236,6 +237,9 @@ static int arasan_sdhci_probe(struct udevice *dev)
host->quirks |= SDHCI_QUIRK_BROKEN_HISPD_MODE;
#endif
+ if (priv->no_1p8)
+ host->quirks |= SDHCI_QUIRK_NO_1_8_V;
+
plat->cfg.f_max = CONFIG_ZYNQ_SDHCI_MAX_FREQ;
ret = mmc_of_parse(dev, &plat->cfg);
@@ -277,6 +281,7 @@ static int arasan_sdhci_ofdata_to_platdata(struct udevice
*dev)
priv->deviceid = dev_read_u32_default(dev, "xlnx,device_id", -1);
priv->bank = dev_read_u32_default(dev, "xlnx,mio_bank", -1);
+ priv->no_1p8 = dev_read_bool(dev, "no-1-8-v");
return 0;
}
diff --git a/include/sdhci.h b/include/sdhci.h
index 94fc3ed56ace..ef84bebcb4aa 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -244,6 +244,7 @@
#define SDHCI_QUIRK_BROKEN_HISPD_MODE BIT(5)
#define SDHCI_QUIRK_WAIT_SEND_CMD (1 << 6)
#define SDHCI_QUIRK_USE_WIDE8 (1 << 8)
+#define SDHCI_QUIRK_NO_1_8_V (1 << 9)
/* to make gcc happy */
struct sdhci_host;
--
2.26.2
[PATCH 2/7] mmc: zynq_sdhci: Define timing macro's
From: Ashok Reddy Soma
Define timing macro's for all the available speeds of mmc. This is
done similar to linux. Replace other macro's used in zynq_sdhci.c
with these new macro's.
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Michal Simek
---
drivers/mmc/zynq_sdhci.c | 24 +++-
include/mmc.h| 13 +
2 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 94c69cf1c1bd..02583f76f936 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -32,20 +32,18 @@ struct arasan_sdhci_priv {
};
#if defined(CONFIG_ARCH_ZYNQMP)
-#define MMC_HS200_BUS_SPEED5
-
static const u8 mode2timing[] = {
- [MMC_LEGACY] = UHS_SDR12_BUS_SPEED,
- [MMC_HS] = HIGH_SPEED_BUS_SPEED,
- [SD_HS] = HIGH_SPEED_BUS_SPEED,
- [MMC_HS_52] = HIGH_SPEED_BUS_SPEED,
- [MMC_DDR_52] = HIGH_SPEED_BUS_SPEED,
- [UHS_SDR12] = UHS_SDR12_BUS_SPEED,
- [UHS_SDR25] = UHS_SDR25_BUS_SPEED,
- [UHS_SDR50] = UHS_SDR50_BUS_SPEED,
- [UHS_DDR50] = UHS_DDR50_BUS_SPEED,
- [UHS_SDR104] = UHS_SDR104_BUS_SPEED,
- [MMC_HS_200] = MMC_HS200_BUS_SPEED,
+ [MMC_LEGACY] = MMC_TIMING_LEGACY,
+ [MMC_HS] = MMC_TIMING_MMC_HS,
+ [SD_HS] = MMC_TIMING_SD_HS,
+ [MMC_HS_52] = MMC_TIMING_UHS_SDR50,
+ [MMC_DDR_52] = MMC_TIMING_UHS_DDR50,
+ [UHS_SDR12] = MMC_TIMING_UHS_SDR12,
+ [UHS_SDR25] = MMC_TIMING_UHS_SDR25,
+ [UHS_SDR50] = MMC_TIMING_UHS_SDR50,
+ [UHS_DDR50] = MMC_TIMING_UHS_DDR50,
+ [UHS_SDR104] = MMC_TIMING_UHS_SDR104,
+ [MMC_HS_200] = MMC_TIMING_MMC_HS200,
};
#define SDHCI_TUNING_LOOP_COUNT40
diff --git a/include/mmc.h b/include/mmc.h
index 82562193cc48..05d8ab8eeac6 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -360,6 +360,19 @@ enum mmc_voltage {
#define MMC_NUM_BOOT_PARTITION 2
#define MMC_PART_RPMB 3 /* RPMB partition number */
+/* timing specification used */
+#define MMC_TIMING_LEGACY 0
+#define MMC_TIMING_MMC_HS 1
+#define MMC_TIMING_SD_HS 2
+#define MMC_TIMING_UHS_SDR12 3
+#define MMC_TIMING_UHS_SDR25 4
+#define MMC_TIMING_UHS_SDR50 5
+#define MMC_TIMING_UHS_SDR104 6
+#define MMC_TIMING_UHS_DDR50 7
+#define MMC_TIMING_MMC_DDR52 8
+#define MMC_TIMING_MMC_HS200 9
+#define MMC_TIMING_MMC_HS400 10
+
/* Driver model support */
/**
--
2.26.2
[PATCH 3/7] mmc: zynq_sdhci: Move macro to the top
Just group macros below headers. Other patches will be using this location
too.
Signed-off-by: Michal Simek
---
drivers/mmc/zynq_sdhci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 02583f76f936..1c83aab84021 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -19,6 +19,8 @@
#include
#include
+#define SDHCI_TUNING_LOOP_COUNT40
+
struct arasan_sdhci_plat {
struct mmc_config cfg;
struct mmc mmc;
@@ -46,8 +48,6 @@ static const u8 mode2timing[] = {
[MMC_HS_200] = MMC_TIMING_MMC_HS200,
};
-#define SDHCI_TUNING_LOOP_COUNT40
-
static void arasan_zynqmp_dll_reset(struct sdhci_host *host, u8 deviceid)
{
u16 clk;
--
2.26.2
[PATCH 4/7] mmc: zynq_sdhci: Read clock phase delays from dt
Define input and output clock phase delays with pre-defined values.
Define arasan_sdhci_clk_data type structure and add it to priv
structure and store these clock phase delays in it.
Read input and output clock phase delays from dt. If these values are
not passed through dt, use pre-defined values.
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Michal Simek
---
drivers/mmc/zynq_sdhci.c | 85
1 file changed, 85 insertions(+)
diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 1c83aab84021..d3a32c98aa35 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -20,6 +20,12 @@
#include
#define SDHCI_TUNING_LOOP_COUNT40
+#define MMC_BANK2 0x2
+
+struct arasan_sdhci_clk_data {
+ int clk_phase_in[MMC_TIMING_MMC_HS400 + 1];
+ int clk_phase_out[MMC_TIMING_MMC_HS400 + 1];
+};
struct arasan_sdhci_plat {
struct mmc_config cfg;
@@ -28,12 +34,17 @@ struct arasan_sdhci_plat {
struct arasan_sdhci_priv {
struct sdhci_host *host;
+ struct arasan_sdhci_clk_data clk_data;
u8 deviceid;
u8 bank;
u8 no_1p8;
};
#if defined(CONFIG_ARCH_ZYNQMP)
+/* Default settings for ZynqMP Clock Phases */
+const u32 zynqmp_iclk_phases[] = {0, 63, 63, 0, 63, 0, 0, 183, 54, 0, 0};
+const u32 zynqmp_oclk_phases[] = {0, 72, 60, 0, 60, 72, 135, 48, 72, 135, 0};
+
static const u8 mode2timing[] = {
[MMC_LEGACY] = MMC_TIMING_LEGACY,
[MMC_HS] = MMC_TIMING_MMC_HS,
@@ -168,6 +179,79 @@ static void arasan_sdhci_set_tapdelay(struct sdhci_host
*host)
priv->bank);
}
+static void arasan_dt_read_clk_phase(struct udevice *dev, unsigned char timing,
+const char *prop)
+{
+ struct arasan_sdhci_priv *priv = dev_get_priv(dev);
+ struct arasan_sdhci_clk_data *clk_data = &priv->clk_data;
+ u32 clk_phase[2] = {0};
+
+ /*
+* Read Tap Delay values from DT, if the DT does not contain the
+* Tap Values then use the pre-defined values
+*/
+ if (dev_read_u32_array(dev, prop, &clk_phase[0], 2)) {
+ dev_dbg(dev, "Using predefined clock phase for %s = %d %d\n",
+ prop, clk_data->clk_phase_in[timing],
+ clk_data->clk_phase_out[timing]);
+ return;
+ }
+
+ /* The values read are Input and Output Clock Delays in order */
+ clk_data->clk_phase_in[timing] = clk_phase[0];
+ clk_data->clk_phase_out[timing] = clk_phase[1];
+}
+
+/**
+ * arasan_dt_parse_clk_phases - Read Tap Delay values from DT
+ *
+ * Called at initialization to parse the values of Tap Delays.
+ *
+ * @dev:Pointer to our struct udevice.
+ */
+static void arasan_dt_parse_clk_phases(struct udevice *dev)
+{
+ struct arasan_sdhci_priv *priv = dev_get_priv(dev);
+ struct arasan_sdhci_clk_data *clk_data = &priv->clk_data;
+ int i;
+
+ if (IS_ENABLED(CONFIG_ARCH_ZYNQMP) &&
+ device_is_compatible(dev, "xlnx,zynqmp-8.9a")) {
+ for (i = 0; i <= MMC_TIMING_MMC_HS400; i++) {
+ clk_data->clk_phase_in[i] = zynqmp_iclk_phases[i];
+ clk_data->clk_phase_out[i] = zynqmp_oclk_phases[i];
+ }
+
+ if (priv->bank == MMC_BANK2) {
+ clk_data->clk_phase_out[MMC_TIMING_UHS_SDR104] = 90;
+ clk_data->clk_phase_out[MMC_TIMING_MMC_HS200] = 90;
+ }
+ }
+
+ arasan_dt_read_clk_phase(dev, MMC_TIMING_LEGACY,
+"clk-phase-legacy");
+ arasan_dt_read_clk_phase(dev, MMC_TIMING_MMC_HS,
+"clk-phase-mmc-hs");
+ arasan_dt_read_clk_phase(dev, MMC_TIMING_SD_HS,
+"clk-phase-sd-hs");
+ arasan_dt_read_clk_phase(dev, MMC_TIMING_UHS_SDR12,
+"clk-phase-uhs-sdr12");
+ arasan_dt_read_clk_phase(dev, MMC_TIMING_UHS_SDR25,
+"clk-phase-uhs-sdr25");
+ arasan_dt_read_clk_phase(dev, MMC_TIMING_UHS_SDR50,
+"clk-phase-uhs-sdr50");
+ arasan_dt_read_clk_phase(dev, MMC_TIMING_UHS_SDR104,
+"clk-phase-uhs-sdr104");
+ arasan_dt_read_clk_phase(dev, MMC_TIMING_UHS_DDR50,
+"clk-phase-uhs-ddr50");
+ arasan_dt_read_clk_phase(dev, MMC_TIMING_MMC_DDR52,
+"clk-phase-mmc-ddr52");
+ arasan_dt_read_clk_phase(dev, MMC_TIMING_MMC_HS200,
+"clk-phase-mmc-hs200");
+ arasan_dt_read_clk_phase(dev, MMC_TIMING_MMC_HS400,
+"clk-phase-mmc-hs400");
+}
+
static void arasan_sdhci_set_control_reg(struct sdhci_host *host)
{
struct mmc *mmc = (struct mmc *)host-
[PATCH 5/7] mmc: zynq_sdhci: Set tapdelays based on clk phase delays
From: Ashok Reddy Soma
Define and use functions for setting input and output tapdelays
based on clk phase delays.
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Michal Simek
---
drivers/mmc/zynq_sdhci.c | 128 +--
1 file changed, 123 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index d3a32c98aa35..1e7b79906f88 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -166,17 +166,135 @@ static int arasan_sdhci_execute_tuning(struct mmc *mmc,
u8 opcode)
return 0;
}
+/**
+ * sdhci_zynqmp_sdcardclk_set_phase - Set the SD Output Clock Tap Delays
+ *
+ * Set the SD Output Clock Tap Delays for Output path
+ *
+ * @host: Pointer to the sdhci_host structure.
+ * @degrees: The clock phase shift between 0 - 359.
+ * Return: 0 on success and error value on error
+ */
+static int sdhci_zynqmp_sdcardclk_set_phase(struct sdhci_host *host,
+ int degrees)
+{
+ struct arasan_sdhci_priv *priv = dev_get_priv(host->mmc->dev);
+ struct mmc *mmc = (struct mmc *)host->mmc;
+ u8 tap_delay, tap_max = 0;
+ int ret;
+ int timing = mode2timing[mmc->selected_mode];
+
+ /*
+* This is applicable for SDHCI_SPEC_300 and above
+* ZynqMP does not set phase for <=25MHz clock.
+* If degrees is zero, no need to do anything.
+*/
+ if (host->version < SDHCI_SPEC_300 ||
+ timing == MMC_TIMING_LEGACY ||
+ timing == MMC_TIMING_UHS_SDR12 || !degrees)
+ return 0;
+
+ switch (timing) {
+ case MMC_TIMING_MMC_HS:
+ case MMC_TIMING_SD_HS:
+ case MMC_TIMING_UHS_SDR25:
+ case MMC_TIMING_UHS_DDR50:
+ case MMC_TIMING_MMC_DDR52:
+ /* For 50MHz clock, 30 Taps are available */
+ tap_max = 30;
+ break;
+ case MMC_TIMING_UHS_SDR50:
+ /* For 100MHz clock, 15 Taps are available */
+ tap_max = 15;
+ break;
+ case MMC_TIMING_UHS_SDR104:
+ case MMC_TIMING_MMC_HS200:
+ /* For 200MHz clock, 8 Taps are available */
+ tap_max = 8;
+ default:
+ break;
+ }
+
+ tap_delay = (degrees * tap_max) / 360;
+
+ arasan_zynqmp_set_tapdelay(priv->deviceid, 0, tap_delay);
+
+ return ret;
+}
+
+/**
+ * sdhci_zynqmp_sampleclk_set_phase - Set the SD Input Clock Tap Delays
+ *
+ * Set the SD Input Clock Tap Delays for Input path
+ *
+ * @host: Pointer to the sdhci_host structure.
+ * @degrees: The clock phase shift between 0 - 359.
+ * Return: 0 on success and error value on error
+ */
+static int sdhci_zynqmp_sampleclk_set_phase(struct sdhci_host *host,
+ int degrees)
+{
+ struct arasan_sdhci_priv *priv = dev_get_priv(host->mmc->dev);
+ struct mmc *mmc = (struct mmc *)host->mmc;
+ u8 tap_delay, tap_max = 0;
+ int ret;
+ int timing = mode2timing[mmc->selected_mode];
+
+ /*
+* This is applicable for SDHCI_SPEC_300 and above
+* ZynqMP does not set phase for <=25MHz clock.
+* If degrees is zero, no need to do anything.
+*/
+ if (host->version < SDHCI_SPEC_300 ||
+ timing == MMC_TIMING_LEGACY ||
+ timing == MMC_TIMING_UHS_SDR12 || !degrees)
+ return 0;
+
+ switch (timing) {
+ case MMC_TIMING_MMC_HS:
+ case MMC_TIMING_SD_HS:
+ case MMC_TIMING_UHS_SDR25:
+ case MMC_TIMING_UHS_DDR50:
+ case MMC_TIMING_MMC_DDR52:
+ /* For 50MHz clock, 120 Taps are available */
+ tap_max = 120;
+ break;
+ case MMC_TIMING_UHS_SDR50:
+ /* For 100MHz clock, 60 Taps are available */
+ tap_max = 60;
+ break;
+ case MMC_TIMING_UHS_SDR104:
+ case MMC_TIMING_MMC_HS200:
+ /* For 200MHz clock, 30 Taps are available */
+ tap_max = 30;
+ default:
+ break;
+ }
+
+ tap_delay = (degrees * tap_max) / 360;
+
+ arasan_zynqmp_set_tapdelay(priv->deviceid, tap_delay, 0);
+
+ return ret;
+}
+
static void arasan_sdhci_set_tapdelay(struct sdhci_host *host)
{
struct arasan_sdhci_priv *priv = dev_get_priv(host->mmc->dev);
+ struct arasan_sdhci_clk_data *clk_data = &priv->clk_data;
struct mmc *mmc = (struct mmc *)host->mmc;
- u8 uhsmode;
+ struct udevice *dev = mmc->dev;
+ u8 timing = mode2timing[mmc->selected_mode];
+ u32 iclk_phase = clk_data->clk_phase_in[timing];
+ u32 oclk_phase = clk_data->clk_phase_out[timing];
- uhsmode = mode2timing[mmc->selected_mode];
+ dev_dbg(dev, "%s, host:%s, mode:%d\n", __func__, host->name, timing);
- if (uhsmode >= UHS_SDR25_BUS_SPEED)
- arasan_zynqmp
[PATCH 7/7] mmc: zynq_sdhci: Extend UHS timings till hs200
From: Ashok Reddy Soma Fix the condition to set UHS timings for speeds upto HS200. Signed-off-by: Ashok Reddy Soma Signed-off-by: Michal Simek --- drivers/mmc/zynq_sdhci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c index 91ec552119d1..55762a13395c 100644 --- a/drivers/mmc/zynq_sdhci.c +++ b/drivers/mmc/zynq_sdhci.c @@ -539,7 +539,7 @@ static void arasan_sdhci_set_control_reg(struct sdhci_host *host) } if (mmc->selected_mode > SD_HS && - mmc->selected_mode <= UHS_DDR50) + mmc->selected_mode <= MMC_HS_200) sdhci_set_uhs_timing(host); } -- 2.26.2
[PATCH 6/7] mmc: zynq_sdhci: Add clock phase delays for Versal
From: Ashok Reddy Soma
Define default values for input and output clock phase delays for
Versal. Also define functions for setting tapdelays based on these
clock phase delays.
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Michal Simek
---
drivers/mmc/zynq_sdhci.c | 160 ++-
1 file changed, 156 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 1e7b79906f88..91ec552119d1 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -19,6 +19,12 @@
#include
#include
+#define SDHCI_ARASAN_ITAPDLY_REGISTER 0xF0F8
+#define SDHCI_ARASAN_OTAPDLY_REGISTER 0xF0FC
+#define SDHCI_ITAPDLY_CHGWIN 0x200
+#define SDHCI_ITAPDLY_ENABLE 0x100
+#define SDHCI_OTAPDLY_ENABLE 0x40
+
#define SDHCI_TUNING_LOOP_COUNT40
#define MMC_BANK2 0x2
@@ -40,11 +46,15 @@ struct arasan_sdhci_priv {
u8 no_1p8;
};
-#if defined(CONFIG_ARCH_ZYNQMP)
+#if defined(CONFIG_ARCH_ZYNQMP) || defined(CONFIG_ARCH_VERSAL)
/* Default settings for ZynqMP Clock Phases */
const u32 zynqmp_iclk_phases[] = {0, 63, 63, 0, 63, 0, 0, 183, 54, 0, 0};
const u32 zynqmp_oclk_phases[] = {0, 72, 60, 0, 60, 72, 135, 48, 72, 135, 0};
+/* Default settings for Versal Clock Phases */
+const u32 versal_iclk_phases[] = {0, 132, 132, 0, 132, 0, 0, 162, 90, 0, 0};
+const u32 versal_oclk_phases[] = {0, 60, 48, 0, 48, 72, 90, 36, 60, 90, 0};
+
static const u8 mode2timing[] = {
[MMC_LEGACY] = MMC_TIMING_LEGACY,
[MMC_HS] = MMC_TIMING_MMC_HS,
@@ -278,6 +288,138 @@ static int sdhci_zynqmp_sampleclk_set_phase(struct
sdhci_host *host,
return ret;
}
+/**
+ * sdhci_versal_sdcardclk_set_phase - Set the SD Output Clock Tap Delays
+ *
+ * Set the SD Output Clock Tap Delays for Output path
+ *
+ * @host: Pointer to the sdhci_host structure.
+ * @degrees: The clock phase shift between 0 - 359.
+ * Return: 0 on success and error value on error
+ */
+static int sdhci_versal_sdcardclk_set_phase(struct sdhci_host *host,
+ int degrees)
+{
+ struct mmc *mmc = (struct mmc *)host->mmc;
+ u8 tap_delay, tap_max = 0;
+ int ret;
+ int timing = mode2timing[mmc->selected_mode];
+
+ /*
+* This is applicable for SDHCI_SPEC_300 and above
+* Versal does not set phase for <=25MHz clock.
+* If degrees is zero, no need to do anything.
+*/
+ if (host->version < SDHCI_SPEC_300 ||
+ timing == MMC_TIMING_LEGACY ||
+ timing == MMC_TIMING_UHS_SDR12 || !degrees)
+ return 0;
+
+ switch (timing) {
+ case MMC_TIMING_MMC_HS:
+ case MMC_TIMING_SD_HS:
+ case MMC_TIMING_UHS_SDR25:
+ case MMC_TIMING_UHS_DDR50:
+ case MMC_TIMING_MMC_DDR52:
+ /* For 50MHz clock, 30 Taps are available */
+ tap_max = 30;
+ break;
+ case MMC_TIMING_UHS_SDR50:
+ /* For 100MHz clock, 15 Taps are available */
+ tap_max = 15;
+ break;
+ case MMC_TIMING_UHS_SDR104:
+ case MMC_TIMING_MMC_HS200:
+ /* For 200MHz clock, 8 Taps are available */
+ tap_max = 8;
+ default:
+ break;
+ }
+
+ tap_delay = (degrees * tap_max) / 360;
+
+ /* Set the Clock Phase */
+ if (tap_delay) {
+ u32 regval;
+
+ regval = sdhci_readl(host, SDHCI_ARASAN_OTAPDLY_REGISTER);
+ regval |= SDHCI_OTAPDLY_ENABLE;
+ sdhci_writel(host, regval, SDHCI_ARASAN_OTAPDLY_REGISTER);
+ regval |= tap_delay;
+ sdhci_writel(host, regval, SDHCI_ARASAN_OTAPDLY_REGISTER);
+ }
+
+ return ret;
+}
+
+/**
+ * sdhci_versal_sampleclk_set_phase - Set the SD Input Clock Tap Delays
+ *
+ * Set the SD Input Clock Tap Delays for Input path
+ *
+ * @host: Pointer to the sdhci_host structure.
+ * @degrees: The clock phase shift between 0 - 359.
+ * Return: 0 on success and error value on error
+ */
+static int sdhci_versal_sampleclk_set_phase(struct sdhci_host *host,
+ int degrees)
+{
+ struct mmc *mmc = (struct mmc *)host->mmc;
+ u8 tap_delay, tap_max = 0;
+ int ret;
+ int timing = mode2timing[mmc->selected_mode];
+
+ /*
+* This is applicable for SDHCI_SPEC_300 and above
+* Versal does not set phase for <=25MHz clock.
+* If degrees is zero, no need to do anything.
+*/
+ if (host->version < SDHCI_SPEC_300 ||
+ timing == MMC_TIMING_LEGACY ||
+ timing == MMC_TIMING_UHS_SDR12 || !degrees)
+ return 0;
+
+ switch (timing) {
+ case MMC_TIMING_MMC_HS:
+ case MMC_TIMING_SD_HS:
+ case MMC_TIMING_UHS_SDR25:
+ case MMC_TIMING_UHS_DDR50:
+ ca
Re: [PATCH v2] drivers: crypto: mod_exp_sw: Re-add DM_FLAG_PRE_RELOC
On 22.05.20 12:42, Heinrich Schuchardt wrote:
> On 5/20/20 2:22 PM, Tom Rini wrote:
>> On Thu, May 07, 2020 at 08:36:03PM +0200, Jan Kiszka wrote:
>>
>>> From: Jan Kiszka
>>>
>>> This driver is safe to use in SPL without relocation. Denying
>>> DM_FLAG_PRE_RELOC prevents its usability for verifying the main U-Boot
>>> or other artifacts from the SPL unless needless enabling the full driver
>>> set (SPL_OF_PLATDATA).
>>>
>>> Fixes: 17e117408571 ("drivers: crypto: rsa_mod_exp: avoid
>>> DM_FLAG_PRE_RELOC")
>>> CC: Heinrich Schuchardt
>>> CC: Marek Vasut
>>> Signed-off-by: Jan Kiszka
>>
>> Applied to u-boot/master, thanks!
>>
>
> With this patch applied pine64-lts_defconfig with CONFIG_RSA=y does not
> boot anymore. See the output below. So something is wrong with this driver.
>
> Do you have an idea how to analyze what is wrong? Unfortunately there is
> no DEBUG_UART available on the Pine A64 LTS board.
I would start crippling it down until things start to boot again. Are
you using it (for image verification e.g.), or is this just the
registration that breaks already?
Jan
>
> Best regards
>
> Heinrich
>
>
>
> U-Boot SPL 2020.07-rc2-00070-g2fa581ba91 (May 22 2020 - 10:29:30 +)
> DRAM: 2048 MiB
> Trying to boot from MMC1
> NOTICE: BL31: v2.2():v2.2-1138-g78460ced4
> NOTICE: BL31: Built : 05:50:47, Apr 7 2020
> NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689)
> NOTICE: BL31: Found U-Boot DTB at 0x4091998, model: Pine64 LTS
> INFO:ARM GICv2 driver initialized
> INFO:Configuring SPC Controller
> INFO:PMIC: Probing AXP803 on RSB
> INFO:PMIC: dcdc1 voltage: 3.300V
> INFO:PMIC: dcdc5 voltage: 1.200V
> INFO:PMIC: dcdc6 voltage: 1.100V
> INFO:PMIC: dldo1 voltage: 3.300V
> INFO:PMIC: Enabling DC SW
> INFO:BL31: Platform setup done
> INFO:BL31: Initializing runtime services
> INFO:BL31: cortex_a53: CPU workaround for 843419 was applied
> INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
> NOTICE: PSCI: System suspend is unavailable
> INFO:BL31: Preparing for EL3 exit to normal world
> INFO:Entry point address = 0x4a00
> INFO:SPSR = 0x3c9
>
> U-Boot SPL 2020.07-rc2-00070-g2fa581ba91 (May 22 2020 - 10:29:30 +)
> DRAM: 2048 MiB
> Trying to boot from MMC1
> NOTICE: BL31: v2.2():v2.2-1138-g78460ced4
> NOTICE: BL31: Built : 05:50:47, Apr 7 2020
> NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689)
> NOTICE: BL31: Found U-Boot DTB at 0x4091998, model: Pine64 LTS
> INFO:ARM GICv2 driver initialized
> INFO:Configuring SPC Controller
> INFO:PMIC: Probing AXP803 on RSB
> INFO:PMIC: dcdc1 voltage: 3.300V
> INFO:PMIC: dcdc5 voltage: 1.200V
> INFO:PMIC: dcdc6 voltage: 1.100V
> INFO:PMIC: dldo1 voltage: 3.300V
> INFO:PMIC: Enabling DC SW
> INFO:BL31: Platform setup done
> INFO:BL31: Initializing runtime services
> INFO:BL31: cortex_a53: CPU workaround for 843419 was applied
> INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
> NOTICE: PSCI: System suspend is unavailable
> INFO:BL31: Preparing for EL3 exit to normal world
> INFO:Entry point address = 0x4a00
> INFO:SPSR = 0x3c9
>
> U-Boot SPL 2020.07-rc2-00070-g2fa581ba91 (May 22 2020 - 10:29:30 +)
> DRAM: 2048 MiB
> Trying to boot from MMC1
> NOTICE: BL31: v2.2():v2.2-1138-g78460ced4
> NOTICE: BL31: Built : 05:50:47, Apr 7 2020
> NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689)
> NOTICE: BL31: Found U-Boot DTB at 0x4091998, model: Pine64 LTS
> INFO:ARM GICv2 driver initialized
> INFO:Configuring SPC Controller
> INFO:PMIC: Probing AXP803 on RSB
> INFO:PMIC: dcdc1 voltage: 3.300V
> INFO:PMIC: dcdc5 voltage: 1.200V
> INFO:PMIC: dcdc6 voltage: 1.100V
> INFO:PMIC: dldo1 voltage: 3.300V
> INFO:PMIC: Enabling DC SW
> INFO:BL31: Platform setup done
> INFO:BL31: Initializing runtime services
> INFO:BL31: cortex_a53: CPU workaround for 843419 was applied
> INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
> NOTICE: PSCI: System suspend is unavailable
> INFO:BL31: Preparing for EL3 exit to normal world
> INFO:Entry point address = 0x4a00
> INFO:SPSR = 0x3c9
>
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
Re: [PATCH 00/22] x86: Enhance MTRR functionality to support multiple CPUs
On Thu, May 21, 2020 at 08:23:04PM -0600, Simon Glass wrote: > At present MTRRs are mirrored to the secondary CPUs only once, as those > CPUs are started up. But U-Boot may add more MTRRs later, e.g. if it > decides that a video console must be set up. > > This series enhances the x86 multi-processor support to allow MTRRs to > be updated at any time. It also updates the 'mtrr' command to support > setting the MTRRs on CPUs other than the boot CPU. Hmm... Why do you need MTRR if CPU supports PAT? > > > Simon Glass (22): > x86: mp_init: Switch to livetree > x86: Move MP code into mp_init > x86: mp_init: Avoid declarations in header files > x86: mp_init: Switch parameter names in start_aps() > x86: mp_init: Drop the num_cpus static variable > x86: mtrr: Fix 'ensable' typo > x86: mp_init: Set up the CPU numbers at the start > x86: mp_init: Adjust bsp_init() to return more information > x86: cpu: Remove unnecessary #ifdefs > x86: mp: Support APs waiting for instructions > global_data: Add a generic global_data flag for SMP state > x86: Set the SMP flag when MP init is complete > x86: mp: Allow running functions on multiple CPUs > x86: mp: Park CPUs before running the OS > x86: mp: Add iterators for CPUs > x86: mtrr: Use MP calls to list the MTRRs > x86: mtrr: Update MTRRs on all CPUs > x86: mtrr: Add support for writing to MTRRs on any CPU > x86: mtrr: Update the command to use the new mtrr calls > x86: mtrr: Restructure so command execution is in one place > x86: mtrr: Update 'mtrr' to allow setting MTRRs on any CPU > x86: mtrr: Enhance 'mtrr' command to list MTRRs on any CPU > > arch/x86/cpu/cpu.c| 63 ++--- > arch/x86/cpu/i386/cpu.c | 26 +-- > arch/x86/cpu/mp_init.c| 377 +- > arch/x86/cpu/mtrr.c | 149 > arch/x86/include/asm/mp.h | 118 -- > arch/x86/include/asm/mtrr.h | 51 > cmd/x86/mtrr.c| 148 > include/asm-generic/global_data.h | 1 + > include/dm/uclass.h | 2 +- > 9 files changed, 751 insertions(+), 184 deletions(-) > > -- > 2.27.0.rc0.183.gde8f92d652-goog > -- With Best Regards, Andy Shevchenko
Re: [PATCH v2] drivers: crypto: mod_exp_sw: Re-add DM_FLAG_PRE_RELOC
Am May 22, 2020 10:50:29 AM UTC schrieb Jan Kiszka :
>On 22.05.20 12:42, Heinrich Schuchardt wrote:
>> On 5/20/20 2:22 PM, Tom Rini wrote:
>>> On Thu, May 07, 2020 at 08:36:03PM +0200, Jan Kiszka wrote:
>>>
From: Jan Kiszka
This driver is safe to use in SPL without relocation. Denying
DM_FLAG_PRE_RELOC prevents its usability for verifying the main
>U-Boot
or other artifacts from the SPL unless needless enabling the full
>driver
set (SPL_OF_PLATDATA).
Fixes: 17e117408571 ("drivers: crypto: rsa_mod_exp: avoid
>DM_FLAG_PRE_RELOC")
CC: Heinrich Schuchardt
CC: Marek Vasut
Signed-off-by: Jan Kiszka
>>>
>>> Applied to u-boot/master, thanks!
>>>
>>
>> With this patch applied pine64-lts_defconfig with CONFIG_RSA=y does
>not
>> boot anymore. See the output below. So something is wrong with this
>driver.
>>
>> Do you have an idea how to analyze what is wrong? Unfortunately there
>is
>> no DEBUG_UART available on the Pine A64 LTS board.
>
>I would start crippling it down until things start to boot again. Are
>you using it (for image verification e.g.), or is this just the
>registration that breaks already?
>
RSA is needed in the UEFI subsystem for verifying variables and images. But
there is no need in SPL for it at all.
In my configuration RSA is not used at all. Something breaks before even the
console becomes available.
The pine64-lts_defconfig board boots via SPL->BL31->U-Boot
Best regards
Heinrich
>Jan
>
>>
>> Best regards
>>
>> Heinrich
>>
>>
>>
>> U-Boot SPL 2020.07-rc2-00070-g2fa581ba91 (May 22 2020 - 10:29:30
>+)
>> DRAM: 2048 MiB
>> Trying to boot from MMC1
>> NOTICE: BL31: v2.2():v2.2-1138-g78460ced4
>> NOTICE: BL31: Built : 05:50:47, Apr 7 2020
>> NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689)
>> NOTICE: BL31: Found U-Boot DTB at 0x4091998, model: Pine64 LTS
>> INFO:ARM GICv2 driver initialized
>> INFO:Configuring SPC Controller
>> INFO:PMIC: Probing AXP803 on RSB
>> INFO:PMIC: dcdc1 voltage: 3.300V
>> INFO:PMIC: dcdc5 voltage: 1.200V
>> INFO:PMIC: dcdc6 voltage: 1.100V
>> INFO:PMIC: dldo1 voltage: 3.300V
>> INFO:PMIC: Enabling DC SW
>> INFO:BL31: Platform setup done
>> INFO:BL31: Initializing runtime services
>> INFO:BL31: cortex_a53: CPU workaround for 843419 was applied
>> INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
>> NOTICE: PSCI: System suspend is unavailable
>> INFO:BL31: Preparing for EL3 exit to normal world
>> INFO:Entry point address = 0x4a00
>> INFO:SPSR = 0x3c9
>>
>> U-Boot SPL 2020.07-rc2-00070-g2fa581ba91 (May 22 2020 - 10:29:30
>+)
>> DRAM: 2048 MiB
>> Trying to boot from MMC1
>> NOTICE: BL31: v2.2():v2.2-1138-g78460ced4
>> NOTICE: BL31: Built : 05:50:47, Apr 7 2020
>> NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689)
>> NOTICE: BL31: Found U-Boot DTB at 0x4091998, model: Pine64 LTS
>> INFO:ARM GICv2 driver initialized
>> INFO:Configuring SPC Controller
>> INFO:PMIC: Probing AXP803 on RSB
>> INFO:PMIC: dcdc1 voltage: 3.300V
>> INFO:PMIC: dcdc5 voltage: 1.200V
>> INFO:PMIC: dcdc6 voltage: 1.100V
>> INFO:PMIC: dldo1 voltage: 3.300V
>> INFO:PMIC: Enabling DC SW
>> INFO:BL31: Platform setup done
>> INFO:BL31: Initializing runtime services
>> INFO:BL31: cortex_a53: CPU workaround for 843419 was applied
>> INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
>> NOTICE: PSCI: System suspend is unavailable
>> INFO:BL31: Preparing for EL3 exit to normal world
>> INFO:Entry point address = 0x4a00
>> INFO:SPSR = 0x3c9
>>
>> U-Boot SPL 2020.07-rc2-00070-g2fa581ba91 (May 22 2020 - 10:29:30
>+)
>> DRAM: 2048 MiB
>> Trying to boot from MMC1
>> NOTICE: BL31: v2.2():v2.2-1138-g78460ced4
>> NOTICE: BL31: Built : 05:50:47, Apr 7 2020
>> NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689)
>> NOTICE: BL31: Found U-Boot DTB at 0x4091998, model: Pine64 LTS
>> INFO:ARM GICv2 driver initialized
>> INFO:Configuring SPC Controller
>> INFO:PMIC: Probing AXP803 on RSB
>> INFO:PMIC: dcdc1 voltage: 3.300V
>> INFO:PMIC: dcdc5 voltage: 1.200V
>> INFO:PMIC: dcdc6 voltage: 1.100V
>> INFO:PMIC: dldo1 voltage: 3.300V
>> INFO:PMIC: Enabling DC SW
>> INFO:BL31: Platform setup done
>> INFO:BL31: Initializing runtime services
>> INFO:BL31: cortex_a53: CPU workaround for 843419 was applied
>> INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
>> NOTICE: PSCI: System suspend is unavailable
>> INFO:BL31: Preparing for EL3 exit to normal world
>> INFO:Entry point address = 0x4a00
>> INFO:SPSR = 0x3c9
>>
[PATCH u-boot 1/2] eth/r8152: fix assigning the wrong endpoint
Although I think it never occurs, the code doesn't make sense, because
it may allow to assign an IN endpoint to ss->ep_out.
Signed-off-by: Hayes Wang
---
drivers/usb/eth/r8152.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/eth/r8152.c b/drivers/usb/eth/r8152.c
index 61b8683230..7c48663370 100644
--- a/drivers/usb/eth/r8152.c
+++ b/drivers/usb/eth/r8152.c
@@ -1354,9 +1354,8 @@ int r8152_eth_probe(struct usb_device *dev, unsigned int
ifnum,
struct usb_interface *iface;
struct usb_interface_descriptor *iface_desc;
int ep_in_found = 0, ep_out_found = 0;
- int i;
-
struct r8152 *tp;
+ int i;
/* let's examine the device now */
iface = &dev->config.if_desc[ifnum];
@@ -1399,10 +1398,13 @@ int r8152_eth_probe(struct usb_device *dev, unsigned
int ifnum,
if ((iface->ep_desc[i].bmAttributes &
USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_BULK) {
u8 ep_addr = iface->ep_desc[i].bEndpointAddress;
- if ((ep_addr & USB_DIR_IN) && !ep_in_found) {
- ss->ep_in = ep_addr &
- USB_ENDPOINT_NUMBER_MASK;
- ep_in_found = 1;
+
+ if (ep_addr & USB_DIR_IN) {
+ if (!ep_in_found) {
+ ss->ep_in = ep_addr &
+ USB_ENDPOINT_NUMBER_MASK;
+ ep_in_found = 1;
+ }
} else {
if (!ep_out_found) {
ss->ep_out = ep_addr &
--
2.21.1
[PATCH] tools/env/fw_env.h: remove env.h
As reported by Nicolas Carrier on the Buildroot mailing list [1], there is a new build issue while building a program which interacts with the u-boot environment. This program uses the headers of the ubootenv library provided by uboot-tools. This is a recent change from uboot [2] adding "#include " to fw_env.h. Adding env.h require a board configuration to build since it also include compiler.h (and others uboot internal includes). env.h include seems not needed since env_set() is not used in fw_env tool. Nicolas removed env.h from fw_env tool and fixed it's build issue. This problem is present since uboot v2019.10. [1] http://lists.busybox.net/pipermail/buildroot/2020-April/280307.html [2] https://gitlab.denx.de/u-boot/u-boot/-/commit/9fb625ce05539fe6876a59ce1dcadb76b33c6f6e Reported-by: Nicolas Carrier Signed-off-by: Romain Naour --- tools/env/fw_env.h | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/env/fw_env.h b/tools/env/fw_env.h index b60fbfc8f8..78c803c944 100644 --- a/tools/env/fw_env.h +++ b/tools/env/fw_env.h @@ -4,7 +4,6 @@ * Wolfgang Denk, DENX Software Engineering, w...@denx.de. */ -#include #include /* -- 2.25.4
[PATCH u-boot 0/2] eth/r8152: minor corrections
These are minor corrections for r8152 driver. Hayes Wang (2): eth/r8152: fix assigning the wrong endpoint eth/r8152: fix typo in register name drivers/usb/eth/r8152.c | 22 -- drivers/usb/eth/r8152.h | 4 ++-- 2 files changed, 14 insertions(+), 12 deletions(-) -- 2.21.1
rk3399 - Rock Pi 4 PCIe
Hi All,
I have applied Jagan's PCIe patch for Rockchip (
http://lists.infradead.org/pipermail/linux-rockchip/2020-May/031117.html)
to my Rock Pi 4 but I am getting intermittent results with the PCIe bus
(and hence NVMe m.2) showing in u-boot (and then Linux).
When it is successful the pci command shows the pci bus as expected when it
isnt working I get the following:
=> pci
PCIe link training gen1 timeout!
No such bus
=> pci enum
failed to find ep-gpios property
=> fatload mmc 0:4 ${fdt_addr_r} rk3399-rock-pi-4.dtb
54702 bytes read in 21 ms (2.5 MiB/s)
=> fdt addr ${fdt_addr_r}
=> fdt set /pcie@f800 ep-gpios <0xb7 27 0>
=> fdt print /pcie@f800 ep-gpios
ep-gpios = <0x00b7 0x001b 0x>
=> pci
failed to find ep-gpios property
No such bus
=> pci enum
failed to find ep-gpios property
I have 4 of these boards with the same intermittent results on all of them.
It fails more then it succeeds and I have a combination of both booted into
linux on my network at the moment.
When researching the issue I did see some commentary on a timing issue
between training and bus scanning on rockchip and I am not sure if this is
relevant to my problem.
Would appreciate any insights people may have and am very happy to work
with people to troubleshoot the issue.
Cheers,
Tony
RE: [PATCH] mmc: retry CMD1 in mmc_send_op_cond() until the eMMC is ready
> -Original Message-
> From: Peng Fan
> Sent: 2020年5月19日 11:38
> To: BOUGH CHEN ; u-boot@lists.denx.de
> Cc: dl-uboot-imx
> Subject: RE: [PATCH] mmc: retry CMD1 in mmc_send_op_cond() until the
> eMMC is ready
>
> > Subject: [PATCH] mmc: retry CMD1 in mmc_send_op_cond() until the eMMC
> > is ready
> >
> > From: Haibo Chen
> >
> > According to eMMC specification v5.1 section 6.4.3, we should issue
> > CMD1 repeatedly in the idle state until the eMMC is ready even if
> > mmc_send_op_cond() send CMD1 with argument = 0. Otherwise some
> eMMC
> > devices seems to enter the inactive mode after
> > mmc_complete_op_cond() issued CMD0 when the eMMC device is busy. This
> > patch also align with Linux 5.7.
> >
> > Signed-off-by: Haibo Chen
> > ---
> > drivers/mmc/mmc.c | 41 +
> > 1 file changed, 33 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index
> > 523c055967..509549756b 100644
> > --- a/drivers/mmc/mmc.c
> > +++ b/drivers/mmc/mmc.c
> > @@ -664,21 +664,46 @@ static int mmc_send_op_cond_iter(struct mmc
> > *mmc, int use_arg)
> >
> > static int mmc_send_op_cond(struct mmc *mmc) {
> > + struct mmc_cmd cmd;
> > int err, i;
> > + int timeout = 1000;
> > + ulong start;
> >
> > /* Some cards seem to need this */
> > mmc_go_idle(mmc);
> >
> > - /* Asking to the card its capabilities */
> > - for (i = 0; i < 2; i++) {
> > - err = mmc_send_op_cond_iter(mmc, i != 0);
> > + cmd.cmdidx = MMC_CMD_SEND_OP_COND;
> > + cmd.resp_type = MMC_RSP_R3;
> > + cmd.cmdarg = 0;
> > +
> > + start = get_timer(0);
> > + /*
> > +* According to eMMC specification v5.1 section 6.4.3, we
> > +* should issue CMD1 repeatedly in the idle state until
> > +* the eMMC is ready. Otherwise some eMMC devices seem to enter
> > +* the inactive mode after mmc_complete_op_cond() issued CMD0
> > when
> > +* the eMMC device is busy.
> > +*/
>
> Could we just extend the previous for loop to fix the issue?
> Your piece code duplicate much of the code and changed the original behavior.
>
> > + while (1) {
> > + err = mmc_send_cmd(mmc, &cmd, NULL);
> > if (err)
> > return err;
> > -
> > - /* exit if not busy (flag seems to be inverted) */
> > - if (mmc->ocr & OCR_BUSY)
> > - break;
> > + if (mmc_host_is_spi(mmc)) {
> > + if (!(cmd.response[0] & (1 << 0)))
> > + break;
> > + } else {
> > + mmc->ocr = cmd.response[0];
> > + /* exit if not busy (flag seems to be inverted) */
> > + if (mmc->ocr & OCR_BUSY)
> > + break;
> > + }
> > + if (get_timer(start) > timeout)
> > + return -EOPNOTSUPP;
>
> TIMEOUT, please.
>
> > + udelay(100);
>
> This will change the original behavior by adding a delay.
>
> > + if (!mmc_host_is_spi(mmc))
> > + cmd.cmdarg = cmd.response[0] | (1 << 30);
>
> Do we need "1 << 30" ?
>
> > }
> > +
> > mmc->op_cond_pending = 1;
> > return 0;
> > }
> > @@ -691,7 +716,7 @@ static int mmc_complete_op_cond(struct mmc
> > *mmc)
> > int err;
> >
> > mmc->op_cond_pending = 0;
> > - if (!(mmc->ocr & OCR_BUSY)) {
> > + if (mmc->ocr & OCR_BUSY) {
>
> When card not go out busy, it means card not finish power up seq. Why drop !?
>
> > /* Some cards seem to need this */
> > mmc_go_idle(mmc);
> >
> > --
>
> Would the following patch help?
>
Hi Peng,
Thanks for your carefully review and suggestion, most eMMC chip can work normal
on the original code, only some Toshiba eMMC need more time to get out of busy
after cmd1.
The patch I send out just refer to the Linux driver code, and pass on the
customer side.
Currently I'm not sure whether the bit 30 of the argument for cmd1 is necessary
for this eMMC, I will get the reworked board which soldered this Toshiba eMMC
in a few days, then I can test on my hand.
Will test this then and give you response.
Best Regards
Haibo Chen
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index
> 523c055967..d3a0538cdb 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -665,12 +665,15 @@ static int mmc_send_op_cond_iter(struct mmc
> *mmc, int use_arg) static int mmc_send_op_cond(struct mmc *mmc) {
> int err, i;
> + int timeout = 1000;
> + ulong start;
>
> /* Some cards seem to need this */
> mmc_go_idle(mmc);
>
> + start = get_timer(0);
> /* Asking to the card its capabilities */
> - for (i = 0; i < 2; i++) {
> + for (i = 0; ; i++) {
> err = mmc_send_op_cond_iter(mmc, i != 0);
> if (err)
> return err;
> @@ -678,6 +681,9 @@ static int mmc_send_op_cond(struct mmc *mmc)
>
[PATCH u-boot 2/2] eth/r8152: fix typo in register name
The PAL_BDC_CR should be PLA_BDC_CR. Signed-off-by: Hayes Wang --- drivers/usb/eth/r8152.c | 8 drivers/usb/eth/r8152.h | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/usb/eth/r8152.c b/drivers/usb/eth/r8152.c index 7c48663370..f201a1789b 100644 --- a/drivers/usb/eth/r8152.c +++ b/drivers/usb/eth/r8152.c @@ -711,9 +711,9 @@ static void r8152b_enter_oob(struct r8152 *tp) rtl_rx_vlan_en(tp, false); - ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PAL_BDC_CR); + ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_BDC_CR); ocp_data |= ALDPS_PROXY_MODE; - ocp_write_word(tp, MCU_TYPE_PLA, PAL_BDC_CR, ocp_data); + ocp_write_word(tp, MCU_TYPE_PLA, PLA_BDC_CR, ocp_data); ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL); ocp_data |= NOW_IS_OOB | DIS_MCU_CLROOB; @@ -844,9 +844,9 @@ static void r8153_enter_oob(struct r8152 *tp) rtl_rx_vlan_en(tp, false); - ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PAL_BDC_CR); + ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_BDC_CR); ocp_data |= ALDPS_PROXY_MODE; - ocp_write_word(tp, MCU_TYPE_PLA, PAL_BDC_CR, ocp_data); + ocp_write_word(tp, MCU_TYPE_PLA, PLA_BDC_CR, ocp_data); ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL); ocp_data |= NOW_IS_OOB | DIS_MCU_CLROOB; diff --git a/drivers/usb/eth/r8152.h b/drivers/usb/eth/r8152.h index 09f1c6178b..c7f62b8b3e 100644 --- a/drivers/usb/eth/r8152.h +++ b/drivers/usb/eth/r8152.h @@ -22,7 +22,7 @@ #define PLA_TEREDO_CFG 0xc0bc #define PLA_MAR0xcd00 #define PLA_BACKUP 0xd000 -#define PAL_BDC_CR 0xd1a0 +#define PLA_BDC_CR 0xd1a0 #define PLA_TEREDO_TIMER 0xd2cc #define PLA_REALWOW_TIMER 0xd2e8 #define PLA_LEDSEL 0xdd90 @@ -225,7 +225,7 @@ #define TEREDO_RS_EVENT_MASK 0x00fe #define OOB_TEREDO_EN 0x0001 -/* PAL_BDC_CR */ +/* PLA_BDC_CR */ #define ALDPS_PROXY_MODE 0x0001 /* PLA_CONFIG34 */ -- 2.21.1
[PATCH 1/4] cmd: unzip: automatically select CONFIG_GZIP
unzip calls gzwrite() which is provided in lib/gunzip.c. Make sure it is automatically pulled in if the user selects CMD_UNZIP. Signed-off-by: Michael Walle --- cmd/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/cmd/Kconfig b/cmd/Kconfig index f9be1988f6..f4eb575b6e 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -810,6 +810,7 @@ config CMD_UNLZ4 config CMD_UNZIP bool "unzip" default y if CMD_BOOTI + select GZIP help Uncompress a zip-compressed memory region. -- 2.20.1
[PATCH 0/4] cmd: {zip, unzip} fixes
Automatically pull in the needed libraries for zip and unzip. Move the CONFIG_GZIP_COMPRESSED from legacy config.h style to a Kconfig option. The sole user of CONFIG_GZIP_COMPRESSED is the sandbox target for the compression tests. Remove the CONFIG option in its config.h and instead select it together with CONFIG_SANDBOX. Michael Walle (4): cmd: unzip: automatically select CONFIG_GZIP cmd: zip: automatically pull in gzip() cmd: zip: fix implicit declaration warning sandbox: move compression option to Kconfig arch/Kconfig | 2 ++ cmd/Kconfig | 2 ++ cmd/zip.c| 1 + include/configs/sandbox.h| 3 --- lib/Kconfig | 4 scripts/config_whitelist.txt | 2 -- 6 files changed, 9 insertions(+), 5 deletions(-) -- 2.20.1
[PATCH 3/4] cmd: zip: fix implicit declaration warning
Fix the following warning:
cmd/zip.c: In function ‘do_zip’:
cmd/zip.c:30:6: warning: implicit declaration of function ‘gzip’; did you mean
‘do_zip’? [-Wimplicit-function-declaration]
if (gzip((void *) dst, &dst_len, (void *) src, src_len) != 0)
^~~~
do_zip
Include gzip.h header which declares the gzip() function.
Signed-off-by: Michael Walle
---
cmd/zip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/cmd/zip.c b/cmd/zip.c
index b433f1889f..8ad3768464 100644
--- a/cmd/zip.c
+++ b/cmd/zip.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
static int do_zip(struct cmd_tbl *cmdtp, int flag, int argc, char *const
argv[])
{
--
2.20.1
[PATCH 2/4] cmd: zip: automatically pull in gzip()
Move the CONFIG_GZIP_COMPRESSED from a config.h macro to a Kconfig menu item. It is not selectable by a user because there is no reason to do so. Instead it will be automatically selected by the stuff which uses gzip(), like the zip command. Remove it from the config_whitelist.txt. Also remove CONFIG_GZIP_COMPRESS_DEF_SZ as this was never used on any board. The default seems to be sane, otherwise it should be added as a Kconfig option. Signed-off-by: Michael Walle --- cmd/Kconfig | 1 + lib/Kconfig | 4 scripts/config_whitelist.txt | 2 -- 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index f4eb575b6e..153864c587 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -816,6 +816,7 @@ config CMD_UNZIP config CMD_ZIP bool "zip" + select GZIP_COMPRESSED help Compress a memory region with zlib deflate method. diff --git a/lib/Kconfig b/lib/Kconfig index c3f694afc0..f18bf3778b 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -424,6 +424,10 @@ config GZIP help This enables support for GZIP compression algorithm. +config GZIP_COMPRESSED + bool + select ZLIB + config BZIP2 bool "Enable bzip2 decompression support" help diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index 3f5e6504e1..2ec0758b75 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -644,8 +644,6 @@ CONFIG_GPIO_LED_STUBS CONFIG_GREEN_LED CONFIG_GURNARD_FPGA CONFIG_GURNARD_SPLASH -CONFIG_GZIP_COMPRESSED -CONFIG_GZIP_COMPRESS_DEF_SZ CONFIG_G_DNL_THOR_PRODUCT_NUM CONFIG_G_DNL_THOR_VENDOR_NUM CONFIG_G_DNL_UMS_PRODUCT_NUM -- 2.20.1
[PATCH 4/4] sandbox: move compression option to Kconfig
CONFIG_BZIP2 and CONFIG_GZIP_COMPRESSED are Kconfig options. Select them by CONFIG_SANDBOX instead of setting them in configs/sandbox.h. Signed-off-by: Michael Walle --- arch/Kconfig | 2 ++ include/configs/sandbox.h | 3 --- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/Kconfig b/arch/Kconfig index 91e049b322..a11f872938 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -86,6 +86,7 @@ config RISCV config SANDBOX bool "Sandbox" select BOARD_LATE_INIT + select BZIP2 select DM select DM_GPIO select DM_I2C @@ -94,6 +95,7 @@ config SANDBOX select DM_SERIAL select DM_SPI select DM_SPI_FLASH + select GZIP_COMPRESSED select HAVE_BLOCK_DEVICE select LZO select OF_BOARD_SETUP diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h index 4549c81169..a2c9811eca 100644 --- a/include/configs/sandbox.h +++ b/include/configs/sandbox.h @@ -114,9 +114,6 @@ BOOTENV \ MEM_LAYOUT_ENV_SETTINGS -#define CONFIG_GZIP_COMPRESSED -#define CONFIG_BZIP2 - #ifndef CONFIG_SPL_BUILD #define CONFIG_SYS_IDE_MAXBUS 1 #define CONFIG_SYS_ATA_IDE0_OFFSET 0 -- 2.20.1
Re: [GIT PULL] Pull request: u-boot-imx u-boot-imx-20200511
On Mon, 11 May 2020 12:04:32 -0400 Tom Rini tr...@konsulko.com wrote: > On Mon, May 11, 2020 at 12:29:37PM +0200, Stefano Babic wrote: > > > Hi Tom, > > > > please pull these i.MX's changes for 2020.07, thanks ! > > > > The following changes since commit c5c657644bc35fd6b3d6e5517698721e90646b8d: > > > > Merge branch '2020-05-08-assorted-fixes' (2020-05-08 18:58:19 -0400) > > > > are available in the Git repository at: > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git > > tags/u-boot-imx-20200511 > > > > for you to fetch changes up to d52a03b130565e6b01dcbe656ebeb611d5ee1aa1: > > > > imx8: cpu: check resource owned after sid fail (2020-05-10 20:55:21 +0200) > > > > Applied to u-boot/master, thanks! All i.MX8QXP boards in mainline are not booting after this merge. Could you please apply below patches to fix this: http://patchwork.ozlabs.org/project/uboot/patch/20200516203420.24409-1-ag...@denx.de http://patchwork.ozlabs.org/project/uboot/patch/20200519233144.2426-1-ag...@denx.de http://patchwork.ozlabs.org/project/uboot/patch/20200520082153.20765-1-ag...@denx.de Or alternatively just pull these using below tag in my repo: The following changes since commit 2fa581ba910368d0f7f995fb906d6c5e4218b594: Merge git://git.denx.de/u-boot-sh (2020-05-21 08:26:40 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-video.git tags/imx8qxp-fixes for you to fetch changes up to 4e7413a998ba5666aa4ee0b4f49789f52b1281b1: thermal: imx_scu_thermal: prevent boot hang with zero pdata (2020-05-22 13:29:25 +0200) - Fix i.MX8QXP boot hang when getting CPU temperature Anatolij Gustschin (3): cpu: imx8: fix type and rate detection cpu: imx8: use intended cpu-thermal device when getting temp value thermal: imx_scu_thermal: prevent boot hang with zero pdata drivers/cpu/imx8_cpu.c| 50 +- drivers/thermal/imx_scu_thermal.c | 4 +++- 2 files changed, 28 insertions(+), 26 deletions(-) gitlab CI: https://gitlab.denx.de/u-boot/custodians/u-boot-video/pipelines/3357 -- Anatolij
Re: [U-Boot] How to enable USB Mass Storage
Hi list, > I want to use the ums command to access the SD card of a > A20-OlinuxIno-Lime > board via usb-org cable. For that I start the CPU in FEL mode, download > the > u-boot-sunxi-with-spl.bin file by sunxi-fel tool. I do this FEL mode boot > for > preparation of an Einstein A20 board, which has only an internal MMC. I > run on > uboot serial console: > > => ums 0 mmc 0 > UMS: LUN 0, dev 0, hwpart 0, sector 0x0, count 0x1dc000 > Controller uninitialized > g_dnl_register: failed!, error: -6 > g_dnl_register failed > Sorry to jump in such an old thread, but as this is still an issue in current master (~ 2020.07-rc2) I don't think it hurts. This error is typically encountered with Allwinner SOCs when: CONFIG_CMD_USB_MASS_STORAGE=y but CONFIG_USB_ETHER is not set. Enabling CONFIG_USB_ETHER=y workarounded the issue for me, as reported also elsewhere: http://patchwork.ozlabs.org/project/uboot/patch/caexmxltm9bhx7aaub+mazgbdw2ccsoo3ne6ep7dbm8mmrya...@mail.gmail.com/#1976362 http://linux-sunxi.org/U-Boot/USB_Mass_Storage#Prerequisites Regards, Diego Rondini
Re: Issue with 'ubi part' ubi_io_read: error -74 (ECC error)
Hi Heiko, Thanks for your response. On 5/22/20, Heiko Schocher wrote: >> Are there any ways or tools in Linux to change MTD settings (most >> likely the ECC or DTB) to the same setting in u-boot? I do have mtd >> and fw_setenv in Linux. > > No for U-Boot (as I am aware of). You need to fix the DTS or may if > older U-Boot your code. > > May you need to add in your U-Boot DTS gpmi node the property: > > fsl,legacy-bch-geometry; I tried but that did not work, it is equivalent to remove fsl,use-minimum-ecc in gpmi node I used to run ubiformat to flash UBIFS image to NAND: # flash_erase /dev/mtd2 0 0 # ubiformat /dev/mtd2 -f /tmp/ubi.img That caused the NAND boot error to run "ubi part" ubi_io_read: error -74 (ECC error). Richard shed light on the problem that u-boot and Linux use different MTD settings, I figured out it is the ECC problem, while adding fsl,use-minimum-ecc in gpmi node cannot even start NAND boot. Why fsl,use-minimum-ecc in gpmi node causing such predicament? Thank you. Kind regards, - jh
Re: [PATCH v2] drivers: crypto: mod_exp_sw: Re-add DM_FLAG_PRE_RELOC
On 22.05.20 13:38, Heinrich Schuchardt wrote:
> Am May 22, 2020 10:50:29 AM UTC schrieb Jan Kiszka :
>> On 22.05.20 12:42, Heinrich Schuchardt wrote:
>>> On 5/20/20 2:22 PM, Tom Rini wrote:
On Thu, May 07, 2020 at 08:36:03PM +0200, Jan Kiszka wrote:
> From: Jan Kiszka
>
> This driver is safe to use in SPL without relocation. Denying
> DM_FLAG_PRE_RELOC prevents its usability for verifying the main
>> U-Boot
> or other artifacts from the SPL unless needless enabling the full
>> driver
> set (SPL_OF_PLATDATA).
>
> Fixes: 17e117408571 ("drivers: crypto: rsa_mod_exp: avoid
>> DM_FLAG_PRE_RELOC")
> CC: Heinrich Schuchardt
> CC: Marek Vasut
> Signed-off-by: Jan Kiszka
Applied to u-boot/master, thanks!
>>>
>>> With this patch applied pine64-lts_defconfig with CONFIG_RSA=y does
>> not
>>> boot anymore. See the output below. So something is wrong with this
>> driver.
>>>
>>> Do you have an idea how to analyze what is wrong? Unfortunately there
>> is
>>> no DEBUG_UART available on the Pine A64 LTS board.
>>
>> I would start crippling it down until things start to boot again. Are
>> you using it (for image verification e.g.), or is this just the
>> registration that breaks already?
>>
>
>
> RSA is needed in the UEFI subsystem for verifying variables and images. But
> there is no need in SPL for it at all.
>
> In my configuration RSA is not used at all. Something breaks before even the
> console becomes available.
>
> The pine64-lts_defconfig board boots via SPL->BL31->U-Boot
But then a workaround for you would be to turn this driver off in SPL.
UEFI is main U-Boot only, isn't it?
That said, understanding the reason for the breakage would still be nice
for the case someone needs to validate what SPL loads with the help of
RSA (which is the case for us on an AM65x board).
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
Re: rk3399 - Rock Pi 4 PCIe
> From: Anthony Davies
> Date: Fri, 22 May 2020 10:49:12 +1000
>
> Hi All,
>
> I have applied Jagan's PCIe patch for Rockchip (
> http://lists.infradead.org/pipermail/linux-rockchip/2020-May/031117.html)
> to my Rock Pi 4 but I am getting intermittent results with the PCIe bus
> (and hence NVMe m.2) showing in u-boot (and then Linux).
>
> When it is successful the pci command shows the pci bus as expected when it
> isnt working I get the following:
> => pci
> PCIe link training gen1 timeout!
> No such bus
> => pci enum
> failed to find ep-gpios property
> => fatload mmc 0:4 ${fdt_addr_r} rk3399-rock-pi-4.dtb
> 54702 bytes read in 21 ms (2.5 MiB/s)
> => fdt addr ${fdt_addr_r}
> => fdt set /pcie@f800 ep-gpios <0xb7 27 0>
> => fdt print /pcie@f800 ep-gpios
> ep-gpios = <0x00b7 0x001b 0x>
> => pci
> failed to find ep-gpios property
> No such bus
> => pci enum
> failed to find ep-gpios property
>
> I have 4 of these boards with the same intermittent results on all of them.
> It fails more then it succeeds and I have a combination of both booted into
> linux on my network at the moment.
>
> When researching the issue I did see some commentary on a timing issue
> between training and bus scanning on rockchip and I am not sure if this is
> relevant to my problem.
>
> Would appreciate any insights people may have and am very happy to work
> with people to troubleshoot the issue.
Might be worth trying:
https://patchwork.ozlabs.org/project/uboot/patch/20200427090947.75951-1-kette...@openbsd.org/
[PATCH v4 02/20] spi: spi-mem: allow specifying a command's extension
In xSPI mode, flashes expect 2-byte opcodes. The second byte is called
the "command extension". There can be 3 types of extensions in xSPI:
repeat, invert, and hex. When the extension type is "repeat", the same
opcode is sent twice. When it is "invert", the second byte is the
inverse of the opcode. When it is "hex" an additional opcode byte based
is sent with the command whose value can be anything.
So, make opcode a 16-bit value and add a 'nbytes', similar to how
multiple address widths are handled.
Signed-off-by: Pratyush Yadav
---
drivers/spi/spi-mem.c | 3 +++
include/spi-mem.h | 6 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 967c241853..fd98faae2b 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -162,6 +162,9 @@ bool spi_mem_default_supports_op(struct spi_slave *slave,
if (op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr)
return false;
+ if (op->cmd.nbytes != 1)
+ return false;
+
return true;
}
EXPORT_SYMBOL_GPL(spi_mem_default_supports_op);
diff --git a/include/spi-mem.h b/include/spi-mem.h
index 55e5019a1c..9167c435f6 100644
--- a/include/spi-mem.h
+++ b/include/spi-mem.h
@@ -20,6 +20,7 @@
{ \
.buswidth = __buswidth, \
.opcode = __opcode, \
+ .nbytes = 1,\
}
#define SPI_MEM_OP_ADDR(__nbytes, __val, __buswidth) \
@@ -72,6 +73,8 @@ enum spi_mem_data_dir {
/**
* struct spi_mem_op - describes a SPI memory operation
+ * @cmd.nbytes: number of opcode bytes (only 1 or 2 are valid). The opcode is
+ * sent MSB-first.
* @cmd.buswidth: number of IO lines used to transmit the command
* @cmd.opcode: operation opcode
* @cmd.dtr: whether the command opcode should be sent in DTR mode or not
@@ -95,9 +98,10 @@ enum spi_mem_data_dir {
*/
struct spi_mem_op {
struct {
+ u8 nbytes;
u8 buswidth;
- u8 opcode;
u8 dtr : 1;
+ u16 opcode;
} cmd;
struct {
--
2.26.2
[PATCH v4 03/20] spi: cadence-qspi: Do not calibrate when device tree sets read delay
If the device tree provides a read delay value, use that directly and do
not perform the calibration procedure.
This allows the device tree to over-ride the read delay value in cases
where the read delay value obtained via calibration is incorrect. One
such example is the Cypress Semper flash. It needs a read delay of 4 in
octal DTR mode. But since the calibration procedure is run before the
flash is switched in octal DTR mode, it yields a read delay of 2. A
value of 4 works for both octal DTR and legacy modes.
Signed-off-by: Pratyush Yadav
---
drivers/spi/cadence_qspi.c | 26 +-
drivers/spi/cadence_qspi.h | 1 +
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 1e85749209..305f2ec0df 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -141,12 +141,20 @@ static int cadence_spi_set_speed(struct udevice *bus,
uint hz)
cadence_qspi_apb_controller_disable(priv->regbase);
/*
-* Calibration required for different current SCLK speed, requested
-* SCLK speed or chip select
+* If the device tree already provides a read delay value, use that
+* instead of calibrating.
*/
- if (priv->previous_hz != hz ||
- priv->qspi_calibrated_hz != hz ||
- priv->qspi_calibrated_cs != spi_chip_select(bus)) {
+ if (plat->read_delay >= 0) {
+ cadence_spi_write_speed(bus, hz);
+ cadence_qspi_apb_readdata_capture(priv->regbase, 1,
+ plat->read_delay);
+ } else if (priv->previous_hz != hz ||
+ priv->qspi_calibrated_hz != hz ||
+ priv->qspi_calibrated_cs != spi_chip_select(bus)) {
+ /*
+* Calibration required for different current SCLK speed,
+* requested SCLK speed or chip select
+*/
err = spi_calibration(bus, hz);
if (err)
return err;
@@ -320,6 +328,14 @@ static int cadence_spi_ofdata_to_platdata(struct udevice
*bus)
255);
plat->tchsh_ns = ofnode_read_u32_default(subnode, "cdns,tchsh-ns", 20);
plat->tslch_ns = ofnode_read_u32_default(subnode, "cdns,tslch-ns", 20);
+ /*
+* Read delay should be an unsigned value but we use a signed integer
+* so that negative values can indicate that the device tree did not
+* specify any signed values and we need to perform the calibration
+* sequence to find it out.
+*/
+ plat->read_delay = ofnode_read_s32_default(subnode, "cdns,read-delay",
+ -1);
debug("%s: regbase=%p ahbbase=%p max-frequency=%d page-size=%d\n",
__func__, plat->regbase, plat->ahbbase, plat->max_hz,
diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index ae459c74a1..9dff2fdced 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h
@@ -26,6 +26,7 @@ struct cadence_spi_platdata {
u32 trigger_address;
fdt_addr_t ahbsize;
booluse_dac_mode;
+ int read_delay;
/* Flash parameters */
u32 page_size;
--
2.26.2
[PATCH v4 04/20] spi: cadence-qspi: Add support for octal DTR flashes
Set up opcode extension and enable/disable DTR mode based on whether the
command is DTR or not.
xSPI flashes can have a 4-byte dummy address associated with some
commands like the Read Status Register command in octal DTR mode. Since
the flash does not support sending the dummy address, we can not use
automatic write completion polling in DTR mode. Further, no write
completion polling makes it impossible to use DAC mode for DTR writes.
In that mode, the controller does not know beforehand how long a write
will be and so it can de-assert Chip Select (CS#) at any time. Once CS#
is de-assert, the flash will go into burning phase. But since the
controller does not do write completion polling, it does not know when
the flash is busy and might send in writes while the flash is not ready.
So, disable write completion polling and make writes go through indirect
mode for DTR writes and let spi-mem take care of polling the SR.
Signed-off-by: Pratyush Yadav
---
drivers/spi/cadence_qspi.c | 61 ++-
drivers/spi/cadence_qspi.h | 14 +-
drivers/spi/cadence_qspi_apb.c | 286 ++---
include/spi-mem.h | 3 +
4 files changed, 338 insertions(+), 26 deletions(-)
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 305f2ec0df..b0f9165bff 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -41,20 +41,22 @@ static int cadence_spi_write_speed(struct udevice *bus,
uint hz)
return 0;
}
-static int cadence_spi_read_id(void *reg_base, u8 len, u8 *idcode)
+static int cadence_spi_read_id(struct cadence_spi_platdata *plat, u8 len,
+ u8 *idcode)
{
struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(0x9F, 1),
SPI_MEM_OP_NO_ADDR,
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_DATA_IN(len, idcode, 1));
- return cadence_qspi_apb_command_read(reg_base, &op);
+ return cadence_qspi_apb_command_read(plat, &op);
}
/* Calibration sequence to determine the read data capture delay register */
static int spi_calibration(struct udevice *bus, uint hz)
{
struct cadence_spi_priv *priv = dev_get_priv(bus);
+ struct cadence_spi_platdata *plat = bus->platdata;
void *base = priv->regbase;
unsigned int idcode = 0, temp = 0;
int err = 0, i, range_lo = -1, range_hi = -1;
@@ -69,7 +71,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
cadence_qspi_apb_controller_enable(base);
/* read the ID which will be our golden value */
- err = cadence_spi_read_id(base, 3, (u8 *)&idcode);
+ err = cadence_spi_read_id(plat, 3, (u8 *)&idcode);
if (err) {
puts("SF: Calibration failed (read)\n");
return err;
@@ -88,7 +90,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
cadence_qspi_apb_controller_enable(base);
/* issue a RDID to get the ID value */
- err = cadence_spi_read_id(base, 3, (u8 *)&temp);
+ err = cadence_spi_read_id(plat, 3, (u8 *)&temp);
if (err) {
puts("SF: Calibration failed (read)\n");
return err;
@@ -267,10 +269,14 @@ static int cadence_spi_mem_exec_op(struct spi_slave *spi,
switch (mode) {
case CQSPI_STIG_READ:
- err = cadence_qspi_apb_command_read(base, op);
+ err = cadence_qspi_apb_command_read_setup(plat, op);
+ if (!err)
+ err = cadence_qspi_apb_command_read(plat, op);
break;
case CQSPI_STIG_WRITE:
- err = cadence_qspi_apb_command_write(base, op);
+ err = cadence_qspi_apb_command_write_setup(plat, op);
+ if (!err)
+ err = cadence_qspi_apb_command_write(plat, op);
break;
case CQSPI_READ:
err = cadence_qspi_apb_read_setup(plat, op);
@@ -290,6 +296,48 @@ static int cadence_spi_mem_exec_op(struct spi_slave *spi,
return err;
}
+static bool cadence_spi_mem_supports_op(struct spi_slave *slave,
+ const struct spi_mem_op *op)
+{
+ bool all_true, all_false;
+ u8 buswidths[4];
+ int i;
+
+ all_true = op->cmd.dtr && op->addr.dtr && op->dummy.dtr &&
+ op->data.dtr;
+ all_false = !op->cmd.dtr && !op->addr.dtr && !op->dummy.dtr &&
+ !op->data.dtr;
+
+ /* Mixed DTR modes not supported. */
+ if (!(all_true || all_false))
+ return false;
+
+ /*
+* Only buswidths of 1, 2, 4, and 8 are supported. 0 is allowed in case
+* that phase does not exist.
+*/
+ buswidths[0] = op->cmd.buswidth;
+ buswidths[1] = op->addr.buswidth;
+ buswidths[2] = op->dummy.buswidth;
[PATCH v4 00/20] mtd: spi-nor-core: add xSPI Octal DTR support
Hi, This series adds support for octal DTR flashes in the spi-nor framework, and then adds hooks for the Cypress Semper flash which is an xSPI compliant Octal DTR flash. The Cadence QSPI controller driver is also updated to run in Octal DTR mode. Tested on TI J721e EVM. Changes in v4: - Fix BFPT parsing stopping too early for JESD216 rev B flashes. - Instead of just checking for spi_nor_get_protocol_width() in spi_nor_octal_dtr_enable(), make sure the protocol is SNOR_PROTO_8_8_8_DTR since get_protocol_width() only cares about data width. - Do not enable stateful X-X-X modes if the reset line is broken. - Instead of setting SNOR_READ_HWCAPS_8_8_8_DTR from Profile 1.0 table parsing, do it in spi_nor_info_init_params() instead based on the SPI_NOR_OCTAL_DTR_READ flag instead. - Set SNOR_HWCAPS_PP_8_8_8_DTR in s28hs post_sfdp hook since this capability is no longer set in Profile 1.0 parsing. - Rename spi_nor_cypress_octal_enable() to spi_nor_cypress_octal_dtr_enable(). - Instead of hard-coding 8D-8D-8D Fast Read dummy cycles to 20, find them out from the Profile 1.0 table. - Call post-bfpt fixup when exiting early because of JESD rev A. - Do not make an invalid Quad Enable BFPT field a fatal error. Silently ignore it by assuming no quad enable bit is present. - Set cmd.nbytes to 1 when using SPI_MEM_OP_CMD(). - Reject ops with more than 1 command byte in spi_mem_default_supports_op(). - Drop flag SPI_NOR_SOFT_RESET. Instead, discover soft reset capability via BFPT. - Add missing headers that were removed from common header. Changes in v3: - Read 2 bytes in Octal DTR mode when reading SR and FSR to avoid tripping up controllers. - Use op->data.nbytes as a measure of whether the data phase exists or not. This fixes data buswidth not being updadted for SR and FSR reads because they keep data buffer as NULL when calling spi_nor_setup_op(). - Add support for Micron mt35xu512aba to run in Octal DTR mode. Pratyush Yadav (20): spi: spi-mem: allow specifying whether an op is DTR or not spi: spi-mem: allow specifying a command's extension spi: cadence-qspi: Do not calibrate when device tree sets read delay spi: cadence-qspi: Add support for octal DTR flashes mtd: spi-nor-core: Add a ->setup() hook mtd: spi-nor-core: Move SFDP related declarations to top mtd: spi-nor-core: Introduce flash-specific fixup hooks mtd: spi-nor-core: Rework hwcaps selection mtd: spi-nor-core: Add support for DTR protocol mtd: spi-nor-core: prepare BFPT parsing for JESD216 rev D mtd: spi-nor-core: Get command opcode extension type from BFPT mtd: spi-nor-core: Parse xSPI Profile 1.0 table mtd: spi-nor-core: Prepare Read SR and FSR for Octal DTR mode mtd: spi-nor-core: Enable octal DTR mode when possible mtd: spi-nor-core: Do not make invalid quad enable fatal mtd: spi-nor-core: Detect Soft Reset sequence support from BFPT mtd: spi-nor-core: Perform a Soft Reset on shutdown mtd: spi-nor-core: Perform a Soft Reset on boot mtd: spi-nor-core: Add support for Cypress Semper flash mtd: spi-nor-core: Allow using Micron mt35xu512aba in Octal DTR mode drivers/mtd/spi/Kconfig| 11 + drivers/mtd/spi/sf_internal.h | 12 + drivers/mtd/spi/sf_probe.c |9 + drivers/mtd/spi/spi-nor-core.c | 1253 ++-- drivers/mtd/spi/spi-nor-ids.c |4 +- drivers/mtd/spi/spi-nor-tiny.c | 22 - drivers/spi/cadence_qspi.c | 87 ++- drivers/spi/cadence_qspi.h | 15 +- drivers/spi/cadence_qspi_apb.c | 286 +++- drivers/spi/spi-mem.c |6 + include/linux/mtd/spi-nor.h| 275 +-- include/spi-mem.h | 17 +- 12 files changed, 1639 insertions(+), 358 deletions(-) -- 2.26.2
[PATCH v4 01/20] spi: spi-mem: allow specifying whether an op is DTR or not
Each phase is given a separate 'dtr' field so mixed protocols like
4S-4D-4D can be supported.
Signed-off-by: Pratyush Yadav
---
drivers/spi/spi-mem.c | 3 +++
include/spi-mem.h | 8
2 files changed, 11 insertions(+)
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index d344701aeb..967c241853 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -159,6 +159,9 @@ bool spi_mem_default_supports_op(struct spi_slave *slave,
op->data.dir == SPI_MEM_DATA_OUT))
return false;
+ if (op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr)
+ return false;
+
return true;
}
EXPORT_SYMBOL_GPL(spi_mem_default_supports_op);
diff --git a/include/spi-mem.h b/include/spi-mem.h
index 893f7bd733..55e5019a1c 100644
--- a/include/spi-mem.h
+++ b/include/spi-mem.h
@@ -74,6 +74,7 @@ enum spi_mem_data_dir {
* struct spi_mem_op - describes a SPI memory operation
* @cmd.buswidth: number of IO lines used to transmit the command
* @cmd.opcode: operation opcode
+ * @cmd.dtr: whether the command opcode should be sent in DTR mode or not
* @addr.nbytes: number of address bytes to send. Can be zero if the operation
* does not need to send an address
* @addr.buswidth: number of IO lines used to transmit the address cycles
@@ -81,10 +82,13 @@ enum spi_mem_data_dir {
* Note that only @addr.nbytes are taken into account in this
* address value, so users should make sure the value fits in the
* assigned number of bytes.
+ * @addr.dtr: whether the address should be sent in DTR mode or not
* @dummy.nbytes: number of dummy bytes to send after an opcode or address. Can
* be zero if the operation does not require dummy bytes
* @dummy.buswidth: number of IO lanes used to transmit the dummy bytes
+ * @dummy.dtr: whether the dummy bytes should be sent in DTR mode or not
* @data.buswidth: number of IO lanes used to send/receive the data
+ * @data.dtr: whether the data should be sent in DTR mode or not
* @data.dir: direction of the transfer
* @data.buf.in: input buffer
* @data.buf.out: output buffer
@@ -93,21 +97,25 @@ struct spi_mem_op {
struct {
u8 buswidth;
u8 opcode;
+ u8 dtr : 1;
} cmd;
struct {
u8 nbytes;
u8 buswidth;
+ u8 dtr : 1;
u64 val;
} addr;
struct {
u8 nbytes;
u8 buswidth;
+ u8 dtr : 1;
} dummy;
struct {
u8 buswidth;
+ u8 dtr : 1;
enum spi_mem_data_dir dir;
unsigned int nbytes;
/* buf.{in,out} must be DMA-able. */
--
2.26.2
[PATCH v4 05/20] mtd: spi-nor-core: Add a ->setup() hook
nor->setup() can be used by flashes to configure settings in case they
have any peculiarities that can't be easily expressed by the generic
spi-nor framework. This includes things like different opcodes, dummy
cycles, page size, uniform/non-uniform sector sizes, etc.
Move related declarations to avoid forward declarations.
Inspired by the Linux kernel's setup() hook.
Signed-off-by: Pratyush Yadav
---
drivers/mtd/spi/spi-nor-core.c | 84 +++
drivers/mtd/spi/spi-nor-tiny.c | 22
include/linux/mtd/spi-nor.h| 192 ++---
3 files changed, 147 insertions(+), 151 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 56b44ebbe8..6e5d6e87d7 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -1441,71 +1441,6 @@ static int spansion_no_read_cr_quad_enable(struct
spi_nor *nor)
#endif /* CONFIG_SPI_FLASH_SFDP_SUPPORT */
#endif /* CONFIG_SPI_FLASH_SPANSION */
-struct spi_nor_read_command {
- u8 num_mode_clocks;
- u8 num_wait_states;
- u8 opcode;
- enum spi_nor_protocol proto;
-};
-
-struct spi_nor_pp_command {
- u8 opcode;
- enum spi_nor_protocol proto;
-};
-
-enum spi_nor_read_command_index {
- SNOR_CMD_READ,
- SNOR_CMD_READ_FAST,
- SNOR_CMD_READ_1_1_1_DTR,
-
- /* Dual SPI */
- SNOR_CMD_READ_1_1_2,
- SNOR_CMD_READ_1_2_2,
- SNOR_CMD_READ_2_2_2,
- SNOR_CMD_READ_1_2_2_DTR,
-
- /* Quad SPI */
- SNOR_CMD_READ_1_1_4,
- SNOR_CMD_READ_1_4_4,
- SNOR_CMD_READ_4_4_4,
- SNOR_CMD_READ_1_4_4_DTR,
-
- /* Octo SPI */
- SNOR_CMD_READ_1_1_8,
- SNOR_CMD_READ_1_8_8,
- SNOR_CMD_READ_8_8_8,
- SNOR_CMD_READ_1_8_8_DTR,
-
- SNOR_CMD_READ_MAX
-};
-
-enum spi_nor_pp_command_index {
- SNOR_CMD_PP,
-
- /* Quad SPI */
- SNOR_CMD_PP_1_1_4,
- SNOR_CMD_PP_1_4_4,
- SNOR_CMD_PP_4_4_4,
-
- /* Octo SPI */
- SNOR_CMD_PP_1_1_8,
- SNOR_CMD_PP_1_8_8,
- SNOR_CMD_PP_8_8_8,
-
- SNOR_CMD_PP_MAX
-};
-
-struct spi_nor_flash_parameter {
- u64 size;
- u32 page_size;
-
- struct spi_nor_hwcaps hwcaps;
- struct spi_nor_read_command reads[SNOR_CMD_READ_MAX];
- struct spi_nor_pp_command page_programs[SNOR_CMD_PP_MAX];
-
- int (*quad_enable)(struct spi_nor *nor);
-};
-
static void
spi_nor_set_read_settings(struct spi_nor_read_command *read,
u8 num_mode_clocks,
@@ -2366,9 +2301,10 @@ static int spi_nor_select_erase(struct spi_nor *nor,
return 0;
}
-static int spi_nor_setup(struct spi_nor *nor, const struct flash_info *info,
-const struct spi_nor_flash_parameter *params,
-const struct spi_nor_hwcaps *hwcaps)
+static int spi_nor_default_setup(struct spi_nor *nor,
+const struct flash_info *info,
+const struct spi_nor_flash_parameter *params,
+const struct spi_nor_hwcaps *hwcaps)
{
u32 ignored_mask, shared_mask;
bool enable_quad_io;
@@ -2427,6 +2363,16 @@ static int spi_nor_setup(struct spi_nor *nor, const
struct flash_info *info,
return 0;
}
+static int spi_nor_setup(struct spi_nor *nor, const struct flash_info *info,
+const struct spi_nor_flash_parameter *params,
+const struct spi_nor_hwcaps *hwcaps)
+{
+ if (!nor->setup)
+ return 0;
+
+ return nor->setup(nor, info, params, hwcaps);
+}
+
static int spi_nor_init(struct spi_nor *nor)
{
int err;
@@ -2492,6 +2438,8 @@ int spi_nor_scan(struct spi_nor *nor)
nor->read_reg = spi_nor_read_reg;
nor->write_reg = spi_nor_write_reg;
+ nor->setup = spi_nor_default_setup;
+
if (spi->mode & SPI_RX_OCTAL) {
hwcaps.mask |= SNOR_HWCAPS_READ_1_1_8;
diff --git a/drivers/mtd/spi/spi-nor-tiny.c b/drivers/mtd/spi/spi-nor-tiny.c
index 55f86d5155..df9eaa5e69 100644
--- a/drivers/mtd/spi/spi-nor-tiny.c
+++ b/drivers/mtd/spi/spi-nor-tiny.c
@@ -544,28 +544,6 @@ static int spansion_read_cr_quad_enable(struct spi_nor
*nor)
}
#endif /* CONFIG_SPI_FLASH_SPANSION */
-struct spi_nor_read_command {
- u8 num_mode_clocks;
- u8 num_wait_states;
- u8 opcode;
- enum spi_nor_protocol proto;
-};
-
-enum spi_nor_read_command_index {
- SNOR_CMD_READ,
- SNOR_CMD_READ_FAST,
-
- /* Quad SPI */
- SNOR_CMD_READ_1_1_4,
-
- SNOR_CMD_READ_MAX
-};
-
-struct spi_nor_flash_parameter {
- struct spi_nor_hwcaps hwcaps;
- struct spi_nor_read_command reads[SNOR_CMD
[PATCH v4 06/20] mtd: spi-nor-core: Move SFDP related declarations to top
These structures will be used in a later commit inside another structure
definition. Also take the declarations out of the ifdef since they won't
affect the final binary anyway and will be used in a later commit.
Signed-off-by: Pratyush Yadav
---
drivers/mtd/spi/spi-nor-core.c | 224 -
1 file changed, 112 insertions(+), 112 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 6e5d6e87d7..9373d0f3ce 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -38,6 +38,118 @@
#define DEFAULT_READY_WAIT_JIFFIES (40UL * HZ)
+struct sfdp_parameter_header {
+ u8 id_lsb;
+ u8 minor;
+ u8 major;
+ u8 length; /* in double words */
+ u8 parameter_table_pointer[3]; /* byte address */
+ u8 id_msb;
+};
+
+#define SFDP_PARAM_HEADER_ID(p)(((p)->id_msb << 8) | (p)->id_lsb)
+#define SFDP_PARAM_HEADER_PTP(p) \
+ (((p)->parameter_table_pointer[2] << 16) | \
+((p)->parameter_table_pointer[1] << 8) | \
+((p)->parameter_table_pointer[0] << 0))
+
+#define SFDP_BFPT_ID 0xff00 /* Basic Flash Parameter Table */
+#define SFDP_SECTOR_MAP_ID 0xff81 /* Sector Map Table */
+#define SFDP_SST_ID0x01bf /* Manufacturer specific Table */
+
+#define SFDP_SIGNATURE 0x50444653U
+#define SFDP_JESD216_MAJOR 1
+#define SFDP_JESD216_MINOR 0
+#define SFDP_JESD216A_MINOR5
+#define SFDP_JESD216B_MINOR6
+
+struct sfdp_header {
+ u32 signature; /* Ox50444653U <=> "SFDP" */
+ u8 minor;
+ u8 major;
+ u8 nph; /* 0-base number of parameter headers */
+ u8 unused;
+
+ /* Basic Flash Parameter Table. */
+ struct sfdp_parameter_headerbfpt_header;
+};
+
+/* Basic Flash Parameter Table */
+
+/*
+ * JESD216 rev B defines a Basic Flash Parameter Table of 16 DWORDs.
+ * They are indexed from 1 but C arrays are indexed from 0.
+ */
+#define BFPT_DWORD(i) ((i) - 1)
+#define BFPT_DWORD_MAX 16
+
+/* The first version of JESB216 defined only 9 DWORDs. */
+#define BFPT_DWORD_MAX_JESD216 9
+
+/* 1st DWORD. */
+#define BFPT_DWORD1_FAST_READ_1_1_2BIT(16)
+#define BFPT_DWORD1_ADDRESS_BYTES_MASK GENMASK(18, 17)
+#define BFPT_DWORD1_ADDRESS_BYTES_3_ONLY (0x0UL << 17)
+#define BFPT_DWORD1_ADDRESS_BYTES_3_OR_4 (0x1UL << 17)
+#define BFPT_DWORD1_ADDRESS_BYTES_4_ONLY (0x2UL << 17)
+#define BFPT_DWORD1_DTRBIT(19)
+#define BFPT_DWORD1_FAST_READ_1_2_2BIT(20)
+#define BFPT_DWORD1_FAST_READ_1_4_4BIT(21)
+#define BFPT_DWORD1_FAST_READ_1_1_4BIT(22)
+
+/* 5th DWORD. */
+#define BFPT_DWORD5_FAST_READ_2_2_2BIT(0)
+#define BFPT_DWORD5_FAST_READ_4_4_4BIT(4)
+
+/* 11th DWORD. */
+#define BFPT_DWORD11_PAGE_SIZE_SHIFT 4
+#define BFPT_DWORD11_PAGE_SIZE_MASKGENMASK(7, 4)
+
+/* 15th DWORD. */
+
+/*
+ * (from JESD216 rev B)
+ * Quad Enable Requirements (QER):
+ * - 000b: Device does not have a QE bit. Device detects 1-1-4 and 1-4-4
+ * reads based on instruction. DQ3/HOLD# functions are hold during
+ * instruction phase.
+ * - 001b: QE is bit 1 of status register 2. It is set via Write Status with
+ * two data bytes where bit 1 of the second byte is one.
+ * [...]
+ * Writing only one byte to the status register has the side-effect of
+ * clearing status register 2, including the QE bit. The 100b code is
+ * used if writing one byte to the status register does not modify
+ * status register 2.
+ * - 010b: QE is bit 6 of status register 1. It is set via Write Status with
+ * one data byte where bit 6 is one.
+ * [...]
+ * - 011b: QE is bit 7 of status register 2. It is set via Write status
+ * register 2 instruction 3Eh with one data byte where bit 7 is one.
+ * [...]
+ * The status register 2 is read using instruction 3Fh.
+ * - 100b: QE is bit 1 of status register 2. It is set via Write Status with
+ * two data bytes where bit 1 of the second byte is one.
+ * [...]
+ * In contrast to the 001b code, writing one byte to the status
+ * register does not modify status register 2.
+ * - 101b: QE is bit 1 of status register 2. Status register 1 is read using
+ * Read Status instruction 05h. Status register2 is read using
+ * instruction 35h. QE is set via Writ Status instruction 01h with
+ * two data bytes where bit 1 of the second byte is one.
+ * [...]
+ */
+#define BFPT_DWORD15_QER_MASK GENMASK(22, 20)
+#define BFPT_DWORD15_QER_NONE (0x0UL << 20) /* Micron */
+#define BFPT_DWORD15_QER_SR2_BIT1_BUGGY
[PATCH v4 12/20] mtd: spi-nor-core: Parse xSPI Profile 1.0 table
This table is indication that the flash is xSPI compliant and hence
supports octal DTR mode. Extract information like the fast read opcode,
the number of dummy cycles needed for a Read Status Register command,
and the number of address bytes needed for a Read Status Register
command.
The default dummy cycles for a fast octal DTR read are set to 20. Since
there is no simple way of determining the dummy cycles needed for the
fast read command, flashes that use a different value should update it
in their flash-specific hooks.
Signed-off-by: Pratyush Yadav
---
drivers/mtd/spi/spi-nor-core.c | 100 +
include/linux/mtd/spi-nor.h| 7 +++
2 files changed, 107 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 2355283d30..2cb419c7ca 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -38,6 +39,8 @@
#define DEFAULT_READY_WAIT_JIFFIES (40UL * HZ)
+#define ROUND_UP_TO(x, y) (((x) + (y) - 1) / (y) * (y))
+
struct sfdp_parameter_header {
u8 id_lsb;
u8 minor;
@@ -56,6 +59,7 @@ struct sfdp_parameter_header {
#define SFDP_BFPT_ID 0xff00 /* Basic Flash Parameter Table */
#define SFDP_SECTOR_MAP_ID 0xff81 /* Sector Map Table */
#define SFDP_SST_ID0x01bf /* Manufacturer specific Table */
+#define SFDP_PROFILE1_ID 0xff05 /* xSPI Profile 1.0 Table */
#define SFDP_SIGNATURE 0x50444653U
#define SFDP_JESD216_MAJOR 1
@@ -153,6 +157,16 @@ struct sfdp_header {
#define BFPT_DWORD18_CMD_EXT_RES (0x2UL << 29) /* Reserved */
#define BFPT_DWORD18_CMD_EXT_16B (0x3UL << 29) /* 16-bit opcode
*/
+/* xSPI Profile 1.0 table (from JESD216D.01). */
+#define PROFILE1_DWORD1_RD_FAST_CMDGENMASK(15, 8)
+#define PROFILE1_DWORD1_RDSR_DUMMY BIT(28)
+#define PROFILE1_DWORD1_RDSR_ADDR_BYTESBIT(29)
+#define PROFILE1_DWORD4_DUMMY_200MHZ GENMASK(11, 7)
+#define PROFILE1_DWORD5_DUMMY_166MHZ GENMASK(31, 27)
+#define PROFILE1_DWORD5_DUMMY_133MHZ GENMASK(21, 17)
+#define PROFILE1_DWORD5_DUMMY_100MHZ GENMASK(11, 7)
+#define PROFILE1_DUMMY_DEFAULT 20
+
struct sfdp_bfpt {
u32 dwords[BFPT_DWORD_MAX];
};
@@ -2055,6 +2069,86 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt, params);
}
+/**
+ * spi_nor_parse_profile1() - parse the xSPI Profile 1.0 table
+ * @nor: pointer to a 'struct spi_nor'
+ * @param_header: pointer to the 'struct sfdp_parameter_header' describing
+ * the 4-Byte Address Instruction Table length and version.
+ * @params:pointer to the 'struct spi_nor_flash_parameter' to be.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spi_nor_parse_profile1(struct spi_nor *nor,
+ const struct sfdp_parameter_header
*profile1_header,
+ struct spi_nor_flash_parameter *params)
+{
+ u32 *table, opcode, addr;
+ size_t len;
+ int ret, i;
+ u8 dummy;
+
+ len = profile1_header->length * sizeof(*table);
+ table = kmalloc(len, GFP_KERNEL);
+ if (!table)
+ return -ENOMEM;
+
+ addr = SFDP_PARAM_HEADER_PTP(profile1_header);
+ ret = spi_nor_read_sfdp(nor, addr, len, table);
+ if (ret)
+ goto out;
+
+ /* Fix endianness of the table DWORDs. */
+ for (i = 0; i < profile1_header->length; i++)
+ table[i] = le32_to_cpu(table[i]);
+
+ /* Get 8D-8D-8D fast read opcode and dummy cycles. */
+ opcode = FIELD_GET(PROFILE1_DWORD1_RD_FAST_CMD, table[0]);
+
+ /*
+* We don't know what speed the controller is running at. Find the
+* dummy cycles for the fastest frequency the flash can run at to be
+* sure we are never short of dummy cycles. A value of 0 means the
+* frequency is not supported.
+*
+* Default to PROFILE1_DUMMY_DEFAULT if we don't find anything, and let
+* flashes set the correct value if needed in their fixup hooks.
+*/
+ dummy = FIELD_GET(PROFILE1_DWORD4_DUMMY_200MHZ, table[3]);
+ if (!dummy)
+ dummy = FIELD_GET(PROFILE1_DWORD5_DUMMY_166MHZ, table[4]);
+ if (!dummy)
+ dummy = FIELD_GET(PROFILE1_DWORD5_DUMMY_133MHZ, table[4]);
+ if (!dummy)
+ dummy = FIELD_GET(PROFILE1_DWORD5_DUMMY_100MHZ, table[4]);
+ if (!dummy)
+ dummy = PROFILE1_DUMMY_DEFAULT;
+
+ /* Round up to an even value to avoid tripping controllers up. */
+ dummy = ROUND_UP_TO(dummy, 2);
+
+ /* Update the fast read settings. */
+ spi_nor_set_read_settings(¶m
[PATCH v4 08/20] mtd: spi-nor-core: Rework hwcaps selection
The spi-mem layer provides a spi_mem_supports_op() function to check
whether a specific operation is supported by the controller or not.
This is much more accurate than the hwcaps selection logic based on
SPI_{RX,TX}_ flags.
Rework the hwcaps selection logic to use spi_mem_supports_op().
Based on the Linux commit c76f5089796a (mtd: spi-nor: Rework hwcaps
selection for the spi-mem case, 2019-08-06)
Signed-off-by: Pratyush Yadav
---
drivers/mtd/spi/spi-nor-core.c | 168 +
include/linux/mtd/spi-nor.h| 14 +++
2 files changed, 144 insertions(+), 38 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index fd99d88501..9db5bffa0a 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -2289,6 +2289,124 @@ static int spi_nor_hwcaps_pp2cmd(u32 hwcaps)
ARRAY_SIZE(hwcaps_pp2cmd));
}
+/**
+ * spi_nor_check_op - check if the operation is supported by controller
+ * @nor:pointer to a 'struct spi_nor'
+ * @op: pointer to op template to be checked
+ *
+ * Returns 0 if operation is supported, -ENOTSUPP otherwise.
+ */
+static int spi_nor_check_op(struct spi_nor *nor,
+ struct spi_mem_op *op)
+{
+ /*
+* First test with 4 address bytes. The opcode itself might be a 3B
+* addressing opcode but we don't care, because SPI controller
+* implementation should not check the opcode, but just the sequence.
+*/
+ op->addr.nbytes = 4;
+ if (!spi_mem_supports_op(nor->spi, op)) {
+ if (nor->mtd.size > SZ_16M)
+ return -ENOTSUPP;
+
+ /* If flash size <= 16MB, 3 address bytes are sufficient */
+ op->addr.nbytes = 3;
+ if (!spi_mem_supports_op(nor->spi, op))
+ return -ENOTSUPP;
+ }
+
+ return 0;
+}
+
+/**
+ * spi_nor_check_readop - check if the read op is supported by controller
+ * @nor: pointer to a 'struct spi_nor'
+ * @read:pointer to op template to be checked
+ *
+ * Returns 0 if operation is supported, -ENOTSUPP otherwise.
+ */
+static int spi_nor_check_readop(struct spi_nor *nor,
+ const struct spi_nor_read_command *read)
+{
+ struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(read->opcode, 1),
+ SPI_MEM_OP_ADDR(3, 0, 1),
+ SPI_MEM_OP_DUMMY(0, 1),
+ SPI_MEM_OP_DATA_IN(0, NULL, 1));
+
+ op.cmd.buswidth = spi_nor_get_protocol_inst_nbits(read->proto);
+ op.addr.buswidth = spi_nor_get_protocol_addr_nbits(read->proto);
+ op.data.buswidth = spi_nor_get_protocol_data_nbits(read->proto);
+ op.dummy.buswidth = op.addr.buswidth;
+ op.dummy.nbytes = (read->num_mode_clocks + read->num_wait_states) *
+ op.dummy.buswidth / 8;
+
+ return spi_nor_check_op(nor, &op);
+}
+
+/**
+ * spi_nor_check_pp - check if the page program op is supported by controller
+ * @nor: pointer to a 'struct spi_nor'
+ * @pp: pointer to op template to be checked
+ *
+ * Returns 0 if operation is supported, -ENOTSUPP otherwise.
+ */
+static int spi_nor_check_pp(struct spi_nor *nor,
+ const struct spi_nor_pp_command *pp)
+{
+ struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(pp->opcode, 1),
+ SPI_MEM_OP_ADDR(3, 0, 1),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_OUT(0, NULL, 1));
+
+ op.cmd.buswidth = spi_nor_get_protocol_inst_nbits(pp->proto);
+ op.addr.buswidth = spi_nor_get_protocol_addr_nbits(pp->proto);
+ op.data.buswidth = spi_nor_get_protocol_data_nbits(pp->proto);
+
+ return spi_nor_check_op(nor, &op);
+}
+
+/**
+ * spi_nor_adjust_hwcaps - Find optimal Read/Write protocol based on SPI
+ * controller capabilities
+ * @nor:pointer to a 'struct spi_nor'
+ * @params: pointer to the 'struct spi_nor_flash_parameter'
+ * representing SPI NOR flash capabilities
+ * @hwcaps: pointer to resulting capabilities after adjusting
+ * according to controller and flash's capability
+ */
+static void
+spi_nor_adjust_hwcaps(struct spi_nor *nor,
+ const struct spi_nor_flash_parameter *params,
+ u32 *hwcaps)
+{
+ unsigned int cap;
+
+ /* DTR modes are not supported yet, mask them all. */
+ *hwcaps &= ~SNOR_HWCAPS_DTR;
+
+ /* X-X-X modes are not supported yet, mask them all. */
+ *hwcaps &= ~SNOR_HWCAPS_X_X_X;
+
+ for (cap = 0; cap < sizeof(*hwcaps) * BITS_PER_BYTE; cap++) {
+ int rdidx, ppidx;
+
+ if (!(*hwcaps & BIT(cap)))
+ continue;
+
+
[PATCH v4 11/20] mtd: spi-nor-core: Get command opcode extension type from BFPT
Some devices in DTR mode expect an extra command byte called the
extension. The extension can either be same as the opcode, bitwise
inverse of the opcode, or another additional byte forming a 16-byte
opcode. Get the extension type from the BFPT. For now, only flashes with
"repeat" and "inverse" extensions are supported.
Signed-off-by: Pratyush Yadav
---
drivers/mtd/spi/spi-nor-core.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index b6cec2cc86..2355283d30 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -147,6 +147,12 @@ struct sfdp_header {
#define BFPT_DWORD15_QER_SR2_BIT1_NO_RD(0x4UL << 20)
#define BFPT_DWORD15_QER_SR2_BIT1 (0x5UL << 20) /* Spansion */
+#define BFPT_DWORD18_CMD_EXT_MASK GENMASK(30, 29)
+#define BFPT_DWORD18_CMD_EXT_REP (0x0UL << 29) /* Repeat */
+#define BFPT_DWORD18_CMD_EXT_INV (0x1UL << 29) /* Invert */
+#define BFPT_DWORD18_CMD_EXT_RES (0x2UL << 29) /* Reserved */
+#define BFPT_DWORD18_CMD_EXT_16B (0x3UL << 29) /* 16-bit opcode
*/
+
struct sfdp_bfpt {
u32 dwords[BFPT_DWORD_MAX];
};
@@ -2028,6 +2034,24 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt,
params);
+ /* 8D-8D-8D command extension. */
+ switch (bfpt.dwords[BFPT_DWORD(18)] & BFPT_DWORD18_CMD_EXT_MASK) {
+ case BFPT_DWORD18_CMD_EXT_REP:
+ nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
+ break;
+
+ case BFPT_DWORD18_CMD_EXT_INV:
+ nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
+ break;
+
+ case BFPT_DWORD18_CMD_EXT_RES:
+ return -EINVAL;
+
+ case BFPT_DWORD18_CMD_EXT_16B:
+ dev_err(nor->dev, "16-bit opcodes not supported\n");
+ return -ENOTSUPP;
+ }
+
return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt, params);
}
--
2.26.2
[PATCH v4 07/20] mtd: spi-nor-core: Introduce flash-specific fixup hooks
Sometimes the information in a flash's SFDP tables is wrong. Sometimes
some information just can't be expressed in the SFDP table. So,
introduce the fixup hooks to allow tailoring settings for a specific
flash.
Three hooks are added: default_init, post_sfdp, and post_bfpt. These
allow tweaking the flash settings at different point in the probe
sequence. Since the hooks reside in nor->info, set that value just
before the call to spi_nor_init_params().
The hooks and at what points they are executed mimics Linux's spi-nor
framework.
Signed-off-by: Pratyush Yadav
---
drivers/mtd/spi/sf_internal.h | 3 ++
drivers/mtd/spi/spi-nor-core.c | 72 --
2 files changed, 72 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index ce0cf4c428..aa42524345 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -68,6 +68,9 @@ struct flash_info {
#define USE_CLSR BIT(14) /* use CLSR command */
#define SPI_NOR_HAS_SST26LOCK BIT(15) /* Flash supports lock/unlock via BPR */
#define SPI_NOR_OCTAL_READ BIT(16) /* Flash supports Octal Read */
+
+ /* Part specific fixup hooks. */
+ const struct spi_nor_fixups *fixups;
};
extern const struct flash_info spi_nor_ids[];
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 9373d0f3ce..fd99d88501 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -150,6 +150,31 @@ struct sfdp_bfpt {
u32 dwords[BFPT_DWORD_MAX];
};
+/**
+ * struct spi_nor_fixups - SPI NOR fixup hooks
+ * @default_init: called after default flash parameters init. Used to tweak
+ *flash parameters when information provided by the flash_info
+ *table is incomplete or wrong.
+ * @post_bfpt: called after the BFPT table has been parsed
+ * @post_sfdp: called after SFDP has been parsed (is also called for SPI NORs
+ * that do not support RDSFDP). Typically used to tweak various
+ * parameters that could not be extracted by other means (i.e.
+ * when information provided by the SFDP/flash_info tables are
+ * incomplete or wrong).
+ *
+ * Those hooks can be used to tweak the SPI NOR configuration when the SFDP
+ * table is broken or not available.
+ */
+struct spi_nor_fixups {
+ void (*default_init)(struct spi_nor *nor);
+ int (*post_bfpt)(struct spi_nor *nor,
+const struct sfdp_parameter_header *bfpt_header,
+const struct sfdp_bfpt *bfpt,
+struct spi_nor_flash_parameter *params);
+ void (*post_sfdp)(struct spi_nor *nor,
+ struct spi_nor_flash_parameter *params);
+};
+
static int spi_nor_read_write_reg(struct spi_nor *nor, struct spi_mem_op
*op, void *buf)
{
@@ -1741,6 +1766,19 @@ static const struct sfdp_bfpt_erase sfdp_bfpt_erases[] =
{
static int spi_nor_hwcaps_read2cmd(u32 hwcaps);
+static int
+spi_nor_post_bfpt_fixups(struct spi_nor *nor,
+const struct sfdp_parameter_header *bfpt_header,
+const struct sfdp_bfpt *bfpt,
+struct spi_nor_flash_parameter *params)
+{
+ if (nor->info->fixups && nor->info->fixups->post_bfpt)
+ return nor->info->fixups->post_bfpt(nor, bfpt_header, bfpt,
+ params);
+
+ return 0;
+}
+
/**
* spi_nor_parse_bfpt() - read and parse the Basic Flash Parameter Table.
* @nor: pointer to a 'struct spi_nor'
@@ -1879,7 +1917,8 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
/* Stop here if not JESD216 rev A or later. */
if (bfpt_header->length < BFPT_DWORD_MAX)
- return 0;
+ return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt,
+ params);
/* Page size: this field specifies 'N' so the page size = 2^N bytes. */
params->page_size = bfpt.dwords[BFPT_DWORD(11)];
@@ -1912,7 +1951,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
return -EINVAL;
}
- return 0;
+ return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt, params);
}
/**
@@ -2075,6 +2114,29 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor,
}
#endif /* SPI_FLASH_SFDP_SUPPORT */
+/**
+ * spi_nor_post_sfdp_fixups() - Updates the flash's parameters and settings
+ * after SFDP has been parsed (is also called for SPI NORs that do not
+ * support RDSFDP).
+ * @nor: pointer to a 'struct spi_nor'
+ *
+ * Typically used to tweak various parameters that could not be extracted by
+ * other means (i.e. when information provided by the SFDP/flash_info tables
+ * are incomplete or wrong).
+ */
+static void spi_nor_post_sfdp_fixups(struct spi_nor *nor,
+s
[PATCH v4 14/20] mtd: spi-nor-core: Enable octal DTR mode when possible
Allow flashes to specify a hook to enable octal DTR mode. Use this hook
whenever possible to get optimal transfer speeds.
Signed-off-by: Pratyush Yadav
---
drivers/mtd/spi/spi-nor-core.c | 31 +++
include/linux/mtd/spi-nor.h| 2 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 656dd09ea2..bb860158ae 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -2803,10 +2803,41 @@ static int spi_nor_setup(struct spi_nor *nor, const
struct flash_info *info,
return nor->setup(nor, info, params, hwcaps);
}
+/** spi_nor_octal_dtr_enable() - enable Octal DTR I/O if needed
+ * @nor: pointer to a 'struct spi_nor'
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spi_nor_octal_dtr_enable(struct spi_nor *nor)
+{
+ int ret;
+
+ if (!nor->octal_dtr_enable)
+ return 0;
+
+ if (!(nor->read_proto == SNOR_PROTO_8_8_8_DTR &&
+ nor->write_proto == SNOR_PROTO_8_8_8_DTR))
+ return 0;
+
+ ret = nor->octal_dtr_enable(nor);
+ if (ret)
+ return ret;
+
+ nor->reg_proto = SNOR_PROTO_8_8_8_DTR;
+
+ return 0;
+}
+
static int spi_nor_init(struct spi_nor *nor)
{
int err;
+ err = spi_nor_octal_dtr_enable(nor);
+ if (err) {
+ dev_dbg(nor->dev, "Octal DTR mode not supported\n");
+ return err;
+ }
+
/*
* Atmel, SST, Intel/Numonyx, and others serial NOR tend to power up
* with the software protection bits set
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index f738c5eecc..dbd29d0200 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -474,6 +474,7 @@ struct flash_info;
* @flash_is_locked: [FLASH-SPECIFIC] check if a region of the SPI NOR is
* @quad_enable: [FLASH-SPECIFIC] enables SPI NOR quad mode
* completely locked
+ * @octal_dtr_enable: [FLASH-SPECIFIC] enables SPI NOR octal DTR mode.
* @priv: the private data
*/
struct spi_nor {
@@ -521,6 +522,7 @@ struct spi_nor {
int (*flash_unlock)(struct spi_nor *nor, loff_t ofs, uint64_t len);
int (*flash_is_locked)(struct spi_nor *nor, loff_t ofs, uint64_t len);
int (*quad_enable)(struct spi_nor *nor);
+ int (*octal_dtr_enable)(struct spi_nor *nor);
void *priv;
/* Compatibility for spi_flash, remove once sf layer is merged with mtd */
--
2.26.2
[PATCH v4 15/20] mtd: spi-nor-core: Do not make invalid quad enable fatal
The Micron MT35XU512ABA flash does not support the quad enable bit. But
instead of programming the Quad Enable Require field to 000b ("Device
does not have a QE bit"), it is programmed to 111b ("Reserved").
While this is technically incorrect, it is not reason enough to abort
BFPT parsing. Instead, continue BFPT parsing assuming there is no quad
enable bit present.
Signed-off-by: Pratyush Yadav
---
drivers/mtd/spi/spi-nor-core.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index bb860158ae..88aa8268f9 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -2051,9 +2051,6 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
/* Quad Enable Requirements. */
switch (bfpt.dwords[BFPT_DWORD(15)] & BFPT_DWORD15_QER_MASK) {
- case BFPT_DWORD15_QER_NONE:
- params->quad_enable = NULL;
- break;
#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
case BFPT_DWORD15_QER_SR2_BIT1_BUGGY:
case BFPT_DWORD15_QER_SR2_BIT1_NO_RD:
@@ -2070,8 +2067,10 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
params->quad_enable = spansion_read_cr_quad_enable;
break;
#endif
+ case BFPT_DWORD15_QER_NONE:
default:
- return -EINVAL;
+ params->quad_enable = NULL;
+ break;
}
/* Stop here if JESD216 rev B. */
--
2.26.2
[PATCH v4 13/20] mtd: spi-nor-core: Prepare Read SR and FSR for Octal DTR mode
The xSPI Profile 1.0 table specifies how many dummy cycles and address
bytes are needed for the Read Status Register command in Octal DTR mode.
Use that information to send the correct Read SR command.
Some controllers might have trouble reading just 1 byte in DTR mode. So,
when we are in DTR mode read 2 bytes and discard the second. This shows
no side effects with the two flashes I tested: Micron mt35xu512aba and
Cypress s28hs512t.
Update Read FSR to mimic Read SR because they share the same
characteristics.
Signed-off-by: Pratyush Yadav
---
drivers/mtd/spi/spi-nor-core.c | 43 +-
1 file changed, 37 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 2cb419c7ca..656dd09ea2 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -376,15 +376,30 @@ static ssize_t spi_nor_write_data(struct spi_nor *nor,
loff_t to, size_t len,
static int read_sr(struct spi_nor *nor)
{
int ret;
- u8 val;
+ u8 val[2];
+ u8 addr_nbytes = nor->rdsr_addr_nbytes;
+ u8 dummy = nor->rdsr_dummy;
+ struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RDSR, 1),
+ SPI_MEM_OP_ADDR(addr_nbytes, 0, 1),
+ SPI_MEM_OP_DUMMY(dummy, 1),
+ SPI_MEM_OP_DATA_IN(1, NULL, 1));
- ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val, 1);
+ spi_nor_setup_op(nor, &op, nor->reg_proto);
+
+ /*
+* We don't want to read only one byte in DTR mode. So, read 2 and then
+* discard the second byte.
+*/
+ if (spi_nor_protocol_is_dtr(nor->reg_proto))
+ op.data.nbytes = 2;
+
+ ret = spi_nor_read_write_reg(nor, &op, val);
if (ret < 0) {
pr_debug("error %d reading SR\n", (int)ret);
return ret;
}
- return val;
+ return *val;
}
/*
@@ -395,15 +410,31 @@ static int read_sr(struct spi_nor *nor)
static int read_fsr(struct spi_nor *nor)
{
int ret;
- u8 val;
+ u8 val[2];
+ u8 addr_nbytes = nor->rdsr_addr_nbytes;
+ u8 dummy = nor->rdsr_dummy;
- ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val, 1);
+ struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RDFSR, 1),
+ SPI_MEM_OP_ADDR(addr_nbytes, 0, 1),
+ SPI_MEM_OP_DUMMY(dummy, 1),
+ SPI_MEM_OP_DATA_IN(1, NULL, 1));
+
+ spi_nor_setup_op(nor, &op, nor->reg_proto);
+
+ /*
+* We don't want to read only one byte in DTR mode. So, read 2 and then
+* discard the second byte.
+*/
+ if (spi_nor_protocol_is_dtr(nor->reg_proto))
+ op.data.nbytes = 2;
+
+ ret = spi_nor_read_write_reg(nor, &op, val);
if (ret < 0) {
pr_debug("error %d reading FSR\n", ret);
return ret;
}
- return val;
+ return *val;
}
/*
--
2.26.2
[PATCH v4 09/20] mtd: spi-nor-core: Add support for DTR protocol
Double Transfer Rate (DTR) is SPI protocol in which data is transferred
on each clock edge as opposed to on each clock cycle. Make
framework-level changes to allow supporting flashes in DTR mode.
Right now, mixed DTR modes are not supported. So, for example a mode
like 4S-4D-4D will not work. All phases need to be either DTR or STR.
Signed-off-by: Pratyush Yadav
---
drivers/mtd/spi/sf_internal.h | 1 +
drivers/mtd/spi/spi-nor-core.c | 126 +
include/linux/mtd/spi-nor.h| 50 +
3 files changed, 150 insertions(+), 27 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index aa42524345..e77e335b26 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -68,6 +68,7 @@ struct flash_info {
#define USE_CLSR BIT(14) /* use CLSR command */
#define SPI_NOR_HAS_SST26LOCK BIT(15) /* Flash supports lock/unlock via BPR */
#define SPI_NOR_OCTAL_READ BIT(16) /* Flash supports Octal Read */
+#define SPI_NOR_OCTAL_DTR_READ BIT(17) /* Flash supports Octal DTR Read */
/* Part specific fixup hooks. */
const struct spi_nor_fixups *fixups;
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 9db5bffa0a..3e8393b352 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -175,6 +175,76 @@ struct spi_nor_fixups {
struct spi_nor_flash_parameter *params);
};
+/**
+ * spi_nor_get_cmd_ext() - Get the command opcode extension based on the
+ *extension type.
+ * @nor: pointer to a 'struct spi_nor'
+ * @op:pointer to the 'struct spi_mem_op' whose
properties
+ * need to be initialized.
+ *
+ * Right now, only "repeat" and "invert" are supported.
+ *
+ * Return: The opcode extension.
+ */
+static u8 spi_nor_get_cmd_ext(const struct spi_nor *nor,
+ const struct spi_mem_op *op)
+{
+ switch (nor->cmd_ext_type) {
+ case SPI_NOR_EXT_INVERT:
+ return ~op->cmd.opcode;
+
+ case SPI_NOR_EXT_REPEAT:
+ return op->cmd.opcode;
+
+ default:
+ dev_err(nor->dev, "Unknown command extension type\n");
+ return 0;
+ }
+}
+
+/**
+ * spi_nor_setup_op() - Set up common properties of a spi-mem op.
+ * @nor: pointer to a 'struct spi_nor'
+ * @op:pointer to the 'struct spi_mem_op' whose
properties
+ * need to be initialized.
+ * @proto: the protocol from which the properties need to be set.
+ */
+static void spi_nor_setup_op(const struct spi_nor *nor,
+struct spi_mem_op *op,
+const enum spi_nor_protocol proto)
+{
+ u8 ext;
+
+ op->cmd.buswidth = spi_nor_get_protocol_inst_nbits(proto);
+
+ if (op->addr.nbytes)
+ op->addr.buswidth = spi_nor_get_protocol_addr_nbits(proto);
+
+ if (op->dummy.nbytes)
+ op->dummy.buswidth = spi_nor_get_protocol_addr_nbits(proto);
+
+ if (op->data.nbytes)
+ op->data.buswidth = spi_nor_get_protocol_data_nbits(proto);
+
+ if (spi_nor_protocol_is_dtr(proto)) {
+ /*
+* spi-mem supports mixed DTR modes, but right now we can only
+* have all phases either DTR or STR. IOW, spi-mem can have
+* something like 4S-4D-4D, but spi-nor can't. So, set all 4
+* phases to either DTR or STR.
+*/
+ op->cmd.dtr = op->addr.dtr = op->dummy.dtr =
+ op->data.dtr = true;
+
+ /* 2 bytes per clock cycle in DTR mode. */
+ op->dummy.nbytes *= 2;
+
+ ext = spi_nor_get_cmd_ext(nor, op);
+ op->cmd.opcode = (op->cmd.opcode << 8) | ext;
+ op->cmd.nbytes = 2;
+ }
+}
+
static int spi_nor_read_write_reg(struct spi_nor *nor, struct spi_mem_op
*op, void *buf)
{
@@ -193,6 +263,8 @@ static int spi_nor_read_reg(struct spi_nor *nor, u8 code,
u8 *val, int len)
SPI_MEM_OP_DATA_IN(len, NULL, 1));
int ret;
+ spi_nor_setup_op(nor, &op, nor->reg_proto);
+
ret = spi_nor_read_write_reg(nor, &op, val);
if (ret < 0)
dev_dbg(nor->dev, "error %d reading %x\n", ret, code);
@@ -207,6 +279,8 @@ static int spi_nor_write_reg(struct spi_nor *nor, u8
opcode, u8 *buf, int len)
SPI_MEM_OP_NO_DUMMY,
SPI_MEM_OP_DATA_OUT(len, NULL, 1));
+ spi_nor_setup_op(nor, &op, nor->reg_proto);
+
return spi_nor_read_write_reg(nor, &op, buf);
}
@@ -221,14 +295,12 @@ static ssize_t spi_nor_read_data(struct spi_nor *nor,
loff_t from, size_t len,
size_t remaining = l
[PATCH v4 17/20] mtd: spi-nor-core: Perform a Soft Reset on shutdown
On probe, the SPI NOR core will put a flash in 8D-8D-8D mode if it
supports it. But Linux as of now expects to get the flash in 1S-1S-1S
mode. Handing the flash to Linux in Octal DTR mode means the kernel will
fail to detect the flash.
So, we need to reset to Power-on-Reset (POR) state before handing off
the flash. A Software Reset command can be used to do this.
One limitation of the soft reset is that it will restore state from
non-volatile registers in some flashes. This means that if the flash was
set to 8D mode in a non-volatile configuration, a soft reset won't help.
This commit assumes that we don't set any non-volatile bits anywhere,
and the flash doesn't have any non-volatile Octal DTR mode
configuration.
Signed-off-by: Pratyush Yadav
---
drivers/mtd/spi/sf_probe.c | 9 +
drivers/mtd/spi/spi-nor-core.c | 64 ++
include/linux/mtd/spi-nor.h| 10 ++
3 files changed, 83 insertions(+)
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index c2e51f9c68..fc658418e0 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -153,6 +153,14 @@ int spi_flash_std_probe(struct udevice *dev)
static int spi_flash_std_remove(struct udevice *dev)
{
+ struct spi_flash *flash;
+ int ret;
+
+ flash = dev_get_uclass_priv(dev);
+ ret = spi_nor_remove(flash);
+ if (ret)
+ return ret;
+
#if CONFIG_IS_ENABLED(SPI_FLASH_MTD)
spi_flash_mtd_unregister();
#endif
@@ -179,6 +187,7 @@ U_BOOT_DRIVER(spi_flash_std) = {
.remove = spi_flash_std_remove,
.priv_auto_alloc_size = sizeof(struct spi_flash),
.ops= &spi_flash_std_ops,
+ .flags = DM_FLAG_OS_PREPARE,
};
#endif /* CONFIG_DM_SPI_FLASH */
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 03bf34a3c9..ca445d7278 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -198,6 +199,8 @@ struct spi_nor_fixups {
struct spi_nor_flash_parameter *params);
};
+#define SPI_NOR_SRST_SLEEP_LEN 200
+
/**
* spi_nor_get_cmd_ext() - Get the command opcode extension based on the
*extension type.
@@ -2883,6 +2886,67 @@ static int spi_nor_init(struct spi_nor *nor)
return 0;
}
+/**
+ * spi_nor_soft_reset() - perform the JEDEC Software Reset sequence
+ * @nor: the spi_nor structure
+ *
+ * This function can be used to switch from Octal DTR mode to legacy mode on a
+ * flash that supports it. The soft reset is executed in Octal DTR mode.
+ *
+ * Return: 0 for success, -errno for failure.
+ */
+static int spi_nor_soft_reset(struct spi_nor *nor)
+{
+ struct spi_mem_op op;
+ int ret;
+ enum spi_nor_cmd_ext ext;
+
+ ext = nor->cmd_ext_type;
+ nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
+
+ op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN, 8),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_NO_ADDR,
+ SPI_MEM_OP_NO_DATA);
+ spi_nor_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR);
+ ret = spi_mem_exec_op(nor->spi, &op);
+ if (ret) {
+ dev_warn(nor->dev, "Software reset enable failed: %d\n", ret);
+ goto out;
+ }
+
+ op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRST, 8),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_NO_ADDR,
+ SPI_MEM_OP_NO_DATA);
+ spi_nor_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR);
+ ret = spi_mem_exec_op(nor->spi, &op);
+ if (ret) {
+ dev_warn(nor->dev, "Software reset failed: %d\n", ret);
+ goto out;
+ }
+
+ /*
+* Software Reset is not instant, and the delay varies from flash to
+* flash. Looking at a few flashes, most range somewhere below 100
+* microseconds. So, wait for 200ms just to be sure.
+*/
+ udelay(SPI_NOR_SRST_SLEEP_LEN);
+
+out:
+ nor->cmd_ext_type = ext;
+ return ret;
+}
+
+int spi_nor_remove(struct spi_nor *nor)
+{
+ if (nor->info->flags & SPI_NOR_OCTAL_DTR_READ &&
+ nor->flags & SNOR_F_SOFT_RESET)
+ return spi_nor_soft_reset(nor);
+
+ return 0;
+}
+
int spi_nor_scan(struct spi_nor *nor)
{
struct spi_nor_flash_parameter params;
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 0850f1d775..d8cebf1dcf 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -67,6 +67,8 @@
#define SPINOR_OP_CLFSR0x50/* Clear flag status register */
#define SPINOR_OP_RDEAR0xc8/* Read Extended Address
Register */
#define SPINOR_OP_WREAR0xc5/* Write Extended Address
Register
[PATCH v4 18/20] mtd: spi-nor-core: Perform a Soft Reset on boot
When the flash is handed to us in a stateful mode like 8D-8D-8D, it is difficult to detect the mode the flash is in. One option is to read SFDP in all modes and see which one gives the correct "SFDP" signature, but not all flashes support SFDP in 8D-8D-8D mode. Further, even if you detect the mode of the flash via SFDP, you still have the problem of actually reading the ID. The Read ID command is not standardized across flash vendors. Flashes can have different dummy cycles needed for reading the ID. Some flashes even expect a 4-byte dummy address with the Read ID command. All this information cannot be obtained from the SFDP table. So, perform a Software Reset sequence before reading the ID and initializing the flash. A Soft Reset will bring back the flash in its default protocol mode assuming no non-volatile configuration was set. This will let us detect the flash even if ROM hands it to us in Octal DTR mode. To accommodate cases where there is more than one flash on a board, and only one of them needs a soft reset, failure to reset is not made fatal, and we still try to read ID if possible. Signed-off-by: Pratyush Yadav --- drivers/mtd/spi/Kconfig| 11 +++ drivers/mtd/spi/spi-nor-core.c | 27 +++ 2 files changed, 38 insertions(+) diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig index 018e8c597e..38d509c568 100644 --- a/drivers/mtd/spi/Kconfig +++ b/drivers/mtd/spi/Kconfig @@ -88,6 +88,17 @@ config SPI_FLASH_SFDP_SUPPORT SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP) tables as per JESD216 standard. +config SPI_FLASH_SOFT_RESET + bool "Software Reset support for SPI NOR flashes" + help +Enable support for xSPI Software Reset. It will be used to switch +from Octal DTR mode to legacy mode to allow detecting flashes that +are handed to us in Octal DTR mode. It is expected that if the config +is enabled the flash supports the Soft Reset sequence and is booted in +Octal DTR mode. Do not enable this config on flashes that are not +supposed to be handed to U-Boot in Octal DTR mode, even if they _do_ +support the Soft Reset sequence. + config SPI_FLASH_BAR bool "SPI flash Bank/Extended address register support" help diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c index ca445d7278..4953ea38e8 100644 --- a/drivers/mtd/spi/spi-nor-core.c +++ b/drivers/mtd/spi/spi-nor-core.c @@ -2971,6 +2971,33 @@ int spi_nor_scan(struct spi_nor *nor) nor->setup = spi_nor_default_setup; +#if defined(CONFIG_SPI_FLASH_SOFT_RESET) + /* +* When the flash is handed to us in a stateful mode like 8D-8D-8D, it +* is difficult to detect the mode the flash is in. One option is to +* read SFDP in all modes and see which one gives the correct "SFDP" +* signature, but not all flashes support SFDP in 8D-8D-8D mode. +* +* Further, even if you detect the mode of the flash via SFDP, you +* still have the problem of actually reading the ID. The Read ID +* command is not standardized across flash vendors. Flashes can have +* different dummy cycles needed for reading the ID. Some flashes even +* expect a 4-byte dummy address with the Read ID command. All this +* information cannot be obtained from the SFDP table. +* +* So, perform a Software Reset sequence before reading the ID and +* initializing the flash. A Soft Reset will bring back the flash in +* its default protocol mode assuming no non-volatile configuration was +* set. This will let us detect the flash even if ROM hands it to us in +* Octal DTR mode. +* +* To accommodate cases where there is more than one flash on a board, +* and only one of them needs a soft reset, failure to reset is not +* made fatal, and we still try to read ID if possible. +*/ + spi_nor_soft_reset(nor); +#endif /* CONFIG_SPI_FLASH_SOFT_RESET */ + info = spi_nor_read_id(nor); if (IS_ERR_OR_NULL(info)) return -ENOENT; -- 2.26.2
[PATCH v4 19/20] mtd: spi-nor-core: Add support for Cypress Semper flash
The Cypress Semper flash is an xSPI compliant octal DTR flash. Add
support for using it in octal DTR mode.
The flash by default boots in a hybrid sector mode. Switch to uniform
sector mode on boot. Use the default 20 dummy cycles for a read fast
command.
The SFDP programming on some older versions of the flash was incorrect.
Fixes for that are included in the fixup hooks.
Signed-off-by: Pratyush Yadav
---
drivers/mtd/spi/sf_internal.h | 4 +
drivers/mtd/spi/spi-nor-core.c | 196 +
drivers/mtd/spi/spi-nor-ids.c | 1 +
include/linux/mtd/spi-nor.h| 13 +++
4 files changed, 214 insertions(+)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index e77e335b26..5669897087 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -76,6 +76,10 @@ struct flash_info {
extern const struct flash_info spi_nor_ids[];
+#ifdef CONFIG_SPI_FLASH_SPANSION
+extern struct spi_nor_fixups s28hs512t_fixups;
+#endif
+
#define JEDEC_MFR(info)((info)->id[0])
#define JEDEC_ID(info) (((info)->id[1]) << 8 | ((info)->id[2]))
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 4953ea38e8..9a19b254e2 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -2811,6 +2811,202 @@ static int spi_nor_setup(struct spi_nor *nor, const
struct flash_info *info,
return nor->setup(nor, info, params, hwcaps);
}
+#ifdef CONFIG_SPI_FLASH_SPANSION
+/**
+ * spi_nor_cypress_octal_dtr_enable() - Enable octal DTR on Cypress flashes.
+ * @nor: pointer to a 'struct spi_nor'
+ *
+ * This also sets the memory access latency cycles to 24 to allow the flash to
+ * run at up to 200MHz.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spi_nor_cypress_octal_dtr_enable(struct spi_nor *nor)
+{
+ struct spi_mem_op op;
+ u8 buf;
+ u8 addr_width = 3;
+ int ret;
+
+ /* Use 24 dummy cycles for memory array reads. */
+ ret = write_enable(nor);
+ if (ret)
+ return ret;
+
+ buf = SPINOR_REG_CYPRESS_CFR2V_MEMLAT_11_24;
+ op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_ANY_REG,
1),
+ SPI_MEM_OP_ADDR(addr_width, SPINOR_REG_CYPRESS_CFR2V,
1),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_OUT(1, &buf, 1));
+ ret = spi_mem_exec_op(nor->spi, &op);
+ if (ret) {
+ dev_warn(nor->dev,
+"failed to set default memory latency value: %d\n",
+ret);
+ return ret;
+ }
+ ret = spi_nor_wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ nor->read_dummy = 24;
+
+ /* Set the octal and DTR enable bits. */
+ ret = write_enable(nor);
+ if (ret)
+ return ret;
+
+ buf = SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_EN;
+ op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_ANY_REG,
1),
+ SPI_MEM_OP_ADDR(addr_width, SPINOR_REG_CYPRESS_CFR5V,
1),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_OUT(1, &buf, 1));
+ ret = spi_mem_exec_op(nor->spi, &op);
+ if (ret) {
+ dev_warn(nor->dev, "Failed to enable octal DTR mode\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int s28hs512t_setup(struct spi_nor *nor, const struct flash_info *info,
+ const struct spi_nor_flash_parameter *params,
+ const struct spi_nor_hwcaps *hwcaps)
+{
+ struct spi_mem_op op;
+ u8 buf;
+ u8 addr_width = 3;
+ int ret;
+
+ ret = spi_nor_wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ /*
+* This Cypress flash also supports hybrid sector sizes. Make sure
+* uniform sector mode is selected. This is done by setting the bit
+* CFR3N[3].
+*/
+ op = (struct spi_mem_op)
+ SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_RD_ANY_REG, 1),
+ SPI_MEM_OP_ADDR(addr_width,
+ SPINOR_REG_CYPRESS_CFR3V, 1),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_IN(1, &buf, 1));
+ ret = spi_mem_exec_op(nor->spi, &op);
+ if (ret)
+ return ret;
+
+ ret = write_enable(nor);
+ if (ret)
+ return ret;
+
+ /* Set the uniform sector mode bit. */
+ buf |= SPINOR_REG_CYPRESS_CFR3N_UNISECT;
+ op = (struct spi_mem_op)
+ SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_ANY_REG, 1),
+ SPI_MEM_OP_ADDR(addr_width,
+ SPINOR_REG_CYPRESS_CFR3N, 1),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_OUT(1, &buf, 1));
[PATCH v4 16/20] mtd: spi-nor-core: Detect Soft Reset sequence support from BFPT
A Soft Reset sequence will return the flash to Power-on-Reset (POR)
state. It consists of two commands: Soft Reset Enable and Soft Reset.
Find out if the sequence is supported from BFPT DWORD 16.
Signed-off-by: Pratyush Yadav
---
drivers/mtd/spi/spi-nor-core.c | 6 ++
include/linux/mtd/spi-nor.h| 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 88aa8268f9..03bf34a3c9 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -151,6 +151,8 @@ struct sfdp_header {
#define BFPT_DWORD15_QER_SR2_BIT1_NO_RD(0x4UL << 20)
#define BFPT_DWORD15_QER_SR2_BIT1 (0x5UL << 20) /* Spansion */
+#define BFPT_DWORD16_SOFT_RST BIT(12)
+
#define BFPT_DWORD18_CMD_EXT_MASK GENMASK(30, 29)
#define BFPT_DWORD18_CMD_EXT_REP (0x0UL << 29) /* Repeat */
#define BFPT_DWORD18_CMD_EXT_INV (0x1UL << 29) /* Invert */
@@ -2073,6 +2075,10 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
break;
}
+ /* Soft Reset support. */
+ if (bfpt.dwords[BFPT_DWORD(16)] & BFPT_DWORD16_SOFT_RST)
+ nor->flags |= SNOR_F_SOFT_RESET;
+
/* Stop here if JESD216 rev B. */
if (bfpt_header->length == BFPT_DWORD_MAX_JESD216B)
return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt,
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index dbd29d0200..0850f1d775 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -248,6 +248,7 @@ enum spi_nor_option_flags {
SNOR_F_READY_XSR_RDY= BIT(4),
SNOR_F_USE_CLSR = BIT(5),
SNOR_F_BROKEN_RESET = BIT(6),
+ SNOR_F_SOFT_RESET = BIT(7),
};
struct spi_nor;
--
2.26.2
[PATCH v4 10/20] mtd: spi-nor-core: prepare BFPT parsing for JESD216 rev D
JESD216 rev D makes BFPT 20 DWORDs. Update the BFPT size define to
reflect that.
The check for rev A or later compared the BFPT header length with the
maximum BFPT length, BFPT_DWORD_MAX. Since BFPT_DWORD_MAX was 16, and so
was the BFPT length for both rev A and B, this check worked fine. But
now, since BFPT_DWORD_MAX is 20, it means this check will also stop BFPT
parsing for rev A or B, since their length is 16.
So, instead check for BFPT_DWORD_MAX_JESD216 to stop BFPT parsing for
the first JESD216 version, and check for BFPT_DWORD_MAX_JESD216B for the
next two versions.
Signed-off-by: Pratyush Yadav
---
drivers/mtd/spi/spi-nor-core.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 3e8393b352..b6cec2cc86 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -77,14 +77,15 @@ struct sfdp_header {
/* Basic Flash Parameter Table */
/*
- * JESD216 rev B defines a Basic Flash Parameter Table of 16 DWORDs.
+ * JESD216 rev D defines a Basic Flash Parameter Table of 20 DWORDs.
* They are indexed from 1 but C arrays are indexed from 0.
*/
#define BFPT_DWORD(i) ((i) - 1)
-#define BFPT_DWORD_MAX 16
+#define BFPT_DWORD_MAX 20
/* The first version of JESB216 defined only 9 DWORDs. */
#define BFPT_DWORD_MAX_JESD216 9
+#define BFPT_DWORD_MAX_JESD216B16
/* 1st DWORD. */
#define BFPT_DWORD1_FAST_READ_1_1_2BIT(16)
@@ -1987,7 +1988,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
}
/* Stop here if not JESD216 rev A or later. */
- if (bfpt_header->length < BFPT_DWORD_MAX)
+ if (bfpt_header->length == BFPT_DWORD_MAX_JESD216)
return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt,
params);
@@ -2022,6 +2023,11 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
return -EINVAL;
}
+ /* Stop here if JESD216 rev B. */
+ if (bfpt_header->length == BFPT_DWORD_MAX_JESD216B)
+ return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt,
+ params);
+
return spi_nor_post_bfpt_fixups(nor, bfpt_header, &bfpt, params);
}
--
2.26.2
[PATCH v4 20/20] mtd: spi-nor-core: Allow using Micron mt35xu512aba in Octal DTR mode
Since this flash doesn't have a Profile 1.0 table, the Octal DTR
capabilities are enabled in the post SFDP fixup, along with the 8D-8D-8D
fast read settings.
Enable Octal DTR mode with 20 dummy cycles to allow running at the
maximum supported frequency of 200Mhz.
The flash supports the soft reset sequence. So, add the flag in the
flash's info.
Signed-off-by: Pratyush Yadav
---
drivers/mtd/spi/sf_internal.h | 4 ++
drivers/mtd/spi/spi-nor-core.c | 87 ++
drivers/mtd/spi/spi-nor-ids.c | 3 +-
include/linux/mtd/spi-nor.h| 10 +++-
4 files changed, 101 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 5669897087..f1caba72be 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -80,6 +80,10 @@ extern const struct flash_info spi_nor_ids[];
extern struct spi_nor_fixups s28hs512t_fixups;
#endif
+#ifdef CONFIG_SPI_FLASH_STMICRO
+extern struct spi_nor_fixups mt35xu512aba_fixups;
+#endif
+
#define JEDEC_MFR(info)((info)->id[0])
#define JEDEC_ID(info) (((info)->id[1]) << 8 | ((info)->id[2]))
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 9a19b254e2..d09df2ebf6 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -3007,6 +3007,93 @@ struct spi_nor_fixups s28hs512t_fixups = {
};
#endif /* CONFIG_SPI_FLASH_SPANSION */
+#ifdef CONFIG_SPI_FLASH_STMICRO
+static int spi_nor_micron_octal_dtr_enable(struct spi_nor *nor)
+{
+ struct spi_mem_op op;
+ u8 buf;
+ u8 addr_width = 3;
+ int ret;
+
+ ret = write_enable(nor);
+ if (ret)
+ return ret;
+
+ buf = SPINOR_MT_DTR_NO_DQS;
+ op = (struct spi_mem_op)
+ SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_MT_WR_ANY_REG, 1),
+ SPI_MEM_OP_ADDR(addr_width, SPINOR_REG_MT_CFR0V, 1),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_OUT(1, &buf, 1));
+ ret = spi_mem_exec_op(nor->spi, &op);
+ if (ret) {
+ dev_err(nor->dev, "Failed to enable octal DTR mode\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int mt35xu512aba_setup(struct spi_nor *nor,
+ const struct flash_info *info,
+ const struct spi_nor_flash_parameter *params,
+ const struct spi_nor_hwcaps *hwcaps)
+{
+ struct spi_mem_op op;
+ u8 buf;
+ u8 addr_width = 3;
+ int ret;
+
+ /* Set dummy cycles for Fast Read to the default of 20. */
+ ret = write_enable(nor);
+ if (ret)
+ return ret;
+
+ buf = 20;
+ op = (struct spi_mem_op)
+ SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_MT_WR_ANY_REG, 1),
+ SPI_MEM_OP_ADDR(addr_width, SPINOR_REG_MT_CFR1V, 1),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_OUT(1, &buf, 1));
+ ret = spi_mem_exec_op(nor->spi, &op);
+ if (ret)
+ return ret;
+
+ ret = spi_nor_wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ return spi_nor_default_setup(nor, info, params, hwcaps);
+}
+
+static void mt35xu512aba_default_init(struct spi_nor *nor)
+{
+ nor->octal_dtr_enable = spi_nor_micron_octal_dtr_enable;
+ nor->setup = mt35xu512aba_setup;
+}
+
+static void mt35xu512aba_post_sfdp_fixup(struct spi_nor *nor,
+struct spi_nor_flash_parameter *params)
+{
+ /* Set the Fast Read settings. */
+ params->hwcaps.mask |= SNOR_HWCAPS_READ_8_8_8_DTR;
+ spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_8_8_8_DTR],
+ 0, 20, SPINOR_OP_MT_DTR_RD,
+ SNOR_PROTO_8_8_8_DTR);
+
+ params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;
+
+ nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
+ params->rdsr_dummy = 8;
+ params->rdsr_addr_nbytes = 0;
+}
+
+struct spi_nor_fixups mt35xu512aba_fixups = {
+ .default_init = mt35xu512aba_default_init,
+ .post_sfdp = mt35xu512aba_post_sfdp_fixup,
+};
+#endif /* CONFIG_SPI_FLASH_STMICRO */
+
/** spi_nor_octal_dtr_enable() - enable Octal DTR I/O if needed
* @nor: pointer to a 'struct spi_nor'
*
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 5459b798c3..f0dd48e398 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -185,7 +185,8 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("n25q00", 0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ INFO("mt25qu02g", 0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR |
SP
Pull request: u-boot-rockchip-20200522
Hi Tom, Please pull the rockchip updates/fixes: - Fix rk3288 chromebook veyron support; - Add pcie driver support for rk3399; - other fixes for rk3399 boards Gitlab ci: https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/pipelines/3355 Thanks, - Kever The following changes since commit 2fa581ba910368d0f7f995fb906d6c5e4218b594: Merge git://git.denx.de/u-boot-sh (2020-05-21 08:26:40 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git tags/u-boot-rockchip-20200522 for you to fetch changes up to 33863f744d513f5c16a254870e7b3cef8580bbc9: rockchip: rk3328: rock64 - fix gen3 SPL hang (2020-05-22 20:53:20 +0800) Andrius Štikonas (1): rockpro64: Enable HDMI output on rockpro64 board Deepak Das (1): rockchip: rk3399: enable spl-fifo-mode for sdmmc Heiko Stuebner (1): board: puma: use dtb given on the commandline instead of using u-boot.dtb Heinrich Schuchardt (1): tools: value checks in rkcommon_check_params() Jagan Teki (6): clk: rk3399: Add enable/disable clks clk: rk3399: Enable/Disable the PCIEPHY clk pci: Add Rockchip PCIe controller driver pci: Add Rockchip PCIe PHY controller driver rockchip: Enable PCIe/M.2 on rk3399 board w/ M.2 rockchip: Enable PCIe/M.2 on rock960 board Kurt Miller (1): rockchip: rk3328: rock64 - fix gen3 SPL hang Urja Rannikko (4): rockchip: spl: veyron speedy boots from SPI rockchip: veyron: move board_early_init_f to _r (after reloc) rockchip: spl-boot-order: do not attempt to access fdt if OF_PLATDATA defconfig: veyron: no need for CONFIG_SPL_PINCTRL_FULL arch/arm/dts/rk3328-rock64-u-boot.dtsi | 21 + arch/arm/dts/rk3399-u-boot.dtsi| 4 + arch/arm/mach-rockchip/spl-boot-order.c| 6 + arch/arm/mach-rockchip/spl.c | 3 +- board/google/veyron/veyron.c | 2 +- board/theobroma-systems/puma_rk3399/fit_spl_atf.sh | 2 +- board/vamrs/rock960_rk3399/rock960-rk3399.c| 24 + configs/chromebit_mickey_defconfig | 4 +- configs/chromebook_jerry_defconfig | 5 +- configs/chromebook_minnie_defconfig| 4 +- configs/chromebook_speedy_defconfig| 3 +- configs/nanopc-t4-rk3399_defconfig | 4 + configs/roc-pc-mezzanine-rk3399_defconfig | 4 + configs/rock64-rk3328_defconfig| 7 +- configs/rock960-rk3399_defconfig | 5 + configs/rockpro64-rk3399_defconfig | 7 + drivers/clk/rockchip/clk_rk3399.c | 154 +++ drivers/pci/Kconfig| 8 + drivers/pci/Makefile | 1 + drivers/pci/pcie_rockchip.c| 491 + drivers/pci/pcie_rockchip.h| 142 ++ drivers/pci/pcie_rockchip_phy.c| 205 + include/configs/rockpro64_rk3399.h | 5 + tools/rkcommon.c | 14 +- 24 files changed, 1106 insertions(+), 19 deletions(-) create mode 100644 drivers/pci/pcie_rockchip.c create mode 100644 drivers/pci/pcie_rockchip.h create mode 100644 drivers/pci/pcie_rockchip_phy.c
Re: Pull request: u-boot-rockchip-20200522
Hi Kever, Is there a reason the Pinebook Pro support not in this PR? Peter > Please pull the rockchip updates/fixes: > - Fix rk3288 chromebook veyron support; > - Add pcie driver support for rk3399; > - other fixes for rk3399 boards > > Gitlab ci: > https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/pipelines/3355 > > Thanks, > - Kever > > The following changes since commit 2fa581ba910368d0f7f995fb906d6c5e4218b594: > > Merge git://git.denx.de/u-boot-sh (2020-05-21 08:26:40 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git > tags/u-boot-rockchip-20200522 > > for you to fetch changes up to 33863f744d513f5c16a254870e7b3cef8580bbc9: > > rockchip: rk3328: rock64 - fix gen3 SPL hang (2020-05-22 20:53:20 +0800) > > > Andrius Štikonas (1): > rockpro64: Enable HDMI output on rockpro64 board > > Deepak Das (1): > rockchip: rk3399: enable spl-fifo-mode for sdmmc > > Heiko Stuebner (1): > board: puma: use dtb given on the commandline instead of using > u-boot.dtb > > Heinrich Schuchardt (1): > tools: value checks in rkcommon_check_params() > > Jagan Teki (6): > clk: rk3399: Add enable/disable clks > clk: rk3399: Enable/Disable the PCIEPHY clk > pci: Add Rockchip PCIe controller driver > pci: Add Rockchip PCIe PHY controller driver > rockchip: Enable PCIe/M.2 on rk3399 board w/ M.2 > rockchip: Enable PCIe/M.2 on rock960 board > > Kurt Miller (1): > rockchip: rk3328: rock64 - fix gen3 SPL hang > > Urja Rannikko (4): > rockchip: spl: veyron speedy boots from SPI > rockchip: veyron: move board_early_init_f to _r (after reloc) > rockchip: spl-boot-order: do not attempt to access fdt if OF_PLATDATA > defconfig: veyron: no need for CONFIG_SPL_PINCTRL_FULL > > arch/arm/dts/rk3328-rock64-u-boot.dtsi | 21 + > arch/arm/dts/rk3399-u-boot.dtsi| 4 + > arch/arm/mach-rockchip/spl-boot-order.c| 6 + > arch/arm/mach-rockchip/spl.c | 3 +- > board/google/veyron/veyron.c | 2 +- > board/theobroma-systems/puma_rk3399/fit_spl_atf.sh | 2 +- > board/vamrs/rock960_rk3399/rock960-rk3399.c| 24 + > configs/chromebit_mickey_defconfig | 4 +- > configs/chromebook_jerry_defconfig | 5 +- > configs/chromebook_minnie_defconfig| 4 +- > configs/chromebook_speedy_defconfig| 3 +- > configs/nanopc-t4-rk3399_defconfig | 4 + > configs/roc-pc-mezzanine-rk3399_defconfig | 4 + > configs/rock64-rk3328_defconfig| 7 +- > configs/rock960-rk3399_defconfig | 5 + > configs/rockpro64-rk3399_defconfig | 7 + > drivers/clk/rockchip/clk_rk3399.c | 154 +++ > drivers/pci/Kconfig| 8 + > drivers/pci/Makefile | 1 + > drivers/pci/pcie_rockchip.c| 491 > + > drivers/pci/pcie_rockchip.h| 142 ++ > drivers/pci/pcie_rockchip_phy.c| 205 + > include/configs/rockpro64_rk3399.h | 5 + > tools/rkcommon.c | 14 +- > 24 files changed, 1106 insertions(+), 19 deletions(-) > create mode 100644 drivers/pci/pcie_rockchip.c > create mode 100644 drivers/pci/pcie_rockchip.h > create mode 100644 drivers/pci/pcie_rockchip_phy.c > >
Re: [PATCH u-boot 2/2] eth/r8152: fix typo in register name
On 5/22/20 10:54 AM, Hayes Wang wrote: > The PAL_BDC_CR should be PLA_BDC_CR. > > Signed-off-by: Hayes Wang > --- > drivers/usb/eth/r8152.c | 8 > drivers/usb/eth/r8152.h | 4 ++-- > 2 files changed, 6 insertions(+), 6 deletions(-) Applied, thanks. Take a look at 1/2 and resend it if applicable.
Re: [PATCH u-boot 1/2] eth/r8152: fix assigning the wrong endpoint
On 5/22/20 10:54 AM, Hayes Wang wrote:
> Although I think it never occurs, the code doesn't make sense, because
> it may allow to assign an IN endpoint to ss->ep_out.
>
> Signed-off-by: Hayes Wang
> ---
> drivers/usb/eth/r8152.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/usb/eth/r8152.c b/drivers/usb/eth/r8152.c
> index 61b8683230..7c48663370 100644
> --- a/drivers/usb/eth/r8152.c
> +++ b/drivers/usb/eth/r8152.c
> @@ -1354,9 +1354,8 @@ int r8152_eth_probe(struct usb_device *dev, unsigned
> int ifnum,
> struct usb_interface *iface;
> struct usb_interface_descriptor *iface_desc;
> int ep_in_found = 0, ep_out_found = 0;
> - int i;
> -
> struct r8152 *tp;
> + int i;
>
> /* let's examine the device now */
> iface = &dev->config.if_desc[ifnum];
> @@ -1399,10 +1398,13 @@ int r8152_eth_probe(struct usb_device *dev, unsigned
> int ifnum,
> if ((iface->ep_desc[i].bmAttributes &
>USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_BULK) {
> u8 ep_addr = iface->ep_desc[i].bEndpointAddress;
> - if ((ep_addr & USB_DIR_IN) && !ep_in_found) {
> - ss->ep_in = ep_addr &
> - USB_ENDPOINT_NUMBER_MASK;
> - ep_in_found = 1;
> +
> + if (ep_addr & USB_DIR_IN) {
> + if (!ep_in_found) {
> + ss->ep_in = ep_addr &
> + USB_ENDPOINT_NUMBER_MASK;
> + ep_in_found = 1;
> + }
So why don't you rework the code this way instead, to make it easier to
understand:
if ((ep_addr & USB_DIR_IN) && !ep_in_found) {
... do in stuff ...
}
if ((ep_addr & USB_DIR_OUT) && !ep_out_found) {
... do out stuff ...
}
Would that work ?
Re: [PATCH 00/22] x86: Enhance MTRR functionality to support multiple CPUs
Hi Andy, On Fri, 22 May 2020 at 04:55, Andy Shevchenko wrote: > > On Thu, May 21, 2020 at 08:23:04PM -0600, Simon Glass wrote: > > At present MTRRs are mirrored to the secondary CPUs only once, as those > > CPUs are started up. But U-Boot may add more MTRRs later, e.g. if it > > decides that a video console must be set up. > > > > This series enhances the x86 multi-processor support to allow MTRRs to > > be updated at any time. It also updates the 'mtrr' command to support > > setting the MTRRs on CPUs other than the boot CPU. > > Hmm... Why do you need MTRR if CPU supports PAT? I suspect U-Boot could move to PAT one day but the needs are small in firmware. Regards, Simon
Re: [PATCH v5 1/2] usb: provide a device tree node to USB devices
Hi Michael,
On Fri, 22 May 2020 at 01:32, Michael Walle wrote:
>
> Hi Simon,
>
> Am 2020-05-22 04:34, schrieb Simon Glass:
> > Hi Michael,
> >
> > On Thu, 21 May 2020 at 17:28, Michael Walle wrote:
> >>
> >> Am 2020-05-21 16:13, schrieb Bin Meng:
> >> > On Thu, May 21, 2020 at 12:40 AM Michael Walle
> >> > wrote:
> >> >>
> >> >> It is possible to specify a device tree node for an USB device. This
> >> >> is
> >> >> useful if you have a static USB setup and want to use aliases which
> >> >> point to these nodes, like on the Raspberry Pi.
> >> >> The nodes are matched against their hub port number, the compatible
> >> >> strings are not matched for now.
> >> >>
> >> >> Signed-off-by: Michael Walle
> >> >> ---
> >> >> This is a new patch in v5:
> >> >> Fixes the ethernet0 alias on Raspberry Pis. This has never been
> >> >> working, but wasn't a problem until recently. Patch 2/2 changes
> >> >> the allocation of the numbers and reserves possible aliases.
> >> >>
> >> >> drivers/usb/host/usb-uclass.c | 41
> >> >> ++-
> >> >> 1 file changed, 36 insertions(+), 5 deletions(-)
> >> >>
> >> >> diff --git a/drivers/usb/host/usb-uclass.c
> >> >> b/drivers/usb/host/usb-uclass.c
> >> >> index cb79dfbbd5..f42c0625cb 100644
> >> >> --- a/drivers/usb/host/usb-uclass.c
> >> >> +++ b/drivers/usb/host/usb-uclass.c
> >> >> @@ -494,6 +494,35 @@ static int usb_match_one_id(struct
> >> >> usb_device_descriptor *desc,
> >> >> return usb_match_one_id_intf(desc, int_desc, id);
> >> >> }
> >> >>
> >> >> +static ofnode usb_get_ofnode(struct udevice *hub, int port)
> >> >> +{
> >> >> + ofnode node;
> >> >> + u32 reg;
> >> >> +
> >> >> + if (!dev_has_of_node(hub))
> >> >> + return ofnode_null();
> >> >> +
> >> >> + /*
> >> >> +* The USB controller and its USB hub are two different
> >> >> udevices,
> >> >> +* but the device tree has only one node for both. Thus we are
> >> >> +* assigning this node to both udevices.
> >> >> +* If port is zero, the controller scans its root hub, thus we
> >> >> +* are using the same ofnode as the controller here.
> >> >> +*/
> >> >> + if (!port)
> >> >> + return dev_ofnode(hub);
> >> >> +
> >> >> + ofnode_for_each_subnode(node, dev_ofnode(hub)) {
> >> >> + if (ofnode_read_u32(node, "reg", ®))
> >> >> + continue;
> >> >> +
> >> >> + if (reg == port)
> >> >> + return node;
> >> >> + }
> >> >> +
> >> >> + return ofnode_null();
> >> >> +}
> >> >> +
> >> >> /**
> >> >> * usb_find_and_bind_driver() - Find and bind the right USB driver
> >> >> *
> >> >> @@ -502,13 +531,14 @@ static int usb_match_one_id(struct
> >> >> usb_device_descriptor *desc,
> >> >> static int usb_find_and_bind_driver(struct udevice *parent,
> >> >> struct usb_device_descriptor
> >> >> *desc,
> >> >> struct usb_interface_descriptor
> >> >> *iface,
> >> >> - int bus_seq, int devnum,
> >> >> + int bus_seq, int devnum, int port,
> >> >> struct udevice **devp)
> >> >> {
> >> >> struct usb_driver_entry *start, *entry;
> >> >> int n_ents;
> >> >> int ret;
> >> >> char name[30], *str;
> >> >> + ofnode node = usb_get_ofnode(parent, port);
> >> >>
> >> >> *devp = NULL;
> >> >> debug("%s: Searching for driver\n", __func__);
> >> >> @@ -533,8 +563,8 @@ static int usb_find_and_bind_driver(struct udevice
> >> >> *parent,
> >> >> * find another driver. For now this doesn't
> >> >> seem
> >> >> * necesssary, so just bind the first match.
> >> >> */
> >> >> - ret = device_bind(parent, drv, drv->name,
> >> >> NULL, -1,
> >> >> - &dev);
> >> >> + ret = device_bind_ofnode(parent, drv,
> >> >> drv->name, NULL,
> >> >> +node, &dev);
> >> >> if (ret)
> >> >> goto error;
> >> >> debug("%s: Match found: %s\n", __func__,
> >> >> drv->name);
> >> >> @@ -651,9 +681,10 @@ int usb_scan_device(struct udevice *parent, int
> >> >> port,
> >> >> if (ret) {
> >> >> if (ret != -ENOENT)
> >> >> return ret;
> >> >> - ret = usb_find_and_bind_driver(parent,
> >> >> &udev->descriptor, iface,
> >> >> + ret = usb_find_and_bind_driver(parent,
> >> >> &udev->descriptor,
> >> >> + iface,
> >> >>
> >> >> udev->controller_dev->seq,
> >> >> - udev->devnum, &dev);
>
Re: [RFC PATCH v3 3/3] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit)
Hi Marek,
On Thu, 21 May 2020 at 23:56, Marek Szyprowski wrote:
>
> Hi Simon,
>
> On 19.05.2020 18:47, Simon Glass wrote:
> > On Tue, 19 May 2020 at 06:00, Marek Szyprowski
> > wrote:
> >> On 19.05.2020 00:38, Simon Glass wrote:
> >>> On Mon, 18 May 2020 at 07:18, Marek Szyprowski
> >>> wrote:
> Create a non-cacheable mapping for the 0x6 physical memory
> region,
> where MMIO registers for the PCIe XHCI controller are instantiated by the
> PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
> 32bit mode, this region is mapped at 0xff80 CPU virtual address.
>
> Signed-off-by: Marek Szyprowski
> ---
> arch/arm/mach-bcm283x/Kconfig | 1 +
> arch/arm/mach-bcm283x/include/mach/base.h | 8
> arch/arm/mach-bcm283x/init.c | 20
> include/configs/rpi.h | 7 +++
> 4 files changed, 36 insertions(+)
>
> diff --git a/arch/arm/mach-bcm283x/Kconfig
> b/arch/arm/mach-bcm283x/Kconfig
> index 00419bf..bcb7f1d 100644
> --- a/arch/arm/mach-bcm283x/Kconfig
> +++ b/arch/arm/mach-bcm283x/Kconfig
> @@ -36,6 +36,7 @@ config BCM2711_32B
> select BCM2711
> select ARMV7_LPAE
> select CPU_V7A
> + select PHYS_64BIT
>
> config BCM2711_64B
> bool "Broadcom BCM2711 SoC 64-bit support"
> diff --git a/arch/arm/mach-bcm283x/include/mach/base.h
> b/arch/arm/mach-bcm283x/include/mach/base.h
> index c4ae398..4ccaf69 100644
> --- a/arch/arm/mach-bcm283x/include/mach/base.h
> +++ b/arch/arm/mach-bcm283x/include/mach/base.h
> @@ -8,4 +8,12 @@
>
> extern unsigned long rpi_bcm283x_base;
>
> +#ifdef CONFIG_ARMV7_LPAE
> +#ifdef CONFIG_TARGET_RPI_4_32B
> +#include
> +#define phys_to_virt addrmap_phys_to_virt
> +#define virt_to_phys addrmap_virt_to_phys
> +#endif
> +#endif
> +
> #endif
> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
> index 9f5bca3..008b312 100644
> --- a/arch/arm/mach-bcm283x/init.c
> +++ b/arch/arm/mach-bcm283x/init.c
> @@ -145,6 +145,26 @@ int mach_cpu_init(void)
> }
>
> #ifdef CONFIG_ARMV7_LPAE
> +#ifdef CONFIG_TARGET_RPI_4_32B
> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT 0xff80UL
> +#include
> +
> +void init_addr_map(void)
> +{
> +
> mmu_set_region_dcache_behaviour_phys(BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT,
> +
> BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS,
> +
> BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE,
> +DCACHE_OFF);
> +
> + /* identity mapping for 0..BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT */
> + addrmap_set_entry(0, 0, BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT, 0);
> + /* XHCI MMIO on PCIe at BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT */
> + addrmap_set_entry(BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT,
> + BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS,
> + BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE, 1);
> +}
> +#endif
> +
> void enable_caches(void)
> {
> dcache_enable();
> diff --git a/include/configs/rpi.h b/include/configs/rpi.h
> index b53a4b6..296e8ee 100644
> --- a/include/configs/rpi.h
> +++ b/include/configs/rpi.h
> @@ -63,6 +63,13 @@
> #define CONFIG_SYS_BOOTM_LEN SZ_64M
> #endif
>
> +#ifdef CONFIG_ARMV7_LPAE
> +#ifdef CONFIG_TARGET_RPI_4_32B
> +#define CONFIG_ADDR_MAP 1
> +#define CONFIG_SYS_NUM_ADDR_MAP 2
> +#endif
> +#endif
> >>> We should be removing things from the config files. Can you move this
> >>> to devicetree or Kconfig?
> >> I can move them to Kconfig, no problem. However I would like to get some
> >> comments if the approach I presented in this patchset is fine.
> > Yes, no problem.
> >
> > I suspect we may need to expand the DMA drivers, perhaps, or some
> > other way to map memory on a per-device basis using driver model.
>
> I'm not sure that we really need such a complex solution. Usually the
> board (or even SoC), if ever, needs one or two such non-identity
> mappings, which can be easily created by the respective init code. The
> PowerPC case mentioned here looks a bit different, because it simply
> copies the mappings already configured in the CPU registers by the
> earlier firmware. Anyway, I don't think that we would ever need to
> manage physical/virtual mapping dynamically in the u-boot. All that
> cover current (and most future?) cases would be a simple function to map
> an arbitrary physical address at the predefined virtual one.
OK, well see how y
Re: [PATCH 03/26] video: Show an error when a vidconsole function fails
On Tue, 19 May 2020 17:10:35 -0600 Simon Glass s...@chromium.org wrote: > At present these functions fail silently even when debugging, which is not > very helpful. Add a way to print a message to the serial output when an > error is detected. > > Signed-off-by: Simon Glass Reviewed-by: Anatolij Gustschin
Re: [PATCH 04/26] sandbox: video: Allow selection of rotated console
On Tue, 19 May 2020 17:10:36 -0600 Simon Glass s...@chromium.org wrote: > Add a devicetree property to select a rotated console. This uses the same > encoding as vidconsole itself: 0=normal; 1=90 degrees clockwise, 2=upside > down, 3=90 degrees anticlockwise. > > Signed-off-by: Simon Glass Reviewed-by: Anatolij Gustschin
Re: [PATCH 05/26] video: Split out expression parts into variables
On Tue, 19 May 2020 17:10:37 -0600 Simon Glass s...@chromium.org wrote: > The functions in this file do similar things but not always in the same > way. To make the code easier to read and compare, use a separate 'linenum' > variable in every function. This is then multiplied by the line length to > get the offset within the frame buffer to modify. Also use an 'x' variable > to hold the pixel position within that line. This is multipled by the > pixel size and added to the offset. > > Also move the pbytes declaration up a little with the other long lines. > > A side effect of splitting out these variables is that they are promoted > to int, i.e. a signed type, from the unsigned short used in the > vidconsole_priv struct. This would be necessary should any of the > variables go negative. At present this can actually happen in > console_putc_xy_2(), if the display width is not a multiple of the > character size (see next patch). > > Signed-off-by: Simon Glass Reviewed-by: Anatolij Gustschin
Re: [PATCH 06/26] video: Adjust rotated console to start at right edge
On Tue, 19 May 2020 17:10:38 -0600 Simon Glass s...@chromium.org wrote: > At present when the console is rotated 180 degrees it starts almost a > whole character to the left of the right edge (typically 7 pixels with > an 8-pixel-wide font). On a display which aligns with the font width, > this just wastes space. On a display that does not this can result in > x_frac going negative for the final character (the one on the left > side) and the overflow -EAGAIN check at the start of the function > failing. > > Change the function to start at the rightmost pixel to fix these > problems. > > Signed-off-by: Simon Glass Reviewed-by: Anatolij Gustschin
Re: [PATCH 07/26] video: Drop unnecessary #ifdef around vid_console_color()
On Tue, 19 May 2020 17:10:39 -0600 Simon Glass s...@chromium.org wrote: > All of the functions in this file only apply if DM_VIDEO is enabled. Drop > the #ifdef as it just clutters things up. Add the needed forward > declaration. > > Signed-off-by: Simon Glass Reviewed-by: Anatolij Gustschin
Re: [PATCH 08/26] video: Add a comment for struct video_uc_platdata
On Tue, 19 May 2020 17:10:40 -0600 Simon Glass s...@chromium.org wrote: > Add a few notes to explain the purpose of each member of this struct. > > Signed-off-by: Simon Glass Reviewed-by: Anatolij Gustschin
[PATCH v4 4/8] lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop()
From: Heiko Stuebner
When calculating rrtmp/rr rsa_gen_key_prop() tries to make
(((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and
(((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[]
with rlen being num_bits * 2
On a 4096bit key this comes down to to 257 uint32_t elements
in rr and 256 elements in rrtmp but with the current allocation
rr and rrtmp only have 129 uint32_t elements.
On 2048bit keys this works by chance as the defined max_rsa_size=4096
allocates a suitable number of elements, but with an actual 4096bit key
this results in other memory parts getting overwritten.
so double the number of elements in rr and rrtmp so that it matches
the needed number and should increase nicely if max_rsa_size gets
increased in the future.
Signed-off-by: Heiko Stuebner
---
changes in v4:
- new patch
lib/rsa/rsa-keyprop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/rsa/rsa-keyprop.c b/lib/rsa/rsa-keyprop.c
index 4b54db44c4..e28fbb7472 100644
--- a/lib/rsa/rsa-keyprop.c
+++ b/lib/rsa/rsa-keyprop.c
@@ -659,8 +659,8 @@ int rsa_gen_key_prop(const void *key, uint32_t keylen,
struct key_prop **prop)
*prop = calloc(sizeof(**prop), 1);
n = calloc(sizeof(uint32_t), 1 + (max_rsa_size >> 5));
- rr = calloc(sizeof(uint32_t), 1 + (max_rsa_size >> 5));
- rrtmp = calloc(sizeof(uint32_t), 1 + (max_rsa_size >> 5));
+ rr = calloc(sizeof(uint32_t), 1 + ((max_rsa_size * 2) >> 5));
+ rrtmp = calloc(sizeof(uint32_t), 1 + ((max_rsa_size * 2) >> 5));
if (!(*prop) || !n || !rr || !rrtmp) {
ret = -ENOMEM;
goto err;
--
2.25.1
[PATCH v4 3/8] lib: rsa: bring exp_len in line when generating a key_prop
From: Heiko Stuebner The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner --- changes in v4: - new patch lib/rsa/rsa-keyprop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/rsa/rsa-keyprop.c b/lib/rsa/rsa-keyprop.c index 9464df0093..4b54db44c4 100644 --- a/lib/rsa/rsa-keyprop.c +++ b/lib/rsa/rsa-keyprop.c @@ -691,7 +691,7 @@ int rsa_gen_key_prop(const void *key, uint32_t keylen, struct key_prop **prop) memcpy((void *)(*prop)->public_exponent + sizeof(uint64_t) - rsa_key.e_sz, rsa_key.e, rsa_key.e_sz); - (*prop)->exp_len = rsa_key.e_sz; + (*prop)->exp_len = sizeof(uint64_t); /* n0 inverse */ br_i32_decode(n, &rsa_key.n[i], rsa_key.n_sz - i); -- 2.25.1
[PATCH v4 6/8] lib: rsa: add documentation to padding_pss_verify to document limitations
From: Heiko Stuebner padding_pss_verify only works with the default pss salt setting of -2 (length to be automatically determined based on the PSS block structure) not -1 (salt length set to the maximum permissible value), which makes verifications of signatures with that saltlen fail. Until this gets implemented at least document this behaviour. Signed-off-by: Heiko Stuebner --- change in v4: - new patch lib/rsa/rsa-verify.c | 13 + 1 file changed, 13 insertions(+) diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c index 048f1ab789..61d98e6e2d 100644 --- a/lib/rsa/rsa-verify.c +++ b/lib/rsa/rsa-verify.c @@ -194,6 +194,19 @@ out: return ret; } +/* + * padding_pss_verify() - verify the pss padding of a signature + * + * Only works with a rsa_pss_saltlen:-2 (default value) right now + * saltlen:-1 "set the salt length to the digest length" is currently + * not supported. + * + * @info: Specifies key and FIT information + * @msg: byte array of message, len equal to msg_len + * @msg_len: Message length + * @hash: Pointer to the expected hash + * @hash_len: Length of the hash + */ int padding_pss_verify(struct image_sign_info *info, uint8_t *msg, int msg_len, const uint8_t *hash, int hash_len) -- 2.25.1
[PATCH v4 7/8] spl: fit: select SPL_HASH_SUPPORT for SPL_FIT_SIGNATURE
From: Heiko Stuebner rsa-checsum needs support for hash functions or else will run into compile errors like: u-boot/lib/rsa/rsa-checksum.c:28: undefined reference to `hash_progressive_lookup_algo' So similar to the main FIT_SIGNATURE entry selects HASH, select SPL_HASH_SUPPORT for SPL_FIT_SIGNATURE. Cc: Heinrich Schuchardt Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich --- Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/Kconfig b/Kconfig index 0e7ccc0b07..482f39c66f 100644 --- a/Kconfig +++ b/Kconfig @@ -459,6 +459,7 @@ config SPL_FIT_SIGNATURE bool "Enable signature verification of FIT firmware within SPL" depends on SPL_DM select SPL_FIT + select SPL_HASH_SUPPORT select SPL_RSA select SPL_RSA_VERIFY select SPL_IMAGE_SIGN_INFO -- 2.25.1
[PATCH v4 1/8] lib: rsa: distinguish between tpl and spl for CONFIG_RSA_VERIFY
From: Heiko Stuebner
While the SPL may want to do signature checking this won't be
the case for TPL in all cases, as TPL is mostly used when the
amount of initial memory is not enough for a full SPL.
So on a system where SPL uses DM but TPL does not we currently
end up with a TPL compile error of:
lib/rsa/rsa-verify.c:48:25: error: dereferencing pointer to incomplete type
‘struct checksum_algo’
To prevent that change the $(SPL_) to $(SPL_TPL_) to distinguish
between both. If someone really needs FIT signature checking in
TPL as well, a new TPL_RSA_VERIFY config symbol needs to be added.
Signed-off-by: Heiko Stuebner
Reviewed-by: Philipp Tomsich
---
changes in v4:
- amound -> amount
- found another entry to handle
changes in v2:
- fix typo "distinguis(h)"
lib/rsa/Makefile | 2 +-
lib/rsa/rsa-verify.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile
index 14ed3cb401..c61ebfd79e 100644
--- a/lib/rsa/Makefile
+++ b/lib/rsa/Makefile
@@ -5,6 +5,6 @@
# (C) Copyright 2000-2007
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-obj-$(CONFIG_$(SPL_)RSA_VERIFY) += rsa-verify.o rsa-checksum.o
+obj-$(CONFIG_$(SPL_TPL_)RSA_VERIFY) += rsa-verify.o rsa-checksum.o
obj-$(CONFIG_RSA_VERIFY_WITH_PKEY) += rsa-keyprop.o
obj-$(CONFIG_RSA_SOFTWARE_EXP) += rsa-mod-exp.o
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index 1d55b997e3..a19867742f 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -492,7 +492,7 @@ int rsa_verify(struct image_sign_info *info,
return -EINVAL;
}
- if (IS_ENABLED(CONFIG_RSA_VERIFY_WITH_PKEY) && !info->fdt_blob) {
+ if (CONFIG_IS_ENABLED(RSA_VERIFY_WITH_PKEY) && !info->fdt_blob) {
/* don't rely on fdt properties */
ret = rsa_verify_with_pkey(info, hash, sig, sig_len);
--
2.25.1
[PATCH v4 5/8] lib: rsa: free local arrays after use in rsa_gen_key_prop()
From: Heiko Stuebner
n, rr and rrtmp are used for internal calculations, but in the end
the results are copied into separately allocated elements of the
actual key_prop, so the n, rr and rrtmp elements are not used anymore
when returning from the function and should of course be freed.
Signed-off-by: Heiko Stuebner
---
changes in v4:
- new patch
lib/rsa/rsa-keyprop.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/lib/rsa/rsa-keyprop.c b/lib/rsa/rsa-keyprop.c
index e28fbb7472..ac33b35ff9 100644
--- a/lib/rsa/rsa-keyprop.c
+++ b/lib/rsa/rsa-keyprop.c
@@ -655,7 +655,7 @@ int rsa_gen_key_prop(const void *key, uint32_t keylen,
struct key_prop **prop)
struct rsa_key rsa_key;
uint32_t *n = NULL, *rr = NULL, *rrtmp = NULL;
const int max_rsa_size = 4096;
- int rlen, i, ret;
+ int rlen, i, ret = 0;
*prop = calloc(sizeof(**prop), 1);
n = calloc(sizeof(uint32_t), 1 + (max_rsa_size >> 5));
@@ -663,12 +663,12 @@ int rsa_gen_key_prop(const void *key, uint32_t keylen,
struct key_prop **prop)
rrtmp = calloc(sizeof(uint32_t), 1 + ((max_rsa_size * 2) >> 5));
if (!(*prop) || !n || !rr || !rrtmp) {
ret = -ENOMEM;
- goto err;
+ goto out;
}
ret = rsa_parse_pub_key(&rsa_key, key, keylen);
if (ret)
- goto err;
+ goto out;
/* modulus */
/* removing leading 0's */
@@ -678,7 +678,7 @@ int rsa_gen_key_prop(const void *key, uint32_t keylen,
struct key_prop **prop)
(*prop)->modulus = malloc(rsa_key.n_sz - i);
if (!(*prop)->modulus) {
ret = -ENOMEM;
- goto err;
+ goto out;
}
memcpy((void *)(*prop)->modulus, &rsa_key.n[i], rsa_key.n_sz - i);
@@ -686,7 +686,7 @@ int rsa_gen_key_prop(const void *key, uint32_t keylen,
struct key_prop **prop)
(*prop)->public_exponent = calloc(1, sizeof(uint64_t));
if (!(*prop)->public_exponent) {
ret = -ENOMEM;
- goto err;
+ goto out;
}
memcpy((void *)(*prop)->public_exponent + sizeof(uint64_t)
- rsa_key.e_sz,
@@ -710,16 +710,15 @@ int rsa_gen_key_prop(const void *key, uint32_t keylen,
struct key_prop **prop)
(*prop)->rr = malloc(rlen);
if (!(*prop)->rr) {
ret = -ENOMEM;
- goto err;
+ goto out;
}
br_i32_encode((void *)(*prop)->rr, rlen, rr);
- return 0;
-
-err:
+out:
free(n);
free(rr);
free(rrtmp);
- rsa_free_key_prop(*prop);
+ if (ret < 0)
+ rsa_free_key_prop(*prop);
return ret;
}
--
2.25.1
[PATCH v4 8/8] spl: fit: select SPL_CRYPTO_SUPPORT for SPL_FIT_SIGNATURE
From: Heiko Stuebner Verifying FIT images obviously needs the rsa parts of crypto support and while main uboot always compiles crypto support, it's optional for SPL and we should thus select the necessary option to not end up in compile errors like: u-boot/lib/rsa/rsa-verify.c:328: undefined reference to `rsa_mod_exp' So select SPL_CRYPTO_SUPPORT in SPL_FIT_SIGNATURE. Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich --- Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/Kconfig b/Kconfig index 482f39c66f..0c184f7f06 100644 --- a/Kconfig +++ b/Kconfig @@ -459,6 +459,7 @@ config SPL_FIT_SIGNATURE bool "Enable signature verification of FIT firmware within SPL" depends on SPL_DM select SPL_FIT + select SPL_CRYPTO_SUPPORT select SPL_HASH_SUPPORT select SPL_RSA select SPL_RSA_VERIFY -- 2.25.1
[PATCH v4 2/8] lib: rsa: take spl/non-spl into account when building rsa_verify_with_pkey()
From: Heiko Stuebner Right now in multiple places there are only checks for the full CONFIG_RSA_VERIFY_WITH_PKEY option, not split into main,spl,tpl variants. This breaks when the rsa functions get enabled for SPL, for example to verify u-boot proper from spl. So fix this by using the existing helpers to distinguis between build-steps. Signed-off-by: Heiko Stuebner --- changes in v3.1: - drop changeid changes in v3: - new patch with another build issue lib/rsa/Makefile | 2 +- lib/rsa/rsa-verify.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile index c61ebfd79e..8b75d41f04 100644 --- a/lib/rsa/Makefile +++ b/lib/rsa/Makefile @@ -6,5 +6,5 @@ # Wolfgang Denk, DENX Software Engineering, w...@denx.de. obj-$(CONFIG_$(SPL_TPL_)RSA_VERIFY) += rsa-verify.o rsa-checksum.o -obj-$(CONFIG_RSA_VERIFY_WITH_PKEY) += rsa-keyprop.o +obj-$(CONFIG_$(SPL_TPL_)RSA_VERIFY_WITH_PKEY) += rsa-keyprop.o obj-$(CONFIG_RSA_SOFTWARE_EXP) += rsa-mod-exp.o diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c index a19867742f..048f1ab789 100644 --- a/lib/rsa/rsa-verify.c +++ b/lib/rsa/rsa-verify.c @@ -285,7 +285,7 @@ out: } #endif -#if CONFIG_IS_ENABLED(FIT_SIGNATURE) || IS_ENABLED(CONFIG_RSA_VERIFY_WITH_PKEY) +#if CONFIG_IS_ENABLED(FIT_SIGNATURE) || CONFIG_IS_ENABLED(RSA_VERIFY_WITH_PKEY) /** * rsa_verify_key() - Verify a signature against some data using RSA Key * @@ -359,7 +359,7 @@ static int rsa_verify_key(struct image_sign_info *info, } #endif -#ifdef CONFIG_RSA_VERIFY_WITH_PKEY +#if CONFIG_IS_ENABLED(RSA_VERIFY_WITH_PKEY) /** * rsa_verify_with_pkey() - Verify a signature against some data using * only modulus and exponent as RSA key properties. -- 2.25.1
[PATCH 1/3] doc: board: rockchip: Improve supported board list format
As an additional step to move documentation to doc/boards/rockchip improve format of the supported board list to make it more readable. Additionally, add the configuration files used to build them based on doc/README.rockchip. Signed-off-by: Walter Lozano --- doc/board/rockchip/rockchip.rst | 68 - 1 file changed, 34 insertions(+), 34 deletions(-) diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst index cd9c8d6dc4..919a686423 100644 --- a/doc/board/rockchip/rockchip.rst +++ b/doc/board/rockchip/rockchip.rst @@ -22,43 +22,43 @@ mainline U-Boot. List of mainline supported rockchip boards: * rk3288 - - Evb-RK3288 - - Firefly-RK3288 - - mqmaker MiQi - - Phytec RK3288 PCM-947 - - PopMetal-RK3288 - - Radxa Rock 2 Square - - Tinker-RK3288 - - Google Jerry - - Google Mickey - - Google Minnie - - Google Speedy - - Amarula Vyasa-RK3288 + - Rockchip Evb-RK3288 (evb-rk3288) + - Firefly-RK3288 (firefly-rk3288) + - MQmaker MiQi (miqi-rk3288) + - Phytec RK3288 PCM-947 (phycore-rk3288) + - PopMetal-RK3288 (popmetal-rk3288) + - Radxa Rock 2 Square (rock2) + - Tinker-RK3288 (tinker-rk3288) + - Google Jerry (chromebook_jerry) + - Google Mickey (chromebook_mickey) + - Google Minnie (chromebook_minnie) + - Google Speedy (chromebook_speedy) + - Amarula Vyasa-RK3288 (vyasa-rk3288) * rk3328 - - Rockchip RK3328 EVB - - Pine64 Rock64 + - Rockchip Evb-RK3328 (evb-rk3328) + - Pine64 Rock64 (rock64-rk3328) * rk3368 - - GeekBox - - PX5 EVB - - Rockchip sheep board - - Theobroma Systems RK3368-uQ7 SoM + - GeekBox (geekbox) + - PX5 EVB (evb-px5) + - Rockchip Sheep (sheep-rk3368) + - Theobroma Systems RK3368-uQ7 SoM - Lion (lion-rk3368) * rk3399 - - 96boards RK3399 Ficus - - 96boards Rock960 - - Firefly-RK3399 Board - - Firefly ROC-RK3399-PC Board - - FriendlyElec NanoPC-T4 - - FriendlyElec NanoPi M4 - - FriendlyARM NanoPi NEO4 - - Google Bob - - Khadas Edge - - Khadas Edge-Captain - - Khadas Edge-V - - Orange Pi RK3399 Board - - Pine64 RockPro64 - - Radxa ROCK Pi 4 - - Rockchip RK3399 Evaluation Board - - Theobroma Systems RK3399-Q7 SoM + - 96boards RK3399 Ficus (ficus-rk3399) + - 96boards Rock960 (rock960-rk3399) + - Firefly-RK3399 (firefly_rk3399) + - Firefly ROC-RK3399-PC + - FriendlyElec NanoPC-T4 (nanopc-t4-rk3399) + - FriendlyElec NanoPi M4 (nanopi-m4-rk3399) + - FriendlyARM NanoPi NEO4 (nanopi-neo4-rk3399) + - Google Bob (chromebook_bob) + - Khadas Edge (khadas-edge-rk3399) + - Khadas Edge-Captain (khadas-edge-captain-rk3399) + - Khadas Edge-V (hadas-edge-v-rk3399) + - Orange Pi RK3399 (orangepi-rk3399) + - Pine64 RockPro64 (rockpro64-rk3399) + - Radxa ROCK Pi 4 (rock-pi-4-rk3399) + - Rockchip Evb-RK3399 (evb_rk3399) + - Theobroma Systems RK3399-Q7 SoM - Puma (puma_rk3399) Building -- 2.20.1
[PATCH 0/3] doc: rockchip: Improve documentation
As an additional step in the process of improve the Rockchip documentation and based on the comments from [1] move the list of supported boards and configs to doc/board/rockchip. [1] https://patchwork.ozlabs.org/project/uboot/list/?series=177974 Walter Lozano (3): doc: board: rockchip: Improve supported board list format doc: board: rockchip: Add missing supported boards doc: rockchip: Remove list of supported boards doc/README.rockchip | 72 ++-- doc/board/rockchip/rockchip.rst | 84 - 2 files changed, 54 insertions(+), 102 deletions(-) -- 2.20.1
[PATCH 2/3] doc: board: rockchip: Add missing supported boards
Update the list of supported boards with the information available on doc/README.rockchip. Signed-off-by: Walter Lozano --- doc/board/rockchip/rockchip.rst | 16 1 file changed, 16 insertions(+) diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst index 919a686423..c174fd83bc 100644 --- a/doc/board/rockchip/rockchip.rst +++ b/doc/board/rockchip/rockchip.rst @@ -21,6 +21,13 @@ mainline U-Boot. List of mainline supported rockchip boards: +* rk3036 + - Rockchip Evb-RK3036 (evb-rk3036) + - Kylin (kylin_rk3036) +* rk3128 + - Rockchip Evb-RK3128 (evb-rk3128) +* rk3229 + - Rockchip Evb-RK3229 (evb-rk3229) * rk3288 - Rockchip Evb-RK3288 (evb-rk3288) - Firefly-RK3288 (firefly-rk3288) @@ -34,9 +41,13 @@ List of mainline supported rockchip boards: - Google Minnie (chromebook_minnie) - Google Speedy (chromebook_speedy) - Amarula Vyasa-RK3288 (vyasa-rk3288) +* rk3308 + - Rockchip Evb-RK3308 (evb-rk3308) + - Roc-cc-RK3308 (roc-cc-rk3308) * rk3328 - Rockchip Evb-RK3328 (evb-rk3328) - Pine64 Rock64 (rock64-rk3328) + - Firefly-RK3328 (roc-cc-rk3328) * rk3368 - GeekBox (geekbox) - PX5 EVB (evb-px5) @@ -59,6 +70,11 @@ List of mainline supported rockchip boards: - Radxa ROCK Pi 4 (rock-pi-4-rk3399) - Rockchip Evb-RK3399 (evb_rk3399) - Theobroma Systems RK3399-Q7 SoM - Puma (puma_rk3399) +* rv1108 + - Rockchip Evb-rv1108 (evb-rv1108) + - Elgin-R1 (elgin-rv1108) +* rv3188 + - Radxa Rock (rock) Building -- 2.20.1
[PATCH 3/3] doc: rockchip: Remove list of supported boards
As documentation is being moved to doc/boards/rockchip create a warning message and remove the redundant list of supported boards. Signed-off-by: Walter Lozano --- doc/README.rockchip | 72 +++-- 1 file changed, 4 insertions(+), 68 deletions(-) diff --git a/doc/README.rockchip b/doc/README.rockchip index 70c8798ed2..154166ec78 100644 --- a/doc/README.rockchip +++ b/doc/README.rockchip @@ -8,6 +8,10 @@ U-Boot on Rockchip A wide range of Rockchip SoCs are supported in mainline U-Boot +Warning +=== +This document is being moved to doc/board/rockchip, so information on it +might be incomplete or outdated. Prerequisites = @@ -24,77 +28,9 @@ You will need: - Suitable ARM cross compiler, e.g.: sudo apt-get install gcc-4.7-arm-linux-gnueabi - Building -At present 11 RK3288 boards are supported: - - - EVB RK3288 - use evb-rk3288 configuration - - Firefly RK3288 - use firefly-rk3288 configuration - - Hisense Chromebook - use chromebook_jerry configuration - - Asus C100P Chromebook - use chromebook_minnie configuration - - Asus Chromebit - use chromebook_mickey configuration - - MiQi RK3288 - use miqi-rk3288 configuration - - phyCORE-RK3288 RDK - use phycore-rk3288 configuration - - PopMetal RK3288 - use popmetal-rk3288 configuration - - Radxa Rock 2 - use rock2 configuration - - Tinker RK3288 - use tinker-rk3288 configuration - - Vyasa RK3288 - use vyasa-rk3288 configuration - -Two RK3036 boards are supported: - - - EVB RK3036 - use evb-rk3036 configuration - - Kylin - use kylin_rk3036 configuration - -Two RK3308 boards are supported: - - - EVB RK3308 - use evb-rk3308 configuration - - ROC-CC-RK3308 - use roc-cc-rk3308 configuration - -Three RK3328 boards are supported: - - - EVB RK3328 - use evb-rk3328_defconfig - - Pine64 Rock64 board - use rock64-rk3328_defconfig - - Firefly / Libre Computer Project ROC-RK3328-CC board - - use roc-cc-rk3328_defconfig - -Size RK3399 boards are supported (aarch64): - - - EBV RK3399 - use evb_rk3399 configuration - - Firefly RK3399 - use the firefly_rk3399 configuration - - Puma - use puma_rk3399 configuration - - Ficus - use ficus-rk3399 configuration - - Rock960 (Vamrs) - use rock960-rk3399 configuration - - Bob - use chromebook_bob configuration - -Four RK3368 boards are supported: - - - Sheep - use sheep-rk3368 configuration - - Lion - use lion-rk3368 configuration - - Geekbox - use geekbox configuration - - EVB PX5 - use evb-px5 configuration - -One RK3128 board is supported: - - - EVB RK3128 - use evb-rk3128 configuration - -One RK3229 board is supported: - - - EVB RK3229 - use evb-rk3229 configuration - -Two RV1108 boards are supported: - - - EVB RV1108 - use evb-rv1108 configuration - - Elgin R1 - use elgin-rv1108 configuration - -One RV3188 baord is supported: - - - Raxda Rock - use rock configuration - - -For example: - 1. To build RK3288 board: CROSS_COMPILE=arm-linux-gnueabi- make O=firefly firefly-rk3288_defconfig all -- 2.20.1
[PATCH v5 3/8] lib: rsa: bring exp_len in line when generating a key_prop
From: Heiko Stuebner The exponent field of struct key_prop gets allocated an uint64_t, and the contents are positioned from the back, so an exponent of "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len to the size returned from the parser, while on the other hand the when getting the key from the devicetree exp_len always gets set to sizeof(uint64_t). So bring that in line with the established code. Signed-off-by: Heiko Stuebner --- changes in v4: - new patch lib/rsa/rsa-keyprop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/rsa/rsa-keyprop.c b/lib/rsa/rsa-keyprop.c index 9464df0093..4b54db44c4 100644 --- a/lib/rsa/rsa-keyprop.c +++ b/lib/rsa/rsa-keyprop.c @@ -691,7 +691,7 @@ int rsa_gen_key_prop(const void *key, uint32_t keylen, struct key_prop **prop) memcpy((void *)(*prop)->public_exponent + sizeof(uint64_t) - rsa_key.e_sz, rsa_key.e, rsa_key.e_sz); - (*prop)->exp_len = rsa_key.e_sz; + (*prop)->exp_len = sizeof(uint64_t); /* n0 inverse */ br_i32_decode(n, &rsa_key.n[i], rsa_key.n_sz - i); -- 2.25.1
[PATCH v5 5/8] lib: rsa: free local arrays after use in rsa_gen_key_prop()
From: Heiko Stuebner
n, rr and rrtmp are used for internal calculations, but in the end
the results are copied into separately allocated elements of the
actual key_prop, so the n, rr and rrtmp elements are not used anymore
when returning from the function and should of course be freed.
Signed-off-by: Heiko Stuebner
---
changes in v4:
- new patch
lib/rsa/rsa-keyprop.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/lib/rsa/rsa-keyprop.c b/lib/rsa/rsa-keyprop.c
index e28fbb7472..ac33b35ff9 100644
--- a/lib/rsa/rsa-keyprop.c
+++ b/lib/rsa/rsa-keyprop.c
@@ -655,7 +655,7 @@ int rsa_gen_key_prop(const void *key, uint32_t keylen,
struct key_prop **prop)
struct rsa_key rsa_key;
uint32_t *n = NULL, *rr = NULL, *rrtmp = NULL;
const int max_rsa_size = 4096;
- int rlen, i, ret;
+ int rlen, i, ret = 0;
*prop = calloc(sizeof(**prop), 1);
n = calloc(sizeof(uint32_t), 1 + (max_rsa_size >> 5));
@@ -663,12 +663,12 @@ int rsa_gen_key_prop(const void *key, uint32_t keylen,
struct key_prop **prop)
rrtmp = calloc(sizeof(uint32_t), 1 + ((max_rsa_size * 2) >> 5));
if (!(*prop) || !n || !rr || !rrtmp) {
ret = -ENOMEM;
- goto err;
+ goto out;
}
ret = rsa_parse_pub_key(&rsa_key, key, keylen);
if (ret)
- goto err;
+ goto out;
/* modulus */
/* removing leading 0's */
@@ -678,7 +678,7 @@ int rsa_gen_key_prop(const void *key, uint32_t keylen,
struct key_prop **prop)
(*prop)->modulus = malloc(rsa_key.n_sz - i);
if (!(*prop)->modulus) {
ret = -ENOMEM;
- goto err;
+ goto out;
}
memcpy((void *)(*prop)->modulus, &rsa_key.n[i], rsa_key.n_sz - i);
@@ -686,7 +686,7 @@ int rsa_gen_key_prop(const void *key, uint32_t keylen,
struct key_prop **prop)
(*prop)->public_exponent = calloc(1, sizeof(uint64_t));
if (!(*prop)->public_exponent) {
ret = -ENOMEM;
- goto err;
+ goto out;
}
memcpy((void *)(*prop)->public_exponent + sizeof(uint64_t)
- rsa_key.e_sz,
@@ -710,16 +710,15 @@ int rsa_gen_key_prop(const void *key, uint32_t keylen,
struct key_prop **prop)
(*prop)->rr = malloc(rlen);
if (!(*prop)->rr) {
ret = -ENOMEM;
- goto err;
+ goto out;
}
br_i32_encode((void *)(*prop)->rr, rlen, rr);
- return 0;
-
-err:
+out:
free(n);
free(rr);
free(rrtmp);
- rsa_free_key_prop(*prop);
+ if (ret < 0)
+ rsa_free_key_prop(*prop);
return ret;
}
--
2.25.1
[PATCH v5 6/8] lib: rsa: add documentation to padding_pss_verify to document limitations
From: Heiko Stuebner padding_pss_verify only works with the default pss salt setting of -2 (length to be automatically determined based on the PSS block structure) not -1 (salt length set to the maximum permissible value), which makes verifications of signatures with that saltlen fail. Until this gets implemented at least document this behaviour. Signed-off-by: Heiko Stuebner --- change in v4: - new patch lib/rsa/rsa-verify.c | 13 + 1 file changed, 13 insertions(+) diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c index 048f1ab789..61d98e6e2d 100644 --- a/lib/rsa/rsa-verify.c +++ b/lib/rsa/rsa-verify.c @@ -194,6 +194,19 @@ out: return ret; } +/* + * padding_pss_verify() - verify the pss padding of a signature + * + * Only works with a rsa_pss_saltlen:-2 (default value) right now + * saltlen:-1 "set the salt length to the digest length" is currently + * not supported. + * + * @info: Specifies key and FIT information + * @msg: byte array of message, len equal to msg_len + * @msg_len: Message length + * @hash: Pointer to the expected hash + * @hash_len: Length of the hash + */ int padding_pss_verify(struct image_sign_info *info, uint8_t *msg, int msg_len, const uint8_t *hash, int hash_len) -- 2.25.1
[PATCH v5 2/8] lib: rsa: take spl/non-spl into account when building rsa_verify_with_pkey()
From: Heiko Stuebner
Right now in multiple places there are only checks for the full
CONFIG_RSA_VERIFY_WITH_PKEY option, not split into main,spl,tpl variants.
This breaks when the rsa functions get enabled for SPL, for example to
verify u-boot proper from spl.
So fix this by using the existing helpers to distinguis between
build-steps.
Signed-off-by: Heiko Stuebner
---
changes in v5:
- include the additional config-check that landed in patch 1/8
in v4
changes in v3.1:
- drop changeid
changes in v3:
- new patch with another build issue
lib/rsa/Makefile | 2 +-
lib/rsa/rsa-verify.c | 6 +++---
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile
index c61ebfd79e..8b75d41f04 100644
--- a/lib/rsa/Makefile
+++ b/lib/rsa/Makefile
@@ -6,5 +6,5 @@
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
obj-$(CONFIG_$(SPL_TPL_)RSA_VERIFY) += rsa-verify.o rsa-checksum.o
-obj-$(CONFIG_RSA_VERIFY_WITH_PKEY) += rsa-keyprop.o
+obj-$(CONFIG_$(SPL_TPL_)RSA_VERIFY_WITH_PKEY) += rsa-keyprop.o
obj-$(CONFIG_RSA_SOFTWARE_EXP) += rsa-mod-exp.o
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index a19867742f..048f1ab789 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -285,7 +285,7 @@ out:
}
#endif
-#if CONFIG_IS_ENABLED(FIT_SIGNATURE) || IS_ENABLED(CONFIG_RSA_VERIFY_WITH_PKEY)
+#if CONFIG_IS_ENABLED(FIT_SIGNATURE) || CONFIG_IS_ENABLED(RSA_VERIFY_WITH_PKEY)
/**
* rsa_verify_key() - Verify a signature against some data using RSA Key
*
@@ -359,7 +359,7 @@ static int rsa_verify_key(struct image_sign_info *info,
}
#endif
-#ifdef CONFIG_RSA_VERIFY_WITH_PKEY
+#if CONFIG_IS_ENABLED(RSA_VERIFY_WITH_PKEY)
/**
* rsa_verify_with_pkey() - Verify a signature against some data using
* only modulus and exponent as RSA key properties.
@@ -492,7 +492,7 @@ int rsa_verify(struct image_sign_info *info,
return -EINVAL;
}
- if (IS_ENABLED(CONFIG_RSA_VERIFY_WITH_PKEY) && !info->fdt_blob) {
+ if (CONFIG_IS_ENABLED(RSA_VERIFY_WITH_PKEY) && !info->fdt_blob) {
/* don't rely on fdt properties */
ret = rsa_verify_with_pkey(info, hash, sig, sig_len);
--
2.25.1
[PATCH v5 1/8] lib: rsa: distinguish between tpl and spl for CONFIG_RSA_VERIFY
From: Heiko Stuebner While the SPL may want to do signature checking this won't be the case for TPL in all cases, as TPL is mostly used when the amount of initial memory is not enough for a full SPL. So on a system where SPL uses DM but TPL does not we currently end up with a TPL compile error of: lib/rsa/rsa-verify.c:48:25: error: dereferencing pointer to incomplete type ‘struct checksum_algo’ To prevent that change the $(SPL_) to $(SPL_TPL_) to distinguish between both. If someone really needs FIT signature checking in TPL as well, a new TPL_RSA_VERIFY config symbol needs to be added. Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich --- changes in v5: - drop change that belongs in patch 2/8 changes in v4: - amound -> amount - found another entry to handle changes in v2: - fix typo "distinguis(h)" lib/rsa/Makefile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile index 14ed3cb401..c61ebfd79e 100644 --- a/lib/rsa/Makefile +++ b/lib/rsa/Makefile @@ -5,6 +5,6 @@ # (C) Copyright 2000-2007 # Wolfgang Denk, DENX Software Engineering, w...@denx.de. -obj-$(CONFIG_$(SPL_)RSA_VERIFY) += rsa-verify.o rsa-checksum.o +obj-$(CONFIG_$(SPL_TPL_)RSA_VERIFY) += rsa-verify.o rsa-checksum.o obj-$(CONFIG_RSA_VERIFY_WITH_PKEY) += rsa-keyprop.o obj-$(CONFIG_RSA_SOFTWARE_EXP) += rsa-mod-exp.o -- 2.25.1
[PATCH v5 8/8] spl: fit: select SPL_CRYPTO_SUPPORT for SPL_FIT_SIGNATURE
From: Heiko Stuebner Verifying FIT images obviously needs the rsa parts of crypto support and while main uboot always compiles crypto support, it's optional for SPL and we should thus select the necessary option to not end up in compile errors like: u-boot/lib/rsa/rsa-verify.c:328: undefined reference to `rsa_mod_exp' So select SPL_CRYPTO_SUPPORT in SPL_FIT_SIGNATURE. Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich --- Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/Kconfig b/Kconfig index 482f39c66f..0c184f7f06 100644 --- a/Kconfig +++ b/Kconfig @@ -459,6 +459,7 @@ config SPL_FIT_SIGNATURE bool "Enable signature verification of FIT firmware within SPL" depends on SPL_DM select SPL_FIT + select SPL_CRYPTO_SUPPORT select SPL_HASH_SUPPORT select SPL_RSA select SPL_RSA_VERIFY -- 2.25.1
[PATCH v5 4/8] lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop()
From: Heiko Stuebner
When calculating rrtmp/rr rsa_gen_key_prop() tries to make
(((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and
(((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[]
with rlen being num_bits * 2
On a 4096bit key this comes down to to 257 uint32_t elements
in rr and 256 elements in rrtmp but with the current allocation
rr and rrtmp only have 129 uint32_t elements.
On 2048bit keys this works by chance as the defined max_rsa_size=4096
allocates a suitable number of elements, but with an actual 4096bit key
this results in other memory parts getting overwritten.
so double the number of elements in rr and rrtmp so that it matches
the needed number and should increase nicely if max_rsa_size gets
increased in the future.
Signed-off-by: Heiko Stuebner
---
changes in v4:
- new patch
lib/rsa/rsa-keyprop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/rsa/rsa-keyprop.c b/lib/rsa/rsa-keyprop.c
index 4b54db44c4..e28fbb7472 100644
--- a/lib/rsa/rsa-keyprop.c
+++ b/lib/rsa/rsa-keyprop.c
@@ -659,8 +659,8 @@ int rsa_gen_key_prop(const void *key, uint32_t keylen,
struct key_prop **prop)
*prop = calloc(sizeof(**prop), 1);
n = calloc(sizeof(uint32_t), 1 + (max_rsa_size >> 5));
- rr = calloc(sizeof(uint32_t), 1 + (max_rsa_size >> 5));
- rrtmp = calloc(sizeof(uint32_t), 1 + (max_rsa_size >> 5));
+ rr = calloc(sizeof(uint32_t), 1 + ((max_rsa_size * 2) >> 5));
+ rrtmp = calloc(sizeof(uint32_t), 1 + ((max_rsa_size * 2) >> 5));
if (!(*prop) || !n || !rr || !rrtmp) {
ret = -ENOMEM;
goto err;
--
2.25.1
[PATCH v5 7/8] spl: fit: select SPL_HASH_SUPPORT for SPL_FIT_SIGNATURE
From: Heiko Stuebner rsa-checsum needs support for hash functions or else will run into compile errors like: u-boot/lib/rsa/rsa-checksum.c:28: undefined reference to `hash_progressive_lookup_algo' So similar to the main FIT_SIGNATURE entry selects HASH, select SPL_HASH_SUPPORT for SPL_FIT_SIGNATURE. Cc: Heinrich Schuchardt Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich --- Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/Kconfig b/Kconfig index 0e7ccc0b07..482f39c66f 100644 --- a/Kconfig +++ b/Kconfig @@ -459,6 +459,7 @@ config SPL_FIT_SIGNATURE bool "Enable signature verification of FIT firmware within SPL" depends on SPL_DM select SPL_FIT + select SPL_HASH_SUPPORT select SPL_RSA select SPL_RSA_VERIFY select SPL_IMAGE_SIGN_INFO -- 2.25.1
[PATCH] lib: rsa: function to verify a signature against a hash
From: Heiko Stuebner
rsa_verify() expects a memory region and wants to do the hashing itself,
but there may be cases where the hashing is done via other means,
like hashing a squashfs rootfs.
So add rsa_verify_hash() to allow verifiying a signature against
an existing hash. As this entails the same verification routines
we can just move the relevant code over from rsa_verify() and also
call rsa_verify_hash() from there.
Signed-off-by: Heiko Stuebner
---
Patch depends on at least
lib: rsa: take spl/non-spl into account when building rsa_verify_with_pkey()
include/u-boot/rsa.h | 21 +
lib/rsa/rsa-verify.c | 56 +---
2 files changed, 53 insertions(+), 24 deletions(-)
diff --git a/include/u-boot/rsa.h b/include/u-boot/rsa.h
index 2d3024d8b7..a0bae495f0 100644
--- a/include/u-boot/rsa.h
+++ b/include/u-boot/rsa.h
@@ -82,6 +82,20 @@ static inline int rsa_add_verify_data(struct image_sign_info
*info,
#endif
#if IMAGE_ENABLE_VERIFY
+/**
+ * rsa_verify_hash() - Verify a signature against a hash
+ *
+ * Verify a RSA PKCS1.5 signature against an expected hash.
+ *
+ * @info: Specifies key and FIT information
+ * @hash: Hash according to algorithm specified in @info
+ * @sig: Signature
+ * @sig_len: Number of bytes in signature
+ * @return 0 if verified, -ve on error
+ */
+int rsa_verify_hash(struct image_sign_info *info,
+ const uint8_t *hash, uint8_t *sig, uint sig_len);
+
/**
* rsa_verify() - Verify a signature against some data
*
@@ -108,6 +122,13 @@ int padding_pss_verify(struct image_sign_info *info,
const uint8_t *hash, int hash_len);
#endif /* CONFIG_FIT_ENABLE_RSASSA_PSS_SUPPORT */
#else
+static inline int rsa_verify_hash(struct image_sign_info *info,
+ const uint8_t *hash,
+ uint8_t *sig, uint sig_len)
+{
+ return -ENXIO;
+}
+
static inline int rsa_verify(struct image_sign_info *info,
const struct image_region region[], int region_count,
uint8_t *sig, uint sig_len)
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index 61d98e6e2d..6c4bbc4625 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -478,33 +478,11 @@ static int rsa_verify_with_keynode(struct image_sign_info
*info,
}
#endif
-int rsa_verify(struct image_sign_info *info,
- const struct image_region region[], int region_count,
- uint8_t *sig, uint sig_len)
+int rsa_verify_hash(struct image_sign_info *info,
+ const uint8_t *hash, uint8_t *sig, uint sig_len)
{
- /* Reserve memory for maximum checksum-length */
- uint8_t hash[info->crypto->key_len];
int ret = -EACCES;
- /*
-* Verify that the checksum-length does not exceed the
-* rsa-signature-length
-*/
- if (info->checksum->checksum_len >
- info->crypto->key_len) {
- debug("%s: invlaid checksum-algorithm %s for %s\n",
- __func__, info->checksum->name, info->crypto->name);
- return -EINVAL;
- }
-
- /* Calculate checksum with checksum-algorithm */
- ret = info->checksum->calculate(info->checksum->name,
- region, region_count, hash);
- if (ret < 0) {
- debug("%s: Error in checksum calculation\n", __func__);
- return -EINVAL;
- }
-
if (CONFIG_IS_ENABLED(RSA_VERIFY_WITH_PKEY) && !info->fdt_blob) {
/* don't rely on fdt properties */
ret = rsa_verify_with_pkey(info, hash, sig, sig_len);
@@ -555,3 +533,33 @@ int rsa_verify(struct image_sign_info *info,
return ret;
}
+
+int rsa_verify(struct image_sign_info *info,
+ const struct image_region region[], int region_count,
+ uint8_t *sig, uint sig_len)
+{
+ /* Reserve memory for maximum checksum-length */
+ uint8_t hash[info->crypto->key_len];
+ int ret = -EACCES;
+
+ /*
+* Verify that the checksum-length does not exceed the
+* rsa-signature-length
+*/
+ if (info->checksum->checksum_len >
+ info->crypto->key_len) {
+ debug("%s: invlaid checksum-algorithm %s for %s\n",
+ __func__, info->checksum->name, info->crypto->name);
+ return -EINVAL;
+ }
+
+ /* Calculate checksum with checksum-algorithm */
+ ret = info->checksum->calculate(info->checksum->name,
+ region, region_count, hash);
+ if (ret < 0) {
+ debug("%s: Error in checksum calculation\n", __func__);
+ return -EINVAL;
+ }
+
+ return rsa_verify_hash(info, hash, sig, sig_len);
+}
--
2.25.1
Re: [PATCH v4 3/8] lib: rsa: bring exp_len in line when generating a key_prop
> On 22.05.2020, at 16:13, Heiko Stuebner wrote: > > From: Heiko Stuebner > > The exponent field of struct key_prop gets allocated an uint64_t, > and the contents are positioned from the back, so an exponent of > "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" > > Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len > to the size returned from the parser, while on the other hand the > when getting the key from the devicetree exp_len always gets set to > sizeof(uint64_t). > > So bring that in line with the established code. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH v4 2/8] lib: rsa: take spl/non-spl into account when building rsa_verify_with_pkey()
> On 22.05.2020, at 16:13, Heiko Stuebner wrote: > > From: Heiko Stuebner > > Right now in multiple places there are only checks for the full > CONFIG_RSA_VERIFY_WITH_PKEY option, not split into main,spl,tpl variants. > > This breaks when the rsa functions get enabled for SPL, for example to > verify u-boot proper from spl. > > So fix this by using the existing helpers to distinguis between > build-steps. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH 2/6] kconfig: Add support for conditional values
Hi, On Fri, 22 May 2020 at 00:18, Heinrich Schuchardt wrote: > > On 5/22/20 4:17 AM, Masahiro Yamada wrote: > > On Fri, May 22, 2020 at 11:02 AM Simon Glass wrote: > >> > >> At present if an optional Kconfig value needs to be used it must be > >> bracketed by #ifdef. For example, with this Kconfig setup: > >> > >> config WIBBLE > >> bool "Support wibbles, the world needs more wibbles" > >> > >> config WIBBLE_ADDR > >> hex "Address of the wibble" > >> depends on WIBBLE > > > > > > > > > > I am not sure if this is a good idea. > > > > > > If you want to always use CONFIG_WIBBLE_ADDR, > > you can get rid of 'depends on WIBBLE'. Yes that's right. But I worry that we end up clutting the Kconfig with unused things. Another option would be for Kconfig to emit hex CONFIGs always, even if optional? > > > > > > Hello Simon, > > what is the effect on the code size if you eliminate the #ifdefs? > > Isn't this move growing the size of the U-Boot binary? No it is handled at compile time so the code doesn't make it into the image. [..] Regards, Simon
Re: [PATCH v4 6/8] lib: rsa: add documentation to padding_pss_verify to document limitations
> On 22.05.2020, at 16:13, Heiko Stuebner wrote: > > From: Heiko Stuebner > > padding_pss_verify only works with the default pss salt setting of -2 > (length to be automatically determined based on the PSS block structure) > not -1 (salt length set to the maximum permissible value), which makes > verifications of signatures with that saltlen fail. > > Until this gets implemented at least document this behaviour. > > Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich
Re: [PATCH v8 1/2] led: led_cortina: Add CAxxx LED support
Hi Alex,
On Thu, 21 May 2020 at 18:43, Alex Nemirovsky
wrote:
>
> From: Jway Lin
>
> Add Cortina Access LED controller support for CA SOCs
>
> Signed-off-by: Jway Lin
> Signed-off-by: Alex Nemirovsky
> CC: Simon Glass
>
> ---
>
> Changes in v8:
> - No code change
> - Split out individual driver from Cortina Package 2 patch series
> to help streamline acceptence into master
>
> Changes in v7:
> - rename OFFSET to SHIFT from macros
> - add additinal struct comments
> - Reading the DT should really happen in the ofdata_to_platdata method
>
> Changes in v4:
> - remove unused macros
> - remove cortina prefix from macros
> - remove use BSS variable
> - further cleanup to meet code style guidelines
> - add additinal struct comments
> - rename DT blink rate symbol
>
> MAINTAINERS | 8 +-
> drivers/led/Kconfig | 8 ++
> drivers/led/Makefile | 1 +
> drivers/led/led_cortina.c | 305
> ++
> 4 files changed, 321 insertions(+), 1 deletion(-)
> create mode 100644 drivers/led/led_cortina.c
Reviewed-by: Simon Glass
One comment below
[..]
> diff --git a/drivers/led/led_cortina.c b/drivers/led/led_cortina.c
> new file mode 100644
> index 000..a6d9159
> --- /dev/null
> +++ b/drivers/led/led_cortina.c
> @@ -0,0 +1,305 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/*
[..]
> +static int cortina_led_set_state(struct udevice *dev, enum led_state_t state)
> +{
> + u32 val;
> + struct cortina_led_cfg *priv = dev_get_priv(dev);
> +
> + val = readl(priv->regs);
> + val &= ~(LED_OFF_ON_MASK << LED_OFF_ON_SHIFT);
> +
> + switch (state) {
> + case LEDST_OFF:
> + val &= ~LED_SW_EVENT;
> + val |= CA_LED_OFF << LED_OFF_ON_SHIFT;
> + cortina_led_write(priv->regs, val);
> + break;
> + case LEDST_ON:
> + val |= LED_SW_EVENT;
> + val |= CA_LED_ON << LED_OFF_ON_SHIFT;
> + cortina_led_write(priv->regs, val);
> + break;
> + case LEDST_TOGGLE:
> + if (cortina_led_get_state(dev) == LEDST_OFF)
> + return cortina_led_set_state(dev, LEDST_ON);
> + else
> + return cortina_led_set_state(dev, LEDST_OFF);
> + break;
> +#ifdef CONFIG_LED_BLINK
> + case LEDST_BLINK:
> + val &= ~LED_SW_EVENT;
> + val |= CA_LED_OFF << LED_OFF_ON_SHIFT;
> + val |= LED_EVENT_BLINK_MASK << LED_EVENT_BLINK_SHIFT;
> + cortina_led_write(priv->regs, val);
> + break;
> +#endif
Try to void #ifdef. You should be able to do this:
case CONFIG_LED_BLINK:
if (IS_ENABLED(CONFIG_LED_BLINK)) {
val code
...
break;
}
/* no break */
> +
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static const struct led_ops cortina_led_ops = {
> + .get_state = cortina_led_get_state,
> + .set_state = cortina_led_set_state,
> +};
> +
> +static int ca_led_ofdata_to_platdata(struct udevice *dev)
> +{
> + struct led_uc_plat *uc_plat = dev_get_uclass_platdata(dev);
> +
> + /* Top-level LED node */
> + if (!uc_plat->label) {
> + struct cortina_led_platdata *plt = dev_get_platdata(dev);
> +
> + plt->rate1 =
> + dev_read_u32_default(dev, "Cortina,blink-rate1", 256);
> + plt->rate2 =
> + dev_read_u32_default(dev, "Cortina,blink-rate2", 512);
> + plt->ctrl_regs = dev_remap_addr(dev);
> + } else {
> + struct cortina_led_cfg *priv = dev_get_priv(dev);
> +
> + priv->regs = dev_remap_addr(dev_get_parent(dev));
> + priv->pin = dev_read_u32_default(dev, "pin", LED_MAX_COUNT);
> + priv->blink_sel = dev_read_u32_default(dev, "blink-sel", 0);
> + priv->off_event = dev_read_u32_default(dev, "off-event", 0);
> + priv->blink_event = dev_read_u32_default(dev, "blink-event",
> 0);
> + priv->on_event = dev_read_u32_default(dev, "on-event", 0);
> + priv->port = dev_read_u32_default(dev, "port", 0);
> +
> + if (dev_read_bool(dev, "active-low"))
> + priv->active_low = true;
> + else
> + priv->active_low = false;
> + }
> +
> + return 0;
> +}
> +
> +static int cortina_led_probe(struct udevice *dev)
> +{
> + struct led_uc_plat *uc_plat = dev_get_uclass_platdata(dev);
> +
> + /* Top-level LED node */
> + if (!uc_plat->label) {
> + struct cortina_led_platdata *platdata = dev_get_platdata(dev);
> + u32 reg_value, val;
> + u16 rate1, rate2;
> +
> + if (!platdata->ctrl_regs)
> + return -EINVAL;
> +
> + reg_value = 0;
Re: [PATCH 2/2] sf: Simplify probe for dm code
Hi Jagan, On Thu, 14 May 2020 at 12:09, Jagan Teki wrote: > > Handling probing code for a particular uclass between > dm vs nodm always confusing and requires additional > ifdefs to handle them properly. > > But, having separate low-level code bases for dm and > nodm can make it easy for the command level to use same > function name to probe the devices. This would indeed > avoid extra ifdef call in source code. > > So, this patch probes the spi flash in common legacy > call spi_flash_probe for both dm and nodm devices and > give a chance to handle on respective code bases based > on the build files. > > Cc: Simon Glass > Cc: Vignesh R > Cc: Daniel Schwierzeck > Signed-off-by: Jagan Teki > --- > cmd/sf.c| 22 - > drivers/mtd/spi/sf-uclass.c | 38 + > drivers/net/fm/fm.c | 20 --- > env/sf.c| 17 + > include/spi_flash.h | 20 +-- > 5 files changed, 19 insertions(+), 98 deletions(-) +Tom Rini This is really going the wrong way. You would cement the code in limbo forever and no one would be able to migrate property. Instead, you should add a patch to disable SPI flash on boards which have not migrated. Then we can actually clean up the mess properly. The deadline has passed and people have had more than 5 years to migrate. It is time to make the cut. Regards, Simon
