Re: [U-Boot] [PATCH] spi: designware_spi: Fix off-by-one for checking fifo depth
2014-12-19 15:35 GMT+08:00 Stefan Roese : > Hi Axel, > > > On 19.12.2014 05:40, Axel Lin wrote: >> >> The depth could be from 2 to 256 from HW spec, so fix off-by-one for >> checking >> fifo depth. >> >> Signed-off-by: Axel Lin >> --- >> Hi, >> I don't have this hardware handy, so please test it. >> drivers/spi/designware_spi.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c >> index 98c9f03..14d0c23 100644 >> --- a/drivers/spi/designware_spi.c >> +++ b/drivers/spi/designware_spi.c >> @@ -164,7 +164,7 @@ static void spi_hw_init(struct dw_spi_priv *priv) >> if (!priv->fifo_len) { >> u32 fifo; >> >> - for (fifo = 2; fifo <= 257; fifo++) { >> + for (fifo = 2; fifo <= 256; fifo++) { >> dw_writew(priv, DW_SPI_TXFLTR, fifo); >> if (fifo != dw_readw(priv, DW_SPI_TXFLTR)) >> break; > > > Please note that this code was not written by myself but is based on the > Linux kernel version. And from my current understanding, this code tries to > detect the FIFO size. So this 257 being bigger than the max value of 256 is > most likely correct. Also another 257 is a few lines below your code: > > dws->fifo_len = (fifo == 257) ? 0 : fifo; hi Stefan, After the for loop iteration with "no-match" case, the fifo variable will be 258 in original code. So above code won't catch such case. > > So I don't think that we need to change this here. > > BTW: It might be better to send this patch (or a question about this 256 vs > 257) to the SPI Linux mailing list. The maintainer there will have deeper > knowledge about this issue. Well, I'll send similar patch for linux driver for review (in spi maillist). Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spi: designware_spi: Fix off-by-one for checking fifo depth
Hi Axel, On 19.12.2014 05:40, Axel Lin wrote: The depth could be from 2 to 256 from HW spec, so fix off-by-one for checking fifo depth. Signed-off-by: Axel Lin --- Hi, I don't have this hardware handy, so please test it. drivers/spi/designware_spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c index 98c9f03..14d0c23 100644 --- a/drivers/spi/designware_spi.c +++ b/drivers/spi/designware_spi.c @@ -164,7 +164,7 @@ static void spi_hw_init(struct dw_spi_priv *priv) if (!priv->fifo_len) { u32 fifo; - for (fifo = 2; fifo <= 257; fifo++) { + for (fifo = 2; fifo <= 256; fifo++) { dw_writew(priv, DW_SPI_TXFLTR, fifo); if (fifo != dw_readw(priv, DW_SPI_TXFLTR)) break; Please note that this code was not written by myself but is based on the Linux kernel version. And from my current understanding, this code tries to detect the FIFO size. So this 257 being bigger than the max value of 256 is most likely correct. Also another 257 is a few lines below your code: dws->fifo_len = (fifo == 257) ? 0 : fifo; So I don't think that we need to change this here. BTW: It might be better to send this patch (or a question about this 256 vs 257) to the SPI Linux mailing list. The maintainer there will have deeper knowledge about this issue. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] powerpc/t1040qds: Add support of SD boot for T1040QDS Board
Add support of 2 stage SD boot loader using SPL framework. here, PBL initialise the internal SRAM and copy SPL(160KB). This further initialise DDR using SPD environment and copy u-boot(768 KB) from NAND to DDR. Finally SPL transer control to u-boot. Initialise/create followings required for SPL framework - Add spl.c which defines board_init_f, board_init_r - Update tlb and ddr accordingly Add T1040QDS_SDCARD_defconfig Update t1040_pbi.cfg to support errata A-007662, A-008007 and LAW for CPC1 Signed-off-by: Vijay Rai --- changes from v1: -Updated Kconfig to support SPL option for T1040QDS arch/powerpc/cpu/mpc85xx/Kconfig |1 + board/freescale/t1040qds/MAINTAINERS |5 ++ board/freescale/t1040qds/Makefile | 10 ++- board/freescale/t1040qds/ddr.c |5 +- board/freescale/t1040qds/spl.c | 155 board/freescale/t1040qds/t1040_pbi.cfg | 16 +++- board/freescale/t1040qds/t1040qds.c|6 +- board/freescale/t1040qds/tlb.c | 11 +++ configs/T1040QDS_SDCARD_defconfig |5 ++ include/configs/T1040QDS.h | 79 +--- 10 files changed, 273 insertions(+), 20 deletions(-) create mode 100644 board/freescale/t1040qds/spl.c create mode 100644 configs/T1040QDS_SDCARD_defconfig diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig index 7501eb4..7177c83 100644 --- a/arch/powerpc/cpu/mpc85xx/Kconfig +++ b/arch/powerpc/cpu/mpc85xx/Kconfig @@ -120,6 +120,7 @@ config TARGET_T102XRDB config TARGET_T1040QDS bool "Support T1040QDS" + select SUPPORT_SPL config TARGET_T104XRDB bool "Support T104xRDB" diff --git a/board/freescale/t1040qds/MAINTAINERS b/board/freescale/t1040qds/MAINTAINERS index 83f6b3c..44d56b6 100644 --- a/board/freescale/t1040qds/MAINTAINERS +++ b/board/freescale/t1040qds/MAINTAINERS @@ -6,6 +6,11 @@ F: include/configs/T1040QDS.h F: configs/T1040QDS_defconfig F: configs/T1040QDS_D4_defconfig +T1040QDS_SDCARD BOARD +M: Priyanka Jain +S: Maintained +F: configs/T1040QDS_SDCARD_defconfig + T1040QDS_SECURE_BOOT BOARD M: Aneesh Bansal S: Maintained diff --git a/board/freescale/t1040qds/Makefile b/board/freescale/t1040qds/Makefile index 19ed21b..27eed4c 100644 --- a/board/freescale/t1040qds/Makefile +++ b/board/freescale/t1040qds/Makefile @@ -4,10 +4,14 @@ # SPDX-License-Identifier: GPL-2.0+ # +ifdef CONFIG_SPL_BUILD +obj-y += spl.o +else obj-y += t1040qds.o -obj-y += ddr.o +obj-y += eth.o obj-$(CONFIG_PCI) += pci.o +obj-$(CONFIG_FSL_DIU_FB) += diu.o +endif +obj-y += ddr.o obj-y += law.o obj-y += tlb.o -obj-y += eth.o -obj-y += diu.o diff --git a/board/freescale/t1040qds/ddr.c b/board/freescale/t1040qds/ddr.c index 43f952f..6147430 100644 --- a/board/freescale/t1040qds/ddr.c +++ b/board/freescale/t1040qds/ddr.c @@ -104,13 +104,16 @@ phys_size_t initdram(int board_type) { phys_size_t dram_size; +#if defined(CONFIG_SPL_BUILD) || !defined(CONFIG_RAMBOOT_PBL) puts("Initializingusing SPD\n"); dram_size = fsl_ddr_sdram(); dram_size = setup_ddr_tlbs(dram_size / 0x10); dram_size *= 0x10; - puts("DDR: "); +#else + dram_size = fsl_ddr_sdram_size(); +#endif return dram_size; } diff --git a/board/freescale/t1040qds/spl.c b/board/freescale/t1040qds/spl.c new file mode 100644 index 000..b601c95 --- /dev/null +++ b/board/freescale/t1040qds/spl.c @@ -0,0 +1,155 @@ +/* Copyright 2013 Freescale Semiconductor, Inc. + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include "../common/qixis.h" +#include "t1040qds_qixis.h" +#include + +DECLARE_GLOBAL_DATA_PTR; + +phys_size_t get_effective_memsize(void) +{ + return CONFIG_SYS_L3_SIZE; +} + +unsigned long get_board_sys_clk(void) +{ + u8 sysclk_conf = QIXIS_READ(brdcfg[1]); + + switch (sysclk_conf & 0x0F) { + case QIXIS_SYSCLK_64: + return 6400; + case QIXIS_SYSCLK_83: + return 8333; + case QIXIS_SYSCLK_100: + return 1; + case QIXIS_SYSCLK_125: + return 12500; + case QIXIS_SYSCLK_133: + return 1; + case QIXIS_SYSCLK_150: + return 15000; + case QIXIS_SYSCLK_160: + return 16000; + case QIXIS_SYSCLK_166: + return 1; + } + return ; +} + +unsigned long get_board_ddr_clk(void) +{ + u8 ddrclk_conf = QIXIS_READ(brdcfg[1]); + + switch ((ddrclk_conf & 0x30) >> 4) { + case QIXIS_DDRCLK_100: + return 1; + case QIXIS_DDRCLK_125: + return 12500; + case QIXIS_DDRCLK_133: + return 1; + } + return ; +} + +#define FSL_CORE
[U-Boot] [PATCH v2 1/1] marvell: kirkwood: guruplug refresh for newer kernel
Refresh for newer kernel. Prepare ENV settings for guruplugs to be OpenWRT ready. +--+ | UBOOT| >> 896 Kb (7x128) = uboot +--+ | ENV | >> 128 Kb = uboot_env +--+ | ROOT(FS) | >> 511 Mb @ 1 Mb = root -> rootfs (ubifs) +--+ With (CC) TRUNK OpenWRT build (QUICK HOWTO) : Marvell>> nand erase.part root Marvell>> ubi part root Marvell>> ubi remove rootfs Marvell>> ubi create rootfs Marvell>> usb start Marvell>> fatload usb 2:1 0x80 guruplug/openwrt/openwrt-kirkwood-guruplugserverplus-rootfs.ubifs Marvell>> ubi write 0x80 rootfs ${filesize} Marvell>> reset Changes in v2: - Fix commit comments Changes in v1: - ADD generic board define - ADD FDT support - ADD HUSH interpreter - Define new NAND partition mapping Signed-off-by: Gerald Kerma --- include/configs/guruplug.h | 84 -- 1 file changed, 67 insertions(+), 17 deletions(-) diff --git a/include/configs/guruplug.h b/include/configs/guruplug.h index a56a4cb..8e53af8 100644 --- a/include/configs/guruplug.h +++ b/include/configs/guruplug.h @@ -1,5 +1,6 @@ /* - * (C) Copyright 2009 + * (C) Copyright 2009-2014 + * Gerald Kerma * Marvell Semiconductor * Written-by: Siddarth Gore * @@ -9,6 +10,8 @@ #ifndef _CONFIG_GURUPLUG_H #define _CONFIG_GURUPLUG_H +#define CONFIG_SYS_GENERIC_BOARD + /* * Version number information */ @@ -23,17 +26,36 @@ #define CONFIG_SKIP_LOWLEVEL_INIT /* disable board lowlevel_init */ /* + * Compression configuration + */ +#define CONFIG_BZIP2 +#define CONFIG_LZMA +#define CONFIG_LZO + +/* + * Enable device tree support + */ +#define CONFIG_OF_LIBFDT + +/* + * Miscellaneous configurable options + */ +#define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */ + +/* * Commands configuration */ #define CONFIG_SYS_NO_FLASH/* Declare no flash (NOR/SPI) */ #include +#define CONFIG_CMD_BOOTZ #define CONFIG_CMD_DHCP #define CONFIG_CMD_ENV -#define CONFIG_CMD_FAT +#define CONFIG_CMD_IDE +#define CONFIG_CMD_MII #define CONFIG_CMD_NAND #define CONFIG_CMD_PING #define CONFIG_CMD_USB -#define CONFIG_CMD_IDE +#define CONFIG_CMD_FAT /* * mv-common.h should be defined after CMD configs since it used them @@ -55,24 +77,38 @@ * it has to be rounded to sector size */ #define CONFIG_ENV_SIZE0x2 /* 128k */ -#define CONFIG_ENV_ADDR0x6 -#define CONFIG_ENV_OFFSET 0x6 /* env starts here */ +#define CONFIG_ENV_OFFSET 0xE /* env starts here */ /* * Default environment variables */ -#define CONFIG_BOOTCOMMAND "setenv ethact egiga0; " \ - "${x_bootcmd_ethernet}; setenv ethact egiga1; " \ - "${x_bootcmd_ethernet}; ${x_bootcmd_usb}; ${x_bootcmd_kernel}; "\ - "setenv bootargs ${x_bootargs} ${x_bootargs_root}; "\ - "bootm 0x640;" - -#define CONFIG_EXTRA_ENV_SETTINGS \ - "x_bootcmd_ethernet=ping 192.168.2.1\0" \ - "x_bootcmd_usb=usb start\0" \ - "x_bootcmd_kernel=nand read.e 0x640 0x10 0x40\0" \ - "x_bootargs=console=ttyS0,115200\0" \ - "x_bootargs_root=ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs\0" +#define CONFIG_BOOTCOMMAND \ + "setenv bootargs ${console} ${mtdparts} ${bootargs_root}; " \ + "ubi part root; " \ + "ubifsmount ubi:rootfs; " \ + "ubifsload 0x80 ${kernel}; "\ + "ubifsload 0x70 ${fdt}; " \ + "ubifsumount; " \ + "fdt addr 0x70; fdt resize; fdt chosen; " \ + "bootz 0x80 - 0x70" + +#define CONFIG_MTDPARTS\ + "mtdparts=orion_nand:" \ + "896K(uboot),128K(uboot_env)," \ + "-@1M(root)\0" + +#define CONFIG_EXTRA_ENV_SETTINGS \ + "console=console=ttyS0,115200\0"\ + "mtdids=nand0=orion_nand\0" \ + "mtdparts="CONFIG_MTDPARTS \ + "kernel=/boot/zImage\0" \ + "fdt=/boot/guruplug-server-plus.dtb\0" \ + "bootargs_root=ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs rw\0" + +#define MTDIDS_DEFAULT "nand0=orion_nand" + +#define MTDPARTS_DEFAULT \ + "mtdparts="CONFIG_MTDPARTS /* * Ethernet Driver configuration @@ -89,6 +125,20 @@ #define CONFIG_SYS_ATA_IDE0_OFFSET MV_SATA_PORT0_OFFSET #endif /*CONFIG_MVSATA_IDE*/ +/* + * File system + */ +#define CONFIG_CMD_EXT2 +#define CONFIG_CMD_EXT4 +#define CONFIG_CMD_FAT +#define CONFIG_CMD_JFFS2 +#def
[U-Boot] [PATCH 4/5] x86: Support PCI UART in the x86_serial driver
Newer x86 Platform Controller Hub chipset starts to integrate NS16550 compatible PCI UART devices. The board configuration file needs to supply the PCI UART vendor ID and device ID via CONFIG_PCI_UART_DEV if we want to use the PCI UART as the U-Boot serial console. Signed-off-by: Bin Meng --- drivers/serial/serial_x86.c | 30 ++ 1 file changed, 30 insertions(+) diff --git a/drivers/serial/serial_x86.c b/drivers/serial/serial_x86.c index e81e035..7ddd596 100644 --- a/drivers/serial/serial_x86.c +++ b/drivers/serial/serial_x86.c @@ -8,6 +8,17 @@ #include #include #include +#include +#include + +DECLARE_GLOBAL_DATA_PTR; + +#ifdef CONFIG_PCI_UART +static struct pci_device_id uart_supported[] = { + CONFIG_PCI_UART_DEV, + { } +}; +#endif static const struct udevice_id x86_serial_ids[] = { { .compatible = "x86-uart" }, @@ -17,6 +28,9 @@ static const struct udevice_id x86_serial_ids[] = { static int x86_serial_ofdata_to_platdata(struct udevice *dev) { struct ns16550_platdata *plat = dev_get_platdata(dev); +#ifdef CONFIG_PCI_UART + pci_dev_t devbusfn; +#endif int ret; ret = ns16550_serial_ofdata_to_platdata(dev); @@ -24,6 +38,22 @@ static int x86_serial_ofdata_to_platdata(struct udevice *dev) return ret; plat->clock = 1843200; +#ifdef CONFIG_PCI_UART + /* +* Newer x86 Platform Controller Hub chipset starts to integrate +* NS16550 compatible PCI UART devices. The board configuration +* file needs to supply the PCI UART vendor ID and device ID via +* CONFIG_PCI_UART_DEV if we want to use the PCI UART as the U-Boot +* serial console. +*/ + devbusfn = pci_early_find_devices(uart_supported, 0); + if (devbusfn == -1) + return -ENODEV; + + /* override the register base here for PCI UART */ + plat->base = pci_read_bar32(gd->arch.hose, devbusfn, 0); +#endif + return 0; } U_BOOT_DRIVER(serial_ns16550) = { -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] x86: Add PCI UART related defines in crownbay.h
The Topcliff PCH has 4 UART devices integrated (Device 10, Funciton 1/2/3/4). Add macros to enable them, but by default the legacy serial port (io addr 0x3f8) is still used on Crown Bay as the console port. Signed-off-by: Bin Meng --- include/configs/crownbay.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/configs/crownbay.h b/include/configs/crownbay.h index eadb339..7b0966e 100644 --- a/include/configs/crownbay.h +++ b/include/configs/crownbay.h @@ -23,6 +23,11 @@ #define CONFIG_X86_SERIAL #define CONFIG_SMSC_LPC47M +/* Turn on this macro if using PCI UART as the U-Boot serial console */ +#undef CONFIG_PCI_UART +#define CONFIG_PCI_UART_DEV\ + {PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_UART_1} + #define CONFIG_PCI_MEM_BUS 0x4000 #define CONFIG_PCI_MEM_PHYSCONFIG_PCI_MEM_BUS #define CONFIG_PCI_MEM_SIZE0x8000 -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] x86: Add an API for finding pci devices in the early phase
This new API pci_early_find_devices() is derived from the generic version of pci_find_devices() with modifications required in the early phase (like hose, config space access routines). Signed-off-by: Bin Meng --- arch/x86/cpu/pci.c | 41 + arch/x86/include/asm/pci.h | 2 ++ 2 files changed, 43 insertions(+) diff --git a/arch/x86/cpu/pci.c b/arch/x86/cpu/pci.c index 1eee08b..cdfb981 100644 --- a/arch/x86/cpu/pci.c +++ b/arch/x86/cpu/pci.c @@ -111,3 +111,44 @@ void pci_write_config32(pci_dev_t dev, unsigned where, unsigned value) { pci_hose_write_config_dword(get_hose(), dev, where, value); } + +pci_dev_t pci_early_find_devices(struct pci_device_id *ids, int index) +{ + struct pci_controller *hose = gd->arch.hose; + u16 vendor, device; + u8 header_type; + pci_dev_t bdf; + int i, bus, found_multi = 0; + + for (bus = hose->first_busno; bus <= hose->last_busno; bus++) + for (bdf = PCI_BDF(bus, 0, 0); +bdf < PCI_BDF(bus + 1, 0, 0); +bdf += PCI_BDF(0, 0, 1)) { + if (pci_skip_dev(hose, bdf)) + continue; + + if (!PCI_FUNC(bdf)) { + header_type = pci_read_config8(bdf, + PCI_HEADER_TYPE); + + found_multi = header_type & 0x80; + } else { + if (!found_multi) + continue; + } + + vendor = pci_read_config16(bdf, PCI_VENDOR_ID); + device = pci_read_config16(bdf, PCI_DEVICE_ID); + + for (i = 0; ids[i].vendor != 0; i++) { + if (vendor == ids[i].vendor && + device == ids[i].device) { + if (index <= 0) + return bdf; + index--; + } + } + } + + return -1; +} diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h index ac1a808..a3550fb 100644 --- a/arch/x86/include/asm/pci.h +++ b/arch/x86/include/asm/pci.h @@ -49,4 +49,6 @@ void pci_write_config8(pci_dev_t dev, unsigned where, unsigned value); void pci_write_config16(pci_dev_t dev, unsigned where, unsigned value); void pci_write_config32(pci_dev_t dev, unsigned where, unsigned value); +pci_dev_t pci_early_find_devices(struct pci_device_id *ids, int index); + #endif -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] x86: Support pci bus scan in the early phase
On x86, some peripherals on pci buses need to be accessed in the early phase (eg: pci uart) with a valid pci memory/io address, thus scan the pci bus and do the corresponding resource allocation. Signed-off-by: Bin Meng --- arch/x86/cpu/pci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/cpu/pci.c b/arch/x86/cpu/pci.c index 404fbb6..1eee08b 100644 --- a/arch/x86/cpu/pci.c +++ b/arch/x86/cpu/pci.c @@ -29,6 +29,7 @@ int pci_early_init_hose(struct pci_controller **hosep) board_pci_setup_hose(hose); pci_setup_type1(hose); + hose->last_busno = pci_hose_scan(hose); gd->arch.hose = hose; *hosep = hose; -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] x86: Support PCI based UART as the U-Boot serial console
Newer x86 Platform Controller Hub chipset (like Topcliff, BayTrail) starts to integrate NS16550 compatible PCI UART devices. In order to use them, we have to scan the PCI bus and allocate memory/io address in the early phase. On Intel Crown Bay board, there are 4 UART DB9 connectors, one of which is from the superio legacy serial port while the other 3 are connected to the Topcliff PCH UART devices. The board configuration file needs to supply the PCI UART vendor ID and device ID via CONFIG_PCI_UART_DEV if we want to use the PCI UART as the U-Boot serial console. Bin Meng (5): x86: Add missing DECLARE_GLOBAL_DATA_PTR for pci.c x86: Support pci bus scan in the early phase x86: Add an API for finding pci devices in the early phase x86: Support PCI UART in the x86_serial driver x86: Add PCI UART related defines in crownbay.h arch/x86/cpu/pci.c | 44 arch/x86/include/asm/pci.h | 2 ++ drivers/serial/serial_x86.c | 30 ++ include/configs/crownbay.h | 5 + 4 files changed, 81 insertions(+) -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] x86: Add missing DECLARE_GLOBAL_DATA_PTR for pci.c
Signed-off-by: Bin Meng --- arch/x86/cpu/pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/cpu/pci.c b/arch/x86/cpu/pci.c index f3492c3..404fbb6 100644 --- a/arch/x86/cpu/pci.c +++ b/arch/x86/cpu/pci.c @@ -15,6 +15,8 @@ #include #include +DECLARE_GLOBAL_DATA_PTR; + static struct pci_controller x86_hose; int pci_early_init_hose(struct pci_controller **hosep) -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] RFC: am35xx: Rearrange SPL on am35xx
This is an attempt to tidy up the early SPL code in an attempt to pave the way for driver model in SPL: - Avoid setting up SDRAM before board_init_f() - Avoid touching global_data before board_init_f() - Allow board_init_f() to set up a new stack (seems that the SRAM stack is not large enough on these boards) This needs more work but it does boot on Beaglebone Black. Signed-off-by: Simon Glass --- arch/arm/cpu/armv7/am33xx/board.c | 60 ++ arch/arm/cpu/armv7/lowlevel_init.S | 4 --- arch/arm/include/asm/spl.h | 3 ++ arch/arm/lib/crt0.S| 9 ++ include/configs/ti_armv7_common.h | 5 ++-- 5 files changed, 56 insertions(+), 25 deletions(-) diff --git a/arch/arm/cpu/armv7/am33xx/board.c b/arch/arm/cpu/armv7/am33xx/board.c index 29b1d73..eeea81a 100644 --- a/arch/arm/cpu/armv7/am33xx/board.c +++ b/arch/arm/cpu/armv7/am33xx/board.c @@ -275,24 +275,11 @@ static void watchdog_disable(void) ; } -void s_init(void) +static gd_t tmp_gdata __attribute__ ((section(".data"))); + +void board_init_f(ulong dummy) { - /* -* The ROM will only have set up sufficient pinmux to allow for the -* first 4KiB NOR to be read, we must finish doing what we know of -* the NOR mux in this space in order to continue. -*/ -#ifdef CONFIG_NOR_BOOT - enable_norboot_pin_mux(); -#endif - /* -* Save the boot parameters passed from romcode. -* We cannot delay the saving further than this, -* to prevent overwrites. -*/ -#ifdef CONFIG_SPL_BUILD - save_omap_boot_params(); -#endif + gd->arch.omap_boot_params = tmp_gdata.arch.omap_boot_params; watchdog_disable(); timer_init(); set_uart_mux_conf(); @@ -303,7 +290,6 @@ void s_init(void) serial_init(); gd->have_console = 1; #elif defined(CONFIG_SPL_BUILD) - gd = &gdata; preloader_console_init(); #endif #if defined(CONFIG_SPL_AM33XX_ENABLE_RTC32K_OSC) @@ -314,5 +300,43 @@ void s_init(void) board_early_init_f(); sdram_init(); #endif + /* Clear the BSS. */ + memset(__bss_start, 0, __bss_end - __bss_start); +#ifdef CONFIG_SPL_STACK_R + unsigned long start_addr_sp; + + start_addr_sp = CONFIG_SPL_STACK_R - sizeof(gd_t); + /* 8-byte alignment for ARM ABI compliance */ + start_addr_sp &= ~0x07; + memcpy((void *)start_addr_sp, (void *)gd, sizeof(gd_t)); + spl_call_board_init_r(start_addr_sp, dummy, board_init_r); +#else + board_init_r(NULL, 0); +#endif +} + +void s_init(void) +{ + gd_t *old_gd; + + /* +* The ROM will only have set up sufficient pinmux to allow for the +* first 4KiB NOR to be read, we must finish doing what we know of +* the NOR mux in this space in order to continue. +*/ +#ifdef CONFIG_NOR_BOOT + enable_norboot_pin_mux(); +#endif + old_gd = (gd_t *)gd; + gd = &tmp_gdata; + /* +* Save the boot parameters passed from romcode. +* We cannot delay the saving further than this, +* to prevent overwrites. +*/ +#ifdef CONFIG_SPL_BUILD + save_omap_boot_params(); +#endif + gd = &old_gd; } #endif diff --git a/arch/arm/cpu/armv7/lowlevel_init.S b/arch/arm/cpu/armv7/lowlevel_init.S index f1aea05..e294db9 100644 --- a/arch/arm/cpu/armv7/lowlevel_init.S +++ b/arch/arm/cpu/armv7/lowlevel_init.S @@ -21,13 +21,9 @@ ENTRY(lowlevel_init) */ ldr sp, =CONFIG_SYS_INIT_SP_ADDR bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ -#ifdef CONFIG_SPL_BUILD - ldr r9, =gdata -#else sub sp, sp, #GD_SIZE bic sp, sp, #7 mov r9, sp -#endif /* * Save the old lr(passed in ip) and the current lr to stack */ diff --git a/arch/arm/include/asm/spl.h b/arch/arm/include/asm/spl.h index 8acd7cd..66d983a 100644 --- a/arch/arm/include/asm/spl.h +++ b/arch/arm/include/asm/spl.h @@ -35,4 +35,7 @@ extern char __bss_start[], __bss_end[]; extern gd_t gdata; +void spl_call_board_init_r(ulong start_addr_sp, ulong boot_flags, + void (*board_init_r)(gd_t *new_gd, ulong dest_addr)); + #endif diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S index 22df3e5..be25fde 100644 --- a/arch/arm/lib/crt0.S +++ b/arch/arm/lib/crt0.S @@ -138,3 +138,12 @@ clbss_l:cmpr0, r1 /* while not at end of BSS */ #endif ENDPROC(_main) + +/* + * spl_call_board_init_r(start_addr_sp, dummy, board_init_r) + */ +ENTRY(spl_call_board_init_r) + mov sp, r0 + mov r9, r0 + bx r2 +ENDPROC(spl_call_board_init_r) diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h index bc75172..38c0e63 100644 --- a/include/configs/ti_armv7_common.h +++ b/include/configs/ti_armv7_common.h @@ -76,8 +76,7 @@ #define CONFIG_NR_DRAM_BANKS
[U-Boot] [PATCH 1/1] marvell: kirkwood: guruplug refresh for newer kernel
Refresh for newer kernel. Prepare ENV settings for sheevaplugs to be OpenWRT ready. +--+ | UBOOT| >> 896 Kb (7x128) = uboot +--+ | ENV | >> 128 Kb = uboot_env +--+ | ROOT(FS) | >> 511 Mb @ 1 Mb = root -> rootfs (ubifs) +--+ With (CC) TRUNK OpenWRT build (QUICK HOWTO) : Marvell>> nand erase.part root Marvell>> ubi part root Marvell>> ubi remove rootfs Marvell>> ubi create rootfs Marvell>> usb reset Marvell>> fatload usb 2:1 0x80 guruplug/openwrt/openwrt-kirkwood-guruplug-rootfs.ubifs Marvell>> ubi write 0x80 rootfs ${filesize} Marvell>> reset Changes in v1: - ADD generic board define - ADD FDT support - ADD HUSH interpreter - Define new NAND partition mapping Signed-off-by: Gerald Kerma --- include/configs/guruplug.h | 84 -- 1 file changed, 67 insertions(+), 17 deletions(-) diff --git a/include/configs/guruplug.h b/include/configs/guruplug.h index a56a4cb..8e53af8 100644 --- a/include/configs/guruplug.h +++ b/include/configs/guruplug.h @@ -1,5 +1,6 @@ /* - * (C) Copyright 2009 + * (C) Copyright 2009-2014 + * Gerald Kerma * Marvell Semiconductor * Written-by: Siddarth Gore * @@ -9,6 +10,8 @@ #ifndef _CONFIG_GURUPLUG_H #define _CONFIG_GURUPLUG_H +#define CONFIG_SYS_GENERIC_BOARD + /* * Version number information */ @@ -23,17 +26,36 @@ #define CONFIG_SKIP_LOWLEVEL_INIT /* disable board lowlevel_init */ /* + * Compression configuration + */ +#define CONFIG_BZIP2 +#define CONFIG_LZMA +#define CONFIG_LZO + +/* + * Enable device tree support + */ +#define CONFIG_OF_LIBFDT + +/* + * Miscellaneous configurable options + */ +#define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */ + +/* * Commands configuration */ #define CONFIG_SYS_NO_FLASH/* Declare no flash (NOR/SPI) */ #include +#define CONFIG_CMD_BOOTZ #define CONFIG_CMD_DHCP #define CONFIG_CMD_ENV -#define CONFIG_CMD_FAT +#define CONFIG_CMD_IDE +#define CONFIG_CMD_MII #define CONFIG_CMD_NAND #define CONFIG_CMD_PING #define CONFIG_CMD_USB -#define CONFIG_CMD_IDE +#define CONFIG_CMD_FAT /* * mv-common.h should be defined after CMD configs since it used them @@ -55,24 +77,38 @@ * it has to be rounded to sector size */ #define CONFIG_ENV_SIZE0x2 /* 128k */ -#define CONFIG_ENV_ADDR0x6 -#define CONFIG_ENV_OFFSET 0x6 /* env starts here */ +#define CONFIG_ENV_OFFSET 0xE /* env starts here */ /* * Default environment variables */ -#define CONFIG_BOOTCOMMAND "setenv ethact egiga0; " \ - "${x_bootcmd_ethernet}; setenv ethact egiga1; " \ - "${x_bootcmd_ethernet}; ${x_bootcmd_usb}; ${x_bootcmd_kernel}; "\ - "setenv bootargs ${x_bootargs} ${x_bootargs_root}; "\ - "bootm 0x640;" - -#define CONFIG_EXTRA_ENV_SETTINGS \ - "x_bootcmd_ethernet=ping 192.168.2.1\0" \ - "x_bootcmd_usb=usb start\0" \ - "x_bootcmd_kernel=nand read.e 0x640 0x10 0x40\0" \ - "x_bootargs=console=ttyS0,115200\0" \ - "x_bootargs_root=ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs\0" +#define CONFIG_BOOTCOMMAND \ + "setenv bootargs ${console} ${mtdparts} ${bootargs_root}; " \ + "ubi part root; " \ + "ubifsmount ubi:rootfs; " \ + "ubifsload 0x80 ${kernel}; "\ + "ubifsload 0x70 ${fdt}; " \ + "ubifsumount; " \ + "fdt addr 0x70; fdt resize; fdt chosen; " \ + "bootz 0x80 - 0x70" + +#define CONFIG_MTDPARTS\ + "mtdparts=orion_nand:" \ + "896K(uboot),128K(uboot_env)," \ + "-@1M(root)\0" + +#define CONFIG_EXTRA_ENV_SETTINGS \ + "console=console=ttyS0,115200\0"\ + "mtdids=nand0=orion_nand\0" \ + "mtdparts="CONFIG_MTDPARTS \ + "kernel=/boot/zImage\0" \ + "fdt=/boot/guruplug-server-plus.dtb\0" \ + "bootargs_root=ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs rw\0" + +#define MTDIDS_DEFAULT "nand0=orion_nand" + +#define MTDPARTS_DEFAULT \ + "mtdparts="CONFIG_MTDPARTS /* * Ethernet Driver configuration @@ -89,6 +125,20 @@ #define CONFIG_SYS_ATA_IDE0_OFFSET MV_SATA_PORT0_OFFSET #endif /*CONFIG_MVSATA_IDE*/ +/* + * File system + */ +#define CONFIG_CMD_EXT2 +#define CONFIG_CMD_EXT4 +#define CONFIG_CMD_FAT +#define CONFIG_CMD_JFFS2 +#define CONFIG_CMD_UBI +#define CONFIG_CMD_UBIFS +
Re: [U-Boot] [PATCH v4 18/23] ARM: Implement non-cached memory support
Hello Tom, On Thu, 18 Dec 2014 21:33:09 +, Tom Warren wrote: > Albert, > > Please pull u-boot-tegra.git/master into ARM master. ./MAKEALL -s tegra is > clean. I assume this is actually for Tom Rini, as non-core ARM trees now merge directly into mainline.1 Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] da850evm: Use generic board and libfdt, fix size for SPI flash
On 19 December 2014 at 02:54, Peter Howard wrote: > On Thu, 2014-12-18 at 12:33 +0530, Jagan Teki wrote: >> On 17 December 2014 at 06:44, Peter Howard >> wrote: >> > Add defines to use CONFIG_SYS_GENERIC_BOARD and CONFIG_OF_LIBFDT. >> > Semi-separate to this: the size of the image for the da850evm has >> > increased to the point that the size in da850evm.h and the offset for >> > the environment in SPI flash no longer work. They are modified to >> > account for the larger image size. >> > >> > Signed-off-by: Peter Howard >> > --- >> > include/configs/da850evm.h | 6 -- >> > 1 file changed, 4 insertions(+), 2 deletions(-) >> > >> > diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h >> > index e5f8afe..e5a612c 100644 >> > --- a/include/configs/da850evm.h >> > +++ b/include/configs/da850evm.h >> > @@ -157,7 +157,7 @@ >> > #define CONFIG_SPL_SPI_FLASH_SUPPORT >> > #define CONFIG_SPL_SPI_LOAD >> > #define CONFIG_SYS_SPI_U_BOOT_OFFS 0x8000 >> > -#define CONFIG_SYS_SPI_U_BOOT_SIZE 0x3 >> > +#define CONFIG_SYS_SPI_U_BOOT_SIZE 0x4 >> > #endif >> > >> > /* >> > @@ -251,7 +251,7 @@ >> > #undef CONFIG_ENV_IS_IN_NAND >> > #define CONFIG_ENV_IS_IN_SPI_FLASH >> > #define CONFIG_ENV_SIZE(64 << 10) >> > -#define CONFIG_ENV_OFFSET (256 << 10) >> > +#define CONFIG_ENV_OFFSET (512 << 10) >> >> Please make sure the proper testing of this new flash env size. >> > > What sort of testing were you thinking of? I've confirmed that it > basically works (i.e. saving/loading/editing+save) - env size is 64K, > SPI is 8MB and offset is only 512K in, so it fits. u-boot image size is > ~260K so there's plenty of room before the env. Looks fine to me, but we have some recent changes in sf which we published on master 5 days back - did you test on top of that? > > Is there something more you wanted? > > Thanks. > >> Reviewed-by: Jagannadha Sutradharudu Teki >> >> > #define CONFIG_ENV_SECT_SIZE (64 << 10) >> > #define CONFIG_SYS_NO_FLASH >> > #endif >> > @@ -259,6 +259,7 @@ >> > /* >> > * U-Boot general configuration >> > */ >> > +#define CONFIG_SYS_GENERIC_BOARD >> > #define CONFIG_MISC_INIT_R >> > #define CONFIG_BOARD_EARLY_INIT_F >> > #define CONFIG_BOOTFILE"uImage" /* Boot file name */ >> > @@ -275,6 +276,7 @@ >> > #define CONFIG_SYS_LONGHELP >> > #define CONFIG_CRC32_VERIFY >> > #define CONFIG_MX_CYCLIC >> > +#define CONFIG_OF_LIBFDT >> > >> > /* >> > * Linux Information >> > -- >> > 1.9.3 thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: remove redudant information from Kconfig files
Hi Masahiro Yamada, On 12/19/2014 01:27 PM, Masahiro Yamada wrote: - "string" type for SYS_* is defined in arch/Kconfig - SYS_CPU "armv7" has been replaced with "select CPU_V7" - SYS_SOC "tegra124" is already defined in tegra124/Kconfig Signed-off-by: Masahiro Yamada For sama5d4ek and sama5d4 xplained board. Acked-by: Bo Shen --- board/atmel/sama5d4_xplained/Kconfig | 3 --- board/atmel/sama5d4ek/Kconfig| 3 --- board/nvidia/nyan-big/Kconfig| 12 board/samsung/smdk5420/Kconfig | 3 --- board/st/stv0991/Kconfig | 8 board/sunxi/Kconfig | 1 - 6 files changed, 30 deletions(-) diff --git a/board/atmel/sama5d4_xplained/Kconfig b/board/atmel/sama5d4_xplained/Kconfig index f6440c0..f320a68 100644 --- a/board/atmel/sama5d4_xplained/Kconfig +++ b/board/atmel/sama5d4_xplained/Kconfig @@ -1,8 +1,5 @@ if TARGET_SAMA5D4_XPLAINED -config SYS_CPU - default "armv7" - config SYS_BOARD default "sama5d4_xplained" diff --git a/board/atmel/sama5d4ek/Kconfig b/board/atmel/sama5d4ek/Kconfig index a889895..7dc569c 100644 --- a/board/atmel/sama5d4ek/Kconfig +++ b/board/atmel/sama5d4ek/Kconfig @@ -1,8 +1,5 @@ if TARGET_SAMA5D4EK -config SYS_CPU - default "armv7" - config SYS_BOARD default "sama5d4ek" diff --git a/board/nvidia/nyan-big/Kconfig b/board/nvidia/nyan-big/Kconfig index 6c42bb9..341c8d7 100644 --- a/board/nvidia/nyan-big/Kconfig +++ b/board/nvidia/nyan-big/Kconfig @@ -1,24 +1,12 @@ if TARGET_NYAN_BIG -config SYS_CPU - string - default "arm720t" if SPL_BUILD - default "armv7" if !SPL_BUILD - config SYS_BOARD - string default "nyan-big" config SYS_VENDOR - string default "nvidia" -config SYS_SOC - string - default "tegra124" - config SYS_CONFIG_NAME - string default "nyan-big" endif diff --git a/board/samsung/smdk5420/Kconfig b/board/samsung/smdk5420/Kconfig index e7aafe5..2f382cd 100644 --- a/board/samsung/smdk5420/Kconfig +++ b/board/samsung/smdk5420/Kconfig @@ -1,15 +1,12 @@ if TARGET_PEACH_PI config SYS_BOARD - string default "smdk5420" config SYS_VENDOR - string default "samsung" config SYS_CONFIG_NAME - string default "peach-pi" endif diff --git a/board/st/stv0991/Kconfig b/board/st/stv0991/Kconfig index 8bda349..007712f 100644 --- a/board/st/stv0991/Kconfig +++ b/board/st/stv0991/Kconfig @@ -1,23 +1,15 @@ if TARGET_STV0991 -config SYS_CPU - string - default "armv7" - config SYS_BOARD - string default "stv0991" config SYS_VENDOR - string default "st" config SYS_SOC - string default "stv0991" config SYS_CONFIG_NAME - string default "stv0991" endif diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 246cd9a..5ae491d 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -33,7 +33,6 @@ config MACH_SUN8I endchoice config SYS_CONFIG_NAME - string default "sun4i" if MACH_SUN4I default "sun5i" if MACH_SUN5I default "sun6i" if MACH_SUN6I Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: remove redudant information from Kconfig files
- "string" type for SYS_* is defined in arch/Kconfig - SYS_CPU "armv7" has been replaced with "select CPU_V7" - SYS_SOC "tegra124" is already defined in tegra124/Kconfig Signed-off-by: Masahiro Yamada --- board/atmel/sama5d4_xplained/Kconfig | 3 --- board/atmel/sama5d4ek/Kconfig| 3 --- board/nvidia/nyan-big/Kconfig| 12 board/samsung/smdk5420/Kconfig | 3 --- board/st/stv0991/Kconfig | 8 board/sunxi/Kconfig | 1 - 6 files changed, 30 deletions(-) diff --git a/board/atmel/sama5d4_xplained/Kconfig b/board/atmel/sama5d4_xplained/Kconfig index f6440c0..f320a68 100644 --- a/board/atmel/sama5d4_xplained/Kconfig +++ b/board/atmel/sama5d4_xplained/Kconfig @@ -1,8 +1,5 @@ if TARGET_SAMA5D4_XPLAINED -config SYS_CPU - default "armv7" - config SYS_BOARD default "sama5d4_xplained" diff --git a/board/atmel/sama5d4ek/Kconfig b/board/atmel/sama5d4ek/Kconfig index a889895..7dc569c 100644 --- a/board/atmel/sama5d4ek/Kconfig +++ b/board/atmel/sama5d4ek/Kconfig @@ -1,8 +1,5 @@ if TARGET_SAMA5D4EK -config SYS_CPU - default "armv7" - config SYS_BOARD default "sama5d4ek" diff --git a/board/nvidia/nyan-big/Kconfig b/board/nvidia/nyan-big/Kconfig index 6c42bb9..341c8d7 100644 --- a/board/nvidia/nyan-big/Kconfig +++ b/board/nvidia/nyan-big/Kconfig @@ -1,24 +1,12 @@ if TARGET_NYAN_BIG -config SYS_CPU - string - default "arm720t" if SPL_BUILD - default "armv7" if !SPL_BUILD - config SYS_BOARD - string default "nyan-big" config SYS_VENDOR - string default "nvidia" -config SYS_SOC - string - default "tegra124" - config SYS_CONFIG_NAME - string default "nyan-big" endif diff --git a/board/samsung/smdk5420/Kconfig b/board/samsung/smdk5420/Kconfig index e7aafe5..2f382cd 100644 --- a/board/samsung/smdk5420/Kconfig +++ b/board/samsung/smdk5420/Kconfig @@ -1,15 +1,12 @@ if TARGET_PEACH_PI config SYS_BOARD - string default "smdk5420" config SYS_VENDOR - string default "samsung" config SYS_CONFIG_NAME - string default "peach-pi" endif diff --git a/board/st/stv0991/Kconfig b/board/st/stv0991/Kconfig index 8bda349..007712f 100644 --- a/board/st/stv0991/Kconfig +++ b/board/st/stv0991/Kconfig @@ -1,23 +1,15 @@ if TARGET_STV0991 -config SYS_CPU - string - default "armv7" - config SYS_BOARD - string default "stv0991" config SYS_VENDOR - string default "st" config SYS_SOC - string default "stv0991" config SYS_CONFIG_NAME - string default "stv0991" endif diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 246cd9a..5ae491d 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -33,7 +33,6 @@ config MACH_SUN8I endchoice config SYS_CONFIG_NAME - string default "sun4i" if MACH_SUN4I default "sun5i" if MACH_SUN5I default "sun6i" if MACH_SUN6I -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] omap: beagle_x15: add MAINTAINERS
Commit 1e4ad74b875f (beagle_x15: add board support for Beagle x15) missed to add board/ti/beagle_x15/MAINTAINERS. Signed-off-by: Masahiro Yamada Cc: Felipe Balbi --- board/ti/beagle_x15/MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) create mode 100644 board/ti/beagle_x15/MAINTAINERS diff --git a/board/ti/beagle_x15/MAINTAINERS b/board/ti/beagle_x15/MAINTAINERS new file mode 100644 index 000..3f84def --- /dev/null +++ b/board/ti/beagle_x15/MAINTAINERS @@ -0,0 +1,6 @@ +BEAGLE X15 +M: Felipe Balbi +S: Maintained +F: board/ti/beagle_x15/ +F: include/configs/beagle_x15.h +F: configs/beagle_x15_defconfig -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] stv0991: record defconfig ownership in MAINTAINERS
This commit fixes warnings reported by tools/genboardscfg.py. Signed-off-by: Masahiro Yamada Cc: Vikas Manocha --- board/st/stv0991/MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/board/st/stv0991/MAINTAINERS b/board/st/stv0991/MAINTAINERS index 87221e9..e7a2cca 100644 --- a/board/st/stv0991/MAINTAINERS +++ b/board/st/stv0991/MAINTAINERS @@ -3,3 +3,4 @@ M: Vikas Manocha S: Maintained F: board/st/stv0991/ F: include/configs/stv0991.h +F: configs/stv0991_defconfig -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dm: README: recommend u-boot.dtb to try driver-model on sandbox
To enjoy driver-model on sandbox, using device tree is recommended. While we are here, change sandbox_config to sandbox_defconfig too. Signed-off-by: Masahiro Yamada --- doc/driver-model/README.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt index 3e2f622..eafa825 100644 --- a/doc/driver-model/README.txt +++ b/doc/driver-model/README.txt @@ -36,9 +36,9 @@ How to try it Build U-Boot sandbox and run it: - make sandbox_config + make sandbox_defconfig make - ./u-boot + ./u-boot -d u-boot.dtb (type 'reset' to exit U-Boot) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] spi: designware_spi: Fix off-by-one for checking fifo depth
The depth could be from 2 to 256 from HW spec, so fix off-by-one for checking fifo depth. Signed-off-by: Axel Lin --- Hi, I don't have this hardware handy, so please test it. drivers/spi/designware_spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c index 98c9f03..14d0c23 100644 --- a/drivers/spi/designware_spi.c +++ b/drivers/spi/designware_spi.c @@ -164,7 +164,7 @@ static void spi_hw_init(struct dw_spi_priv *priv) if (!priv->fifo_len) { u32 fifo; - for (fifo = 2; fifo <= 257; fifo++) { + for (fifo = 2; fifo <= 256; fifo++) { dw_writew(priv, DW_SPI_TXFLTR, fifo); if (fifo != dw_readw(priv, DW_SPI_TXFLTR)) break; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mtd:mxs:nand support oobsize bigger than 512
If ecc chunk data size is 512 and oobsize is bigger than 512, there is a chance that block_mark_bit_offset conflicts with bch ecc area. The following graph is modified from kernel gpmi-nand.c driver with each data block 512 bytes. We can see that Block Mark conflicts with ecc area from bch view. We can enlarge the ecc chunk size to avoid this problem to those oobsize which is larger than 512. | P| |<->| | | |(Block Mark) | | P' | | | | |<--->| D | | O'| | |<->| |<->| V V V V V +---+--+-+--+-+--+-+--+-+---+ | M | data |E| data |E| data |E| data |E| | +---+--+-+--+-+--+-+--+-+---+ ^ ^ | O| |<>| P : the page size for BCH module. E : The ECC strength. G : the length of Galois Field. N : The chunk count of per page. M : the metasize of per page. C : the ecc chunk size, aka the "data" above. P': the nand chip's page size. O : the nand chip's oob size. O': the free oob. Signed-off-by: Peng Fan --- arch/arm/include/asm/imx-common/regs-bch.h | 2 ++ drivers/mtd/nand/mxs_nand.c| 33 ++ 2 files changed, 27 insertions(+), 8 deletions(-) diff --git a/arch/arm/include/asm/imx-common/regs-bch.h b/arch/arm/include/asm/imx-common/regs-bch.h index a33d341..5c47783 100644 --- a/arch/arm/include/asm/imx-common/regs-bch.h +++ b/arch/arm/include/asm/imx-common/regs-bch.h @@ -148,6 +148,7 @@ struct mxs_bch_regs { #defineBCH_FLASHLAYOUT0_ECC0_ECC30 (0xf << 12) #defineBCH_FLASHLAYOUT0_ECC0_ECC32 (0x10 << 12) #defineBCH_FLASHLAYOUT0_GF13_0_GF14_1 (1 << 10) +#defineBCH_FLASHLAYOUT0_GF13_0_GF14_1_OFFSET 10 #defineBCH_FLASHLAYOUT0_DATA0_SIZE_MASK0xfff #defineBCH_FLASHLAYOUT0_DATA0_SIZE_OFFSET 0 @@ -178,6 +179,7 @@ struct mxs_bch_regs { #defineBCH_FLASHLAYOUT1_ECCN_ECC30 (0xf << 12) #defineBCH_FLASHLAYOUT1_ECCN_ECC32 (0x10 << 12) #defineBCH_FLASHLAYOUT1_GF13_0_GF14_1 (1 << 10) +#defineBCH_FLASHLAYOUT1_GF13_0_GF14_1_OFFSET 10 #defineBCH_FLASHLAYOUT1_DATAN_SIZE_MASK0xfff #defineBCH_FLASHLAYOUT1_DATAN_SIZE_OFFSET 0 diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c index a45fcf9..0db9eb3 100644 --- a/drivers/mtd/nand/mxs_nand.c +++ b/drivers/mtd/nand/mxs_nand.c @@ -29,6 +29,7 @@ #defineMXS_NAND_DMA_DESCRIPTOR_COUNT 4 +#defineMXS_NAND_MAX_CHUNK_DATA_CHUNK_SIZE 1024 #defineMXS_NAND_CHUNK_DATA_CHUNK_SIZE 512 #if defined(CONFIG_MX6) #defineMXS_NAND_CHUNK_DATA_CHUNK_SIZE_SHIFT2 @@ -68,6 +69,8 @@ struct mxs_nand_info { }; struct nand_ecclayout fake_ecc_layout; +static int chunk_data_size = MXS_NAND_CHUNK_DATA_CHUNK_SIZE; +static int gf_len = 13; /* * Cache management functions @@ -130,12 +133,12 @@ static void mxs_nand_return_dma_descs(struct mxs_nand_info *info) static uint32_t mxs_nand_ecc_chunk_cnt(uint32_t page_data_size) { - return page_data_size / MXS_NAND_CHUNK_DATA_CHUNK_SIZE; + return page_data_size / chunk_data_size; } static uint32_t mxs_nand_ecc_size_in_bits(uint32_t ecc_strength) { - return ecc_strength * 13; + return ecc_strength * gf_len; } static uint32_t mxs_nand_aux_status_offset(void) @@ -149,7 +152,7 @@ static inline uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size, int ecc_strength; ecc_strength = ((page_oob_size - MXS_NAND_METADATA_SIZE) * 8) - / (13 * mxs_nand_ecc_chunk_cnt(page_data_size)); + / (gf_len * mxs_nand_ecc_chunk_cnt(page_data_size)); return round_down(ecc_strength, 2); } @@ -164,7 +167,7 @@ static inline uint32_t mxs_nand_get_mark_offset(uint32_t page_data_size, uint32_t block_mark_chunk_bit_offset; uint32_t block_mark_bit_offset; - chunk_data_size_in_bits = MXS_NAND_CHUNK_DATA_CHUNK_SIZE * 8; + chunk_data_size_in
[U-Boot] [PATCH 1/2] mtd:mxs:nand calculate ecc strength dynamically
Calculate ecc strength according oobsize, but not hardcoded which is not aligned with kernel driver Signed-off-by: Peng Fan Signed-off-by: Ye.Li --- drivers/mtd/nand/mxs_nand.c | 22 -- 1 file changed, 4 insertions(+), 18 deletions(-) diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c index 7a064ab..a45fcf9 100644 --- a/drivers/mtd/nand/mxs_nand.c +++ b/drivers/mtd/nand/mxs_nand.c @@ -146,26 +146,12 @@ static uint32_t mxs_nand_aux_status_offset(void) static inline uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size, uint32_t page_oob_size) { - if (page_data_size == 2048) { - if (page_oob_size == 64) - return 8; + int ecc_strength; - if (page_oob_size == 112) - return 14; - } - - if (page_data_size == 4096) { - if (page_oob_size == 128) - return 8; - - if (page_oob_size == 218) - return 16; + ecc_strength = ((page_oob_size - MXS_NAND_METADATA_SIZE) * 8) + / (13 * mxs_nand_ecc_chunk_cnt(page_data_size)); - if (page_oob_size == 224) - return 16; - } - - return 0; + return round_down(ecc_strength, 2); } static inline uint32_t mxs_nand_get_mark_offset(uint32_t page_data_size, -- 1.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] [RFC] [v2] rsa: Split the rsa-verify
Hi Ruchika, On 18 December 2014 at 04:22, Ruchika Gupta wrote: > > Public exponentiation which is required in rsa verify > functionality is currently tightly integrated with > verification code in rsa_verify.c. Currently this > implementation is software based. Some platforms > having support of the exponentiation in hardware. > To enable the rsa verify functionality to use the > Modular exponentiation if present in hardware, the > patch-set splits the file into two files: > > 1. rsa-verify.c > - The file parses device tree keys node to fill a keyprop > structure. The keyprop structure can then be converted > to implementation specific formal (struct rsa_pub_key > for sw implementation). > - The parsed device tree node is then passed to a generic > rsa_mod_exp function. > > 2. rsa-mod-exp.c > Move the software specific functions related to exponentiation > from rsa-verify.c to this file. The file is compiled if > "CONFIG_RSA_MOD_EXP_SW" is defined. In general if both > CONFIG_FIT_SIGNATURE and CONFIG_RSA are defined, > CONFIG_RSA_MOD_EXP_SW gets automatically defined. > > Platforms having hardware implementation for rsa_mod_exp can > add a define "CONFIG_RSA_MOD_EXP_HW" to their config files. > Adding this defined, undefs the CONFIG_RSA_MOD_EXP_SW and > hardware implementation of mod_exp gets compiled. > > Signed-off-by: Ruchika Gupta > CC: Simon Glass > --- > Changes in v2: > Addressed few of Simon Glass's comments: > - Kconfig option added for RSA > - Comments added for new keyprop struct > > Kconfig | 2 + > include/config_fallbacks.h | 8 ++ > include/u-boot/rsa-mod-exp.h | 34 + > lib/Kconfig | 15 +++ > lib/rsa/Makefile | 1 + > lib/rsa/rsa-mod-exp.c| 308 > +++ > lib/rsa/rsa-verify.c | 307 +- > tools/Makefile | 2 +- > 8 files changed, 399 insertions(+), 278 deletions(-) > create mode 100644 include/u-boot/rsa-mod-exp.h > create mode 100644 lib/rsa/rsa-mod-exp.c > Here are my comments on the whole series. In general the approach looks fine provided you move it to driver model in a follow-up series. See the 'thermal' uclass for a very simple example. - Check your multi-line comment style - Make sure you add a full help paragraph for new Kconfigs - Avoid double blank lines - First patch should just move code out of lib/rsa/rsa-verify.c - Add a separate patch to move CONFIG_FIT_SIGNATURE to Kconfig for existing boards - Make sure functions have comments describing their purpose, arguments, return value. Normally these go in the header file except for static functions - For your header file guard #ifdefs, use a symbol that relates to the filename - Word-wrap your commit messages to >70 chars (e.g. 76 or so) - Make sure you check return values of functions that return errors - Make sure the vboot tests still pass make O=sandbox sandbox_defconfig all O=b/sandbox ./test/vboot/vboot_test.sh - Check your hash.c changes, I think you have the #ifdefs wrong. Please then send a v3 without RFC and we'll try to get final things resolved. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-x86.git
Hi Tom, Here is the last of the Atom changes - we now have good support for one Atom variant (with a path to adding to it) and basic support for ivybridge. A good start. The following changes since commit d8bec60c1b0de7770f9b56ad092ab9be801d99af: ARM: UniPhier: enable CONFIG_CMD_DM (2014-12-18 23:34:30 +0900) are available in the git repository at: git://git.denx.de/u-boot-x86.git for you to fetch changes up to d2c6181d2d2afe00399cf0c8d9deafcb66b77330: x86: Add a script to process Intel microcode files (2014-12-18 17:26:08 -0700) Bin Meng (14): x86: Integrate Tunnel Creek processor microcode x86: Add basic support to queensbay platform and crownbay board x86: ich6-gpio: Add Intel Tunnel Creek GPIO support x86: Enable the queensbay cpu directory build x86: Add queensbay and crownbay Kconfig files x86: Add crownbay defconfig and config.h x86: Use consistent name XXX_ADDR for binary blob flash address x86: Include FSP and CMC binary in the u-boot.rom build rules x86: crownbay: Add SPI flash support x86: crownbay: Enable Intel E1000 NIC support x86: crownbay: Add SDHCI support x86: Rename coreboot-serial to x86-serial x86: Add a README.x86 for U-Boot on x86 support x86: Clean up the FSP support codes Simon Glass (9): x86: ifdtool: Correct a debug() missing parameter x86: ifdtool: Display filename when file errors are reported x86: ifdtool: Use a structure for the file/address list x86: ifdtool: Add support for early microcode access x86: Move microcode updates into a separate directory x86: ivybridge: Update the microcode x86: Correct problems in the microcode loading x86: Convert microcode format to device-tree-only x86: Add a script to process Intel microcode files Makefile | 16 +- arch/x86/Kconfig | 13 ++ arch/x86/cpu/Makefile| 1 + arch/x86/cpu/ivybridge/microcode_intel.c | 27 ++- arch/x86/cpu/ivybridge/sdram.c | 2 +- arch/x86/cpu/queensbay/Kconfig | 79 +++ arch/x86/cpu/queensbay/Makefile | 9 + arch/x86/cpu/queensbay/fsp_configs.c | 2 +- arch/x86/cpu/queensbay/fsp_support.c | 255 ++-- arch/x86/cpu/queensbay/tnc.c | 72 ++ arch/x86/cpu/queensbay/tnc_car.S | 124 ++ arch/x86/cpu/queensbay/tnc_dram.c| 78 +++ arch/x86/cpu/queensbay/tnc_pci.c | 61 + arch/x86/cpu/queensbay/topcliff.c| 47 arch/x86/dts/coreboot.dtsi | 2 +- arch/x86/dts/crownbay.dts| 7 + arch/x86/dts/link.dts| 4 +- arch/x86/dts/m12206a7_0028.dtsi | 622 - arch/x86/dts/m12306a9_0017.dtsi | 750 --- arch/x86/dts/microcode/m0220661105_cv.dtsi | 368 + arch/x86/dts/microcode/m12206a7_0029.dtsi| 686 ++ arch/x86/dts/microcode/m12306a9_001b.dtsi| 814 arch/x86/include/asm/arch-queensbay/fsp/fsp_api.h| 18 +- arch/x86/include/asm/arch-queensbay/fsp/fsp_ffs.h| 28 +-- arch/x86/include/asm/arch-queensbay/fsp/fsp_fv.h | 14 +- arch/x86/include/asm/arch-queensbay/fsp/fsp_hob.h| 112 + arch/x86/include/asm/arch-queensbay/fsp/fsp_infoheader.h | 6 +- arch/x86/include/asm/arch-queensbay/fsp/fsp_platform.h | 8 +- arch/x86/include/asm/arch-queensbay/fsp/fsp_support.h| 63 ++--- arch/x86/include/asm/arch-queensbay/fsp/fsp_types.h | 17 +- arch/x86/include/asm/arch-queensbay/fsp/fsp_vpd.h| 8 +- arch/x86/include/asm/arch-queensbay/gpio.h | 13 ++ arch/x86/include/asm/arch-queensbay/tnc.h| 15 ++ arch/x86/include/asm/gpio.h | 4 +- arch/x86/include/asm/ibmpc.h | 3 + arch/x86/lib/cmd_hob.c | 22 +- board/coreboot/coreboot/coreboot.c | 2 +- board/google/chromebook_link/link.c | 2 +- board/intel/crownbay/Kconfig | 20 ++ board/intel/crownbay/MAINTAINERS | 6 + board/intel/crownbay/Makefile| 7 + board/intel/crownbay/crownbay.c
[U-Boot] [PATCH] RFC: am35xx: Rearrange SPL on am35xx
This is an attempt to tidy up the early SPL code in an attempt to pave the way for driver model in SPL: - Avoid setting up SDRAM before board_init_f() - Avoid touching global_data before board_init_f() - Allow board_init_f() to set up a new stack (seems that the SRAM stack is not large enough on these boards) This needs more work but it does boot on Beaglebone Black. Signed-off-by: Simon Glass --- arch/arm/cpu/armv7/am33xx/board.c | 60 ++ arch/arm/cpu/armv7/lowlevel_init.S | 4 --- arch/arm/include/asm/spl.h | 3 ++ arch/arm/lib/crt0.S| 9 ++ include/configs/ti_armv7_common.h | 5 ++-- 5 files changed, 56 insertions(+), 25 deletions(-) diff --git a/arch/arm/cpu/armv7/am33xx/board.c b/arch/arm/cpu/armv7/am33xx/board.c index 29b1d73..eeea81a 100644 --- a/arch/arm/cpu/armv7/am33xx/board.c +++ b/arch/arm/cpu/armv7/am33xx/board.c @@ -275,24 +275,11 @@ static void watchdog_disable(void) ; } -void s_init(void) +static gd_t tmp_gdata __attribute__ ((section(".data"))); + +void board_init_f(ulong dummy) { - /* -* The ROM will only have set up sufficient pinmux to allow for the -* first 4KiB NOR to be read, we must finish doing what we know of -* the NOR mux in this space in order to continue. -*/ -#ifdef CONFIG_NOR_BOOT - enable_norboot_pin_mux(); -#endif - /* -* Save the boot parameters passed from romcode. -* We cannot delay the saving further than this, -* to prevent overwrites. -*/ -#ifdef CONFIG_SPL_BUILD - save_omap_boot_params(); -#endif + gd->arch.omap_boot_params = tmp_gdata.arch.omap_boot_params; watchdog_disable(); timer_init(); set_uart_mux_conf(); @@ -303,7 +290,6 @@ void s_init(void) serial_init(); gd->have_console = 1; #elif defined(CONFIG_SPL_BUILD) - gd = &gdata; preloader_console_init(); #endif #if defined(CONFIG_SPL_AM33XX_ENABLE_RTC32K_OSC) @@ -314,5 +300,43 @@ void s_init(void) board_early_init_f(); sdram_init(); #endif + /* Clear the BSS. */ + memset(__bss_start, 0, __bss_end - __bss_start); +#ifdef CONFIG_SPL_STACK_R + unsigned long start_addr_sp; + + start_addr_sp = CONFIG_SPL_STACK_R - sizeof(gd_t); + /* 8-byte alignment for ARM ABI compliance */ + start_addr_sp &= ~0x07; + memcpy((void *)start_addr_sp, (void *)gd, sizeof(gd_t)); + spl_call_board_init_r(start_addr_sp, dummy, board_init_r); +#else + board_init_r(NULL, 0); +#endif +} + +void s_init(void) +{ + gd_t *old_gd; + + /* +* The ROM will only have set up sufficient pinmux to allow for the +* first 4KiB NOR to be read, we must finish doing what we know of +* the NOR mux in this space in order to continue. +*/ +#ifdef CONFIG_NOR_BOOT + enable_norboot_pin_mux(); +#endif + old_gd = (gd_t *)gd; + gd = &tmp_gdata; + /* +* Save the boot parameters passed from romcode. +* We cannot delay the saving further than this, +* to prevent overwrites. +*/ +#ifdef CONFIG_SPL_BUILD + save_omap_boot_params(); +#endif + gd = &old_gd; } #endif diff --git a/arch/arm/cpu/armv7/lowlevel_init.S b/arch/arm/cpu/armv7/lowlevel_init.S index f1aea05..e294db9 100644 --- a/arch/arm/cpu/armv7/lowlevel_init.S +++ b/arch/arm/cpu/armv7/lowlevel_init.S @@ -21,13 +21,9 @@ ENTRY(lowlevel_init) */ ldr sp, =CONFIG_SYS_INIT_SP_ADDR bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ -#ifdef CONFIG_SPL_BUILD - ldr r9, =gdata -#else sub sp, sp, #GD_SIZE bic sp, sp, #7 mov r9, sp -#endif /* * Save the old lr(passed in ip) and the current lr to stack */ diff --git a/arch/arm/include/asm/spl.h b/arch/arm/include/asm/spl.h index 8acd7cd..66d983a 100644 --- a/arch/arm/include/asm/spl.h +++ b/arch/arm/include/asm/spl.h @@ -35,4 +35,7 @@ extern char __bss_start[], __bss_end[]; extern gd_t gdata; +void spl_call_board_init_r(ulong start_addr_sp, ulong boot_flags, + void (*board_init_r)(gd_t *new_gd, ulong dest_addr)); + #endif diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S index 22df3e5..be25fde 100644 --- a/arch/arm/lib/crt0.S +++ b/arch/arm/lib/crt0.S @@ -138,3 +138,12 @@ clbss_l:cmpr0, r1 /* while not at end of BSS */ #endif ENDPROC(_main) + +/* + * spl_call_board_init_r(start_addr_sp, dummy, board_init_r) + */ +ENTRY(spl_call_board_init_r) + mov sp, r0 + mov r9, r0 + bx r2 +ENDPROC(spl_call_board_init_r) diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h index bc75172..38c0e63 100644 --- a/include/configs/ti_armv7_common.h +++ b/include/configs/ti_armv7_common.h @@ -76,8 +76,7 @@ #define CONFIG_NR_DRAM_BANKS
[U-Boot] [PATCH 2/2] Revert "ARM: omap4: Update sdram setting for panda rev A6"
This reverts commit 47a4bea6af77b01d59a410d09a4c34b2dd14cf50. Signed-off-by: Nishanth Menon --- arch/arm/cpu/armv7/omap4/sdram_elpida.c |4 1 file changed, 4 deletions(-) diff --git a/arch/arm/cpu/armv7/omap4/sdram_elpida.c b/arch/arm/cpu/armv7/omap4/sdram_elpida.c index 6903696..4462c72 100644 --- a/arch/arm/cpu/armv7/omap4/sdram_elpida.c +++ b/arch/arm/cpu/armv7/omap4/sdram_elpida.c @@ -121,8 +121,6 @@ static void emif_get_reg_dump_sdp(u32 emif_nr, const struct emif_regs **regs) *regs = &emif_regs_elpida_380_mhz_1cs; else if (omap4_rev == OMAP4430_ES2_0) *regs = &emif_regs_elpida_200_mhz_2cs; - else if (omap4_rev == OMAP4430_ES2_3) - *regs = &emif_regs_elpida_400_mhz_1cs; else if (omap4_rev < OMAP4470_ES1_0) *regs = &emif_regs_elpida_400_mhz_2cs; else @@ -138,8 +136,6 @@ static void emif_get_dmm_regs_sdp(const struct dmm_lisa_map_regs if (omap_rev == OMAP4430_ES1_0) *dmm_lisa_regs = &lisa_map_2G_x_1_x_2; - else if (omap_rev == OMAP4430_ES2_3) - *dmm_lisa_regs = &lisa_map_2G_x_2_x_2; else if (omap_rev < OMAP4460_ES1_0) *dmm_lisa_regs = &lisa_map_2G_x_2_x_2; else -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] ARM: OMAP4: Fix SDP4430 ES2.3 breakage
With commit 47a4bea6af77b01d59a410d09a4c34b2dd14cf50 ("ARM: omap4: Update sdram setting for panda rev A6") which attempted to "fix" Panda ES B3 problem of a different DDR by checking for CPU revision and changing configuration as per Panda for configuration that is common for SDP4430 and Panda. This resulted in all OMAP4430 SDP with processor boards > ES2.3 being now broken. This does not obviously help the situation :). So fix it by doing the missing DMM configuration needed for Panda as an override of the weak function and revert the bad commit. based on v2015.01-rc3 tag. Bootlogs: http://slexy.org/view/s2r58bpvpp (Panda ES B3) http://slexy.org/view/s20v9cq7mc (SDP4430 ES2.3) previously (broken v2015.01-rc3 for SDP4430 ES2.3 : http://slexy.org/view/s2fPVW28hd) Nishanth Menon (2): ARM: OMAP4: Panda: rework DMM logic Revert "ARM: omap4: Update sdram setting for panda rev A6" arch/arm/cpu/armv7/omap4/sdram_elpida.c |4 arch/arm/include/asm/arch-omap4/sys_proto.h |3 +++ board/ti/panda/panda.c | 16 3 files changed, 19 insertions(+), 4 deletions(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARM: OMAP4: Panda: rework DMM logic
Part of DMM logic is reuse from commit 47a4bea6af77b01d59a410d09a4c34b2dd14cf50 ("ARM: omap4: Update sdram setting for panda rev A6") Which broke SDP4430 with ES2.3 (uses old DDR). So, to maintain support for newer DDR used in Panda ES rev B3, we should, in addition to the commit 675cc77a3ae45e8b0ec17128563264d4a509f628 ("ARM:OMAP4+: panda-es: Support Rev B3 Elpida DDR2 RAM"), DDR timings, also do DMM configuration specific to Panda. Signed-off-by: Nishanth Menon --- arch/arm/include/asm/arch-omap4/sys_proto.h |3 +++ board/ti/panda/panda.c | 16 2 files changed, 19 insertions(+) diff --git a/arch/arm/include/asm/arch-omap4/sys_proto.h b/arch/arm/include/asm/arch-omap4/sys_proto.h index 83d858f..e19975e 100644 --- a/arch/arm/include/asm/arch-omap4/sys_proto.h +++ b/arch/arm/include/asm/arch-omap4/sys_proto.h @@ -22,6 +22,9 @@ extern const struct emif_regs emif_regs_elpida_200_mhz_2cs; extern const struct emif_regs emif_regs_elpida_380_mhz_1cs; extern const struct emif_regs emif_regs_elpida_400_mhz_1cs; extern const struct emif_regs emif_regs_elpida_400_mhz_2cs; +extern const struct dmm_lisa_map_regs lisa_map_2G_x_1_x_2; +extern const struct dmm_lisa_map_regs lisa_map_2G_x_2_x_2; +extern const struct dmm_lisa_map_regs ma_lisa_map_2G_x_2_x_2; struct omap_sysinfo { char *board_string; }; diff --git a/board/ti/panda/panda.c b/board/ti/panda/panda.c index 16368cb..783ba35 100644 --- a/board/ti/panda/panda.c +++ b/board/ti/panda/panda.c @@ -180,6 +180,22 @@ void emif_get_reg_dump(u32 emif_nr, const struct emif_regs **regs) else *regs = &emif_regs_elpida_400_mhz_1cs; } + +void emif_get_dmm_regs(const struct dmm_lisa_map_regs + **dmm_lisa_regs) +{ + u32 omap_rev = omap_revision(); + + if (omap_rev == OMAP4430_ES1_0) + *dmm_lisa_regs = &lisa_map_2G_x_1_x_2; + else if (omap_rev == OMAP4430_ES2_3) + *dmm_lisa_regs = &lisa_map_2G_x_2_x_2; + else if (omap_rev < OMAP4460_ES1_0) + *dmm_lisa_regs = &lisa_map_2G_x_2_x_2; + else + *dmm_lisa_regs = &ma_lisa_map_2G_x_2_x_2; +} + #endif /** -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] da850evm: Use generic board and libfdt, fix size for SPI flash
On Thu, 2014-12-18 at 12:33 +0530, Jagan Teki wrote: > On 17 December 2014 at 06:44, Peter Howard wrote: > > Add defines to use CONFIG_SYS_GENERIC_BOARD and CONFIG_OF_LIBFDT. > > Semi-separate to this: the size of the image for the da850evm has > > increased to the point that the size in da850evm.h and the offset for > > the environment in SPI flash no longer work. They are modified to > > account for the larger image size. > > > > Signed-off-by: Peter Howard > > --- > > include/configs/da850evm.h | 6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h > > index e5f8afe..e5a612c 100644 > > --- a/include/configs/da850evm.h > > +++ b/include/configs/da850evm.h > > @@ -157,7 +157,7 @@ > > #define CONFIG_SPL_SPI_FLASH_SUPPORT > > #define CONFIG_SPL_SPI_LOAD > > #define CONFIG_SYS_SPI_U_BOOT_OFFS 0x8000 > > -#define CONFIG_SYS_SPI_U_BOOT_SIZE 0x3 > > +#define CONFIG_SYS_SPI_U_BOOT_SIZE 0x4 > > #endif > > > > /* > > @@ -251,7 +251,7 @@ > > #undef CONFIG_ENV_IS_IN_NAND > > #define CONFIG_ENV_IS_IN_SPI_FLASH > > #define CONFIG_ENV_SIZE(64 << 10) > > -#define CONFIG_ENV_OFFSET (256 << 10) > > +#define CONFIG_ENV_OFFSET (512 << 10) > > Please make sure the proper testing of this new flash env size. > What sort of testing were you thinking of? I've confirmed that it basically works (i.e. saving/loading/editing+save) - env size is 64K, SPI is 8MB and offset is only 512K in, so it fits. u-boot image size is ~260K so there's plenty of room before the env. Is there something more you wanted? Thanks. > Reviewed-by: Jagannadha Sutradharudu Teki > > > #define CONFIG_ENV_SECT_SIZE (64 << 10) > > #define CONFIG_SYS_NO_FLASH > > #endif > > @@ -259,6 +259,7 @@ > > /* > > * U-Boot general configuration > > */ > > +#define CONFIG_SYS_GENERIC_BOARD > > #define CONFIG_MISC_INIT_R > > #define CONFIG_BOARD_EARLY_INIT_F > > #define CONFIG_BOOTFILE"uImage" /* Boot file name */ > > @@ -275,6 +276,7 @@ > > #define CONFIG_SYS_LONGHELP > > #define CONFIG_CRC32_VERIFY > > #define CONFIG_MX_CYCLIC > > +#define CONFIG_OF_LIBFDT > > > > /* > > * Linux Information > > -- > > 1.9.3 > > > > thanks! -- Peter Howard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 18/23] ARM: Implement non-cached memory support
Hi Albert, On 18 December 2014 at 13:17, Albert ARIBAUD wrote: > Hello Simon, > > On Wed, 10 Dec 2014 08:03:29 -0700, Simon Glass > wrote: >> Hi Albert, >> >> On 9 December 2014 at 22:25, Simon Glass wrote: >> > From: Thierry Reding >> > >> > Implement an API that can be used by drivers to allocate memory from a >> > pool that is mapped uncached. This is useful if drivers would otherwise >> > need to do extensive cache maintenance (or explicitly maintaining the >> > cache isn't safe). >> > >> > The API is protected using the new CONFIG_SYS_NONCACHED_MEMORY setting. >> > Boards can set this to the size to be used for the non-cached area. The >> > area will typically be right below the malloc() area, but architectures >> > should take care of aligning the beginning and end of the area to honor >> > any mapping restrictions. Architectures must also ensure that mappings >> > established for this area do not overlap with the malloc() area (which >> > should remain cached for improved performance). >> > >> > While the API is currently only implemented for ARM v7, it should be >> > generic enough to allow other architectures to implement it as well. >> > >> > Signed-off-by: Thierry Reding >> > Signed-off-by: Simon Glass >> > --- >> > >> > Changes in v4: None >> > Changes in v3: >> > - Avoid build error with noncached_init() when the dcache is disabled >> > >> > README| 19 +++ >> > arch/arm/include/asm/system.h | 5 + >> > arch/arm/lib/cache.c | 44 >> > +++ >> > common/board_r.c | 11 +++ >> > 4 files changed, 79 insertions(+) >> >> I think you have applied the other cache patches. Are you OK with this >> one? I would like to get this series applied very soon (after DM I2C) >> as it's been around since August. > > This is delegated to Tom Warren in Patchwork. I'm delegating it to > myself and applying it; if Tom has applied it too, this should not > cause a major merge issue. Agreed, sounds good, thanks. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] TI: armv7: enable UUID and PART
Enable UUID and partition support for scripted handling platforms with MMC and eMMC and varied partitioning schemes And remove it from headers that end up redefining it. Signed-off-by: Nishanth Menon --- Based on v2015.01-rc3 tag include/configs/am335x_evm.h |2 -- include/configs/am43xx_evm.h |2 -- include/configs/beagle_x15.h |2 -- include/configs/dra7xx_evm.h |2 -- include/configs/omap5_uevm.h |2 -- include/configs/ti_armv7_common.h |2 ++ 6 files changed, 2 insertions(+), 10 deletions(-) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 560e3bf..0004750 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -47,8 +47,6 @@ /* Enhance our eMMC support / experience. */ #define CONFIG_CMD_GPT #define CONFIG_EFI_PARTITION -#define CONFIG_PARTITION_UUIDS -#define CONFIG_CMD_PART #ifdef CONFIG_NAND #define NANDARGS \ diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h index 4472c3e..b00585c 100644 --- a/include/configs/am43xx_evm.h +++ b/include/configs/am43xx_evm.h @@ -148,8 +148,6 @@ /* Enhance our eMMC support / experience. */ #define CONFIG_CMD_GPT #define CONFIG_EFI_PARTITION -#define CONFIG_PARTITION_UUIDS -#define CONFIG_CMD_PART #ifndef CONFIG_SPL_BUILD #define CONFIG_EXTRA_ENV_SETTINGS \ diff --git a/include/configs/beagle_x15.h b/include/configs/beagle_x15.h index cc36330..b233301 100644 --- a/include/configs/beagle_x15.h +++ b/include/configs/beagle_x15.h @@ -42,8 +42,6 @@ /* Enhance our eMMC support / experience. */ #define CONFIG_CMD_GPT #define CONFIG_EFI_PARTITION -#define CONFIG_PARTITION_UUIDS -#define CONFIG_CMD_PART /* CPSW Ethernet */ #define CONFIG_CMD_NET /* 'bootp' and 'tftp' */ diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h index 174a711..dee2b11 100644 --- a/include/configs/dra7xx_evm.h +++ b/include/configs/dra7xx_evm.h @@ -48,8 +48,6 @@ /* Enhance our eMMC support / experience. */ #define CONFIG_CMD_GPT #define CONFIG_EFI_PARTITION -#define CONFIG_PARTITION_UUIDS -#define CONFIG_CMD_PART #define CONFIG_HSMMC2_8BIT /* CPSW Ethernet */ diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h index e07795f..0ca4e82 100644 --- a/include/configs/omap5_uevm.h +++ b/include/configs/omap5_uevm.h @@ -36,8 +36,6 @@ /* Enhance our eMMC support / experience. */ #define CONFIG_CMD_GPT #define CONFIG_EFI_PARTITION -#define CONFIG_PARTITION_UUIDS -#define CONFIG_CMD_PART #define CONFIG_HSMMC2_8BIT #define CONFIG_SUPPORT_EMMC_BOOT diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h index 93bcce2..081b39d 100644 --- a/include/configs/ti_armv7_common.h +++ b/include/configs/ti_armv7_common.h @@ -187,6 +187,8 @@ #define CONFIG_CMD_EXT2 #define CONFIG_CMD_EXT4 #define CONFIG_CMD_FS_GENERIC +#define CONFIG_PARTITION_UUIDS +#define CONFIG_CMD_PART #endif /* -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] watchdog not resetting beaglebone after timeout period
On Thu, Dec 11, 2014 at 11:55:05AM +0100, Belisko Marek wrote: > Hi, > > I'm using latest u-boot master > (9b416a9f4ca7cf5ac4d5f7143d67edde7f7d7326) running on beaglebone > (white). This board has watchdog enabled by default for 60 secs > timeout but in my case it's not resetting board after that amount of > time. I did check watchdog registers: I just checked on my BBB and with falcon mode it's tripping the reset. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 18/23] ARM: Implement non-cached memory support
Hello Simon, On Wed, 10 Dec 2014 08:03:29 -0700, Simon Glass wrote: > Hi Albert, > > On 9 December 2014 at 22:25, Simon Glass wrote: > > From: Thierry Reding > > > > Implement an API that can be used by drivers to allocate memory from a > > pool that is mapped uncached. This is useful if drivers would otherwise > > need to do extensive cache maintenance (or explicitly maintaining the > > cache isn't safe). > > > > The API is protected using the new CONFIG_SYS_NONCACHED_MEMORY setting. > > Boards can set this to the size to be used for the non-cached area. The > > area will typically be right below the malloc() area, but architectures > > should take care of aligning the beginning and end of the area to honor > > any mapping restrictions. Architectures must also ensure that mappings > > established for this area do not overlap with the malloc() area (which > > should remain cached for improved performance). > > > > While the API is currently only implemented for ARM v7, it should be > > generic enough to allow other architectures to implement it as well. > > > > Signed-off-by: Thierry Reding > > Signed-off-by: Simon Glass > > --- > > > > Changes in v4: None > > Changes in v3: > > - Avoid build error with noncached_init() when the dcache is disabled > > > > README| 19 +++ > > arch/arm/include/asm/system.h | 5 + > > arch/arm/lib/cache.c | 44 > > +++ > > common/board_r.c | 11 +++ > > 4 files changed, 79 insertions(+) > > I think you have applied the other cache patches. Are you OK with this > one? I would like to get this series applied very soon (after DM I2C) > as it's been around since August. This is delegated to Tom Warren in Patchwork. I'm delegating it to myself and applying it; if Tom has applied it too, this should not cause a major merge issue. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 2/3] usb: eth: add ASIX AX88179 DRIVER
On Thu, Dec 18, 2014 at 5:17 AM, Marek Vasut wrote: > Would you pick it and submit for current release or do you want me to do it? If you can do it that would be great. Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 14/14] sun8i: Add defconfig for Ippo_q8h v1.2
On Tue, 2014-12-16 at 21:31 +0100, Hans de Goede wrote: > We need separate defconfigs for the v5 and v1.2 versions of this board, as > they use different DRAM parameters. > > Note they also use different dtb files, as the wifi is different too. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell (I think this is the patch you mentioned just now WRT having added a MAINTAINERS entry, so I won't mention it again ;-)) > diff --git a/configs/Ippo_q8h_v1.2_defconfig b/configs/Ippo_q8h_v1.2_defconfig > new file mode 100644 > index 000..fefed32 > --- /dev/null > +++ b/configs/Ippo_q8h_v1.2_defconfig > @@ -0,0 +1,15 @@ > +CONFIG_SPL=y > +CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=5" > +CONFIG_FDTFILE="sun8i-a23-ippo-q8h-v1.2.dtb" > +CONFIG_VIDEO=n > +CONFIG_USB_KEYBOARD=n > ++S:CONFIG_ARM=y > ++S:CONFIG_ARCH_SUNXI=y > ++S:CONFIG_MACH_SUN8I=y No CONFIG_TARGET? Do you want to send a patch to nuke them all, better than having a mixture IMHO. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/14] sun8i: Add dram initialization support
On Tue, 2014-12-16 at 21:31 +0100, Hans de Goede wrote: > Based on the register / dram_para headers from the Allwinner u-boot / linux > sources + the init sequences from boot0. > > Signed-off-by: Hans de Goede > +/* > + * Note this code uses a lot of magic hex values, that is because this code > + * simply replays the init sequence as done by the Allwinner boot0 code, so > + * we do not know what these values mean. There are no symbolic constants for > + * these magic values, since we do not know how to name them and making up > + * names for them is not useful. On that basis I've only really given this a quick glance. I've no problem with it. Couple of queries about the defconfig changes: > diff --git a/configs/Ippo_q8h_v5_defconfig b/configs/Ippo_q8h_v5_defconfig > index 50c2f93..37aa46d 100644 > --- a/configs/Ippo_q8h_v5_defconfig > +++ b/configs/Ippo_q8h_v5_defconfig > @@ -1,8 +1,15 @@ > +CONFIG_SPL=y > CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=5" > -CONFIG_ARM=y > -CONFIG_ARCH_SUNXI=y > -CONFIG_MACH_SUN8I=y > -CONFIG_TARGET_IPPO_Q8H_V5=y Not replaced with a S: variant? I know you want CONFIG_TARGET to go, but I don't think that was part of what you intended in this patch. > -CONFIG_DEFAULT_DEVICE_TREE="sun8i-a23-ippo-q8h-v5.dtb" > +CONFIG_FDTFILE="sun8i-a23-ippo-q8h-v5.dtb" The switch from CONFIG_DEFAULT_DEVICE_TREE to CONFIG_FDTFILE conversion seems a little out of place too. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/14] sunxi: Use memcmp for mctl_mem_matches
On Tue, 2014-12-16 at 21:31 +0100, Hans de Goede wrote: > Use memcmp for mctl_mem_matches instead of DIY. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/14] sunxi: Fill memory before comparing it when doing dram init on sun6i
On Tue, 2014-12-16 at 21:31 +0100, Hans de Goede wrote: > The sun8i boot0 code fills the DRAM with a "random" pattern before comparing > it at different offsets to do columns, etc. detection. The sun6i boot0 code > does not do it, but it seems like a good idea to do this regardless. Is this the right way round? The existing sun6i code (which you are moving here) seems to _rely_ on something having written a useful pattern, which I would have assumed to have been boot0. Or else how does it work now? Chance? > The new mctl_mem_fill function this introduces is added as an inline helper > in dram.h, so that it can be shared with the sun8i dram code. > > While at it move mctl_mem_matches to dram.h for re-use in sun8i too. > > Signed-off-by: Hans de Goede > --- > arch/arm/cpu/armv7/sunxi/dram_sun6i.c | 15 +-- > arch/arm/include/asm/arch-sunxi/dram.h | 29 + > 2 files changed, 30 insertions(+), 14 deletions(-) > > diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c > b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c > index e1670e5..4675c48 100644 > --- a/arch/arm/cpu/armv7/sunxi/dram_sun6i.c > +++ b/arch/arm/cpu/armv7/sunxi/dram_sun6i.c > @@ -326,20 +326,6 @@ static void mctl_port_cfg(void) > writel(0x0307, &mctl_com->mbagcr[5]); > } > > -static bool mctl_mem_matches(u32 offset) > -{ > - const int match_count = 64; > - int i, matches = 0; > - > - for (i = 0; i < match_count; i++) { > - if (readl(CONFIG_SYS_SDRAM_BASE + i * 4) == > - readl(CONFIG_SYS_SDRAM_BASE + offset + i * 4)) > - matches++; > - } > - > - return matches == match_count; > -} > - > unsigned long sunxi_dram_init(void) > { > struct sunxi_mctl_com_reg * const mctl_com = > @@ -391,6 +377,7 @@ unsigned long sunxi_dram_init(void) > MCTL_CR_BANK(1) | MCTL_CR_RANK(1)); > > /* Detect and set page size */ > + mctl_mem_fill(); > for (columns = 7; columns < 20; columns++) { > if (mctl_mem_matches(1 << columns)) > break; > diff --git a/arch/arm/include/asm/arch-sunxi/dram.h > b/arch/arm/include/asm/arch-sunxi/dram.h > index 18924f5..0bf718c 100644 > --- a/arch/arm/include/asm/arch-sunxi/dram.h > +++ b/arch/arm/include/asm/arch-sunxi/dram.h > @@ -22,6 +22,8 @@ > #include > #endif > > +#define MCTL_MEM_FILL_MATCH_COUNT 64 > + > unsigned long sunxi_dram_init(void); > > /* > @@ -37,4 +39,31 @@ static inline void mctl_await_completion(u32 *reg, u32 > mask, u32 val) > } > } > > +/* > + * Fill beginning of DRAM with "random" data for mctl_mem_matches() > + */ > +static inline void mctl_mem_fill(void) > +{ > + int i; > + > + for (i = 0; i < MCTL_MEM_FILL_MATCH_COUNT; i++) > + writel(0xaa55aa55 + i, CONFIG_SYS_SDRAM_BASE + i * 4); > +} > + > +/* > + * Test if memory at offset offset matches memory at begin of DRAM > + */ > +static inline bool mctl_mem_matches(u32 offset) > +{ > + int i, matches = 0; > + > + for (i = 0; i < MCTL_MEM_FILL_MATCH_COUNT; i++) { > + if (readl(CONFIG_SYS_SDRAM_BASE + i * 4) == > + readl(CONFIG_SYS_SDRAM_BASE + offset + i * 4)) > + matches++; > + } > + > + return matches == MCTL_MEM_FILL_MATCH_COUNT; > +} > + > #endif /* _SUNXI_DRAM_H */ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/14] sunxi: Move await_completion dram helper to dram.h
On Tue, 2014-12-16 at 21:31 +0100, Hans de Goede wrote: > The await_completion helper is already copy pasted between the sun4i and sun6i > dram code, and we need it for sun8i too, so lets make it an inline helper in > dram.h, rather then adding yet another copy. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/14] sun6i: Add k and m parameters to clock_set_pll5()
On Tue, 2014-12-16 at 21:31 +0100, Hans de Goede wrote: > The A23 (sun8i) requires different values for these then sun6i, so make them > function parameters. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/14] sun6i: Add a sigma_delta_enable paramter to clock_set_pll5()
On Tue, 2014-12-16 at 21:31 +0100, Hans de Goede wrote: > The sun8i dram code sometimes wants to enable sigma delta mode, > add a parameter to allow this. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/14] sunxi: axp221: Disable dcdc4 on sun8i (A23)
On Tue, 2014-12-16 at 21:31 +0100, Hans de Goede wrote: > dcdc4 is not used on sun8i, disable it. > > While at it also add comments to the other fixed voltages to document what > they are used for. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell (although I'm wondering if it might have been better to make this Kconfigurable...) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/14] sunxi: axp221: Explicitly turn off unused voltages
On Tue, 2014-12-16 at 21:31 +0100, Hans de Goede wrote: > Explicitly turn off unused voltages, rather then leaving them as is. Likewise > explictly enabled the dcdc convertors, rather then assuming they are already > enabled at boot. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/14] sunxi: axp221: Add Kconfig help and sane defaults for typical ldo usage
On Tue, 2014-12-16 at 21:31 +0100, Hans de Goede wrote: > Some of the ldo-s of the axp221 are used in the same way on most boards, add > comments to the Kconfig help text to reflect this, and give them defaults > matching their typical usage. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/14] sunxi: axp221: Make dcdc1 voltage configurable
On Tue, 2014-12-16 at 21:31 +0100, Hans de Goede wrote: > The dcdc1 voltage is typically used as generic 3.3V IO voltage for things like > GPIO-s, sdcard interfaces, etc. On most boards this is undervolted to 3.0V to > safe battery, but not on all, make it configurable so that we can use the > same settings as the original firmware on all boards. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/14] sunxi: axp221: Add axp223 support
On Tue, 2014-12-16 at 21:31 +0100, Hans de Goede wrote: > The axp223 appears to be the same as the axp221, except that it uses the > rsb to communicate rather then the p2wi. At least all the registers we use > are 100% the same. > > Signed-off-by: Hans de Goede With the whitespace fixed: Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/14] sunxi: Add support for the rsb (Reduced Serial Bus)
On Wed, 2014-12-17 at 13:56 +0100, Hans de Goede wrote: > >> @@ -128,7 +128,8 @@ > >> #define SUN6I_CPUCFG_BASE 0x01f01c00 > >> #define SUNXI_R_UART_BASE 0x01f02800 > >> #define SUNXI_R_PIO_BASE 0x01f02c00 > >> -#define SUNXI_P2WI_BASE0x01f03400 > >> +#define SUNXI_P2WI_BASE0x01f03400 /* on > >> sun6i */ > >> +#define SUNXI_RSB_BASE 0x01f03400 /* on sun8i */ > > > > Maybe we just use SUN6I_ SUN8I_ prefixes? > > The base address will be different on sun9i. Did you miss this suggestions from Chen-Yu? Seems like a good one. I don't have any other comments. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/14] sunxi: Add support for the rsb (Reduced Serial Bus)
On Wed, 2014-12-17 at 13:56 +0100, Hans de Goede wrote: > Hi, > > On 17-12-14 03:22, Chen-Yu Tsai wrote: > > Hi, > > > > On Wed, Dec 17, 2014 at 4:31 AM, Hans de Goede wrote: > >> sun8i (A23) introduces a new bus for communicating with the pmic, the rsb, > >> the rsb is also used to communicate with the pmic on the A80, and is > >> documented in the A80 user manual. > >> > >> This commit adds support for this based on the rsb driver from the > >> allwinner > >> u-boot sources. > >> > >> Note: Not yet ready for upstream, code needs some significant cleanups. > > > > Confusing note. > > Ugh, I forgot to remove that note after doing the cleanups, I'll remove it > from the version of the patch my personal tree :) I'll stop ignoring this patch then ;-) Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/14] sun6i: s/SUNXI_GPL0_R_P2WI/SUN6I_GPL0_R_P2WI/
On Tue, 2014-12-16 at 21:31 +0100, Hans de Goede wrote: > The p2wi interface is only available on sun6i, adjust the gpio pinmux defines > for it to reflect this. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] sun6i: Add new CSQ_CS908 board
On Thu, 2014-12-18 at 11:39 +0100, Hans de Goede wrote: > Hi, > > On 14-12-14 15:57, Ian Campbell wrote: > > On Sun, 2014-11-23 at 14:43 +0100, Hans de Goede wrote: > >> The CSQ CS908 is an A31s based top-set box, with 1G RAM, 8G NAND, > >> rtl8188etv usb wifi, 2 USB A receptacles (1 connected through the OTG > >> controller), ethernet, 3.5 mm jack with a/v out and hdmi out: > >> > >> http://www.geekbuying.com/item/CS908-Allwinner-A31S-Quad-Core-1-2GHz-Android-4-4-Mini-TV-Box-HDMI-HDD-Player-1G-8G-WIFI-Miracast---Black-95.html > >> > >> Note it has no sdcard slot and therefore can only be fel booted. > >> > >> Signed-off-by: Hans de Goede > >> Acked-by: Ian Campbell > >> --- > >> configs/CSQ_CS908_defconfig | 19 +++ > > > > Apparently I'm terrible at remembering this during review: this is > > missing a MAINTAINERS entry. (MAKEALL warns about this when regenerating > > boards.cfg). > > Yeah, I'm bad at remembering to update MAINTAINERS too... > > > Since this patch is only in u-boot-sunxi#next so far do you just want to > > fold in an update to add it to your stanza (or add a new appropriate > > stanza) and force push? Ack to that plan if you do. > > Done (fixed, forced-push). Thanks. > I've also fixed the same problem for the new Ippo_q8h_v1.2_defconfig in > my sun8i spl / draminit set in my personal tree. Great, that's one less to forget then! Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] ARM: UniPhier: enable CONFIG_CMD_DM
Hi Masahiro, On 18 December 2014 at 03:11, Masahiro Yamada wrote: > > Signed-off-by: Masahiro Yamada > --- > > include/configs/uniphier.h | 2 ++ > 1 file changed, 2 insertions(+) Note that this will become the default once we get the DM Kconfig series done. Acked-by: Simon Glass (But I assume you will apply it) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT] Pull request: u-boot-dfu (18-12-2014)
On Thursday, December 18, 2014 at 12:43:30 PM, Lukasz Majewski wrote: > The following changes since commit > 68ae882596524a2dde9da73283241b01d56375d5: > > USB: gadget: atmel_usba_udc: fix transfer hang issue (2014-12-16 > 16:08:50 +0100) > > are available in the git repository at: > > git://git.denx.de/u-boot-dfu.git > > for you to fetch changes up to 0ff7e585df83470139739533bdbf41114f395470: > > fastboot: handle flash write to GPT partitions (2014-12-18 12:26:06 > +0100) Pulled, thank you! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-usb/master
Hi, please find a couple of more fixes for this release. The following changes since commit b9206e61f3d87535ac4f4b0b858e674fd1edfeaf: Merge git://git.denx.de/u-boot-x86 (2014-12-15 17:13:47 -0500) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 0ff7e585df83470139739533bdbf41114f395470: fastboot: handle flash write to GPT partitions (2014-12-18 12:26:06 +0100) Bo Shen (1): USB: gadget: atmel_usba_udc: fix transfer hang issue Przemyslaw Marczak (3): dfu: mmc: check if mmc device exists in mmc_block_op() gadget: f_thor: check pointers before use in download_tail() dfu: dfu_get_buf: check the value of env dfu_bufsiz before use Rob Herring (2): usb, g_dnl: generalize DFU detach functions fastboot: add support for continue command Steve Rae (2): disk: part_efi: move code to static functions fastboot: handle flash write to GPT partitions README | 9 common/cmd_dfu.c| 6 +-- common/cmd_fastboot.c | 4 ++ common/fb_mmc.c | 26 -- disk/part_efi.c | 268 ++ drivers/dfu/dfu.c | 24 +++--- drivers/dfu/dfu_mmc.c | 8 +++- drivers/usb/gadget/atmel_usba_udc.c | 1 - drivers/usb/gadget/f_dfu.c | 2 +- drivers/usb/gadget/f_fastboot.c | 14 ++ drivers/usb/gadget/f_thor.c | 16 ++- drivers/usb/gadget/g_dnl.c | 17 +++ include/dfu.h | 3 -- include/g_dnl.h | 4 ++ include/part.h | 20 15 files changed, 317 insertions(+), 105 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding patch: http://patchwork.ozlabs.org/patch/373593/
On Thursday, December 18, 2014 at 09:32:56 AM, Ramneek Mehresh wrote: > Hi Marex, > > Following u-boot patch is pending for your review for some time. Please let > me know if you have any concerns. fsl/usb: Add USB XHCI support: > http://patchwork.ozlabs.org/patch/373593/ I missed the patch completely, sorry. Next time, please keep me on CC when submitting the patches, that helps a lot. As for the board_usb_init, you can drop the inline and the __board_usb_init() and do: __weak int board_usb_init(int index, enum usb_init_type init) { return 0; } The static void fsl_xhci_core_exit(struct fsl_xhci *fsl_xhci) must shut down the controller, which I don't see happening. Why? Thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 2/3] usb: eth: add ASIX AX88179 DRIVER
On Thursday, December 18, 2014 at 07:53:56 AM, Joe Hershberger wrote: > Hi Marek, > > On Wed, Dec 17, 2014 at 10:00 AM, Marek Vasut wrote: > > On Wednesday, December 17, 2014 at 01:33:57 PM, René Griessl wrote: > > > > Is there a reason you can't implement write_hwaddr() so that it will > > > > behave like other NICs (u-boot is the highest priority source of the > > > > MAC address). > > > > > > The AX88179 uses an external flash to store the MAC address. So for my > > > application I do not want the user to be able to change it, since it is > > > a unique ID inside the server cluster. > > > I could add it as compiler option. Maybe it is even better to implement > > > my behavior as option, since it differs from standard. > > > I think it will be finished mid of january, so if it is OK for you in a > > > separate patch. > > > > Joe, can you just pick the patch as is and wait for subsequent patch to > > improve > > > the driver? My understanding is that the driver is operating correctly > > and pulling the MAC from an integrated EEPROM, which is fine. If you > > want to > > allow > > > overriding this MAC using the $ethaddr, this is only an improvement and > > can be > > > added later. This would improve our hardware support and avoid blocking > > the > > > driver further. > > > > What do you think please ? > > I agree... You may have noticed I already Acked it and agreed that the > improvement may come later. All righty, thanks! Would you pick it and submit for current release or do you want me to do it? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] arm: build arch memset/memcpy in Thumb2 mode
Resynchronize memcpy/memset with kernel 3.17 and build them in Thumb2 mode (unified syntax). Those assembler files can be built and linked in ARM mode too, however when calling them from Thumb2 built code, the stack got corrupted and the copy did not succeed (the exact details have not been traced back). However, the Linux kernel builds those files in Thumb2 mode. Hence U-Boot should build them in Thumb2 mode too when CONFIG_SYS_THUMB_BUILD is set. To build the files without warning, some assembler instructions had to be replaced with their UAL compliant variant (thanks Jeroen for this input). To build the file in Thumb2 mode the implicit-it=always option need to be set to generate Thumb2 compliant IT instructions where needed. We add this option to the general AFLAGS when building for Thumb2. Reviewed-by: Simon Glass Tested-by: Simon Glass Signed-off-by: Stefan Agner --- arch/arm/config.mk | 4 +- arch/arm/include/asm/assembler.h | 33 ++-- arch/arm/lib/memcpy.S| 80 +++- arch/arm/lib/memset.S| 112 --- 4 files changed, 142 insertions(+), 87 deletions(-) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index f0eafd6..9a4c270 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -26,7 +26,9 @@ PLATFORM_CPPFLAGS += -D__ARM__ # Choose between ARM/Thumb instruction sets ifeq ($(CONFIG_SYS_THUMB_BUILD),y) -PF_CPPFLAGS_ARM := $(call cc-option, -mthumb -mthumb-interwork,\ +AFLAGS_IMPLICIT_IT := $(call as-option,-Wa$(comma)-mimplicit-it=always) +PF_CPPFLAGS_ARM:= $(AFLAGS_IMPLICIT_IT) \ + $(call cc-option, -mthumb -mthumb-interwork,\ $(call cc-option,-marm,)\ $(call cc-option,-mno-thumb-interwork,)\ ) diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 5e4789b..11b80fb 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -14,12 +14,14 @@ * assembler source. */ +#include + /* * Endian independent macros for shifting bytes within registers. */ #ifndef __ARMEB__ -#define pull lsr -#define push lsl +#define lspull lsr +#define lspush lsl #define get_byte_0 lsl #0 #define get_byte_1 lsr #8 #define get_byte_2 lsr #16 @@ -29,8 +31,8 @@ #define put_byte_2 lsl #16 #define put_byte_3 lsl #24 #else -#define pull lsl -#define push lsr +#define lspull lsl +#define lspush lsr #define get_byte_0 lsr #24 #define get_byte_1 lsr #16 #define get_byte_2 lsr #8 @@ -54,7 +56,28 @@ #define PLD(code...) #endif + .irpc,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo + .macro ret\c, reg +#if defined(__ARM_ARCH_5E__) || defined(__ARM_ARCH_5TE__) + mov\c pc, \reg +#else + .ifeqs "\reg", "lr" + bx\c\reg + .else + mov\c pc, \reg + .endif +#endif + .endm + .endr + /* - * Cache alligned + * Cache aligned, used for optimized memcpy/memset + * In the kernel this is only enabled for Feroceon CPU's... + * We disable it especially for Thumb builds since those instructions + * are not made in a Thumb ready way... */ +#ifdef CONFIG_SYS_THUMB_BUILD +#define CALGN(code...) +#else #define CALGN(code...) code +#endif diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S index f655256..eeaf003 100644 --- a/arch/arm/lib/memcpy.S +++ b/arch/arm/lib/memcpy.S @@ -10,9 +10,14 @@ * published by the Free Software Foundation. */ +#include #include +#ifdef CONFIG_SYS_THUMB_BUILD +#define W(instr) instr.w +#else #define W(instr) instr +#endif #define LDR1W_SHIFT0 #define STR1W_SHIFT0 @@ -30,7 +35,7 @@ .endm .macro ldr1b ptr reg cond=al abort - ldr\cond\()b \reg, [\ptr], #1 + ldrb\cond\() \reg, [\ptr], #1 .endm .macro str1w ptr reg abort @@ -42,7 +47,7 @@ .endm .macro str1b ptr reg cond=al abort - str\cond\()b \reg, [\ptr], #1 + strb\cond\() \reg, [\ptr], #1 .endm .macro enter reg1 reg2 @@ -56,10 +61,12 @@ .text /* Prototype: void *memcpy(void *dest, const void *src, size_t n); */ - -.globl memcpy -memcpy: - + .syntax unified +#ifdef CONFIG_SYS_THUMB_BUILD + .thumb + .thumb_func +#endif +ENTRY(memcpy) cmp r0, r1 moveq pc, lr @@ -79,7 +86,7 @@ memcpy: CALGN( andsip, r0, #31 ) CALGN( rsb r3, ip, #32 ) - CALGN( sbcnes r4, r3, r2 ) @ C is always set here + CALGN( sbcsne r4, r3, r2 ) @ C is always set here CALGN( bcs 2f ) CALGN( adr r4, 6f ) CALGN( subsr2, r2, r3 ) @ C gets set
Re: [U-Boot] Pull request: u-boot-uniphier
On Thu, Dec 18, 2014 at 11:43:05PM +0900, Masahiro YAMADA wrote: > Hi Tom, > > The following changes since commit e3bf81b1e841ecabe7c8b3d48621256db8b8623e: > > Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx > (2014-12-16 15:20:02 -0500) > > are available in the git repository at: > > > git://git.denx.de/u-boot-uniphier.git master > > for you to fetch changes up to d8bec60c1b0de7770f9b56ad092ab9be801d99af: > > ARM: UniPhier: enable CONFIG_CMD_DM (2014-12-18 23:34:30 +0900) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] ARM: UniPhier: minor fixes
On Thu, Dec 18, 2014 at 11:41:35PM +0900, Masahiro YAMADA wrote: > 2014-12-18 19:10 GMT+09:00 Masahiro Yamada : > > > > > > > > Masahiro Yamada (5): > > ARM: UniPhier: fix property names of aliases nodes of device trees > > ARM: UniPhier: remove unnecessary ifdef conditional > > ARM: UniPhier: use DRAM area for init stack of normal image > > ARM: UniPhier: select CONFIG_SPL > > ARM: UniPhier: enable CONFIG_CMD_DM > > Series, applied to u-boot-uniphier In public, as a reminder to everyone (not picking on Masahiro), as a rule of thumb please try and wait 24h between posting your patches and applying them to your own tree. The patches themselves are fine so I'll be taking the PR shortly. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] fs: fat: read: fix fat16 ls/read issue
The present fat implementation ignores FAT16 long name directory entries which aren't placed in a single sector. This was becouse of the buffer was always filled by the two sectors, and the loop was made also for two sectors. If some file long name entries are stored in two sectors, the we have two cases: Case 1: Both of sectors are in the buffer - all required data for long file name is in the buffer. - Read OK! Case 2: The current directory entry is placed at the end of the second buffered sector. And the next entries are placed in a sector which is not buffered yet. Then two next sectors are buffered and the mentioned entry is ignored. - Read fail! This commit fixes this issue by: - read two sectors after loop on each single is done - keep the last used sector as a first in the buffer before the read of two next The commit doesn't affects the fat32 imlementation, which works good as previous. Signed-off-by: Przemyslaw Marczak Cc: Mikhail Zolotaryov Cc: Tom Rini Cc: Stephen Warren Cc: Simon Glass Cc: Suriyan Ramasami Cc: Lukasz Majewski Cc: Wolfgang Denk Tested-by: Simon Glass --- Changes v2: - add more expressive variable names - add code comment to the patch change Changes v3: - add Tested-by --- fs/fat/fat.c | 69 1 file changed, 51 insertions(+), 18 deletions(-) diff --git a/fs/fat/fat.c b/fs/fat/fat.c index 04a51db..bccc3e3 100644 --- a/fs/fat/fat.c +++ b/fs/fat/fat.c @@ -823,8 +823,11 @@ int do_fat_read_at(const char *filename, loff_t pos, void *buffer, int ret = -1; int firsttime; __u32 root_cluster = 0; + __u32 read_blk; int rootdir_size = 0; - int j; + int buffer_blk_cnt; + int do_read; + __u8 *dir_ptr; if (read_bootsectandvi(&bs, &volinfo, &mydata->fatsize)) { debug("Error: reading boot sector\n"); @@ -909,24 +912,54 @@ int do_fat_read_at(const char *filename, loff_t pos, void *buffer, isdir = 1; } - j = 0; + buffer_blk_cnt = 0; + firsttime = 1; while (1) { int i; - if (j == 0) { - debug("FAT read sect=%d, clust_size=%d, DIRENTSPERBLOCK=%zd\n", - cursect, mydata->clust_size, DIRENTSPERBLOCK); + if (mydata->fatsize == 32 || firsttime) { + dir_ptr = do_fat_read_at_block; + firsttime = 0; + } else { + /** +* FAT16 sector buffer modification: +* Each loop, the second buffered block is moved to +* the buffer begin, and two next sectors are read +* next to the previously moved one. So the sector +* buffer keeps always 3 sectors for fat16. +* And the current sector is the buffer second sector +* beside the "firsttime" read, when it is the first one. +* +* PREFETCH_BLOCKS is 2 for FAT16 == loop[0:1] +* n = computed root dir sector +* loop | cursect-1 | cursect| cursect+1 | +* 0 | sector n+0 | sector n+1 | none | +* 1 | none | sector n+0 | sector n+1 | +* 0 | sector n+1 | sector n+2 | sector n+3 | +* 1 | sector n+3 | ... + */ + dir_ptr = (do_fat_read_at_block + mydata->sect_size); + memcpy(do_fat_read_at_block, dir_ptr, mydata->sect_size); + } + + do_read = 1; + + if (mydata->fatsize == 32 && buffer_blk_cnt) + do_read = 0; + + if (do_read) { + read_blk = (mydata->fatsize == 32) ? + mydata->clust_size : PREFETCH_BLOCKS; + + debug("FAT read(sect=%d, cnt:%d), clust_size=%d, DIRENTSPERBLOCK=%zd\n", + cursect, read_blk, mydata->clust_size, DIRENTSPERBLOCK); - if (disk_read(cursect, - (mydata->fatsize == 32) ? - (mydata->clust_size) : - PREFETCH_BLOCKS, - do_fat_read_at_block) < 0) { + if (disk_read(cursect, read_blk, dir_ptr) < 0) { debug("Error: reading rootdir block\n"); goto exit; } - dentptr = (dir_entry *) do_fat_read_at_block; + dentptr = (dir_entry *)dir_ptr; } for (i = 0; i < DIRENTSPERBLOCK; i++) { @@ -951
Re: [U-Boot] [PATCH v2] arm: build arch memset/memcpy in Thumb2 mode
Hello Stefan, On Mon, 15 Dec 2014 22:06:11 +0100, Stefan Agner wrote: > Hi Andreas, > > On 2014-12-15 15:24, Andreas Färber wrote: > > Hi Stefan, > > > > Am 03.12.2014 um 18:04 schrieb Stefan Agner: > >> Can this be fixed by the merger or should I create a new revision? > > > > It looks as if this was neither applied nor respun? I have some more > > patches to make CONFIG_USE_PRIVATE_LIBGCC build for Thumb that I would > > like to rebase on it. > > Not sure what the expectation is... Probably I should just do a respin > since there are now three minor nits... Agreed, and assuming the three nits are cared for, I'd take it as a bugfix. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] kikwood: uboot-envtools: add plugs boards
Sorry... I post to the wrong list ! Regards, Gérald Le 18/12/2014 15:59, Gerald Kerma a écrit : > Add some kirkwood plugs to uboot-envtools > - SheevaPlug > - SheevaPlug with eSATA > - GuruplugServerPlus > > Signed-off-by: Gerald Kerma > --- > package/boot/uboot-envtools/files/kirkwood | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/package/boot/uboot-envtools/files/kirkwood > b/package/boot/uboot-envtools/files/kirkwood > index b15b8f9..13b3e60 100644 > --- a/package/boot/uboot-envtools/files/kirkwood > +++ b/package/boot/uboot-envtools/files/kirkwood > @@ -17,7 +17,10 @@ case "$board" in > "ea3500" | \ > "ea4500" | \ > "ib62x0" | \ > -"pogo_e02") > +"guruplug-server-plus" | \ > +"pogo_e02"| \ > +"sheevaplug" | \ > +"sheevaplug-esata" ) > ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x2" "0x2" > ;; > esac > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] fs: fat: read: fix fat16 ls/read issue
The present fat implementation ignores FAT16 long name directory entries which aren't placed in a single sector. This was becouse of the buffer was always filled by the two sectors, and the loop was made also for two sectors. If some file long name entries are stored in two sectors, the we have two cases: Case 1: Both of sectors are in the buffer - all required data for long file name is in the buffer. - Read OK! Case 2: The current directory entry is placed at the end of the second buffered sector. And the next entries are placed in a sector which is not buffered yet. Then two next sectors are buffered and the mentioned entry is ignored. - Read fail! This commit fixes this issue by: - read two sectors after loop on each single is done - keep the last used sector as a first in the buffer before the read of two next The commit doesn't affects the fat32 imlementation, which works good as previous. Signed-off-by: Przemyslaw Marczak Cc: Mikhail Zolotaryov Cc: Tom Rini Cc: Stephen Warren Cc: Simon Glass Cc: Suriyan Ramasami Cc: Lukasz Majewski Cc: Wolfgang Denk --- Changes v2: - add more expressive variable names - add code comment to the patch change --- fs/fat/fat.c | 69 1 file changed, 51 insertions(+), 18 deletions(-) diff --git a/fs/fat/fat.c b/fs/fat/fat.c index 04a51db..bccc3e3 100644 --- a/fs/fat/fat.c +++ b/fs/fat/fat.c @@ -823,8 +823,11 @@ int do_fat_read_at(const char *filename, loff_t pos, void *buffer, int ret = -1; int firsttime; __u32 root_cluster = 0; + __u32 read_blk; int rootdir_size = 0; - int j; + int buffer_blk_cnt; + int do_read; + __u8 *dir_ptr; if (read_bootsectandvi(&bs, &volinfo, &mydata->fatsize)) { debug("Error: reading boot sector\n"); @@ -909,24 +912,54 @@ int do_fat_read_at(const char *filename, loff_t pos, void *buffer, isdir = 1; } - j = 0; + buffer_blk_cnt = 0; + firsttime = 1; while (1) { int i; - if (j == 0) { - debug("FAT read sect=%d, clust_size=%d, DIRENTSPERBLOCK=%zd\n", - cursect, mydata->clust_size, DIRENTSPERBLOCK); + if (mydata->fatsize == 32 || firsttime) { + dir_ptr = do_fat_read_at_block; + firsttime = 0; + } else { + /** +* FAT16 sector buffer modification: +* Each loop, the second buffered block is moved to +* the buffer begin, and two next sectors are read +* next to the previously moved one. So the sector +* buffer keeps always 3 sectors for fat16. +* And the current sector is the buffer second sector +* beside the "firsttime" read, when it is the first one. +* +* PREFETCH_BLOCKS is 2 for FAT16 == loop[0:1] +* n = computed root dir sector +* loop | cursect-1 | cursect| cursect+1 | +* 0 | sector n+0 | sector n+1 | none | +* 1 | none | sector n+0 | sector n+1 | +* 0 | sector n+1 | sector n+2 | sector n+3 | +* 1 | sector n+3 | ... + */ + dir_ptr = (do_fat_read_at_block + mydata->sect_size); + memcpy(do_fat_read_at_block, dir_ptr, mydata->sect_size); + } + + do_read = 1; + + if (mydata->fatsize == 32 && buffer_blk_cnt) + do_read = 0; + + if (do_read) { + read_blk = (mydata->fatsize == 32) ? + mydata->clust_size : PREFETCH_BLOCKS; + + debug("FAT read(sect=%d, cnt:%d), clust_size=%d, DIRENTSPERBLOCK=%zd\n", + cursect, read_blk, mydata->clust_size, DIRENTSPERBLOCK); - if (disk_read(cursect, - (mydata->fatsize == 32) ? - (mydata->clust_size) : - PREFETCH_BLOCKS, - do_fat_read_at_block) < 0) { + if (disk_read(cursect, read_blk, dir_ptr) < 0) { debug("Error: reading rootdir block\n"); goto exit; } - dentptr = (dir_entry *) do_fat_read_at_block; + dentptr = (dir_entry *)dir_ptr; } for (i = 0; i < DIRENTSPERBLOCK; i++) { @@ -951,7 +984,7 @@ int do_fat_read_at(const char *filename,
Re: [U-Boot] [PATCH] fs: fat: read: fix fat16 ls/read issue
Hello, On 12/18/2014 03:56 PM, Simon Glass wrote: Hi, On 18 December 2014 at 07:40, Przemyslaw Marczak wrote: Hello, On 12/18/2014 03:34 PM, Simon Glass wrote: Hi Przemyslaw, On 18 December 2014 at 07:32, Przemyslaw Marczak wrote: Hello, On 12/18/2014 02:47 PM, Simon Glass wrote: Hi, On 11 December 2014 at 05:01, Przemyslaw Marczak wrote: The present fat implementation ignores FAT16 long name directory entries which aren't placed in a single sector. This was becouse of the buffer was always filled by the two sectors, and the loop was made also for two sectors. If some file long name entries are stored in two sectors, the we have two cases: Case 1: Both of sectors are in the buffer - all required data for long file name is in the buffer. - Read OK! Case 2: The current directory entry is placed at the end of the second buffered sector. And the next entries are placed in a sector which is not buffered yet. Then two next sectors are buffered and the mentioned entry is ignored. - Read fail! This commit fixes this issue by: - read two sectors after loop on each single is done - keep the last used sector as a first in the buffer before the read of two next The commit doesn't affects the fat32 imlementation, which works good as previous. Signed-off-by: Przemyslaw Marczak Cc: Mikhail Zolotaryov Cc: Tom Rini Cc: Stephen Warren Cc: Simon Glass Cc: Suriyan Ramasami Cc: Lukasz Majewski Cc: Wolfgang Denk --- fs/fat/fat.c | 33 - 1 file changed, 24 insertions(+), 9 deletions(-) Tested-by: Simon Glass diff --git a/fs/fat/fat.c b/fs/fat/fat.c index 04a51db..afbf12d 100644 --- a/fs/fat/fat.c +++ b/fs/fat/fat.c @@ -823,8 +823,11 @@ int do_fat_read_at(const char *filename, loff_t pos, void *buffer, int ret = -1; int firsttime; __u32 root_cluster = 0; + __u32 read_blk; int rootdir_size = 0; - int j; + int j, k; What is k? Can we use a proper variable name? Also for j. That might save needing a comment for them. + int do_read; + __u8 *dir_ptr; Why does it use __u8 instead of u8 or uint8_t for example? __u8 is used in a whole fat code, and also as a directory entry buffer, so why not to keep the whole code style? OK, sounds good. Do you have any ideas on the bug I reported? No, but I think that this is not any fat issue. Can you explain what you mean here? What other software could be causing this? Regards, Simon The fat code is quite unreadable, but it is simple. Passing the "/syslinux/..//bcm2835-rpi-b-rev2.dtb" as the fatload argument is just treat as a "/syslinux" directory which doesn't exists. So the file can't be read, right? Best regards, -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] kikwood: uboot-envtools: add plugs boards
Add some kirkwood plugs to uboot-envtools - SheevaPlug - SheevaPlug with eSATA - GuruplugServerPlus Signed-off-by: Gerald Kerma --- package/boot/uboot-envtools/files/kirkwood | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/package/boot/uboot-envtools/files/kirkwood b/package/boot/uboot-envtools/files/kirkwood index b15b8f9..13b3e60 100644 --- a/package/boot/uboot-envtools/files/kirkwood +++ b/package/boot/uboot-envtools/files/kirkwood @@ -17,7 +17,10 @@ case "$board" in "ea3500" | \ "ea4500" | \ "ib62x0" | \ -"pogo_e02") +"guruplug-server-plus" | \ +"pogo_e02"| \ +"sheevaplug" | \ +"sheevaplug-esata" ) ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x2" "0x2" ;; esac -- 2.1.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fs: fat: read: fix fat16 ls/read issue
Hi, On 18 December 2014 at 07:40, Przemyslaw Marczak wrote: > Hello, > > > On 12/18/2014 03:34 PM, Simon Glass wrote: >> >> Hi Przemyslaw, >> >> On 18 December 2014 at 07:32, Przemyslaw Marczak >> wrote: >>> >>> Hello, >>> >>> On 12/18/2014 02:47 PM, Simon Glass wrote: Hi, On 11 December 2014 at 05:01, Przemyslaw Marczak wrote: > > > The present fat implementation ignores FAT16 long name > directory entries which aren't placed in a single sector. > > This was becouse of the buffer was always filled by the > two sectors, and the loop was made also for two sectors. > > If some file long name entries are stored in two sectors, > the we have two cases: > > Case 1: > Both of sectors are in the buffer - all required data > for long file name is in the buffer. > - Read OK! > > Case 2: > The current directory entry is placed at the end of the > second buffered sector. And the next entries are placed > in a sector which is not buffered yet. Then two next > sectors are buffered and the mentioned entry is ignored. > - Read fail! > > This commit fixes this issue by: > - read two sectors after loop on each single is done > - keep the last used sector as a first in the buffer > before the read of two next > > The commit doesn't affects the fat32 imlementation, > which works good as previous. > > Signed-off-by: Przemyslaw Marczak > Cc: Mikhail Zolotaryov > Cc: Tom Rini > Cc: Stephen Warren > Cc: Simon Glass > Cc: Suriyan Ramasami > Cc: Lukasz Majewski > Cc: Wolfgang Denk > --- >fs/fat/fat.c | 33 - >1 file changed, 24 insertions(+), 9 deletions(-) Tested-by: Simon Glass > > diff --git a/fs/fat/fat.c b/fs/fat/fat.c > index 04a51db..afbf12d 100644 > --- a/fs/fat/fat.c > +++ b/fs/fat/fat.c > @@ -823,8 +823,11 @@ int do_fat_read_at(const char *filename, loff_t > pos, > void *buffer, > int ret = -1; > int firsttime; > __u32 root_cluster = 0; > + __u32 read_blk; > int rootdir_size = 0; > - int j; > + int j, k; What is k? Can we use a proper variable name? Also for j. That might save needing a comment for them. > + int do_read; > + __u8 *dir_ptr; Why does it use __u8 instead of u8 or uint8_t for example? >>> >>> >>> >>> __u8 is used in a whole fat code, and also as a directory entry buffer, >>> so >>> why not to keep the whole code style? >> >> >> OK, sounds good. >> >> Do you have any ideas on the bug I reported? >> > > No, but I think that this is not any fat issue. Can you explain what you mean here? What other software could be causing this? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-uniphier
Hi Tom, The following changes since commit e3bf81b1e841ecabe7c8b3d48621256db8b8623e: Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2014-12-16 15:20:02 -0500) are available in the git repository at: git://git.denx.de/u-boot-uniphier.git master for you to fetch changes up to d8bec60c1b0de7770f9b56ad092ab9be801d99af: ARM: UniPhier: enable CONFIG_CMD_DM (2014-12-18 23:34:30 +0900) Masahiro Yamada (5): ARM: UniPhier: fix property names of aliases nodes of device trees ARM: UniPhier: remove unnecessary ifdef conditional ARM: UniPhier: use DRAM area for init stack of normal image ARM: UniPhier: select CONFIG_SPL ARM: UniPhier: enable CONFIG_CMD_DM arch/arm/Kconfig | 1 + arch/arm/cpu/armv7/uniphier/init_page_table.c | 4 arch/arm/dts/uniphier-ph1-ld4-ref.dts | 8 arch/arm/dts/uniphier-ph1-pro4-ref.dts| 8 arch/arm/dts/uniphier-ph1-sld3-ref.dts| 6 +++--- arch/arm/dts/uniphier-ph1-sld8-ref.dts| 8 configs/ph1_ld4_defconfig | 1 - configs/ph1_pro4_defconfig| 1 - configs/ph1_sld8_defconfig| 1 - include/configs/uniphier.h| 6 ++ 10 files changed, 22 insertions(+), 22 deletions(-) -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] ARM: UniPhier: minor fixes
2014-12-18 19:10 GMT+09:00 Masahiro Yamada : > > > > Masahiro Yamada (5): > ARM: UniPhier: fix property names of aliases nodes of device trees > ARM: UniPhier: remove unnecessary ifdef conditional > ARM: UniPhier: use DRAM area for init stack of normal image > ARM: UniPhier: select CONFIG_SPL > ARM: UniPhier: enable CONFIG_CMD_DM > Series, applied to u-boot-uniphier -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fs: fat: read: fix fat16 ls/read issue
Hello, On 12/18/2014 03:34 PM, Simon Glass wrote: Hi Przemyslaw, On 18 December 2014 at 07:32, Przemyslaw Marczak wrote: Hello, On 12/18/2014 02:47 PM, Simon Glass wrote: Hi, On 11 December 2014 at 05:01, Przemyslaw Marczak wrote: The present fat implementation ignores FAT16 long name directory entries which aren't placed in a single sector. This was becouse of the buffer was always filled by the two sectors, and the loop was made also for two sectors. If some file long name entries are stored in two sectors, the we have two cases: Case 1: Both of sectors are in the buffer - all required data for long file name is in the buffer. - Read OK! Case 2: The current directory entry is placed at the end of the second buffered sector. And the next entries are placed in a sector which is not buffered yet. Then two next sectors are buffered and the mentioned entry is ignored. - Read fail! This commit fixes this issue by: - read two sectors after loop on each single is done - keep the last used sector as a first in the buffer before the read of two next The commit doesn't affects the fat32 imlementation, which works good as previous. Signed-off-by: Przemyslaw Marczak Cc: Mikhail Zolotaryov Cc: Tom Rini Cc: Stephen Warren Cc: Simon Glass Cc: Suriyan Ramasami Cc: Lukasz Majewski Cc: Wolfgang Denk --- fs/fat/fat.c | 33 - 1 file changed, 24 insertions(+), 9 deletions(-) Tested-by: Simon Glass diff --git a/fs/fat/fat.c b/fs/fat/fat.c index 04a51db..afbf12d 100644 --- a/fs/fat/fat.c +++ b/fs/fat/fat.c @@ -823,8 +823,11 @@ int do_fat_read_at(const char *filename, loff_t pos, void *buffer, int ret = -1; int firsttime; __u32 root_cluster = 0; + __u32 read_blk; int rootdir_size = 0; - int j; + int j, k; What is k? Can we use a proper variable name? Also for j. That might save needing a comment for them. + int do_read; + __u8 *dir_ptr; Why does it use __u8 instead of u8 or uint8_t for example? __u8 is used in a whole fat code, and also as a directory entry buffer, so why not to keep the whole code style? OK, sounds good. Do you have any ideas on the bug I reported? No, but I think that this is not any fat issue. if (read_bootsectandvi(&bs, &volinfo, &mydata->fatsize)) { debug("Error: reading boot sector\n"); @@ -910,23 +913,35 @@ int do_fat_read_at(const char *filename, loff_t pos, void *buffer, } j = 0; + k = 0; while (1) { int i; - if (j == 0) { + if (mydata->fatsize == 32 || !k) { + dir_ptr = do_fat_read_at_block; + k = 1; + } else { + dir_ptr = (do_fat_read_at_block + mydata->sect_size); + memcpy(do_fat_read_at_block, dir_ptr, mydata->sect_size); + } + + do_read = 1; + + if (mydata->fatsize == 32 && j) + do_read = 0; + + if (do_read) { debug("FAT read sect=%d, clust_size=%d, DIRENTSPERBLOCK=%zd\n", cursect, mydata->clust_size, DIRENTSPERBLOCK); - if (disk_read(cursect, - (mydata->fatsize == 32) ? - (mydata->clust_size) : - PREFETCH_BLOCKS, - do_fat_read_at_block) < 0) { + read_blk = (mydata->fatsize == 32) ? + mydata->clust_size : PREFETCH_BLOCKS; + if (disk_read(cursect, read_blk, dir_ptr) < 0) { debug("Error: reading rootdir block\n"); goto exit; } - dentptr = (dir_entry *) do_fat_read_at_block; + dentptr = (dir_entry *)dir_ptr; } for (i = 0; i < DIRENTSPERBLOCK; i++) { @@ -951,7 +966,7 @@ int do_fat_read_at(const char *filename, loff_t pos, void *buffer, get_vfatname(mydata, root_cluster, - do_fat_read_at_block, +dir_ptr, dentptr, l_name); if (dols == LS_ROOT) { -- 1.9.1 Regards, Simon Thanks, -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fs: fat: read: fix fat16 ls/read issue
Hi Przemyslaw, On 18 December 2014 at 07:32, Przemyslaw Marczak wrote: > Hello, > > On 12/18/2014 02:47 PM, Simon Glass wrote: >> >> Hi, >> >> On 11 December 2014 at 05:01, Przemyslaw Marczak >> wrote: >>> >>> The present fat implementation ignores FAT16 long name >>> directory entries which aren't placed in a single sector. >>> >>> This was becouse of the buffer was always filled by the >>> two sectors, and the loop was made also for two sectors. >>> >>> If some file long name entries are stored in two sectors, >>> the we have two cases: >>> >>> Case 1: >>> Both of sectors are in the buffer - all required data >>> for long file name is in the buffer. >>> - Read OK! >>> >>> Case 2: >>> The current directory entry is placed at the end of the >>> second buffered sector. And the next entries are placed >>> in a sector which is not buffered yet. Then two next >>> sectors are buffered and the mentioned entry is ignored. >>> - Read fail! >>> >>> This commit fixes this issue by: >>> - read two sectors after loop on each single is done >>> - keep the last used sector as a first in the buffer >>>before the read of two next >>> >>> The commit doesn't affects the fat32 imlementation, >>> which works good as previous. >>> >>> Signed-off-by: Przemyslaw Marczak >>> Cc: Mikhail Zolotaryov >>> Cc: Tom Rini >>> Cc: Stephen Warren >>> Cc: Simon Glass >>> Cc: Suriyan Ramasami >>> Cc: Lukasz Majewski >>> Cc: Wolfgang Denk >>> --- >>> fs/fat/fat.c | 33 - >>> 1 file changed, 24 insertions(+), 9 deletions(-) >> >> >> Tested-by: Simon Glass >> >>> >>> diff --git a/fs/fat/fat.c b/fs/fat/fat.c >>> index 04a51db..afbf12d 100644 >>> --- a/fs/fat/fat.c >>> +++ b/fs/fat/fat.c >>> @@ -823,8 +823,11 @@ int do_fat_read_at(const char *filename, loff_t pos, >>> void *buffer, >>> int ret = -1; >>> int firsttime; >>> __u32 root_cluster = 0; >>> + __u32 read_blk; >>> int rootdir_size = 0; >>> - int j; >>> + int j, k; >> >> >> What is k? Can we use a proper variable name? Also for j. That might >> save needing a comment for them. >> >>> + int do_read; >>> + __u8 *dir_ptr; >> >> >> Why does it use __u8 instead of u8 or uint8_t for example? > > > __u8 is used in a whole fat code, and also as a directory entry buffer, so > why not to keep the whole code style? OK, sounds good. Do you have any ideas on the bug I reported? > > >>> >>> if (read_bootsectandvi(&bs, &volinfo, &mydata->fatsize)) { >>> debug("Error: reading boot sector\n"); >>> @@ -910,23 +913,35 @@ int do_fat_read_at(const char *filename, loff_t >>> pos, void *buffer, >>> } >>> >>> j = 0; >>> + k = 0; >>> while (1) { >>> int i; >>> >>> - if (j == 0) { >>> + if (mydata->fatsize == 32 || !k) { >>> + dir_ptr = do_fat_read_at_block; >>> + k = 1; >>> + } else { >>> + dir_ptr = (do_fat_read_at_block + >>> mydata->sect_size); >>> + memcpy(do_fat_read_at_block, dir_ptr, >>> mydata->sect_size); >>> + } >>> + >>> + do_read = 1; >>> + >>> + if (mydata->fatsize == 32 && j) >>> + do_read = 0; >>> + >>> + if (do_read) { >>> debug("FAT read sect=%d, clust_size=%d, >>> DIRENTSPERBLOCK=%zd\n", >>> cursect, mydata->clust_size, >>> DIRENTSPERBLOCK); >>> >>> - if (disk_read(cursect, >>> - (mydata->fatsize == 32) ? >>> - (mydata->clust_size) : >>> - PREFETCH_BLOCKS, >>> - do_fat_read_at_block) < 0) { >>> + read_blk = (mydata->fatsize == 32) ? >>> + mydata->clust_size : PREFETCH_BLOCKS; >>> + if (disk_read(cursect, read_blk, dir_ptr) < 0) { >>> debug("Error: reading rootdir block\n"); >>> goto exit; >>> } >>> >>> - dentptr = (dir_entry *) do_fat_read_at_block; >>> + dentptr = (dir_entry *)dir_ptr; >>> } >>> >>> for (i = 0; i < DIRENTSPERBLOCK; i++) { >>> @@ -951,7 +966,7 @@ int do_fat_read_at(const char *filename, loff_t pos, >>> void *buffer, >>> >>> get_vfatname(mydata, >>> root_cluster, >>> - >>> do_fat_read_at_block, >>> +dir_ptr, >>> dentptr, l_name); >>> >>> if (dols == LS_ROOT) { >>> -- >>> 1.9.1
Re: [U-Boot] [PATCH] fs: fat: read: fix fat16 ls/read issue
Hello, On 12/18/2014 02:47 PM, Simon Glass wrote: Hi, On 11 December 2014 at 05:01, Przemyslaw Marczak wrote: The present fat implementation ignores FAT16 long name directory entries which aren't placed in a single sector. This was becouse of the buffer was always filled by the two sectors, and the loop was made also for two sectors. If some file long name entries are stored in two sectors, the we have two cases: Case 1: Both of sectors are in the buffer - all required data for long file name is in the buffer. - Read OK! Case 2: The current directory entry is placed at the end of the second buffered sector. And the next entries are placed in a sector which is not buffered yet. Then two next sectors are buffered and the mentioned entry is ignored. - Read fail! This commit fixes this issue by: - read two sectors after loop on each single is done - keep the last used sector as a first in the buffer before the read of two next The commit doesn't affects the fat32 imlementation, which works good as previous. Signed-off-by: Przemyslaw Marczak Cc: Mikhail Zolotaryov Cc: Tom Rini Cc: Stephen Warren Cc: Simon Glass Cc: Suriyan Ramasami Cc: Lukasz Majewski Cc: Wolfgang Denk --- fs/fat/fat.c | 33 - 1 file changed, 24 insertions(+), 9 deletions(-) Tested-by: Simon Glass diff --git a/fs/fat/fat.c b/fs/fat/fat.c index 04a51db..afbf12d 100644 --- a/fs/fat/fat.c +++ b/fs/fat/fat.c @@ -823,8 +823,11 @@ int do_fat_read_at(const char *filename, loff_t pos, void *buffer, int ret = -1; int firsttime; __u32 root_cluster = 0; + __u32 read_blk; int rootdir_size = 0; - int j; + int j, k; What is k? Can we use a proper variable name? Also for j. That might save needing a comment for them. + int do_read; + __u8 *dir_ptr; Why does it use __u8 instead of u8 or uint8_t for example? __u8 is used in a whole fat code, and also as a directory entry buffer, so why not to keep the whole code style? if (read_bootsectandvi(&bs, &volinfo, &mydata->fatsize)) { debug("Error: reading boot sector\n"); @@ -910,23 +913,35 @@ int do_fat_read_at(const char *filename, loff_t pos, void *buffer, } j = 0; + k = 0; while (1) { int i; - if (j == 0) { + if (mydata->fatsize == 32 || !k) { + dir_ptr = do_fat_read_at_block; + k = 1; + } else { + dir_ptr = (do_fat_read_at_block + mydata->sect_size); + memcpy(do_fat_read_at_block, dir_ptr, mydata->sect_size); + } + + do_read = 1; + + if (mydata->fatsize == 32 && j) + do_read = 0; + + if (do_read) { debug("FAT read sect=%d, clust_size=%d, DIRENTSPERBLOCK=%zd\n", cursect, mydata->clust_size, DIRENTSPERBLOCK); - if (disk_read(cursect, - (mydata->fatsize == 32) ? - (mydata->clust_size) : - PREFETCH_BLOCKS, - do_fat_read_at_block) < 0) { + read_blk = (mydata->fatsize == 32) ? + mydata->clust_size : PREFETCH_BLOCKS; + if (disk_read(cursect, read_blk, dir_ptr) < 0) { debug("Error: reading rootdir block\n"); goto exit; } - dentptr = (dir_entry *) do_fat_read_at_block; + dentptr = (dir_entry *)dir_ptr; } for (i = 0; i < DIRENTSPERBLOCK; i++) { @@ -951,7 +966,7 @@ int do_fat_read_at(const char *filename, loff_t pos, void *buffer, get_vfatname(mydata, root_cluster, -do_fat_read_at_block, +dir_ptr, dentptr, l_name); if (dols == LS_ROOT) { -- 1.9.1 Regards, Simon Thanks, -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fs: fat: read: fix fat16 ls/read issue
Hello, On 12/18/2014 02:47 PM, Simon Glass wrote: Hi, On 11 December 2014 at 05:01, Przemyslaw Marczak wrote: The present fat implementation ignores FAT16 long name directory entries which aren't placed in a single sector. This was becouse of the buffer was always filled by the two sectors, and the loop was made also for two sectors. If some file long name entries are stored in two sectors, the we have two cases: Case 1: Both of sectors are in the buffer - all required data for long file name is in the buffer. - Read OK! Case 2: The current directory entry is placed at the end of the second buffered sector. And the next entries are placed in a sector which is not buffered yet. Then two next sectors are buffered and the mentioned entry is ignored. - Read fail! This commit fixes this issue by: - read two sectors after loop on each single is done - keep the last used sector as a first in the buffer before the read of two next The commit doesn't affects the fat32 imlementation, which works good as previous. Signed-off-by: Przemyslaw Marczak Cc: Mikhail Zolotaryov Cc: Tom Rini Cc: Stephen Warren Cc: Simon Glass Cc: Suriyan Ramasami Cc: Lukasz Majewski Cc: Wolfgang Denk --- fs/fat/fat.c | 33 - 1 file changed, 24 insertions(+), 9 deletions(-) Tested-by: Simon Glass Thank you. diff --git a/fs/fat/fat.c b/fs/fat/fat.c index 04a51db..afbf12d 100644 --- a/fs/fat/fat.c +++ b/fs/fat/fat.c @@ -823,8 +823,11 @@ int do_fat_read_at(const char *filename, loff_t pos, void *buffer, int ret = -1; int firsttime; __u32 root_cluster = 0; + __u32 read_blk; int rootdir_size = 0; - int j; + int j, k; What is k? Can we use a proper variable name? Also for j. That might save needing a comment for them. k is a counter for a first time read. I will change this code and add some comment. + int do_read; + __u8 *dir_ptr; Why does it use __u8 instead of u8 or uint8_t for example? if (read_bootsectandvi(&bs, &volinfo, &mydata->fatsize)) { debug("Error: reading boot sector\n"); @@ -910,23 +913,35 @@ int do_fat_read_at(const char *filename, loff_t pos, void *buffer, } j = 0; + k = 0; while (1) { int i; - if (j == 0) { + if (mydata->fatsize == 32 || !k) { + dir_ptr = do_fat_read_at_block; + k = 1; + } else { + dir_ptr = (do_fat_read_at_block + mydata->sect_size); + memcpy(do_fat_read_at_block, dir_ptr, mydata->sect_size); + } + + do_read = 1; + + if (mydata->fatsize == 32 && j) + do_read = 0; + + if (do_read) { debug("FAT read sect=%d, clust_size=%d, DIRENTSPERBLOCK=%zd\n", cursect, mydata->clust_size, DIRENTSPERBLOCK); - if (disk_read(cursect, - (mydata->fatsize == 32) ? - (mydata->clust_size) : - PREFETCH_BLOCKS, - do_fat_read_at_block) < 0) { + read_blk = (mydata->fatsize == 32) ? + mydata->clust_size : PREFETCH_BLOCKS; + if (disk_read(cursect, read_blk, dir_ptr) < 0) { debug("Error: reading rootdir block\n"); goto exit; } - dentptr = (dir_entry *) do_fat_read_at_block; + dentptr = (dir_entry *)dir_ptr; } for (i = 0; i < DIRENTSPERBLOCK; i++) { @@ -951,7 +966,7 @@ int do_fat_read_at(const char *filename, loff_t pos, void *buffer, get_vfatname(mydata, root_cluster, -do_fat_read_at_block, +dir_ptr, dentptr, l_name); if (dols == LS_ROOT) { -- 1.9.1 Regards, Simon Thank you and best regards, -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/3] Serial Flash: call spi_flash_free more coherently
On 3 November 2014 at 19:31, Valentin Longchamp wrote: > Some board require spi_flash_free to be called after all the accesses, > in order, for instance, to restore the pin multiplexing configuration in > the case where the SPI pins are multiplexed. So, for each probe calls you must need to free the flash even-though the flash is-in-use, looks some different behavior. Can you pleas elaborate little more. > > This patch series tries to enhance this. Patch 1 adds spi_flash_free > calls to env_sf so that the SPI interface is always "cleaned up" after > the env read/writes. Patch 2 adds a 'sf release' command that implicitly > calls spi_flash_free and is thus the pendant of 'sf probe'. Patch 3 uses > the 'sf command' for the km_arm board scripts. > > The whole series had already been sent more than a year ago [1] but it > was rejected without any feedback. So I send this rebased v2 so that it > finally gets reviewed and merged. > > [1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/169723 > > Changes in v2: > - Rebased on v2014.10 > > Valentin Longchamp (3): > env_sf: generalize call to spi_flash_free after accesses > cmd_sf: add 'release' command This may not be an optimistic solutions where we couldn't add command to have generic behavior which does at-least on probe time - IMHO. > km_arm: call 'sf release' in the newenv and update scripts > > common/cmd_sf.c | 13 - > common/env_sf.c | 34 -- > include/configs/km/km_arm.h | 6 -- > 3 files changed, 32 insertions(+), 21 deletions(-) > > -- > 1.8.0.1 > thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Revert "spi: add config option to enable the WP pin function on st micron flashes"
This reverts commit 562f8df18da62ae02c4ace1e530451fe82c3312d. Never see the issue with N25Q128 flash without need of W#/Vpp signal during probe. Signed-off-by: Jagannadha Sutradharudu Teki Cc: Heiko Schocher --- README| 11 --- drivers/mtd/spi/sf_internal.h | 4 drivers/mtd/spi/sf_probe.c| 30 -- 3 files changed, 45 deletions(-) diff --git a/README b/README index 4ca04d0..908646f 100644 --- a/README +++ b/README @@ -3090,17 +3090,6 @@ CBFS (Coreboot Filesystem) support memories can be connected with a given cs line. currently Xilinx Zynq qspi support these type of connections. - CONFIG_SYS_SPI_ST_ENABLE_WP_PIN - enable the W#/Vpp signal to disable writing to the status - register on ST MICRON flashes like the N25Q128. - The status register write enable/disable bit, combined with - the W#/VPP signal provides hardware data protection for the - device as follows: When the enable/disable bit is set to 1, - and the W#/VPP signal is driven LOW, the status register - nonvolatile bits become read-only and the WRITE STATUS REGISTER - operation will not execute. The only way to exit this - hardware-protected mode is to drive W#/VPP HIGH. - - SystemACE Support: CONFIG_SYSTEMACE diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h index 785f7a9..bd834dc 100644 --- a/drivers/mtd/spi/sf_internal.h +++ b/drivers/mtd/spi/sf_internal.h @@ -97,10 +97,6 @@ enum { #define STATUS_QEB_MXIC(1 << 6) #define STATUS_PEC (1 << 7) -#ifdef CONFIG_SYS_SPI_ST_ENABLE_WP_PIN -#define STATUS_SRWD(1 << 7) /* SR write protect */ -#endif - /* Flash timeout values */ #define SPI_FLASH_PROG_TIMEOUT (2 * CONFIG_SYS_HZ) #define SPI_FLASH_PAGE_ERASE_TIMEOUT (5 * CONFIG_SYS_HZ) diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c index ce9987f..3b0e652 100644 --- a/drivers/mtd/spi/sf_probe.c +++ b/drivers/mtd/spi/sf_probe.c @@ -287,34 +287,6 @@ int spi_flash_decode_fdt(const void *blob, struct spi_flash *flash) } #endif /* CONFIG_OF_CONTROL */ -#ifdef CONFIG_SYS_SPI_ST_ENABLE_WP_PIN -/* enable the W#/Vpp signal to disable writing to the status register */ -static int spi_enable_wp_pin(struct spi_flash *flash) -{ - u8 status; - int ret; - - ret = spi_flash_cmd_read_status(flash, &status); - if (ret < 0) - return ret; - - ret = spi_flash_cmd_write_status(flash, STATUS_SRWD); - if (ret < 0) - return ret; - - ret = spi_flash_cmd_write_disable(flash); - if (ret < 0) - return ret; - - return 0; -} -#else -static int spi_enable_wp_pin(struct spi_flash *flash) -{ - return 0; -} -#endif - /** * spi_flash_probe_slave() - Probe for a SPI flash device on a bus * @@ -393,8 +365,6 @@ int spi_flash_probe_slave(struct spi_slave *spi, struct spi_flash *flash) puts(" Full access #define CONFIG_SPI_FLASH_BAR\n"); } #endif - if (spi_enable_wp_pin(flash)) - puts("Enable WP pin failed\n"); /* Release spi bus */ spi_release_bus(spi); -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fs: fat: read: fix fat16 ls/read issue
Hi, On 11 December 2014 at 05:01, Przemyslaw Marczak wrote: > The present fat implementation ignores FAT16 long name > directory entries which aren't placed in a single sector. > > This was becouse of the buffer was always filled by the > two sectors, and the loop was made also for two sectors. > > If some file long name entries are stored in two sectors, > the we have two cases: > > Case 1: > Both of sectors are in the buffer - all required data > for long file name is in the buffer. > - Read OK! > > Case 2: > The current directory entry is placed at the end of the > second buffered sector. And the next entries are placed > in a sector which is not buffered yet. Then two next > sectors are buffered and the mentioned entry is ignored. > - Read fail! > > This commit fixes this issue by: > - read two sectors after loop on each single is done > - keep the last used sector as a first in the buffer > before the read of two next > > The commit doesn't affects the fat32 imlementation, > which works good as previous. > > Signed-off-by: Przemyslaw Marczak > Cc: Mikhail Zolotaryov > Cc: Tom Rini > Cc: Stephen Warren > Cc: Simon Glass > Cc: Suriyan Ramasami > Cc: Lukasz Majewski > Cc: Wolfgang Denk > --- > fs/fat/fat.c | 33 - > 1 file changed, 24 insertions(+), 9 deletions(-) Tested-by: Simon Glass > > diff --git a/fs/fat/fat.c b/fs/fat/fat.c > index 04a51db..afbf12d 100644 > --- a/fs/fat/fat.c > +++ b/fs/fat/fat.c > @@ -823,8 +823,11 @@ int do_fat_read_at(const char *filename, loff_t pos, > void *buffer, > int ret = -1; > int firsttime; > __u32 root_cluster = 0; > + __u32 read_blk; > int rootdir_size = 0; > - int j; > + int j, k; What is k? Can we use a proper variable name? Also for j. That might save needing a comment for them. > + int do_read; > + __u8 *dir_ptr; Why does it use __u8 instead of u8 or uint8_t for example? > > if (read_bootsectandvi(&bs, &volinfo, &mydata->fatsize)) { > debug("Error: reading boot sector\n"); > @@ -910,23 +913,35 @@ int do_fat_read_at(const char *filename, loff_t pos, > void *buffer, > } > > j = 0; > + k = 0; > while (1) { > int i; > > - if (j == 0) { > + if (mydata->fatsize == 32 || !k) { > + dir_ptr = do_fat_read_at_block; > + k = 1; > + } else { > + dir_ptr = (do_fat_read_at_block + mydata->sect_size); > + memcpy(do_fat_read_at_block, dir_ptr, > mydata->sect_size); > + } > + > + do_read = 1; > + > + if (mydata->fatsize == 32 && j) > + do_read = 0; > + > + if (do_read) { > debug("FAT read sect=%d, clust_size=%d, > DIRENTSPERBLOCK=%zd\n", > cursect, mydata->clust_size, DIRENTSPERBLOCK); > > - if (disk_read(cursect, > - (mydata->fatsize == 32) ? > - (mydata->clust_size) : > - PREFETCH_BLOCKS, > - do_fat_read_at_block) < 0) { > + read_blk = (mydata->fatsize == 32) ? > + mydata->clust_size : PREFETCH_BLOCKS; > + if (disk_read(cursect, read_blk, dir_ptr) < 0) { > debug("Error: reading rootdir block\n"); > goto exit; > } > > - dentptr = (dir_entry *) do_fat_read_at_block; > + dentptr = (dir_entry *)dir_ptr; > } > > for (i = 0; i < DIRENTSPERBLOCK; i++) { > @@ -951,7 +966,7 @@ int do_fat_read_at(const char *filename, loff_t pos, void > *buffer, > > get_vfatname(mydata, > root_cluster, > -do_fat_read_at_block, > +dir_ptr, > dentptr, l_name); > > if (dols == LS_ROOT) { > -- > 1.9.1 > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fs: fat: read: fix fat16 ls/read issue
Hello, On 12/18/2014 02:36 PM, Simon Glass wrote: Hi Przemyslaw, On 18 December 2014 at 06:31, Przemyslaw Marczak wrote: Hello, On 12/18/2014 02:14 PM, Simon Glass wrote: Hi Przemyslaw, On 18 December 2014 at 03:26, Przemyslaw Marczak wrote: Hello Simon, On 12/18/2014 04:39 AM, Simon Glass wrote: Hi Przemyslaw, On 17 December 2014 at 02:03, Przemyslaw Marczak wrote: Hello, On 12/16/2014 11:26 PM, Simon Glass wrote: Hi Przemyslaw, On 12 December 2014 at 08:30, Przemyslaw Marczak wrote: Hello, On 12/12/2014 01:32 AM, Simon Glass wrote: Hi Przemyslaw, On 11 December 2014 at 05:01, Przemyslaw Marczak wrote: The present fat implementation ignores FAT16 long name directory entries which aren't placed in a single sector. This was becouse of the buffer was always filled by the two sectors, and the loop was made also for two sectors. If some file long name entries are stored in two sectors, the we have two cases: Case 1: Both of sectors are in the buffer - all required data for long file name is in the buffer. - Read OK! Case 2: The current directory entry is placed at the end of the second buffered sector. And the next entries are placed in a sector which is not buffered yet. Then two next sectors are buffered and the mentioned entry is ignored. - Read fail! This commit fixes this issue by: - read two sectors after loop on each single is done - keep the last used sector as a first in the buffer before the read of two next The commit doesn't affects the fat32 imlementation, which works good as previous. This is very interesting\! Is this the same failure that I saw on this thread? http://u-boot.10912.n7.nabble.com/PATCH-U-Boot-ARM-rpi-b-detect-board-revision-td196720.html (search for fatload) "I tried this out. It worked OK for me except that it can't find the device tree file bcm2835-rpi-b-rev2.dtb. Oddly I can fatload it from /bcm2835-rpi-b-rev2.dtb but when I try from /syslinux/..//bcm2835-rpi-b-rev2.dtb it fails and cannot find the file. Reducing the filename length to 8 chars works. I wonder what year of my life FAT will stop plaguing me? " Also can you write a test for this in test/fs/fs-test.sh? Regards, Simon [snip] Probably this is an another case which is caused by the sector buffer bug. Does this patch fixed your issue? I have some simple test for manual use with the ums tool. It just copy the test files to the tested fat16 partition mounted using the UMS, next it computes CRC32 of those files on the host and next using U-Boot fatload/crc32 commands - it tests the read feature. But it's not full automated - I didn't work on getting the log from U-Boot console. So I could check if the file checksums are proper and if all files were found on the partiion, by the U-Boot read command. It's not useful for the "test/fs/fs-test.sh" because this is not designed for the sandbox. My test writes some commands directly to U-Boot console, like this: echo "some cmd" > /dev/ttyS0. Unfortunately the sandbox config seems to be broken. The bug was not so obvious, any read/write on fat partition can change fat directory entries or add the new ones and then all data can be read right. I will send the scripts for such simple test. I'm not sure if it fixes my problem but it seems likely. I will see if I can make time to test it. If you want to write input data to U-Boot sandbox we can do that fairly easily. You can import cros_subprocess and use the function there to generate output from your test and inspect the input from U-Boot's command line. Let me know if you'd like an example. Regards, Simon Before, I wrote, that sandbox seems to be broken, sorry for this - it was just my dirty repo - sandbox compiles and works well. Somewhat bewildering, but it does not in fact fix my problem. Here is a compressed version of the fat filesystem if you want to take a look: https://drive.google.com/file/d/0B7WYZbZ9zd-3NGRMNkFQQTdtV2M/view?usp=sharing Regards, Simon I had put this image on my Trats2 device on partition mmc 0:6 using ums and dd linux command. Next I put latest mainline u-boot, commit: e3bf81b1e841ecabe7c8b3d48621256db8b8623e : "Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx" So this is the version with the fat bug. But I can see and load the file: "bcm2835-rpi-b-rev2.dtb". Trats2 # fatls mmc 0:6 17840 bootcode.bin 120 cmdline.txt 1331 config.txt 6115 fixup.dat 2324 fixup_cd.dat 9166 fixup_x.dat 3232856 kernel.img 2615064 start.elf 533080 start_cd.elf 3572200 start_x.elf 137 issue.txt 18974 license.oracle 295524 u-boot.bin 1331 config.txt~ extlinux/ 3368648 zimage 3963 bcm2835-rpi-b.dtb 3963 bcm2835.dtb 3963 bcm2835-rpi-b-rev2.dtb 18 file(s), 1 dir(s) Trats2 # fatload mmc 0:6 0x4000 bcm2835-rpi-b-rev2.dtb reading bcm2835-rpi-b-rev2.dtb
Re: [U-Boot] [PATCH] fs: fat: read: fix fat16 ls/read issue
Hi Przemyslaw, On 18 December 2014 at 06:31, Przemyslaw Marczak wrote: > Hello, > > > On 12/18/2014 02:14 PM, Simon Glass wrote: >> >> Hi Przemyslaw, >> >> On 18 December 2014 at 03:26, Przemyslaw Marczak >> wrote: >>> >>> Hello Simon, >>> >>> >>> On 12/18/2014 04:39 AM, Simon Glass wrote: Hi Przemyslaw, On 17 December 2014 at 02:03, Przemyslaw Marczak wrote: > > > Hello, > > > On 12/16/2014 11:26 PM, Simon Glass wrote: >> >> >> >> Hi Przemyslaw, >> >> On 12 December 2014 at 08:30, Przemyslaw Marczak >> >> wrote: >>> >>> >>> >>> Hello, >>> >>> >>> On 12/12/2014 01:32 AM, Simon Glass wrote: Hi Przemyslaw, On 11 December 2014 at 05:01, Przemyslaw Marczak wrote: > > > > > > The present fat implementation ignores FAT16 long name > directory entries which aren't placed in a single sector. > > This was becouse of the buffer was always filled by the > two sectors, and the loop was made also for two sectors. > > If some file long name entries are stored in two sectors, > the we have two cases: > > Case 1: > Both of sectors are in the buffer - all required data > for long file name is in the buffer. > - Read OK! > > Case 2: > The current directory entry is placed at the end of the > second buffered sector. And the next entries are placed > in a sector which is not buffered yet. Then two next > sectors are buffered and the mentioned entry is ignored. > - Read fail! > > This commit fixes this issue by: > - read two sectors after loop on each single is done > - keep the last used sector as a first in the buffer > before the read of two next > > The commit doesn't affects the fat32 imlementation, > which works good as previous. This is very interesting\! Is this the same failure that I saw on this thread? http://u-boot.10912.n7.nabble.com/PATCH-U-Boot-ARM-rpi-b-detect-board-revision-td196720.html (search for fatload) "I tried this out. It worked OK for me except that it can't find the device tree file bcm2835-rpi-b-rev2.dtb. Oddly I can fatload it from /bcm2835-rpi-b-rev2.dtb but when I try from /syslinux/..//bcm2835-rpi-b-rev2.dtb it fails and cannot find the file. Reducing the filename length to 8 chars works. I wonder what year of my life FAT will stop plaguing me? " Also can you write a test for this in test/fs/fs-test.sh? Regards, Simon [snip] >>> >>> Probably this is an another case which is caused by the sector buffer >>> bug. >>> Does this patch fixed your issue? >>> >>> I have some simple test for manual use with the ums tool. >>> It just copy the test files to the tested fat16 partition mounted >>> using >>> the >>> UMS, next it computes CRC32 of those files on the host and next using >>> U-Boot >>> fatload/crc32 commands - it tests the read feature. But it's not full >>> automated - I didn't work on getting the log from U-Boot console. >>> >>> So I could check if the file checksums are proper and if all files >>> were >>> found on the partiion, by the U-Boot read command. It's not useful >>> for >>> the >>> "test/fs/fs-test.sh" because this is not designed for the sandbox. >>> My test writes some commands directly to U-Boot console, like this: >>> echo >>> "some cmd" > /dev/ttyS0. >>> >>> Unfortunately the sandbox config seems to be broken. >>> >>> The bug was not so obvious, any read/write on fat partition can >>> change >>> fat >>> directory entries or add the new ones and then all data can be read >>> right. >>> >>> I will send the scripts for such simple test. >> >> >> >> >> I'm not sure if it fixes my problem but it seems likely. I will see if >> I can make time to test it. >> >> If you want to write input data to U-Boot sandbox we can do that >> fairly easily. You can import cros_subprocess and use the function >> there to generate output from your test and inspect the input from >> U-Boot's command line. Let me know if you'd like an example. >> >> Regards, >> Simon >> > > Before, I wrote, that sandbox seems to be broken, sorry for this - it > was > just my dirty repo - sandbox compiles and works well. Somew
Re: [U-Boot] [PATCH] fs: fat: read: fix fat16 ls/read issue
Hello, On 12/18/2014 02:14 PM, Simon Glass wrote: Hi Przemyslaw, On 18 December 2014 at 03:26, Przemyslaw Marczak wrote: Hello Simon, On 12/18/2014 04:39 AM, Simon Glass wrote: Hi Przemyslaw, On 17 December 2014 at 02:03, Przemyslaw Marczak wrote: Hello, On 12/16/2014 11:26 PM, Simon Glass wrote: Hi Przemyslaw, On 12 December 2014 at 08:30, Przemyslaw Marczak wrote: Hello, On 12/12/2014 01:32 AM, Simon Glass wrote: Hi Przemyslaw, On 11 December 2014 at 05:01, Przemyslaw Marczak wrote: The present fat implementation ignores FAT16 long name directory entries which aren't placed in a single sector. This was becouse of the buffer was always filled by the two sectors, and the loop was made also for two sectors. If some file long name entries are stored in two sectors, the we have two cases: Case 1: Both of sectors are in the buffer - all required data for long file name is in the buffer. - Read OK! Case 2: The current directory entry is placed at the end of the second buffered sector. And the next entries are placed in a sector which is not buffered yet. Then two next sectors are buffered and the mentioned entry is ignored. - Read fail! This commit fixes this issue by: - read two sectors after loop on each single is done - keep the last used sector as a first in the buffer before the read of two next The commit doesn't affects the fat32 imlementation, which works good as previous. This is very interesting\! Is this the same failure that I saw on this thread? http://u-boot.10912.n7.nabble.com/PATCH-U-Boot-ARM-rpi-b-detect-board-revision-td196720.html (search for fatload) "I tried this out. It worked OK for me except that it can't find the device tree file bcm2835-rpi-b-rev2.dtb. Oddly I can fatload it from /bcm2835-rpi-b-rev2.dtb but when I try from /syslinux/..//bcm2835-rpi-b-rev2.dtb it fails and cannot find the file. Reducing the filename length to 8 chars works. I wonder what year of my life FAT will stop plaguing me? " Also can you write a test for this in test/fs/fs-test.sh? Regards, Simon [snip] Probably this is an another case which is caused by the sector buffer bug. Does this patch fixed your issue? I have some simple test for manual use with the ums tool. It just copy the test files to the tested fat16 partition mounted using the UMS, next it computes CRC32 of those files on the host and next using U-Boot fatload/crc32 commands - it tests the read feature. But it's not full automated - I didn't work on getting the log from U-Boot console. So I could check if the file checksums are proper and if all files were found on the partiion, by the U-Boot read command. It's not useful for the "test/fs/fs-test.sh" because this is not designed for the sandbox. My test writes some commands directly to U-Boot console, like this: echo "some cmd" > /dev/ttyS0. Unfortunately the sandbox config seems to be broken. The bug was not so obvious, any read/write on fat partition can change fat directory entries or add the new ones and then all data can be read right. I will send the scripts for such simple test. I'm not sure if it fixes my problem but it seems likely. I will see if I can make time to test it. If you want to write input data to U-Boot sandbox we can do that fairly easily. You can import cros_subprocess and use the function there to generate output from your test and inspect the input from U-Boot's command line. Let me know if you'd like an example. Regards, Simon Before, I wrote, that sandbox seems to be broken, sorry for this - it was just my dirty repo - sandbox compiles and works well. Somewhat bewildering, but it does not in fact fix my problem. Here is a compressed version of the fat filesystem if you want to take a look: https://drive.google.com/file/d/0B7WYZbZ9zd-3NGRMNkFQQTdtV2M/view?usp=sharing Regards, Simon I had put this image on my Trats2 device on partition mmc 0:6 using ums and dd linux command. Next I put latest mainline u-boot, commit: e3bf81b1e841ecabe7c8b3d48621256db8b8623e : "Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx" So this is the version with the fat bug. But I can see and load the file: "bcm2835-rpi-b-rev2.dtb". Trats2 # fatls mmc 0:6 17840 bootcode.bin 120 cmdline.txt 1331 config.txt 6115 fixup.dat 2324 fixup_cd.dat 9166 fixup_x.dat 3232856 kernel.img 2615064 start.elf 533080 start_cd.elf 3572200 start_x.elf 137 issue.txt 18974 license.oracle 295524 u-boot.bin 1331 config.txt~ extlinux/ 3368648 zimage 3963 bcm2835-rpi-b.dtb 3963 bcm2835.dtb 3963 bcm2835-rpi-b-rev2.dtb 18 file(s), 1 dir(s) Trats2 # fatload mmc 0:6 0x4000 bcm2835-rpi-b-rev2.dtb reading bcm2835-rpi-b-rev2.dtb 3963 bytes read in 5 ms (773.4 KiB/s) Trats2 # crc32 0x4000 0xf7b CRC32 for 4000 ... 4f7a ==> c36ee8db Trats2 # The only missing file is "boot.scr"
Re: [U-Boot] [PATCH RFC] arm: mx6: Add CCGR0 configuration to default DCD (spl_sd.cfg)
Hi Stefan, On Mon, Dec 8, 2014 at 2:27 PM, Stefan Roese wrote: > Yes, its applied. I'm nearly on mainline right now. And it doesn't help. > Which makes sense if my current guess is correct, that the BootROM doesn't > load the SPL completely without this CCGR0 register setting in the DCD. On a mx6qsabresd booting via SPL: U-Boot SPL 2015.01-rc3-00158-ge3bf81b (Dec 18 2014 - 11:19:37) U-Boot 2015.01-rc3-00158-ge3bf81b (Dec 18 2014 - 11:19:37) CPU: Freescale i.MX6Q rev1.2 at 792 MHz CPU: Temperature 46 C Reset cause: POR Board: MX6-SabreSD I2C: ready DRAM: 1 GiB PMIC: PFUZE100 ID=0x10 MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 *** Warning - bad CRC, using default environment No panel detected: default to Hannstar-XGA Display: Hannstar-XGA (1024x768) In:serial Out: serial Err: serial Net: FEC [PRIME] Hit any key to stop autoboot: 0 => bmode sd3 resetting ... U-Boot SPL 2015.01-rc3-00158-ge3bf81b (Dec 18 2014 - 11:19:37) U-Boot 2015.01-rc3-00158-ge3bf81b (Dec 18 2014 - 11:19:37) CPU: Freescale i.MX6Q rev1.2 at 792 MHz CPU: Temperature 47 C Reset cause: WDOG Board: MX6-SabreSD I2C: ready DRAM: 1 GiB PMIC: PFUZE100 ID=0x10 MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 *** Warning - bad CRC, using default environment No panel detected: default to Hannstar-XGA Display: Hannstar-XGA (1024x768) In:serial Out: serial Err: serial Net: FEC [PRIME] Hit any key to stop autoboot: 0 => However if I move the SD card into SD2 slot, then it fails: => bmode sd2 resetting ... U-Boot SPL 2015.01-rc3-00158-ge3bf81b (Dec 18 2014 - 11:19:37) MMC: no card present spl: mmc init failed: err - -16 ### ERROR ### Please RESET the board ### The spl loaded, but it failed to load U-boot. Probably because SPL did not initialized SD2, so it seems things are working fine here. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] SPI: Add S25FL164K flash identifier info
On 17 November 2014 at 20:22, Ben Dooks wrote: > Add the necessary flash entry for the Spansion S25FL164K > flash. Tested on Marvell 88F6218 based design. > > Signed-off-by: Ben Dooks > --- > drivers/mtd/spi/sf_params.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c > index 462e5c2..c1f243b 100644 > --- a/drivers/mtd/spi/sf_params.c > +++ b/drivers/mtd/spi/sf_params.c > @@ -53,6 +53,7 @@ const struct spi_flash_params spi_flash_params_table[] = { > {"S25FL064A", 0x010216, 0x0, 64 * 1024, 128, 0, > 0}, > {"S25FL064A", 0x010216, 0x0, 64 * 1024, 128, 0, > 0}, > {"S25FL116k", 0x014015, 0x0, 64 * 1024, 128, 0, > 0}, > + {"S25FL164K", 0x014017, 0x0140,64 * 1024, 128, 0, > 0}, > {"S25FL128P_256K", 0x012018, 0x0300, 256 * 1024,64, RD_FULL, >WR_QPP}, > {"S25FL128P_64K", 0x012018, 0x0301,64 * 1024, 256, RD_FULL, >WR_QPP}, > {"S25FL032P", 0x010215, 0x4d00,64 * 1024,64, RD_FULL, >WR_QPP}, > -- > 2.1.1 > Applied to u-boot-spi/master thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] SPI: Add S25FL064A and S25FL116K flash information
On 18 December 2014 at 18:38, Ben Dooks wrote: > On 18/12/14 12:14, Jagan Teki wrote: >> On 17 November 2014 at 20:21, Ben Dooks wrote: >>> From: Adnan Ali >>> >>> Add S25FL064A and S25FL116K flash indentifiers. >>> >>> Signed-off-by: Adnan Ali >>> --- >>> drivers/mtd/spi/sf_params.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c >>> index 61545ca..462e5c2 100644 >>> --- a/drivers/mtd/spi/sf_params.c >>> +++ b/drivers/mtd/spi/sf_params.c >>> @@ -51,6 +51,8 @@ const struct spi_flash_params spi_flash_params_table[] = { >>> {"S25FL016A", 0x010214, 0x0, 64 * 1024,32, 0, >>> 0}, >>> {"S25FL032A", 0x010215, 0x0, 64 * 1024,64, 0, >>> 0}, >>> {"S25FL064A", 0x010216, 0x0, 64 * 1024, 128, 0, >>> 0}, >>> + {"S25FL064A", 0x010216, 0x0, 64 * 1024, 128, 0, >>> 0}, >> >> What is this, already there the same part - any new? > > I must have missed this when re-basing off the previous u-boot. > >>> + {"S25FL116k", 0x014015, 0x0, 64 * 1024, 128, 0, >>> 0}, >> >> Is this tested! can you rebase master and send the same patches. > > Yes, it was one of the devices we looked at and tested on a Marvell > 88F6281 based system. > >>> {"S25FL128P_256K", 0x012018, 0x0300, 256 * 1024,64, RD_FULL, >>> WR_QPP}, >>> {"S25FL128P_64K", 0x012018, 0x0301,64 * 1024, 256, RD_FULL, >>> WR_QPP}, >>> {"S25FL032P", 0x010215, 0x4d00,64 * 1024,64, RD_FULL, >>> WR_QPP}, >>> -- >>> 2.1.1 >>> Applied to u-boot-spi/master thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i2c_eeprom: include to fix build error
On 18 December 2014 at 04:00, Masahiro Yamada wrote: > drivers/misc/i2c_eeprom.c fails to build unless CONFIG_FIT_SIGNATURE > is defined. > > CC drivers/misc/i2c_eeprom.o > drivers/misc/i2c_eeprom.c: In function 'i2c_eeprom_read': > drivers/misc/i2c_eeprom.c:15:10: error: 'ENODEV' undeclared > (first use in this function) > drivers/misc/i2c_eeprom.c:15:10: note: each undeclared identifier > is reported only once for each function it appears in > drivers/misc/i2c_eeprom.c: In function 'i2c_eeprom_write': > drivers/misc/i2c_eeprom.c:21:10: error: 'ENODEV' undeclared > (first use in this function) > drivers/misc/i2c_eeprom.c:22:1: warning: control reaches end of > non-void function [-Wreturn-type] > drivers/misc/i2c_eeprom.c: In function 'i2c_eeprom_read': > drivers/misc/i2c_eeprom.c:16:1: warning: control reaches end of > non-void function [-Wreturn-type] > make[2]: *** [drivers/misc/i2c_eeprom.o] Error 1 > make[1]: *** [drivers/misc] Error 2 > make: *** [drivers] Error 2 > > By the way, Sandbox (enabling CONFIG_FIT_SIGNATURE) is luckily > working depending on it. > Sandbox includes include/asm-generic/errno.h > from include/errno.h > from include/u-boot/rsa-checksum.h > from include/image.h > from include/common.h > from drivers/misc/i2c_eeprom.c > > Signed-off-by: Masahiro Yamada > --- > > drivers/misc/i2c_eeprom.c | 1 + > 1 file changed, 1 insertion(+) Thanks! Acked-by: Simon Glass Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fs: fat: read: fix fat16 ls/read issue
Hi Przemyslaw, On 18 December 2014 at 03:26, Przemyslaw Marczak wrote: > Hello Simon, > > > On 12/18/2014 04:39 AM, Simon Glass wrote: >> >> Hi Przemyslaw, >> >> On 17 December 2014 at 02:03, Przemyslaw Marczak >> wrote: >>> >>> Hello, >>> >>> >>> On 12/16/2014 11:26 PM, Simon Glass wrote: Hi Przemyslaw, On 12 December 2014 at 08:30, Przemyslaw Marczak wrote: > > > Hello, > > > On 12/12/2014 01:32 AM, Simon Glass wrote: >> >> >> >> Hi Przemyslaw, >> >> On 11 December 2014 at 05:01, Przemyslaw Marczak >> >> wrote: >>> >>> >>> >>> >>> The present fat implementation ignores FAT16 long name >>> directory entries which aren't placed in a single sector. >>> >>> This was becouse of the buffer was always filled by the >>> two sectors, and the loop was made also for two sectors. >>> >>> If some file long name entries are stored in two sectors, >>> the we have two cases: >>> >>> Case 1: >>> Both of sectors are in the buffer - all required data >>> for long file name is in the buffer. >>> - Read OK! >>> >>> Case 2: >>> The current directory entry is placed at the end of the >>> second buffered sector. And the next entries are placed >>> in a sector which is not buffered yet. Then two next >>> sectors are buffered and the mentioned entry is ignored. >>> - Read fail! >>> >>> This commit fixes this issue by: >>> - read two sectors after loop on each single is done >>> - keep the last used sector as a first in the buffer >>> before the read of two next >>> >>> The commit doesn't affects the fat32 imlementation, >>> which works good as previous. >> >> >> >> >> >> This is very interesting\! Is this the same failure that I saw on this >> thread? >> >> >> >> >> http://u-boot.10912.n7.nabble.com/PATCH-U-Boot-ARM-rpi-b-detect-board-revision-td196720.html >> >> (search for fatload) >> >> "I tried this out. It worked OK for me except that it can't find the >> device tree file bcm2835-rpi-b-rev2.dtb. >> >> Oddly I can fatload it from /bcm2835-rpi-b-rev2.dtb but when I try >> from /syslinux/..//bcm2835-rpi-b-rev2.dtb it fails and cannot find the >> file. Reducing the filename length to 8 chars works. I wonder what >> year of my life FAT will stop plaguing me? " >> >> >> Also can you write a test for this in test/fs/fs-test.sh? >> >> Regards, >> Simon >> >> [snip] >> > > Probably this is an another case which is caused by the sector buffer > bug. > Does this patch fixed your issue? > > I have some simple test for manual use with the ums tool. > It just copy the test files to the tested fat16 partition mounted using > the > UMS, next it computes CRC32 of those files on the host and next using > U-Boot > fatload/crc32 commands - it tests the read feature. But it's not full > automated - I didn't work on getting the log from U-Boot console. > > So I could check if the file checksums are proper and if all files were > found on the partiion, by the U-Boot read command. It's not useful for > the > "test/fs/fs-test.sh" because this is not designed for the sandbox. > My test writes some commands directly to U-Boot console, like this: > echo > "some cmd" > /dev/ttyS0. > > Unfortunately the sandbox config seems to be broken. > > The bug was not so obvious, any read/write on fat partition can change > fat > directory entries or add the new ones and then all data can be read > right. > > I will send the scripts for such simple test. I'm not sure if it fixes my problem but it seems likely. I will see if I can make time to test it. If you want to write input data to U-Boot sandbox we can do that fairly easily. You can import cros_subprocess and use the function there to generate output from your test and inspect the input from U-Boot's command line. Let me know if you'd like an example. Regards, Simon >>> >>> Before, I wrote, that sandbox seems to be broken, sorry for this - it was >>> just my dirty repo - sandbox compiles and works well. >> >> >> Somewhat bewildering, but it does not in fact fix my problem. >> >> Here is a compressed version of the fat filesystem if you want to take a >> look: >> >> >> https://drive.google.com/file/d/0B7WYZbZ9zd-3NGRMNkFQQTdtV2M/view?usp=sharing >> >> Regards, >> Simon >> > > I had put this image on my Trats2 device on partition mmc 0:6 using ums and > dd linux command. Next I put latest mainline u-boot, commit: > e3bf81b1e841ecabe7c8b3d48621256db8b8623e : "Merge branch 'master' of > git://git.denx.de/u-boot-mpc85xx" > > So this is the version with the fat bug. But I can see and load the
Re: [U-Boot] [PATCH 1/2] SPI: Add S25FL064A and S25FL116K flash information
On 18/12/14 12:14, Jagan Teki wrote: > On 17 November 2014 at 20:21, Ben Dooks wrote: >> From: Adnan Ali >> >> Add S25FL064A and S25FL116K flash indentifiers. >> >> Signed-off-by: Adnan Ali >> --- >> drivers/mtd/spi/sf_params.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c >> index 61545ca..462e5c2 100644 >> --- a/drivers/mtd/spi/sf_params.c >> +++ b/drivers/mtd/spi/sf_params.c >> @@ -51,6 +51,8 @@ const struct spi_flash_params spi_flash_params_table[] = { >> {"S25FL016A", 0x010214, 0x0, 64 * 1024,32, 0, >> 0}, >> {"S25FL032A", 0x010215, 0x0, 64 * 1024,64, 0, >> 0}, >> {"S25FL064A", 0x010216, 0x0, 64 * 1024, 128, 0, >> 0}, >> + {"S25FL064A", 0x010216, 0x0, 64 * 1024, 128, 0, >> 0}, > > What is this, already there the same part - any new? I must have missed this when re-basing off the previous u-boot. >> + {"S25FL116k", 0x014015, 0x0, 64 * 1024, 128, 0, >> 0}, > > Is this tested! can you rebase master and send the same patches. Yes, it was one of the devices we looked at and tested on a Marvell 88F6281 based system. >> {"S25FL128P_256K", 0x012018, 0x0300, 256 * 1024,64, RD_FULL, >> WR_QPP}, >> {"S25FL128P_64K", 0x012018, 0x0301,64 * 1024, 256, RD_FULL, >> WR_QPP}, >> {"S25FL032P", 0x010215, 0x4d00,64 * 1024,64, RD_FULL, >> WR_QPP}, >> -- >> 2.1.1 >> > > thanks! > -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd/spi: Add support for SST25WF040B
On 3 December 2014 at 07:07, Shengzhou Liu wrote: > Add support for SST25WF040B-40I-SN flash. > Tested on T1024QDS board. > > Signed-off-by: Shengzhou Liu > --- > drivers/mtd/spi/sf_params.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c > index 61545ca..6e3a270 100644 > --- a/drivers/mtd/spi/sf_params.c > +++ b/drivers/mtd/spi/sf_params.c > @@ -98,6 +98,7 @@ const struct spi_flash_params spi_flash_params_table[] = { > {"SST25WF010", 0xbf2502, 0x0, 64 * 1024, 2, 0, > SECT_4K | SST_WP}, > {"SST25WF020", 0xbf2503, 0x0, 64 * 1024, 4, 0, > SECT_4K | SST_WP}, > {"SST25WF040", 0xbf2504, 0x0, 64 * 1024, 8, 0, > SECT_4K | SST_WP}, > + {"SST25WF040B",0x621613, 0x0, 64 * 1024, 8, 0, > SECT_4K | SST_WP}, > {"SST25WF080", 0xbf2505, 0x0, 64 * 1024,16, 0, > SECT_4K | SST_WP}, > #endif > #ifdef CONFIG_SPI_FLASH_WINBOND/* WINBOND */ > -- > 1.8.0 Applied to u-boot-spi/master thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: sf: Zap ramtron driver
On 6 November 2014 at 16:05, Jagannadha Sutradharudu Teki wrote: > Removed ramtron driver since the EMK boards are > no longer been active, and these are the only boards > used this flash driver. > > Commit details for EMK zap: > "ppc/arm: zap EMK boards" > (sha1: d58a9451e7339ed4cf2b2627e534611f427fb791) > > Signed-off-by: Jagannadha Sutradharudu Teki > Cc: Reinhard Meyer > --- > drivers/mtd/spi/Makefile | 1 - > drivers/mtd/spi/ramtron.c | 404 > -- > 2 files changed, 405 deletions(-) > delete mode 100644 drivers/mtd/spi/ramtron.c > > diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile > index 15789a0..c61b784 100644 > --- a/drivers/mtd/spi/Makefile > +++ b/drivers/mtd/spi/Makefile > @@ -17,6 +17,5 @@ obj-$(CONFIG_SPI_FLASH) += sf_probe.o > #endif > obj-$(CONFIG_CMD_SF) += sf.o > obj-$(CONFIG_SPI_FLASH) += sf_ops.o sf_params.o > -obj-$(CONFIG_SPI_FRAM_RAMTRON) += ramtron.o > obj-$(CONFIG_SPI_FLASH_SANDBOX) += sandbox.o > obj-$(CONFIG_SPI_M95XXX) += eeprom_m95xxx.o > diff --git a/drivers/mtd/spi/ramtron.c b/drivers/mtd/spi/ramtron.c > deleted file mode 100644 > index a23032c..000 > --- a/drivers/mtd/spi/ramtron.c > +++ /dev/null > @@ -1,404 +0,0 @@ > -/* > - * (C) Copyright 2010 > - * Reinhard Meyer, EMK Elektronik, reinhard.me...@emk-elektronik.de > - * > - * SPDX-License-Identifier:GPL-2.0+ > - */ > - > -/* > - * Note: RAMTRON SPI FRAMs are ferroelectric, nonvolatile RAMs > - * with an interface identical to SPI flash devices. > - * However since they behave like RAM there are no delays or > - * busy polls required. They can sustain read or write at the > - * allowed SPI bus speed, which can be 40 MHz for some devices. > - * > - * Unfortunately some RAMTRON devices do not have a means of > - * identifying them. They will leave the SO line undriven when > - * the READ-ID command is issued. It is therefore mandatory > - * that the MISO line has a proper pull-up, so that READ-ID > - * will return a row of 0xff. This 0xff pseudo-id will cause > - * probes by all vendor specific functions that are designed > - * to handle it. If the MISO line is not pulled up, READ-ID > - * could return any random noise, even mimicking another > - * device. > - * > - * We use CONFIG_SPI_FRAM_RAMTRON_NON_JEDEC > - * to define which device will be assumed after a simple status > - * register verify. This method is prone to false positive > - * detection and should therefore be the last to be tried. > - * Enter it in the last position in the table in spi_flash.c! > - * > - * The define CONFIG_SPI_FRAM_RAMTRON_NON_JEDEC both activates > - * compilation of the special handler and defines the device > - * to assume. > - */ > - > -#include > -#include > -#include > -#include > -#include "sf_internal.h" > - > -/* > - * Properties of supported FRAMs > - * Note: speed is currently not used because we have no method to deliver > that > - * value to the upper layers > - */ > -struct ramtron_spi_fram_params { > - u32 size; /* size in bytes */ > - u8 addr_len; /* number of address bytes */ > - u8 merge_cmd; /* some address bits are in the command byte > */ > - u8 id1;/* device ID 1 (family, density) */ > - u8 id2;/* device ID 2 (sub, rev, rsvd) */ > - u32 speed; /* max. SPI clock in Hz */ > - const char *name; /* name for display and/or matching */ > -}; > - > -struct ramtron_spi_fram { > - struct spi_flash flash; > - const struct ramtron_spi_fram_params *params; > -}; > - > -static inline struct ramtron_spi_fram *to_ramtron_spi_fram(struct spi_flash > -*flash) > -{ > - return container_of(flash, struct ramtron_spi_fram, flash); > -} > - > -/* > - * table describing supported FRAM chips: > - * chips without RDID command must have the values 0xff for id1 and id2 > - */ > -static const struct ramtron_spi_fram_params ramtron_spi_fram_table[] = { > - { > - .size = 32*1024, > - .addr_len = 2, > - .merge_cmd = 0, > - .id1 = 0x22, > - .id2 = 0x00, > - .speed = 4000, > - .name = "FM25V02", > - }, > - { > - .size = 32*1024, > - .addr_len = 2, > - .merge_cmd = 0, > - .id1 = 0x22, > - .id2 = 0x01, > - .speed = 4000, > - .name = "FM25VN02", > - }, > - { > - .size = 64*1024, > - .addr_len = 2, > - .merge_cmd = 0, > - .id1 = 0x23, > - .id2 = 0x00, > - .speed = 4000, > - .name = "FM25V05", > - }, > - { > - .size = 64*1024, > - .addr_len = 2, > - .merge_cmd = 0, > - .id1
Re: [U-Boot] Falcon mode boot support
Hi Tom, > I suspect that this might be related to the general problem on these > part families where SPL isn't as fast as we expect it to be, perhaps > cache related. I did a bit of digging around following this line of thought and found an old discussion on the mailing list (http://lists.denx.de/pipermail/u-boot/2013-June/156949.html) regarding someone who had a very similar problem with SPL/Falcon and NAND flash. I have emailed Bas van den Berg to see if he is willing to share his final implementation as adding the code that adds the SRAM to the MMU and enables the caches to the end of am33xx_spl_board_init() hangs within the enable_caches() function. Unfortunately this getting well out of my comfort zone with the ARM cores and so I'm not sure where to go next and how to debug it further. Regards, Andy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] SPI: Add S25FL064A and S25FL116K flash information
On 17 November 2014 at 20:21, Ben Dooks wrote: > From: Adnan Ali > > Add S25FL064A and S25FL116K flash indentifiers. > > Signed-off-by: Adnan Ali > --- > drivers/mtd/spi/sf_params.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c > index 61545ca..462e5c2 100644 > --- a/drivers/mtd/spi/sf_params.c > +++ b/drivers/mtd/spi/sf_params.c > @@ -51,6 +51,8 @@ const struct spi_flash_params spi_flash_params_table[] = { > {"S25FL016A", 0x010214, 0x0, 64 * 1024,32, 0, > 0}, > {"S25FL032A", 0x010215, 0x0, 64 * 1024,64, 0, > 0}, > {"S25FL064A", 0x010216, 0x0, 64 * 1024, 128, 0, > 0}, > + {"S25FL064A", 0x010216, 0x0, 64 * 1024, 128, 0, > 0}, What is this, already there the same part - any new? > + {"S25FL116k", 0x014015, 0x0, 64 * 1024, 128, 0, > 0}, Is this tested! can you rebase master and send the same patches. > {"S25FL128P_256K", 0x012018, 0x0300, 256 * 1024,64, RD_FULL, >WR_QPP}, > {"S25FL128P_64K", 0x012018, 0x0301,64 * 1024, 256, RD_FULL, >WR_QPP}, > {"S25FL032P", 0x010215, 0x4d00,64 * 1024,64, RD_FULL, >WR_QPP}, > -- > 2.1.1 > thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT] Pull request: u-boot-dfu (18-12-2014)
The following changes since commit 68ae882596524a2dde9da73283241b01d56375d5: USB: gadget: atmel_usba_udc: fix transfer hang issue (2014-12-16 16:08:50 +0100) are available in the git repository at: git://git.denx.de/u-boot-dfu.git for you to fetch changes up to 0ff7e585df83470139739533bdbf41114f395470: fastboot: handle flash write to GPT partitions (2014-12-18 12:26:06 +0100) Przemyslaw Marczak (3): dfu: mmc: check if mmc device exists in mmc_block_op() gadget: f_thor: check pointers before use in download_tail() dfu: dfu_get_buf: check the value of env dfu_bufsiz before use Rob Herring (2): usb, g_dnl: generalize DFU detach functions fastboot: add support for continue command Steve Rae (2): disk: part_efi: move code to static functions fastboot: handle flash write to GPT partitions README | 9 ++ common/cmd_dfu.c| 6 +- common/cmd_fastboot.c | 4 + common/fb_mmc.c | 26 +++- disk/part_efi.c | 268 +--- drivers/dfu/dfu.c | 24 +--- drivers/dfu/dfu_mmc.c | 8 +- drivers/usb/gadget/f_dfu.c | 2 +- drivers/usb/gadget/f_fastboot.c | 14 +++ drivers/usb/gadget/f_thor.c | 16 ++- drivers/usb/gadget/g_dnl.c | 17 +++ include/dfu.h | 3 - include/g_dnl.h | 4 + include/part.h | 20 +++ 14 files changed, 317 insertions(+), 104 deletions(-) -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A23 u-boot with SPL / dram init available in my personal git repo
Hi, On 15-12-14 07:01, Ricky Xian wrote: Hi, I'm trying to boot from usb fel mode on A23. I have rebuilt your sunxi-wip branch, and try to run on my A23 (q88?) board, but it's failed in fel mode in executing. I think the u-boot-spl.bin can be used as A20, this's the website I refer to: http://docs.cubieboard.org/tutorials/cb2/development/booting_from_usb_in_fel_mode my testing instructions are: fel write address u-boot-spl.bin fel exec address the address for A20 is 0x2000, so that the DRAM will be initialized. but it's incorrect for A23 if the size reach 0x4000. can you please let me know how to use fel and your u-boot-spl.bin? I've just tested this, and it works fine for me using the following commands: make -j4 CROSS_COMPILE=arm-linux-gnu- Ippo_q8h_v1_2_felconfig Note the _felconfig rather then _defconfig at the end ! And then: make -j4 CROSS_COMPILE=arm-linux-gnu- sudo ~hans/bin/fel write 0x2000 spl/u-boot-spl.bin sudo ~hans/bin/fel exe 0x2000 sleep 0.5 sudo ~hans/bin/fel write 0x4a00 u-boot.bin sudo ~hans/bin/fel exe 0x4a00 Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] [RFC] [v2] rsa: Use checksum algorithms from struct hash_algo
Currently the hash functions used in RSA are called directly from the sha1 and sha256 libraries. Change the RSA checksum library to use the progressive hash API's registered with struct hash_algo. This will allow the checksum library to use the support of hardware accelerated progressive hash API's once available. Signed-off-by: Ruchika Gupta CC: Simon Glass --- Changes in v2: Added generic function hash_calculate. Pass an additional argument as name of algorithm. common/image-sig.c| 6 ++--- include/image.h | 5 ++-- include/u-boot/rsa-checksum.h | 7 +++--- lib/rsa/rsa-checksum.c| 53 +++ lib/rsa/rsa-verify.c | 3 ++- 5 files changed, 60 insertions(+), 14 deletions(-) diff --git a/common/image-sig.c b/common/image-sig.c index 8601eda..2c9f0cd 100644 --- a/common/image-sig.c +++ b/common/image-sig.c @@ -38,7 +38,7 @@ struct checksum_algo checksum_algos[] = { #if IMAGE_ENABLE_SIGN EVP_sha1, #endif - sha1_calculate, + hash_calculate, padding_sha1_rsa2048, }, { @@ -48,7 +48,7 @@ struct checksum_algo checksum_algos[] = { #if IMAGE_ENABLE_SIGN EVP_sha256, #endif - sha256_calculate, + hash_calculate, padding_sha256_rsa2048, }, { @@ -58,7 +58,7 @@ struct checksum_algo checksum_algos[] = { #if IMAGE_ENABLE_SIGN EVP_sha256, #endif - sha256_calculate, + hash_calculate, padding_sha256_rsa4096, } diff --git a/include/image.h b/include/image.h index af30d60..ec55f23 100644 --- a/include/image.h +++ b/include/image.h @@ -926,8 +926,9 @@ struct checksum_algo { #if IMAGE_ENABLE_SIGN const EVP_MD *(*calculate_sign)(void); #endif - void (*calculate)(const struct image_region region[], - int region_count, uint8_t *checksum); + int (*calculate)(const char *name, +const struct image_region region[], +int region_count, uint8_t *checksum); const uint8_t *rsa_padding; }; diff --git a/include/u-boot/rsa-checksum.h b/include/u-boot/rsa-checksum.h index c996fb3..c546c80 100644 --- a/include/u-boot/rsa-checksum.h +++ b/include/u-boot/rsa-checksum.h @@ -16,9 +16,8 @@ extern const uint8_t padding_sha256_rsa4096[]; extern const uint8_t padding_sha256_rsa2048[]; extern const uint8_t padding_sha1_rsa2048[]; -void sha256_calculate(const struct image_region region[], int region_count, - uint8_t *checksum); -void sha1_calculate(const struct image_region region[], int region_count, - uint8_t *checksum); +int hash_calculate(const char *name, + const struct image_region region[], int region_count, + uint8_t *checksum); #endif diff --git a/lib/rsa/rsa-checksum.c b/lib/rsa/rsa-checksum.c index 8d8b59f..7f1909a 100644 --- a/lib/rsa/rsa-checksum.c +++ b/lib/rsa/rsa-checksum.c @@ -10,12 +10,13 @@ #include #include #include +#include #else #include "fdt_host.h" -#endif -#include #include #include +#endif +#include /* PKCS 1.5 paddings as described in the RSA PKCS#1 v2.1 standard. */ @@ -136,7 +137,33 @@ const uint8_t padding_sha256_rsa4096[RSA4096_BYTES - SHA256_SUM_LEN] = { 0x03, 0x04, 0x02, 0x01, 0x05, 0x00, 0x04, 0x20 }; -void sha1_calculate(const struct image_region region[], int region_count, +#ifndef USE_HOSTCC +int hash_calculate(const char *name, + const struct image_region region[], + int region_count, uint8_t *checksum) +{ + struct hash_algo *algo; + int ret = 0; + void *ctx; + uint32_t i; + i = 0; + + ret = hash_progressive_lookup_algo(name, &algo); + if (ret) + return ret; + + algo->hash_init(algo, &ctx); + for (i = 0; i < region_count - 1; i++) + algo->hash_update(algo, ctx, region[i].data, region[i].size, 0); + + algo->hash_update(algo, ctx, region[i].data, region[i].size, 1); + algo->hash_finish(algo, ctx, checksum, algo->digest_size); + + return 0; +} + +#else +int sha1_calculate(const struct image_region region[], int region_count, uint8_t *checksum) { sha1_context ctx; @@ -147,9 +174,11 @@ void sha1_calculate(const struct image_region region[], int region_count, for (i = 0; i < region_count; i++) sha1_update(&ctx, region[i].data, region[i].size); sha1_finish(&ctx, checksum); + + return 0; } -void sha256_calculate(const struct image_region region[], int region_count, +int sha256_calculate(const struct image_region region[], int region_count, uint8_t *checksum) { sha256_context ctx; @@ -160,4 +189,20 @@ void sha256_calculate(const struct image_region region[], int region_
[U-Boot] [PATCH 3/4] [RFC] [v2] hash: Add function to find hash_algo struct with progressive hash
The hash_algo structure has some implementations in which progressive hash API's are not defined. These are basically the hardware based implementations of SHA. An API is added to find the algo which has progressive hash API's defined. This can then be integrated with RSA checksum library which used Progressive Hash API's. Signed-off-by: Ruchika Gupta CC: Simon Glass --- Changes in v2 : Added commit message common/hash.c | 35 ++- include/hash.h | 15 +++ 2 files changed, 41 insertions(+), 9 deletions(-) diff --git a/common/hash.c b/common/hash.c index 12d6759..87263df 100644 --- a/common/hash.c +++ b/common/hash.c @@ -20,7 +20,7 @@ #include #include -#ifdef CONFIG_CMD_SHA1SUM +#ifdef CONFIG_SHA256 static int hash_init_sha1(struct hash_algo *algo, void **ctxp) { sha1_context *ctx = malloc(sizeof(sha1_context)); @@ -125,12 +125,8 @@ static struct hash_algo hash_algo[] = { CHUNKSZ_SHA256, }, #endif - /* -* This is CONFIG_CMD_SHA1SUM instead of CONFIG_SHA1 since otherwise -* it bloats the code for boards which use SHA1 but not the 'hash' -* or 'sha1sum' commands. -*/ -#ifdef CONFIG_CMD_SHA1SUM + +#ifdef CONFIG_SHA1 { "sha1", SHA1_SUM_LEN, @@ -140,7 +136,6 @@ static struct hash_algo hash_algo[] = { hash_update_sha1, hash_finish_sha1, }, -#define MULTI_HASH #endif #ifdef CONFIG_SHA256 { @@ -152,7 +147,6 @@ static struct hash_algo hash_algo[] = { hash_update_sha256, hash_finish_sha256, }, -#define MULTI_HASH #endif { "crc32", @@ -165,6 +159,10 @@ static struct hash_algo hash_algo[] = { }, }; +#if defined(CONFIG_SHA256) || defined(CONFIG_CMD_SHA1SUM) +#define MULTI_HASH +#endif + #if defined(CONFIG_HASH_VERIFY) || defined(CONFIG_CMD_HASH) #define MULTI_HASH #endif @@ -311,6 +309,25 @@ int hash_lookup_algo(const char *algo_name, struct hash_algo **algop) return -EPROTONOSUPPORT; } +int hash_progressive_lookup_algo(const char *algo_name, +struct hash_algo **algop) +{ + int i; + + for (i = 0; i < ARRAY_SIZE(hash_algo); i++) { + if (!strcmp(algo_name, hash_algo[i].name)) { + if (hash_algo[i].hash_init) { + *algop = &hash_algo[i]; + return 0; + } + } + } + + debug("Unknown hash algorithm '%s'\n", algo_name); + return -EPROTONOSUPPORT; +} + + void hash_show(struct hash_algo *algo, ulong addr, ulong len, uint8_t *output) { int i; diff --git a/include/hash.h b/include/hash.h index d8ec4f0..059f84e 100644 --- a/include/hash.h +++ b/include/hash.h @@ -128,6 +128,21 @@ int hash_block(const char *algo_name, const void *data, unsigned int len, int hash_lookup_algo(const char *algo_name, struct hash_algo **algop); /** + * hash_progressive_lookup_algo() - Look up the hash_algo struct with progressive + * hash support for an algorithm + * + * The function returns the pointer to the struct or -EPROTONOSUPPORT if the + * algorithm is not available with progressive hash support. + * + * @algo_name: Hash algorithm to look up + * @algop: Pointer to the hash_algo struct if found + * + * @return 0 if ok, -EPROTONOSUPPORT for an unknown algorithm. + */ +int hash_progressive_lookup_algo(const char *algo_name, +struct hash_algo **algop); + +/** * hash_show() - Print out a hash algorithm and value * * You will get a message like this (without a newline at the end): -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] [RFC] [v2] crypto/fsl: Add support for RSA Modular Exponentiation
Support added for offloading Modular Exponentiation required in RSA Verify functionality to hardware which depends on CONFIG_RSA_MOD_EXP_HW. Signed-off-by: Ruchika Gupta CC: Simon Glass --- Changes in v2: Added Kconfig option for RSA_MOD_HW drivers/crypto/fsl/Kconfig| 5 + drivers/crypto/fsl/Makefile | 1 + drivers/crypto/fsl/fsl_rsa.c | 44 +++ drivers/crypto/fsl/jobdesc.c | 28 +++ drivers/crypto/fsl/jobdesc.h | 5 + drivers/crypto/fsl/rsa_caam.h | 27 ++ lib/Kconfig | 11 +-- 7 files changed, 119 insertions(+), 2 deletions(-) create mode 100644 drivers/crypto/fsl/Kconfig create mode 100644 drivers/crypto/fsl/fsl_rsa.c create mode 100644 drivers/crypto/fsl/rsa_caam.h diff --git a/drivers/crypto/fsl/Kconfig b/drivers/crypto/fsl/Kconfig new file mode 100644 index 000..45e6683 --- /dev/null +++ b/drivers/crypto/fsl/Kconfig @@ -0,0 +1,5 @@ +config FSL_CAAM + depends on CRYPTO + bool "Freescale Crypto Driver Support" + help + HW Acceleration support for RSA based platforms diff --git a/drivers/crypto/fsl/Makefile b/drivers/crypto/fsl/Makefile index 067d0a9..ef36f67 100644 --- a/drivers/crypto/fsl/Makefile +++ b/drivers/crypto/fsl/Makefile @@ -8,4 +8,5 @@ obj-y += sec.o obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o +obj-$(CONFIG_RSA_MOD_EXP_HW) += fsl_rsa.o obj-$(CONFIG_CMD_BLOB) += fsl_blob.o diff --git a/drivers/crypto/fsl/fsl_rsa.c b/drivers/crypto/fsl/fsl_rsa.c new file mode 100644 index 000..1100316 --- /dev/null +++ b/drivers/crypto/fsl/fsl_rsa.c @@ -0,0 +1,44 @@ +/* + * Copyright (c) 2013, Google Inc. + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include "jobdesc.h" +#include "desc.h" +#include "jr.h" +#include "rsa_caam.h" +#include + +int rsa_mod_exp(const uint8_t *sig, uint32_t sig_len, + struct key_prop *prop, uint8_t *out) +{ + uint32_t keylen; + struct pk_in_params pkin; + uint32_t desc[MAX_CAAM_DESCSIZE]; + int ret; + + /* Length in bytes */ + keylen = prop->num_bits / 8; + + pkin.a = sig; + pkin.a_siz = sig_len; + pkin.n = prop->modulus; + pkin.n_siz = keylen; + pkin.e = prop->public_exponent; + pkin.e_siz = prop->exp_len; + + inline_cnstr_jobdesc_pkha_rsaexp(desc, &pkin, out, sig_len); + + ret = run_descriptor_jr(desc); + + if (ret) { + debug("%s: RSA failed to verify: %d\n", __func__, ret); + return ret; + } + + return 0; +} diff --git a/drivers/crypto/fsl/jobdesc.c b/drivers/crypto/fsl/jobdesc.c index 1386bae..cc0dced 100644 --- a/drivers/crypto/fsl/jobdesc.c +++ b/drivers/crypto/fsl/jobdesc.c @@ -11,6 +11,7 @@ #include #include "desc_constr.h" #include "jobdesc.h" +#include "rsa_caam.h" #define KEY_BLOB_SIZE 32 #define MAC_SIZE 16 @@ -123,3 +124,30 @@ void inline_cnstr_jobdesc_rng_instantiation(uint32_t *desc) append_operation(desc, OP_TYPE_CLASS1_ALG | OP_ALG_ALGSEL_RNG | OP_ALG_RNG4_SK); } + +/* Change key size to bytes form bits in calling function*/ +void inline_cnstr_jobdesc_pkha_rsaexp(uint32_t *desc, + struct pk_in_params *pkin, uint8_t *out, + uint32_t out_siz) +{ + dma_addr_t dma_addr_e, dma_addr_a, dma_addr_n, dma_addr_out; + + dma_addr_e = virt_to_phys((void *)pkin->e); + dma_addr_a = virt_to_phys((void *)pkin->a); + dma_addr_n = virt_to_phys((void *)pkin->n); + dma_addr_out = virt_to_phys((void *)out); + + init_job_desc(desc, 0); + append_key(desc, dma_addr_e, pkin->e_siz, KEY_DEST_PKHA_E | CLASS_1); + + append_fifo_load(desc, dma_addr_a, +pkin->a_siz, LDST_CLASS_1_CCB | FIFOLD_TYPE_PK_A); + + append_fifo_load(desc, dma_addr_n, +pkin->n_siz, LDST_CLASS_1_CCB | FIFOLD_TYPE_PK_N); + + append_operation(desc, OP_TYPE_PK | OP_ALG_PK | OP_ALG_PKMODE_MOD_EXPO); + + append_fifo_store(desc, dma_addr_out, out_siz, + LDST_CLASS_1_CCB | FIFOST_TYPE_PKHA_B); +} diff --git a/drivers/crypto/fsl/jobdesc.h b/drivers/crypto/fsl/jobdesc.h index 3cf7226..84b3edd 100644 --- a/drivers/crypto/fsl/jobdesc.h +++ b/drivers/crypto/fsl/jobdesc.h @@ -10,6 +10,7 @@ #include #include +#include "rsa_caam.h" #define KEY_IDNFR_SZ_BYTES 16 @@ -26,4 +27,8 @@ void inline_cnstr_jobdesc_blob_decap(uint32_t *desc, uint8_t *key_idnfr, uint32_t out_sz); void inline_cnstr_jobdesc_rng_instantiation(uint32_t *desc); + +void inline_cnstr_jobdesc_pkha_rsaexp(uint32_t *desc, + struct pk_in_params *pkin, uint8_t *out, + uint32_t out_s
[U-Boot] [PATCH 1/4] [RFC] [v2] rsa: Split the rsa-verify
Public exponentiation which is required in rsa verify functionality is currently tightly integrated with verification code in rsa_verify.c. Currently this implementation is software based. Some platforms having support of the exponentiation in hardware. To enable the rsa verify functionality to use the Modular exponentiation if present in hardware, the patch-set splits the file into two files: 1. rsa-verify.c - The file parses device tree keys node to fill a keyprop structure. The keyprop structure can then be converted to implementation specific formal (struct rsa_pub_key for sw implementation). - The parsed device tree node is then passed to a generic rsa_mod_exp function. 2. rsa-mod-exp.c Move the software specific functions related to exponentiation from rsa-verify.c to this file. The file is compiled if "CONFIG_RSA_MOD_EXP_SW" is defined. In general if both CONFIG_FIT_SIGNATURE and CONFIG_RSA are defined, CONFIG_RSA_MOD_EXP_SW gets automatically defined. Platforms having hardware implementation for rsa_mod_exp can add a define "CONFIG_RSA_MOD_EXP_HW" to their config files. Adding this defined, undefs the CONFIG_RSA_MOD_EXP_SW and hardware implementation of mod_exp gets compiled. Signed-off-by: Ruchika Gupta CC: Simon Glass --- Changes in v2: Addressed few of Simon Glass's comments: - Kconfig option added for RSA - Comments added for new keyprop struct Kconfig | 2 + include/config_fallbacks.h | 8 ++ include/u-boot/rsa-mod-exp.h | 34 + lib/Kconfig | 15 +++ lib/rsa/Makefile | 1 + lib/rsa/rsa-mod-exp.c| 308 +++ lib/rsa/rsa-verify.c | 307 +- tools/Makefile | 2 +- 8 files changed, 399 insertions(+), 278 deletions(-) create mode 100644 include/u-boot/rsa-mod-exp.h create mode 100644 lib/rsa/rsa-mod-exp.c diff --git a/Kconfig b/Kconfig index 153ee2b..82b14bd 100644 --- a/Kconfig +++ b/Kconfig @@ -101,6 +101,7 @@ config TPL help If you want to build TPL as well as the normal image and SPL, say Y. + config FIT bool "Support Flattened Image Tree" depends on !SPL_BUILD @@ -118,6 +119,7 @@ config FIT_VERBOSE config FIT_SIGNATURE bool "Enabel signature verification of FIT uImages" depends on FIT + select RSA help This option enables signature verification of FIT uImages, using a hash signed and verified using RSA. diff --git a/include/config_fallbacks.h b/include/config_fallbacks.h index ddfe045..b46bef9 100644 --- a/include/config_fallbacks.h +++ b/include/config_fallbacks.h @@ -83,6 +83,14 @@ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + 128) #endif +/* This can be removed once all platforms move to defconfig + * option to enable FIT_SIGNATURE + */ +#if defined(CONFIG_FIT_SIGNATURE) && defined(CONFIG_RSA) && \ + !defined(CONFIG_RSA_MOD_EXP_HW) && !defined(CONFIG_RSA_MOD_EXP_SW) +#define CONFIG_RSA_MOD_EXP_SW +#endif + #ifndef CONFIG_FIT_SIGNATURE #define CONFIG_IMAGE_FORMAT_LEGACY #endif diff --git a/include/u-boot/rsa-mod-exp.h b/include/u-boot/rsa-mod-exp.h new file mode 100644 index 000..0d2ccd6 --- /dev/null +++ b/include/u-boot/rsa-mod-exp.h @@ -0,0 +1,34 @@ +/* + * Copyright (c) 2014, Ruchika Gupta. + * + * SPDX-License-Identifier:GPL-2.0+ +*/ + +#ifndef _RSA_MOD_EXP_H +#define _RSA_MOD_EXP_H + +#include +#include + +/** + * struct key_prop - holder for a public key properties + * + * The struct has pointers to modulus (Typically called N), + * The inverse, R^2, exponent. These can be typecasted and + * used as byte arrays or converted to the required format + * as per requirement of RSA implementation. + * + */ +struct key_prop { + const void *rr; /* R^2 can be treated as byte array */ + const void *modulus;/* modulus as byte array */ + const void *public_exponent; /* public exponent as byte array */ + uint32_t n0inv; /* -1 / modulus[0] mod 2^32 */ + int num_bits; /* Key length in bits */ + uint32_t exp_len; /* Exponent length in number of uint8_t */ +}; + +int rsa_mod_exp(const uint8_t *sig, uint32_t sig_len, + struct key_prop *node, uint8_t *out); + +#endif diff --git a/lib/Kconfig b/lib/Kconfig index 8460439..a921bb3 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -27,4 +27,19 @@ config SYS_HZ get_timer() must operate in milliseconds and this option must be set to 1000. +config RSA + bool "Use RSA Library" + help + RSA support + +if RSA + +config RSA_MOD_EXP_SW + depends on RSA + bool "Implement RSA Modular Exponentiation in software" + default y + help + Modular Exponentiation support in SW + +endif endmenu diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile index a5a96cb6..ccc6060 100644 --- a/lib/rsa/Makefile +++ b/lib/rsa/Makefile @@ -8,3
Re: [U-Boot] [PATCH 13/14] sun8i: Add dram initialization support
On Wed, Dec 17, 2014 at 4:31 AM, Hans de Goede wrote: > Based on the register / dram_para headers from the Allwinner u-boot / linux > sources + the init sequences from boot0. > > Signed-off-by: Hans de Goede > --- > arch/arm/cpu/armv7/sunxi/Makefile | 1 + > arch/arm/cpu/armv7/sunxi/board.c | 3 +- > arch/arm/cpu/armv7/sunxi/dram_sun8i.c | 340 > ++ > arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 4 + > arch/arm/include/asm/arch-sunxi/dram.h| 2 + > arch/arm/include/asm/arch-sunxi/dram_sun8i.h | 266 > board/sunxi/Kconfig | 3 +- > configs/Ippo_q8h_v5_defconfig | 17 +- > include/configs/sun8i.h | 2 + > 9 files changed, 631 insertions(+), 7 deletions(-) > create mode 100644 arch/arm/cpu/armv7/sunxi/dram_sun8i.c > create mode 100644 arch/arm/include/asm/arch-sunxi/dram_sun8i.h > > diff --git a/arch/arm/cpu/armv7/sunxi/Makefile > b/arch/arm/cpu/armv7/sunxi/Makefile > index 3e8975a..1e89937 100644 > --- a/arch/arm/cpu/armv7/sunxi/Makefile > +++ b/arch/arm/cpu/armv7/sunxi/Makefile > @@ -33,6 +33,7 @@ obj-$(CONFIG_MACH_SUN4I) += dram_sun4i.o > obj-$(CONFIG_MACH_SUN5I) += dram_sun4i.o > obj-$(CONFIG_MACH_SUN6I) += dram_sun6i.o > obj-$(CONFIG_MACH_SUN7I) += dram_sun4i.o > +obj-$(CONFIG_MACH_SUN8I) += dram_sun8i.o > ifdef CONFIG_SPL_FEL > obj-y += start.o > endif > diff --git a/arch/arm/cpu/armv7/sunxi/board.c > b/arch/arm/cpu/armv7/sunxi/board.c > index 9b3e80c..bc98c56 100644 > --- a/arch/arm/cpu/armv7/sunxi/board.c > +++ b/arch/arm/cpu/armv7/sunxi/board.c > @@ -114,7 +114,8 @@ void reset_cpu(ulong addr) > /* do some early init */ > void s_init(void) > { > -#if defined CONFIG_SPL_BUILD && defined CONFIG_MACH_SUN6I > +#if defined CONFIG_SPL_BUILD && \ > + (defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I) > /* Magic (undocmented) value taken from boot0, without this DRAM > * access gets messed up (seems cache related) */ > setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0x1800); > diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun8i.c > b/arch/arm/cpu/armv7/sunxi/dram_sun8i.c > new file mode 100644 > index 000..3736fd1 > --- /dev/null > +++ b/arch/arm/cpu/armv7/sunxi/dram_sun8i.c > @@ -0,0 +1,340 @@ > +/* > + * Sun8i platform dram controller init. > + * > + * (C) Copyright 2014 Hans de Goede > + * > + * SPDX-License-Identifier:GPL-2.0+ > + */ > + > +/* > + * Note this code uses a lot of magic hex values, that is because this code > + * simply replays the init sequence as done by the Allwinner boot0 code, so > + * we do not know what these values mean. There are no symbolic constants for > + * these magic values, since we do not know how to name them and making up > + * names for them is not useful. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +static const struct dram_para dram_para = { > + .clock = CONFIG_DRAM_CLK, > + .type = 3, > + .zq = CONFIG_DRAM_ZQ, > + .odt_en = 1, > + .para1 = 0, /* not used (only used when tpr13 bit 31 is set */ > + .para2 = 0, /* not used (only used when tpr13 bit 31 is set */ > + .mr0 = 6736, > + .mr1 = 4, > + .mr2 = 16, > + .mr3 = 0, > + /* tpr0 - 10 contain timing constants or-ed together in u32 vals */ > + .tpr0 = 0x2ab83def, > + .tpr1 = 0x18082356, > + .tpr2 = 0x00034156, > + .tpr3 = 0x448c5533, > + .tpr4 = 0x08010d00, > + .tpr5 = 0x0340b20f, > + .tpr6 = 0x20d118cc, > + .tpr7 = 0x14062485, > + .tpr8 = 0x220d1d52, > + .tpr9 = 0x1e078c22, > + .tpr10 = 0x3c, > + .tpr11 = 0, /* not used */ > + .tpr12 = 0, /* not used */ > + .tpr13 = 0x3, > +}; > + > +static void mctl_sys_init(void) > +{ > + struct sunxi_ccm_reg * const ccm = > + (struct sunxi_ccm_reg *)SUNXI_CCM_BASE; > + > + /* enable pll5, note the divide by 2 is deliberate! */ > + clock_set_pll5(dram_para.clock * 100 / 2, 1, 2, > + dram_para.tpr13 & 0x4); > + > + /* deassert ahb mctl reset */ > + setbits_le32(&ccm->ahb_reset0_cfg, 1 << AHB_RESET_OFFSET_MCTL); > + > + /* enable ahb mctl clock */ > + setbits_le32(&ccm->ahb_gate0, 1 << AHB_GATE_OFFSET_MCTL); > +} > + > +static void mctl_apply_odt_correction(u32 *reg, int correction) > +{ > + int val; > + > + val = (readl(reg) >> 8) & 0xff; > + val += correction; > + > + /* clamp */ > + if (val < 0) > + val = 0; > + else if (val > 255) > + val = 255; > + > + clrsetbits_le32(reg, 0xff00, val << 8); > +} > + > +static void mctl_init(u32 *bus_width) > +{ > + struct sunxi_ccm_reg * const ccm = > + (struct sunxi_ccm_reg *)SUNXI_CCM_BASE; > + struct sunxi_mctl_com
[U-Boot] [PATCH] i2c_eeprom: include to fix build error
drivers/misc/i2c_eeprom.c fails to build unless CONFIG_FIT_SIGNATURE is defined. CC drivers/misc/i2c_eeprom.o drivers/misc/i2c_eeprom.c: In function 'i2c_eeprom_read': drivers/misc/i2c_eeprom.c:15:10: error: 'ENODEV' undeclared (first use in this function) drivers/misc/i2c_eeprom.c:15:10: note: each undeclared identifier is reported only once for each function it appears in drivers/misc/i2c_eeprom.c: In function 'i2c_eeprom_write': drivers/misc/i2c_eeprom.c:21:10: error: 'ENODEV' undeclared (first use in this function) drivers/misc/i2c_eeprom.c:22:1: warning: control reaches end of non-void function [-Wreturn-type] drivers/misc/i2c_eeprom.c: In function 'i2c_eeprom_read': drivers/misc/i2c_eeprom.c:16:1: warning: control reaches end of non-void function [-Wreturn-type] make[2]: *** [drivers/misc/i2c_eeprom.o] Error 1 make[1]: *** [drivers/misc] Error 2 make: *** [drivers] Error 2 By the way, Sandbox (enabling CONFIG_FIT_SIGNATURE) is luckily working depending on it. Sandbox includes include/asm-generic/errno.h from include/errno.h from include/u-boot/rsa-checksum.h from include/image.h from include/common.h from drivers/misc/i2c_eeprom.c Signed-off-by: Masahiro Yamada --- drivers/misc/i2c_eeprom.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/misc/i2c_eeprom.c b/drivers/misc/i2c_eeprom.c index d0548ec..814134a 100644 --- a/drivers/misc/i2c_eeprom.c +++ b/drivers/misc/i2c_eeprom.c @@ -5,6 +5,7 @@ */ #include +#include #include #include #include -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: OMAP5: DRA7xx: Enable I2C4 and I2C5 usage on the J6Eco EVM
Tom, Even if this patch is not applied if considered useless, the one fixing the clocks (http://patchwork.ozlabs.org/patch/410834/) should be, in my opinion, as it is essentially a bug fix. Now, for the DRA7xx SoCs, 1) a write to a undefined (or zero) register address is occurring since struct member .cm_l4per_i2c5_clkctrl is not initialized, and 2) a 'data abort' exception shall happen if access to I2C5 is tried due to lack of the functional clock. Best regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] kbuild: Fix a false error of generic board support
Hi Marek, Tom, On Wed, 17 Dec 2014 10:52:32 -0500 Tom Rini wrote: > On Wed, Dec 17, 2014 at 02:04:32AM +0100, Marek Vasut wrote: > > On Wednesday, December 17, 2014 at 12:56:46 AM, Tom Rini wrote: > > > On Tue, Dec 16, 2014 at 02:56:44PM -0600, mgerlach wrote: > > > > Hello Masahiro Yamada, > > > > > > > > Even the with this patch, we encountered a false error of generic board > > > > support. The problem was very interrmittent for us, but we were able > > > > to debug the problem to performing builds on EXT3 file systems which > > > > have a time stamp resolution of one second. To reproduce the problem, > > > > touch ./include/config/auto.conf and .config on a configured uboot tree > > > > on an EXT3 file system. > > > > > > > > The patch below fixes the problem for us. > > > > > > This makes an odd race condition problem I run into when doing massively > > > paralell builds worse :( With MAKEALL no ARM boards build (ARCH wasn't > > > set in time so it tried arch//Makefile for something) and buildman was > > > also broken in a bunch of places. > > > > Let me just chime in, I recall I did report something possibly similar some > > time > > ago [1]. I did not manage to put a finger on this issue though and I can no > > longer trigger it. > > > > [1] http://lists.denx.de/pipermail/u-boot/2013-June/157481.html > > No, my problem was introduced with the switch to Kbuild itself. Marek's problem is unrelated to this issue. (2013-June is before Kbuild) York Sun also reported the similar build error in this thread. http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/203331/focus=203468 This is really related to what Mathew saw, I think. Some bug reports imply "autoconf_is_current" is not working on some cases although I have never been able to reproduce the problem on my box. I guess it is almost time for further build-system refactoring. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/14] sunxi: axp221: Add axp223 support
Hi, On 17-12-14 03:34, Chen-Yu Tsai wrote: On Wed, Dec 17, 2014 at 4:31 AM, Hans de Goede wrote: The axp223 appears to be the same as the axp221, except that it uses the rsb to communicate rather then the p2wi. At least all the registers we use are 100% the same. Signed-off-by: Hans de Goede --- arch/arm/cpu/armv7/sunxi/cpu_info.c | 2 +- drivers/power/Kconfig | 8 ++-- drivers/power/axp221.c | 88 - include/axp221.h| 4 ++ 4 files changed, 76 insertions(+), 26 deletions(-) diff --git a/arch/arm/cpu/armv7/sunxi/cpu_info.c b/arch/arm/cpu/armv7/sunxi/cpu_info.c index 7a3a4ca..b6cb9de 100644 --- a/arch/arm/cpu/armv7/sunxi/cpu_info.c +++ b/arch/arm/cpu/armv7/sunxi/cpu_info.c @@ -76,7 +76,7 @@ int print_cpuinfo(void) int sunxi_get_sid(unsigned int *sid) { -#ifdef CONFIG_MACH_SUN6I +#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I #ifdef CONFIG_AXP221_POWER return axp221_get_sid(sid); #else diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 1ec7c0e..7373a79 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -1,10 +1,10 @@ config AXP221_POWER - boolean "axp221 pmic support" - depends on MACH_SUN6I + boolean "axp221 / axp223 pmic support" + depends on MACH_SUN6I || MACH_SUN8I default y ---help--- - Say y here to enable support for the axp221 pmic found on most sun6i - (A31) boards. + Say y here to enable support for the axp221 / axp223 pmic found on most + sun6i (A31) / sun8i (A23) boards. config AXP221_DLDO1_VOLT int "axp221 dldo1 voltage" diff --git a/drivers/power/axp221.c b/drivers/power/axp221.c index 826567a..717adad 100644 --- a/drivers/power/axp221.c +++ b/drivers/power/axp221.c @@ -1,4 +1,10 @@ /* + * AXP221 and AXP223 driver + * + * IMPORTANT when making changes to this file check that the registers + * used are the same for the axp221 and axp223. + * + * (C) Copyright 2014 Hans de Goede * (C) Copyright 2013 Oliver Schinagl * * SPDX-License-Identifier:GPL-2.0+ @@ -7,8 +13,50 @@ #include #include #include +#include #include +/* + * The axp221 uses the p2wi bus, the axp223 is identical (for all registers + * used sofar) but uses the rsb bus. These functions abstract this. + */ +static int pmic_bus_init(void) +{ +#ifdef CONFIG_MACH_SUN6I + p2wi_init(); + return p2wi_change_to_p2wi_mode(AXP221_CHIP_ADDR, AXP221_CTRL_ADDR, + AXP221_INIT_DATA); +#else + int ret; + + rsb_init(); + + ret = rsb_set_device_mode(AXP223_DEVICE_MODE_DATA); + if (ret) + return ret; + + return rsb_set_device_address(AXP223_DEVICE_ADDR, AXP223_RUNTIME_ADDR); +#endif +} + +static int pmic_bus_read(const u8 addr, u8 *data) +{ +#ifdef CONFIG_MACH_SUN6I + return p2wi_read(addr, data); +#else + return rsb_read(AXP223_RUNTIME_ADDR, addr, data); +#endif +} + +static int pmic_bus_write(const u8 addr, u8 data) +{ +#ifdef CONFIG_MACH_SUN6I + return p2wi_write(addr, data); +#else + return rsb_write(AXP223_RUNTIME_ADDR, addr, data); +#endif +} + static u8 axp221_mvolt_to_cfg(int mvolt, int min, int max, int div) { if (mvolt < min) @@ -24,12 +72,12 @@ static int axp221_setbits(u8 reg, u8 bits) int ret; u8 val; - ret = p2wi_read(reg, &val); + ret = pmic_bus_read(reg, &val); if (ret) return ret; val |= bits; - return p2wi_write(reg, val); + return pmic_bus_write(reg, val); } int axp221_set_dcdc1(unsigned int mvolt) @@ -37,7 +85,7 @@ int axp221_set_dcdc1(unsigned int mvolt) int ret; u8 cfg = axp221_mvolt_to_cfg(mvolt, 1600, 3400, 100); - ret = p2wi_write(AXP221_DCDC1_CTRL, cfg); + ret = pmic_bus_write(AXP221_DCDC1_CTRL, cfg); if (ret) return ret; @@ -49,28 +97,28 @@ int axp221_set_dcdc2(unsigned int mvolt) { u8 cfg = axp221_mvolt_to_cfg(mvolt, 600, 1540, 20); - return p2wi_write(AXP221_DCDC2_CTRL, cfg); + return pmic_bus_write(AXP221_DCDC2_CTRL, cfg); } int axp221_set_dcdc3(unsigned int mvolt) { u8 cfg = axp221_mvolt_to_cfg(mvolt, 600, 1860, 20); - return p2wi_write(AXP221_DCDC3_CTRL, cfg); + return pmic_bus_write(AXP221_DCDC3_CTRL, cfg); } int axp221_set_dcdc4(unsigned int mvolt) { u8 cfg = axp221_mvolt_to_cfg(mvolt, 600, 1540, 20); - return p2wi_write(AXP221_DCDC4_CTRL, cfg); + return pmic_bus_write(AXP221_DCDC4_CTRL, cfg); } int axp221_set_dcdc5(unsigned int mvolt) { u8 cfg = axp221_mvolt_to_cfg(mvolt, 1000, 2550, 50); - return p2wi_write(AXP221_DCDC5_CTRL, cfg); + return pmic_bus_write(AXP221_DCDC5_CTRL, cfg); } int axp221_set_dldo1(unsigned int mvolt) @@ -78,7 +126,7 @@ int axp221_set_dldo1(unsigned in
Re: [U-Boot] [PATCH 1/2] kbuild: Fix a false error of generic board support
Hi Matthew, Tom, On Tue, 16 Dec 2014 18:56:46 -0500 Tom Rini wrote: > On Tue, Dec 16, 2014 at 02:56:44PM -0600, mgerlach wrote: > > > Hello Masahiro Yamada, > > > > Even the with this patch, we encountered a false error of generic board > > support. The problem was very interrmittent for us, but we were able > > to debug the problem to performing builds on EXT3 file systems which > > have a time stamp resolution of one second. To reproduce the problem, > > touch ./include/config/auto.conf and .config on a configured uboot tree on > > an EXT3 file system. > > > > The patch below fixes the problem for us. > > This makes an odd race condition problem I run into when doing massively > paralell builds worse :( With MAKEALL no ARM boards build (ARCH wasn't > set in time so it tried arch//Makefile for something) and buildman was > also broken in a bunch of places. > Me too. Although I do not know why, Methew's patch makes it worse. Without MAKEALL or buildman, I hit the same error every time. $ LANG=C make -j8 CROSS_COMPILE=arm-linux-gnueabi- ph1_ld4_defconfig all HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf # # configuration written to .config # # # configuration written to spl/.config # ./Makefile:511: arch//Makefile: No such file or directory make[1]: *** No rule to make target `arch//Makefile'. Stop. make: *** [__build_one_by_one] Error 2 Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] sun6i: Add new CSQ_CS908 board
Hi, On 14-12-14 15:57, Ian Campbell wrote: On Sun, 2014-11-23 at 14:43 +0100, Hans de Goede wrote: The CSQ CS908 is an A31s based top-set box, with 1G RAM, 8G NAND, rtl8188etv usb wifi, 2 USB A receptacles (1 connected through the OTG controller), ethernet, 3.5 mm jack with a/v out and hdmi out: http://www.geekbuying.com/item/CS908-Allwinner-A31S-Quad-Core-1-2GHz-Android-4-4-Mini-TV-Box-HDMI-HDD-Player-1G-8G-WIFI-Miracast---Black-95.html Note it has no sdcard slot and therefore can only be fel booted. Signed-off-by: Hans de Goede Acked-by: Ian Campbell --- configs/CSQ_CS908_defconfig | 19 +++ Apparently I'm terrible at remembering this during review: this is missing a MAINTAINERS entry. (MAKEALL warns about this when regenerating boards.cfg). Yeah, I'm bad at remembering to update MAINTAINERS too... Since this patch is only in u-boot-sunxi#next so far do you just want to fold in an update to add it to your stanza (or add a new appropriate stanza) and force push? Ack to that plan if you do. Done (fixed, forced-push). I've also fixed the same problem for the new Ippo_q8h_v1.2_defconfig in my sun8i spl / draminit set in my personal tree. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot