[U-Boot] [PATCH 3/7] spl: Use u-boot.img instead of u-boot.bin when CONFIG_SPL_PBL_PAD is enabled
In SD boot, the magic number of u-boot image will be checked. For LS102xA, u-boot.bin doesn't have the magic number. So use u-boot.img which includes the magic number instead of u-boot.bin when building u-boot-with-spl-pbl.bin. Signed-off-by: Alison Wang alison.w...@freescale.com --- Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 6af424e..d4a3899 100644 --- a/Makefile +++ b/Makefile @@ -967,8 +967,10 @@ u-boot-img.bin: spl/u-boot-spl.bin u-boot.img FORCE ifdef CONFIG_SPL_PBL_PAD SPLPBL_BINLOAD := spl/u-boot-spl-pbl-pad.bin +UBOOT_BINLOAD := u-boot.img else SPLPBL_BINLOAD := spl/u-boot-spl.bin +UBOOT_BINLOAD := u-boot.bin endif #Add a target to create boot binary having SPL binary in PBI format @@ -989,7 +991,7 @@ spl/u-boot-spl-pbl-pad.bin: spl/u-boot-spl.bin FORCE OBJCOPYFLAGS_u-boot-with-spl-pbl.bin = -I binary -O binary --pad-to=$(CONFIG_SPL_PAD_TO) \ --gap-fill=0xff -u-boot-with-spl-pbl.bin: spl/u-boot-spl.pbl u-boot.bin FORCE +u-boot-with-spl-pbl.bin: spl/u-boot-spl.pbl $(UBOOT_BINLOAD) FORCE $(call if_changed,pad_cat) # PPC4xx needs the SPL at the end of the image, since the reset vector -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/7] spl: pbl: Add new SPL image for pblimage tool
For the pblimage tool, the SPL image is splitted into 64 byte chunks, and PBL needs a command for each piece. In current pblimage structure, the size of the SPL image should be a fixed value. Well, for LS102xA and some other ARM platforms, the size of the SPL image is changeable. So a new image spl/u-boot-spl-pbl-pad.bin is built, and the size of it is a fixed value CONFIG_SPL_MAX_SIZE. Use it instead of spl/u-boot-spl.bin for LS102xA. CONFIG_SPL_PBL_PAD is used to enable this function. Signed-off-by: Alison Wang alison.w...@freescale.com --- Makefile | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 1fccd0b..6af424e 100644 --- a/Makefile +++ b/Makefile @@ -730,6 +730,7 @@ ALL-y += u-boot.srec u-boot.bin System.map binary_size_check ALL-$(CONFIG_ONENAND_U_BOOT) += u-boot-onenand.bin ifeq ($(CONFIG_SPL_FSL_PBL),y) ALL-$(CONFIG_RAMBOOT_PBL) += u-boot-with-spl-pbl.bin +ALL-$(CONFIG_SPL_PBL_PAD) += spl/u-boot-spl-pbl-pad.bin else ALL-$(CONFIG_RAMBOOT_PBL) += u-boot.pbl endif @@ -774,6 +775,8 @@ cmd_cat = cat $(filter-out $(PHONY), $^) $@ append = cat $(filter-out $ $(PHONY), $^) $@ +cmd_pad = $(cmd_objcopy) + quiet_cmd_pad_cat = CAT $@ cmd_pad_cat = $(cmd_objcopy) $(append) || rm -f $@ @@ -962,15 +965,27 @@ endif u-boot-img.bin: spl/u-boot-spl.bin u-boot.img FORCE $(call if_changed,cat) +ifdef CONFIG_SPL_PBL_PAD +SPLPBL_BINLOAD := spl/u-boot-spl-pbl-pad.bin +else +SPLPBL_BINLOAD := spl/u-boot-spl.bin +endif + #Add a target to create boot binary having SPL binary in PBI format #concatenated with u-boot binary. It is need by PowerPC SoC having #internal SRAM = 512KB. MKIMAGEFLAGS_u-boot-spl.pbl = -n $(srctree)/$(CONFIG_SYS_FSL_PBL_RCW:%=%) \ -R $(srctree)/$(CONFIG_SYS_FSL_PBL_PBI:%=%) -T pblimage -spl/u-boot-spl.pbl: spl/u-boot-spl.bin FORCE +spl/u-boot-spl.pbl: $(SPLPBL_BINLOAD) FORCE $(call if_changed,mkimage) +OBJCOPYFLAGS_u-boot-spl-pbl-pad.bin = -I binary -O binary --pad-to=$(CONFIG_SPL_MAX_SIZE) \ + --gap-fill=0xff + +spl/u-boot-spl-pbl-pad.bin: spl/u-boot-spl.bin FORCE + $(call if_changed,pad) + OBJCOPYFLAGS_u-boot-with-spl-pbl.bin = -I binary -O binary --pad-to=$(CONFIG_SPL_PAD_TO) \ --gap-fill=0xff -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7] ls102xa: pblimage: Add pblimage tool support for LS102xA
For LS102xA, the initialized next_pbl_cmd should be the sum of
0x8100, the lower 24 bits of CONFIG_SPL_TEXT_BASE and
CONFIG_SPL_MAX_SIZE(0x1a000). The sum is different from PowerPC.
The PBI CRC command is different from PowerPC too.
In pblimage tool, add the support for the above two issues.
Signed-off-by: Alison Wang alison.w...@freescale.com
---
tools/pblimage.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/tools/pblimage.c b/tools/pblimage.c
index 6e6e801..152678b 100644
--- a/tools/pblimage.c
+++ b/tools/pblimage.c
@@ -12,6 +12,10 @@
* Initialize to an invalid value.
*/
static uint32_t next_pbl_cmd = 0x8200;
+static uint32_t pbl_cmd_initaddr = 0x8200;
+static uint32_t pbi_crc_cmd1 = 0x13;
+static uint32_t pbi_crc_cmd2 = 0x80;
+
/*
* need to store all bytes in memory for calculating crc32, then write the
* bytes to image file for PBL boot.
@@ -49,7 +53,7 @@ static void init_next_pbl_cmd(FILE *fp_uboot)
exit(EXIT_FAILURE);
}
- next_pbl_cmd = 0x8200 - st.st_size;
+ next_pbl_cmd = pbl_cmd_initaddr - st.st_size;
}
static void generate_pbl_cmd(void)
@@ -81,7 +85,7 @@ static void pbl_fget(size_t size, FILE *stream)
static void load_uboot(FILE *fp_uboot)
{
init_next_pbl_cmd(fp_uboot);
- while (next_pbl_cmd 0x8200) {
+ while (next_pbl_cmd pbl_cmd_initaddr) {
generate_pbl_cmd();
pbl_fget(64, fp_uboot);
}
@@ -111,6 +115,14 @@ static void pbl_parser(char *name)
size_t len = 0;
fname = name;
+
+ if (strstr(fname, ls102xa)) {
+ next_pbl_cmd = 0x8101a000;
+ pbl_cmd_initaddr = 0x8101a000;
+ pbi_crc_cmd1 = 0x61;
+ pbi_crc_cmd2 = 0;
+ }
+
fd = fopen(name, r);
if (fd == NULL) {
printf(Error:%s - Can't open\n, fname);
@@ -172,8 +184,8 @@ static void add_end_cmd(void)
/* Add PBI CRC command. */
*pmem_buf++ = 0x08;
- *pmem_buf++ = 0x13;
- *pmem_buf++ = 0x80;
+ *pmem_buf++ = pbi_crc_cmd1;
+ *pmem_buf++ = pbi_crc_cmd2;
*pmem_buf++ = 0x40;
pbl_size += 4;
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/7] Add SD boot support for LS1021AQDS/TWR board
This series contain SD boot support for LS1021AQDS/TWR board. SPL framework is used. PBL initialize the internal RAM and copy SPL to it, then SPL initialize DDR using SPD and copy u-boot from SD card to DDR, finally SPL transfer control to u-boot. Alison Wang (7): spl: pbl: Add new SPL image for pblimage tool ls102xa: pblimage: Add pblimage tool support for LS102xA spl: Use u-boot.img instead of u-boot.bin when CONFIG_SPL_PBL_PAD is enabled ls102xa: qixis: Add CONFIG_QIXIS_I2C_ACCESS macro common: spl: Add interactive DDR debugger support for SPL arm: ls102xa: Add SD boot support for LS1021AQDS board arm: ls102xa: Add SD boot support for LS1021ATWR board Makefile | 21 +++-- arch/arm/cpu/armv7/ls102xa/Makefile | 1 + arch/arm/cpu/armv7/ls102xa/spl.c | 35 +++ arch/arm/cpu/armv7/ls102xa/u-boot-spl.lds | 89 + arch/arm/include/asm/arch-ls102xa/spl.h | 20 board/freescale/common/qixis.h| 7 +++ board/freescale/ls1021aqds/MAINTAINERS| 1 + board/freescale/ls1021aqds/ddr.c | 5 - board/freescale/ls1021aqds/ls1021aqds.c | 31 +++ board/freescale/ls1021aqds/ls102xa_pbi.cfg| 8 board/freescale/ls1021aqds/ls102xa_rcw_sd.cfg | 14 ++ board/freescale/ls1021atwr/MAINTAINERS| 1 + board/freescale/ls1021atwr/ls1021atwr.c | 31 ++- board/freescale/ls1021atwr/ls102xa_pbi.cfg| 13 + board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg | 14 ++ common/Makefile | 19 ++- configs/ls1021aqds_sdcard_defconfig | 4 configs/ls1021atwr_sdcard_defconfig | 4 include/configs/ls1021aqds.h | 67 +++ include/configs/ls1021atwr.h | 52 tools/pblimage.c | 20 21 files changed, 440 insertions(+), 17 deletions(-) create mode 100644 arch/arm/cpu/armv7/ls102xa/spl.c create mode 100644 arch/arm/cpu/armv7/ls102xa/u-boot-spl.lds create mode 100644 arch/arm/include/asm/arch-ls102xa/spl.h create mode 100644 board/freescale/ls1021aqds/ls102xa_pbi.cfg create mode 100644 board/freescale/ls1021aqds/ls102xa_rcw_sd.cfg create mode 100644 board/freescale/ls1021atwr/ls102xa_pbi.cfg create mode 100644 board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg create mode 100644 configs/ls1021aqds_sdcard_defconfig create mode 100644 configs/ls1021atwr_sdcard_defconfig ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/7] ls102xa: qixis: Add CONFIG_QIXIS_I2C_ACCESS macro
Through adding CONFIG_QIXIS_I2C_ACCESS macro, QIXIS_READ(reg)/QIXIS_WRITE(reg, value) can be used for both i2c and ifc access to QIXIS FPGA. This is more convenient for coding. Signed-off-by: Jason Jin jason@freescale.com Signed-off-by: Alison Wang alison.w...@freescale.com --- board/freescale/common/qixis.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/board/freescale/common/qixis.h b/board/freescale/common/qixis.h index d8fed14..52d2021 100644 --- a/board/freescale/common/qixis.h +++ b/board/freescale/common/qixis.h @@ -100,8 +100,15 @@ u8 qixis_read_i2c(unsigned int reg); void qixis_write_i2c(unsigned int reg, u8 value); #endif +#if defined(CONFIG_QIXIS_I2C_ACCESS) defined(CONFIG_SYS_I2C_FPGA_ADDR) +#define QIXIS_READ(reg) qixis_read_i2c(offsetof(struct qixis, reg)) +#define QIXIS_WRITE(reg, value) \ + qixis_write_i2c(offsetof(struct qixis, reg), value) +#else #define QIXIS_READ(reg) qixis_read(offsetof(struct qixis, reg)) #define QIXIS_WRITE(reg, value) qixis_write(offsetof(struct qixis, reg), value) +#endif + #ifdef CONFIG_SYS_I2C_FPGA_ADDR #define QIXIS_READ_I2C(reg) qixis_read_i2c(offsetof(struct qixis, reg)) #define QIXIS_WRITE_I2C(reg, value) \ -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/7] common: spl: Add interactive DDR debugger support for SPL
For LS102xA, interactive DDR debugger is still needed in SPL part. So build the needed files in SPL image too. Signed-off-by: Alison Wang alison.w...@freescale.com --- common/Makefile | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/common/Makefile b/common/Makefile index aca0f7f..5f7bf49 100644 --- a/common/Makefile +++ b/common/Makefile @@ -15,15 +15,6 @@ ifdef CONFIG_SYS_HUSH_PARSER obj-y += cli_hush.o endif -# We always have this since drivers/ddr/fs/interactive.c needs it -obj-y += cli_simple.o - -obj-y += cli.o -obj-y += cli_readline.o -obj-y += s_record.o -obj-y += xyzModem.o -obj-y += cmd_disk.o - # This option is not just y/n - it can have a numeric value ifdef CONFIG_BOOTDELAY obj-y += autoboot.o @@ -264,4 +255,14 @@ obj-$(CONFIG_IO_TRACE) += iotrace.o obj-y += memsize.o obj-y += stdio.o +# We always have this since drivers/ddr/fs/interactive.c needs it +obj-y += cli_simple.o + +obj-y += cli.o +obj-y += cli_readline.o +obj-y += command.o +obj-y += s_record.o +obj-y += xyzModem.o +obj-y += cmd_disk.o + CFLAGS_env_embedded.o := -Wa,--no-warn -DENV_CRC=$(shell tools/envcrc 2/dev/null) -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7] arm: ls102xa: Add SD boot support for LS1021AQDS board
This patch adds SD boot support for LS1021AQDS board. SPL
framework is used. PBL initialize the internal RAM and copy
SPL to it, then SPL initialize DDR using SPD and copy u-boot
from SD card to DDR, finally SPL transfer control to u-boot.
Signed-off-by: Alison Wang alison.w...@freescale.com
Signed-off-by: Jason Jin jason@freescale.com
---
arch/arm/cpu/armv7/ls102xa/Makefile | 1 +
arch/arm/cpu/armv7/ls102xa/spl.c | 35 +++
arch/arm/cpu/armv7/ls102xa/u-boot-spl.lds | 89 +++
arch/arm/include/asm/arch-ls102xa/spl.h | 20 ++
board/freescale/ls1021aqds/MAINTAINERS| 1 +
board/freescale/ls1021aqds/ddr.c | 5 +-
board/freescale/ls1021aqds/ls1021aqds.c | 31 ++
board/freescale/ls1021aqds/ls102xa_pbi.cfg| 8 +++
board/freescale/ls1021aqds/ls102xa_rcw_sd.cfg | 14 +
configs/ls1021aqds_sdcard_defconfig | 4 ++
include/configs/ls1021aqds.h | 67
11 files changed, 274 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/cpu/armv7/ls102xa/spl.c
create mode 100644 arch/arm/cpu/armv7/ls102xa/u-boot-spl.lds
create mode 100644 arch/arm/include/asm/arch-ls102xa/spl.h
create mode 100644 board/freescale/ls1021aqds/ls102xa_pbi.cfg
create mode 100644 board/freescale/ls1021aqds/ls102xa_rcw_sd.cfg
create mode 100644 configs/ls1021aqds_sdcard_defconfig
diff --git a/arch/arm/cpu/armv7/ls102xa/Makefile
b/arch/arm/cpu/armv7/ls102xa/Makefile
index d82ce8d..56ef3a7 100644
--- a/arch/arm/cpu/armv7/ls102xa/Makefile
+++ b/arch/arm/cpu/armv7/ls102xa/Makefile
@@ -10,3 +10,4 @@ obj-y += timer.o
obj-$(CONFIG_OF_LIBFDT) += fdt.o
obj-$(CONFIG_SYS_HAS_SERDES) += fsl_ls1_serdes.o ls102xa_serdes.o
+obj-$(CONFIG_SPL) += spl.o
diff --git a/arch/arm/cpu/armv7/ls102xa/spl.c b/arch/arm/cpu/armv7/ls102xa/spl.c
new file mode 100644
index 000..77ea1ee
--- /dev/null
+++ b/arch/arm/cpu/armv7/ls102xa/spl.c
@@ -0,0 +1,35 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include spl.h
+
+u32 spl_boot_device(void)
+{
+#ifdef CONFIG_SPL_MMC_SUPPORT
+ return BOOT_DEVICE_MMC1;
+#endif
+ return BOOT_DEVICE_NAND;
+}
+
+u32 spl_boot_mode(void)
+{
+ switch (spl_boot_device()) {
+ case BOOT_DEVICE_MMC1:
+#ifdef CONFIG_SPL_FAT_SUPPORT
+ return MMCSD_MODE_FAT;
+#else
+ return MMCSD_MODE_RAW;
+#endif
+ break;
+ case BOOT_DEVICE_NAND:
+ return 0;
+ break;
+ default:
+ puts(spl: error: unsupported device\n);
+ hang();
+ }
+}
diff --git a/arch/arm/cpu/armv7/ls102xa/u-boot-spl.lds
b/arch/arm/cpu/armv7/ls102xa/u-boot-spl.lds
new file mode 100644
index 000..10671e7
--- /dev/null
+++ b/arch/arm/cpu/armv7/ls102xa/u-boot-spl.lds
@@ -0,0 +1,89 @@
+/*
+ * Copyright (c) 2004-2008 Texas Instruments
+ *
+ * (C) Copyright 2002
+ * Gary Jennejohn, DENX Software Engineering, ga...@denx.de
+ *
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+OUTPUT_FORMAT(elf32-littlearm, elf32-littlearm, elf32-littlearm)
+OUTPUT_ARCH(arm)
+ENTRY(_start)
+SECTIONS
+{
+ . = 0x;
+
+ . = ALIGN(4);
+ .text :
+ {
+ __image_copy_start = .;
+ *(.vectors)
+ CPUDIR/start.o (.text*)
+ *(.text*)
+ }
+
+ . = ALIGN(4);
+ .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
+
+ . = ALIGN(4);
+ .data : {
+ *(.data*)
+ }
+
+ . = ALIGN(4);
+ .u_boot_list : {
+ KEEP(*(SORT(.u_boot_list*_i2c_*)));
+ }
+
+ . = .;
+
+ __image_copy_end = .;
+
+ .rel.dyn : {
+ __rel_dyn_start = .;
+ *(.rel*)
+ __rel_dyn_end = .;
+ }
+
+ .end :
+ {
+ *(.__end)
+ }
+
+ _image_binary_end = .;
+
+ .bss __rel_dyn_start (OVERLAY) : {
+ __bss_start = .;
+ *(.bss*)
+. = ALIGN(4);
+ __bss_end = .;
+ }
+
+ .dynsym _image_binary_end : { *(.dynsym) }
+ .dynbss : { *(.dynbss) }
+ .dynstr : { *(.dynstr*) }
+ .dynamic : { *(.dynamic*) }
+ .hash : { *(.hash*) }
+ .plt : { *(.plt*) }
+ .interp : { *(.interp*) }
+ .gnu : { *(.gnu*) }
+ .ARM.exidx : { *(.ARM.exidx*) }
+}
+
+#if defined(CONFIG_SPL_MAX_SIZE)
+ASSERT(__image_copy_end - __image_copy_start (CONFIG_SPL_MAX_SIZE), \
+ SPL image too big);
+#endif
+
+#if defined(CONFIG_SPL_BSS_MAX_SIZE)
+ASSERT(__bss_end - __bss_start (CONFIG_SPL_BSS_MAX_SIZE), \
+ SPL image BSS too big);
+#endif
+
+#if defined(CONFIG_SPL_MAX_FOOTPRINT)
+ASSERT(__bss_end - _start (CONFIG_SPL_MAX_FOOTPRINT), \
+ SPL image plus BSS too big);
+#endif
diff --git
[U-Boot] [PATCH 7/7] arm: ls102xa: Add SD boot support for LS1021ATWR board
This patch adds SD boot support for LS1021ATWR board. SPL
framework is used. PBL initialize the internal RAM and copy
SPL to it, then SPL initialize DDR using SPD and copy u-boot
from SD card to DDR, finally SPL transfer control to u-boot.
Signed-off-by: Chen Lu chen...@freescale.com
Signed-off-by: Alison Wang alison.w...@freescale.com
Signed-off-by: Jason Jin jason@freescale.com
---
board/freescale/ls1021atwr/MAINTAINERS| 1 +
board/freescale/ls1021atwr/ls1021atwr.c | 31 +++-
board/freescale/ls1021atwr/ls102xa_pbi.cfg| 13 +++
board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg | 14
configs/ls1021atwr_sdcard_defconfig | 4 +++
include/configs/ls1021atwr.h | 52 +++
6 files changed, 114 insertions(+), 1 deletion(-)
create mode 100644 board/freescale/ls1021atwr/ls102xa_pbi.cfg
create mode 100644 board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg
create mode 100644 configs/ls1021atwr_sdcard_defconfig
diff --git a/board/freescale/ls1021atwr/MAINTAINERS
b/board/freescale/ls1021atwr/MAINTAINERS
index 4e5bc15..651d43e 100644
--- a/board/freescale/ls1021atwr/MAINTAINERS
+++ b/board/freescale/ls1021atwr/MAINTAINERS
@@ -4,3 +4,4 @@ S: Maintained
F: board/freescale/ls1021atwr/
F: include/configs/ls1021atwr.h
F: configs/ls1021atwr_nor_defconfig
+F: configs/ls1021atwr_sdcard_defconfig
diff --git a/board/freescale/ls1021atwr/ls1021atwr.c
b/board/freescale/ls1021atwr/ls1021atwr.c
index b522ff2..7c0654a 100644
--- a/board/freescale/ls1021atwr/ls1021atwr.c
+++ b/board/freescale/ls1021atwr/ls1021atwr.c
@@ -16,6 +16,7 @@
#include netdev.h
#include fsl_mdio.h
#include tsec.h
+#include spl.h
DECLARE_GLOBAL_DATA_PTR;
@@ -65,6 +66,7 @@ struct cpld_data {
u8 rev2;/* Reserved */
};
+#if !defined(CONFIG_SD_BOOT) !defined(CONFIG_QSPI_BOOT)
static void convert_serdes_mux(int type, int need_reset);
void cpld_show(void)
@@ -100,11 +102,14 @@ void cpld_show(void)
in_8(cpld_data-serdes_mux));
#endif
}
+#endif
int checkboard(void)
{
puts(Board: LS1021ATWR\n);
+#if !defined(CONFIG_SD_BOOT) !defined(CONFIG_QSPI_BOOT)
cpld_show();
+#endif
return 0;
}
@@ -213,6 +218,7 @@ int board_eth_init(bd_t *bis)
}
#endif
+#if !defined(CONFIG_SD_BOOT) !defined(CONFIG_QSPI_BOOT)
int config_serdes_mux(void)
{
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
@@ -244,6 +250,7 @@ int config_serdes_mux(void)
return 0;
}
+#endif
int board_early_init_f(void)
{
@@ -270,13 +277,33 @@ int board_early_init_f(void)
return 0;
}
+#ifdef CONFIG_SPL_BUILD
+void board_init_f(ulong dummy)
+{
+ /* Set global data pointer */
+ gd = gdata;
+
+ /* Clear the BSS */
+ memset(__bss_start, 0, __bss_end - __bss_start);
+
+ get_clocks();
+
+ preloader_console_init();
+
+ dram_init();
+
+ board_init_r(NULL, 0);
+}
+#endif
+
int board_init(void)
{
#ifndef CONFIG_SYS_FSL_NO_SERDES
fsl_serdes_init();
+#if !defined(CONFIG_SD_BOOT) !defined(CONFIG_QSPI_BOOT)
config_serdes_mux();
#endif
-
+#endif
return 0;
}
@@ -304,6 +331,7 @@ u16 flash_read16(void *addr)
return (((val) 8) 0x00ff) | (((val) 8) 0xff00);
}
+#if !defined(CONFIG_SD_BOOT) !defined(CONFIG_QSPI_BOOT)
static void convert_flash_bank(char bank)
{
struct cpld_data *cpld_data = (void *)(CONFIG_SYS_CPLD_BASE);
@@ -486,3 +514,4 @@ U_BOOT_CMD(
-change lane C lane D to PCIeX2\n
\nWARNING: If you aren't familiar with the setting of serdes, don't
try to change anything!\n
);
+#endif
diff --git a/board/freescale/ls1021atwr/ls102xa_pbi.cfg
b/board/freescale/ls1021atwr/ls102xa_pbi.cfg
new file mode 100644
index 000..76373ce
--- /dev/null
+++ b/board/freescale/ls1021atwr/ls102xa_pbi.cfg
@@ -0,0 +1,13 @@
+#PBI commands
+
+09570200
+09570158 0300
+09570200
+8940007c 21f47300
+
+#Configure Scratch register
+09ee0200 1000
+#Configure alternate space
+09570158 0008
+#Flush PBL data
+096100c0 000F
diff --git a/board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg
b/board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg
new file mode 100644
index 000..6c83e3b
--- /dev/null
+++ b/board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg
@@ -0,0 +1,14 @@
+#PBL preamble and RCW header
+aa55aa55 01ee0100
+
+#enable IFC, disable QSPI and DSPI
+#0608000a
+#2000 00404000 60025a00 21042000
+#0020 01038000
+# 001b1200
+
+#disable IFC, enable QSPI and DSPI
+0608000a
+2000 00407900 60025a00 21046000
+ 01038000
+20024800 881b1540
diff --git a/configs/ls1021atwr_sdcard_defconfig
b/configs/ls1021atwr_sdcard_defconfig
new file mode 100644
index 000..0eb556a
--- /dev/null
+++
[U-Boot] [PATCH] kbuild: refactor some makefiles
[1] Move driver/core/, driver/input/ and drivers/input/ entries from the top Makefile to drivers/Makefile [2] Remove the conditional by CONFIG_DM in drivers/core/Makefile because the whole drivers/core directory is already selected by CONFIG_DM in the upper level [3] Likewise for CONFIG_DM_DEMO in drivers/demo/Makefile [4] Simplify common/Makefile - both CONFIG_DDR_SPD and CONFIG_SPD_EEPROM are boolean macros so they can directly select objects Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- Makefile | 3 --- common/Makefile | 9 ++--- drivers/Makefile | 3 +++ drivers/core/Makefile | 2 +- drivers/demo/Makefile | 2 +- 5 files changed, 7 insertions(+), 12 deletions(-) diff --git a/Makefile b/Makefile index 1fccd0b..6221113 100644 --- a/Makefile +++ b/Makefile @@ -613,11 +613,9 @@ libs-y += fs/ libs-y += net/ libs-y += disk/ libs-y += drivers/ -libs-$(CONFIG_DM) += drivers/core/ libs-y += drivers/dma/ libs-y += drivers/gpio/ libs-y += drivers/i2c/ -libs-y += drivers/input/ libs-y += drivers/mmc/ libs-y += drivers/mtd/ libs-$(CONFIG_CMD_NAND) += drivers/mtd/nand/ @@ -649,7 +647,6 @@ libs-$(CONFIG_API) += api/ libs-$(CONFIG_HAS_POST) += post/ libs-y += test/ libs-y += test/dm/ -libs-$(CONFIG_DM_DEMO) += drivers/demo/ ifneq (,$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 mx35 mxs vf610)) libs-y += arch/$(ARCH)/imx-common/ diff --git a/common/Makefile b/common/Makefile index aca0f7f..e9ca55d 100644 --- a/common/Makefile +++ b/common/Makefile @@ -243,13 +243,8 @@ obj-y += cmd_nvedit.o #environment obj-y += env_common.o #others -ifdef CONFIG_DDR_SPD -SPD := y -endif -ifdef CONFIG_SPD_EEPROM -SPD := y -endif -obj-$(SPD) += ddr_spd.o +obj-$(CONFIG_DDR_SPD) += ddr_spd.o +obj-$(CONFIG_SPD_EEPROM) += ddr_spd.o obj-$(CONFIG_HWCONFIG) += hwconfig.o obj-$(CONFIG_BOUNCE_BUFFER) += bouncebuf.o obj-y += console.o diff --git a/drivers/Makefile b/drivers/Makefile index b22b109..d8361d9 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -1,3 +1,5 @@ +obj-$(CONFIG_DM) += core/ +obj-$(CONFIG_DM_DEMO) += demo/ obj-$(CONFIG_BIOSEMU) += bios_emulator/ obj-y += block/ obj-$(CONFIG_BOOTCOUNT_LIMIT) += bootcount/ @@ -16,3 +18,4 @@ obj-y += watchdog/ obj-$(CONFIG_QE) += qe/ obj-y += memory/ obj-y += pwm/ +obj-y += input/ diff --git a/drivers/core/Makefile b/drivers/core/Makefile index 90b2a7f..c7905b1 100644 --- a/drivers/core/Makefile +++ b/drivers/core/Makefile @@ -4,4 +4,4 @@ # SPDX-License-Identifier: GPL-2.0+ # -obj-$(CONFIG_DM) := device.o lists.o root.o uclass.o util.o +obj-y := device.o lists.o root.o uclass.o util.o diff --git a/drivers/demo/Makefile b/drivers/demo/Makefile index baaa2ba..171ddf3 100644 --- a/drivers/demo/Makefile +++ b/drivers/demo/Makefile @@ -4,6 +4,6 @@ # SPDX-License-Identifier: GPL-2.0+ # -obj-$(CONFIG_DM_DEMO) += demo-uclass.o demo-pdata.o +obj-y += demo-uclass.o demo-pdata.o obj-$(CONFIG_DM_DEMO_SIMPLE) += demo-simple.o obj-$(CONFIG_DM_DEMO_SHAPE) += demo-shape.o -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/11] dm: imx: Use gpio_request() to request GPIOs
On 09/17/14 17:34, Simon Glass wrote:
Hi Igor,
On 17 September 2014 08:31, Igor Grinberg grinb...@compulab.co.il
mailto:grinb...@compulab.co.il wrote:
On 09/17/14 17:00, Simon Glass wrote:
Hi Igor,
On 17 September 2014 06:13, Igor Grinberg grinb...@compulab.co.il
mailto:grinb...@compulab.co.il mailto:grinb...@compulab.co.il
mailto:grinb...@compulab.co.il wrote:
Hi Simon,
On 09/17/14 06:51, Simon Glass wrote:
GPIOs should be requested before use. Without this, driver model
will not
permit the GPIO to be used.
Signed-off-by: Simon Glass s...@chromium.org
mailto:s...@chromium.org mailto:s...@chromium.org
mailto:s...@chromium.org
---
Changes in v2:
- Check return values of gpio_request()
arch/arm/imx-common/i2c-mxv7.c | 24
board/compulab/cm_fx6/cm_fx6.c | 15 +++
board/compulab/cm_fx6/common.c | 7 +++
3 files changed, 46 insertions(+)
[...]
diff --git a/board/compulab/cm_fx6/common.c
b/board/compulab/cm_fx6/common.c
index 1f39679..e4d7e2e 100644
--- a/board/compulab/cm_fx6/common.c
+++ b/board/compulab/cm_fx6/common.c
@@ -79,6 +79,13 @@ void cm_fx6_set_ecspi_iomux(void)
int board_spi_cs_gpio(unsigned bus, unsigned cs)
{
+#ifndef CONFIG_SPL_BUILD
+ int ret;
+
+ ret = gpio_request(CM_FX6_ECSPI_BUS0_CS0, ecspi_bus0_cs0);
+ if (ret)
+ return ret;
+#endif
Is there a reason for excluding this request from spl builds?
We do build with CONFIG_SPL_GPIO_SUPPORT and we don't have a
problem with spl size.
So, if there is no strong reason to exclude it from spl build,
I'd like to remove the #ifndef.
It isn't supported by DM yet.
AFAICS, gpio_request() is available for SPL.
So in such case the non-DM version will be used and
I can't see any problem with this (unless it does not work for some
reason).
I suggest that if you wanted the gpio_request() in the non-DM case you would
already have added it?
I would thought so too... Unfortunately, it has slipped through...
I would prefer not to have an #ifdef CONFIG_DM_GPIO here also. Can we revisit
when DM supports SPL?
Yes, no problem.
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: gadget: fastboot: improve download progress bar
On Thursday, September 18, 2014 at 03:34:18 AM, Bo Shen wrote:
Hi Marek,
On 09/17/2014 07:16 PM, Marek Vasut wrote:
On Wednesday, September 17, 2014 at 12:28:57 PM, Bo Shen wrote:
Hi Marek,
On 09/17/2014 06:10 PM, Marek Vasut wrote:
On Wednesday, September 17, 2014 at 09:43:56 AM, Bo Shen wrote:
+CC Lukasz, this is his turf.
When download is ongoing, if the actual size of one transfer
is not the same as BTYES_PER_DOT, which will cause the dot
won't print anymore. Then it will let the user thinking it
is stuck, actually it is transfering without dot printed.
So, improve the method to show the progress bar (print dot).
Signed-off-by: Bo Shen voice.s...@atmel.com
---
drivers/usb/gadget/f_fastboot.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/f_fastboot.c
b/drivers/usb/gadget/f_fastboot.c index 7a1acb9..2f13bf0 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -51,6 +51,7 @@ static inline struct f_fastboot
*func_to_fastboot(struct usb_function *f) static struct f_fastboot
*fastboot_func;
static unsigned int download_size;
static unsigned int download_bytes;
+static unsigned int num_of_dot;
static struct usb_endpoint_descriptor fs_ep_in = {
.bLength= USB_DT_ENDPOINT_SIZE,
@@ -414,9 +415,10 @@ static void rx_handler_dl_image(struct usb_ep
*ep, struct usb_request *req) req-length = ep-maxpacket;
}
-if (download_bytes !(download_bytes % BYTES_PER_DOT)) {
+if (download_bytes ((download_bytes / BYTES_PER_DOT)
num_of_dot)) { + num_of_dot = download_bytes / BYTES_PER_DOT;
putc('.');
-if (!(download_bytes % (74 * BYTES_PER_DOT)))
+if (!(num_of_dot % 74))
putc('\n');
}
req-actual = 0;
@@ -431,6 +433,7 @@ static void cb_download(struct usb_ep *ep, struct
usb_request *req) strsep(cmd, :);
download_size = simple_strtoul(cmd, NULL, 16);
download_bytes = 0;
+num_of_dot = 0;
Make it a 'download_total' and log the total amount of bytes
transferred please, that way it can be re-used for other purposes in
the future ; for example for printing how much data were already
transferred ;-)
The download_bytes record the total amount of bytes transferred.
And the download_bytes will print after finishing transfer.
So why can this not be used to indicate the total progress ? Because the
transfeer speed is variating too much ?
As I described in the commit message. If the transfer length is not
exactly the same as the request length, then the old method
download_bytes % BYTES_PER_DOT
won't be 0 anymore, so for the following transfer, it won't print dot
anymore.
And can you not reset the download_bytes for each transfer ?
Maybe we're not even aligned on what transfer means, so we might want to sync
on this word first. What does transfer mean in this case?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Need help with u-boot problem with usb-keyboard / kvm switch
On Wednesday, September 17, 2014 at 09:29:07 PM, Eric Nelson wrote: Hi Hans, On 09/17/2014 12:11 PM, Hans de Goede wrote: Hi Marek, et al, I'm working on cleaning up Luc's hdmi out support patchset for sunxi. As part of this I want to also add support for usb keyboards, so as to get a full console without needing to solder wires to testpoints on some boards :) So when I plug in the usb coming from my kvm I get this: (Re)start USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80 3 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found And the usb keyboard does not work. If I plug in a single usb-2 hub (no ohci support for sunxi in u-boot yet), then things do work, but after a few minutes of inactivity the usb code starts spamming the console with: EHCI timed out on TD - token=0x80008c80 EHCI timed out on TD - token=0x80008c80 ... Could this be a problem with the phy settings (iow a sunxi specific problem)? Probably not. We've seen the same thing on SABRE Lite and Nitrogen6X boards. I agree, this happens. Which controller and driver do you use on the Sunxi hardware? btw you can check if this is a cache issue by disabling dcache (set CONFIG_CMD_CACHE in the config and use 'dcache off' before 'usb start'). You can also patch the arch/arm/lib/cache-cp15.c functions to do additional alignment checks (always a good idea) , just like I did that in arch/arm/cpu/arm926ejs/cache.c Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Need help with u-boot problem with usb-keyboard / kvm switch
On Wednesday, September 17, 2014 at 09:19:11 PM, Luc Verhaegen wrote: On Wed, Sep 17, 2014 at 09:11:38PM +0200, Hans de Goede wrote: Hi Marek, et al, I'm working on cleaning up Luc's hdmi out support patchset for sunxi. ? Your email is missing it's contents, is that at typo ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot panasonic repo
On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote: Hi Michal, Hi, On Thu, 11 Sep 2014 06:56:04 +0200 Michal Simek mon...@monstr.eu wrote: Hi, On 09/11/2014 05:09 AM, Masahiro Yamada wrote: On Thu, 11 Sep 2014 01:33:20 +0200 Marek Vasut ma...@denx.de wrote: Hello, I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place. Me too. I'd like to own u-boot-uniphier to collect Panasonic-SoC-specific changes. That would be faster and would not disturb Albert. I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that. The point is that you collect Zynq-specific patches in your own place by yourself and then send a pull-req to Albert or Tom, right? It does not matter whether it is a separate u-boot-zynq repo or u-boot-microbraze/zynq branch. I have sent the first series to add the core support of Panasonic SoCs and boards (but it is taking much longer than I have expected) and then I am planning to send more features and boards in the next phase. What's the difference between what I want to do for Panasonic SoCs and what you usually do for Zynq SoCs? [...] I fully support that we should have a repo for the panasonic socs, it's pointless to load Albert by making him apply patches by hand and you have proven numerous times that you do know what you're doing. I really see no blocker for doing this. 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 v3 07/11] imx: Add error checking to setup_i2c()
On 09/17/14 18:02, Simon Glass wrote: Since this function can fail, check its return value. Signed-off-by: Simon Glass s...@chromium.org Thanks! Acked-by: Igor Grinberg grinb...@compulab.co.il -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 08/11] dm: imx: Use gpio_request() to request GPIOs
On 09/17/14 18:02, Simon Glass wrote: GPIOs should be requested before use. Without this, driver model will not permit the GPIO to be used. Signed-off-by: Simon Glass s...@chromium.org Acked-by: Igor Grinberg grinb...@compulab.co.il -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/11] dm: imx: gpio: Support driver model in MXC gpio driver
On 09/17/14 18:02, Simon Glass wrote: Add driver model support with this driver. In this case the platform data is in the driver. It would be better to put this into an SOC-specific file, but this is best attempted when more boards are moved over to use driver model. Signed-off-by: Simon Glass s...@chromium.org Acked-by: Igor Grinberg grinb...@compulab.co.il -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot panasonic repo
On 09/18/2014 09:27 AM, Marek Vasut wrote: On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote: Hi Michal, Hi, On Thu, 11 Sep 2014 06:56:04 +0200 Michal Simek mon...@monstr.eu wrote: Hi, On 09/11/2014 05:09 AM, Masahiro Yamada wrote: On Thu, 11 Sep 2014 01:33:20 +0200 Marek Vasut ma...@denx.de wrote: Hello, I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place. Me too. I'd like to own u-boot-uniphier to collect Panasonic-SoC-specific changes. That would be faster and would not disturb Albert. I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that. The point is that you collect Zynq-specific patches in your own place by yourself and then send a pull-req to Albert or Tom, right? It does not matter whether it is a separate u-boot-zynq repo or u-boot-microbraze/zynq branch. I have sent the first series to add the core support of Panasonic SoCs and boards (but it is taking much longer than I have expected) and then I am planning to send more features and boards in the next phase. What's the difference between what I want to do for Panasonic SoCs and what you usually do for Zynq SoCs? [...] I fully support that we should have a repo for the panasonic socs, it's pointless to load Albert by making him apply patches by hand and you have proven numerous times that you do know what you're doing. I really see no blocker for doing this. +1 on this if Masahiro wants to have separate repo. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot panasonic repo
On Thursday, September 18, 2014 at 09:58:47 AM, Michal Simek wrote: On 09/18/2014 09:27 AM, Marek Vasut wrote: On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote: Hi Michal, Hi, On Thu, 11 Sep 2014 06:56:04 +0200 Michal Simek mon...@monstr.eu wrote: Hi, On 09/11/2014 05:09 AM, Masahiro Yamada wrote: On Thu, 11 Sep 2014 01:33:20 +0200 Marek Vasut ma...@denx.de wrote: Hello, I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place. Me too. I'd like to own u-boot-uniphier to collect Panasonic-SoC-specific changes. That would be faster and would not disturb Albert. I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that. The point is that you collect Zynq-specific patches in your own place by yourself and then send a pull-req to Albert or Tom, right? It does not matter whether it is a separate u-boot-zynq repo or u-boot-microbraze/zynq branch. I have sent the first series to add the core support of Panasonic SoCs and boards (but it is taking much longer than I have expected) and then I am planning to send more features and boards in the next phase. What's the difference between what I want to do for Panasonic SoCs and what you usually do for Zynq SoCs? [...] I fully support that we should have a repo for the panasonic socs, it's pointless to load Albert by making him apply patches by hand and you have proven numerous times that you do know what you're doing. I really see no blocker for doing this. +1 on this if Masahiro wants to have separate repo. There is no repo for those SoCs at all, so I'd be all for it. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Cannot boot fitImage on RPi
Hello,
I am trying to use fitImage instead of uImage on different test-systems,
but ran into some issues and don´t know how to proceed further.
I am building fitImage with an Yocto build system using the patches
provided by Marek Vasut to Yocto.
My first target was the Beaglebone Black, which worked fine, it created
a fitImage, which I booted from sd-card using the values provided in the
docs
(U-Boot 2014.07 TI staging):
ext2load mmc 0:2 8200 /boot/fitImage
setenv bootargs root=/dev/mmcblk0p2 rootwait console=ttyO2,115200
bootm 8200
booting...
My second target was a Raspberry Pi, which I tried boot the same way:
(U-Boot 2014.07 denx master)
ext2load mmc 0:2 ${kernel_addr_r} /boot/fitImage
setenv bootargs console=ttyAMA0 kgdboc=ttyAMA0 root=/dev/mmcblk0p2
rootfstype=ext4 rootwait
bootm ${kernel_addr_r}
Output:
Wrong Image Format for bootm command
ERROR: can't get kernel image!
iminfo ${kernel_addr_r}
## Checking Image at 0100 ...
Unknown image format!
The strange thing is, if I copy the fitImage from the Raspberry PI to
the Beagleboard SD card and try to read it from the Beagle:
ext2load mmc 0:2 8200 /boot/fitImage.rpi
iminfo 8200
## Checking Image at 8200 ...
FIT image found
FIT description: U-Boot fitImage for Poky (Yocto Project Reference
Distro)/3.16.2+git6159fc07f1bbda28dc967163a49fadb71225f5b3/raspberrypi
I don´t know what I did wrong, the fitImage itself seems to be working.
Do I use the wrong address to load the Image? The commands for the RPi
work if using uImage. I also changed the U-Boot on the RPi from the Denx
to the TI version, also with no luck.
Any ideas?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: [PATCH] usb: gadget: fastboot: improve download progress bar
Hi Marek,
On 09/18/2014 10:32 AM, Marek Vasut wrote:
On Thursday, September 18, 2014 at 03:34:18 AM, Bo Shen wrote:
Hi Marek,
On 09/17/2014 07:16 PM, Marek Vasut wrote:
On Wednesday, September 17, 2014 at 12:28:57 PM, Bo Shen wrote:
Hi Marek,
On 09/17/2014 06:10 PM, Marek Vasut wrote:
On Wednesday, September 17, 2014 at 09:43:56 AM, Bo Shen wrote:
+CC Lukasz, this is his turf.
When download is ongoing, if the actual size of one transfer is
not the same as BTYES_PER_DOT, which will cause the dot won't
print anymore. Then it will let the user thinking it is stuck,
actually it is transfering without dot printed.
So, improve the method to show the progress bar (print dot).
Signed-off-by: Bo Shen voice.s...@atmel.com
---
drivers/usb/gadget/f_fastboot.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/f_fastboot.c
b/drivers/usb/gadget/f_fastboot.c index 7a1acb9..2f13bf0 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -51,6 +51,7 @@ static inline struct f_fastboot
*func_to_fastboot(struct usb_function *f) static struct
f_fastboot *fastboot_func;
static unsigned int download_size;
static unsigned int download_bytes;
+static unsigned int num_of_dot;
static struct usb_endpoint_descriptor fs_ep_in = {
.bLength= USB_DT_ENDPOINT_SIZE,
@@ -414,9 +415,10 @@ static void rx_handler_dl_image(struct
usb_ep *ep, struct usb_request *req) req-length = ep-maxpacket;
}
- if (download_bytes !(download_bytes % BYTES_PER_DOT)) {
+ if (download_bytes ((download_bytes / BYTES_PER_DOT)
num_of_dot)) { +num_of_dot = download_bytes / BYTES_PER_DOT;
putc('.');
- if (!(download_bytes % (74 * BYTES_PER_DOT)))
+ if (!(num_of_dot % 74))
putc('\n');
}
req-actual = 0;
@@ -431,6 +433,7 @@ static void cb_download(struct usb_ep *ep,
struct usb_request *req) strsep(cmd, :);
download_size = simple_strtoul(cmd, NULL, 16);
download_bytes = 0;
+ num_of_dot = 0;
Make it a 'download_total' and log the total amount of bytes
transferred please, that way it can be re-used for other purposes
in the future ; for example for printing how much data were
already transferred ;-)
The download_bytes record the total amount of bytes transferred.
And the download_bytes will print after finishing transfer.
So why can this not be used to indicate the total progress ? Because
the transfeer speed is variating too much ?
As I described in the commit message. If the transfer length is not
exactly the same as the request length, then the old method
download_bytes % BYTES_PER_DOT
won't be 0 anymore, so for the following transfer, it won't print dot
anymore.
And can you not reset the download_bytes for each transfer ?
No, I don't reset the download_bytes for each transfer. It reset the
download_bytes before transfer start.
The download_bytes is increase in rx_handler_dl_image function.
Maybe we're not even aligned on what transfer means, so we might want to sync on this
word first. What does transfer mean in this case?
Transfer I mean here is a usb request, which trying to transfer
EP_BUFFER_SIZE at one time.
In my test case, sometime it transfer less than EP_BUFFER_SIZE in a usb
request. So, it cause dot won't print the dot, and seems stuck. However,
it will finish transfer after some time.
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot panasonic repo
Hi guys, On 09/18/2014 10:02 AM, Marek Vasut wrote: On Thursday, September 18, 2014 at 09:58:47 AM, Michal Simek wrote: On 09/18/2014 09:27 AM, Marek Vasut wrote: On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote: Hi Michal, Hi, On Thu, 11 Sep 2014 06:56:04 +0200 Michal Simek mon...@monstr.eu wrote: Hi, On 09/11/2014 05:09 AM, Masahiro Yamada wrote: On Thu, 11 Sep 2014 01:33:20 +0200 Marek Vasut ma...@denx.de wrote: Hello, I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place. Me too. I'd like to own u-boot-uniphier to collect Panasonic-SoC-specific changes. That would be faster and would not disturb Albert. I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that. The point is that you collect Zynq-specific patches in your own place by yourself and then send a pull-req to Albert or Tom, right? It does not matter whether it is a separate u-boot-zynq repo or u-boot-microbraze/zynq branch. I have sent the first series to add the core support of Panasonic SoCs and boards (but it is taking much longer than I have expected) and then I am planning to send more features and boards in the next phase. What's the difference between what I want to do for Panasonic SoCs and what you usually do for Zynq SoCs? [...] I fully support that we should have a repo for the panasonic socs, it's pointless to load Albert by making him apply patches by hand and you have proven numerous times that you do know what you're doing. I really see no blocker for doing this. +1 on this if Masahiro wants to have separate repo. There is no repo for those SoCs at all, so I'd be all for it. This is the flow which is IMHO the best. Masahiro will send the RFC patch for MAINTAINERS file to Albert with adding his fragment for Panasonic SoCs. If Albert ACK but not apply it that it means that he agrees with that person to be responsible for this part. Based on that Masahiro asks for repo (if he wants it) and repo will be created. Then he sends update patch to mailing list and after review he will apply this patch to his repo and start to collect SoC specific patches and then send pull request to Albert. Also record on wiki will be updated based on that. This seems to me like a sensible way how to do it which is transparent for everybody. The same for Masahiro regarding Kconfig if Tom agrees with it. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: [PATCH 0/7] ARM: sunxi: Add basic support for Allwinner A31 (sun6i)
Hi, On 09/18/2014 06:27 AM, Siarhei Siamashka wrote: On Tue, 09 Sep 2014 09:00:57 +0200 Hans de Goede hdego...@redhat.com wrote: Hi, On 09/08/2014 03:28 PM, Chen-Yu Tsai wrote: Hi everyone, This series add basic support for Allwinner's A31 SoC. The patches, excluding the first one, were cherry-picked from u-boot-sunxi. Due to the difference between u-boot mainline and u-boot-sunxi, some patches were rearranged or squashed to better fit the current state of u-boot, and not introduce any build breaks. It follows Ian's initial merge method of sun7i support: introducing various components first, then enabling them in the last commit. I tried to keep the commits separate, thus retaining the original author and Signed-off-bys. Patch 1 adds a wrapper around func(USB, usb, 0) in BOOT_TARGET_DEVICES to deal with breakage when USB support is not enabled. Patch 2 adds memory addresses for some hardware blocks new in sun6i. Patch 3 adds support for the new PRCM (power reset and clock management) block, which also contains PLL bias voltage control. Patch 4 adds support for the clock module. This patch is a bunch of different sun6i related patches on the clock code, from when sun6i support was introduced to u-boot-sunxi, up to its current form. This is done to avoid various conflicts and needlessly introducing then removing macros. Patch 5 adds mmc support on sun6i. Patch 6 adds uart0 muxing on sun6i. Patch 7 enables sun6i support and adds defconfig for the Colombus board. Chen, Many thanks for working on this! Just a quick not for people celebrating too early, this is the *incomplete* sun7i support from the linux-sunxi/u-boot-sunxi git repo. It is fine to merge this upstream, but this does not include SPL support. This allows replacing u-boot.bin on allwinnner sd-card images, which is very useful. But it does not get us all the way to booting sun7i devices we still need boot0 and boot1 binaries from allwinner for that (for now). If I understand it correctly, one of the things that needs to be done in SPL is the initialization of the DRAM controller. A few weeks ago Oliver has updated the http://linux-sunxi.org/DRAM_Controller page and added a link to the 'dram_sun6i.c' file from the rhombus-tech.net u-boot repository: http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/sunxi/dram_sun6i.c;hb=refs/heads/allwinner-sunxi-a31 Does this repository look like exactly the missing part of code? Yes it does, interesting. I had found that file before, but this one was missing in the repo I found then: http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-sunxi/dram.h;hb=refs/heads/allwinner-sunxi-a31 But with that one added, this is definitely interesting. Assuming that this code works, it provides a usable starting point for us. Yep, assuming :) If no one beats me to it I'll take a look at this as time permits. It looks like the Allwinner A31 DRAM controller registers are very similar to what is used in RK3288 (I have not checked the details, but if we are very lucky, it might be even a 100% perfect match): https://chromium-review.googlesource.com/#/c/209419/ And thanks to the Rockchip developers (who are contributing this DRAM controller support code to coreboot), now we have a lot of named defines for the individual bitfields in the hardware registers. So we can decode the magic constants used in the Allwinner code. And thanks to Texas Instruments, we also have some useful documentation, which also happens to be a reasonably good match: http://www.ti.com/lit/ug/spruhn7a/spruhn7a.pdf Sounds good / useful. In general, if we are on our own, then we just need to do all the boring work again (similar to what we did with the Allwinner A10/A13/A20 DRAM controller earlier). Starting with the creation of the http://linux-sunxi.org/A31_DRAM_Controller_Register_Guide wiki page and populating it with the information gathered from the Allwinner and Rockchip source code and also from the TI Keystone2 documentation. Naturally, every bit of this information needs to be verified on real Allwinner A31 hardware before we can make any assumptions. Yep. However Allwinner has promised to provide us with some better documentation later this month: https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg06840.html I don't know if they are going to include the documentation for the DRAM controller in the first new documentation delivery. It surely may be complicated, because Allwinner is obviously licensing the DRAM controller IP from a third party and not designing it from scratch (in a nice company with Rockchip and Texas Instruments). But Texas Instruments somehow can provide the DRAM controller documentation in free public access. So I would guess that it should be possible for Allwinner too. We still need proper Power-Down and Self-Refresh mode support for Allwinner
Re: [U-Boot] U-Boot panasonic repo
Dear Tom, In message 201409180927.35918.ma...@denx.de Marek Vasut wrote: I fully support that we should have a repo for the panasonic socs, it's pointless to load Albert by making him apply patches by hand and you have proven numerous times that you do know what you're doing. I really see no blocker for doing this. I did not see any negative comments for this. So is it OK to create the panasonic repo as suggested? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Wisdom is one of the few things that looks bigger the further away it is. - Terry Pratchett, _Witches Abroad_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Need help with u-boot problem with usb-keyboard / kvm switch
Hi, On 09/17/2014 09:19 PM, Luc Verhaegen wrote: On Wed, Sep 17, 2014 at 09:11:38PM +0200, Hans de Goede wrote: Hi Marek, et al, I'm working on cleaning up Luc's hdmi out support patchset for sunxi. ? Cleaning up may not have been the best choice of words, I was talking about the rebase on top of upstream u-boot + the various fixes you already know about. I plan to submit a patch-set to the kernel for the clock resource stuff for simplefb to the proper lists for that discussion soon, and assuming that gets accepted I would like to land the hdmi support in upstream u-boot soon. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arch/arm: Add individual TLB size support.
Hi Albert, On Thu, 11 Sep 2014 17:55:00 +0200, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi li.xi...@freescale.com, On Wed, 10 Sep 2014 03:10:27 +, li.xi...@freescale.com li.xi...@freescale.com wrote: Hi Albert, Subject: Re: [PATCH] arch/arm: Add individual TLB size support. Hi Xiubo, On Mon, 7 Jul 2014 13:19:11 +0800, Xiubo Li li.xi...@freescale.com wrote: This adds CONFIG_TLB_SIZE for individual board, whose TLB size maybe larger than PGTABLE_SIZE. Signed-off-by: Xiubo Li li.xi...@freescale.com --- arch/arm/lib/board.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index dc34190..b7327ce 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -353,7 +353,11 @@ void board_init_f(ulong bootflag) #if !(defined(CONFIG_SYS_ICACHE_OFF) defined(CONFIG_SYS_DCACHE_OFF)) /* reserve TLB table */ +#ifdef CONFIG_TLB_SIZE + gd-arch.tlb_size = CONFIG_TLB_SIZE; +#else gd-arch.tlb_size = PGTABLE_SIZE; +#endif addr -= gd-arch.tlb_size; /* round down to next 64 kB limit */ There is no code in current mainline which defines CONFIG_TLB_SIZE; that makes the patch a dead code addition. Yes, this will be used by our LS1 SoC first, and it is still doing The upstream. Then please sumbit this patch as part of the LS1 SoC support series, where the code it creates will actually be used. Besides, what's the point of this as opposed to, e.g., just defining the right PGTABLE_SIZE, or renaming PGTABLE_SIZE as CONFIG_TLB_SIZE? We'll add the LPAE support in uboot and need more space for tlb. I still don't get it. Is gd-arch.tlb_size the size of a page table or of a translation lookahead buffer? Ping on both points. Meanwhile I've put the patch in 'Changes Requested' state. Thanks very much, BRs Xiubo Amicalement, Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot panasonic repo
Hi Wolfgang, On Thu, 18 Sep 2014 10:32:46 +0200 Wolfgang Denk w...@denx.de wrote: Dear Tom, In message 201409180927.35918.ma...@denx.de Marek Vasut wrote: I fully support that we should have a repo for the panasonic socs, it's pointless to load Albert by making him apply patches by hand and you have proven numerous times that you do know what you're doing. I really see no blocker for doing this. I did not see any negative comments for this. So is it OK to create the panasonic repo as suggested? I really appreciate it! @ Marek and Masahiro: if we reach an agreement to create such repos, please send me your SSH public keys that shall be used for these. Also, what should the names be - u-boot-socfpga ? And u-boot-uniphier ? [But is there not a chance that Pana- sonic might have other SoCs that might be mainlines? So maybe we should use u-boot-panasonic instead?] This is a question I have not answered yet. Wolfgang, UniPhier is kind of a brand name of system LSIs developed by Panasonic. I'd like to name u-boot-uniphier.git for some (not technical but political) reason. 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 00/40] ARM: tegra: Add PCIe support
Hi Simon, On Thu, 11 Sep 2014 13:20:03 -0600, Simon Glass s...@chromium.org wrote: Hi, On 11 September 2014 10:17, Stephen Warren swar...@wwwdotorg.org wrote: On 09/11/2014 10:00 AM, Albert ARIBAUD wrote: Hi Thierry, On Tue, 26 Aug 2014 17:33:48 +0200, Thierry Reding thierry.red...@gmail.com wrote: From: Thierry Reding tred...@nvidia.com Note: this series was split over several custodians (including myself). It might thus get applied piecewise... Shouldn't it rather be assigned a single custodian -with others giving their Ack) and be applied as a whole? And yes, I'm ok with getting all the pieces. Yes, applying it all in one place would probably make sense. IIRC, Simon Glass already applied some of the DT patches early in the series? I CC'd him to check, Yes I applied the fdt patches to u-boot-fdt/next. I can do a pull request to ARM if that helps, or you can just grab them. Well, the idea was applying it all in one place :) and I don't like the idea of pulling the fdt tree into the arm tree, so I'll pick them up, but please give your Acked-by to them, so that PW sees it and puts it in when I apply the patches. BTW, Thierry is on vacation at the moment, so I don't expect he'll respond. Regards, Simon Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Call for participation in the U-Boot Mini Summit 2014
Hi Detlev, On Wed, 2014-09-03 at 18:56 +0200, Przemyslaw Marczak wrote: Hello Detlev, On 08/11/2014 05:48 PM, Przemyslaw Marczak wrote: Hello Detlev, On 01/13/2014 06:12 PM, Detlev Zundel wrote: Hi, as already indicated, we are looking forward to our next U-Boot Mini Summit at Embedded Linux Conference Europe 2014 which will take place in Düsseldorf, Germany from October 13 - 15. The call for papers of the main conference is now open[1] and if you want to submit a talk for the main tracks, you should note the deadline of July 11. For our U-Boot Mini Summit, I'd like to get the schedule completed synchronized to the schedule release of the main event, which is August 12. So please submit talk proposals here with at least me on CC. To coordinate the event better, I have setup another wiki page[2] that can and _should_ be edited by the interested parties. Feel free for example to add yourself to the interested participants so that we get an idea of how many of the U-Boot developers will be there. Best wishes Detlev Sorry for my late input on this regard. But if there's still a possibility to have another talk I'd like to propose mine ARC - new first-class citizen in U-Boot (which was declined for main ELCE2014 event). Abstract is in-lined below. === U-Boot is a de-facto standard bootloader for Linux-driven embedded systems. It provides flexible means for loading kernel and if required image of filesystem from different media be it embedded non-volatile memory, attached storage or even network share. Linux kernel was ported to DesignWare ARC a while ago and starting from version 3.9 the port was accepted upstream. Now to enable real-life device booting on custom hardware decision was made to port U-Boot for ARC. This presentation unveils reasons to start the project, highlights milestones passed during porting process, touches some pitfalls and encourages more engineers and companies to use and contribute to U-Boot project. === I'm not sure if this kind of speech is of any interest for existing U-boot developers, but I may indeed emphasize technical aspects now. Any feedback is more than welcome. Regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot panasonic repo
Dear Masahiro, In message 20140918174315.70f0.aa925...@jp.panasonic.com you wrote: I did not see any negative comments for this. So is it OK to create the panasonic repo as suggested? I really appreciate it! OK. I think Michal Simek posted a nice proposal for the actual work flow to set this up. Could you please do as he suggested? In parallel, please send me you public SSH key (private mail). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Programmer's Lament: (Shakespeare, Macbeth, Act I, Scene vii) That we but teach bloody instructions, which, being taught, return to plague the inventor... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] ARMv8: PSCI: Add linker section to hold PSCI code
Hi Arnab,
On Thu, 28 Aug 2014 01:59:57 +0530, Arnab Basu
arnab.b...@freescale.com wrote:
A separate linker section makes it possible to keep this code either
in DDR or in some secure memory location provided specifically for the
purpose.
So far no one is using this section.
Signed-off-by: Arnab Basu arnab.b...@freescale.com
Reviewed-by: Bhupesh Sharma bhupesh.sha...@freescale.com
Cc: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/config.mk|2 +-
arch/arm/cpu/armv8/u-boot.lds | 30 ++
2 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index c339e6d..9272e9c 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -111,7 +111,7 @@ endif
# limit ourselves to the sections we want in the .bin.
ifdef CONFIG_ARM64
-OBJCOPYFLAGS += -j .text -j .rodata -j .data -j .u_boot_list -j .rela.dyn
+OBJCOPYFLAGS += -j .text -j .secure_text -j .rodata -j .data -j .u_boot_list
-j .rela.dyn
else
OBJCOPYFLAGS += -j .text -j .secure_text -j .rodata -j .hash -j .data -j
.got.plt -j .u_boot_list -j .rel.dyn
endif
diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds
index 4c1..bd95fff 100644
--- a/arch/arm/cpu/armv8/u-boot.lds
+++ b/arch/arm/cpu/armv8/u-boot.lds
@@ -8,6 +8,8 @@
* SPDX-License-Identifier: GPL-2.0+
*/
+#include config.h
+
OUTPUT_FORMAT(elf64-littleaarch64, elf64-littleaarch64,
elf64-littleaarch64)
OUTPUT_ARCH(aarch64)
ENTRY(_start)
@@ -23,6 +25,34 @@ SECTIONS
*(.text*)
}
+#ifdef CONFIG_ARMV8_PSCI
+
+#ifndef CONFIG_ARMV8_SECURE_BASE
+#define CONFIG_ARMV8_SECURE_BASE
+#endif
+
+ .__secure_start : {
+ . = ALIGN(0x1000);
+ *(.__secure_start)
+ }
+
+ .secure_text CONFIG_ARMV8_SECURE_BASE :
+ AT(ADDR(.__secure_start) + SIZEOF(.__secure_start))
+ {
+ *(._secure.text)
+ }
+
+ . = LOADADDR(.__secure_start) +
+ SIZEOF(.__secure_start) +
+ SIZEOF(.secure_text);
+
+ __secure_end_lma = .;
+ .__secure_end : AT(__secure_end_lma) {
+ *(.__secure_end)
+ LONG(0x1d1071c);/* Must output something to reset LMA */
Can you explain in more detail what issue this fixes?
+ }
+#endif
+
. = ALIGN(8);
.rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] compiler_gcc: do not redefine __gnu_attributes
Hello Masahiro, On 18-09-14 04:13, Masahiro Yamada wrote: Jeroen, commit fb8ffd7cfc68b3dc44e182356a207d784cb30b34 compiler*.h: sync include/linux/compiler*.h with Linux 3.16 undid the changes of 7ea50d52849fe8ffa5b5b74c979b60b1045d6fc9 compiler_gcc: do not redefine __gnu_attributes. Add the checks back whether these macro's are already defined (as it causes a lot of noise on e.g. FreeBSD where these defines are already in cdefs.h) As the original patch this checkpatch warning is ignored: WARNING: Adding new packed members is to be done with care Strange. Which source files include cdefs.h? The host std* include this file, not a source file. For building u-boot images, sources should only include headers in the u-boot source tree. The standard system headers should not be used except only a few files such as stdarg.h. This is the same as Linux Kernel. Yes, and stdarg.h includes cdefs.h. So each include of common.h causes several warnings. On the contrary, host programs are allowed to use standard system headers such as stdio.h, stdlib.h etc, where linux/compiler.h should not be included. The root cause of warnings is _not_ that __packed and __weak are always defined in compiler-gcc.h. This only works properly it u-boot for the target does not depend on any host header at all, which as you mentioned is not the case. Hence we shouldn't be surprised if they define something in their namespace and hence checking if that is done is fine. I believe the real problem is there are some source files include both system headers and linux/compiler.h at the same time. No it is a header issue only. The only alternative I can think of is a custom version of stdarg etc and I don't really like that idea. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] ARMv8: PSCI: Enable SMC
Hi Arnab, On Thu, 28 Aug 2014 02:00:01 +0530, Arnab Basu arnab.b...@freescale.com wrote: Enable the SMC instruction so that the kernel can use the psci code Signed-off-by: Arnab Basu arnab.b...@freescale.com Reviewed-by: Bhupesh Sharma bhupesh.sha...@freescale.com Cc: Marc Zyngier marc.zyng...@arm.com --- arch/arm/include/asm/macro.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h index 0009c28..94a1e68 100644 --- a/arch/arm/include/asm/macro.h +++ b/arch/arm/include/asm/macro.h @@ -106,7 +106,11 @@ lr .reqx30 .endm .macro armv8_switch_to_el2_m, xreg1 +#ifdef CONFIG_ARMV8_PSCI + mov \xreg1, #0x531 /* Non-secure EL0/EL1 | HVC | 64bit EL2 */ +#else mov \xreg1, #0x5b1 /* Non-secure EL0/EL1 | HVC | 64bit EL2 */ The 'mov' lines have different constant arguments in the instruction; their explanatory comments should not be the same. +#endif msr scr_el3, \xreg1 msr cptr_el3, xzr /* Disable coprocessor traps to EL3 */ mov \xreg1, #0x33ff Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: ls102xa: Fixed a register definition error
There are 8 SCFG_SPARECR registers in SCFG memory block, not
just one.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index 7995fe2..b5db720 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -182,7 +182,7 @@ struct ccsr_scfg {
u32 etsecmcr;
u32 sdhciovserlcr;
u32 resv14[61];
- u32 sparecr;
+ u32 sparecr[8];
};
/* Clocking */
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: HYP/non-sec: Make a variable as a local one
Defining variable gic_dist_addr as a globe one prevents some
functions, which use this variable, from being used before relocation
which happened in the deep sleep resume process on Freescale SoC
platforms.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
arch/arm/cpu/armv7/virt-v7.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c
index 651ca40..b69fd37 100644
--- a/arch/arm/cpu/armv7/virt-v7.c
+++ b/arch/arm/cpu/armv7/virt-v7.c
@@ -15,8 +15,6 @@
#include asm/io.h
#include asm/secure.h
-unsigned long gic_dist_addr;
-
static unsigned int read_id_pfr1(void)
{
unsigned int reg;
@@ -68,6 +66,12 @@ static void kick_secondary_cpus_gic(unsigned long gicdaddr)
void __weak smp_kick_all_cpus(void)
{
+ unsigned long gic_dist_addr;
+
+ gic_dist_addr = get_gicd_base_address();
+ if (gic_dist_addr == -1)
+ return;
+
kick_secondary_cpus_gic(gic_dist_addr);
}
@@ -75,6 +79,7 @@ int armv7_init_nonsec(void)
{
unsigned int reg;
unsigned itlinesnr, i;
+ unsigned long gic_dist_addr;
/* check whether the CPU supports the security extensions */
reg = read_id_pfr1();
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] spl: pbl: Add new SPL image for pblimage tool
Hi Alison, On Thu, 18 Sep 2014 13:47:13 +0800, Alison Wang b18...@freescale.com wrote: For the pblimage tool, the SPL image is splitted into 64 byte chunks, and PBL needs a command for each piece. In current pblimage structure, the size of the SPL image should be a fixed value. Well, for LS102xA and some other ARM platforms, the size of the SPL image is changeable. So a new image spl/u-boot-spl-pbl-pad.bin is built, and the size of it is a fixed value CONFIG_SPL_MAX_SIZE. Use it instead of spl/u-boot-spl.bin for LS102xA. CONFIG_SPL_PBL_PAD is used to enable this function. Signed-off-by: Alison Wang alison.w...@freescale.com --- There is already a CONFIG_SPL_PAD_TO (see ./README). Can you not use this? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] compiler.h: remove duplicated uninitialized_var
Hello Masahiro, On 18-09-14 04:14, Masahiro Yamada wrote: Since clang has a different definition for uninitialized_var it will complain that it is redefined in include/compiler.h. Since these are already defined in linux/compiler.h just remove this instance. Cc: Masahiro Yamada yamad...@jp.panasonic.com Cc: Tom Rini tr...@ti.com Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl I don't mind this patch but it has made me realize another problem. We have both include/compiler.h and include/linux/compiler.h. Some sources use tha former and others use the latter. I don't know how to use the right one in the right place. no me neither, although it seems arch / drivers tend to use linux/compiler.h more while tools include compiler.h more. Header file policy is one of the biggest problem in U-boot. Everyone has added ugly work-arounds to solve his own problem without correct views or judgement. diff --git a/include/compiler.h b/include/compiler.h index 9afc11b..1451916 100644 --- a/include/compiler.h +++ b/include/compiler.h @@ -129,9 +129,6 @@ typedef unsigned long int uintptr_t; #endif /* USE_HOSTCC */ -/* compiler options */ -#define uninitialized_var(x) x = x - #define likely(x) __builtin_expect(!!(x), 1) #define unlikely(x) __builtin_expect(!!(x), 0) I am not sure if likely(x) and unlikely(x) should also duplicated here. yup I wondered about that too. likely / unlikely are used a lot more though then the isolated use of uninitialized_var. And as they don't cause any problems (the definitions are the same) I let them alone, but I think they should be removed as well some day. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: HYP/non-sec: Make a variable as a local one
Hi Tang,
Please fix subject / commit summary to indicate which variable is to be
made local.
On Thu, 18 Sep 2014 17:12:34 +0800, Tang Yuantian
yuantian.t...@freescale.com wrote:
Defining variable gic_dist_addr as a globe one prevents some
functions, which use this variable, from being used before relocation
which happened in the deep sleep resume process on Freescale SoC
platforms.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
arch/arm/cpu/armv7/virt-v7.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c
index 651ca40..b69fd37 100644
--- a/arch/arm/cpu/armv7/virt-v7.c
+++ b/arch/arm/cpu/armv7/virt-v7.c
@@ -15,8 +15,6 @@
#include asm/io.h
#include asm/secure.h
-unsigned long gic_dist_addr;
-
static unsigned int read_id_pfr1(void)
{
unsigned int reg;
@@ -68,6 +66,12 @@ static void kick_secondary_cpus_gic(unsigned long gicdaddr)
void __weak smp_kick_all_cpus(void)
{
+ unsigned long gic_dist_addr;
+
+ gic_dist_addr = get_gicd_base_address();
+ if (gic_dist_addr == -1)
+ return;
+
kick_secondary_cpus_gic(gic_dist_addr);
}
@@ -75,6 +79,7 @@ int armv7_init_nonsec(void)
{
unsigned int reg;
unsigned itlinesnr, i;
+ unsigned long gic_dist_addr;
/* check whether the CPU supports the security extensions */
reg = read_id_pfr1();
Did you check that the global was not used as a common variable between
the functions?
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] ls102xa: pblimage: Add pblimage tool support for LS102xA
Hi Alison,
On Thu, 18 Sep 2014 13:47:14 +0800, Alison Wang b18...@freescale.com
wrote:
For LS102xA, the initialized next_pbl_cmd should be the sum of
0x8100, the lower 24 bits of CONFIG_SPL_TEXT_BASE and
CONFIG_SPL_MAX_SIZE(0x1a000). The sum is different from PowerPC.
The PBI CRC command is different from PowerPC too.
In pblimage tool, add the support for the above two issues.
Signed-off-by: Alison Wang alison.w...@freescale.com
---
tools/pblimage.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/tools/pblimage.c b/tools/pblimage.c
index 6e6e801..152678b 100644
--- a/tools/pblimage.c
+++ b/tools/pblimage.c
@@ -12,6 +12,10 @@
* Initialize to an invalid value.
*/
static uint32_t next_pbl_cmd = 0x8200;
+static uint32_t pbl_cmd_initaddr = 0x8200;
+static uint32_t pbi_crc_cmd1 = 0x13;
+static uint32_t pbi_crc_cmd2 = 0x80;
+
/*
* need to store all bytes in memory for calculating crc32, then write the
* bytes to image file for PBL boot.
@@ -49,7 +53,7 @@ static void init_next_pbl_cmd(FILE *fp_uboot)
exit(EXIT_FAILURE);
}
- next_pbl_cmd = 0x8200 - st.st_size;
+ next_pbl_cmd = pbl_cmd_initaddr - st.st_size;
}
static void generate_pbl_cmd(void)
@@ -81,7 +85,7 @@ static void pbl_fget(size_t size, FILE *stream)
static void load_uboot(FILE *fp_uboot)
{
init_next_pbl_cmd(fp_uboot);
- while (next_pbl_cmd 0x8200) {
+ while (next_pbl_cmd pbl_cmd_initaddr) {
generate_pbl_cmd();
pbl_fget(64, fp_uboot);
}
@@ -111,6 +115,14 @@ static void pbl_parser(char *name)
size_t len = 0;
fname = name;
+
+ if (strstr(fname, ls102xa)) {
+ next_pbl_cmd = 0x8101a000;
+ pbl_cmd_initaddr = 0x8101a000;
+ pbi_crc_cmd1 = 0x61;
+ pbi_crc_cmd2 = 0;
+ }
Basing the tool's behaviour on the file name is not a good approach
IMO. Can't we add some command line option to the tool to select the
right set of values?
fd = fopen(name, r);
if (fd == NULL) {
printf(Error:%s - Can't open\n, fname);
@@ -172,8 +184,8 @@ static void add_end_cmd(void)
/* Add PBI CRC command. */
*pmem_buf++ = 0x08;
- *pmem_buf++ = 0x13;
- *pmem_buf++ = 0x80;
+ *pmem_buf++ = pbi_crc_cmd1;
+ *pmem_buf++ = pbi_crc_cmd2;
*pmem_buf++ = 0x40;
pbl_size += 4;
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] compiler_gcc: do not redefine __gnu_attributes
Hi Jeroen, On Thu, 18 Sep 2014 11:15:25 +0200 Jeroen Hofstee jer...@myspectrum.nl wrote: Hello Masahiro, On 18-09-14 04:13, Masahiro Yamada wrote: Jeroen, commit fb8ffd7cfc68b3dc44e182356a207d784cb30b34 compiler*.h: sync include/linux/compiler*.h with Linux 3.16 undid the changes of 7ea50d52849fe8ffa5b5b74c979b60b1045d6fc9 compiler_gcc: do not redefine __gnu_attributes. Add the checks back whether these macro's are already defined (as it causes a lot of noise on e.g. FreeBSD where these defines are already in cdefs.h) As the original patch this checkpatch warning is ignored: WARNING: Adding new packed members is to be done with care Strange. Which source files include cdefs.h? The host std* include this file, not a source file. For building u-boot images, sources should only include headers in the u-boot source tree. The standard system headers should not be used except only a few files such as stdarg.h. This is the same as Linux Kernel. Yes, and stdarg.h includes cdefs.h. So each include of common.h causes several warnings. Oh, my dear! This is really unfortunate. On the contrary, host programs are allowed to use standard system headers such as stdio.h, stdlib.h etc, where linux/compiler.h should not be included. The root cause of warnings is _not_ that __packed and __weak are always defined in compiler-gcc.h. This only works properly it u-boot for the target does not depend on any host header at all, which as you mentioned is not the case. Hence we shouldn't be surprised if they define something in their namespace and hence checking if that is done is fine. I believe the real problem is there are some source files include both system headers and linux/compiler.h at the same time. No it is a header issue only. The only alternative I can think of is a custom version of stdarg etc and I don't really like that idea. Me neither. Thanks for explaining this and fully understood. Acked-by: Masahiro Yamada yamad...@jp.panasonic.com (Ideally, I hope a little more comments because I did not know stdarg.h on FreeBSD defines __packed, __weak etc.) Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: [PATCH] usb: gadget: fastboot: improve download progress bar
On Thursday, September 18, 2014 at 10:11:49 AM, Bo Shen wrote:
Hi Marek,
On 09/18/2014 10:32 AM, Marek Vasut wrote:
On Thursday, September 18, 2014 at 03:34:18 AM, Bo Shen wrote:
Hi Marek,
On 09/17/2014 07:16 PM, Marek Vasut wrote:
On Wednesday, September 17, 2014 at 12:28:57 PM, Bo Shen wrote:
Hi Marek,
On 09/17/2014 06:10 PM, Marek Vasut wrote:
On Wednesday, September 17, 2014 at 09:43:56 AM, Bo Shen wrote:
+CC Lukasz, this is his turf.
When download is ongoing, if the actual size of one transfer is
not the same as BTYES_PER_DOT, which will cause the dot won't
print anymore. Then it will let the user thinking it is stuck,
actually it is transfering without dot printed.
So, improve the method to show the progress bar (print dot).
Signed-off-by: Bo Shen voice.s...@atmel.com
---
drivers/usb/gadget/f_fastboot.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/f_fastboot.c
b/drivers/usb/gadget/f_fastboot.c index 7a1acb9..2f13bf0 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -51,6 +51,7 @@ static inline struct f_fastboot
*func_to_fastboot(struct usb_function *f) static struct
f_fastboot *fastboot_func;
static unsigned int download_size;
static unsigned int download_bytes;
+static unsigned int num_of_dot;
static struct usb_endpoint_descriptor fs_ep_in = {
.bLength= USB_DT_ENDPOINT_SIZE,
@@ -414,9 +415,10 @@ static void rx_handler_dl_image(struct
usb_ep *ep, struct usb_request *req) req-length = ep-maxpacket;
}
- if (download_bytes !(download_bytes % BYTES_PER_DOT)) {
+ if (download_bytes ((download_bytes / BYTES_PER_DOT)
num_of_dot)) { + num_of_dot = download_bytes /
BYTES_PER_DOT;
putc('.');
- if (!(download_bytes % (74 * BYTES_PER_DOT)))
+ if (!(num_of_dot % 74))
putc('\n');
}
req-actual = 0;
@@ -431,6 +433,7 @@ static void cb_download(struct usb_ep *ep,
struct usb_request *req) strsep(cmd, :);
download_size = simple_strtoul(cmd, NULL, 16);
download_bytes = 0;
+ num_of_dot = 0;
Make it a 'download_total' and log the total amount of bytes
transferred please, that way it can be re-used for other purposes
in the future ; for example for printing how much data were
already transferred ;-)
The download_bytes record the total amount of bytes transferred.
And the download_bytes will print after finishing transfer.
So why can this not be used to indicate the total progress ? Because
the transfeer speed is variating too much ?
As I described in the commit message. If the transfer length is not
exactly the same as the request length, then the old method
download_bytes % BYTES_PER_DOT
won't be 0 anymore, so for the following transfer, it won't print dot
anymore.
And can you not reset the download_bytes for each transfer ?
No, I don't reset the download_bytes for each transfer. It reset the
download_bytes before transfer start.
The download_bytes is increase in rx_handler_dl_image function.
OK
Maybe we're not even aligned on what transfer means, so we might want
to sync on this word first. What does transfer mean in this case?
Transfer I mean here is a usb request, which trying to transfer
EP_BUFFER_SIZE at one time.
In my test case, sometime it transfer less than EP_BUFFER_SIZE in a usb
request. So, it cause dot won't print the dot, and seems stuck. However,
it will finish transfer after some time.
I see now. This code is really weird.
What would happen if the following condition is met in the code for k0 ?
(download_bytes == download_size) AND (download_bytes = k * BYTES_PER_DOT)
I think the original code would happily print a dot after printing this output:
printf(\ndownloading of %d bytes finished\n, download_bytes);
Do you agree ? If yes, then I believe this code should go into the else branch
only.
Also, you can probably avoid the counting variable if you do something like:
if (download_bytes / CONST != (download_bytes + transfer_size) / CONST) {
print(dot);
if (download_bytes / (74 * CONST) != ((download_bytes + transfer_size)
/
(74 * CONST))
print(\n);
}
Surely, the code can be simplified . You would also need to be careful about
this assignment at the top of the function : download_bytes += transfer_size;
What do you think ?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kbuild: refactor some makefiles
On Thursday, September 18, 2014 at 08:43:41 AM, Masahiro Yamada wrote: [1] Move driver/core/, driver/input/ and drivers/input/ entries from the top Makefile to drivers/Makefile [2] Remove the conditional by CONFIG_DM in drivers/core/Makefile because the whole drivers/core directory is already selected by CONFIG_DM in the upper level [3] Likewise for CONFIG_DM_DEMO in drivers/demo/Makefile [4] Simplify common/Makefile - both CONFIG_DDR_SPD and CONFIG_SPD_EEPROM are boolean macros so they can directly select objects Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- [...] Acked-by: Marek Vasut ma...@denx.de Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot panasonic repo
Hi Michal, On Thu, 18 Sep 2014 10:24:39 +0200 Michal Simek mon...@monstr.eu wrote: Hi guys, On 09/18/2014 10:02 AM, Marek Vasut wrote: On Thursday, September 18, 2014 at 09:58:47 AM, Michal Simek wrote: On 09/18/2014 09:27 AM, Marek Vasut wrote: On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote: Hi Michal, Hi, On Thu, 11 Sep 2014 06:56:04 +0200 Michal Simek mon...@monstr.eu wrote: Hi, On 09/11/2014 05:09 AM, Masahiro Yamada wrote: On Thu, 11 Sep 2014 01:33:20 +0200 Marek Vasut ma...@denx.de wrote: Hello, I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place. Me too. I'd like to own u-boot-uniphier to collect Panasonic-SoC-specific changes. That would be faster and would not disturb Albert. I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that. The point is that you collect Zynq-specific patches in your own place by yourself and then send a pull-req to Albert or Tom, right? It does not matter whether it is a separate u-boot-zynq repo or u-boot-microbraze/zynq branch. I have sent the first series to add the core support of Panasonic SoCs and boards (but it is taking much longer than I have expected) and then I am planning to send more features and boards in the next phase. What's the difference between what I want to do for Panasonic SoCs and what you usually do for Zynq SoCs? [...] I fully support that we should have a repo for the panasonic socs, it's pointless to load Albert by making him apply patches by hand and you have proven numerous times that you do know what you're doing. I really see no blocker for doing this. +1 on this if Masahiro wants to have separate repo. There is no repo for those SoCs at all, so I'd be all for it. This is the flow which is IMHO the best. Thanks for your suggestion! Masahiro will send the RFC patch for MAINTAINERS file to Albert with adding his fragment for Panasonic SoCs. If Albert ACK but not apply it that it means that he agrees with that person to be responsible for this part. Based on that Masahiro asks for repo (if he wants it) and repo will be created. The patch for MAINTAINERS is already on our patchwork. Is this the one you mentioned? http://patchwork.ozlabs.org/patch/386108/ If so, all I have to do now is to just wait until Albert ackes it? 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 6/7] arm: ls102xa: Add SD boot support for LS1021AQDS board
Hi Alison,
On Thu, 18 Sep 2014 13:47:18 +0800, Alison Wang b18...@freescale.com
wrote:
This patch adds SD boot support for LS1021AQDS board. SPL
framework is used. PBL initialize the internal RAM and copy
SPL to it, then SPL initialize DDR using SPD and copy u-boot
from SD card to DDR, finally SPL transfer control to u-boot.
Signed-off-by: Alison Wang alison.w...@freescale.com
Signed-off-by: Jason Jin jason@freescale.com
---
arch/arm/cpu/armv7/ls102xa/Makefile | 1 +
arch/arm/cpu/armv7/ls102xa/spl.c | 35 +++
arch/arm/cpu/armv7/ls102xa/u-boot-spl.lds | 89
+++
arch/arm/include/asm/arch-ls102xa/spl.h | 20 ++
board/freescale/ls1021aqds/MAINTAINERS| 1 +
board/freescale/ls1021aqds/ddr.c | 5 +-
board/freescale/ls1021aqds/ls1021aqds.c | 31 ++
board/freescale/ls1021aqds/ls102xa_pbi.cfg| 8 +++
board/freescale/ls1021aqds/ls102xa_rcw_sd.cfg | 14 +
configs/ls1021aqds_sdcard_defconfig | 4 ++
include/configs/ls1021aqds.h | 67
11 files changed, 274 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/cpu/armv7/ls102xa/spl.c
create mode 100644 arch/arm/cpu/armv7/ls102xa/u-boot-spl.lds
create mode 100644 arch/arm/include/asm/arch-ls102xa/spl.h
create mode 100644 board/freescale/ls1021aqds/ls102xa_pbi.cfg
create mode 100644 board/freescale/ls1021aqds/ls102xa_rcw_sd.cfg
create mode 100644 configs/ls1021aqds_sdcard_defconfig
diff --git a/arch/arm/cpu/armv7/ls102xa/Makefile
b/arch/arm/cpu/armv7/ls102xa/Makefile
index d82ce8d..56ef3a7 100644
--- a/arch/arm/cpu/armv7/ls102xa/Makefile
+++ b/arch/arm/cpu/armv7/ls102xa/Makefile
@@ -10,3 +10,4 @@ obj-y += timer.o
obj-$(CONFIG_OF_LIBFDT) += fdt.o
obj-$(CONFIG_SYS_HAS_SERDES) += fsl_ls1_serdes.o ls102xa_serdes.o
+obj-$(CONFIG_SPL) += spl.o
diff --git a/arch/arm/cpu/armv7/ls102xa/spl.c
b/arch/arm/cpu/armv7/ls102xa/spl.c
new file mode 100644
index 000..77ea1ee
--- /dev/null
+++ b/arch/arm/cpu/armv7/ls102xa/spl.c
@@ -0,0 +1,35 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include spl.h
+
+u32 spl_boot_device(void)
+{
+#ifdef CONFIG_SPL_MMC_SUPPORT
+ return BOOT_DEVICE_MMC1;
+#endif
+ return BOOT_DEVICE_NAND;
+}
+
+u32 spl_boot_mode(void)
+{
+ switch (spl_boot_device()) {
+ case BOOT_DEVICE_MMC1:
+#ifdef CONFIG_SPL_FAT_SUPPORT
+ return MMCSD_MODE_FAT;
+#else
+ return MMCSD_MODE_RAW;
+#endif
+ break;
+ case BOOT_DEVICE_NAND:
+ return 0;
+ break;
+ default:
+ puts(spl: error: unsupported device\n);
+ hang();
+ }
+}
diff --git a/arch/arm/cpu/armv7/ls102xa/u-boot-spl.lds
b/arch/arm/cpu/armv7/ls102xa/u-boot-spl.lds
new file mode 100644
index 000..10671e7
--- /dev/null
+++ b/arch/arm/cpu/armv7/ls102xa/u-boot-spl.lds
@@ -0,0 +1,89 @@
+/*
+ * Copyright (c) 2004-2008 Texas Instruments
+ *
+ * (C) Copyright 2002
+ * Gary Jennejohn, DENX Software Engineering, ga...@denx.de
+ *
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+OUTPUT_FORMAT(elf32-littlearm, elf32-littlearm, elf32-littlearm)
+OUTPUT_ARCH(arm)
+ENTRY(_start)
+SECTIONS
+{
+ . = 0x;
+
+ . = ALIGN(4);
+ .text :
+ {
+ __image_copy_start = .;
+ *(.vectors)
+ CPUDIR/start.o (.text*)
+ *(.text*)
+ }
+
+ . = ALIGN(4);
+ .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
+
+ . = ALIGN(4);
+ .data : {
+ *(.data*)
+ }
+
+ . = ALIGN(4);
+ .u_boot_list : {
+ KEEP(*(SORT(.u_boot_list*_i2c_*)));
+ }
IS this required? And if it is, could it not be added to the
arch/arm/cpu/u-boot-spl.lds file? This way you would not need an .lds
file at all.
+ . = .;
+
+ __image_copy_end = .;
+
+ .rel.dyn : {
+ __rel_dyn_start = .;
+ *(.rel*)
+ __rel_dyn_end = .;
+ }
+
+ .end :
+ {
+ *(.__end)
+ }
+
+ _image_binary_end = .;
+
+ .bss __rel_dyn_start (OVERLAY) : {
+ __bss_start = .;
+ *(.bss*)
+ . = ALIGN(4);
+ __bss_end = .;
+ }
+
+ .dynsym _image_binary_end : { *(.dynsym) }
+ .dynbss : { *(.dynbss) }
+ .dynstr : { *(.dynstr*) }
+ .dynamic : { *(.dynamic*) }
+ .hash : { *(.hash*) }
+ .plt : { *(.plt*) }
+ .interp : { *(.interp*) }
+ .gnu : { *(.gnu*) }
+ .ARM.exidx : { *(.ARM.exidx*) }
+}
+
+#if defined(CONFIG_SPL_MAX_SIZE)
+ASSERT(__image_copy_end - __image_copy_start (CONFIG_SPL_MAX_SIZE), \
+ SPL image too big);
+#endif
+
+#if
Re: [U-Boot] [PATCH] arm: ls102xa: Fixed a register definition error
Hi Tang,
On Thu, 18 Sep 2014 17:12:06 +0800, Tang Yuantian
yuantian.t...@freescale.com wrote:
There are 8 SCFG_SPARECR registers in SCFG memory block, not
just one.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index 7995fe2..b5db720 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -182,7 +182,7 @@ struct ccsr_scfg {
u32 etsecmcr;
u32 sdhciovserlcr;
u32 resv14[61];
- u32 sparecr;
+ u32 sparecr[8];
};
/* Clocking */
Obviously the original code was not problematic as sparecr was not
used. Is your change dictated by a patch or series that you are
preparing and that will use sparecr?
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 5/6] MAINTAINERS: add me as a maintainer of UniPhier platform
Hi Masahiro, On Fri, 5 Sep 2014 14:50:22 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- Changes in v4: None Changes in v3: None Changes in v2: - Newly added MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index af194ca..cb5b3f0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -149,6 +149,14 @@ F: arch/arm/include/asm/arch-davinci/ F: arch/arm/include/asm/arch-omap*/ F: arch/arm/include/asm/ti-common/ +ARM UNIPHIER +M: Masahiro Yamada yamad...@jp.panasonic.com +S: Maintained +F: arch/arm/cpu/armv7/uniphier/ +F: arch/arm/include/asm/arch-uniphier/ +F: configs/ph1_*_defconfig +F: drivers/serial/serial_uniphier.c + ARM ZYNQ M: Michal Simek mon...@monstr.eu S: Maintained Acked-by: Albert ARIBAUD albert.u.b...@aribaud.net Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 5/6] MAINTAINERS: add me as a maintainer of UniPhier platform
Hi Masahiro, On 09/18/2014 01:33 PM, Albert ARIBAUD wrote: Hi Masahiro, On Fri, 5 Sep 2014 14:50:22 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- Changes in v4: None Changes in v3: None Changes in v2: - Newly added MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index af194ca..cb5b3f0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -149,6 +149,14 @@ F: arch/arm/include/asm/arch-davinci/ F: arch/arm/include/asm/arch-omap*/ F: arch/arm/include/asm/ti-common/ +ARM UNIPHIER +M: Masahiro Yamada yamad...@jp.panasonic.com +S: Maintained +F: arch/arm/cpu/armv7/uniphier/ +F: arch/arm/include/asm/arch-uniphier/ +F: configs/ph1_*_defconfig +F: drivers/serial/serial_uniphier.c + ARM ZYNQ M: Michal Simek mon...@monstr.eu S: Maintained Acked-by: Albert ARIBAUD albert.u.b...@aribaud.net Acked-by: Michal Simek mon...@monstr.eu Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot panasonic repo
Hi Masahiro, On Thu, 18 Sep 2014 19:13:04 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hi Michal, On Thu, 18 Sep 2014 10:24:39 +0200 Michal Simek mon...@monstr.eu wrote: Hi guys, On 09/18/2014 10:02 AM, Marek Vasut wrote: On Thursday, September 18, 2014 at 09:58:47 AM, Michal Simek wrote: On 09/18/2014 09:27 AM, Marek Vasut wrote: On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote: Hi Michal, Hi, On Thu, 11 Sep 2014 06:56:04 +0200 Michal Simek mon...@monstr.eu wrote: Hi, On 09/11/2014 05:09 AM, Masahiro Yamada wrote: On Thu, 11 Sep 2014 01:33:20 +0200 Marek Vasut ma...@denx.de wrote: Hello, I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place. Me too. I'd like to own u-boot-uniphier to collect Panasonic-SoC-specific changes. That would be faster and would not disturb Albert. I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that. The point is that you collect Zynq-specific patches in your own place by yourself and then send a pull-req to Albert or Tom, right? It does not matter whether it is a separate u-boot-zynq repo or u-boot-microbraze/zynq branch. I have sent the first series to add the core support of Panasonic SoCs and boards (but it is taking much longer than I have expected) and then I am planning to send more features and boards in the next phase. What's the difference between what I want to do for Panasonic SoCs and what you usually do for Zynq SoCs? [...] I fully support that we should have a repo for the panasonic socs, it's pointless to load Albert by making him apply patches by hand and you have proven numerous times that you do know what you're doing. I really see no blocker for doing this. +1 on this if Masahiro wants to have separate repo. There is no repo for those SoCs at all, so I'd be all for it. This is the flow which is IMHO the best. Thanks for your suggestion! Masahiro will send the RFC patch for MAINTAINERS file to Albert with adding his fragment for Panasonic SoCs. If Albert ACK but not apply it that it means that he agrees with that person to be responsible for this part. Based on that Masahiro asks for repo (if he wants it) and repo will be created. The patch for MAINTAINERS is already on our patchwork. Is this the one you mentioned? http://patchwork.ozlabs.org/patch/386108/ If so, all I have to do now is to just wait until Albert ackes it? Your wait is over. :) I assume you're going to re-delegate the uniphier series to yourself once this is done? Or do you want me to apply it? Best Regards Masahiro Yamada Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] compulab: eeprom: add default eeprom bus
Hi Igor, On Wed, 17 Sep 2014 17:18:49 +0300, Igor Grinberg grinb...@compulab.co.il wrote: On 09/17/14 15:59, Nikita Kiryanov wrote: Add default eeprom bus setting. This addresses the trimslice compile error that was introduced with the addition of this setting. Cc: Albert ARIBAUD albert.u.b...@aribaud.net Cc: Igor Grinberg grinb...@compulab.co.il Signed-off-by: Nikita Kiryanov nik...@compulab.co.il Acked-by: Igor Grinberg grinb...@compulab.co.il Albert, this should be a temporary fix to not break the trimslice support. We intend to rework this while switching Kconfig for all boards. Thanks! --- board/compulab/common/eeprom.c | 4 1 file changed, 4 insertions(+) diff --git a/board/compulab/common/eeprom.c b/board/compulab/common/eeprom.c index 85442cd..2df3ada 100644 --- a/board/compulab/common/eeprom.c +++ b/board/compulab/common/eeprom.c @@ -15,6 +15,10 @@ # define CONFIG_SYS_I2C_EEPROM_ADDR_LEN1 #endif +#ifndef CONFIG_SYS_I2C_EEPROM_BUS +#define CONFIG_SYS_I2C_EEPROM_BUS 0 +#endif + #define EEPROM_LAYOUT_VER_OFFSET 44 #define BOARD_SERIAL_OFFSET20 #define BOARD_SERIAL_OFFSET_LEGACY 8 a 'git grep CONFIG_SYS_I2C_EEPROM_BUS' shows that all values for CONFIG_SYS_I2C_EEPROM_BUS are set in include/configs/*.h. Therefore I would prefer that the temporary fix be in include/configs/trimslice.h header file too. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP4: Use generic 'load' command instead of 'fatload' for 'loadbootscript' and 'loadbootenv' as already done for 'loadimage' and 'loaduimage'.
On Fri, Sep 05, 2014 at 03:32:46PM +0200, Guillaume GARDET wrote: This patch uses generic 'load' command instead of 'fatload' for 'loadbootscript' and 'loadbootenv' as already done for 'loadimage' and 'loaduimage' for OMAP4 boards. This allows to use EXT partition instead of FAT, while keeping FAT compatibility. Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr Cc: Tom Rini tr...@ti.com Applied to u-boot-ti/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] [U-Boot, U-boot, v2] ARM: keystone: ddr3: workaround for ddr3a/3b memory issue
On Wed, Sep 10, 2014 at 03:54:59PM +0300, Khoronzhuk, Ivan wrote: From: Murali Karicheri m-kariche...@ti.com This patch implements a workaround to fix DDR3 memory issue. The code for workaround detects PGSR0 errors and then preps for and executes a software-controlled hard reset.In board_early_init, where logic has been added to identify whether or not the previous reset was a PORz. PLL initialization is skipped in the case of a software-controlled hard reset. Signed-off-by: Murali Karicheri m-kariche...@ti.com Signed-off-by: Keegan Garcia kgar...@ti.com Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com Applied to u-boot-ti/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] am335x_evm: Add boot script support to am335x_evm
On Thu, Sep 11, 2014 at 09:23:08AM +0200, Guillaume GARDET wrote: This patch adds boot script support to am335x_evm Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr Cc: Tom Rini tr...@ti.com Applied to u-boot-ti/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
[U-Boot] Please pull u-boot-ti/master
Hello, The following changes since commit c292adae170fa8c27dca75963bdb0a9afc640e57: Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' (2014-09-17 23:35:34 +0200) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to 3aae66e2a74ac89724d16b6e8908dcd0d2825eeb: am335x_evm: Add boot script support to am335x_evm (2014-09-17 21:06:56 -0400) Guillaume GARDET (2): OMAP4: Use generic 'load' command instead of 'fatload' for 'loadbootscript' and 'loadbootenv' as already done for 'loadimage' and 'loaduimage'. am335x_evm: Add boot script support to am335x_evm Murali Karicheri (1): ARM: keystone: ddr3: workaround for ddr3a/3b memory issue arch/arm/cpu/armv7/keystone/ddr3.c| 75 + arch/arm/include/asm/arch-keystone/ddr3.h |1 + arch/arm/include/asm/arch-keystone/hardware.h |2 + board/ti/ks2_evm/ddr3_k2hk.c |4 ++ include/configs/am335x_evm.h | 29 ++ include/configs/ti_omap4_common.h |4 +- 6 files changed, 102 insertions(+), 13 deletions(-) -- 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] A minor question on a Driver Model function
Hi Bill,
On 09/17/14 18:25, Bill Pringlemeir wrote:
On 12 September 2014 05:25, Masahiro Yamada yamad...@jp.panasonic.com
wrote:
I have a qustion about lists_driver_lookup_name() function.
for (entry = drv; entry != drv + n_ents; entry++) {
if (strncmp(name, entry-name, len))
continue;
/* Full match */
if (len == strlen(entry-name))
return entry;
}
On 09/14/14 21:28, Simon Glass wrote:
I would suggest still using strncmp as it is safer,
but count also the '\0', so something like:
On 17 Sep 2014, grinb...@compulab.co.il wrote:
Why safer?
Could you give me more detailed explanation?
On 09/17/14 11:18, Masahiro Yamada wrote:
Well, I'm not an expert in s/w security, but I'll try to explain...
[snip]
But, again, I'm not an expert in this area, so its only a suggestion.
I thought it was fairly apparent that the current code supports passing
a string that is *NOT* null terminated. This can be convenient if you
extract a sub-string from a command line and do not need to make a copy
that is NULL terminate or perform 'strtok()' type magic.
Here is the whole function:
--cut--
struct driver *lists_driver_lookup_name(const char *name)
{
struct driver *drv =
ll_entry_start(struct driver, driver);
const int n_ents = ll_entry_count(struct driver, driver);
struct driver *entry;
int len;
if (!drv || !n_ents)
return NULL;
len = strlen(name);
for (entry = drv; entry != drv + n_ents; entry++) {
if (strncmp(name, entry-name, len))
continue;
/* Full match */
if (len == strlen(entry-name))
return entry;
}
/* Not found */
return NULL;
}
--cut--
and... no, the code does not support passing a string that is
not null terminated.
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Need help with u-boot problem with usb-keyboard / kvm switch
On Thu, Sep 18, 2014 at 10:34:04AM +0200, Hans de Goede wrote: Hi, Cleaning up may not have been the best choice of words, I was talking about the rebase on top of upstream u-boot + the various fixes you already know about. I plan to submit a patch-set to the kernel for the clock resource stuff for simplefb to the proper lists for that discussion soon, and assuming that gets accepted I would like to land the hdmi support in upstream u-boot soon. Ok, thanks for getting me up to date on this. As for simplefb, i had given up on that, and wanted to cough up an alternate driver that simply wouldn't be called that. But as usual, i am all over the place. So let's see how the simplefb route goes. Good luck. Thanks, Luc Verhaegen. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] compulab: eeprom: add default eeprom bus
Hi ALbert, On 18/09/14 15:26, Albert ARIBAUD wrote: Hi Igor, On Wed, 17 Sep 2014 17:18:49 +0300, Igor Grinberg grinb...@compulab.co.il wrote: On 09/17/14 15:59, Nikita Kiryanov wrote: Add default eeprom bus setting. This addresses the trimslice compile error that was introduced with the addition of this setting. Cc: Albert ARIBAUD albert.u.b...@aribaud.net Cc: Igor Grinberg grinb...@compulab.co.il Signed-off-by: Nikita Kiryanov nik...@compulab.co.il Acked-by: Igor Grinberg grinb...@compulab.co.il Albert, this should be a temporary fix to not break the trimslice support. We intend to rework this while switching Kconfig for all boards. Thanks! --- board/compulab/common/eeprom.c | 4 1 file changed, 4 insertions(+) diff --git a/board/compulab/common/eeprom.c b/board/compulab/common/eeprom.c index 85442cd..2df3ada 100644 --- a/board/compulab/common/eeprom.c +++ b/board/compulab/common/eeprom.c @@ -15,6 +15,10 @@ # define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1 #endif +#ifndef CONFIG_SYS_I2C_EEPROM_BUS +#define CONFIG_SYS_I2C_EEPROM_BUS 0 +#endif + #define EEPROM_LAYOUT_VER_OFFSET 44 #define BOARD_SERIAL_OFFSET 20 #define BOARD_SERIAL_OFFSET_LEGACY8 a 'git grep CONFIG_SYS_I2C_EEPROM_BUS' shows that all values for CONFIG_SYS_I2C_EEPROM_BUS are set in include/configs/*.h. Therefore I would prefer that the temporary fix be in include/configs/trimslice.h header file too. Given that trimslice does not use the eeprom code, I feel that it's cleaner to not populate its config file with irrelevant defines. It's also consistent with the way CONFIG_SYS_I2C_EEPROM_ADDR and CONFIG_SYS_I2C_EEPROM_ADDR_LEN are handled. -- Regards, Nikita Kiryanov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot panasonic repo
Hi Albert, 2014-09-18 20:44 GMT+09:00 Albert ARIBAUD albert.u.b...@aribaud.net: Hi Masahiro, On Thu, 18 Sep 2014 19:13:04 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hi Michal, On Thu, 18 Sep 2014 10:24:39 +0200 Michal Simek mon...@monstr.eu wrote: Hi guys, On 09/18/2014 10:02 AM, Marek Vasut wrote: On Thursday, September 18, 2014 at 09:58:47 AM, Michal Simek wrote: On 09/18/2014 09:27 AM, Marek Vasut wrote: On Thursday, September 11, 2014 at 07:18:00 AM, Masahiro Yamada wrote: Hi Michal, Hi, On Thu, 11 Sep 2014 06:56:04 +0200 Michal Simek mon...@monstr.eu wrote: Hi, On 09/11/2014 05:09 AM, Masahiro Yamada wrote: On Thu, 11 Sep 2014 01:33:20 +0200 Marek Vasut ma...@denx.de wrote: Hello, I'd be interested in maintaining u-boot-socfpga repository. So far, we don't have a repo for this platform and there is a large flurry of patches flying around without any kind of central point for them. I'd like to get your formal consent for starting this and if you agree, I'd start sending PR to Albert once the repo is in place. Me too. I'd like to own u-boot-uniphier to collect Panasonic-SoC-specific changes. That would be faster and would not disturb Albert. I am not sure if you need to have separate repo to work like this. I am keeping zynq patches in my microblaze repo and sending pull request to Albert (or Tom now) and there is no problem with that. The point is that you collect Zynq-specific patches in your own place by yourself and then send a pull-req to Albert or Tom, right? It does not matter whether it is a separate u-boot-zynq repo or u-boot-microbraze/zynq branch. I have sent the first series to add the core support of Panasonic SoCs and boards (but it is taking much longer than I have expected) and then I am planning to send more features and boards in the next phase. What's the difference between what I want to do for Panasonic SoCs and what you usually do for Zynq SoCs? [...] I fully support that we should have a repo for the panasonic socs, it's pointless to load Albert by making him apply patches by hand and you have proven numerous times that you do know what you're doing. I really see no blocker for doing this. +1 on this if Masahiro wants to have separate repo. There is no repo for those SoCs at all, so I'd be all for it. This is the flow which is IMHO the best. Thanks for your suggestion! Masahiro will send the RFC patch for MAINTAINERS file to Albert with adding his fragment for Panasonic SoCs. If Albert ACK but not apply it that it means that he agrees with that person to be responsible for this part. Based on that Masahiro asks for repo (if he wants it) and repo will be created. The patch for MAINTAINERS is already on our patchwork. Is this the one you mentioned? http://patchwork.ozlabs.org/patch/386108/ If so, all I have to do now is to just wait until Albert ackes it? Your wait is over. :) Thanks!! I assume you're going to re-delegate the uniphier series to yourself once this is done? Or do you want me to apply it? Do not apply it, please. I've received some comments on this version and I am planning to send v5. I will change the state of this version to Superseded lator. 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 v3 09/11] dm: imx: gpio: Support driver model in MXC gpio driver
Hi Igor, On 18 September 2014 01:35, Igor Grinberg grinb...@compulab.co.il wrote: On 09/17/14 18:02, Simon Glass wrote: Add driver model support with this driver. In this case the platform data is in the driver. It would be better to put this into an SOC-specific file, but this is best attempted when more boards are moved over to use driver model. Signed-off-by: Simon Glass s...@chromium.org Acked-by: Igor Grinberg grinb...@compulab.co.il Thanks for reviewing these. The latest experimental state of driver model is at u-boot-dm/working. There is also an imx-working branch with this series in it. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 14/35] arm: socfpga: clock: Add missing stubs into board file
On Mon 2014-09-15 13:06:07, Marek Vasut wrote: Add some stub defines, which are used by the clock code, but are missing from the auto-generated header file for the SoCFPGA family. Signed-off-by: Marek Vasut ma...@denx.de Cc: Chin Liang See cl...@altera.com Cc: Dinh Nguyen dingu...@altera.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Tom Rini tr...@ti.com Cc: Wolfgang Denk w...@denx.de Acked-by: Pavel Machek pa...@denx.de -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/35] arm: socfpga: clock: Trim down code duplication
On Mon 2014-09-15 13:06:09, Marek Vasut wrote: Pull out functions to read frequency of Main clock VCO and PLL clock VCO as the code is duplicated multiple times. Signed-off-by: Marek Vasut ma...@denx.de Cc: Chin Liang See cl...@altera.com Cc: Dinh Nguyen dingu...@altera.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Tom Rini tr...@ti.com Cc: Wolfgang Denk w...@denx.de Acked-by : Pavel Machek pa...@denx.de -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dm: avoid dev-req_seq overflow
Since dev-req_seq value is initialized from reg property of fdt node,
there is posibility, that address value contained in fdt is greater than
INT_MAX, and then value in dev-req_seq is negative which led to probe()
fail.
This patch fix this problem by ensuring that req_seq is positive, unless
it's one of errno codes.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/core/device.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 166b073..35ffce0 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -107,6 +107,8 @@ int device_bind(struct udevice *parent, struct driver *drv,
const char *name,
* when the device is probed.
*/
dev-req_seq = fdtdec_get_int(gd-fdt_blob, of_offset, reg, -1);
+ if (!IS_ERR_VALUE(dev-req_seq))
+ dev-req_seq = INT_MAX;
dev-seq = -1;
if (uc-uc_drv-name of_offset != -1) {
fdtdec_get_alias_seq(gd-fdt_blob, uc-uc_drv-name, of_offset,
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/35][RFC] arm: socfpga: Usability fixes
Hi! What board are doing your testing on? The Arrow Sockit? I have board similar to SocKit, yes. I also see this error print: U-Boot 2014.10-rc2-00139-g70e9e3e-dirty (Sep 16 2014 - 16:26:56) CPU: Altera SoCFPGA Platform BOARD: Altera SoCFPGA Cyclone5 Board Watchdog enabled DRAM: 1 GiB WARNING: Caches not enabled Using default environment In:serial Out: serial Err: serial Net: dwmac.ff702000 Error: dwmac.ff702000 address not set. ^ Do you see this on your side? I can track it down... i2c code that reads address from ROM was not part of the merge, so you need to either set address manually or port it from rocketboards version. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] ARMv8: PSCI: Add linker section to hold PSCI code
On Thu, Sep 18 2014 at 10:12:17 AM, Albert ARIBAUD albert.u.b...@aribaud.net
wrote:
Hi Arnab,
On Thu, 28 Aug 2014 01:59:57 +0530, Arnab Basu
arnab.b...@freescale.com wrote:
A separate linker section makes it possible to keep this code either
in DDR or in some secure memory location provided specifically for the
purpose.
So far no one is using this section.
Signed-off-by: Arnab Basu arnab.b...@freescale.com
Reviewed-by: Bhupesh Sharma bhupesh.sha...@freescale.com
Cc: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/config.mk|2 +-
arch/arm/cpu/armv8/u-boot.lds | 30 ++
2 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index c339e6d..9272e9c 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -111,7 +111,7 @@ endif
# limit ourselves to the sections we want in the .bin.
ifdef CONFIG_ARM64
-OBJCOPYFLAGS += -j .text -j .rodata -j .data -j .u_boot_list -j .rela.dyn
+OBJCOPYFLAGS += -j .text -j .secure_text -j .rodata -j .data -j
.u_boot_list -j .rela.dyn
else
OBJCOPYFLAGS += -j .text -j .secure_text -j .rodata -j .hash -j .data -j
.got.plt -j .u_boot_list -j .rel.dyn
endif
diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds
index 4c1..bd95fff 100644
--- a/arch/arm/cpu/armv8/u-boot.lds
+++ b/arch/arm/cpu/armv8/u-boot.lds
@@ -8,6 +8,8 @@
* SPDX-License-Identifier: GPL-2.0+
*/
+#include config.h
+
OUTPUT_FORMAT(elf64-littleaarch64, elf64-littleaarch64,
elf64-littleaarch64)
OUTPUT_ARCH(aarch64)
ENTRY(_start)
@@ -23,6 +25,34 @@ SECTIONS
*(.text*)
}
+#ifdef CONFIG_ARMV8_PSCI
+
+#ifndef CONFIG_ARMV8_SECURE_BASE
+#define CONFIG_ARMV8_SECURE_BASE
+#endif
+
+.__secure_start : {
+. = ALIGN(0x1000);
+*(.__secure_start)
+}
+
+.secure_text CONFIG_ARMV8_SECURE_BASE :
+AT(ADDR(.__secure_start) + SIZEOF(.__secure_start))
+{
+*(._secure.text)
+}
+
+. = LOADADDR(.__secure_start) +
+SIZEOF(.__secure_start) +
+SIZEOF(.secure_text);
+
+__secure_end_lma = .;
+.__secure_end : AT(__secure_end_lma) {
+*(.__secure_end)
+LONG(0x1d1071c);/* Must output something to reset LMA */
Can you explain in more detail what issue this fixes?
If you use AT to force a new load address (LMA), you must ensure that
you actually output something at this address. Here, if *(.__secure_end)
ends up being empty, whatever follows would be as if the AT never
happened, ending up at the wrong LMA.
The workaround is to force the output of a dummy value in all
cases, ensuring that the rest of the text is at a sensible LMA. This is
an issue that has been in GNU ld for years, and this workaround is a
copy/paste of the same one in the ARMv7 ld script.
Thanks,
M.
--
Jazz is not dead. It just smells funny.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: [PATCH 0/7] ARM: sunxi: Add basic support for Allwinner A31 (sun6i)
Hi, On Thu, Sep 18, 2014 at 4:31 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 09/18/2014 06:27 AM, Siarhei Siamashka wrote: On Tue, 09 Sep 2014 09:00:57 +0200 Hans de Goede hdego...@redhat.com wrote: Hi, On 09/08/2014 03:28 PM, Chen-Yu Tsai wrote: Hi everyone, This series add basic support for Allwinner's A31 SoC. The patches, excluding the first one, were cherry-picked from u-boot-sunxi. Due to the difference between u-boot mainline and u-boot-sunxi, some patches were rearranged or squashed to better fit the current state of u-boot, and not introduce any build breaks. It follows Ian's initial merge method of sun7i support: introducing various components first, then enabling them in the last commit. I tried to keep the commits separate, thus retaining the original author and Signed-off-bys. Patch 1 adds a wrapper around func(USB, usb, 0) in BOOT_TARGET_DEVICES to deal with breakage when USB support is not enabled. Patch 2 adds memory addresses for some hardware blocks new in sun6i. Patch 3 adds support for the new PRCM (power reset and clock management) block, which also contains PLL bias voltage control. Patch 4 adds support for the clock module. This patch is a bunch of different sun6i related patches on the clock code, from when sun6i support was introduced to u-boot-sunxi, up to its current form. This is done to avoid various conflicts and needlessly introducing then removing macros. Patch 5 adds mmc support on sun6i. Patch 6 adds uart0 muxing on sun6i. Patch 7 enables sun6i support and adds defconfig for the Colombus board. Chen, Many thanks for working on this! Just a quick not for people celebrating too early, this is the *incomplete* sun7i support from the linux-sunxi/u-boot-sunxi git repo. It is fine to merge this upstream, but this does not include SPL support. This allows replacing u-boot.bin on allwinnner sd-card images, which is very useful. But it does not get us all the way to booting sun7i devices we still need boot0 and boot1 binaries from allwinner for that (for now). If I understand it correctly, one of the things that needs to be done in SPL is the initialization of the DRAM controller. A few weeks ago Oliver has updated the http://linux-sunxi.org/DRAM_Controller page and added a link to the 'dram_sun6i.c' file from the rhombus-tech.net u-boot repository: http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/sunxi/dram_sun6i.c;hb=refs/heads/allwinner-sunxi-a31 Does this repository look like exactly the missing part of code? Yes it does, interesting. I had found that file before, but this one was missing in the repo I found then: http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-sunxi/dram.h;hb=refs/heads/allwinner-sunxi-a31 But with that one added, this is definitely interesting. The A31 Hummingbird's SDK has provided us with full boot0/boot1, which also includes the dram code: http://dl.linux-sunxi.org/SDK/A31/unpacked-stripped/a31_v4.5_hummingbird_kfb_ok/lichee/boot-v1.0/boot/source/init_dram/ It is more complex than what we found in u-boot. This code also shows what is encoded into the dram parameters found in the fex files. Assuming that this code works, it provides a usable starting point for us. Yep, assuming :) If no one beats me to it I'll take a look at this as time permits. It looks like the Allwinner A31 DRAM controller registers are very similar to what is used in RK3288 (I have not checked the details, but if we are very lucky, it might be even a 100% perfect match): https://chromium-review.googlesource.com/#/c/209419/ And thanks to the Rockchip developers (who are contributing this DRAM controller support code to coreboot), now we have a lot of named defines for the individual bitfields in the hardware registers. So we can decode the magic constants used in the Allwinner code. And thanks to Texas Instruments, we also have some useful documentation, which also happens to be a reasonably good match: http://www.ti.com/lit/ug/spruhn7a/spruhn7a.pdf Sounds good / useful. In general, if we are on our own, then we just need to do all the boring work again (similar to what we did with the Allwinner A10/A13/A20 DRAM controller earlier). Starting with the creation of the http://linux-sunxi.org/A31_DRAM_Controller_Register_Guide wiki page and populating it with the information gathered from the Allwinner and Rockchip source code and also from the TI Keystone2 documentation. Naturally, every bit of this information needs to be verified on real Allwinner A31 hardware before we can make any assumptions. Yep. Matching the register bits with the parts decoded from dram parameters seems like a place to start, though i don't understand much of the terminology. However Allwinner has promised to provide us with some better documentation later this month:
Re: [U-Boot] A minor question on a Driver Model function
On 12 September 2014 05:25, Masahiro Yamada
yamad...@jp.panasonic.com wrote:
I have a qustion about lists_driver_lookup_name() function.
On 09/14/14 21:28, Simon Glass wrote:
I would suggest still using strncmp as it is safer,
but count also the '\0', so something like:
On 17 Sep 2014, grinb...@compulab.co.il wrote:
Why safer?
Could you give me more detailed explanation?
On 09/17/14 11:18, Masahiro Yamada wrote:
Well, I'm not an expert in s/w security, but I'll try to explain...
[snip]
But, again, I'm not an expert in this area, so its only a
suggestion.
On 09/17/14 18:25, Bill Pringlemeir wrote:
I thought it was fairly apparent that the current code supports
passing a string that is *NOT* null terminated. This can be
convenient if you extract a sub-string from a command line and do not
need to make a copy that is NULL terminate or perform 'strtok()' type
magic.
On 18 Sep 2014, grinb...@compulab.co.il wrote:
Here is the whole function:
--cut--
struct driver *lists_driver_lookup_name(const char *name)
{
struct driver *drv =
ll_entry_start(struct driver, driver);
const int n_ents = ll_entry_count(struct driver, driver);
struct driver *entry;
int len;
if (!drv || !n_ents)
return NULL;
len = strlen(name);
for (entry = drv; entry != drv + n_ents; entry++) {
if (strncmp(name, entry-name, len))
continue;
/* Full match */
if (len == strlen(entry-name))
return entry;
/* Not found */
return NULL;
--cut--
and... no, the code does not support passing a string that is
not null terminated.
Then using the strncmp() seems useless for security reasons? The 'len'
is not passed in by the caller and 'strlen()' will have the same
problems that 'strcmp()' would for read buffer overflows? I would guess
the code was cribbed from where 'len' was passed? In that case, it
would support strings that are not null terminated.
Sorry, I didn't look and understand your query now.
Fwiw,
Bill Pringlemeir.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH 5/7] sun4i: Add support for a number of new sun4i boards
On Sun, 27 Jul 2014 23:25:21 +0200
Hans de Goede hdego...@redhat.com wrote:
Add support for boards which I own and which already have a dts file in the
upstream kernel.
Hi Hans,
It's good to know that you have all this hardware and can take care of
maintaining it.
Signed-off-by: Henrik Nordstrom hen...@henriknordstrom.net
Signed-off-by: Stefan Roese s...@denx.de
Signed-off-by: Hans de Goede hdego...@redhat.com
---
board/sunxi/Makefile| 6 ++
board/sunxi/dram_a10_olinuxino_l.c | 31 +++
board/sunxi/dram_sun4i_360_1024_iow16.c | 31 +++
board/sunxi/dram_sun4i_360_1024_iow8.c | 31 +++
board/sunxi/dram_sun4i_360_512.c| 31 +++
board/sunxi/dram_sun4i_384_1024_iow8.c | 31 +++
boards.cfg | 6 ++
7 files changed, 167 insertions(+)
create mode 100644 board/sunxi/dram_a10_olinuxino_l.c
create mode 100644 board/sunxi/dram_sun4i_360_1024_iow16.c
create mode 100644 board/sunxi/dram_sun4i_360_1024_iow8.c
create mode 100644 board/sunxi/dram_sun4i_360_512.c
create mode 100644 board/sunxi/dram_sun4i_384_1024_iow8.c
diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index 03f55cc..b1db5d9 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -11,8 +11,14 @@
obj-y+= board.o
obj-$(CONFIG_SUNXI_GMAC) += gmac.o
obj-$(CONFIG_SUNXI_AHCI) += ahci.o
+obj-$(CONFIG_A10_OLINUXINO_L)+= dram_a10_olinuxino_l.o
Which revision of A10-OLinuXino-LIME do you have? Revision A is known
to have troubles running stable at 1008MHz CPU clock speed, as confirmed
on a sample set of two boards (mine and Oliver Schinagl's):
https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04343.html
A bunch of revision C boards were all fine in Oliver's tests. And
nobody has ever tested revision B so far, so we have no idea whether
it is stable or not. A mysterious thing is that the Olimex
representatives on IRC were not aware of any fixes of this kind
applied to the PCB.
My understanding is that the revision A was just a small pre-production
batch, donated by OLIMEX to a number of open source developers. Some of
these boards were distributed at FOSDEM. I'm not sure if we should
really worry about the reliability of the revision A, because none of
the 'normal' customers probably have such boards. We only need to
clarify the status of revision B.
But if we want to support the revision A too, then it probably needs
its own config, which would somehow restrict the CPU clock speed.
obj-$(CONFIG_A13_OLINUXINOM) += dram_a13_oli_micro.o
+obj-$(CONFIG_BA10_TV_BOX)+= dram_sun4i_384_1024_iow8.o
obj-$(CONFIG_CUBIEBOARD) += dram_cubieboard.o
obj-$(CONFIG_CUBIEBOARD2)+= dram_cubieboard2.o
obj-$(CONFIG_CUBIETRUCK) += dram_cubietruck.o
+obj-$(CONFIG_MELE_A1000) += dram_sun4i_360_512.o
+obj-$(CONFIG_MELE_A1000G)+= dram_sun4i_360_1024_iow8.o
+obj-$(CONFIG_MINI_X) += dram_sun4i_360_512.o
+obj-$(CONFIG_MINI_X_1GB) += dram_sun4i_360_1024_iow16.o
obj-$(CONFIG_R7DONGLE) += dram_r7dongle.o
diff --git a/board/sunxi/dram_a10_olinuxino_l.c
b/board/sunxi/dram_a10_olinuxino_l.c
new file mode 100644
index 000..24a1bd9
--- /dev/null
+++ b/board/sunxi/dram_a10_olinuxino_l.c
@@ -0,0 +1,31 @@
+/* this file is generated, don't edit it yourself */
+
+#include common.h
+#include asm/arch/dram.h
+
+static struct dram_para dram_para = {
+ .clock = 480,
+ .type = 3,
+ .rank_num = 1,
+ .density = 4096,
+ .io_width = 16,
+ .bus_width = 16,
+ .cas = 6,
The CAS=6 is not quite right for the 480MHz DRAM clock speed if we
are dealing with the typical DDR3 chips, with the timings mostly
representing the standard JEDEC speed bins.
CAS=6 is good up to 400MHz. CAS=7 is good up to 533MHz. And CAS=9 is
good up to 667MHz.
+ .zq = 123,
+ .odt_en = 0,
+ .size = 512,
+ .tpr0 = 0x30926692,
+ .tpr1 = 0x1090,
+ .tpr2 = 0x1a0c8,
The .tpr0/.tpr1/.tpr2 settings here are simply using the default reset
values of the DRAM controller hardware registers. Which happen to
match the DDR2-800E speed bin, as identified by Jens Kuske:
https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg03548.html
Either way, these settings are outside of the valid range when running
at 480MHz (which would be something like DDR3-960 in our case).
The fundamental problem here is that u-boot-sunxi essentially trusted
the device manufacturers to pick the correct DRAM settings. However
it looks like the device manufacturers did not have any proper DRAM
documentation either. And they just ended up picking some random
settings, which seemed to kinda work (and then copy/pasted these
settings from one device to another with minor variation). Also
without doubt, they were all under a
[U-Boot] compulab trimslice build error due to 52658fda7abc (compulab: eeprom: add support for defining eeprom i2c bus)
After commit 52658fda7abc (compulab: eeprom: add support for defining eeprom i2c bus), the trimslice board fails to build with: .../board/compulab/common/eeprom.c: In function ‘cl_eeprom_read’: .../board/compulab/common/eeprom.c:37:24: error: ‘CONFIG_SYS_I2C_EEPROM_BUS’ undeclared (first use in this function) .../board/compulab/common/eeprom.c:37:24: note: each undeclared identifier is reported only once for each function it appears in I have no idea if this EEPROM code should even run on TrimSlice or not. Can you take a look at the correct fix? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] ARMv8: PSCI: Enable SMC
-Original Message- From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] Sent: Thursday, September 18, 2014 2:48 PM To: Basu Arnab-B45036 Cc: marc.zyng...@arm.com; mark.rutl...@arm.com; Sun York-R58495; Yoder Stuart-B08248; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 8/8] ARMv8: PSCI: Enable SMC Hi Arnab, On Thu, 28 Aug 2014 02:00:01 +0530, Arnab Basu arnab.b...@freescale.com wrote: Enable the SMC instruction so that the kernel can use the psci code Signed-off-by: Arnab Basu arnab.b...@freescale.com Reviewed-by: Bhupesh Sharma bhupesh.sha...@freescale.com Cc: Marc Zyngier marc.zyng...@arm.com --- arch/arm/include/asm/macro.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h index 0009c28..94a1e68 100644 --- a/arch/arm/include/asm/macro.h +++ b/arch/arm/include/asm/macro.h @@ -106,7 +106,11 @@ lr .reqx30 .endm .macro armv8_switch_to_el2_m, xreg1 +#ifdef CONFIG_ARMV8_PSCI + mov \xreg1, #0x531 /* Non-secure EL0/EL1 | HVC | 64bit EL2 */ +#else mov \xreg1, #0x5b1 /* Non-secure EL0/EL1 | HVC | 64bit EL2 */ The 'mov' lines have different constant arguments in the instruction; their explanatory comments should not be the same. Right, I'll fix the comment. Thanks Arnab +#endif msr scr_el3, \xreg1 msr cptr_el3, xzr /* Disable coprocessor traps to EL3 */ mov \xreg1, #0x33ff Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: avoid dev-req_seq overflow
Hi Robert,
On 18 September 2014 09:13, Robert Baldyga r.bald...@samsung.com wrote:
Since dev-req_seq value is initialized from reg property of fdt node,
there is posibility, that address value contained in fdt is greater than
INT_MAX, and then value in dev-req_seq is negative which led to probe()
fail.
This patch fix this problem by ensuring that req_seq is positive, unless
it's one of errno codes.
Wouldn't this be a bug in the device tree file? What does it mean to have a
-ve value?
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/core/device.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 166b073..35ffce0 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -107,6 +107,8 @@ int device_bind(struct udevice *parent, struct driver
*drv, const char *name,
* when the device is probed.
*/
dev-req_seq = fdtdec_get_int(gd-fdt_blob, of_offset, reg, -1);
+ if (!IS_ERR_VALUE(dev-req_seq))
+ dev-req_seq = INT_MAX;
dev-seq = -1;
if (uc-uc_drv-name of_offset != -1) {
fdtdec_get_alias_seq(gd-fdt_blob, uc-uc_drv-name,
of_offset,
--
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 v2 00/40] ARM: tegra: Add PCIe support
HI Albert, On 18 September 2014 02:43, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Simon, On Thu, 11 Sep 2014 13:20:03 -0600, Simon Glass s...@chromium.org wrote: Hi, On 11 September 2014 10:17, Stephen Warren swar...@wwwdotorg.org wrote: On 09/11/2014 10:00 AM, Albert ARIBAUD wrote: Hi Thierry, On Tue, 26 Aug 2014 17:33:48 +0200, Thierry Reding thierry.red...@gmail.com wrote: From: Thierry Reding tred...@nvidia.com Note: this series was split over several custodians (including myself). It might thus get applied piecewise... Shouldn't it rather be assigned a single custodian -with others giving their Ack) and be applied as a whole? And yes, I'm ok with getting all the pieces. Yes, applying it all in one place would probably make sense. IIRC, Simon Glass already applied some of the DT patches early in the series? I CC'd him to check, Yes I applied the fdt patches to u-boot-fdt/next. I can do a pull request to ARM if that helps, or you can just grab them. Well, the idea was applying it all in one place :) and I don't like the idea of pulling the fdt tree into the arm tree, so I'll pick them up, but please give your Acked-by to them, so that PW sees it and puts it in when I apply the patches. They should all be acked already (I did that before I pulled them in) so please go ahead. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] compiler_gcc: prevent redefining attributes
The libc headers on FreeBSD and likely related projects as well contain an header file, cdefs.h which provides similiar functionality as linux/compiler.h. It provides compiler independent defines like __weak __packed, to allow compiling with multiple compilers which might have a different syntax for such extension. Since that header file is included in multiple standard headers, like stddef.h and stdarg.h, multiple definitions of those defines will be present if both are included. When compiling u-boot the compiler will warn about it hundreds of times since e.g. common.h will include both files indirectly. commit 7ea50d52849fe8ffa5b5b74c979b60b1045d6fc9 compiler_gcc: do not redefine __gnu_attributes prevented such redefinitions, but this was undone by commit fb8ffd7cfc68b3dc44e182356a207d784cb30b34 compiler*.h: sync include/linux/compiler*.h with Linux 3.16. Add the checks back where necessary to prevent such warnings. As the original patch this checkpatch warning is ignored: WARNING: Adding new packed members is to be done with care Cc: Masahiro Yamada yamad...@jp.panasonic.com Cc: Tom Rini tr...@ti.com Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl --- changes since v1: As requested by Masahiro, elaborate a bit about what cdefs.h is and how these warnings are caused. Only this patch is reposted. --- include/linux/compiler-gcc.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h index 02ae99e..e057bd2 100644 --- a/include/linux/compiler-gcc.h +++ b/include/linux/compiler-gcc.h @@ -64,8 +64,12 @@ #endif #define __deprecated __attribute__((deprecated)) +#ifndef __packed #define __packed __attribute__((packed)) +#endif +#ifndef __weak #define __weak __attribute__((weak)) +#endif /* * it doesn't make sense on ARM (currently the only user of __naked) to trace @@ -91,8 +95,12 @@ * would be. * [...] */ +#ifndef __pure #define __pure __attribute__((pure)) +#endif +#ifndef __aligned #define __aligned(x) __attribute__((aligned(x))) +#endif #define __printf(a, b) __attribute__((format(printf, a, b))) #define __scanf(a, b) __attribute__((format(scanf, a, b))) #define noinline __attribute__((noinline)) @@ -115,4 +123,6 @@ */ #define uninitialized_var(x) x = x +#ifndef __always_inline #define __always_inlineinline __attribute__((always_inline)) +#endif -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] compulab: eeprom: add default eeprom bus
Hi Nikita, On Thu, 18 Sep 2014 16:21:07 +0300, Nikita Kiryanov nik...@compulab.co.il wrote: Hi ALbert, On 18/09/14 15:26, Albert ARIBAUD wrote: Hi Igor, On Wed, 17 Sep 2014 17:18:49 +0300, Igor Grinberg grinb...@compulab.co.il wrote: On 09/17/14 15:59, Nikita Kiryanov wrote: Add default eeprom bus setting. This addresses the trimslice compile error that was introduced with the addition of this setting. Cc: Albert ARIBAUD albert.u.b...@aribaud.net Cc: Igor Grinberg grinb...@compulab.co.il Signed-off-by: Nikita Kiryanov nik...@compulab.co.il Acked-by: Igor Grinberg grinb...@compulab.co.il Albert, this should be a temporary fix to not break the trimslice support. We intend to rework this while switching Kconfig for all boards. Thanks! --- board/compulab/common/eeprom.c | 4 1 file changed, 4 insertions(+) diff --git a/board/compulab/common/eeprom.c b/board/compulab/common/eeprom.c index 85442cd..2df3ada 100644 --- a/board/compulab/common/eeprom.c +++ b/board/compulab/common/eeprom.c @@ -15,6 +15,10 @@ # define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1 #endif +#ifndef CONFIG_SYS_I2C_EEPROM_BUS +#define CONFIG_SYS_I2C_EEPROM_BUS0 +#endif + #define EEPROM_LAYOUT_VER_OFFSET44 #define BOARD_SERIAL_OFFSET 20 #define BOARD_SERIAL_OFFSET_LEGACY 8 a 'git grep CONFIG_SYS_I2C_EEPROM_BUS' shows that all values for CONFIG_SYS_I2C_EEPROM_BUS are set in include/configs/*.h. Therefore I would prefer that the temporary fix be in include/configs/trimslice.h header file too. Given that trimslice does not use the eeprom code, I feel that it's cleaner to not populate its config file with irrelevant defines. It's also consistent with the way CONFIG_SYS_I2C_EEPROM_ADDR and CONFIG_SYS_I2C_EEPROM_ADDR_LEN are handled. Makes sense enough. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] sama5d3xek: get GMAC working
I had a strange behaviour for my sama5d34ek board which could sometimes not get up GMAC in U-Boot. It turned out, that we missed to initialize the PHY correctly. Bo, could you please verify correct behaviour on 100MiB devices like sama5d31ek? Andreas Bießmann (2): macb: simplify gmac initialisation sama5d3xek: run PHY's config board/atmel/sama5d3xek/sama5d3xek.c | 29 - drivers/net/macb.c | 25 - 2 files changed, 28 insertions(+), 26 deletions(-) -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] macb: simplify gmac initialisation
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
Cc: Joe Hershberger joe.hershber...@gmail.com
Cc: Bo Shen voice.s...@atmel.com
---
drivers/net/macb.c | 25 -
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 01a94a4..375c8a4 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -479,31 +479,22 @@ static int macb_phy_init(struct macb_device *macb)
/* First check for GMAC */
if (macb_is_gem(macb)) {
lpa = macb_mdio_read(macb, MII_STAT1000);
- if (lpa (1 11)) {
- speed = 1000;
- duplex = 1;
- } else {
- if (lpa (1 10)) {
- speed = 1000;
- duplex = 1;
- } else {
- speed = 0;
- }
- }
- if (speed == 1000) {
- printf(%s: link up, %dMbps %s-duplex (lpa: 0x%04x)\n,
+ if (lpa (LPA_1000FULL | LPA_1000HALF)) {
+ duplex = ((lpa LPA_1000FULL) ? 1 : 0);
+
+ printf(%s: link up, 1000Mbps %s-duplex (lpa:
0x%04x)\n,
netdev-name,
- speed,
duplex ? full : half,
lpa);
ncfgr = macb_readl(macb, NCFGR);
- ncfgr = ~(GEM_BIT(GBE) | MACB_BIT(SPD) | MACB_BIT(FD));
- if (speed)
- ncfgr |= GEM_BIT(GBE);
+ ncfgr = ~(MACB_BIT(SPD) | MACB_BIT(FD));
+ ncfgr |= GEM_BIT(GBE);
+
if (duplex)
ncfgr |= MACB_BIT(FD);
+
macb_writel(macb, NCFGR, ncfgr);
return 1;
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] sama5d3xek: run PHY's config
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
Cc: Bo Shen voice.s...@atmel.com
---
board/atmel/sama5d3xek/sama5d3xek.c | 29 -
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/board/atmel/sama5d3xek/sama5d3xek.c
b/board/atmel/sama5d3xek/sama5d3xek.c
index f53754b..ca4f79d 100644
--- a/board/atmel/sama5d3xek/sama5d3xek.c
+++ b/board/atmel/sama5d3xek/sama5d3xek.c
@@ -17,6 +17,7 @@
#include lcd.h
#include atmel_lcdc.h
#include atmel_mci.h
+#include phy.h
#include micrel.h
#include net.h
#include netdev.h
@@ -273,15 +274,25 @@ int dram_init(void)
int board_phy_config(struct phy_device *phydev)
{
- /* rx data delay */
- ksz9021_phy_extended_write(phydev,
- MII_KSZ9021_EXT_RGMII_RX_DATA_SKEW, 0x);
- /* tx data delay */
- ksz9021_phy_extended_write(phydev,
- MII_KSZ9021_EXT_RGMII_TX_DATA_SKEW, 0x);
- /* rx/tx clock delay */
- ksz9021_phy_extended_write(phydev,
- MII_KSZ9021_EXT_RGMII_CLOCK_SKEW, 0xf2f4);
+ /* board specific timings for GMAC */
+ if (has_gmac()) {
+ /* rx data delay */
+ ksz9021_phy_extended_write(phydev,
+ MII_KSZ9021_EXT_RGMII_RX_DATA_SKEW,
+ 0x);
+ /* tx data delay */
+ ksz9021_phy_extended_write(phydev,
+ MII_KSZ9021_EXT_RGMII_TX_DATA_SKEW,
+ 0x);
+ /* rx/tx clock delay */
+ ksz9021_phy_extended_write(phydev,
+ MII_KSZ9021_EXT_RGMII_CLOCK_SKEW,
+ 0xf2f4);
+ }
+
+ /* always run the PHY's config routine */
+ if (phydev-drv-config)
+ return phydev-drv-config(phydev);
return 0;
}
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] compiler.h: remove duplicated uninitialized_var
On Thu, Sep 18, 2014 at 11:39:44AM +0200, Jeroen Hofstee wrote: Hello Masahiro, On 18-09-14 04:14, Masahiro Yamada wrote: Since clang has a different definition for uninitialized_var it will complain that it is redefined in include/compiler.h. Since these are already defined in linux/compiler.h just remove this instance. Cc: Masahiro Yamada yamad...@jp.panasonic.com Cc: Tom Rini tr...@ti.com Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl I don't mind this patch but it has made me realize another problem. We have both include/compiler.h and include/linux/compiler.h. Some sources use tha former and others use the latter. I don't know how to use the right one in the right place. no me neither, although it seems arch / drivers tend to use linux/compiler.h more while tools include compiler.h more. My first guess is that we can't as easily throw linux/compiler.h into tools and thus need that around just for tools. Perhaps we should note as much in compiler.h and fix regular code to use linux/compiler.h ? -- 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] arm: ls102xa: Fixed a register definition error
-Original Message-
From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
Sent: Thursday, September 18, 2014 7:25 PM
To: Tang Yuantian-B29983
Cc: Wang Huan-B18965; Lu Jingchang-B35083; Jin Zhengxiong-R64188;
Kushwaha Prabhakar-B32579; u-boot@lists.denx.de
Subject: Re: [PATCH] arm: ls102xa: Fixed a register definition error
Hi Tang,
On Thu, 18 Sep 2014 17:12:06 +0800, Tang Yuantian
yuantian.t...@freescale.com wrote:
There are 8 SCFG_SPARECR registers in SCFG memory block, not just one.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index 7995fe2..b5db720 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -182,7 +182,7 @@ struct ccsr_scfg {
u32 etsecmcr;
u32 sdhciovserlcr;
u32 resv14[61];
- u32 sparecr;
+ u32 sparecr[8];
};
/* Clocking */
Obviously the original code was not problematic as sparecr was not used. Is
your
change dictated by a patch or series that you are preparing and that will use
sparecr?
Yes, they will be used by deep sleep patches I am preparing.
Thanks,
Yuantian
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: HYP/non-sec: Make a variable as a local one
-Original Message-
From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
Sent: Thursday, September 18, 2014 5:44 PM
To: Tang Yuantian-B29983
Cc: andre.przyw...@linaro.org; i...@hellion.org.uk; marc.zyng...@arm.com;
u-boot@lists.denx.de; Jin Zhengxiong-R64188
Subject: Re: [PATCH] ARM: HYP/non-sec: Make a variable as a local one
Hi Tang,
Please fix subject / commit summary to indicate which variable is to be made
local.
On Thu, 18 Sep 2014 17:12:34 +0800, Tang Yuantian
yuantian.t...@freescale.com wrote:
Defining variable gic_dist_addr as a globe one prevents some
functions, which use this variable, from being used before relocation
which happened in the deep sleep resume process on Freescale SoC
platforms.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
arch/arm/cpu/armv7/virt-v7.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/virt-v7.c
b/arch/arm/cpu/armv7/virt-v7.c index 651ca40..b69fd37 100644
--- a/arch/arm/cpu/armv7/virt-v7.c
+++ b/arch/arm/cpu/armv7/virt-v7.c
@@ -15,8 +15,6 @@
#include asm/io.h
#include asm/secure.h
-unsigned long gic_dist_addr;
-
static unsigned int read_id_pfr1(void) {
unsigned int reg;
@@ -68,6 +66,12 @@ static void kick_secondary_cpus_gic(unsigned long
gicdaddr)
void __weak smp_kick_all_cpus(void)
{
+ unsigned long gic_dist_addr;
+
+ gic_dist_addr = get_gicd_base_address();
+ if (gic_dist_addr == -1)
+ return;
+
kick_secondary_cpus_gic(gic_dist_addr);
}
@@ -75,6 +79,7 @@ int armv7_init_nonsec(void) {
unsigned int reg;
unsigned itlinesnr, i;
+ unsigned long gic_dist_addr;
/* check whether the CPU supports the security extensions */
reg = read_id_pfr1();
Did you check that the global was not used as a common variable between the
functions?
Yes, I grep it globally. It was referred by only 2 places which are both in
virt-v7.c file.
I will fix the subject.
Thanks,
Yuantian
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] ARM: HYP/non-sec: Make variable gic_dist_addr as a local one
Defining variable gic_dist_addr as a globe one prevents some
functions, which use it, from being used before relocation
which is the case in the deep sleep resume process on Freescale
SoC platforms.
Besides, we can always get the GIC base address by calling
get_gicd_base_address() without referring gic_dist_addr.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
v2:
- refine the subjuct and commit message.
arch/arm/cpu/armv7/virt-v7.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c
index 651ca40..b69fd37 100644
--- a/arch/arm/cpu/armv7/virt-v7.c
+++ b/arch/arm/cpu/armv7/virt-v7.c
@@ -15,8 +15,6 @@
#include asm/io.h
#include asm/secure.h
-unsigned long gic_dist_addr;
-
static unsigned int read_id_pfr1(void)
{
unsigned int reg;
@@ -68,6 +66,12 @@ static void kick_secondary_cpus_gic(unsigned long gicdaddr)
void __weak smp_kick_all_cpus(void)
{
+ unsigned long gic_dist_addr;
+
+ gic_dist_addr = get_gicd_base_address();
+ if (gic_dist_addr == -1)
+ return;
+
kick_secondary_cpus_gic(gic_dist_addr);
}
@@ -75,6 +79,7 @@ int armv7_init_nonsec(void)
{
unsigned int reg;
unsigned itlinesnr, i;
+ unsigned long gic_dist_addr;
/* check whether the CPU supports the security extensions */
reg = read_id_pfr1();
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] compiler_gcc: prevent redefining attributes
On Thu, 18 Sep 2014 20:10:27 +0200 Jeroen Hofstee jer...@myspectrum.nl wrote: The libc headers on FreeBSD and likely related projects as well contain an header file, cdefs.h which provides similiar functionality as linux/compiler.h. It provides compiler independent defines like __weak __packed, to allow compiling with multiple compilers which might have a different syntax for such extension. Since that header file is included in multiple standard headers, like stddef.h and stdarg.h, multiple definitions of those defines will be present if both are included. When compiling u-boot the compiler will warn about it hundreds of times since e.g. common.h will include both files indirectly. commit 7ea50d52849fe8ffa5b5b74c979b60b1045d6fc9 compiler_gcc: do not redefine __gnu_attributes prevented such redefinitions, but this was undone by commit fb8ffd7cfc68b3dc44e182356a207d784cb30b34 compiler*.h: sync include/linux/compiler*.h with Linux 3.16. Add the checks back where necessary to prevent such warnings. As the original patch this checkpatch warning is ignored: WARNING: Adding new packed members is to be done with care Cc: Masahiro Yamada yamad...@jp.panasonic.com Cc: Tom Rini tr...@ti.com Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl Acked-by: Masahiro Yamada yamad...@jp.panasonic.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] sama5d3xek: get GMAC working
Hi Andreas, On 09/19/2014 05:46 AM, Andreas Bießmann wrote: I had a strange behaviour for my sama5d34ek board which could sometimes not get up GMAC in U-Boot. It turned out, that we missed to initialize the PHY correctly. Bo, could you please verify correct behaviour on 100MiB devices like sama5d31ek? Test OK on sama5d31ek board, you can add Tested-by tag for this patch series. Tested-by: Bo Shen voice.s...@atmel.com Thanks. Andreas Bießmann (2): macb: simplify gmac initialisation sama5d3xek: run PHY's config board/atmel/sama5d3xek/sama5d3xek.c | 29 - drivers/net/macb.c | 25 - 2 files changed, 28 insertions(+), 26 deletions(-) Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: [PATCH] usb: gadget: fastboot: improve download progress bar
Hi Marek,
On 09/18/2014 05:59 PM, Marek Vasut wrote:
On Thursday, September 18, 2014 at 10:11:49 AM, Bo Shen wrote:
Hi Marek,
On 09/18/2014 10:32 AM, Marek Vasut wrote:
On Thursday, September 18, 2014 at 03:34:18 AM, Bo Shen wrote:
Hi Marek,
On 09/17/2014 07:16 PM, Marek Vasut wrote:
On Wednesday, September 17, 2014 at 12:28:57 PM, Bo Shen wrote:
Hi Marek,
On 09/17/2014 06:10 PM, Marek Vasut wrote:
On Wednesday, September 17, 2014 at 09:43:56 AM, Bo Shen wrote:
+CC Lukasz, this is his turf.
When download is ongoing, if the actual size of one transfer is
not the same as BTYES_PER_DOT, which will cause the dot won't
print anymore. Then it will let the user thinking it is stuck,
actually it is transfering without dot printed.
So, improve the method to show the progress bar (print dot).
Signed-off-by: Bo Shen voice.s...@atmel.com
---
drivers/usb/gadget/f_fastboot.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/f_fastboot.c
b/drivers/usb/gadget/f_fastboot.c index 7a1acb9..2f13bf0 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -51,6 +51,7 @@ static inline struct f_fastboot
*func_to_fastboot(struct usb_function *f) static struct
f_fastboot *fastboot_func;
static unsigned int download_size;
static unsigned int download_bytes;
+static unsigned int num_of_dot;
static struct usb_endpoint_descriptor fs_ep_in = {
.bLength= USB_DT_ENDPOINT_SIZE,
@@ -414,9 +415,10 @@ static void rx_handler_dl_image(struct
usb_ep *ep, struct usb_request *req) req-length = ep-maxpacket;
}
- if (download_bytes !(download_bytes % BYTES_PER_DOT)) {
+ if (download_bytes ((download_bytes / BYTES_PER_DOT)
num_of_dot)) { +num_of_dot = download_bytes /
BYTES_PER_DOT;
putc('.');
- if (!(download_bytes % (74 * BYTES_PER_DOT)))
+ if (!(num_of_dot % 74))
putc('\n');
}
req-actual = 0;
@@ -431,6 +433,7 @@ static void cb_download(struct usb_ep *ep,
struct usb_request *req) strsep(cmd, :);
download_size = simple_strtoul(cmd, NULL, 16);
download_bytes = 0;
+ num_of_dot = 0;
Make it a 'download_total' and log the total amount of bytes
transferred please, that way it can be re-used for other purposes
in the future ; for example for printing how much data were
already transferred ;-)
The download_bytes record the total amount of bytes transferred.
And the download_bytes will print after finishing transfer.
So why can this not be used to indicate the total progress ? Because
the transfeer speed is variating too much ?
As I described in the commit message. If the transfer length is not
exactly the same as the request length, then the old method
download_bytes % BYTES_PER_DOT
won't be 0 anymore, so for the following transfer, it won't print dot
anymore.
And can you not reset the download_bytes for each transfer ?
No, I don't reset the download_bytes for each transfer. It reset the
download_bytes before transfer start.
The download_bytes is increase in rx_handler_dl_image function.
OK
Maybe we're not even aligned on what transfer means, so we might want
to sync on this word first. What does transfer mean in this case?
Transfer I mean here is a usb request, which trying to transfer
EP_BUFFER_SIZE at one time.
In my test case, sometime it transfer less than EP_BUFFER_SIZE in a usb
request. So, it cause dot won't print the dot, and seems stuck. However,
it will finish transfer after some time.
I see now. This code is really weird.
What would happen if the following condition is met in the code for k0 ?
(download_bytes == download_size) AND (download_bytes = k * BYTES_PER_DOT)
I am not fully understand what you plan to present here.
I think the original code would happily print a dot after printing this output:
printf(\ndownloading of %d bytes finished\n, download_bytes);
Do you agree ? If yes, then I believe this code should go into the else branch
only.
Yes, I agree. This may happen, if the (download_bytes % BTYES_PER_DOT)
equals to 0.
Also, you can probably avoid the counting variable if you do something like:
if (download_bytes / CONST != (download_bytes + transfer_size) / CONST) {
print(dot);
if (download_bytes / (74 * CONST) != ((download_bytes + transfer_size) /
(74 * CONST))
print(\n);
}
Surely, the code can be simplified . You would also need to be careful about
this assignment at the top of the function : download_bytes += transfer_size;
What do you think ?
I think this piece of code is better, which won't introduce new variable.
If no other comments, I will modify the code like this and send the v2
patch.
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Need help with u-boot problem with usb-keyboard / kvm switch
Hi All, On 09/18/2014 03:29 AM, Eric Nelson wrote: Hi Hans, On 09/17/2014 12:11 PM, Hans de Goede wrote: Hi Marek, et al, I'm working on cleaning up Luc's hdmi out support patchset for sunxi. As part of this I want to also add support for usb keyboards, so as to get a full console without needing to solder wires to testpoints on some boards :) So when I plug in the usb coming from my kvm I get this: (Re)start USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80 3 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found And the usb keyboard does not work. If I plug in a single usb-2 hub (no ohci support for sunxi in u-boot yet), then things do work, but after a few minutes of inactivity the usb code starts spamming the console with: EHCI timed out on TD - token=0x80008c80 EHCI timed out on TD - token=0x80008c80 ... Could this be a problem with the phy settings (iow a sunxi specific problem)? Probably not. We've seen the same thing on SABRE Lite and Nitrogen6X boards. U-Boot usb start ; setenv stdin serial,usbkbd (Re)start USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 2 USB Device(s) found USB1: USB EHCI 1.00 scanning bus 1 for devices... EHCI timed out on TD - token=0x80008c80 EHCI timed out on TD - token=0x80008c80 EHCI timed out on TD - token=0x80008c80 6 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found Timeout poll on interrupt endpoint Failed to get keyboard state from device 1c4f:0002 U-Boot usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Mass Storage (480 Mb/s, 100mA) Generic Mass Storage 4A3709D5 3 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-4 Hub (480 Mb/s, 2mA) | +-5 Human Interface (1.5 Mb/s, 100mA) |Logitech USB Optical Mouse | +-6 Hub (480 Mb/s, 100mA) | | USB 2.0 Hub | | | +-7 Human Interface (1.5 Mb/s, 98mA) | USB USB Keykoard | +-8 (12 Mb/s, 100mA) Oddly, the issue seems to be specific to **some** USB keyboards. We have some (mostly older) USB keyboards that just work and have had investigation on our to-do list for quite some time now. I was going to start with a question to the list: Is anyone else using USB keyboard support? I use the USB keyboard with following hack patch (which based on v2013.04), then it works well on my side. ---8--- diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c index bc17b85..b74bfd7 100644 --- a/drivers/usb/host/ohci-hcd.c +++ b/drivers/usb/host/ohci-hcd.c @@ -515,6 +515,7 @@ static inline int sohci_return_job(struct ohci *hc, urb_priv_t *urb) ohci_readl(regs-intrdisable); /* PCI posting flush */ } urb-actual_length = 0; +#if 0 td_submit_job( urb-dev, urb-pipe, @@ -523,6 +524,8 @@ static inline int sohci_return_job(struct ohci *hc, urb_priv_t *urb) NULL, urb, urb-interval); +#endif + urb_free_priv(urb); break; case PIPE_CONTROL: case PIPE_BULK: ---8--- USB mass storage seems to be pretty reliable. We have folks using it as an alternate boot for emergency situations. Regards, Eric Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] arm: ls102xa: Add SD boot support for LS1021AQDS board
Hi, Albert,
On Thu, 18 Sep 2014 13:47:18 +0800, Alison Wang b18...@freescale.com
wrote:
+
+ . = ALIGN(4);
+ .u_boot_list : {
+ KEEP(*(SORT(.u_boot_list*_i2c_*)));
+ }
IS this required? And if it is, could it not be added to the
arch/arm/cpu/u-boot-spl.lds file? This way you would not need an .lds file
at all.
[Alison Wang] Yes, it is required. I would like to add it in
arch/arm/cpu/u-boot-spl.lds. I was not sure adding it in
arch/arm/cpu/u-boot-spl.lds is acceptable or not.
Alison
--
View this message in context:
http://u-boot.10912.n7.nabble.com/PATCH-0-7-Add-SD-boot-support-for-LS1021AQDS-TWR-board-tp189678p189759.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: ls102xa: Fixed a register definition error
Verified on board ls1021qds.
Regards,
Alison.
-Original Message-
From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
Sent: Thursday, September 18, 2014 7:25 PM
To: Tang Yuantian-B29983
Cc: Wang Huan-B18965; Lu Jingchang-B35083; Jin Zhengxiong-R64188;
Kushwaha Prabhakar-B32579; u-boot@lists.denx.de
Subject: Re: [PATCH] arm: ls102xa: Fixed a register definition error
Hi Tang,
On Thu, 18 Sep 2014 17:12:06 +0800, Tang Yuantian
yuantian.t...@freescale.com wrote:
There are 8 SCFG_SPARECR registers in SCFG memory block, not just one.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index 7995fe2..b5db720 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -182,7 +182,7 @@ struct ccsr_scfg {
u32 etsecmcr;
u32 sdhciovserlcr;
u32 resv14[61];
- u32 sparecr;
+ u32 sparecr[8];
};
/* Clocking */
Obviously the original code was not problematic as sparecr was not used.
Is your change dictated by a patch or series that you are preparing and
that will use sparecr?
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] spl: pbl: Add new SPL image for pblimage tool
Hi, Albert, On Thu, 18 Sep 2014 13:47:13 +0800, Alison Wang b18...@freescale.com wrote: For the pblimage tool, the SPL image is splitted into 64 byte chunks, and PBL needs a command for each piece. In current pblimage structure, the size of the SPL image should be a fixed value. Well, for LS102xA and some other ARM platforms, the size of the SPL image is changeable. So a new image spl/u-boot-spl-pbl-pad.bin is built, and the size of it is a fixed value CONFIG_SPL_MAX_SIZE. Use it instead of spl/u-boot-spl.bin for LS102xA. CONFIG_SPL_PBL_PAD is used to enable this function. Signed-off-by: Alison Wang alison.w...@freescale.com --- There is already a CONFIG_SPL_PAD_TO (see ./README). Can you not use this? [Alison Wang] I have already used CONFIG_SPL_PAD_TO to determine the offset to which u-boot-spl.pbl should be padded when generating u-boot-with-spl-pbl.bin. Well, I used CONFIG_SPL_MAX_SIZE to determine the size of u-boot-spl-pbl-pad.bin. u-boot-spl-pbl-pad.bin is generated by padding u-boot-spl.bin to CONFIG_SPL_MAX_SIZE. Best Regards, Alison Wang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: [PATCH] usb: gadget: fastboot: improve download progress bar
On Friday, September 19, 2014 at 05:27:05 AM, Bo Shen wrote:
Hi Marek,
[...]
Transfer I mean here is a usb request, which trying to transfer
EP_BUFFER_SIZE at one time.
In my test case, sometime it transfer less than EP_BUFFER_SIZE in a usb
request. So, it cause dot won't print the dot, and seems stuck. However,
it will finish transfer after some time.
I see now. This code is really weird.
What would happen if the following condition is met in the code for k0 ?
(download_bytes == download_size) AND (download_bytes = k *
BYTES_PER_DOT)
I am not fully understand what you plan to present here.
I think the original code would happily print a dot after printing this
output: printf(\ndownloading of %d bytes finished\n, download_bytes);
Do you agree ? If yes, then I believe this code should go into the else
branch only.
Yes, I agree. This may happen, if the (download_bytes % BTYES_PER_DOT)
equals to 0.
Also, you can probably avoid the counting variable if you do something
like:
if (download_bytes / CONST != (download_bytes + transfer_size) / CONST) {
print(dot);
if (download_bytes / (74 * CONST) != ((download_bytes + transfer_size) /
(74 * CONST))
print(\n);
}
Surely, the code can be simplified . You would also need to be careful
about this assignment at the top of the function : download_bytes +=
transfer_size;
What do you think ?
I think this piece of code is better, which won't introduce new variable.
If no other comments, I will modify the code like this and send the v2
patch.
Well OK then. Thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Call for participation in the U-Boot Mini Summit 2014
On Thursday, September 18, 2014 at 10:52:12 AM, Alexey Brodkin wrote: Hi Detlev, On Wed, 2014-09-03 at 18:56 +0200, Przemyslaw Marczak wrote: Hello Detlev, On 08/11/2014 05:48 PM, Przemyslaw Marczak wrote: Hello Detlev, On 01/13/2014 06:12 PM, Detlev Zundel wrote: Hi, as already indicated, we are looking forward to our next U-Boot Mini Summit at Embedded Linux Conference Europe 2014 which will take place in Düsseldorf, Germany from October 13 - 15. The call for papers of the main conference is now open[1] and if you want to submit a talk for the main tracks, you should note the deadline of July 11. For our U-Boot Mini Summit, I'd like to get the schedule completed synchronized to the schedule release of the main event, which is August 12. So please submit talk proposals here with at least me on CC. To coordinate the event better, I have setup another wiki page[2] that can and _should_ be edited by the interested parties. Feel free for example to add yourself to the interested participants so that we get an idea of how many of the U-Boot developers will be there. Best wishes Detlev Sorry for my late input on this regard. But if there's still a possibility to have another talk I'd like to propose mine ARC - new first-class citizen in U-Boot (which was declined for main ELCE2014 event). Abstract is in-lined below. === U-Boot is a de-facto standard bootloader for Linux-driven embedded systems. It provides flexible means for loading kernel and if required image of filesystem from different media be it embedded non-volatile memory, attached storage or even network share. Linux kernel was ported to DesignWare ARC a while ago and starting from version 3.9 the port was accepted upstream. Now to enable real-life device booting on custom hardware decision was made to port U-Boot for ARC. This presentation unveils reasons to start the project, highlights milestones passed during porting process, touches some pitfalls and encourages more engineers and companies to use and contribute to U-Boot project. === I'm not sure if this kind of speech is of any interest for existing U-boot developers, but I may indeed emphasize technical aspects now. Any feedback is more than welcome. If that's an introduction to porting U-Boot, it might bring to light some new ideas about the porting process and also point out some obstacles we were not aware of. I think it's a good idea to have such a war story ;-) 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 6/7] arm: ls102xa: Add SD boot support for LS1021AQDS board
Hi, Albert,
+ . = ALIGN(4);
+ .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
+
+ . = ALIGN(4);
+ .data : {
+ *(.data*)
+ }
+
+ . = ALIGN(4);
+ .u_boot_list : {
+ KEEP(*(SORT(.u_boot_list*_i2c_*)));
+ }
IS this required? And if it is, could it not be added to the
arch/arm/cpu/u-boot-spl.lds file? This way you would not need an .lds
file at all.
[Alison Wang] Yes, it is required. I would like to add it in
arch/arm/cpu/u-boot-spl.lds. I was not sure adding it in
arch/arm/cpu/u-boot-spl.lds is acceptable or not.
Best Regards,
Alison Wang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: avoid dev-req_seq overflow
On 09/18/2014 08:00 PM, Simon Glass wrote:
Hi Robert,
On 18 September 2014 09:13, Robert Baldyga r.bald...@samsung.com
mailto:r.bald...@samsung.com wrote:
Since dev-req_seq value is initialized from reg property of fdt node,
there is posibility, that address value contained in fdt is greater than
INT_MAX, and then value in dev-req_seq is negative which led to probe()
fail.
This patch fix this problem by ensuring that req_seq is positive, unless
it's one of errno codes.
Wouldn't this be a bug in the device tree file? What does it mean to
have a -ve value?
Device tree seems to be ok. We have:
pinctrl0: pinctrl@e020 {
compatible = samsung,s5pc110-pinctrl;
reg = 0xe020 0x1000;
};
So when we take address from reg as dev-req_seq, then value
0xe020 after casting to int gives -534773760. Function
uclass_resolve_seq() returns it as proper seq number, because it's
unique. But then in file drivers/core/device.c, in function
device_probe() we have:
seq = uclass_resolve_seq(dev);
if (seq 0) {
ret = seq;
goto fail;
}
And it will obviously fail.
Using reg value as req_seq doesn't work when this value is greater
than INT_MAX.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
mailto:r.bald...@samsung.com
---
drivers/core/device.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 166b073..35ffce0 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -107,6 +107,8 @@ int device_bind(struct udevice *parent, struct
driver *drv, const char *name,
* when the device is probed.
*/
dev-req_seq = fdtdec_get_int(gd-fdt_blob, of_offset,
reg, -1);
+ if (!IS_ERR_VALUE(dev-req_seq))
+ dev-req_seq = INT_MAX;
dev-seq = -1;
if (uc-uc_drv-name of_offset != -1) {
fdtdec_get_alias_seq(gd-fdt_blob, uc-uc_drv-name,
of_offset,
--
1.9.1
Thanks,
Robert Baldyga
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
