Re: [U-Boot] [PATCH v2 3/3] efi_selftest: unit test for CalculateCrc32()
On 06.07.18 07:09, Heinrich Schuchardt wrote: > This unit test checks the CalculateCrc32 bootservice and checks the > headers of the system table, the boot services tablle, and the runtime > services table before and after ExitBootServices(). > > Signed-off-by: Heinrich Schuchardt This is a good step forward, thanks! I still don't see any code that adapts the systab crc in efi_install_configuration_table(), so we're clearly missing a test case for this. Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] efi_loader: correctly initialize system table crc32
The crc32 of the system table has to be calculated after all fields have been set. Adjust the signature of CalculateCrc32(). Provide a unit test that checks the crc of the system table, the runtime services table, and the boot sevices table before and after ExitBootServices(). v2: avoid a warning in a debug statement Heinrich Schuchardt (3): efi_loader: correctly initialize system table crc32 efi_loader: correct signature of CalculateCrc32() efi_selftest: unit test for CalculateCrc32() cmd/bootefi.c | 10 +- include/efi_api.h | 5 +- lib/efi_loader/efi_boottime.c | 8 +- lib/efi_selftest/Makefile | 1 + lib/efi_selftest/efi_selftest_crc32.c | 141 ++ 5 files changed, 154 insertions(+), 11 deletions(-) create mode 100644 lib/efi_selftest/efi_selftest_crc32.c -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] efi_selftest: unit test for CalculateCrc32()
This unit test checks the CalculateCrc32 bootservice and checks the
headers of the system table, the boot services tablle, and the runtime
services table before and after ExitBootServices().
Signed-off-by: Heinrich Schuchardt
---
v2:
no change
---
lib/efi_selftest/Makefile | 1 +
lib/efi_selftest/efi_selftest_crc32.c | 141 ++
2 files changed, 142 insertions(+)
create mode 100644 lib/efi_selftest/efi_selftest_crc32.c
diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
index d927208700..590f90b16d 100644
--- a/lib/efi_selftest/Makefile
+++ b/lib/efi_selftest/Makefile
@@ -16,6 +16,7 @@ efi_selftest_bitblt.o \
efi_selftest_config_table.o \
efi_selftest_controllers.o \
efi_selftest_console.o \
+efi_selftest_crc32.o \
efi_selftest_devicepath.o \
efi_selftest_devicepath_util.o \
efi_selftest_events.o \
diff --git a/lib/efi_selftest/efi_selftest_crc32.c
b/lib/efi_selftest/efi_selftest_crc32.c
new file mode 100644
index 00..8555b8f114
--- /dev/null
+++ b/lib/efi_selftest/efi_selftest_crc32.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * efi_selftest_crc32
+ *
+ * Copyright (c) 2018 Heinrich Schuchardt
+ *
+ * This unit test checks the CalculateCrc32 bootservice and checks the
+ * headers of the system table, the boot services tablle, and the runtime
+ * services table before and after ExitBootServices().
+ */
+
+#include
+
+const struct efi_system_table *st;
+efi_status_t (EFIAPI *bs_crc32)(const void *data, efi_uintn_t data_size,
+ u32 *crc32);
+
+static int check_table(const void *table)
+{
+ efi_status_t ret;
+ u32 crc32, res;
+ /* Casting from const to not const */
+ struct efi_table_hdr *hdr = (struct efi_table_hdr *)table;
+
+ if (!hdr->signature) {
+ efi_st_error("Missing header signature\n");
+ return EFI_ST_FAILURE;
+ }
+ if (!hdr->revision) {
+ efi_st_error("Missing header revision\n");
+ return EFI_ST_FAILURE;
+ }
+ if (hdr->headersize <= sizeof(struct efi_table_hdr)) {
+ efi_st_error("Incorrect headersize value\n");
+ return EFI_ST_FAILURE;
+ }
+ if (hdr->reserved) {
+ efi_st_error("Reserved header field is not zero\n");
+ return EFI_ST_FAILURE;
+ }
+
+ crc32 = hdr->crc32;
+ /*
+* Setting the crc32 of the 'const' table to zero is easier than
+* copying
+*/
+ hdr->crc32 = 0;
+ ret = bs_crc32(table, hdr->headersize, );
+ /* Reset table crc32 so it stays constant */
+ hdr->crc32 = crc32;
+ if (ret != EFI_ST_SUCCESS) {
+ efi_st_error("CalculateCrc32 failed\n");
+ return EFI_ST_FAILURE;
+ }
+ if (res != crc32) {
+ efi_st_error("Incorrect CRC32\n");
+ // return EFI_ST_FAILURE;
+ }
+ return EFI_ST_SUCCESS;
+}
+
+/*
+ * Setup unit test.
+ *
+ * Check that CalculateCrc32 is working correctly.
+ * Check tables before ExitBootServices().
+ *
+ * @handle:handle of the loaded image
+ * @systable: system table
+ * @return:EFI_ST_SUCCESS for success
+ */
+static int setup(const efi_handle_t handle,
+const struct efi_system_table *systable)
+{
+ efi_status_t ret;
+ u32 res;
+
+ st = systable;
+ bs_crc32 = systable->boottime->calculate_crc32;
+
+ /* Check that CalculateCrc32 is working */
+ ret = bs_crc32("U-Boot", 6, );
+ if (ret != EFI_ST_SUCCESS) {
+ efi_st_error("CalculateCrc32 failed\n");
+ return EFI_ST_FAILURE;
+ }
+ if (res != 0x134b0db4) {
+ efi_st_error("Incorrect CRC32\n");
+ return EFI_ST_FAILURE;
+ }
+
+ /* Check tables before ExitBootServices() */
+ if (check_table(st) != EFI_ST_SUCCESS) {
+ efi_st_error("Checking system table\n");
+ return EFI_ST_FAILURE;
+ }
+ if (check_table(st->boottime) != EFI_ST_SUCCESS) {
+ efi_st_error("Checking boottime table\n");
+ return EFI_ST_FAILURE;
+ }
+ if (check_table(st->runtime) != EFI_ST_SUCCESS) {
+ efi_st_error("Checking runtime table\n");
+ return EFI_ST_FAILURE;
+ }
+
+ return EFI_ST_SUCCESS;
+}
+
+/*
+ * Execute unit test
+ *
+ * Check tables after ExitBootServices()
+ *
+ * @return:EFI_ST_SUCCESS for success
+ */
+static int execute(void)
+{
+ if (check_table(st) != EFI_ST_SUCCESS) {
+ efi_st_error("Checking system table\n");
+ return EFI_ST_FAILURE;
+ }
+ if (check_table(st->runtime) != EFI_ST_SUCCESS) {
+ efi_st_error("Checking runtime table\n");
+ return EFI_ST_FAILURE;
+ }
+
+ /*
+* We cannot call SetVirtualAddressMap() and recheck the
[U-Boot] [PATCH v2 1/3] efi_loader: correctly initialize system table crc32
We should calculate the crc32 after initalizing all fields of the system table. Signed-off-by: Heinrich Schuchardt --- v2: no change --- cmd/bootefi.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/cmd/bootefi.c b/cmd/bootefi.c index b60c151fb4..1bf75e2bba 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -44,11 +44,6 @@ efi_status_t efi_init_obj_list(void) if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED) return efi_obj_list_initialized; - /* Initialize system table */ - ret = efi_initialize_system_table(); - if (ret != EFI_SUCCESS) - goto out; - /* Initialize EFI driver uclass */ ret = efi_driver_init(); if (ret != EFI_SUCCESS) @@ -91,6 +86,11 @@ efi_status_t efi_init_obj_list(void) if (ret != EFI_SUCCESS) goto out; + /* Initialize system table */ + ret = efi_initialize_system_table(); + if (ret != EFI_SUCCESS) + goto out; + out: efi_obj_list_initialized = ret; return ret; -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] efi_loader: correct signature of CalculateCrc32()
Use const for the buffer. We are not changing the buffer.
Use efi_uintn_t where prescribed by the UEFI spec.
Prefer u32 over uint32_t.
Signed-off-by: Heinrich Schuchardt
---
v2:
avoid a warning in a debug statement
---
include/efi_api.h | 5 +++--
lib/efi_loader/efi_boottime.c | 8
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/include/efi_api.h b/include/efi_api.h
index c98cc34908..ebf2a3bc18 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -165,8 +165,9 @@ struct efi_boot_services {
void **handle, ...);
efi_status_t (EFIAPI *uninstall_multiple_protocol_interfaces)(
void *handle, ...);
- efi_status_t (EFIAPI *calculate_crc32)(void *data,
- unsigned long data_size, uint32_t *crc32);
+ efi_status_t (EFIAPI *calculate_crc32)(const void *data,
+ efi_uintn_t data_size,
+ u32 *crc32);
void (EFIAPI *copy_mem)(void *destination, const void *source,
size_t length);
void (EFIAPI *set_mem)(void *buffer, size_t size, uint8_t value);
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 9ac8e18680..3689cebf8f 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -2418,11 +2418,11 @@ static efi_status_t EFIAPI
efi_uninstall_multiple_protocol_interfaces(
* @crc32_p: cyclic redundancy code
* Return Value: status code
*/
-static efi_status_t EFIAPI efi_calculate_crc32(void *data,
- unsigned long data_size,
- uint32_t *crc32_p)
+static efi_status_t EFIAPI efi_calculate_crc32(const void *data,
+ efi_uintn_t data_size,
+ u32 *crc32_p)
{
- EFI_ENTRY("%p, %ld", data, data_size);
+ EFI_ENTRY("%p, %zu", data, data_size);
*crc32_p = crc32(0, data, data_size);
return EFI_EXIT(EFI_SUCCESS);
}
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size
On Sat, May 19, 2018 at 02:08:53PM +0200, Dr. Philipp Tomsich wrote: > Marty, > > > On 19 May 2018, at 12:40, Marty E. Plummer wrote: > > > > So explain to me what you'd like me to do here, if you would. What I > > gather from this is you want me to flip CONFIG_PHYS_64BIT and see if it > > works or what? I can flash/reflash u-boot and coreboot pretty easily on > > the device, so I'm down for any sort of hardware testing needed to get > > this into a usable state. > > Yes, just enable PHYS_64BIT and report on how far it goes (activating some > debug may be helpful to understand what goes wrong, if it fails). > > My gut feeling is that it could work, but there’s a number of pitfalls and we > may > not be lucky. > Testing flipping CONFIG_PHYS_64BIT, both with and without my 'clamping' patch to sdram_common.c, has the same results, in that all that is output on the servo console is that wierd output. Where to from here, then? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 0/5] drivers: Add reset ctrl to drivers
On Thu, Jun 14, 2018 at 6:45 PM, Ley Foon Tan wrote: > Add reset ctrl to dwmmc socfpga, designware Ethernet and ns16550 serial > drivers. > > A reset property is an optional feature, so only print out a warning and > do not fail if a reset property is not present. > > If a reset property is discovered, then use it to deassert, thus bringing the > IP out of reset. > > v6: > - Include change history to patches and cover letter > - Added Joe's Acked-by in designware emac patch. > > v5: https://patchwork.ozlabs.org/cover/924857/ > - Rename CONFIG_SPL_RESET_SUPPORT to CONFIG_SPL_DM_RESET > - Change to use CONFIG_IS_ENABLED(DM_RESET) in reset.h > - Added Simon's Reviewed-by in dwmmc, 16550 serial and designware emac > patches. > > v4: https://patchwork.ozlabs.org/cover/923883/ > - Add patch to check CONFIG_SPL_RESET_SUPPORT in reset.h > > v3: https://patchwork.ozlabs.org/cover/910018/ > - remove #ifdef CONFIG_DM_RESET switch > - add maintainer emails > > v2: https://patchwork.ozlabs.org/cover/908667/ > - remove 'return' in designware emac driver > - keep reset control in socfpga_dw_mmc.c because it didn't call to common > dwmmc probe > function when in SPL. > - add reviewed-by in ns16550 patch > > v1: https://patchwork.ozlabs.org/cover/905519/ > > Ley Foon Tan (5): > reset: Rename CONFIG_SPL_RESET_SUPPORT to CONFIG_SPL_DM_RESET > include: reset: Change to use CONFIG_IS_ENABLED(DM_RESET) > mmc: dwmmc: socfpga: Add reset ctrl to driver > serial: ns16550: Add reset ctrl to driver > net: designware: Add reset ctrl to driver > > arch/arm/mach-stm32mp/Kconfig | 2 +- > common/spl/Kconfig| 2 +- > drivers/Makefile | 2 +- > drivers/mmc/socfpga_dw_mmc.c | 17 + > drivers/net/designware.c | 8 > drivers/serial/ns16550.c | 8 > include/reset.h | 2 +- > 7 files changed, 37 insertions(+), 4 deletions(-) > > -- > 2.2.2 > Hi Tom Can help to merge this series of patches? Thanks. Regards Ley Foon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3] spi: cadence_qspi: Fix compilation warning
Use "%zu" for size_t data type.
Compilation warning as below:
In file included from include/linux/bug.h:7:0,
from include/common.h:26,
from drivers/spi/cadence_qspi.c:8:
drivers/spi/cadence_qspi.c: In function ‘cadence_spi_xfer’:
drivers/spi/cadence_qspi.c:211:8: warning: format ‘%d’ expects argument of type
‘int’, but argument 3 has type ‘size_t {aka long unsigned int}’ [-Wformat=]
debug("%s: len=%d [bytes]\n", __func__, data_bytes);
^
include/linux/printk.h:37:21: note: in definition of macro ‘pr_fmt’
#define pr_fmt(fmt) fmt
^~~
include/log.h:142:2: note: in expansion of macro ‘debug_cond’
debug_cond(_DEBUG, fmt, ##args)
^~
drivers/spi/cadence_qspi.c:211:2: note: in expansion of macro ‘debug’
debug("%s: len=%d [bytes]\n", __func__, data_bytes);
Signed-off-by: Ley Foon Tan
Acked-by: Marek Vasut
---
v1: Cast data_byte to integet
v2: Use "%lu"
v3: Still have compilation warning with "%lu" in Cyclone V build.
So, change to use "%zu" for size_t type.
---
drivers/spi/cadence_qspi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 91742ba..29db6fa 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -207,7 +207,7 @@ static int cadence_spi_xfer(struct udevice *dev, unsigned
int bitlen,
} else {
data_bytes = bitlen / 8;
}
- debug("%s: len=%d [bytes]\n", __func__, data_bytes);
+ debug("%s: len=%zu [bytes]\n", __func__, data_bytes);
/* Set Chip select */
cadence_qspi_apb_chipselect(base, spi_chip_select(dev),
--
2.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] imx: i.mx6q: imx6q_logic: Migrate to SPL and enable SDP
Since the vast majority of i.MX6 boards are migrating to SPL,
this patch converts im6q_logic to SPL and enables the SDP for
loading SPL and u-boot.img over USB. The Falcon mode only
supports NAND flash as of now due to limited space/RAM, but
all i.MX6D/Q SOM's from Logic PD have internal NAND from which
to boot.
Signed-off-by: Adam Ford
diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index 521fad74b5..524631b32c 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -198,6 +198,8 @@ config TARGET_MX6CUBOXI
config TARGET_MX6LOGICPD
bool "Logic PD i.MX6 SOM"
+ select MX6Q
+ select SUPPORT_SPL
select BOARD_EARLY_INIT_F
select BOARD_LATE_INIT
select DM
@@ -206,7 +208,6 @@ config TARGET_MX6LOGICPD
select DM_I2C
select DM_MMC
select DM_PMIC
- select DM_REGULATOR
select OF_CONTROL
config TARGET_MX6MEMCAL
diff --git a/board/logicpd/imx6/imx6logic.c b/board/logicpd/imx6/imx6logic.c
index 84405635a5..ce1c8a5d6b 100644
--- a/board/logicpd/imx6/imx6logic.c
+++ b/board/logicpd/imx6/imx6logic.c
@@ -182,3 +182,144 @@ int board_late_init(void)
return 0;
}
+
+#ifdef CONFIG_SPL_BUILD
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_SPL_OS_BOOT
+int spl_start_uboot(void)
+{
+ /* break into full u-boot on 'c' */
+ if (serial_tstc() && serial_getc() == 'c')
+ return 1;
+
+ return 0;
+}
+#endif
+
+static void ccgr_init(void)
+{
+ struct mxc_ccm_reg *ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+
+ writel(0x00C03F3F, >CCGR0);
+ writel(0x0030FC03, >CCGR1);
+ writel(0x0FFFC000, >CCGR2);
+ writel(0x3FF0, >CCGR3);
+ writel(0xF300, >CCGR4);
+ writel(0x0FF3, >CCGR5);
+ writel(0x0FFF, >CCGR6);
+}
+
+static int mx6q_dcd_table[] = {
+ MX6_IOM_GRP_DDR_TYPE, 0x000C,
+ MX6_IOM_GRP_DDRPKE, 0x,
+ MX6_IOM_DRAM_SDCLK_0, 0x0030,
+ MX6_IOM_DRAM_SDCLK_1, 0x0030,
+ MX6_IOM_DRAM_CAS, 0x0030,
+ MX6_IOM_DRAM_RAS, 0x0030,
+ MX6_IOM_GRP_ADDDS, 0x0030,
+ MX6_IOM_DRAM_RESET, 0x0030,
+ MX6_IOM_DRAM_SDBA2, 0x,
+ MX6_IOM_DRAM_SDODT0, 0x0030,
+ MX6_IOM_DRAM_SDODT1, 0x0030,
+ MX6_IOM_GRP_CTLDS, 0x0030,
+ MX6_IOM_DDRMODE_CTL, 0x0002,
+ MX6_IOM_DRAM_SDQS0, 0x0030,
+ MX6_IOM_DRAM_SDQS1, 0x0030,
+ MX6_IOM_DRAM_SDQS2, 0x0030,
+ MX6_IOM_DRAM_SDQS3, 0x0030,
+ MX6_IOM_GRP_DDRMODE, 0x0002,
+ MX6_IOM_GRP_B0DS, 0x0030,
+ MX6_IOM_GRP_B1DS, 0x0030,
+ MX6_IOM_GRP_B2DS, 0x0030,
+ MX6_IOM_GRP_B3DS, 0x0030,
+ MX6_IOM_DRAM_DQM0, 0x0030,
+ MX6_IOM_DRAM_DQM1, 0x0030,
+ MX6_IOM_DRAM_DQM2, 0x0030,
+ MX6_IOM_DRAM_DQM3, 0x0030,
+ MX6_MMDC_P0_MDSCR, 0x8000,
+ MX6_MMDC_P0_MPZQHWCTRL, 0xA1390003,
+ MX6_MMDC_P0_MPWLDECTRL0, 0x002D003A,
+ MX6_MMDC_P0_MPWLDECTRL1, 0x0038002B,
+ MX6_MMDC_P0_MPDGCTRL0, 0x03340338,
+ MX6_MMDC_P0_MPDGCTRL1, 0x0334032C,
+ MX6_MMDC_P0_MPRDDLCTL, 0x4036383C,
+ MX6_MMDC_P0_MPWRDLCTL, 0x2E384038,
+ MX6_MMDC_P0_MPRDDQBY0DL, 0x,
+ MX6_MMDC_P0_MPRDDQBY1DL, 0x,
+ MX6_MMDC_P0_MPRDDQBY2DL, 0x,
+ MX6_MMDC_P0_MPRDDQBY3DL, 0x,
+ MX6_MMDC_P0_MPMUR0, 0x0800,
+ MX6_MMDC_P0_MDPDC, 0x00020036,
+ MX6_MMDC_P0_MDOTC, 0x09444040,
+ MX6_MMDC_P0_MDCFG0, 0xB8BE7955,
+ MX6_MMDC_P0_MDCFG1, 0xFF328F64,
+ MX6_MMDC_P0_MDCFG2, 0x01FF00DB,
+ MX6_MMDC_P0_MDMISC, 0x00011740,
+ MX6_MMDC_P0_MDSCR, 0x8000,
+ MX6_MMDC_P0_MDRWD, 0x26D2,
+ MX6_MMDC_P0_MDOR, 0x00BE1023,
+ MX6_MMDC_P0_MDASP, 0x0047,
+ MX6_MMDC_P0_MDCTL, 0x8519,
+ MX6_MMDC_P0_MDSCR, 0x00888032,
+ MX6_MMDC_P0_MDSCR, 0x8033,
+ MX6_MMDC_P0_MDSCR, 0x8031,
+ MX6_MMDC_P0_MDSCR, 0x19408030,
+ MX6_MMDC_P0_MDSCR, 0x04008040,
+ MX6_MMDC_P0_MDREF, 0x7800,
+ MX6_MMDC_P0_MPODTCTRL, 0x0007,
+ MX6_MMDC_P0_MDPDC, 0x00025576,
+ MX6_MMDC_P0_MAPSR, 0x00011006,
+ MX6_MMDC_P0_MDSCR, 0x,
+ /* enable AXI cache for VDOA/VPU/IPU */
+
+ MX6_IOMUXC_GPR4, 0xF0CF,
+ /* set IPU AXI-id0 Qos=0xf(bypass) AXI-id1 Qos=0x7 */
+ MX6_IOMUXC_GPR6, 0x007F007F,
+ MX6_IOMUXC_GPR7, 0x007F007F,
+};
+
+static void ddr_init(int *table, int size)
+{
+ int i;
+
+ for (i = 0; i < size / 2 ; i++)
+ writel(table[2 * i + 1], table[2 * i]);
+}
+
+static void spl_dram_init(void)
+{
+ if (is_mx6dq())
+ ddr_init(mx6q_dcd_table, ARRAY_SIZE(mx6q_dcd_table));
+}
+
+void board_init_f(ulong dummy)
+{
+ /* DDR initialization */
+ spl_dram_init();
+
+ /* setup AIPS and disable watchdog */
+
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On 7/5/2018 6:10 PM, Marek Vasut wrote: > On 07/06/2018 01:11 AM, Jason Rush wrote: >> On 7/4/2018 2:23 AM, Marek Vasut wrote: >>> On 07/04/2018 01:45 AM, Jason Rush wrote: On 7/3/2018 9:08 AM, Marek Vasut wrote: > On 07/03/2018 03:58 PM, Jason Rush wrote: >> On 6/29/2018 10:17 AM, Marek Vasut wrote: >>> On 06/29/2018 05:06 PM, Jason Rush wrote: On 6/29/2018 9:52 AM, Marek Vasut wrote: > On 06/29/2018 04:44 PM, Jason Rush wrote: >> On 6/29/2018 9:34 AM, Marek Vasut wrote: >>> On 06/29/2018 04:31 PM, Jason Rush wrote: Dinh, >>> Hi, >>> A while ago, you posted the following patchset for SoCFPGA to add the PL330 DMA driver, and updated the SoCFPGA SDRAM init to write zeros to SDRAM to initialize the ECC bits if ECC was enabled: https://lists.denx.de/pipermail/u-boot/2016-October/269643.html I know it's been a long time, so I'll summarize some of the conversation... At the time, you had a problem with the patchset causing the SPL to fail to find the MMC. You had tracked it down to an issue with the following commit "a78cd8613204 ARM: Rework and correct barrier definitions". You and Marek discussed it a bit, but I don't think there was a real conclusion. You submitted a second version of the patchset asking for advice on debugging the issue: https://lists.denx.de/pipermail/u-boot/2016-December/275822.html No real conversation came from the second patchset, and that was the end of the patch. I was hoping we could revisit adding your patchset again. I am working on a custom SoCFPGA board with a Cyclone V and ECC SDRAM. I rebased your patchset against v2018.05 and it is working on my custom board (although I don't have an MMC). I also tested it on a SoCKit booting from an MMC (I forced it to scrub the SDRAM on the SoCKit, because it doesn't have ECC RAM), and the SoCKit finds the MMC and boots. I don't have any suggestions on why it is working now on my board and not back when you first submitted the patchset. Maybe something else was fixed in the MMC? I was hoping you and Marek could test this patch again on some different SoCFPGA boards to see if you get the same results. >>> Look at this patch >>> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=commit;h=9bb8a249b292d26f152c20e3641600b3d7b3924b >>> >>> You likely want similar approach, it's faster then the DMA and much >>> simpler. >>> >> Thanks Marek. I'll give it a try. Would you be interested in a >> similar patch for the Gen 5? > I don't have any Gen5 board which uses ECC, do you ? > If so, yes, prepare a patch, it should be very similar. > > Make sure to measure how long it takes to scrub the memory and how > much > memory you have, I'd be interested in the numbers. > Looking at the master branch, it doesn't look like that code is ever being called? The sdram_init_ecc_bits() function is called from the ddr_calibration_sequence function(), but I can't find where ddr_calibration_sequence is called(). >>> git grep for it, it's called from somewhere in the >>> arch/arm/mach-socfpga/ >>> Either way, I can test it. I have a custom Cyclone V board with ECC, and the Intel Arria V SoC Dev Kit I can test it on too which I think has ECC. >>> Please do. >>> >> I implemented a similar memset approach for the gen 5 socfpga. It's >> basically the same >> code as in that patch; however, when I performed a single memset the >> processor would >> reset for some reason. I changed it to loop over calling memset with a >> size of 32MB over >> the entire address the address, and that worked as opposed to doing a >> single memset on >> the RAM. > Can you do grep MEMSET .config in your U-Boot build dir ? The arch > memset is implemented in assembler and doesn't trigger WDT , so if it > takes too long, it could be that the WDT resets the platform. Both CONFIG_USE_ARCH_MEMSET and CONFIG_SPL_USE_ARCH_MEMSET are set in my .config, so it must be the WDT triggering as you suspect. >> I started on a SoCKit because it was handy, I know it doesn't have ECC > It doesn't by default.
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On 07/06/2018 01:11 AM, Jason Rush wrote: > On 7/4/2018 2:23 AM, Marek Vasut wrote: >> On 07/04/2018 01:45 AM, Jason Rush wrote: >>> On 7/3/2018 9:08 AM, Marek Vasut wrote: On 07/03/2018 03:58 PM, Jason Rush wrote: > On 6/29/2018 10:17 AM, Marek Vasut wrote: >> On 06/29/2018 05:06 PM, Jason Rush wrote: >>> On 6/29/2018 9:52 AM, Marek Vasut wrote: On 06/29/2018 04:44 PM, Jason Rush wrote: > On 6/29/2018 9:34 AM, Marek Vasut wrote: >> On 06/29/2018 04:31 PM, Jason Rush wrote: >>> Dinh, >> Hi, >> >>> A while ago, you posted the following patchset for SoCFPGA to add >>> the PL330 >>> DMA driver, and updated the SoCFPGA SDRAM init to write zeros to >>> SDRAM to >>> initialize the ECC bits if ECC was enabled: >>> >>> https://lists.denx.de/pipermail/u-boot/2016-October/269643.html >>> >>> I know it's been a long time, so I'll summarize some of the >>> conversation... >>> >>> At the time, you had a problem with the patchset causing the SPL to >>> fail to >>> find the MMC. You had tracked it down to an issue with the >>> following commit >>> "a78cd8613204 ARM: Rework and correct barrier definitions". You >>> and Marek >>> discussed it a bit, but I don't think there was a real conclusion. >>> You >>> submitted a second version of the patchset asking for advice on >>> debugging >>> the issue: >>> >>> https://lists.denx.de/pipermail/u-boot/2016-December/275822.html >>> >>> No real conversation came from the second patchset, and that was >>> the end of >>> the patch. >>> >>> I was hoping we could revisit adding your patchset again. I am >>> working on a >>> custom SoCFPGA board with a Cyclone V and ECC SDRAM. I rebased your >>> patchset >>> against v2018.05 and it is working on my custom board (although I >>> don't have >>> an MMC). I also tested it on a SoCKit booting from an MMC (I forced >>> it to >>> scrub the SDRAM on the SoCKit, because it doesn't have ECC RAM), >>> and the >>> SoCKit finds the MMC and boots. >>> >>> I don't have any suggestions on why it is working now on my board >>> and not >>> back when you first submitted the patchset. Maybe something else >>> was fixed >>> in the MMC? I was hoping you and Marek could test this patch again >>> on some >>> different SoCFPGA boards to see if you get the same results. >> Look at this patch >> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=commit;h=9bb8a249b292d26f152c20e3641600b3d7b3924b >> >> You likely want similar approach, it's faster then the DMA and much >> simpler. >> > Thanks Marek. I'll give it a try. Would you be interested in a > similar patch for the Gen 5? I don't have any Gen5 board which uses ECC, do you ? If so, yes, prepare a patch, it should be very similar. Make sure to measure how long it takes to scrub the memory and how much memory you have, I'd be interested in the numbers. >>> Looking at the master branch, it doesn't look like that code is ever >>> being called? >>> The sdram_init_ecc_bits() function is called from the >>> ddr_calibration_sequence function(), >>> but I can't find where ddr_calibration_sequence is called(). >> git grep for it, it's called from somewhere in the arch/arm/mach-socfpga/ >> >>> Either way, I can test it. I have a custom Cyclone V board with ECC, >>> and the Intel Arria V SoC >>> Dev Kit I can test it on too which I think has ECC. >> Please do. >> > I implemented a similar memset approach for the gen 5 socfpga. It's > basically the same > code as in that patch; however, when I performed a single memset the > processor would > reset for some reason. I changed it to loop over calling memset with a > size of 32MB over > the entire address the address, and that worked as opposed to doing a > single memset on > the RAM. Can you do grep MEMSET .config in your U-Boot build dir ? The arch memset is implemented in assembler and doesn't trigger WDT , so if it takes too long, it could be that the WDT resets the platform. >>> Both CONFIG_USE_ARCH_MEMSET and CONFIG_SPL_USE_ARCH_MEMSET >>> are set in my .config, so it must be the WDT triggering as you suspect. >>> > I started on a SoCKit because it was handy, I know it doesn't have ECC It doesn't by default. > , but I forced it to > initialize the RAM as a quick test. It seems much slower than the DMA > approach. It > should be noted, I didn't
Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing
On 7/4/2018 2:23 AM, Marek Vasut wrote: > On 07/04/2018 01:45 AM, Jason Rush wrote: >> On 7/3/2018 9:08 AM, Marek Vasut wrote: >>> On 07/03/2018 03:58 PM, Jason Rush wrote: On 6/29/2018 10:17 AM, Marek Vasut wrote: > On 06/29/2018 05:06 PM, Jason Rush wrote: >> On 6/29/2018 9:52 AM, Marek Vasut wrote: >>> On 06/29/2018 04:44 PM, Jason Rush wrote: On 6/29/2018 9:34 AM, Marek Vasut wrote: > On 06/29/2018 04:31 PM, Jason Rush wrote: >> Dinh, > Hi, > >> A while ago, you posted the following patchset for SoCFPGA to add >> the PL330 >> DMA driver, and updated the SoCFPGA SDRAM init to write zeros to >> SDRAM to >> initialize the ECC bits if ECC was enabled: >> >> https://lists.denx.de/pipermail/u-boot/2016-October/269643.html >> >> I know it's been a long time, so I'll summarize some of the >> conversation... >> >> At the time, you had a problem with the patchset causing the SPL to >> fail to >> find the MMC. You had tracked it down to an issue with the >> following commit >> "a78cd8613204 ARM: Rework and correct barrier definitions". You and >> Marek >> discussed it a bit, but I don't think there was a real conclusion. >> You >> submitted a second version of the patchset asking for advice on >> debugging >> the issue: >> >> https://lists.denx.de/pipermail/u-boot/2016-December/275822.html >> >> No real conversation came from the second patchset, and that was the >> end of >> the patch. >> >> I was hoping we could revisit adding your patchset again. I am >> working on a >> custom SoCFPGA board with a Cyclone V and ECC SDRAM. I rebased your >> patchset >> against v2018.05 and it is working on my custom board (although I >> don't have >> an MMC). I also tested it on a SoCKit booting from an MMC (I forced >> it to >> scrub the SDRAM on the SoCKit, because it doesn't have ECC RAM), and >> the >> SoCKit finds the MMC and boots. >> >> I don't have any suggestions on why it is working now on my board >> and not >> back when you first submitted the patchset. Maybe something else >> was fixed >> in the MMC? I was hoping you and Marek could test this patch again >> on some >> different SoCFPGA boards to see if you get the same results. > Look at this patch > http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=commit;h=9bb8a249b292d26f152c20e3641600b3d7b3924b > > You likely want similar approach, it's faster then the DMA and much > simpler. > Thanks Marek. I'll give it a try. Would you be interested in a similar patch for the Gen 5? >>> I don't have any Gen5 board which uses ECC, do you ? >>> If so, yes, prepare a patch, it should be very similar. >>> >>> Make sure to measure how long it takes to scrub the memory and how much >>> memory you have, I'd be interested in the numbers. >>> >> Looking at the master branch, it doesn't look like that code is ever >> being called? >> The sdram_init_ecc_bits() function is called from the >> ddr_calibration_sequence function(), >> but I can't find where ddr_calibration_sequence is called(). > git grep for it, it's called from somewhere in the arch/arm/mach-socfpga/ > >> Either way, I can test it. I have a custom Cyclone V board with ECC, and >> the Intel Arria V SoC >> Dev Kit I can test it on too which I think has ECC. > Please do. > I implemented a similar memset approach for the gen 5 socfpga. It's basically the same code as in that patch; however, when I performed a single memset the processor would reset for some reason. I changed it to loop over calling memset with a size of 32MB over the entire address the address, and that worked as opposed to doing a single memset on the RAM. >>> Can you do grep MEMSET .config in your U-Boot build dir ? The arch >>> memset is implemented in assembler and doesn't trigger WDT , so if it >>> takes too long, it could be that the WDT resets the platform. >> Both CONFIG_USE_ARCH_MEMSET and CONFIG_SPL_USE_ARCH_MEMSET >> are set in my .config, so it must be the WDT triggering as you suspect. >> I started on a SoCKit because it was handy, I know it doesn't have ECC >>> It doesn't by default. >>> , but I forced it to initialize the RAM as a quick test. It seems much slower than the DMA approach. It should be noted, I didn't implement any code to time the scrubbing, but rather just roughly monitored the time to get a rough idea of how long it took. On the
Re: [U-Boot] [PATCH v2 4/8] usb: rockchip: implement K_FW_LBA_READ_10 command
Hi Alberto,
> This patch implement reading blocks form selected device with
> LBA addressing.
>
> Corresponding command on workstation is:
> rkdeveloptool rl
>
> While we support reading more than one blocks per K_FW_LBA_READ_10
> request, rkdeveloptool and original rockchip tool do perform
> chunk reads limiting the maximum size per chunk far lower
> than max int values.
>
> Signed-off-by: Alberto Panizzo
> ---
> arch/arm/include/asm/arch-rockchip/f_rockusb.h | 3 +
> doc/README.rockusb | 1 +
> drivers/usb/gadget/f_rockusb.c | 101
> - 3 files changed, 104 insertions(+), 1
> deletion(-)
>
> diff --git a/arch/arm/include/asm/arch-rockchip/f_rockusb.h
> b/arch/arm/include/asm/arch-rockchip/f_rockusb.h index
> 0b62771..3f2e763 100644 ---
> a/arch/arm/include/asm/arch-rockchip/f_rockusb.h +++
> b/arch/arm/include/asm/arch-rockchip/f_rockusb.h @@ -27,6 +27,7 @@
> */
>
> #define RKUSB_BUF_SIZE EP_BUFFER_SIZE * 2
> +#define RKBLOCK_BUF_SIZE 4096
>
> #define RKUSB_STATUS_IDLE0
> #define RKUSB_STATUS_CMD 1
> @@ -120,6 +121,8 @@ struct f_rockusb {
> unsigned int lba;
> unsigned int dl_size;
> unsigned int dl_bytes;
> + unsigned int ul_size;
> + unsigned int ul_bytes;
> struct blk_desc *desc;
> int reboot_flag;
> void *buf;
> diff --git a/doc/README.rockusb b/doc/README.rockusb
> index 3a93edc..7f58296 100644
> --- a/doc/README.rockusb
> +++ b/doc/README.rockusb
> @@ -47,6 +47,7 @@ Current set of rkdeveloptool commands supported:
> - rfi: Read Flash Id
> - rd : Reset Device
> - td : Test Device Ready
> +- rl : Read blocks using LBA
> - wl : Write blocks using LBA
>
> To do
> diff --git a/drivers/usb/gadget/f_rockusb.c
> b/drivers/usb/gadget/f_rockusb.c index 0314ff0..4a62e1b 100644
> --- a/drivers/usb/gadget/f_rockusb.c
> +++ b/drivers/usb/gadget/f_rockusb.c
> @@ -328,6 +328,7 @@ static int rockusb_tx_write(const char *buffer,
> unsigned int buffer_size)
> memcpy(in_req->buf, buffer, buffer_size);
> in_req->length = buffer_size;
> + debug("Transferring 0x%x bytes\n", buffer_size);
> usb_ep_dequeue(rockusb_func->in_ep, in_req);
> ret = usb_ep_queue(rockusb_func->in_ep, in_req, 0);
> if (ret)
> @@ -421,6 +422,78 @@ static unsigned int rx_bytes_expected(struct
> usb_ep *ep) return rx_remain;
> }
>
> +/* usb_request complete call back to handle upload image */
> +static void tx_handler_ul_image(struct usb_ep *ep, struct
> usb_request *req) +{
> + ALLOC_CACHE_ALIGN_BUFFER(char, rbuffer, RKBLOCK_BUF_SIZE);
> + struct f_rockusb *f_rkusb = get_rkusb();
> + struct usb_request *in_req = rockusb_func->in_req;
> + int ret;
> +
> + if (!f_rkusb->desc) {
> + char *type = f_rkusb->dev_type;
> + int index = f_rkusb->dev_index;
> +
> + f_rkusb->desc = blk_get_dev(type, index);
> + if (!f_rkusb->desc ||
> + f_rkusb->desc->type == DEV_TYPE_UNKNOWN) {
> + puts("invalid mmc device\n");
> + rockusb_tx_write_csw(f_rkusb->tag, 0,
> CSW_FAIL,
> + USB_BULK_CS_WRAP_LEN);
> + return;
> + }
> + }
> +
> + /* Print error status of previous transfer */
> + if (req->status)
> + debug("status: %d ep '%s' trans: %d len %d\n",
> req->status,
> + ep->name, req->actual, req->length);
> +
> + /* On transfer complete reset in_req and feedback host with
> CSW_GOOD */
> + if (f_rkusb->ul_bytes >= f_rkusb->ul_size) {
> + in_req->length = 0;
> + in_req->complete = rockusb_complete;
> +
> + rockusb_tx_write_csw(f_rkusb->tag, 0, CSW_GOOD,
> + USB_BULK_CS_WRAP_LEN);
> + return;
> + }
> +
> + /* Proceed with current chunk */
> + unsigned int transfer_size = f_rkusb->ul_size -
> f_rkusb->ul_bytes; +
> + if (transfer_size > RKBLOCK_BUF_SIZE)
> + transfer_size = RKBLOCK_BUF_SIZE;
> + /* Read at least one block */
> + unsigned int blkcount = (transfer_size + 511) / 512;
Could you replace the 512 magic with f_rkusb->desc->blksz ?
> +
> + debug("ul %x bytes, %x blks, read lba %x, ul_size:%x,
> ul_bytes:%x, ",
> + transfer_size, blkcount, f_rkusb->lba,
> + f_rkusb->ul_size, f_rkusb->ul_bytes);
> +
> + int blks = blk_dread(f_rkusb->desc, f_rkusb->lba, blkcount,
> rbuffer); +
> + if (blks != blkcount) {
> + printf("failed reading from device %s: %d\n",
> +f_rkusb->dev_type, f_rkusb->dev_index);
> + rockusb_tx_write_csw(f_rkusb->tag, 0, CSW_FAIL,
> + USB_BULK_CS_WRAP_LEN);
> + return;
> + }
> + f_rkusb->lba += blkcount;
> + f_rkusb->ul_bytes
[U-Boot] [PATCH] kconfig: Avoid format overflow warning from GCC 8.1
cherry-pick kernel commit 2ae89c7 (2018-06-05) to avoid warnings when compiling with GCC 8.1 In file included from scripts/kconfig/zconf.tab.c:2486: scripts/kconfig/confdata.c: In function ‘conf_write’: scripts/kconfig/confdata.c:771:22: warning: ‘%s’ directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=] sprintf(newname, "%s%s", dirname, basename); ^~ scripts/kconfig/confdata.c:771:19: note: assuming directive output of 7 bytes sprintf(newname, "%s%s", dirname, basename); ^~ scripts/kconfig/confdata.c:771:2: note: ‘sprintf’ output 1 or more bytes (assuming 4104) into a destination of size 4097 sprintf(newname, "%s%s", dirname, basename); ^~~ scripts/kconfig/confdata.c:774:23: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=] sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid()); ^~~ scripts/kconfig/confdata.c:774:3: note: ‘sprintf’ output between 13 and 4119 bytes into a destination of size 4097 sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid()); ^~~ Signed-off-by: Luis Araneda --- scripts/kconfig/confdata.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c index e4cbb87d76..a04bb26304 100644 --- a/scripts/kconfig/confdata.c +++ b/scripts/kconfig/confdata.c @@ -743,7 +743,7 @@ int conf_write(const char *name) struct menu *menu; const char *basename; const char *str; - char dirname[PATH_MAX+1], tmpname[PATH_MAX+1], newname[PATH_MAX+1]; + char dirname[PATH_MAX+1], tmpname[PATH_MAX+22], newname[PATH_MAX+8]; char *env; dirname[0] = 0; -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] efi_loader: correct signature of CalculateCrc32()
Use const for the buffer. We are not changing the buffer.
Use efi_uintn_t where prescribed by the UEFI spec.
Prefer u32 over uint32_t.
Signed-off-by: Heinrich Schuchardt
---
include/efi_api.h | 5 +++--
lib/efi_loader/efi_boottime.c | 6 +++---
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/include/efi_api.h b/include/efi_api.h
index c98cc34908..ebf2a3bc18 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -165,8 +165,9 @@ struct efi_boot_services {
void **handle, ...);
efi_status_t (EFIAPI *uninstall_multiple_protocol_interfaces)(
void *handle, ...);
- efi_status_t (EFIAPI *calculate_crc32)(void *data,
- unsigned long data_size, uint32_t *crc32);
+ efi_status_t (EFIAPI *calculate_crc32)(const void *data,
+ efi_uintn_t data_size,
+ u32 *crc32);
void (EFIAPI *copy_mem)(void *destination, const void *source,
size_t length);
void (EFIAPI *set_mem)(void *buffer, size_t size, uint8_t value);
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 9ac8e18680..5a011f0b36 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -2418,9 +2418,9 @@ static efi_status_t EFIAPI
efi_uninstall_multiple_protocol_interfaces(
* @crc32_p: cyclic redundancy code
* Return Value: status code
*/
-static efi_status_t EFIAPI efi_calculate_crc32(void *data,
- unsigned long data_size,
- uint32_t *crc32_p)
+static efi_status_t EFIAPI efi_calculate_crc32(const void *data,
+ efi_uintn_t data_size,
+ u32 *crc32_p)
{
EFI_ENTRY("%p, %ld", data, data_size);
*crc32_p = crc32(0, data, data_size);
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] efi_loader: correctly initialize system table crc32
We should calculate the crc32 after initalizing all fields of the system table. Signed-off-by: Heinrich Schuchardt --- cmd/bootefi.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/cmd/bootefi.c b/cmd/bootefi.c index b60c151fb4..1bf75e2bba 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -44,11 +44,6 @@ efi_status_t efi_init_obj_list(void) if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED) return efi_obj_list_initialized; - /* Initialize system table */ - ret = efi_initialize_system_table(); - if (ret != EFI_SUCCESS) - goto out; - /* Initialize EFI driver uclass */ ret = efi_driver_init(); if (ret != EFI_SUCCESS) @@ -91,6 +86,11 @@ efi_status_t efi_init_obj_list(void) if (ret != EFI_SUCCESS) goto out; + /* Initialize system table */ + ret = efi_initialize_system_table(); + if (ret != EFI_SUCCESS) + goto out; + out: efi_obj_list_initialized = ret; return ret; -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] efi_selftest: unit test for CalculateCrc32()
This unit test checks the CalculateCrc32 bootservice and checks the
headers of the system table, the boot services tablle, and the runtime
services table before and after ExitBootServices().
Signed-off-by: Heinrich Schuchardt
---
lib/efi_selftest/Makefile | 1 +
lib/efi_selftest/efi_selftest_crc32.c | 141 ++
2 files changed, 142 insertions(+)
create mode 100644 lib/efi_selftest/efi_selftest_crc32.c
diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
index d927208700..590f90b16d 100644
--- a/lib/efi_selftest/Makefile
+++ b/lib/efi_selftest/Makefile
@@ -16,6 +16,7 @@ efi_selftest_bitblt.o \
efi_selftest_config_table.o \
efi_selftest_controllers.o \
efi_selftest_console.o \
+efi_selftest_crc32.o \
efi_selftest_devicepath.o \
efi_selftest_devicepath_util.o \
efi_selftest_events.o \
diff --git a/lib/efi_selftest/efi_selftest_crc32.c
b/lib/efi_selftest/efi_selftest_crc32.c
new file mode 100644
index 00..8555b8f114
--- /dev/null
+++ b/lib/efi_selftest/efi_selftest_crc32.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * efi_selftest_crc32
+ *
+ * Copyright (c) 2018 Heinrich Schuchardt
+ *
+ * This unit test checks the CalculateCrc32 bootservice and checks the
+ * headers of the system table, the boot services tablle, and the runtime
+ * services table before and after ExitBootServices().
+ */
+
+#include
+
+const struct efi_system_table *st;
+efi_status_t (EFIAPI *bs_crc32)(const void *data, efi_uintn_t data_size,
+ u32 *crc32);
+
+static int check_table(const void *table)
+{
+ efi_status_t ret;
+ u32 crc32, res;
+ /* Casting from const to not const */
+ struct efi_table_hdr *hdr = (struct efi_table_hdr *)table;
+
+ if (!hdr->signature) {
+ efi_st_error("Missing header signature\n");
+ return EFI_ST_FAILURE;
+ }
+ if (!hdr->revision) {
+ efi_st_error("Missing header revision\n");
+ return EFI_ST_FAILURE;
+ }
+ if (hdr->headersize <= sizeof(struct efi_table_hdr)) {
+ efi_st_error("Incorrect headersize value\n");
+ return EFI_ST_FAILURE;
+ }
+ if (hdr->reserved) {
+ efi_st_error("Reserved header field is not zero\n");
+ return EFI_ST_FAILURE;
+ }
+
+ crc32 = hdr->crc32;
+ /*
+* Setting the crc32 of the 'const' table to zero is easier than
+* copying
+*/
+ hdr->crc32 = 0;
+ ret = bs_crc32(table, hdr->headersize, );
+ /* Reset table crc32 so it stays constant */
+ hdr->crc32 = crc32;
+ if (ret != EFI_ST_SUCCESS) {
+ efi_st_error("CalculateCrc32 failed\n");
+ return EFI_ST_FAILURE;
+ }
+ if (res != crc32) {
+ efi_st_error("Incorrect CRC32\n");
+ // return EFI_ST_FAILURE;
+ }
+ return EFI_ST_SUCCESS;
+}
+
+/*
+ * Setup unit test.
+ *
+ * Check that CalculateCrc32 is working correctly.
+ * Check tables before ExitBootServices().
+ *
+ * @handle:handle of the loaded image
+ * @systable: system table
+ * @return:EFI_ST_SUCCESS for success
+ */
+static int setup(const efi_handle_t handle,
+const struct efi_system_table *systable)
+{
+ efi_status_t ret;
+ u32 res;
+
+ st = systable;
+ bs_crc32 = systable->boottime->calculate_crc32;
+
+ /* Check that CalculateCrc32 is working */
+ ret = bs_crc32("U-Boot", 6, );
+ if (ret != EFI_ST_SUCCESS) {
+ efi_st_error("CalculateCrc32 failed\n");
+ return EFI_ST_FAILURE;
+ }
+ if (res != 0x134b0db4) {
+ efi_st_error("Incorrect CRC32\n");
+ return EFI_ST_FAILURE;
+ }
+
+ /* Check tables before ExitBootServices() */
+ if (check_table(st) != EFI_ST_SUCCESS) {
+ efi_st_error("Checking system table\n");
+ return EFI_ST_FAILURE;
+ }
+ if (check_table(st->boottime) != EFI_ST_SUCCESS) {
+ efi_st_error("Checking boottime table\n");
+ return EFI_ST_FAILURE;
+ }
+ if (check_table(st->runtime) != EFI_ST_SUCCESS) {
+ efi_st_error("Checking runtime table\n");
+ return EFI_ST_FAILURE;
+ }
+
+ return EFI_ST_SUCCESS;
+}
+
+/*
+ * Execute unit test
+ *
+ * Check tables after ExitBootServices()
+ *
+ * @return:EFI_ST_SUCCESS for success
+ */
+static int execute(void)
+{
+ if (check_table(st) != EFI_ST_SUCCESS) {
+ efi_st_error("Checking system table\n");
+ return EFI_ST_FAILURE;
+ }
+ if (check_table(st->runtime) != EFI_ST_SUCCESS) {
+ efi_st_error("Checking runtime table\n");
+ return EFI_ST_FAILURE;
+ }
+
+ /*
+* We cannot call SetVirtualAddressMap() and recheck the runtime
+* table
[U-Boot] [PATCH 0/3] efi_loader: correctly initialize system table crc32
The crc32 of the system table has to be calculated after all fields have been set. Adjust the signature of CalculateCrc32(). Provide a unit test that checks the crc of the system table, the runtime services table, and the boot sevices table before and after ExitBootServices(). Heinrich Schuchardt (3): efi_loader: correctly initialize system table crc32 efi_loader: correct signature of CalculateCrc32() efi_selftest: unit test for CalculateCrc32() cmd/bootefi.c | 10 +- include/efi_api.h | 4 +- lib/efi_loader/efi_boottime.c | 6 +- lib/efi_selftest/Makefile | 1 + lib/efi_selftest/efi_selftest_crc32.c | 141 ++ 5 files changed, 152 insertions(+), 10 deletions(-) create mode 100644 lib/efi_selftest/efi_selftest_crc32.c -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [BUG] efi_loader: efi_set_virtual_address_map() does not support runtime drivers
The function efi_set_virtual_address_map() is left after hitting the first EFI_RUNTIME_SERVICES_CODE to relocate. But if EFI runtime drivers have been loaded into U-Boot there will be multiple such blocks. SetVirtualAddressMap() as described in the UEFI spec is rather complex to implement. It involves runtime drivers updating the pointers they hold upon an event they receive and the firmware reapplying the relocation information provided when loading the images of the runtime drivers. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.Reset()
Implement the reset service of the EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.
This should resolve the error reported by the SCT in
Protocol/SimpleTextOut/BlackBoxTest/SimpleTextOutBBTestFunction_uefi.c:639
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_console.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 3fd0d2fd51..b487288785 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -105,14 +105,6 @@ static int term_read_reply(int *n, int num, char end_char)
return 0;
}
-static efi_status_t EFIAPI efi_cout_reset(
- struct efi_simple_text_output_protocol *this,
- char extended_verification)
-{
- EFI_ENTRY("%p, %d", this, extended_verification);
- return EFI_EXIT(EFI_UNSUPPORTED);
-}
-
static efi_status_t EFIAPI efi_cout_output_string(
struct efi_simple_text_output_protocol *this,
const efi_string_t string)
@@ -341,6 +333,20 @@ static efi_status_t EFIAPI efi_cout_clear_screen(
return EFI_EXIT(EFI_SUCCESS);
}
+static efi_status_t EFIAPI efi_cout_reset(
+ struct efi_simple_text_output_protocol *this,
+ char extended_verification)
+{
+ EFI_ENTRY("%p, %d", this, extended_verification);
+
+ /* Clear screen */
+ EFI_CALL(efi_cout_clear_screen(this));
+ /* Set default colors */
+ printf(ESC "[0;37;40m");
+
+ return EFI_EXIT(EFI_SUCCESS);
+}
+
static efi_status_t EFIAPI efi_cout_set_cursor_position(
struct efi_simple_text_output_protocol *this,
unsigned long column, unsigned long row)
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] MAINTAINERS: assign lib/charset.c
lib/charset.c is only used by the EFI subsystem. Signed-off-by: Heinrich Schuchardt --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index b2c9717cb7..2aef214ea0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -348,6 +348,7 @@ F: doc/README.iscsi F: include/efi* F: include/pe.h F: include/asm-generic/pe.h +F: lib/charset.c F: lib/efi*/ F: test/py/tests/test_efi* F: cmd/bootefi.c -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: rename utf16_strlen, utf16_strnlen
The function names utf16_strlen() and utf16_strnlen() are misnomers.
The functions do not count utf-16 characters but non-zero words.
So let's rename them to u16_strlen and u16_strnlen().
In utf16_dup() avoid assignment in if clause.
Signed-off-by: Heinrich Schuchardt
---
include/charset.h | 29 -
lib/charset.c | 10 +++---
lib/efi_loader/efi_bootmgr.c | 2 +-
lib/efi_loader/efi_console.c | 2 +-
lib/efi_loader/efi_file.c | 2 +-
lib/efi_loader/efi_variable.c | 2 +-
lib/vsprintf.c| 2 +-
7 files changed, 24 insertions(+), 25 deletions(-)
diff --git a/include/charset.h b/include/charset.h
index 11832cbd12..be6e6fe2c7 100644
--- a/include/charset.h
+++ b/include/charset.h
@@ -12,30 +12,25 @@
#define MAX_UTF8_PER_UTF16 3
+size_t u16_strlen(const u16 *in);
/**
- * utf16_strlen() - Get the length of an utf16 string
+ * u16_strlen - count non-zero words
*
- * Returns the number of 16 bit characters in an utf16 string, not
- * including the terminating NULL character.
- *
- * @in the string to measure
- * @return the string length
+ * @in:utf-16 string
+ * ReturnValue:number of non-zero words.
+ * This is not the number of utf-16 letters!
*/
-size_t utf16_strlen(const uint16_t *in);
+size_t u16_strlen(const u16 *in);
/**
- * utf16_strnlen() - Get the length of a fixed-size utf16 string.
- *
- * Returns the number of 16 bit characters in an utf16 string,
- * not including the terminating NULL character, but at most
- * 'count' number of characters. In doing this, utf16_strnlen()
- * looks at only the first 'count' characters.
+ * u16_strlen - count non-zero words
*
- * @in the string to measure
- * @count the maximum number of characters to count
- * @return the string length, up to a maximum of 'count'
+ * @in:utf-16 string
+ * @count: maximum number of words to count
+ * ReturnValue:number of non-zero words.
+ * This is not the number of utf-16 letters!
*/
-size_t utf16_strnlen(const uint16_t *in, size_t count);
+size_t u16_strnlen(const u16 *in, size_t count);
/**
* utf16_strcpy() - UTF16 equivalent of strcpy()
diff --git a/lib/charset.c b/lib/charset.c
index cd186a5a5a..8ff8d59957 100644
--- a/lib/charset.c
+++ b/lib/charset.c
@@ -12,14 +12,14 @@
* utf8/utf16 conversion mostly lifted from grub
*/
-size_t utf16_strlen(const uint16_t *in)
+size_t u16_strlen(const u16 *in)
{
size_t i;
for (i = 0; in[i]; i++);
return i;
}
-size_t utf16_strnlen(const uint16_t *in, size_t count)
+size_t u16_strnlen(const u16 *in, size_t count)
{
size_t i;
for (i = 0; count-- && in[i]; i++);
@@ -39,7 +39,11 @@ uint16_t *utf16_strcpy(uint16_t *dest, const uint16_t *src)
uint16_t *utf16_strdup(const uint16_t *s)
{
uint16_t *new;
- if (!s || !(new = malloc((utf16_strlen(s) + 1) * 2)))
+
+ if (!s)
+ return NULL;
+ new = malloc((u16_strlen(s) + 1) * 2);
+ if (!new)
return NULL;
utf16_strcpy(new, s);
return new;
diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index 853358ab93..0c5764db12 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -60,7 +60,7 @@ static void parse_load_option(struct load_option *lo, void
*ptr)
ptr += sizeof(u16);
lo->label = ptr;
- ptr += (utf16_strlen(lo->label) + 1) * 2;
+ ptr += (u16_strlen(lo->label) + 1) * 2;
lo->file_path = ptr;
ptr += lo->file_path_length;
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 3fd0d2fd51..47fe54d79e 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -122,7 +122,7 @@ static efi_status_t EFIAPI efi_cout_output_string(
EFI_ENTRY("%p, %p", this, string);
- unsigned int n16 = utf16_strlen(string);
+ unsigned int n16 = u16_strlen(string);
char buf[MAX_UTF8_PER_UTF16 * n16 + 1];
u16 *p;
diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index e6a15bcb52..c21881b32c 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -139,7 +139,7 @@ static struct efi_file_handle *file_open(struct file_system
*fs,
if (file_name) {
utf16_to_utf8((u8 *)f0, (u16 *)file_name, 1);
- flen = utf16_strlen((u16 *)file_name);
+ flen = u16_strlen((u16 *)file_name);
}
/* we could have a parent, but also an absolute path: */
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 90b637215e..770c67abb9 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -106,7 +106,7 @@ static efi_status_t efi_to_native(char *native, u16
*variable_name,
{
size_t len;
- len =
Re: [U-Boot] [PATCH 3/5] net: Make copy_filename() accept NULL src
On Thu, Jul 5, 2018 at 6:49 AM, Alexander Graf wrote: > On 07/04/2018 06:18 PM, Joe Hershberger wrote: >> >> On Wed, Jul 4, 2018 at 4:25 AM, Alexander Graf wrote: >>> >>> On 07/04/2018 02:36 AM, Joe Hershberger wrote: Rather than crashing, check the src ptr and set dst to empty string. Signed-off-by: Joe Hershberger >>> >>> >>> Wouldn't it make more sense to check for the existence outside at the >>> caller's side? That way it's much easier to see what really is happening. >> >> It's much easier to allow NULL so that we can directly pass the return >> result of getenv(). > > > I know, and I see how it looks insanely smart and simple today. Until you > realize that the amazing "copy_filename" function doesn't touch the target > at all if it gets passed in NULL. And all of that implicitly. So implicitly > it will leave the old value in the filename if nothing is set in env. I think you are mis-reading the code. If src is NULL, it will set dst[0] = '\0'; I think the behavior is quite reasonable. > Imaging you're trying to read the code 4 years from now. Will you remember > all of the side effects of copy_filename()? Imagine you're someone who's new > to the code and doesn't know all the implicit side effects of its functions. > Will you understand what is going on at a glimpse? That's an argument for documentation... and anyway, yes, I think the function is sensible and I would expect it to do what it does. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/5] net: phy: prevent uclass_eth device "node" field overwriting
This series prevents the UCLASS_ETH device "node" field overwriting by some network drivers when Ethernet PHYs are linked to UCLASS_ETH device using "phy-handle" DT property and when Ethernet PHY driver needs to read some additional information from DT (like dp83867). It fixes following cases: - network drivers priv->phydev = phy_connect(priv->bus, priv->phyaddr, dev, priv->interface); <-- phydev is connected to dev which is UCLASS_ETH device if (priv->phy_of_handle > 0) dev_set_of_offset(priv->phydev->dev, priv->phy_of_handle); <-- phydev->dev->node is overwritten by phy-handle DT node - PHY driver in .config() callback int node = dev_of_offset(dev); <-- PHY driver uses overwritten dev->node const void *fdt = gd->fdt_blob; if (fdtdec_get_bool(fdt, node, "property")) ... As result, UCLASS_ETH device can't be used any more for DT accessing. It adds new field ofnode node to struct phy_device and updates TI CPSW and zynq_gem drivers to use it. zynq_gem.c, xilinx_phy.c changes only build tested. Changes in v2: - struct phy_device->node field initialization added to phy_device_create() Dependency: This series has dependency from https://patchwork.ozlabs.org/cover/936370/ due to possible merge conflicts PS: Not sure if any other Net drivers need to be updated, at least I've not found any. Grygorii Strashko (5): net: phy: add ofnode node to struct phy_device net: phy: dp83867: switch to use phy_get_ofnode() net: phy: xilinx: switch to use phy_get_ofnode() drivers: net: cpsw: fix phy dt node setting drivers: net: zynq_gem: fix phy dt node setting drivers/net/cpsw.c | 2 +- drivers/net/phy/phy.c| 4 drivers/net/phy/ti.c | 7 +-- drivers/net/phy/xilinx_phy.c | 10 ++ drivers/net/zynq_gem.c | 2 +- include/phy.h| 13 + 6 files changed, 30 insertions(+), 8 deletions(-) -- 2.10.5 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 5/5] drivers: net: zynq_gem: fix phy dt node setting
Now zynq_gem driver will overwrite UCLASS_ETH node when PHY is connected and configured which is not correct. Use struct phydev->node instead. Signed-off-by: Grygorii Strashko Acked-by: Joe Hershberger --- drivers/net/zynq_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c index d1138fe..0f56cda 100644 --- a/drivers/net/zynq_gem.c +++ b/drivers/net/zynq_gem.c @@ -350,7 +350,7 @@ static int zynq_phy_init(struct udevice *dev) priv->phydev->advertising = priv->phydev->supported; if (priv->phy_of_handle > 0) - dev_set_of_offset(priv->phydev->dev, priv->phy_of_handle); + priv->phydev->node = offset_to_ofnode(priv->phy_of_handle); return phy_config(priv->phydev); } -- 2.10.5 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/5] net: phy: add ofnode node to struct phy_device
Now the UCLASS_ETH device "node" field is owerwritten by some network drivers in
case of Ethernet PHYs which are linked to UCLASS_ETH device using
"phy-handle" DT property and when Ethernet PHY driver needs to read some
additional information from DT. In such cases following happens (in
general):
- network drivers
priv->phydev = phy_connect(priv->bus, priv->phyaddr, dev,
priv->interface);
<-- phydev is connected to dev which is UCLASS_ETH device
if (priv->phy_of_handle > 0)
dev_set_of_offset(priv->phydev->dev, priv->phy_of_handle);
<-- phydev->dev->node is overwritten by phy-handle DT node
- PHY driver in .config() callback
int node = dev_of_offset(dev);
<-- PHY driver uses overwritten dev->node
const void *fdt = gd->fdt_blob;
if (fdtdec_get_bool(fdt, node, "property"))
...
As result, UCLASS_ETH device can't be used any more for DT accessing.
This patch adds additional ofnode node field to struct phy_device which can
be set explicitly by network drivers and used by PHY drivers, so
overwriting can be avoided. Also add helper function phy_get_ofnode()
which will check and return phy_device->node or dev_ofnode(phydev->dev) for
backward compatibility with existing drivers.
Signed-off-by: Grygorii Strashko
---
Changes in v2:
- struct phy_device->node field initialization added to phy_device_create()
drivers/net/phy/phy.c | 4
include/phy.h | 13 +
2 files changed, 17 insertions(+)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 4e610bf..eea88f8 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -644,6 +644,10 @@ static struct phy_device *phy_device_create(struct mii_dev
*bus, int addr,
dev->link = 0;
dev->interface = interface;
+#ifdef CONFIG_DM_ETH
+ dev->node = ofnode_null();
+#endif
+
dev->autoneg = AUTONEG_ENABLE;
dev->addr = addr;
diff --git a/include/phy.h b/include/phy.h
index 7c3fc5c..0575ea8 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -9,6 +9,7 @@
#ifndef _PHY_H
#define _PHY_H
+#include
#include
#include
#include
@@ -165,6 +166,7 @@ struct phy_device {
#ifdef CONFIG_DM_ETH
struct udevice *dev;
+ ofnode node;
#else
struct eth_device *dev;
#endif
@@ -235,11 +237,22 @@ void phy_connect_dev(struct phy_device *phydev, struct
udevice *dev);
struct phy_device *phy_connect(struct mii_dev *bus, int addr,
struct udevice *dev,
phy_interface_t interface);
+static inline ofnode phy_get_ofnode(struct phy_device *phydev)
+{
+ if (ofnode_valid(phydev->node))
+ return phydev->node;
+ else
+ return dev_ofnode(phydev->dev);
+}
#else
void phy_connect_dev(struct phy_device *phydev, struct eth_device *dev);
struct phy_device *phy_connect(struct mii_dev *bus, int addr,
struct eth_device *dev,
phy_interface_t interface);
+static inline ofnode phy_get_ofnode(struct phy_device *phydev)
+{
+ return ofnode_null();
+}
#endif
int phy_startup(struct phy_device *phydev);
int phy_config(struct phy_device *phydev);
--
2.10.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/5] net: phy: dp83867: switch to use phy_get_ofnode()
Use PHY API phy_get_ofnode() helper to get PHY DT node.
Signed-off-by: Grygorii Strashko
Acked-by: Joe Hershberger
---
drivers/net/phy/ti.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
index 98c36ab..d4a7e39 100644
--- a/drivers/net/phy/ti.c
+++ b/drivers/net/phy/ti.c
@@ -172,8 +172,11 @@ void phy_write_mmd_indirect(struct phy_device *phydev, int
prtad,
static int dp83867_of_init(struct phy_device *phydev)
{
struct dp83867_private *dp83867 = phydev->priv;
- struct udevice *dev = phydev->dev;
- ofnode node = dev_ofnode(dev);
+ ofnode node;
+
+ node = phy_get_ofnode(phydev);
+ if (!ofnode_valid(node))
+ return -EINVAL;
if (ofnode_read_bool(node, "ti,max-output-impedance"))
dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
--
2.10.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/5] drivers: net: cpsw: fix phy dt node setting
Now CPSW driver will overwrite UCLASS_ETH node when PHY is connected and configured which is not correct. Use struct phydev->node instead. Signed-off-by: Grygorii Strashko Acked-by: Joe Hershberger --- drivers/net/cpsw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c index 9919d39..c31695e 100644 --- a/drivers/net/cpsw.c +++ b/drivers/net/cpsw.c @@ -999,7 +999,7 @@ static int cpsw_phy_init(struct cpsw_priv *priv, struct cpsw_slave *slave) #ifdef CONFIG_DM_ETH if (slave->data->phy_of_handle) - dev_set_of_offset(phydev->dev, slave->data->phy_of_handle); + phydev->node = offset_to_ofnode(slave->data->phy_of_handle); #endif priv->phydev = phydev; -- 2.10.5 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/5] net: phy: xilinx: switch to use phy_get_ofnode()
Use PHY API phy_get_ofnode() helper to get PHY DT node.
Signed-off-by: Grygorii Strashko
Acked-by: Joe Hershberger
---
drivers/net/phy/xilinx_phy.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/xilinx_phy.c b/drivers/net/phy/xilinx_phy.c
index 004cfcf..3aa8891 100644
--- a/drivers/net/phy/xilinx_phy.c
+++ b/drivers/net/phy/xilinx_phy.c
@@ -10,8 +10,6 @@
#include
#include
-DECLARE_GLOBAL_DATA_PTR;
-
#define MII_PHY_STATUS_SPD_MASK0x0C00
#define MII_PHY_STATUS_FULLDUPLEX 0x1000
#define MII_PHY_STATUS_10000x0800
@@ -101,10 +99,14 @@ static int xilinxphy_startup(struct phy_device *phydev)
static int xilinxphy_of_init(struct phy_device *phydev)
{
u32 phytype;
+ ofnode node;
debug("%s\n", __func__);
- phytype = fdtdec_get_int(gd->fdt_blob, dev_of_offset(phydev->dev),
-"xlnx,phy-type", -1);
+ node = phy_get_ofnode(phydev);
+ if (!ofnode_valid(node))
+ return -EINVAL;
+
+ phytype = ofnode_read_u32_default(node, "xlnx,phy-type", -1);
if (phytype == XAE_PHY_TYPE_1000BASE_X)
phydev->flags |= XAE_PHY_TYPE_1000BASE_X;
--
2.10.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] sf: add Macronix mx25l1633e entry
From: Ludwig Zenz
Add support for the Macronix mx25l1633e nor flash. (Tested on a imx6 board)
Signed-off-by: Ludwig Zenz
---
drivers/mtd/spi/spi_flash_ids.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
index bcee009..3b28341 100644
--- a/drivers/mtd/spi/spi_flash_ids.c
+++ b/drivers/mtd/spi/spi_flash_ids.c
@@ -86,6 +86,7 @@ const struct spi_flash_info spi_flash_ids[] = {
{"mx25l12805", INFO(0xc22018, 0x0, 64 * 1024, 256, RD_FULL |
WR_QPP) },
{"mx25l25635f",INFO(0xc22019, 0x0, 64 * 1024, 512, RD_FULL |
WR_QPP) },
{"mx25l51235f",INFO(0xc2201a, 0x0, 64 * 1024, 1024, RD_FULL |
WR_QPP) },
+ {"mx25l1633e", INFO(0xc22415, 0x0, 64 * 1024,32, RD_FULL |
WR_QPP | SECT_4K) },
{"mx25u6435f", INFO(0xc22537, 0x0, 64 * 1024, 128, RD_FULL |
WR_QPP) },
{"mx25l12855e",INFO(0xc22618, 0x0, 64 * 1024, 256, RD_FULL |
WR_QPP) },
{"mx25u1635e", INFO(0xc22535, 0x0, 64 * 1024, 32, SECT_4K) },
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] board: freescale: ls1012afrx:Common files to support
>-Original Message- >From: York Sun >Sent: Tuesday, July 3, 2018 8:53 PM >To: Pramod Kumar ; u-boot@lists.denx.de >Subject: Re: [PATCH 1/2 v2] board: freescale: ls1012afrx:Common files to >support > >On 06/06/2018 04:16 AM, Pramod Kumar wrote: >> LS1012A-FRDM and LS1012A-FRWY board. >> >> 1-Move all common files applicable for both boards LS1012A-FRDM >> and LS1012A-FRWY into board directory ls1012afrx. >> 2-Restructure LS1012A-FRDM code. Only board specific files are >> in LS1012A-FRDM board directory. >> >> Signed-off-by: Pramod Kumar >> --- >> Depends on: >> http://patchwork.ozlabs.org/patch/918935/ >> http://patchwork.ozlabs.org/patch/918933/ >> http://patchwork.ozlabs.org/patch/918932/ >> >> Changes for v2: >> - Rebased patch to above dependency patches >> > >Previous patch 918933 added FRWY board into FRDM Kconfig. If you want to >separate them, send a patch to do that. Don't mix with adding a new board. > For patch http://patchwork.ozlabs.org/patch/926134/ [U-Boot,1/2,v2] board: freescale: ls1012afrx:Common files to support In this patch, i have removed FRWY kconfig support. I have created a new directory "board/freescale/ls1012afrx/" and added common files which are applicable for both FRDM and FRWY. This patch would enable only FRDM board. For patch http://patchwork.ozlabs.org/patch/926132/ [U-Boot,2/2,v2] board: freescale: ls1012afrwy: Add LS1012A-FRWY board support. This patch create support for FRWY board by creating new directory "/board/freescale/ls1012afrwy". FRWY board would use the common files located in "board/freescale/ls1012afrx/". This patch would enable the FRWY board. >York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] sf: add Gigadevice gd25q16c entry
From: Ludwig Zenz
Add support for the Gigadevice gd25q16c nor flash. (Tested on a imx6 board)
Signed-off-by: Ludwig Zenz
---
drivers/mtd/spi/spi_flash_ids.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
index 3b28341..7fc8109 100644
--- a/drivers/mtd/spi/spi_flash_ids.c
+++ b/drivers/mtd/spi/spi_flash_ids.c
@@ -62,6 +62,7 @@ const struct spi_flash_info spi_flash_ids[] = {
{"en25s64",INFO(0x1c3817, 0x0, 64 * 1024, 128, 0) },
#endif
#ifdef CONFIG_SPI_FLASH_GIGADEVICE /* GIGADEVICE */
+ {"gd25q16c", INFO(0xc84015, 0x0, 64 * 1024,32, RD_FULL |
WR_QPP | SECT_4K) },
{"gd25q64b", INFO(0xc84017, 0x0, 64 * 1024, 128, SECT_4K) },
{"gd25q32b", INFO(0xc84016, 0x0, 64 * 1024,64, SECT_4K) },
{"gd25lq32", INFO(0xc86016, 0x0, 64 * 1024,64, SECT_4K) },
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] adout specification ram size before boot linux
Hello!! We using zenq_7z010 board, We have some question, How setting RAM size to 64M for linux kernel before linux kenerl ? Thanks ! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] ARM: imx6: DHCOM i.MX6 PDK: ddr init for 32bit bus and 4GBit chips
From: Ludwig Zenz
Support 1GIB + 2GIB DDR3 with 64bit bus width and 512MIB + 1GIB with 32bit bus
width
Signed-off-by: Ludwig Zenz
---
board/dhelectronics/dh_imx6/dh_imx6_spl.c | 191 +++---
1 file changed, 173 insertions(+), 18 deletions(-)
diff --git a/board/dhelectronics/dh_imx6/dh_imx6_spl.c
b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
index eafb86d..04e9eab 100644
--- a/board/dhelectronics/dh_imx6/dh_imx6_spl.c
+++ b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
@@ -136,7 +136,31 @@ static const struct mx6sdl_iomux_grp_regs
dhcom6sdl_grp_ioregs = {
.grp_b7ds = 0x0030,
};
-static const struct mx6_mmdc_calibration dhcom_mmdc_calib = {
+static const struct mx6_mmdc_calibration dhcom_mmdc_calib_4x4g_1066 = {
+ .p0_mpwldectrl0 = 0x00150019,
+ .p0_mpwldectrl1 = 0x001C000B,
+ .p1_mpwldectrl0 = 0x00020018,
+ .p1_mpwldectrl1 = 0x0002000C,
+ .p0_mpdgctrl0 = 0x43140320,
+ .p0_mpdgctrl1 = 0x03080304,
+ .p1_mpdgctrl0 = 0x43180320,
+ .p1_mpdgctrl1 = 0x03100254,
+ .p0_mprddlctl = 0x4830383C,
+ .p1_mprddlctl = 0x3836323E,
+ .p0_mpwrdlctl = 0x3E444642,
+ .p1_mpwrdlctl = 0x4232,
+};
+
+static const struct mx6_mmdc_calibration dhcom_mmdc_calib_2x4g_800 = {
+ .p0_mpwldectrl0 = 0x0040003C,
+ .p0_mpwldectrl1 = 0x0032003E,
+ .p0_mpdgctrl0 = 0x42350231,
+ .p0_mpdgctrl1 = 0x021A0218,
+ .p0_mprddlctl = 0x4B4B4E49,
+ .p0_mpwrdlctl = 0x3F3F3035,
+};
+
+static const struct mx6_mmdc_calibration dhcom_mmdc_calib_4x2g_1066 = {
.p0_mpwldectrl0 = 0x0011000E,
.p0_mpwldectrl1 = 0x000E001B,
.p1_mpwldectrl0 = 0x00190015,
@@ -151,23 +175,89 @@ static const struct mx6_mmdc_calibration dhcom_mmdc_calib
= {
.p1_mpwrdlctl = 0x473E4A3B,
};
-static const struct mx6_ddr3_cfg dhcom_mem_ddr = {
+static const struct mx6_mmdc_calibration dhcom_mmdc_calib_4x2g_800 = {
+ .p0_mpwldectrl0 = 0x003A003A,
+ .p0_mpwldectrl1 = 0x0030002F,
+ .p1_mpwldectrl0 = 0x002F0038,
+ .p1_mpwldectrl1 = 0x00270039,
+ .p0_mpdgctrl0 = 0x420F020F,
+ .p0_mpdgctrl1 = 0x01760175,
+ .p1_mpdgctrl0 = 0x41640171,
+ .p1_mpdgctrl1 = 0x015E0160,
+ .p0_mprddlctl = 0x45464B4A,
+ .p1_mprddlctl = 0x49484A46,
+ .p0_mpwrdlctl = 0x40402E32,
+ .p1_mpwrdlctl = 0x3A3A3231,
+};
+
+static const struct mx6_mmdc_calibration dhcom_mmdc_calib_2x2g_800 = {
+ .p0_mpwldectrl0 = 0x0040003C,
+ .p0_mpwldectrl1 = 0x0032003E,
+ .p0_mpdgctrl0 = 0x42350231,
+ .p0_mpdgctrl1 = 0x021A0218,
+ .p0_mprddlctl = 0x4B4B4E49,
+ .p0_mpwrdlctl = 0x3F3F3035,
+};
+
+/*
+ * 2 Gbit DDR3 memory
+ * - NANYA #NT5CC128M16IP-DII
+ * - NANYA #NT5CB128M16FP-DII
+ */
+static const struct mx6_ddr3_cfg dhcom_mem_ddr_2g = {
.mem_speed = 1600,
.density= 2,
- .width = 64,
+ .width = 16,
.banks = 8,
.rowaddr= 14,
.coladdr= 10,
.pagesz = 2,
- .trcd = 1312,
+ .trcd = 1375,
.trcmin = 5863,
.trasmin= 3750,
};
-static const struct mx6_ddr_sysinfo dhcom_ddr_info = {
+/*
+ * 4 Gbit DDR3 memory
+ * - Intelligent Memory #IM4G16D3EABG-125I
+ */
+static const struct mx6_ddr3_cfg dhcom_mem_ddr_4g = {
+ .mem_speed = 1600,
+ .density= 4,
+ .width = 16,
+ .banks = 8,
+ .rowaddr= 15,
+ .coladdr= 10,
+ .pagesz = 2,
+ .trcd = 1375,
+ .trcmin = 4875,
+ .trasmin= 3500,
+};
+
+/* DDR3 64bit */
+static const struct mx6_ddr_sysinfo dhcom_ddr_64bit = {
/* width of data bus:0=16,1=32,2=64 */
.dsize = 2,
- .cs_density = 16,
+ .cs_density = 32,
+ .ncs= 1,/* single chip select */
+ .cs1_mirror = 1,
+ .rtt_wr = 1,/* DDR3_RTT_60_OHM, RTT_Wr = RZQ/4 */
+ .rtt_nom= 1,/* DDR3_RTT_60_OHM, RTT_Nom = RZQ/4 */
+ .walat = 1,/* Write additional latency */
+ .ralat = 5,/* Read additional latency */
+ .mif3_mode = 3,/* Command prediction working mode */
+ .bi_on = 1,/* Bank interleaving enabled */
+ .sde_to_rst = 0x10, /* 14 cycles, 200us (JEDEC default) */
+ .rst_to_cke = 0x23, /* 33 cycles, 500us (JEDEC default) */
+ .refsel = 1,/* Refresh cycles at 32KHz */
+ .refr = 3,/* 4 refresh commands per refresh cycle */
+};
+
+/* DDR3 32bit */
+static const struct mx6_ddr_sysinfo dhcom_ddr_32bit = {
+ /* width of data bus:0=16,1=32,2=64 */
+ .dsize = 1,
+ .cs_density = 32,
.ncs= 1,/* single chip select */
[U-Boot] [PATCH] sf: add paired dev info for winbond w25q16jv
From: Ludwig Zenz
This commit adds paired dev info for winbond w25q16jv (tested w25q16jvssiq with
a i.mx6 board)
Signed-off-by: Ludwig Zenz
---
drivers/mtd/spi/spi_flash_ids.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
index 9212373..bcee009 100644
--- a/drivers/mtd/spi/spi_flash_ids.c
+++ b/drivers/mtd/spi/spi_flash_ids.c
@@ -187,7 +187,7 @@ const struct spi_flash_info spi_flash_ids[] = {
* Below paired flash devices has similar spi_flash params.
* (s25fl129p_64k, s25fl128s_64k)
* (w25q80bl, w25q80bv)
-* (w25q16cl, w25q16dv)
+* (w25q16cl, w25q16dv, w25q16jv)
* (w25q32bv, w25q32fv_spi)
* (w25q64cv, w25q64fv_spi)
* (w25q128bv, w25q128fv_spi)
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] ARM: imx6: configure ddrcode pins in spl DHCOM i.MX6 PDK
From: Ludwig Zenz
Preperation for conditional DDR3 initialization based on GPIO codes.
Signed-off-by: Ludwig Zenz
---
board/dhelectronics/dh_imx6/dh_imx6_spl.c | 40 +++
1 file changed, 40 insertions(+)
diff --git a/board/dhelectronics/dh_imx6/dh_imx6_spl.c
b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
index beda389..eafb86d 100644
--- a/board/dhelectronics/dh_imx6/dh_imx6_spl.c
+++ b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
@@ -208,6 +208,45 @@ static void setup_iomux_boardid(void)
SETUP_IOMUX_PADS(hwcode_pads);
}
+/* DDR Code */
+static iomux_v3_cfg_t const ddrcode_pads[] = {
+ IOMUX_PADS(PAD_EIM_A16__GPIO2_IO22 | MUX_PAD_CTRL(GPIO_PAD_CTRL)),
+ IOMUX_PADS(PAD_EIM_A17__GPIO2_IO21 | MUX_PAD_CTRL(GPIO_PAD_CTRL)),
+};
+
+static void setup_iomux_ddrcode(void)
+{
+ /* ddr code pins */
+ SETUP_IOMUX_PADS(ddrcode_pads);
+}
+
+enum dhcom_ddr3_code {
+ DH_DDR3_SIZE_256MIB = 0x00,
+ DH_DDR3_SIZE_512MIB = 0x01,
+ DH_DDR3_SIZE_1GIB = 0x02,
+ DH_DDR3_SIZE_2GIB = 0x03
+};
+
+#define DDR3_CODE_BIT_0 IMX_GPIO_NR(2, 22)
+#define DDR3_CODE_BIT_1 IMX_GPIO_NR(2, 21)
+
+enum dhcom_ddr3_code dhcom_get_ddr3_code(void)
+{
+ enum dhcom_ddr3_code ddr3_code;
+
+ gpio_request(DDR3_CODE_BIT_0, "DDR3_CODE_BIT_0");
+ gpio_request(DDR3_CODE_BIT_1, "DDR3_CODE_BIT_1");
+
+ gpio_direction_input(DDR3_CODE_BIT_0);
+ gpio_direction_input(DDR3_CODE_BIT_1);
+
+ /* 256MB = 0b00; 512MB = 0b01; 1GB = 0b10; 2GB = 0b11 */
+ ddr3_code = (!!gpio_get_value(DDR3_CODE_BIT_1) << 1)
+| (!!gpio_get_value(DDR3_CODE_BIT_0));
+
+ return ddr3_code;
+}
+
/* GPIO */
static iomux_v3_cfg_t const gpio_pads[] = {
IOMUX_PADS(PAD_GPIO_2__GPIO1_IO02 | MUX_PAD_CTRL(GPIO_PAD_CTRL)),
@@ -365,6 +404,7 @@ void board_init_f(ulong dummy)
timer_init();
setup_iomux_boardid();
+ setup_iomux_ddrcode();
setup_iomux_gpio();
setup_iomux_enet();
setup_iomux_sd();
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] Revert "ARM: imx6: Disable DDR DRAM calibration DHCOM i.MX6 PDK"
From: Ludwig Zenz This reverts commit a637fe6f27fd4c19ef9f43a5f871c244581422ac. The DDR DRAM calibration was enhanced by write leveling correction code. It can be used with T-topology now. Signed-off-by: Ludwig Zenz --- board/dhelectronics/dh_imx6/dh_imx6_spl.c | 4 1 file changed, 4 insertions(+) diff --git a/board/dhelectronics/dh_imx6/dh_imx6_spl.c b/board/dhelectronics/dh_imx6/dh_imx6_spl.c index dffe4eb..beda389 100644 --- a/board/dhelectronics/dh_imx6/dh_imx6_spl.c +++ b/board/dhelectronics/dh_imx6/dh_imx6_spl.c @@ -384,6 +384,10 @@ void board_init_f(ulong dummy) _grp_ioregs); mx6_dram_cfg(_ddr_info, _mmdc_calib, _mem_ddr); + /* Perform DDR DRAM calibration */ + udelay(100); + mmdc_do_dqs_calibration(_ddr_info); + /* Clear the BSS. */ memset(__bss_start, 0, __bss_end - __bss_start); -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] efi_selftest: test InstallConfigurationTable()
On 06/28/2018 12:45 PM, Heinrich Schuchardt wrote: Provide a unit test for InstallConfigurationTable(). A table is installed, updated, removed. The table entry and the triggering of events is checked. Signed-off-by: Heinrich Schuchardt Could you please do a crc test run that checks the crc32 header values of the systab/BTS/RTS structs at some early stage and again towards the end of your tests? Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/7] efi_loader: calculate crc32 for EFI tables
On 06/28/2018 12:45 PM, Heinrich Schuchardt wrote:
For the boot and runtime services tables and for the system table the
crc32 has to be set in the header.
Signed-off-by: Heinrich Schuchardt
Reviewed-by: Bin Meng
---
v2
no change
---
cmd/bootefi.c | 5 +
include/efi_loader.h | 2 ++
lib/efi_loader/efi_boottime.c | 32
3 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 91277106a2..07c61ac542 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -44,6 +44,11 @@ efi_status_t efi_init_obj_list(void)
if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED)
return efi_obj_list_initialized;
+ /* Initialize system table */
+ ret = efi_initialize_system_table();
+ if (ret != EFI_SUCCESS)
+ goto out;
+
/* Initialize EFI driver uclass */
ret = efi_driver_init();
if (ret != EFI_SUCCESS)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index d6e1f50e22..8c9c36556b 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -199,6 +199,8 @@ extern struct list_head efi_obj_list;
/* List of all events */
extern struct list_head efi_events;
+/* Called by bootefi to initialize runtime */
+efi_status_t efi_initialize_system_table(void);
/* Called by bootefi to make console interface available */
int efi_console_register(void);
/* Called by bootefi to make all disk storage accessible as EFI objects */
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 7c619c652c..904056dbfd 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -163,6 +163,18 @@ const char *__efi_nesting_dec(void)
return indent_string(--nesting_level);
}
+/**
+ * efi_update_table_header_crc32() - Update CRC32 in table header
+ *
+ * @table: EFI table
+ */
+static void efi_update_table_header_crc32(struct efi_table_hdr *table)
+{
+ table->crc32 = 0;
+ table->crc32 = crc32(0, (const unsigned char *)table,
+table->headersize);
+}
+
/**
* efi_queue_event - queue an EFI event
*
@@ -1848,9 +1860,7 @@ static efi_status_t EFIAPI
efi_exit_boot_services(efi_handle_t image_handle,
systab.boottime = NULL;
/* Recalculate CRC32 */
- systab.hdr.crc32 = 0;
- systab.hdr.crc32 = crc32(0, (const unsigned char *),
-sizeof(struct efi_system_table));
+ efi_update_table_header_crc32();
/* Give the payload some time to boot */
efi_set_watchdog(0);
@@ -2988,7 +2998,7 @@ out:
return EFI_EXIT(r);
}
-static const struct efi_boot_services efi_boot_services = {
+static struct efi_boot_services efi_boot_services = {
.hdr = {
.signature = EFI_BOOT_SERVICES_SIGNATURE,
.revision = EFI_SPECIFICATION_VERSION,
@@ -3060,3 +3070,17 @@ struct efi_system_table __efi_runtime_data systab = {
.nr_tables = 0,
.tables = (void *)efi_conf_table,
};
+
+/**
+ * efi_initialize_system_table() - Initialize system table
+ *
+ * Return Value:status code
+ */
+efi_status_t efi_initialize_system_table(void)
+{
+ /* Set crc32 field in table headers */
+ efi_update_table_header_crc32();
Systab gets modified when tables get added.
+ efi_update_table_header_crc32(_runtime_services.hdr);
The RTS table gets modified on exit_boot_services.
Can you please send a follow-up patch to recalculate the crc32 on those
2 events as well?
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] bootmenu: Extend BOOTDELAY help text
Extend BOOTDELAY help text to cover its additional usage within the bootmenu command. Signed-off-by: Alex Kiernan --- common/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/common/Kconfig b/common/Kconfig index 4c7a1a9af8..81e88ea77c 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -182,6 +182,10 @@ config BOOTDELAY set to -1 to disable autoboot. set to -2 to autoboot with no delay and not check for abort + If this value is >= 0 then it is also used for the default delay + before starting the default entry in bootmenu. If it is < 0 then + a default value of 10s is used. + See doc/README.autoboot for details. config USE_BOOTARGS -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] env: Include bootdelay in environment if negative
The test for (CONFIG_BOOTDELAY >= 0) has been in U-Boot since the
beginning, but the meaning of it has changed over time. Allow the
default to be set for any value, including -ve ones. This allows
(for example) CONFIG_ENV_IS_NOWHERE to have values for bootdelay in
its compiled in environment.
The only thing this changes is where the default for bootdelay can be
fetched from; before this change you get a compiled in default, after
you'll pull it from the default value in the environment, but both values
will be the same. Also if there's a value set in the environment then
that will take precedence (as before).
Signed-off-by: Alex Kiernan
---
include/env_default.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/env_default.h b/include/env_default.h
index 54d8124793..bd600cfa44 100644
--- a/include/env_default.h
+++ b/include/env_default.h
@@ -40,7 +40,7 @@ const uchar default_environment[] = {
#ifdef CONFIG_NFSBOOTCOMMAND
"nfsboot=" CONFIG_NFSBOOTCOMMAND "\0"
#endif
-#if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0)
+#if defined(CONFIG_BOOTDELAY)
"bootdelay="__stringify(CONFIG_BOOTDELAY) "\0"
#endif
#if defined(CONFIG_BAUDRATE) && (CONFIG_BAUDRATE >= 0)
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] net: Re-check prerequisites when autoloading
On 07/04/2018 06:23 PM, Joe Hershberger wrote:
On Wed, Jul 4, 2018 at 4:20 AM, Alexander Graf wrote:
On 07/04/2018 02:36 AM, Joe Hershberger wrote:
With net autoload, we check the prerequisites for the initial command,
but the greater prerequisites when autoloading are not checked.
If we would attempt to autoload, check those prerequisites too.
If we are not expecting a serverip from the server, then don't worry
about it not being set, but don't attempt to load if it isn't.
Signed-off-by: Joe Hershberger
---
net/net.c | 20
1 file changed, 20 insertions(+)
diff --git a/net/net.c b/net/net.c
index bff3e9c5b5..42a50e60f8 100644
--- a/net/net.c
+++ b/net/net.c
@@ -332,6 +332,16 @@ void net_auto_load(void)
const char *s = env_get("autoload");
if (s != NULL && strcmp(s, "NFS") == 0) {
+ if (net_check_prereq(NFS)) {
+/* We aren't expecting to get a serverip, so just accept the assigned IP
*/
+#ifdef CONFIG_BOOTP_SERVERIP
+ net_set_state(NETLOOP_SUCCESS);
+#else
+ printf("Cannot autoload with NFS\n");
+ net_set_state(NETLOOP_FAIL);
+#endif
I don't understand the #ifdef. In the CONFIG_BOOTP_SERVERIP case, you should
already have net_server_ip set from the variable setter, so when do you
realistically get into the case where net_check_prereq() fails here? I can
My thinking here was that if the user is in control of the serverip
and chooses not to set it, then at least populate the dhcp variables
that were successful. If we return a fail from here, even though DHCP
was successful, the result will not be saved to the env for the user.
IMHO CONFIG_BOOTP_SERVERIP is a very esoteric use case already. Let's
not interpret too much into it. Instead, I would prefer if we could just
treat it the same as the normal case as often as we can ...
Or maybe just move its functionality (do not set serverip from dhcp
command) into an environment variable.
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] net: Make copy_filename() accept NULL src
On 07/04/2018 06:18 PM, Joe Hershberger wrote: On Wed, Jul 4, 2018 at 4:25 AM, Alexander Graf wrote: On 07/04/2018 02:36 AM, Joe Hershberger wrote: Rather than crashing, check the src ptr and set dst to empty string. Signed-off-by: Joe Hershberger Wouldn't it make more sense to check for the existence outside at the caller's side? That way it's much easier to see what really is happening. It's much easier to allow NULL so that we can directly pass the return result of getenv(). I know, and I see how it looks insanely smart and simple today. Until you realize that the amazing "copy_filename" function doesn't touch the target at all if it gets passed in NULL. And all of that implicitly. So implicitly it will leave the old value in the filename if nothing is set in env. Imaging you're trying to read the code 4 years from now. Will you remember all of the side effects of copy_filename()? Imagine you're someone who's new to the code and doesn't know all the implicit side effects of its functions. Will you understand what is going on at a glimpse? Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] efi_loader: EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.Reset()
On 07/05/2018 08:18 AM, Heinrich Schuchardt wrote:
Implement the reset service of the EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.
This should resolve the error reported by the SCT in
Protocol/SimpleTextOut/BlackBoxTest/SimpleTextOutBBTestFunction_uefi.c:639
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_console.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 3fd0d2fd51..17aced86a5 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -110,7 +110,15 @@ static efi_status_t EFIAPI efi_cout_reset(
char extended_verification)
{
EFI_ENTRY("%p, %d", this, extended_verification);
- return EFI_EXIT(EFI_UNSUPPORTED);
+
+ /* Clear screen */
+ printf(ESC "[2J");
+ efi_con_mode.cursor_column = 0;
+ efi_con_mode.cursor_row = 0;
Can this just call clear_screen()?
Alex
+ /* Set default colors */
+ printf(ESC "[0;37;40m");
+
+ return EFI_EXIT(EFI_SUCCESS);
}
static efi_status_t EFIAPI efi_cout_output_string(
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] sunxi: A64: OHCI: prevent turning off shared USB clock
Hi, On 05/07/18 10:25, Marek Vasut wrote: > On 07/05/2018 01:57 AM, Andre Przywara wrote: >> On the A64 the clock for the first USB controller is actually the parent >> of the clock for the second controller, so turning them off in that order >> makes the system hang. >> Fix this by only turning off *both* clocks when the *last* OHCI controller >> is brought down. This covers the case when only one controller is used. >> >> Signed-off-by: Andre Przywara >> --- >> Hi, >> >> as requested by Marek, a second version to address the problem of only >> one controller instantiated. I tested all cases: >> - only [EO]HCI1 enabled (current U-Boot master DT) >> - both controllers enabled (mainline Linux DT) >> - only [EO]HCI0 enabled (DT hack) >> In all cases the system booted without hanging, plus I confirmed that >> the USB clocks were disabled in all cases (early in the kernel). >> >> Cheers, >> Andre. >> >> P.S. I found the MMC0, EMAC and USB-OTG AHB gates and resets still running, >> but this is an unrelated issue and no regression. Just in case somebody >> feels bored ... > > Applied, thanks for all the effort you put into this . Thank _you_ for staying on this, and insisting on the more robust solution! Cheers, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] rtc: pl031: convert the driver to driver model
On Wed, Jul 04, 2018 at 12:50:52PM +0200, Heinrich Schuchardt wrote:
> On 07/04/2018 09:36 AM, AKASHI Takahiro wrote:
> > Signed-off-by: AKASHI Takahiro
> > ---
> > drivers/rtc/Kconfig | 6 ++
> > drivers/rtc/pl031.c | 109 +--
> > include/dm/platform_data/rtc_pl031.h | 12 +++
> > 3 files changed, 87 insertions(+), 40 deletions(-)
> > create mode 100644 include/dm/platform_data/rtc_pl031.h
> >
> > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> > index a3f8c8aecc..96c4cce410 100644
> > --- a/drivers/rtc/Kconfig
> > +++ b/drivers/rtc/Kconfig
> > @@ -55,6 +55,12 @@ config RTC_MV
> > Enable Marvell RTC driver. This driver supports the rtc that is
> > present
> > on some Marvell SoCs.
> >
> > +config RTC_PL031
> > + bool "Enable ARM PL031 driver"
> > + depends on DM_RTC
> > + help
> > + Enable ARM PL031 driver.
> > +
> > config RTC_S35392A
> > bool "Enable S35392A driver"
> > select BITREVERSE
> > diff --git a/drivers/rtc/pl031.c b/drivers/rtc/pl031.c
> > index 8955805e3b..eecade8374 100644
> > --- a/drivers/rtc/pl031.c
> > +++ b/drivers/rtc/pl031.c
> > @@ -8,14 +8,10 @@
> >
> > #include
> > #include
> > +#include
> > +#include
> > #include
> >
> > -#if defined(CONFIG_CMD_DATE)
> > -
> > -#ifndef CONFIG_SYS_RTC_PL031_BASE
> > -#error CONFIG_SYS_RTC_PL031_BASE is not defined!
> > -#endif
> > -
> > /*
> > * Register definitions
> > */
> > @@ -30,78 +26,111 @@
> >
> > #define RTC_CR_START (1 << 0)
> >
> > -#defineRTC_WRITE_REG(addr, val) \
> > - (*(volatile unsigned int *)(CONFIG_SYS_RTC_PL031_BASE +
> > (addr)) = (val))
> > -#defineRTC_READ_REG(addr) \
> > - (*(volatile unsigned int *)(CONFIG_SYS_RTC_PL031_BASE +
> > (addr)))
> > +#defineRTC_WRITE_REG(base, addr, val) \
> > + (*(volatile unsigned int *)((base) + (addr)) = (val))
> > +#defineRTC_READ_REG(base, addr)\
> > + (*(volatile unsigned int *)((base) + (addr)))
> >
> > static int pl031_initted = 0;
> >
> > /* Enable RTC Start in Control register*/
> > -void rtc_init(void)
> > +void pl031_rtc_init(struct pl031_rtc_platdata *pdata)
> > {
> > - RTC_WRITE_REG(RTC_CR, RTC_CR_START);
> > + RTC_WRITE_REG(pdata->base, RTC_CR, RTC_CR_START);
> >
> > pl031_initted = 1;
> > }
> >
> > /*
> > - * Reset the RTC. We set the date back to 1970-01-01.
> > + * Get the current time from the RTC
> > */
> > -void rtc_reset(void)
> > +static int pl031_rtc_get(struct udevice *dev, struct rtc_time *tm)
> > {
> > - RTC_WRITE_REG(RTC_LR, 0x00);
> > - if(!pl031_initted)
> > - rtc_init();
> > + struct pl031_rtc_platdata *pdata = dev_get_platdata(dev);
> > + ulong tim;
> > +
> > + if (!tm) {
> > + puts("Error getting the date/time\n");
> > + return -1;
> > + }
> > +
> > + if (!pl031_initted)
> > + pl031_rtc_init(pdata);
> > +
> > + tim = RTC_READ_REG(pdata->base, RTC_DR);
> > +
> > + rtc_to_tm(tim, tm);
>
> Please, check the return code. The RTC may contain invalid data.
But how do we know if the value is bogus or not?
> > +
> > + debug("Get DATE: %4d-%02d-%02d (wday=%d) TIME: %2d:%02d:%02d\n",
> > + tm->tm_year, tm->tm_mon, tm->tm_mday, tm->tm_wday,
> > + tm->tm_hour, tm->tm_min, tm->tm_sec);
> > +
> > + return 0;
> > }
> >
> > /*
> > * Set the RTC
> > -*/
> > -int rtc_set(struct rtc_time *tmp)
> > + */
> > +static int pl031_rtc_set(struct udevice *dev, const struct rtc_time *tm)
> > {
> > + struct pl031_rtc_platdata *pdata = dev_get_platdata(dev);
> > unsigned long tim;
>
> Please, add a debug statement here, too.
OK.
> >
> > - if(!pl031_initted)
> > - rtc_init();
> > -
> > - if (tmp == NULL) {
> > + if (!tm) {
> > puts("Error setting the date/time\n");
> > return -1;
> > }
> >
> > + if (!pl031_initted)
> > + pl031_rtc_init(pdata);
> > +
> > /* Calculate number of seconds this incoming time represents */
> > - tim = rtc_mktime(tmp);
> > + tim = rtc_mktime(tm);
> >
> > - RTC_WRITE_REG(RTC_LR, tim);
> > + RTC_WRITE_REG(pdata->base, RTC_LR, tim);
> >
> > return -1;
>
> No error has occurred. Please, return 0.
Ouch.
> > }
> >
> > /*
> > - * Get the current time from the RTC
> > + * Reset the RTC. We set the date back to 1970-01-01.
> > */
> > -int rtc_get(struct rtc_time *tmp)
> > +static int pl031_rtc_reset(struct udevice *dev)
> > {
> > - ulong tim;
> > + struct pl031_rtc_platdata *pdata = dev_get_platdata(dev);
> >
> > - if(!pl031_initted)
> > - rtc_init();
> > + RTC_WRITE_REG(pdata->base, RTC_LR, 0x00);
> >
> > - if (tmp == NULL) {
> > - puts("Error getting the date/time\n");
> > - return -1;
> > - }
> > + if (!pl031_initted)
>
> nits:
>
> There is no English word initted. I would
Re: [U-Boot] [PATCH v2] sunxi: A64: OHCI: prevent turning off shared USB clock
On 07/05/2018 01:57 AM, Andre Przywara wrote: > On the A64 the clock for the first USB controller is actually the parent > of the clock for the second controller, so turning them off in that order > makes the system hang. > Fix this by only turning off *both* clocks when the *last* OHCI controller > is brought down. This covers the case when only one controller is used. > > Signed-off-by: Andre Przywara > --- > Hi, > > as requested by Marek, a second version to address the problem of only > one controller instantiated. I tested all cases: > - only [EO]HCI1 enabled (current U-Boot master DT) > - both controllers enabled (mainline Linux DT) > - only [EO]HCI0 enabled (DT hack) > In all cases the system booted without hanging, plus I confirmed that > the USB clocks were disabled in all cases (early in the kernel). > > Cheers, > Andre. > > P.S. I found the MMC0, EMAC and USB-OTG AHB gates and resets still running, > but this is an unrelated issue and no regression. Just in case somebody > feels bored ... Applied, thanks for all the effort you put into this . -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] sunxi: A64: OHCI: prevent turning off shared USB clock
On Thu, Jul 5, 2018 at 5:27 AM, Andre Przywara wrote:
> On the A64 the clock for the first USB controller is actually the parent
> of the clock for the second controller, so turning them off in that order
> makes the system hang.
> Fix this by only turning off *both* clocks when the *last* OHCI controller
> is brought down. This covers the case when only one controller is used.
>
> Signed-off-by: Andre Przywara
> ---
> Hi,
>
> as requested by Marek, a second version to address the problem of only
> one controller instantiated. I tested all cases:
> - only [EO]HCI1 enabled (current U-Boot master DT)
> - both controllers enabled (mainline Linux DT)
> - only [EO]HCI0 enabled (DT hack)
> In all cases the system booted without hanging, plus I confirmed that
> the USB clocks were disabled in all cases (early in the kernel).
>
> Cheers,
> Andre.
>
> P.S. I found the MMC0, EMAC and USB-OTG AHB gates and resets still running,
Yes MUSB doesn't have shutdown support yet for UCLASS_USB_DEV_GENERIC
so .remove is not able to call. But I've verified this with some
change[1] and it's working as usual. will send it soon.
> but this is an unrelated issue and no regression. Just in case somebody
> feels bored ...
>
> drivers/usb/host/ohci-sunxi.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/ohci-sunxi.c b/drivers/usb/host/ohci-sunxi.c
> index 0ddbdbe460..bb3c2475df 100644
> --- a/drivers/usb/host/ohci-sunxi.c
> +++ b/drivers/usb/host/ohci-sunxi.c
> @@ -44,6 +44,8 @@ struct ohci_sunxi_priv {
> const struct ohci_sunxi_cfg *cfg;
> };
>
> +static fdt_addr_t last_ohci_addr = 0;
> +
> static int ohci_usb_probe(struct udevice *dev)
> {
> struct usb_bus_priv *bus_priv = dev_get_uclass_priv(dev);
> @@ -53,6 +55,9 @@ static int ohci_usb_probe(struct udevice *dev)
> u8 reg_mask = 0;
> int phys, ret;
>
> + if ((fdt_addr_t)regs > last_ohci_addr)
> + last_ohci_addr = (fdt_addr_t)regs;
> +
> priv->cfg = (const struct ohci_sunxi_cfg *)dev_get_driver_data(dev);
> priv->ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
> if (IS_ERR(priv->ccm))
> @@ -114,6 +119,7 @@ no_phy:
> static int ohci_usb_remove(struct udevice *dev)
> {
> struct ohci_sunxi_priv *priv = dev_get_priv(dev);
> + fdt_addr_t base_addr = devfdt_get_addr(dev);
> int ret;
>
> if (generic_phy_valid(>phy)) {
> @@ -130,7 +136,18 @@ static int ohci_usb_remove(struct udevice *dev)
>
> if (priv->cfg->has_reset)
> clrbits_le32(priv->reset0_cfg, priv->ahb_gate_mask);
> - clrbits_le32(>ccm->usb_clk_cfg, priv->usb_gate_mask);
> + /*
> +* On the A64 CLK_USB_OHCI0 is the parent of CLK_USB_OHCI1, so
> +* we have to wait with bringing down any clock until the last
> +* OHCI controller is removed.
> +*/
> + if (!priv->cfg->extra_usb_gate_mask || base_addr == last_ohci_addr) {
> + u32 usb_gate_mask = priv->usb_gate_mask;
> +
> + usb_gate_mask |= priv->cfg->extra_usb_gate_mask;
> + clrbits_le32(>ccm->usb_clk_cfg, usb_gate_mask);
> + }
> +
> clrbits_le32(>ccm->ahb_gate0, priv->ahb_gate_mask);
>
> return 0;
> --
Reviewed-by: Jagan Teki
Tested-by: Jagan Teki
[1]
https://github.com/amarula/u-boot-amarula/commit/401f74ebfb21bb92f793d50e2d3042c19327051c
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/7] Improve rockusb support in U-Boot
Hi Alberto, > Dear Kever, > > On Thu, Jul 5, 2018 at 3:15 AM, Kever Yang > wrote: > > > > Hi Alberto, > > > > Thanks for your patches, and I'm so glad for people using > > rockusb and try to improve it. > > > > You can reference to rockchip source code here: > > https://github.com/rockchip-linux/u-boot/blob/release/drivers/usb/gadget/f_rockusb.c > > > > We use msc as base framework instead of dfu because of the big > > performance improvement, and the cmd handling part will be the > > same. > > > Don't know if injecting rockusb protocol in f_mass_storage.c will be > acceptable in terms of coexistence and maintainability of resulting > f_mass_storage.c I would like to have the rockchip part separate to be included by enabling Kconfig option in u-boot. > Do you plan to upstream your tree? > > I saw patches in your tree and resulting f_rockusb.c is more clear > yes. But we pay the price in f_mass_storage.c. It would be nice to see the code posted on u-boot ML. > > Best Regards, > Alberto Panizzo > > -- > Amarula Solutions SRL Via le Canevare 30 31100 > Treviso Italy Amarula Solutions BV Cruquiuskade 47 > Amsterdam 1018 AM The Netherlands Phone. +31(0)851119171 Fax. > +31(0)204106211 www.amarulasolutions.com > > > > > > > PS: Yes, rockusb is available for all Rockchip's SoCs. > > > > Thanks, > > - Kever > > On 07/04/2018 03:02 AM, Alberto Panizzo wrote: > > > rockusb protocol has been introduced by Eddie Cai in U-Boot > > > mainline allowing to write internal eMMC of RK3288 based boards > > > (and potentially all other Rockchip's CPUs). > > > > > > On workstation side the open source project rkdeveloptool do > > > implement the rockusb protocol. You can find it on GitHub here: > > > https://github.com/rockchip-linux/rkdeveloptool > > > > > > This patchset increase the supported functionalities on target > > > side allowing developers to: > > > - Read flash: rl command of rkdeveloptool > > > - Read chip version: rci command of rkdeveloptool > > > - Complete the write cycle implementing block erase > > > - Improve read/write speed > > > > > > Alberto Panizzo (7): > > > usb: rockchip: fix command failed on host side due to missing > > > data usb: rockchip: implement skeleton for K_FW_GET_CHIP_VER > > > command rockchip: rk3288: implement reading chip version from > > > bootrom code usb: rockchip: implement K_FW_LBA_READ_10 command > > > usb: rockchip: implement K_FW_LBA_ERASE_10 command > > > usb: rockchip: be quiet on serial port while transferring data > > > usb: rockchip: boost up write speed from 4MB/s to 15MB/s > > > > > > arch/arm/include/asm/arch-rockchip/f_rockusb.h | 6 +- > > > arch/arm/mach-rockchip/rk3288/Makefile | 1 + > > > arch/arm/mach-rockchip/rk3288/rockusb_rk3288.c | 30 > > > drivers/usb/gadget/f_rockusb.c | 225 > > > - 4 files changed, 253 insertions(+), 9 > > > deletions(-) create mode 100644 > > > arch/arm/mach-rockchip/rk3288/rockusb_rk3288.c > > > > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de pgpcvUAe674ox.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] usb: rockchip: implement K_FW_LBA_READ_10 command
Hi Kever,
On Thu, Jul 5, 2018 at 3:19 AM, Kever Yang wrote:
>
> Hi Alberto,
>
>
> On 07/04/2018 03:02 AM, Alberto Panizzo wrote:
> > It is now possible to read from block device al logic layer.
> > Corresponding command on workstation is:
> > rkdeveloptool rl
> >
> > Signed-off-by: Alberto Panizzo
> > ---
> > arch/arm/include/asm/arch-rockchip/f_rockusb.h | 2 +
> > drivers/usb/gadget/f_rockusb.c | 102
> > -
> > 2 files changed, 103 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/include/asm/arch-rockchip/f_rockusb.h
> > b/arch/arm/include/asm/arch-rockchip/f_rockusb.h
> > index f5cad8e..f04d401 100644
> > --- a/arch/arm/include/asm/arch-rockchip/f_rockusb.h
> > +++ b/arch/arm/include/asm/arch-rockchip/f_rockusb.h
> > @@ -120,6 +120,8 @@ struct f_rockusb {
> > unsigned int lba;
> > unsigned int dl_size;
> > unsigned int dl_bytes;
> > + unsigned int ul_size;
> > + unsigned int ul_bytes;
> > struct blk_desc *desc;
> > int reboot_flag;
> > void *buf;
> > diff --git a/drivers/usb/gadget/f_rockusb.c b/drivers/usb/gadget/f_rockusb.c
> > index 7612871..dbf31cb 100644
> > --- a/drivers/usb/gadget/f_rockusb.c
> > +++ b/drivers/usb/gadget/f_rockusb.c
> > @@ -340,6 +340,7 @@ static int rockusb_tx_write(const char *buffer,
> > unsigned int buffer_size)
> >
> > memcpy(in_req->buf, buffer, buffer_size);
> > in_req->length = buffer_size;
> > + debug("Transferring 0x%x bytes\n", buffer_size);
> > usb_ep_dequeue(rockusb_func->in_ep, in_req);
> > ret = usb_ep_queue(rockusb_func->in_ep, in_req, 0);
> > if (ret)
> > @@ -434,6 +435,79 @@ static unsigned int rx_bytes_expected(struct usb_ep
> > *ep)
> > return rx_remain;
> > }
> >
> > +/* usb_request complete call back to handle upload image */
> > +static void tx_handler_ul_image(struct usb_ep *ep, struct usb_request *req)
>
> Could you use another name like '_rl_' instead of '_ul_', and since
> there is a prefix 'tx',
> maybe we don't need this '_ul_'? Because there is a rockusb cmd 'UL' or
> 'ul' means
> 'upgrade loader'.
Name has been chosen following the sibling rx_handler_dl_image function name:
tx_handler_ul_image is
- a transfer -> tx_
- a complete handler -> handler
- it does upload data to the usb host -> ul_image
I know upgrade_tool/rkdeveloptool do have ul command but this is a
totally different context
>
>
> > +{
> > +#define RBUFFER_SIZE 4096
> You can use the same size for TX and RX buffer.
>
> BTW: I don't like the design of the return value here, there should
> always have return
> value instead of void, many error cat may happen during the TX.
This is a request complete handler, so function arguments and return
value cannot be
different than the proposed.
Errors have to be reported to the host with a CSW_FAIL message and managed
here on target switching back to the default complete handler.
Best Regards,
Alberto Panizzo
--
Amarula Solutions SRL Via le Canevare 30 31100 Treviso Italy
Amarula Solutions BV Cruquiuskade 47 Amsterdam 1018 AM The Netherlands
Phone. +31(0)851119171 Fax. +31(0)204106211 www.amarulasolutions.com
>
> Thanks,
> - Kever
> > + ALLOC_CACHE_ALIGN_BUFFER(char, rbuffer, RBUFFER_SIZE);
> > + struct f_rockusb *f_rkusb = get_rkusb();
> > + struct usb_request *in_req = rockusb_func->in_req;
> > + int ret;
> > +
> > + if (!f_rkusb->desc) {
> > + char *type = f_rkusb->dev_type;
> > + int index = f_rkusb->dev_index;
> > +
> > + f_rkusb->desc = blk_get_dev(type, index);
> > + if (!f_rkusb->desc ||
> > + f_rkusb->desc->type == DEV_TYPE_UNKNOWN) {
> > + puts("invalid mmc device\n");
> > + rockusb_tx_write_csw(f_rkusb->tag, 0, CSW_FAIL,
> > + USB_BULK_CS_WRAP_LEN);
> > + return;
> > + }
> > + }
> > +
> > + /* Print error status of previous transfer */
> > + if (req->status)
> > + debug("status: %d ep '%s' trans: %d len %d\n", req->status,
> > + ep->name, req->actual, req->length);
> > +
> > + /* On transfer complete reset in_req and feedback host with CSW_GOOD
> > */
> > + if (f_rkusb->ul_bytes >= f_rkusb->ul_size) {
> > + in_req->length = 0;
> > + in_req->complete = rockusb_complete;
> > +
> > + rockusb_tx_write_csw(f_rkusb->tag, 0, CSW_GOOD,
> > + USB_BULK_CS_WRAP_LEN);
> > + return;
> > + }
> > +
> > + /* Proceed with current chunk */
> > + unsigned int transfer_size = f_rkusb->ul_size - f_rkusb->ul_bytes;
> > +
> > + if (transfer_size > RBUFFER_SIZE)
> > + transfer_size = RBUFFER_SIZE;
> > + /* Read at least one block */
> > + unsigned int blkcount = (transfer_size + 511) / 512;
> > +
> > +
Re: [U-Boot] [PATCH 0/7] Improve rockusb support in U-Boot
Dear Kever, On Thu, Jul 5, 2018 at 3:15 AM, Kever Yang wrote: > > Hi Alberto, > > Thanks for your patches, and I'm so glad for people using rockusb > and try to improve it. > > You can reference to rockchip source code here: > https://github.com/rockchip-linux/u-boot/blob/release/drivers/usb/gadget/f_rockusb.c > > We use msc as base framework instead of dfu because of the big > performance improvement, and the cmd handling part will be the same. Don't know if injecting rockusb protocol in f_mass_storage.c will be acceptable in terms of coexistence and maintainability of resulting f_mass_storage.c Do you plan to upstream your tree? I saw patches in your tree and resulting f_rockusb.c is more clear yes. But we pay the price in f_mass_storage.c. Best Regards, Alberto Panizzo -- Amarula Solutions SRL Via le Canevare 30 31100 Treviso Italy Amarula Solutions BV Cruquiuskade 47 Amsterdam 1018 AM The Netherlands Phone. +31(0)851119171 Fax. +31(0)204106211 www.amarulasolutions.com > > > PS: Yes, rockusb is available for all Rockchip's SoCs. > > Thanks, > - Kever > On 07/04/2018 03:02 AM, Alberto Panizzo wrote: > > rockusb protocol has been introduced by Eddie Cai in U-Boot mainline > > allowing to write internal eMMC of RK3288 based boards (and potentially > > all other Rockchip's CPUs). > > > > On workstation side the open source project rkdeveloptool do implement > > the rockusb protocol. You can find it on GitHub here: > > https://github.com/rockchip-linux/rkdeveloptool > > > > This patchset increase the supported functionalities on target side > > allowing developers to: > > - Read flash: rl command of rkdeveloptool > > - Read chip version: rci command of rkdeveloptool > > - Complete the write cycle implementing block erase > > - Improve read/write speed > > > > Alberto Panizzo (7): > > usb: rockchip: fix command failed on host side due to missing data > > usb: rockchip: implement skeleton for K_FW_GET_CHIP_VER command > > rockchip: rk3288: implement reading chip version from bootrom code > > usb: rockchip: implement K_FW_LBA_READ_10 command > > usb: rockchip: implement K_FW_LBA_ERASE_10 command > > usb: rockchip: be quiet on serial port while transferring data > > usb: rockchip: boost up write speed from 4MB/s to 15MB/s > > > > arch/arm/include/asm/arch-rockchip/f_rockusb.h | 6 +- > > arch/arm/mach-rockchip/rk3288/Makefile | 1 + > > arch/arm/mach-rockchip/rk3288/rockusb_rk3288.c | 30 > > drivers/usb/gadget/f_rockusb.c | 225 > > - > > 4 files changed, 253 insertions(+), 9 deletions(-) > > create mode 100644 arch/arm/mach-rockchip/rk3288/rockusb_rk3288.c > > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] rtc: pl031: convert the driver to driver model
On Wed, Jul 04, 2018 at 10:53:34AM +0200, Alexander Graf wrote:
> On 07/04/2018 09:36 AM, AKASHI Takahiro wrote:
>
> This patch is missing a patch description. I'm not the maintainer of the rtc
> code base so it's not my call, but I personally just reject all patches with
> empty patch descriptions ;).
>
> And thanks a lot for doing the conversion! I think it's a very good step
> forward.
>
> >Signed-off-by: AKASHI Takahiro
> >---
> > drivers/rtc/Kconfig | 6 ++
> > drivers/rtc/pl031.c | 109 +--
> > include/dm/platform_data/rtc_pl031.h | 12 +++
> > 3 files changed, 87 insertions(+), 40 deletions(-)
> > create mode 100644 include/dm/platform_data/rtc_pl031.h
> >
> >diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> >index a3f8c8aecc..96c4cce410 100644
> >--- a/drivers/rtc/Kconfig
> >+++ b/drivers/rtc/Kconfig
> >@@ -55,6 +55,12 @@ config RTC_MV
> > Enable Marvell RTC driver. This driver supports the rtc that is
> > present
> > on some Marvell SoCs.
> >+config RTC_PL031
> >+bool "Enable ARM PL031 driver"
> >+depends on DM_RTC
> >+help
> >+ Enable ARM PL031 driver.
> >+
> > config RTC_S35392A
> > bool "Enable S35392A driver"
> > select BITREVERSE
> >diff --git a/drivers/rtc/pl031.c b/drivers/rtc/pl031.c
> >index 8955805e3b..eecade8374 100644
> >--- a/drivers/rtc/pl031.c
> >+++ b/drivers/rtc/pl031.c
> >@@ -8,14 +8,10 @@
> > #include
> > #include
> >+#include
> >+#include
> > #include
> >-#if defined(CONFIG_CMD_DATE)
> >-
> >-#ifndef CONFIG_SYS_RTC_PL031_BASE
> >-#error CONFIG_SYS_RTC_PL031_BASE is not defined!
> >-#endif
> >-
> > /*
> > * Register definitions
> > */
> >@@ -30,78 +26,111 @@
> > #define RTC_CR_START (1 << 0)
> >-#define RTC_WRITE_REG(addr, val) \
> >-(*(volatile unsigned int *)(CONFIG_SYS_RTC_PL031_BASE +
> >(addr)) = (val))
> >-#define RTC_READ_REG(addr) \
> >-(*(volatile unsigned int *)(CONFIG_SYS_RTC_PL031_BASE +
> >(addr)))
> >+#define RTC_WRITE_REG(base, addr, val) \
> >+(*(volatile unsigned int *)((base) + (addr)) = (val))
>
> Any particular reason you don't pass in pdata? While at it you could then
> also convert the macros into inline functions. That would make the code
> slightly more readable and result in pretty much the same binary output.
>
> Also, you don't want to have the explicit casts here as they may get
> compiled into something that is not explicitly valid as MMIO access opcode.
> Instead, please convert it to readl()/writel() while you're at it.
OK.
> >+#define RTC_READ_REG(base, addr)\
> >+(*(volatile unsigned int *)((base) + (addr)))
> > static int pl031_initted = 0;
> > /* Enable RTC Start in Control register*/
> >-void rtc_init(void)
> >+void pl031_rtc_init(struct pl031_rtc_platdata *pdata)
>
> Does this have to be global still? I guess we can now make this function
> static, no?
See the comment below.
> > {
> >-RTC_WRITE_REG(RTC_CR, RTC_CR_START);
> >+RTC_WRITE_REG(pdata->base, RTC_CR, RTC_CR_START);
> > pl031_initted = 1;
> > }
> > /*
> >- * Reset the RTC. We set the date back to 1970-01-01.
> >+ * Get the current time from the RTC
> > */
> >-void rtc_reset(void)
> >+static int pl031_rtc_get(struct udevice *dev, struct rtc_time *tm)
> > {
> >-RTC_WRITE_REG(RTC_LR, 0x00);
> >-if(!pl031_initted)
> >-rtc_init();
> >+struct pl031_rtc_platdata *pdata = dev_get_platdata(dev);
> >+ulong tim;
> >+
> >+if (!tm) {
> >+puts("Error getting the date/time\n");
> >+return -1;
> >+}
> >+
> >+if (!pl031_initted)
>
> In theory with dm you can now have multiple instances of the device, right?
('date' command assumes that there is only one RTC device on system.)
> So we can no longer have a global variable that indicates if a device is
> initialized. Instead, this needs to move into device private data.
As Tuomas suggested, init routine should go into probe function,
so this global will be no longer needed.
>
> >+pl031_rtc_init(pdata);
> >+
> >+tim = RTC_READ_REG(pdata->base, RTC_DR);
> >+
> >+rtc_to_tm(tim, tm);
> >+
> >+debug("Get DATE: %4d-%02d-%02d (wday=%d) TIME: %2d:%02d:%02d\n",
> >+tm->tm_year, tm->tm_mon, tm->tm_mday, tm->tm_wday,
> >+tm->tm_hour, tm->tm_min, tm->tm_sec);
> >+
> >+return 0;
> > }
> > /*
> > * Set the RTC
> >-*/
> >-int rtc_set(struct rtc_time *tmp)
> >+ */
> >+static int pl031_rtc_set(struct udevice *dev, const struct rtc_time *tm)
> > {
> >+struct pl031_rtc_platdata *pdata = dev_get_platdata(dev);
> > unsigned long tim;
> >-if(!pl031_initted)
> >-rtc_init();
> >-
> >-if (tmp == NULL) {
> >+if (!tm) {
> > puts("Error setting the date/time\n");
> > return -1;
> > }
> >+if (!pl031_initted)
> >+
Re: [U-Boot] [PATCH 1/2] arm: timer: factor out FSL arch timer erratum workaround
Hi, On 03/07/18 21:51, Andreas Färber wrote: > Am 03.07.2018 um 01:08 schrieb Andreas Färber: >> Am 02.07.2018 um 10:01 schrieb Jagan Teki: >>> On Wed, Jun 27, 2018 at 6:12 AM, Andre Przywara >>> wrote: At the moment we have the workaround for the Freescale arch timer erratum A-008585 merged into the generic timer_read_counter() routine. Split those two up, so that we can add other errata workaround more easily. Also add an explaining comment on the way. Signed-off-by: Andre Przywara --- >>> >>> Applied both patches, to u-boot-sunxi/master >> >> Tested both on top of v2018.07-rc2, fixes the boot for me. > > Actually I saw it again just now, without having touched U-Boot at all. > Unplugged power, retried, worked. So it seems we've reduced the > likelihood, but something might still be astray... There are reports for that happening on the kernel side as well: http://lists.infradead.org/pipermail/linux-arm-kernel/2018-July/588288.html (also see the follow-ups) I suspect the TVAL access is affected as well (this internally accesses the counter), so we would need to cover this also. I'd suggest we wait for the kernel side solution and then copy that, but we keep this patch here in, as it seems to fix far more frequent problems. Btw: I tried to use the Freescale workaround in U-Boot, but this at least requires another patch: to fix the problem when the CPU runs at 24MHz. Also it doesn't really help the MMC issue (I saw the same crashes), as it doesn't cover forward jumps. Cheers, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Support of device-tree for PowerPC platform: Query
Hi Jagdish, On Thu, Jul 5, 2018 at 1:31 PM, Jagdish Gediya wrote: > Hi Bin, > >> -Original Message- >> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Bin Meng >> Sent: Tuesday, July 3, 2018 8:11 PM >> To: Prabhakar Kushwaha >> Cc: u-boot@lists.denx.de >> Subject: Re: [U-Boot] Support of device-tree for PowerPC platform: Query >> >> Hi Prabhakar, >> >> On Mon, Jul 2, 2018 at 11:27 PM, Prabhakar Kushwaha >> wrote: >> > Dear Bin, >> > >> > Coming back to x86 example. >> > >> >> -Original Message- >> >> From: Bin Meng [mailto:bmeng...@gmail.com] >> >> Sent: Friday, June 29, 2018 7:03 AM >> >> To: York Sun >> >> Cc: Simon Glass ; Prabhakar Kushwaha >> >> ; u-boot@lists.denx.de >> >> Subject: Re: [U-Boot] Support of device-tree for PowerPC platform: >> >> Query >> >> >> >> Hi York, >> >> >> >> On Thu, Jun 28, 2018 at 11:32 PM, York Sun wrote: >> >> > On 06/27/2018 10:53 PM, Bin Meng wrote: >> >> > >> >> >> >> >> >>> Can the DT perhaps go before U-Boot in the flash? We would need a >> >> >>> way to find it though. >> >> >>> >> >> >> >> >> >> I don't see any issue that DT go after U-Boot in the flash. x86 >> >> >> does this way, and its reset vector is also the last address of flash. >> >> >> >> >> > >> >> > Big issue. e500 runs from the last address of the flash. We cannot >> >> > put DT after U-Boot. >> >> >> >> Looks you did not get it. I know e500 reset vector is the last 4 bytes >> >> below >> 4G. >> >> This is similar to x86. DTB can be put after the u-boot image without >> >> reset vector. You may check how x86 does this. >> >> >> > >> > I tried to search thing for x86 but did not succeed ☹ >> > >> >> You can test x86 build easily with QEMU. >> >> $ make qemu-x86_defconfig >> $ make V=1 >> >> This way you can see how u-boot.rom image is built. >> >> > I request you to help me with sample code and boot flow. >> > I will try to understand and see how it can help PowerPC. >> > >> >> Please see the sample build flow below: >> >> 1. objcopy --gap-fill=0xff -O binary -R .start16 -R .resetvec u-boot >> u-boot- >> nodtb.bin >> >> .start16 and .resetvec is the x86 boot vector. This is similar to PPC >> BookE's reset >> vector. These two sections are removed to generate a new u-boot-nodtb >> binary. >> >> 2. cat arch/x86/dts/qemu-x86_i440fx.dtb > dts/dt.dtb >> cat u-boot-nodtb.bin dts/dt.dtb > u-boot-dtb.bin >> >> Append dtb to the end of the u-boot-nodtb binary and get a new u-boot-dtb >> binary. >> >> 3. cp dts/dt.dtb u-boot.dtb >> objcopy --gap-fill=0xff -O binary -j .start16 -j .resetvec u-boot >> u-boot-x86- >> 16bit.bin >> >> Create a binary which contains the reset vector. >> >> 4. ./tools/binman/binman -d u-boot.dtb -O . -I . -I >> ./board/emulation/qemu-x86 u-boot-x86-16bit.bin >> >> Use binman to assemble the final u-boot.rom image. > > Wouldn't it be similar to CONFIG_OF_EMBED as dtb is embedded in final > binary(before start and resetvec sections)? It's similar, but they are different things. CONFIG_OF_EMBED builds dts into the data section of U-Boot image while CONFIG_OF_SEPARATE does not. Both should be supported in PowerPC IMO. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/2] dm: mdio: add a uclass for MDIO
On 05.07.2018 09:34, m...@marvell.com wrote: From: Ken Ma Add a uclass which provides access to MDIO busses and includes operations required by MDIO. The implementation is based on the existing mii/phy/mdio data structures and APIs. This patch also adds device tree binding for MDIO bus. Signed-off-by: Ken Ma Reviewed-by: s...@chromium.org, joe.hershber...@ni.com --- Changes in v4: - Minor updates for comments and Maintainer. Changes in v3: - Move mdio uclass implementation to driver/net folder; - Replace flat-tree functions with livetree functions and update codes and comments to be consistent with driver-model codes style; - Put struct mii_dev to uclass platdata to avoid the mdio alloc and let driver model framework to alloc the memroy automatically, meanwhile the mii bus link initialization is added. Changes in v2: - Fix error printing: - Change some debug to pr_err; - mii bus has no parent member and it is not a udevice, so dev_err is changed to pr_err for mii bus error printings. MAINTAINERS | 1 + doc/device-tree-bindings/net/mdio-bus.txt | 54 ++ drivers/Kconfig | 2 + drivers/net/Makefile | 1 + drivers/net/mdio/Kconfig | 18 + drivers/net/mdio/Makefile | 6 ++ drivers/net/mdio/mdio-uclass.c| 112 ++ include/dm/uclass-id.h| 1 + include/net/mdio.h| 62 + 9 files changed, 257 insertions(+) create mode 100644 doc/device-tree-bindings/net/mdio-bus.txt create mode 100644 drivers/net/mdio/Kconfig create mode 100644 drivers/net/mdio/Makefile create mode 100644 drivers/net/mdio/mdio-uclass.c create mode 100644 include/net/mdio.h Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] mdio: add marvell MDIO driver
On 05.07.2018 09:34, m...@marvell.com wrote: From: Ken Ma This patch adds a separate driver for the MDIO interface of the Marvell Ethernet controllers based on driver model. There are two reasons to have a separate driver rather than including it inside the MAC driver itself: *) The MDIO interface is shared by all Ethernet ports, so a driver must guarantee non-concurrent accesses to this MDIO interface. The most logical way is to have a separate driver that handles this single MDIO interface, used by all Ethernet ports. *) The MDIO interface is the same between the existing mv643xx_eth driver and the new mvneta/mvpp2 driver. Even though it is for now only used by the mvneta/mvpp2 driver, it will in the future be used by the mv643xx_eth driver as well. This driver supports SMI IEEE for 802.3 Clause 22 and XSMI for IEEE 802.3 Clause 45. This patch also adds device tree binding for marvell MDIO driver. Signed-off-by: Ken Ma Reviewed-by: Chris Packham --- Changes in v4: - Use wait_for_bit_le32() instead of implementing private busy wait polling function. Changes in v3: - Move marvell mdio driver to driver/net/mdio folder; - Update codes according to mdio uclass implementation updates. Changes in v2: - Fix error printing: - Change some debug to pr_err; - mii bus has no parent member and it is not a udevice, so dev_err is changed to pr_err for mii bus error printings. MAINTAINERS | 1 + arch/arm/Kconfig | 1 + doc/device-tree-bindings/net/marvell-mdio.txt | 18 +++ drivers/net/mdio/Kconfig | 10 ++ drivers/net/mdio/Makefile | 1 + drivers/net/mdio/mvmdio.c | 200 ++ 6 files changed, 231 insertions(+) create mode 100644 doc/device-tree-bindings/net/marvell-mdio.txt create mode 100644 drivers/net/mdio/mvmdio.c Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 1/2] dm: mdio: add a uclass for MDIO
From: Ken Ma
Add a uclass which provides access to MDIO busses and includes
operations required by MDIO.
The implementation is based on the existing mii/phy/mdio data
structures and APIs.
This patch also adds device tree binding for MDIO bus.
Signed-off-by: Ken Ma
Reviewed-by: s...@chromium.org, joe.hershber...@ni.com
---
Changes in v4:
- Minor updates for comments and Maintainer.
Changes in v3:
- Move mdio uclass implementation to driver/net folder;
- Replace flat-tree functions with livetree functions and update codes
and comments to be consistent with driver-model codes style;
- Put struct mii_dev to uclass platdata to avoid the mdio alloc and
let driver model framework to alloc the memroy automatically,
meanwhile the mii bus link initialization is added.
Changes in v2:
- Fix error printing:
- Change some debug to pr_err;
- mii bus has no parent member and it is not a udevice, so dev_err
is changed to pr_err for mii bus error printings.
MAINTAINERS | 1 +
doc/device-tree-bindings/net/mdio-bus.txt | 54 ++
drivers/Kconfig | 2 +
drivers/net/Makefile | 1 +
drivers/net/mdio/Kconfig | 18 +
drivers/net/mdio/Makefile | 6 ++
drivers/net/mdio/mdio-uclass.c| 112 ++
include/dm/uclass-id.h| 1 +
include/net/mdio.h| 62 +
9 files changed, 257 insertions(+)
create mode 100644 doc/device-tree-bindings/net/mdio-bus.txt
create mode 100644 drivers/net/mdio/Kconfig
create mode 100644 drivers/net/mdio/Makefile
create mode 100644 drivers/net/mdio/mdio-uclass.c
create mode 100644 include/net/mdio.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 642c448..07f7c66 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -432,6 +432,7 @@ M: Joe Hershberger
S: Maintained
T: git git://git.denx.de/u-boot-net.git
F: drivers/net/
+F: drivers/net/mdio/
F: net/
NIOS
diff --git a/doc/device-tree-bindings/net/mdio-bus.txt
b/doc/device-tree-bindings/net/mdio-bus.txt
new file mode 100644
index 000..68d8b25
--- /dev/null
+++ b/doc/device-tree-bindings/net/mdio-bus.txt
@@ -0,0 +1,54 @@
+MDIO (Management Data Input/Output) busses
+
+MDIO busses can be described with a node for the MDIO master device
+and a set of child nodes for each phy on the bus.
+
+The MDIO node requires the following properties:
+- #address-cells - number of cells required to define phy address on
+the MDIO bus.
+- #size-cells - should be zero.
+- compatible - name of MDIO bus controller following generic names
+recommended practice.
+- reg- address and length of the MDIO register.
+
+Optional property:
+- mdio-name - MDIO bus name
+
+The child nodes of the MDIO driver are the individual PHY devices
+connected to this MDIO bus. They must have a "reg" property given the
+PHY address on the MDIO bus.
+- reg - (required) phy address in MDIO bus.
+
+Example for cp110 MDIO node at the SoC level:
+ cp0_mdio: mdio@12a200 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,orion-mdio";
+ reg = <0x12a200 0x10>;
+ mdio-name = "cp0-mdio";
+ };
+
+ cp0_xmdio: mdio@12a600 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,xmdio";
+ reg = <0x12a600 0x200>;
+ mdio-name = "cp0-xmdio";
+ };
+
+And at the board level, example for armada-8040-mcbin board:
+ _mdio {
+ ge_phy: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+
+ _xmdio {
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+
+ phy8: ethernet-phy@8 {
+ reg = <8>;
+ };
+ };
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 9e21b28..0e0982c 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -54,6 +54,8 @@ source "drivers/mtd/Kconfig"
source "drivers/net/Kconfig"
+source "drivers/net/mdio/Kconfig"
+
source "drivers/nvme/Kconfig"
source "drivers/pci/Kconfig"
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 584bfdf..1cda03f 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -70,3 +70,4 @@ obj-$(CONFIG_VSC9953) += vsc9953.o
obj-$(CONFIG_PIC32_ETH) += pic32_mdio.o pic32_eth.o
obj-$(CONFIG_DWC_ETH_QOS) += dwc_eth_qos.o
obj-$(CONFIG_FSL_PFE) += pfe_eth/
+obj-$(CONFIG_MDIO) += mdio/
diff --git a/drivers/net/mdio/Kconfig b/drivers/net/mdio/Kconfig
new file mode 100644
index 000..c065baa
--- /dev/null
+++ b/drivers/net/mdio/Kconfig
@@ -0,0 +1,18 @@
+#
+# MDIO infrastructure and drivers
+#
+
+menu "MDIO Support"
+
+config MDIO
+ bool "Enable MDIO (Management Data
[U-Boot] [PATCH v4 2/2] mdio: add marvell MDIO driver
From: Ken Ma This patch adds a separate driver for the MDIO interface of the Marvell Ethernet controllers based on driver model. There are two reasons to have a separate driver rather than including it inside the MAC driver itself: *) The MDIO interface is shared by all Ethernet ports, so a driver must guarantee non-concurrent accesses to this MDIO interface. The most logical way is to have a separate driver that handles this single MDIO interface, used by all Ethernet ports. *) The MDIO interface is the same between the existing mv643xx_eth driver and the new mvneta/mvpp2 driver. Even though it is for now only used by the mvneta/mvpp2 driver, it will in the future be used by the mv643xx_eth driver as well. This driver supports SMI IEEE for 802.3 Clause 22 and XSMI for IEEE 802.3 Clause 45. This patch also adds device tree binding for marvell MDIO driver. Signed-off-by: Ken Ma Reviewed-by: Chris Packham --- Changes in v4: - Use wait_for_bit_le32() instead of implementing private busy wait polling function. Changes in v3: - Move marvell mdio driver to driver/net/mdio folder; - Update codes according to mdio uclass implementation updates. Changes in v2: - Fix error printing: - Change some debug to pr_err; - mii bus has no parent member and it is not a udevice, so dev_err is changed to pr_err for mii bus error printings. MAINTAINERS | 1 + arch/arm/Kconfig | 1 + doc/device-tree-bindings/net/marvell-mdio.txt | 18 +++ drivers/net/mdio/Kconfig | 10 ++ drivers/net/mdio/Makefile | 1 + drivers/net/mdio/mvmdio.c | 200 ++ 6 files changed, 231 insertions(+) create mode 100644 doc/device-tree-bindings/net/marvell-mdio.txt create mode 100644 drivers/net/mdio/mvmdio.c diff --git a/MAINTAINERS b/MAINTAINERS index 07f7c66..d737aed 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -137,6 +137,7 @@ T: git git://git.denx.de/u-boot-marvell.git F: arch/arm/mach-kirkwood/ F: arch/arm/mach-mvebu/ F: drivers/ata/ahci_mvebu.c +F: drivers/net/mdio/mvmdio.c ARM MARVELL PXA M: Marek Vasut diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index dde422b..e52b164 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -432,6 +432,7 @@ config ARCH_MVEBU select DM_SPI select DM_SPI_FLASH select SPI + select MDIO config TARGET_DEVKIT3250 bool "Support devkit3250" diff --git a/doc/device-tree-bindings/net/marvell-mdio.txt b/doc/device-tree-bindings/net/marvell-mdio.txt new file mode 100644 index 000..55db435 --- /dev/null +++ b/doc/device-tree-bindings/net/marvell-mdio.txt @@ -0,0 +1,18 @@ +* Marvell MDIO Ethernet Controller interface + +The Ethernet controllers of the Marvel Armada 3700 and Armada 7k/8k +have an identical unit that provides an interface with the MDIO bus. +This driver handles this MDIO interface. + +Mandatory properties: +SoC specific: + - #address-cells: Must be <1>. + - #size-cells: Must be <0>. + - compatible: Should be "marvell,orion-mdio" (for SMI) + "marvell,xmdio" (for XSMI) + - reg: Base address and size SMI/XMSI bus. + +Optional properties: + - mdio-name - MDIO bus name + +For example, please refer to "mdio-bus.txt". diff --git a/drivers/net/mdio/Kconfig b/drivers/net/mdio/Kconfig index c065baa..a2271e0 100644 --- a/drivers/net/mdio/Kconfig +++ b/drivers/net/mdio/Kconfig @@ -15,4 +15,14 @@ config MDIO udevice or mii bus from its child phy node or an ethernet udevice which the phy belongs to. +config MVMDIO + bool "Marvell MDIO interface support" + depends on MDIO + select PHYLIB + help + This driver supports the MDIO interface found in the network + interface units of the Marvell EBU SoCs (Kirkwood, Orion5x, + Dove, Armada 370, Armada XP, Armada 37xx and Armada7K/8K/8KP). + + This driver is used by the MVPP2 and MVNETA drivers. endmenu diff --git a/drivers/net/mdio/Makefile b/drivers/net/mdio/Makefile index 45ae502..8b2e5a4 100644 --- a/drivers/net/mdio/Makefile +++ b/drivers/net/mdio/Makefile @@ -4,3 +4,4 @@ # Author: Ken Ma obj-$(CONFIG_MDIO) += mdio-uclass.o +obj-$(CONFIG_MVMDIO) += mvmdio.o diff --git a/drivers/net/mdio/mvmdio.c b/drivers/net/mdio/mvmdio.c new file mode 100644 index 000..57224b5 --- /dev/null +++ b/drivers/net/mdio/mvmdio.c @@ -0,0 +1,200 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2018 Marvell International Ltd. + * Author: Ken Ma + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#define MVMDIO_SMI_DATA_SHIFT 0 +#define MVMDIO_SMI_PHY_ADDR_SHIFT 16 +#define MVMDIO_SMI_PHY_REG_SHIFT 21 +#define MVMDIO_SMI_READ_OPERATION BIT(26) +#define MVMDIO_SMI_WRITE_OPERATION
[U-Boot] [PATCH v4 0/2] Add MDIO driver model support
From: Ken Ma Changes in v4: - Minor updates for comments and Maintainer. - Use wait_for_bit_le32() instead of implementing private busy wait polling function. Changes in v3: - Move mdio uclass implementation to driver/net folder; - Replace flat-tree functions with livetree functions and update codes and comments to be consistent with driver-model codes style; - Put struct mii_dev to uclass platdata to avoid the mdio alloc and let driver model framework to alloc the memroy automatically, meanwhile the mii bus link initialization is added. - Move marvell mdio driver to driver/net/mdio folder; - Update codes according to mdio uclass implementation updates. Changes in v2: - Fix error printing: - Change some debug to pr_err; - mii bus has no parent member and it is not a udevice, so dev_err is changed to pr_err for mii bus error printings. - Fix error printing: - Change some debug to pr_err; - mii bus has no parent member and it is not a udevice, so dev_err is changed to pr_err for mii bus error printings. Ken Ma (2): dm: mdio: add a uclass for MDIO mdio: add marvell MDIO driver MAINTAINERS | 2 + arch/arm/Kconfig | 1 + doc/device-tree-bindings/net/marvell-mdio.txt | 18 +++ doc/device-tree-bindings/net/mdio-bus.txt | 54 +++ drivers/Kconfig | 2 + drivers/net/Makefile | 1 + drivers/net/mdio/Kconfig | 28 drivers/net/mdio/Makefile | 7 + drivers/net/mdio/mdio-uclass.c| 112 +++ drivers/net/mdio/mvmdio.c | 200 ++ include/dm/uclass-id.h| 1 + include/net/mdio.h| 62 12 files changed, 488 insertions(+) create mode 100644 doc/device-tree-bindings/net/marvell-mdio.txt create mode 100644 doc/device-tree-bindings/net/mdio-bus.txt create mode 100644 drivers/net/mdio/Kconfig create mode 100644 drivers/net/mdio/Makefile create mode 100644 drivers/net/mdio/mdio-uclass.c create mode 100644 drivers/net/mdio/mvmdio.c create mode 100644 include/net/mdio.h -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH v3 1/2] dm: mdio: add a uclass for MDIO
Hi Joe
Please see my comments inline, thanks a lot for your kind and careful review!
Yours,
Ken
-Original Message-
From: Joe Hershberger [mailto:joe.hershber...@ni.com]
Sent: 2018年6月20日 4:59
To: Ken Ma ; Simon Glass
Cc: U-Boot Mailing List ; Andy Shevchenko
; Eugeniy Paltsev
; Michal Simek ;
Alexander Graf ; Joe Hershberger ;
Heinrich Schuchardt ; Stefan Roese ; Chris
Packham
Subject: [EXT] Re: [U-Boot] [PATCH v3 1/2] dm: mdio: add a uclass for MDIO
External Email
--
On Tue, Jun 12, 2018 at 11:33 PM, wrote:
> From: Ken Ma
>
> Add a uclass which provides access to MDIO busses and includes
> operations required by MDIO.
> The implementation is based on the existing mii/phy/mdio data
> structures and APIs.
> This patch also adds evice tree binding for MDIO bus.
>
> Signed-off-by: Ken Ma
> Reviewed-by: s...@chromium.org, joe.hershber...@ni.com
> ---
>
> Changes in v3:
> - Move mdio uclass implementation to driver/net folder;
> - Replace flat-tree functions with livetree functions and update codes
> and comments to be consistent with driver-model codes style;
> - Put struct mii_dev to uclass platdata to avoid the mdio alloc and
> let driver model framework to alloc the memroy automatically,
> meanwhile the mii bus link initialization is added,
>
> Changes in v2: None
>
> MAINTAINERS | 1 +
> doc/device-tree-bindings/net/mdio-bus.txt | 54 ++
> drivers/Kconfig | 2 +
> drivers/net/Makefile | 1 +
> drivers/net/mdio/Kconfig | 18 +
> drivers/net/mdio/Makefile | 6 ++
> drivers/net/mdio/mdio-uclass.c| 112
> ++
> include/dm/uclass-id.h| 1 +
> include/net/mdio.h| 62 +
> 9 files changed, 257 insertions(+)
> create mode 100644 doc/device-tree-bindings/net/mdio-bus.txt
> create mode 100644 drivers/net/mdio/Kconfig create mode 100644
> drivers/net/mdio/Makefile create mode 100644
> drivers/net/mdio/mdio-uclass.c create mode 100644 include/net/mdio.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS index 642c448..9e1fc83 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -335,6 +335,7 @@ M: Simon Glass
I think it makes sense for me to maintain this, unless Simon really wants it.
He's not even Cc'ed, so maybe he doesn't know you are assigning it to him?
Adding him.
[Ken] Thank you for your remind, at first I do not put mdio under driver/net
and I could not find a person to mainline it, so I add Simon as maintainer. I
will update the maintainer to you. Thanks a lot!
> S: Maintained
> T: git git://git.denx.de/u-boot-dm.git
> F: drivers/core/
> +F: drivers/net/mdio/
> F: include/dm/
> F: test/dm/
>
> diff --git a/doc/device-tree-bindings/net/mdio-bus.txt
> b/doc/device-tree-bindings/net/mdio-bus.txt
> new file mode 100644
> index 000..68d8b25
> --- /dev/null
> +++ b/doc/device-tree-bindings/net/mdio-bus.txt
Is it reasonable to use Documentation/devicetree/bindings/net/mdio.txt
from Linux?
[Ken] Linux struct mii_bus implements reset_delay_us and reset_gpiod as
optional properties while u-boot struct mii_bus has no such fields at all.
Once uboot struct mii_bus contains reset_delay_us and reset_gpiod, we can add
the related part in mdio_uclass.c and mdio_bus.txt.
BTW, I add optional property of mdio name to the txt.
And u-boot mdio is based on uclass and actually it's a bus, so I follow
spi_bus.txt(in uboot) naming and name it to mdio_bus.txt.
> @@ -0,0 +1,54 @@
> +MDIO (Management Data Input/Output) busses
> +
> +MDIO busses can be described with a node for the MDIO master device
> +and a set of child nodes for each phy on the bus.
> +
> +The MDIO node requires the following properties:
> +- #address-cells - number of cells required to define phy address on
> +the MDIO bus.
> +- #size-cells - should be zero.
> +- compatible - name of MDIO bus controller following generic names
> +recommended practice.
> +- reg- address and length of the MDIO register.
> +
> +Optional property:
> +- mdio-name - MDIO bus name
> +
> +The child nodes of the MDIO driver are the individual PHY devices
> +connected to this MDIO bus. They must have a "reg" property given the
> +PHY address on the MDIO bus.
> +- reg - (required) phy address in MDIO bus.
> +
> +Example for cp110 MDIO node at the SoC level:
> + cp0_mdio: mdio@12a200 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "marvell,orion-mdio";
> + reg = <0x12a200 0x10>;
> + mdio-name = "cp0-mdio";
> + };
> +
> + cp0_xmdio: mdio@12a600 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
Re: [U-Boot] [PATCH v2 1/2] rtc: pl031: convert the driver to driver model
On Wed, Jul 04, 2018 at 02:35:19PM +0300, Tuomas Tynkkynen wrote:
> Hi Akashi,
>
> Thank you for the DM conversion.
>
> On 07/04/2018 10:36 AM, AKASHI Takahiro wrote:
> <..snip..>
> >diff --git a/include/dm/platform_data/rtc_pl031.h
> >b/include/dm/platform_data/rtc_pl031.h
> >new file mode 100644
> >index 00..8e4ba1ce69
> >--- /dev/null
> >+++ b/include/dm/platform_data/rtc_pl031.h
> >@@ -0,0 +1,12 @@
> >+/* SPDX-License-Identifier: GPL-2.0+ */
> >+
> >+#ifndef __rtc_pl031_h
> >+#define __rtc_pl031_h
> >+
> >+#include
> >+
> >+struct pl031_rtc_platdata {
> >+phys_addr_t base;
> >+};
> >+
> >+#endif
> >
>
> I think this file won't be necessary, the structure can stay private to
> pl031.c.
> PL031 is an ARM IP block and U-Boot on ARM uses the device tree to locate
> devices.
I think that you are suggesting we would use udevice.priv instead of
udevice.platdata, right? That will be fine with device-tree based devices.
But don't we have to take care of no-device-tree (probably legacy)
devices here?
Thanks,
-Takhairo AKASHI
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] arm: qemu-arm: enable PL031 (RTC) in defconfig
On Wed, Jul 04, 2018 at 12:25:34PM +0200, Heinrich Schuchardt wrote: > On 07/04/2018 10:56 AM, Alexander Graf wrote: > > On 07/04/2018 09:36 AM, AKASHI Takahiro wrote: > >> Signed-off-by: AKASHI Takahiro > >> --- > >> configs/qemu_arm64_defconfig | 2 ++ > >> configs/qemu_arm_defconfig | 2 ++ > >> 2 files changed, 4 insertions(+) > >> > >> diff --git a/configs/qemu_arm64_defconfig b/configs/qemu_arm64_defconfig > >> index cdf5072fe4..f3e3963860 100644 > >> --- a/configs/qemu_arm64_defconfig > >> +++ b/configs/qemu_arm64_defconfig > >> @@ -28,3 +28,5 @@ CONFIG_USB=y > >> CONFIG_DM_USB=y > >> CONFIG_USB_EHCI_HCD=y > >> CONFIG_USB_EHCI_PCI=y > >> +CONFIG_DM_RTC=y > >> +CONFIG_RTC_PL031=y > > > > Is there any particular reason you don't just do select statements in > > the ARCH_QEMU definition? Or maybe imply? > > 'select' makes it impossible to switch configuration options off. We > should only use it if really needed. 'imply' is fine here. Basically I don't care whether those two go into defconfig or ARCH_QEMU, but as far as RTC_PL031 is concerned, it always comes with qemu's VM and "selecting" it at ARCH_QEMU is quite reasonable. Turning off this option only saves hundreds of bytes for VM. Who cares? That's said, we will go for 'imply.' For CMD_DATE, it will be automatically turned on if DM_RTC. To make RTC_PL031 independent from CMD_DATE, we also have to modify rtc/date.c's dependency (DM_RTC). > Configuration options should appear in *_defconfig files in the same > sequence as in the generated .config file. CONFIG_RTC_PL031 precedes > CONFIG_SCSI. So they will go away from *_defconfig. Thanks, -Takahiro AKASHI > Please, add a commit message to the next version of the patch. > > Best regards > > Heinrich > > > > > > > Alex > > > >> diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig > >> index bbce6cd719..28dfba0283 100644 > >> --- a/configs/qemu_arm_defconfig > >> +++ b/configs/qemu_arm_defconfig > >> @@ -28,3 +28,5 @@ CONFIG_USB=y > >> CONFIG_DM_USB=y > >> CONFIG_USB_EHCI_HCD=y > >> CONFIG_USB_EHCI_PCI=y > >> +CONFIG_DM_RTC=y > >> +CONFIG_RTC_PL031=y > > > > > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] efi_loader: EFI_SIMPLE_TEXT_INPUT_PROTOCOL.Reset()
Implement the reset service of the EFI_SIMPLE_TEXT_INPUT_PROTOCOL.
This should resolve the error reported by the SCT in
Protocol/SimpleTextIn/BlackBoxTest/SimpleTextInBBTestFunction.c:193
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_console.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index ce66c935ec..1d52753456 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -381,7 +381,12 @@ static efi_status_t EFIAPI efi_cin_reset(
bool extended_verification)
{
EFI_ENTRY("%p, %d", this, extended_verification);
- return EFI_EXIT(EFI_UNSUPPORTED);
+
+ /* Empty input buffer */
+ while (tstc())
+ getc();
+
+ return EFI_EXIT(EFI_SUCCESS);
}
/*
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] efi_loader: set revision in loaded image protocol
The revision number has to be set in the loaded image protocol.
The problem was detected by running the SCT in
Protocol/LoadedImage/BlackBoxTest/LoadedImageBBTestMain.c:890
Signed-off-by: Heinrich Schuchardt
---
include/efi_api.h | 2 ++
lib/efi_loader/efi_boottime.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/include/efi_api.h b/include/efi_api.h
index 99ea2c5b69..c98cc34908 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -321,6 +321,8 @@ struct efi_system_table {
EFI_GUID(0x5b1b31a1, 0x9562, 0x11d2, \
0x8e, 0x3f, 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
+#define EFI_LOADED_IMAGE_PROTOCOL_REVISION 0x1000
+
struct efi_loaded_image {
u32 revision;
void *parent_handle;
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 105e80bb52..9ac8e18680 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1484,6 +1484,7 @@ efi_status_t efi_setup_loaded_image(
/* efi_exit() assumes that the handle points to the info */
obj->handle = info;
+ info->revision = EFI_LOADED_IMAGE_PROTOCOL_REVISION;
info->file_path = file_path;
if (device_path) {
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] efi_loader: EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.Reset()
Implement the reset service of the EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.
This should resolve the error reported by the SCT in
Protocol/SimpleTextOut/BlackBoxTest/SimpleTextOutBBTestFunction_uefi.c:639
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_console.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 3fd0d2fd51..17aced86a5 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -110,7 +110,15 @@ static efi_status_t EFIAPI efi_cout_reset(
char extended_verification)
{
EFI_ENTRY("%p, %d", this, extended_verification);
- return EFI_EXIT(EFI_UNSUPPORTED);
+
+ /* Clear screen */
+ printf(ESC "[2J");
+ efi_con_mode.cursor_column = 0;
+ efi_con_mode.cursor_row = 0;
+ /* Set default colors */
+ printf(ESC "[0;37;40m");
+
+ return EFI_EXIT(EFI_SUCCESS);
}
static efi_status_t EFIAPI efi_cout_output_string(
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] efi_loader: clear screen has to reset cursor position
After clearing the screen the cursor position is row 0, column 0.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_console.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 1d52753456..3fd0d2fd51 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -335,6 +335,8 @@ static efi_status_t EFIAPI efi_cout_clear_screen(
EFI_ENTRY("%p", this);
printf(ESC"[2J");
+ efi_con_mode.cursor_column = 0;
+ efi_con_mode.cursor_row = 0;
return EFI_EXIT(EFI_SUCCESS);
}
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/4] efi_loader: text protocols
This patch set fixes some problems found via the SCT. Heinrich Schuchardt (4): efi_loader: set revision in loaded image protocol efi_loader: EFI_SIMPLE_TEXT_INPUT_PROTOCOL.Reset() efi_loader: clear screen has to reset cursor position efi_loader: EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.Reset() include/efi_api.h | 2 ++ lib/efi_loader/efi_boottime.c | 1 + lib/efi_loader/efi_console.c | 19 +-- 3 files changed, 20 insertions(+), 2 deletions(-) -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
