[U-Boot] [PATCH 4/4] powerpc/p1010rdb: add p1010rdb-pb support with updating p1010rdb-pa
- Rename old P1010RDB board as P1010RDB-PA.
- Add support for new P1010RDB-PB board.
- Some optimization.
For more details, see board/freescale/p1010rdb/README.
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
board/freescale/p1010rdb/p1010rdb.c | 176 ++--
boards.cfg | 40 +---
include/configs/P1010RDB.h | 101 ++---
3 files changed, 283 insertions(+), 34 deletions(-)
diff --git a/board/freescale/p1010rdb/p1010rdb.c
b/board/freescale/p1010rdb/p1010rdb.c
index ae8ba45..e940d22 100644
--- a/board/freescale/p1010rdb/p1010rdb.c
+++ b/board/freescale/p1010rdb/p1010rdb.c
@@ -38,12 +38,23 @@ DECLARE_GLOBAL_DATA_PTR;
enum {
MUX_TYPE_IFC,
MUX_TYPE_SDHC,
+ MUX_TYPE_SPIFLASH,
+ MUX_TYPE_TDM,
+ MUX_TYPE_CAN,
+ MUX_TYPE_CS0_NOR,
+ MUX_TYPE_CS0_NAND,
+};
+
+enum {
+ I2C_READ_BANK,
+ I2C_READ_PCB_VER,
};
static uint sd_ifc_mux;
struct cpld_data {
u8 cpld_ver; /* cpld revision */
+#if defined(CONFIG_P1010RDB_PA)
u8 pcba_ver; /* pcb revision number */
u8 twindie_ddr3;
u8 res1[6];
@@ -58,6 +69,9 @@ struct cpld_data {
u8 por1; /* POR Options */
u8 por2; /* POR Options */
u8 por3; /* POR Options */
+#elif defined(CONFIG_P1010RDB_PB)
+ u8 rom_loc;
+#endif
};
int board_early_init_f(void)
@@ -116,6 +130,9 @@ int config_board_mux(int ctrl_type)
ccsr_gur_t __iomem *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
u8 tmp;
+#if defined(CONFIG_P1010RDB_PA)
+ struct cpld_data *cpld_data = (void *)(CONFIG_SYS_CPLD_BASE);
+
switch (ctrl_type) {
case MUX_TYPE_IFC:
i2c_set_bus_num(I2C_PCA9557_BUS_NUM);
@@ -136,25 +153,171 @@ int config_board_mux(int ctrl_type)
clrsetbits_be32(gur-pmuxcr, PMUXCR1_SDHC_MASK,
PMUXCR1_SDHC_ENABLE);
break;
+ case MUX_TYPE_SPIFLASH:
+ out_8(cpld_data-spi_cs0_sel, MUX_CPLD_SPICS0_FLASH);
+ break;
+ case MUX_TYPE_TDM:
+ out_8(cpld_data-tdm_can_sel, MUX_CPLD_TDM);
+ out_8(cpld_data-spi_cs0_sel, MUX_CPLD_SPICS0_SLIC);
+ break;
+ case MUX_TYPE_CAN:
+ out_8(cpld_data-tdm_can_sel, MUX_CPLD_CAN_UART);
+ break;
default:
break;
}
+#elif defined(CONFIG_P1010RDB_PB)
+ uint orig_bus = i2c_get_bus_num();
+ i2c_set_bus_num(I2C_PCA9557_BUS_NUM);
+ switch (ctrl_type) {
+ case MUX_TYPE_IFC:
+ i2c_read(I2C_PCA9557_ADDR2, 0, 1, tmp, 1);
+ clrbits_8(tmp, 0x04);
+ i2c_write(I2C_PCA9557_ADDR2, 1, 1, tmp, 1);
+ i2c_read(I2C_PCA9557_ADDR2, 3, 1, tmp, 1);
+ clrbits_8(tmp, 0x04);
+ i2c_write(I2C_PCA9557_ADDR2, 3, 1, tmp, 1);
+ sd_ifc_mux = MUX_TYPE_IFC;
+ clrbits_be32(gur-pmuxcr, PMUXCR1_IFC_MASK);
+ break;
+ case MUX_TYPE_SDHC:
+ i2c_read(I2C_PCA9557_ADDR2, 0, 1, tmp, 1);
+ setbits_8(tmp, 0x04);
+ i2c_write(I2C_PCA9557_ADDR2, 1, 1, tmp, 1);
+ i2c_read(I2C_PCA9557_ADDR2, 3, 1, tmp, 1);
+ clrbits_8(tmp, 0x04);
+ i2c_write(I2C_PCA9557_ADDR2, 3, 1, tmp, 1);
+ sd_ifc_mux = MUX_TYPE_SDHC;
+ clrsetbits_be32(gur-pmuxcr, PMUXCR1_SDHC_MASK,
+ PMUXCR1_SDHC_ENABLE);
+ break;
+ case MUX_TYPE_SPIFLASH:
+ i2c_read(I2C_PCA9557_ADDR2, 0, 1, tmp, 1);
+ clrbits_8(tmp, 0x80);
+ i2c_write(I2C_PCA9557_ADDR2, 1, 1, tmp, 1);
+ i2c_read(I2C_PCA9557_ADDR2, 3, 1, tmp, 1);
+ clrbits_8(tmp, 0x80);
+ i2c_write(I2C_PCA9557_ADDR2, 3, 1, tmp, 1);
+ break;
+ case MUX_TYPE_TDM:
+ i2c_read(I2C_PCA9557_ADDR2, 0, 1, tmp, 1);
+ setbits_8(tmp, 0x82);
+ i2c_write(I2C_PCA9557_ADDR2, 1, 1, tmp, 1);
+ i2c_read(I2C_PCA9557_ADDR2, 3, 1, tmp, 1);
+ clrbits_8(tmp, 0x82);
+ i2c_write(I2C_PCA9557_ADDR2, 3, 1, tmp, 1);
+ break;
+ case MUX_TYPE_CAN:
+ i2c_read(I2C_PCA9557_ADDR2, 0, 1, tmp, 1);
+ clrbits_8(tmp, 0x02);
+ i2c_write(I2C_PCA9557_ADDR2, 1, 1, tmp, 1);
+ i2c_read(I2C_PCA9557_ADDR2, 3, 1, tmp, 1);
+ clrbits_8(tmp, 0x02);
+ i2c_write(I2C_PCA9557_ADDR2, 3, 1, tmp, 1);
+ break;
+ case MUX_TYPE_CS0_NOR:
+ i2c_read(I2C_PCA9557_ADDR2, 0, 1, tmp, 1);
+ clrbits_8(tmp, 0x08);
+ i2c_write(I2C_PCA9557_ADDR2, 1, 1, tmp, 1);
+ i2c_read(I2C_PCA9557_ADDR2, 3, 1, tmp, 1);
+ clrbits_8(tmp, 0x08);
+
[U-Boot] [PATCH 3/4] board/p1010rdb: add pin mux and sdhc support in any boot
Since pins multiplexing, SDHC shares signals with IFC, with this patch:
To enable SDHC in case of NOR/NAND/SPI boot
a) For temporary use case in runtime without reboot system
run 'mux sdhc' in u-boot to validate SDHC with invalidating IFC.
b) For long-term use case
set 'esdhc' in hwconfig and save it.
To enable IFC in case of SD boot
a) For temporary use case in runtime without reboot system
run 'mux ifc' in u-boot to validate IFC with invalidating SDHC.
b) For long-term use case
set 'ifc' in hwconfig and save it.
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
board/freescale/p1010rdb/law.c | 2 -
board/freescale/p1010rdb/p1010rdb.c | 119 +++-
board/freescale/p1010rdb/tlb.c | 4 --
include/configs/P1010RDB.h | 15 +
4 files changed, 107 insertions(+), 33 deletions(-)
diff --git a/board/freescale/p1010rdb/law.c b/board/freescale/p1010rdb/law.c
index 0045127..ed41a05 100644
--- a/board/freescale/p1010rdb/law.c
+++ b/board/freescale/p1010rdb/law.c
@@ -9,11 +9,9 @@
#include asm/mmu.h
struct law_entry law_table[] = {
-#ifndef CONFIG_SDCARD
SET_LAW(CONFIG_SYS_FLASH_BASE_PHYS, LAW_SIZE_32M, LAW_TRGT_IF_IFC),
SET_LAW(CONFIG_SYS_CPLD_BASE_PHYS, LAW_SIZE_128K, LAW_TRGT_IF_IFC),
SET_LAW(CONFIG_SYS_NAND_BASE_PHYS, LAW_SIZE_1M, LAW_TRGT_IF_IFC),
-#endif
};
int num_law_entries = ARRAY_SIZE(law_table);
diff --git a/board/freescale/p1010rdb/p1010rdb.c
b/board/freescale/p1010rdb/p1010rdb.c
index 42153e6..ae8ba45 100644
--- a/board/freescale/p1010rdb/p1010rdb.c
+++ b/board/freescale/p1010rdb/p1010rdb.c
@@ -21,10 +21,8 @@
#include asm/fsl_serdes.h
#include asm/fsl_ifc.h
#include asm/fsl_pci.h
-
-#ifndef CONFIG_SDCARD
#include hwconfig.h
-#endif
+#include i2c.h
DECLARE_GLOBAL_DATA_PTR;
@@ -33,8 +31,17 @@ DECLARE_GLOBAL_DATA_PTR;
#define MUX_CPLD_TDM 0x01
#define MUX_CPLD_SPICS0_FLASH 0x00
#define MUX_CPLD_SPICS0_SLIC 0x02
+#define PMUXCR1_IFC_MASK 0x0000
+#define PMUXCR1_SDHC_MASK 0x00fff000
+#define PMUXCR1_SDHC_ENABLE0x00555000
+
+enum {
+ MUX_TYPE_IFC,
+ MUX_TYPE_SDHC,
+};
+
+static uint sd_ifc_mux;
-#ifndef CONFIG_SDCARD
struct cpld_data {
u8 cpld_ver; /* cpld revision */
u8 pcba_ver; /* pcb revision number */
@@ -52,17 +59,14 @@ struct cpld_data {
u8 por2; /* POR Options */
u8 por3; /* POR Options */
};
-#endif
int board_early_init_f(void)
{
ccsr_gpio_t *pgpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR);
-#ifndef CONFIG_SDCARD
struct fsl_ifc *ifc = (void *)CONFIG_SYS_IFC_ADDR;
/* Clock configuration to access CPLD using IFC(GPCM) */
setbits_be32(ifc-ifc_gcr, 1 IFC_GCR_TBCTL_TRN_TIME_SHIFT);
-#endif
/*
* Reset PCIe slots via GPIO4
*/
@@ -74,7 +78,6 @@ int board_early_init_f(void)
int board_early_init_r(void)
{
-#ifndef CONFIG_SDCARD
const unsigned int flashbase = CONFIG_SYS_FLASH_BASE;
const u8 flash_esel = find_tlb_idx((void *)flashbase, 1);
@@ -98,7 +101,6 @@ int board_early_init_r(void)
CONFIG_SYS_FLASH_BASE_PHYS + 0x100,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, flash_esel+1, BOOKE_PAGESZ_16M, 1);
-#endif
return 0;
}
@@ -109,6 +111,38 @@ void pci_init_board(void)
}
#endif /* ifdef CONFIG_PCI */
+int config_board_mux(int ctrl_type)
+{
+ ccsr_gur_t __iomem *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+ u8 tmp;
+
+ switch (ctrl_type) {
+ case MUX_TYPE_IFC:
+ i2c_set_bus_num(I2C_PCA9557_BUS_NUM);
+ tmp = 0xf0;
+ i2c_write(I2C_PCA9557_ADDR1, 3, 1, tmp, 1);
+ tmp = 0x01;
+ i2c_write(I2C_PCA9557_ADDR1, 1, 1, tmp, 1);
+ sd_ifc_mux = MUX_TYPE_IFC;
+ clrbits_be32(gur-pmuxcr, PMUXCR1_IFC_MASK);
+ break;
+ case MUX_TYPE_SDHC:
+ i2c_set_bus_num(I2C_PCA9557_BUS_NUM);
+ tmp = 0xf0;
+ i2c_write(I2C_PCA9557_ADDR1, 3, 1, tmp, 1);
+ tmp = 0x05;
+ i2c_write(I2C_PCA9557_ADDR1, 1, 1, tmp, 1);
+ sd_ifc_mux = MUX_TYPE_SDHC;
+ clrsetbits_be32(gur-pmuxcr, PMUXCR1_SDHC_MASK,
+ PMUXCR1_SDHC_ENABLE);
+ break;
+ default:
+ break;
+ }
+
+ return 0;
+}
+
int checkboard(void)
{
struct cpu_type *cpu;
@@ -116,6 +150,11 @@ int checkboard(void)
cpu = gd-arch.cpu;
printf(Board: %sRDB\n, cpu-name);
+#ifdef CONFIG_SDCARD
+ /* switch to IFC to read info from CPLD */
+ config_board_mux(MUX_TYPE_IFC);
+#endif
+
return 0;
}
@@ -211,6 +250,16 @@ void fdt_del_sdhc(void *blob)
}
}
+void fdt_del_ifc(void *blob)
+{
+ int nodeoff = 0;
+
+ while
[U-Boot] [PATCH 1/4] powerpc/p1010rdb: remove unused cpld_show
Function cpld_show() was for debug and not called, so clean it.
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
board/freescale/p1010rdb/p1010rdb.c | 35 ---
1 file changed, 35 deletions(-)
diff --git a/board/freescale/p1010rdb/p1010rdb.c
b/board/freescale/p1010rdb/p1010rdb.c
index 06aa800..42153e6 100644
--- a/board/freescale/p1010rdb/p1010rdb.c
+++ b/board/freescale/p1010rdb/p1010rdb.c
@@ -52,41 +52,6 @@ struct cpld_data {
u8 por2; /* POR Options */
u8 por3; /* POR Options */
};
-
-void cpld_show(void)
-{
- struct cpld_data *cpld_data = (void *)(CONFIG_SYS_CPLD_BASE);
-
- printf(CPLD: V%x.%x PCBA: V%x.0\n,
- in_8(cpld_data-cpld_ver) 0xF0,
- in_8(cpld_data-cpld_ver) 0x0F,
- in_8(cpld_data-pcba_ver) 0x0F);
-
-#ifdef CONFIG_DEBUG
- printf(twindie_ddr =%x\n,
- in_8(cpld_data-twindie_ddr3));
- printf(bank_sel =%x\n,
- in_8(cpld_data-bank_sel));
- printf(usb2_sel =%x\n,
- in_8(cpld_data-usb2_sel));
- printf(porsw_sel =%x\n,
- in_8(cpld_data-porsw_sel));
- printf(tdm_can_sel =%x\n,
- in_8(cpld_data-tdm_can_sel));
- printf(tdm_can_sel =%x\n,
- in_8(cpld_data-tdm_can_sel));
- printf(spi_cs0_sel =%x\n,
- in_8(cpld_data-spi_cs0_sel));
- printf(bcsr0 =%x\n,
- in_8(cpld_data-bcsr0));
- printf(bcsr1 =%x\n,
- in_8(cpld_data-bcsr1));
- printf(bcsr2 =%x\n,
- in_8(cpld_data-bcsr2));
- printf(bcsr3 =%x\n,
- in_8(cpld_data-bcsr3));
-#endif
-}
#endif
int board_early_init_f(void)
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] powerpc/eeprom: update MAX_NUM_PORTS to adapt non-256-bytes EEPROM
Some boards use System EEPROM with 128-bytes instead of 256-bytes. Since we regard 256-bytes EEPROM as standard EEPROM with default value for MAX_NUM_PORTS. For those non-256-bytes EEPROM, we can redefine MAX_NUM_PORTS in board-specific file to override the default MAX_NUM_PORTS. This patch doesn't impact on previous existing boards. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- Verified with 128B and 256B EEPROM, CRC works. board/freescale/common/sys_eeprom.c | 4 1 file changed, 4 insertions(+) diff --git a/board/freescale/common/sys_eeprom.c b/board/freescale/common/sys_eeprom.c index d789364..9c18dd8 100644 --- a/board/freescale/common/sys_eeprom.c +++ b/board/freescale/common/sys_eeprom.c @@ -18,7 +18,11 @@ #endif #ifdef CONFIG_SYS_I2C_EEPROM_NXID +/* some boards with non-256-bytes EEPROM have special define */ +/* for MAX_NUM_PORTS in board-specific file */ +#ifndef MAX_NUM_PORTS #define MAX_NUM_PORTS 23 +#endif #define NXID_VERSION 1 #endif -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/3] dfu: ram support
Hi, DFU spec mentions it as a method to upgrade firmware (software stored in writable non-volatile memory). It also says other potential uses of DFU is beyond scope of the spec. Here such a beyond the scope use is being attempted - directly pumping binary images from host via USB to RAM. This facility is a developer centric one in that it gives advantage over upgrading non-volatile memory for testing new images every time during development and/or testing. Directly putting image onto RAM would speed up upgrade process. This and convenience was the initial thoughts that led to doing this, speed improvement over MMC was only 1 second though - 6 sec on RAM as opposed to 7 sec on MMC in beagle bone, perhaps enabling cache and/or optimizing DFU framework to avoid multiple copy for ram (if worth) may help, and on other platforms and other boot media like NAND maybe improvement would be higher. And for a platform that doesn't yet have proper DFU suppport for non-volatile media's, DFU to RAM can be used. Another minor advantage would be to increase life of mmc/nand as it would be less used during development/testing. usage: image name ram start address size eg. kernel ram 0x8100 0x100 Downloading images to RAM using DFU is not something new, this is acheived in openmoko also. DFU on RAM can be used for extracting RAM contents to host using dfu upload. Perhaps this can be extended to io for squeezing out register In addition to ram support, a minor unification of dfu read/write enum's currently duplicated in mmc/nand is done, helping ram support too. Also dfu ram support is added for am335x SoC based boards. Based on: usb master branch Regards Afzal v3: collected tags, error used instead of printf v2: unified read/write dfu ops enum, added am335x support Afzal Mohammed (3): dfu: unify mmc/nand read/write ops enum dfu: ram support am335x_evm: enable DFU RAM drivers/dfu/Makefile | 1 + drivers/dfu/dfu.c| 7 ++-- drivers/dfu/dfu_mmc.c| 9 ++ drivers/dfu/dfu_nand.c | 7 +--- drivers/dfu/dfu_ram.c| 76 include/configs/am335x_evm.h | 6 include/dfu.h| 23 ++ 7 files changed, 114 insertions(+), 15 deletions(-) create mode 100644 drivers/dfu/dfu_ram.c -- 1.8.2.135.g7b592fa ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] dfu: unify mmc/nand read/write ops enum
MMC and NAND independently defines same enumerators for read/write.
Unify them by defining enum in dfu header. RAM support that is being
added newly also can make use of it.
Signed-off-by: Afzal Mohammed afzal.mohd...@gmail.com
Cc: Marek Vasut ma...@denx.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
Acked-by: Lukasz Majewski l.majew...@samsung.com
---
v3: collected tag
v2: new
drivers/dfu/dfu_mmc.c | 9 ++---
drivers/dfu/dfu_nand.c | 7 +--
include/dfu.h | 5 +
3 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 0871a77..f942758 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -13,16 +13,11 @@
#include div64.h
#include dfu.h
-enum dfu_mmc_op {
- DFU_OP_READ = 1,
- DFU_OP_WRITE,
-};
-
static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE)
dfu_file_buf[CONFIG_SYS_DFU_MAX_FILE_SIZE];
static long dfu_file_buf_len;
-static int mmc_block_op(enum dfu_mmc_op op, struct dfu_entity *dfu,
+static int mmc_block_op(enum dfu_op op, struct dfu_entity *dfu,
u64 offset, void *buf, long *len)
{
char cmd_buf[DFU_CMD_BUF_SIZE];
@@ -65,7 +60,7 @@ static int mmc_file_buffer(struct dfu_entity *dfu, void *buf,
long *len)
return 0;
}
-static int mmc_file_op(enum dfu_mmc_op op, struct dfu_entity *dfu,
+static int mmc_file_op(enum dfu_op op, struct dfu_entity *dfu,
void *buf, long *len)
{
char cmd_buf[DFU_CMD_BUF_SIZE];
diff --git a/drivers/dfu/dfu_nand.c b/drivers/dfu/dfu_nand.c
index 0ec12cf..edbf5a9 100644
--- a/drivers/dfu/dfu_nand.c
+++ b/drivers/dfu/dfu_nand.c
@@ -19,12 +19,7 @@
#include jffs2/load_kernel.h
#include nand.h
-enum dfu_nand_op {
- DFU_OP_READ = 1,
- DFU_OP_WRITE,
-};
-
-static int nand_block_op(enum dfu_nand_op op, struct dfu_entity *dfu,
+static int nand_block_op(enum dfu_op op, struct dfu_entity *dfu,
u64 offset, void *buf, long *len)
{
loff_t start, lim;
diff --git a/include/dfu.h b/include/dfu.h
index 392cef1..6a3e253 100644
--- a/include/dfu.h
+++ b/include/dfu.h
@@ -29,6 +29,11 @@ enum dfu_layout {
DFU_FS_EXT4,
};
+enum dfu_op {
+ DFU_OP_READ = 1,
+ DFU_OP_WRITE,
+};
+
struct mmc_internal_data {
/* RAW programming */
unsigned int lba_start;
--
1.8.2.135.g7b592fa
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/3] dfu: ram support
DFU spec mentions it as a method to upgrade firmware (software stored
in writable non-volatile memory). It also says other potential uses of
DFU is beyond scope of the spec.
Here such a beyond the scope use is being attempted - directly pumping
binary images from host via USB to RAM. This facility is a developer
centric one in that it gives advantage over upgrading non-volatile
memory for testing new images every time during development and/or
testing.
Directly putting image onto RAM would speed up upgrade process. This and
convenience was the initial thoughts that led to doing this, speed
improvement over MMC was only 1 second though - 6 sec on RAM as opposed
to 7 sec on MMC in beagle bone, perhaps enabling cache and/or optimizing
DFU framework to avoid multiple copy for ram (if worth) may help, and
on other platforms and other boot media like NAND maybe improvement
would be higher.
And for a platform that doesn't yet have proper DFU suppport for
non-volatile media's, DFU to RAM can be used.
Another minor advantage would be to increase life of mmc/nand as it
would be less used during development/testing.
usage: image name ram start address size
eg. kernel ram 0x8100 0x100
Downloading images to RAM using DFU is not something new, this is
acheived in openmoko also.
DFU on RAM can be used for extracting RAM contents to host using dfu
upload. Perhaps this can be extended to io for squeezing out register
dump through usb, if it is worth.
Signed-off-by: Afzal Mohammed afzal.mohd...@gmail.com
Cc: Marek Vasut ma...@denx.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
---
v3: error used instead of printf
v2: remove read/write enumerator define's, instead use new common ones
drivers/dfu/Makefile | 1 +
drivers/dfu/dfu.c | 7 +++--
drivers/dfu/dfu_ram.c | 76 +++
include/dfu.h | 18
4 files changed, 100 insertions(+), 2 deletions(-)
create mode 100644 drivers/dfu/dfu_ram.c
diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile
index fca370a..de9e44e 100644
--- a/drivers/dfu/Makefile
+++ b/drivers/dfu/Makefile
@@ -12,6 +12,7 @@ LIB = $(obj)libdfu.o
COBJS-$(CONFIG_DFU_FUNCTION) += dfu.o
COBJS-$(CONFIG_DFU_MMC) += dfu_mmc.o
COBJS-$(CONFIG_DFU_NAND) += dfu_nand.o
+COBJS-$(CONFIG_DFU_RAM) += dfu_ram.o
SRCS:= $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS-y))
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 689f5db..56b21c7 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -348,6 +348,9 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char *s,
int alt,
} else if (strcmp(interface, nand) == 0) {
if (dfu_fill_entity_nand(dfu, s))
return -1;
+ } else if (strcmp(interface, ram) == 0) {
+ if (dfu_fill_entity_ram(dfu, s))
+ return -1;
} else {
printf(%s: Device %s not (yet) supported!\n,
__func__, interface);
@@ -397,14 +400,14 @@ int dfu_config_entities(char *env, char *interface, int
num)
const char *dfu_get_dev_type(enum dfu_device_type t)
{
- const char *dev_t[] = {NULL, eMMC, OneNAND, NAND };
+ const char *dev_t[] = {NULL, eMMC, OneNAND, NAND, RAM };
return dev_t[t];
}
const char *dfu_get_layout(enum dfu_layout l)
{
const char *dfu_layout[] = {NULL, RAW_ADDR, FAT, EXT2,
- EXT3, EXT4 };
+ EXT3, EXT4, RAM_ADDR };
return dfu_layout[l];
}
diff --git a/drivers/dfu/dfu_ram.c b/drivers/dfu/dfu_ram.c
new file mode 100644
index 000..2e3520c
--- /dev/null
+++ b/drivers/dfu/dfu_ram.c
@@ -0,0 +1,76 @@
+/*
+ * (C) Copyright 2013
+ * Afzal Mohammed afzal.mohd...@gmail.com
+ *
+ * Reference: dfu_mmc.c
+ * Copyright (C) 2012 Samsung Electronics
+ * author: Lukasz Majewski l.majew...@samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include malloc.h
+#include errno.h
+#include dfu.h
+
+static int dfu_transfer_medium_ram(enum dfu_op op, struct dfu_entity *dfu,
+ u64 offset, void *buf, long *len)
+{
+ if (dfu-layout != DFU_RAM_ADDR) {
+ error(unsupported layout: %s\n, dfu_get_layout(dfu-layout));
+ return -EINVAL;
+ }
+
+ if (offset dfu-data.ram.size) {
+ error(request exceeds allowed area\n);
+ return -EINVAL;
+ }
+
+ if (op == DFU_OP_WRITE)
+ memcpy(dfu-data.ram.start + offset, buf, *len);
+ else
+ memcpy(buf, dfu-data.ram.start + offset, *len);
+
+ return 0;
+}
+
+static int dfu_write_medium_ram(struct dfu_entity *dfu, u64 offset,
+ void *buf, long *len)
+{
+ return dfu_transfer_medium_ram(DFU_OP_WRITE, dfu, offset, buf, len);
+}
+
+static int
[U-Boot] [PATCH v3 3/3] am335x_evm: enable DFU RAM
Enable DFU for RAM, provide example dfu_alt_info
Signed-off-by: Afzal Mohammed afzal.mohd...@gmail.com
Cc: Tom Rini tr...@ti.com
Cc: Marek Vasut ma...@denx.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
Reviewed-by: Lukasz Majewski l.majew...@samsung.com
---
v3: collected tag
v2: new
include/configs/am335x_evm.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 3de30fc..978fdf9 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -100,6 +100,7 @@
loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0 \
importbootenv=echo Importing environment from mmc ...; \
env import -t $loadaddr $filesize\0 \
+ dfu_alt_info_ram= DFU_ALT_INFO_RAM \0 \
ramargs=setenv bootargs console=${console} \
${optargs} \
root=${ramroot} \
@@ -321,6 +322,11 @@
kernel part 0 8; \
rootfs part 0 9
#endif
+#define CONFIG_DFU_RAM
+#define DFU_ALT_INFO_RAM \
+ kernel ram 0x8020 0xD8; \
+ fdt ram 0x80F8 0x8; \
+ ramdisk ram 0x8100 0x400
/*
* Default to using SPI for environment, etc.
--
1.8.2.135.g7b592fa
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] mx6sabresd: Avoid hang when HDMI cable is not connected
Hi Eric, On 12/09/2013 17:02, Eric Nelson wrote: This isn't needed yet in the stock (main-line) code base, since we haven't added any panels without detection. ok, thanks - I will then apply Fabio's patches for the Freescale's boards. We do have a form this patch and a lot of panels in our local tree on Github, but wanted to avoid unnecessary noise on the list because we've integrated a dozen or so panels and the existing structure really doesn't scale. We had a separate discussion regarding treating the displays as data (environment), but have stalled somewhat on that front. I think also that using the environment seems a clumsy solution. We used a lot of times in the past, and we have not unified their usage. The current device-tree code for i.MX6 uses mode strings instead of the detailed timing data that's really needed for a proper solution. I admit that using DT also for u-boot seems a better solution. You're right about i.MX6 in kernel, but on the other hand I like how it is described for i.MX28 boards. The display-timings node contain all information we need. It would be nice to have the same for i.MX6. Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net: fec_mxc: Add support for mx6 solo-lite
On 13/09/2013 05:16, Otavio Salvador wrote: On Thu, Sep 12, 2013 at 7:41 PM, Fabio Estevam feste...@gmail.com wrote: From: Fabio Estevam fabio.este...@freescale.com Similarly as mx25 and mx53, mx6solo-lite needs to setup the MII gasket for RMII mode. Add support for mx6solo-lite. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Seems safe enough to go into 2013.10, doesn't it? :-) Agree - I will merge it and push it. Regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v9 3/5] generic board patch of manual reloc and zero gd_t
From: David Feng feng...@phytium.com.cn
Signed-off-by: David Feng feng...@phytium.com.cn
---
common/board_f.c | 19 +++
common/board_r.c | 18 ++
2 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index 0ada1af..f6ca610 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -458,7 +458,7 @@ static int reserve_round_4k(void)
static int reserve_mmu(void)
{
/* reserve TLB table */
- gd-arch.tlb_size = 4096 * 4;
+ gd-arch.tlb_size = PGTABLE_SIZE;
gd-relocaddr -= gd-arch.tlb_size;
/* round down to next 64 kB limit */
@@ -610,7 +610,7 @@ static int reserve_stacks(void)
* TODO(s...@chromium.org): Perhaps create arch_reserve_stack()
* to handle this and put in arch/xxx/lib/stack.c
*/
-# ifdef CONFIG_ARM
+# if defined(CONFIG_ARM) !defined(CONFIG_ARMV8)
# ifdef CONFIG_USE_IRQ
gd-start_addr_sp -= (CONFIG_STACKSIZE_IRQ + CONFIG_STACKSIZE_FIQ);
debug(Reserving %zu Bytes for IRQ stack at: %08lx\n,
@@ -807,11 +807,6 @@ static int mark_bootstage(void)
}
static init_fnc_t init_sequence_f[] = {
-#if !defined(CONFIG_CPM2) !defined(CONFIG_MPC512X) \
- !defined(CONFIG_MPC83xx) !defined(CONFIG_MPC85xx) \
- !defined(CONFIG_MPC86xx) !defined(CONFIG_X86)
- zero_global_data,
-#endif
#ifdef CONFIG_SANDBOX
setup_ram_buf,
#endif
@@ -1001,10 +996,18 @@ void board_init_f(ulong boot_flags)
{
#ifndef CONFIG_X86
gd_t data;
-
gd = data;
#endif
+ /*
+* Zero gd_t first, otherwise the debug print(if DEBUG defined)
+* in initcall_run_list function before zero_global_data is called
+* will go wrong.
+*/
+#ifndef CONFIG_X86
+ zero_global_data();
+#endif
+
gd-flags = boot_flags;
if (initcall_run_list(init_sequence_f))
diff --git a/common/board_r.c b/common/board_r.c
index 86ca1cb..7217e3c 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -157,6 +157,13 @@ static int initr_reloc_global_data(void)
*/
gd-env_addr += gd-relocaddr - CONFIG_SYS_MONITOR_BASE;
#endif
+#ifdef CONFIG_NEEDS_MANUAL_RELOC
+ /*
+* We have to relocate the command table manually
+*/
+ fixup_cmdtable(ll_entry_start(cmd_tbl_t, cmd),
+ ll_entry_count(cmd_tbl_t, cmd));
+#endif /* CONFIG_NEEDS_MANUAL_RELOC */
return 0;
}
@@ -899,6 +906,7 @@ init_fnc_t init_sequence_r[] = {
initr_modem,
#endif
run_main_loop,
+ NULL,
};
void board_init_r(gd_t *new_gd, ulong dest_addr)
@@ -906,6 +914,16 @@ void board_init_r(gd_t *new_gd, ulong dest_addr)
#ifndef CONFIG_X86
gd = new_gd;
#endif
+#ifdef CONFIG_NEEDS_MANUAL_RELOC
+ /*
+* We have to relocate the init_sequence_r table manually
+*/
+ init_fnc_t *init_fnc_ptr;
+ for (init_fnc_ptr = init_sequence_r; *init_fnc_ptr; ++init_fnc_ptr)
+ *init_fnc_ptr = (init_fnc_t *)
+ ((unsigned long)(*init_fnc_ptr) + gd-reloc_off);
+#endif /* CONFIG_NEEDS_MANUAL_RELOC */
+
if (initcall_run_list(init_sequence_r))
hang();
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v9 2/5] board support of vexpress_aemv8a
From: David Feng feng...@phytium.com.cn
Signed-off-by: David Feng feng...@phytium.com.cn and Sharma Bhupesh
b45...@freescale.com
---
MAINTAINERS |4 +
board/armltd/dts/vexpress64.dts | 439 ++
board/armltd/vexpress64/Makefile | 27 +++
board/armltd/vexpress64/vexpress64.c | 70 ++
boards.cfg |1 +
include/configs/vexpress_aemv8a.h| 193 +++
6 files changed, 734 insertions(+)
create mode 100644 board/armltd/dts/vexpress64.dts
create mode 100644 board/armltd/vexpress64/Makefile
create mode 100644 board/armltd/vexpress64/vexpress64.c
create mode 100644 include/configs/vexpress_aemv8a.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 6e50fc4..d142307 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1095,6 +1095,10 @@ Sergey Yanovich ynv...@gmail.com
lp8x4x xscale/pxa
+David Feng feng...@phytium.com.cn
+
+ vexpress_aemv8a ARM ARMV8 (Quad Core)
+
-
Unknown / orphaned boards:
diff --git a/board/armltd/dts/vexpress64.dts b/board/armltd/dts/vexpress64.dts
new file mode 100644
index 000..067fea7
--- /dev/null
+++ b/board/armltd/dts/vexpress64.dts
@@ -0,0 +1,439 @@
+/*
+ * ARM Ltd. Fast Models
+ *
+ * Architecture Envelope Model (AEM) ARMv8-A
+ * ARMAEMv8AMPCT
+ *
+ * RTSM_VE_AEMv8A.lisa
+ */
+
+/dts-v1/;
+
+/memreserve/ 0x8000 0x0001;
+
+/ {
+ /* boot configurations for u-boot */
+ config {
+ /*bootdelay = 1;*/
+ kernel-offset = 0x10;
+ rootdisk-offset = 0x80;
+ bootcmd = bootm 0x10 0x80:0x200;
+ };
+};
+
+/ {
+ model = RTSM_VE_AEMv8A;
+ compatible = arm,rtsm_ve,aemv8a, arm,vexpress;
+ interrupt-parent = gic;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ /* chosen */
+ /* generated by u-boot */
+
+
+ aliases {
+ serial0 = v2m_serial0;
+ serial1 = v2m_serial1;
+ serial2 = v2m_serial2;
+ serial3 = v2m_serial3;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 0;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ cpu@1 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 1;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ cpu@2 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 2;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ cpu@3 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 3;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ };
+
+ memory@8000 {
+ device_type = memory;
+ reg = 0x 0x8000 0 0x8000,
+ 0x0008 0x8000 0 0x8000;
+ };
+
+ gic: interrupt-controller@2c001000 {
+ compatible = arm,cortex-a15-gic, arm,cortex-a9-gic;
+ #interrupt-cells = 3;
+ #address-cells = 0;
+ interrupt-controller;
+ reg = 0x0 0x2c001000 0 0x1000,
+ 0x0 0x2c002000 0 0x1000,
+ 0x0 0x2c004000 0 0x2000,
+ 0x0 0x2c006000 0 0x2000;
+ interrupts = 1 9 0xf04;
+ };
+
+ timer {
+ compatible = arm,armv8-timer;
+ interrupts = 1 13 0xff01,
+1 14 0xff01,
+1 11 0xff01,
+1 10 0xff01;
+ clock-frequency = 1;
+ };
+
+ pmu {
+ compatible = arm,armv8-pmuv3;
+ interrupts = 0 60 4,
+0 61 4,
+0 62 4,
+0 63 4;
+ };
+
+ smb {
+ compatible = simple-bus;
+
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0 0x0800 0x0400,
+1 0 0 0x1400 0x0400,
+2 0 0 0x1800 0x0400,
+3 0 0 0x1c00 0x0400,
+4 0 0 0x0c00 0x0400,
+5 0 0
[U-Boot] [PATCH v9 4/5] 64bit initrd start address support
From: David Feng feng...@phytium.com.cn
Signed-off-by: David Feng feng...@phytium.com.cn
---
common/fdt_support.c | 66 ++
1 file changed, 34 insertions(+), 32 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index b034c98..9bc5821 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -21,6 +21,34 @@
*/
DECLARE_GLOBAL_DATA_PTR;
+/*
+ * Get cells len in bytes
+ * if #-cells property is 2 then len is 8
+ * otherwise len is 4
+ */
+static int get_cells_len(void *blob, char *nr_cells_name)
+{
+ const fdt32_t *cell;
+
+ cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
+ if (cell fdt32_to_cpu(*cell) == 2)
+ return 8;
+
+ return 4;
+}
+
+/*
+ * Write a 4 or 8 byte big endian cell
+ */
+static void write_cell(u8 *addr, u64 val, int size)
+{
+ int shift = (size - 1) * 8;
+ while (size-- 0) {
+ *addr++ = (val shift) 0xff;
+ shift -= 8;
+ }
+}
+
/**
* fdt_getprop_u32_default - Find a node and return it's property or a default
*
@@ -131,9 +159,9 @@ static int fdt_fixup_stdout(void *fdt, int chosenoff)
int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end, int force)
{
- int nodeoffset;
+ int nodeoffset, addr_cell_len;
int err, j, total;
- fdt32_t tmp;
+ fdt64_t tmp;
const char *path;
uint64_t addr, size;
@@ -170,9 +198,11 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong
initrd_end, int force)
return err;
}
+ addr_cell_len = get_cells_len(fdt, #address-cells);
+
path = fdt_getprop(fdt, nodeoffset, linux,initrd-start, NULL);
if ((path == NULL) || force) {
- tmp = cpu_to_fdt32(initrd_start);
+ write_cell((u8 *)tmp, initrd_start, addr_cell_len);
err = fdt_setprop(fdt, nodeoffset,
linux,initrd-start, tmp, sizeof(tmp));
if (err 0) {
@@ -181,7 +211,7 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong
initrd_end, int force)
fdt_strerror(err));
return err;
}
- tmp = cpu_to_fdt32(initrd_end);
+ write_cell((u8 *)tmp, initrd_end, addr_cell_len);
err = fdt_setprop(fdt, nodeoffset,
linux,initrd-end, tmp, sizeof(tmp));
if (err 0) {
@@ -343,34 +373,6 @@ void do_fixup_by_compat_u32(void *fdt, const char *compat,
do_fixup_by_compat(fdt, compat, prop, tmp, 4, create);
}
-/*
- * Get cells len in bytes
- * if #-cells property is 2 then len is 8
- * otherwise len is 4
- */
-static int get_cells_len(void *blob, char *nr_cells_name)
-{
- const fdt32_t *cell;
-
- cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
- if (cell fdt32_to_cpu(*cell) == 2)
- return 8;
-
- return 4;
-}
-
-/*
- * Write a 4 or 8 byte big endian cell
- */
-static void write_cell(u8 *addr, u64 val, int size)
-{
- int shift = (size - 1) * 8;
- while (size-- 0) {
- *addr++ = (val shift) 0xff;
- shift -= 8;
- }
-}
-
#ifdef CONFIG_NR_DRAM_BANKS
#define MEMORY_BANKS_MAX CONFIG_NR_DRAM_BANKS
#else
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v9 0/5] arm64 patch
From: David Feng feng...@phytium.com.cn The porting has been merged with arm architecture. Most architecture codes are placed in arch/arm/cpu/armv8 directory. Generic board is also supported after a few bugs are fixed. u-boot could be running at EL1 or EL2. Changes for v8: - add Signed-off-by information to patch board support of vexpress_aemv8a which SMC9 support is integrated from Sharma Bhupesh's patch. - adjust pt_regs struct and add exception state preservation in exception.S. Changes for v7: - Integrate SMC9 patch of sharma bhupesh. - remove v8_outer_cache* which is not need currently. - Change license tag. - Mov crt0.S/relocate.S/interrupts.c to arm/lib and rename them with _64 suffix. - Make el3/el2 initializing process of start.S as two separate routines. It could be easier to be replaced with processor specific codes. - Remove exception stack save and restore routine, it is unnecessary now. - simplify __weak function declaration. Changes for v6: - Check the patches with checkpatch.pl and get rid of almost all warnings. There are a few warnings still, but I think it should be that. - change printf format in cmd_pxe.c, use %zd indtead of %ld to format size_t type variable. - add macro PGTABLE_SIZE to identify tlb table size. Changes for v5: - Make modification to inappropriate licensed file and bugs according to ScottWood's advice. Thanks Scott for his checking to these patches. - Enable u-boot's running at EL1. - Get rid of compiling warnings originated from cmd_pxe.c. Changes for v4: - fix the generic board_f.c, remove zero_global_data from init_sequence_f array and move it to board_init_f() function with CONFIG_X86 switch. The previous fixup is inaccurate. - Replace __ARMEB__ with __AARCH64EB__ in byteorder.h and unaligned.h, gcc for aarch64 use __AARCH64EB__ and __AARCH64EL__ to identify endian. - Some modification to README.armv8 Changes for v3: - merge arm64 to arm architecture. David Feng (5): core support of arm64 board support of vexpress_aemv8a generic board patch of manual reloc and zero gd_t 64bit initrd start address support remove compiling warnings MAINTAINERS |4 + arch/arm/config.mk |4 + arch/arm/cpu/armv8/Makefile | 38 +++ arch/arm/cpu/armv8/cache.S | 130 + arch/arm/cpu/armv8/cache_v8.c | 228 arch/arm/cpu/armv8/config.mk| 16 ++ arch/arm/cpu/armv8/cpu.c| 67 + arch/arm/cpu/armv8/exceptions.S | 115 arch/arm/cpu/armv8/start.S | 236 + arch/arm/cpu/armv8/timer.c | 80 ++ arch/arm/cpu/armv8/tlb.S| 30 +++ arch/arm/cpu/armv8/u-boot.lds | 71 + arch/arm/include/asm/arch-armv8/gpio.h | 11 + arch/arm/include/asm/arch-armv8/mmu.h | 106 arch/arm/include/asm/byteorder.h| 12 + arch/arm/include/asm/cache.h|5 + arch/arm/include/asm/config.h | 10 + arch/arm/include/asm/global_data.h |6 +- arch/arm/include/asm/io.h | 15 +- arch/arm/include/asm/macro.h| 20 ++ arch/arm/include/asm/posix_types.h | 10 + arch/arm/include/asm/proc-armv/ptrace.h | 21 ++ arch/arm/include/asm/proc-armv/system.h | 59 - arch/arm/include/asm/system.h | 77 ++ arch/arm/include/asm/types.h|4 + arch/arm/include/asm/u-boot.h |4 + arch/arm/include/asm/unaligned.h|2 +- arch/arm/lib/Makefile | 14 + arch/arm/lib/board.c| 16 +- arch/arm/lib/bootm.c| 16 ++ arch/arm/lib/crt0_64.S | 116 arch/arm/lib/interrupts_64.c| 120 + arch/arm/lib/relocate_64.S | 57 board/armltd/dts/vexpress64.dts | 439 +++ board/armltd/vexpress64/Makefile| 27 ++ board/armltd/vexpress64/vexpress64.c| 70 + boards.cfg |1 + common/board_f.c| 19 +- common/board_r.c| 18 ++ common/cmd_pxe.c|4 +- common/fdt_support.c| 66 ++--- common/image.c |1 + doc/README.armv8| 18 ++ examples/standalone/stubs.c | 15 ++ include/configs/vexpress_aemv8a.h | 193 ++ include/image.h |1 + 46 files changed, 2540 insertions(+), 52 deletions(-) create mode 100644 arch/arm/cpu/armv8/Makefile create mode 100644 arch/arm/cpu/armv8/cache.S create mode 100644 arch/arm/cpu/armv8/cache_v8.c create mode 100644 arch/arm/cpu/armv8/config.mk create mode 100644 arch/arm/cpu/armv8/cpu.c
[U-Boot] [PATCH v9 1/5] core support of arm64
From: David Feng feng...@phytium.com.cn Signed-off-by: David Feng feng...@phytium.com.cn --- arch/arm/config.mk |4 + arch/arm/cpu/armv8/Makefile | 38 + arch/arm/cpu/armv8/cache.S | 130 + arch/arm/cpu/armv8/cache_v8.c | 228 + arch/arm/cpu/armv8/config.mk| 16 +++ arch/arm/cpu/armv8/cpu.c| 67 + arch/arm/cpu/armv8/exceptions.S | 115 +++ arch/arm/cpu/armv8/start.S | 236 +++ arch/arm/cpu/armv8/timer.c | 80 +++ arch/arm/cpu/armv8/tlb.S| 30 arch/arm/cpu/armv8/u-boot.lds | 71 ++ arch/arm/include/asm/arch-armv8/gpio.h | 11 ++ arch/arm/include/asm/arch-armv8/mmu.h | 106 ++ arch/arm/include/asm/byteorder.h| 12 ++ arch/arm/include/asm/cache.h|5 + arch/arm/include/asm/config.h | 10 ++ arch/arm/include/asm/global_data.h |6 +- arch/arm/include/asm/io.h | 15 +- arch/arm/include/asm/macro.h| 20 +++ arch/arm/include/asm/posix_types.h | 10 ++ arch/arm/include/asm/proc-armv/ptrace.h | 21 +++ arch/arm/include/asm/proc-armv/system.h | 59 +++- arch/arm/include/asm/system.h | 77 ++ arch/arm/include/asm/types.h|4 + arch/arm/include/asm/u-boot.h |4 + arch/arm/include/asm/unaligned.h|2 +- arch/arm/lib/Makefile | 14 ++ arch/arm/lib/board.c| 16 ++- arch/arm/lib/bootm.c| 16 +++ arch/arm/lib/crt0_64.S | 116 +++ arch/arm/lib/interrupts_64.c| 120 arch/arm/lib/relocate_64.S | 57 common/image.c |1 + doc/README.armv8| 18 +++ examples/standalone/stubs.c | 15 ++ include/image.h |1 + 36 files changed, 1741 insertions(+), 10 deletions(-) create mode 100644 arch/arm/cpu/armv8/Makefile create mode 100644 arch/arm/cpu/armv8/cache.S create mode 100644 arch/arm/cpu/armv8/cache_v8.c create mode 100644 arch/arm/cpu/armv8/config.mk create mode 100644 arch/arm/cpu/armv8/cpu.c create mode 100644 arch/arm/cpu/armv8/exceptions.S create mode 100644 arch/arm/cpu/armv8/start.S create mode 100644 arch/arm/cpu/armv8/timer.c create mode 100644 arch/arm/cpu/armv8/tlb.S create mode 100644 arch/arm/cpu/armv8/u-boot.lds create mode 100644 arch/arm/include/asm/arch-armv8/gpio.h create mode 100644 arch/arm/include/asm/arch-armv8/mmu.h create mode 100644 arch/arm/lib/crt0_64.S create mode 100644 arch/arm/lib/interrupts_64.c create mode 100644 arch/arm/lib/relocate_64.S create mode 100644 doc/README.armv8 diff --git a/arch/arm/config.mk b/arch/arm/config.mk index ce3903b..f1c6a7b 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -74,7 +74,9 @@ endif endif # needed for relocation +ifndef CONFIG_ARMV8 LDFLAGS_u-boot += -pie +endif # # FIXME: binutils versions 2.22 have a bug in the assembler where @@ -95,6 +97,8 @@ endif endif # check that only R_ARM_RELATIVE relocations are generated +ifndef CONFIG_ARMV8 ifneq ($(CONFIG_SPL_BUILD),y) ALL-y += checkarmreloc endif +endif diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile new file mode 100644 index 000..b216f27 --- /dev/null +++ b/arch/arm/cpu/armv8/Makefile @@ -0,0 +1,38 @@ +# +# (C) Copyright 2000-2003 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(CPU).o + +START := start.o + +COBJS += cpu.o +COBJS += timer.o +COBJS += cache_v8.o + +SOBJS += exceptions.o +SOBJS += cache.o +SOBJS += tlb.o + +SRCS := $(START:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) +START := $(addprefix $(obj),$(START)) + +all: $(obj).depend $(START) $(LIB) + +$(LIB):$(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/arch/arm/cpu/armv8/cache.S b/arch/arm/cpu/armv8/cache.S new file mode 100644 index 000..419f169 --- /dev/null +++ b/arch/arm/cpu/armv8/cache.S @@ -0,0 +1,130 @@ +/* + * (C) Copyright 2013 + * David Feng feng...@phytium.com.cn + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include asm-offsets.h +#include config.h +#include version.h +#include asm/macro.h +#include linux/linkage.h + +/* + * void __asm_flush_dcache_level(level) + * + * clean and invalidate one level cache. + * + * x0: cache level + * x1~x9: clobbered + */
[U-Boot] [PATCH v9 5/5] remove compiling warnings
From: David Feng feng...@phytium.com.cn
Signed-off-by: David Feng feng...@phytium.com.cn
---
common/cmd_pxe.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
index a2fb50a..df58522 100644
--- a/common/cmd_pxe.c
+++ b/common/cmd_pxe.c
@@ -57,7 +57,7 @@ static int format_mac_pxe(char *outbuf, size_t outbuf_len)
uchar ethaddr[6];
if (outbuf_len 21) {
- printf(outbuf is too small (%d 21)\n, outbuf_len);
+ printf(outbuf is too small (%zd 21)\n, outbuf_len);
return -EINVAL;
}
@@ -100,7 +100,7 @@ static int get_bootfile_path(const char *file_path, char
*bootfile_path,
path_len = (last_slash - bootfile) + 1;
if (bootfile_path_size path_len) {
- printf(bootfile_path too small. (%d %d)\n,
+ printf(bootfile_path too small. (%zd %zd)\n,
bootfile_path_size, path_len);
return -1;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] at91: add support for CDU9G25 board
This patch adds support for our companies board CDU9G25 with Atmel AT91SAM9G25,
128MB DDR2, 256MB NAND.
Signed-off-by: Jiri Prchal jiri.prc...@aksignal.cz
---
v.2
Fixed static IP and MAC addr cofiguration by random MAC and DHCP.
Added entry to MAINTAINERS.
Fixed line lenght, trailing spaces and other cosmetics.
v.3
Removed static eth_gadget addresses.
MAC address set from serial number of F-RAM.
v.4
Changed debug to printf if used random MAC addr, print that addr.
Keep MAC addr set in enviroment.
MAINTAINERS |3 +
board/cdu9g25/Makefile| 34 +++
board/cdu9g25/cdu9g25.c | 204 ++
board/cdu9g25/config.mk |1 +
boards.cfg|1 +
include/configs/cdu9g25.h | 216 +
6 files changed, 459 insertions(+)
create mode 100644 board/cdu9g25/Makefile
create mode 100644 board/cdu9g25/cdu9g25.c
create mode 100644 board/cdu9g25/config.mk
create mode 100644 include/configs/cdu9g25.h
diff --git a/MAINTAINERS b/MAINTAINERS
index bd0f3a0..9d0008a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -851,6 +851,9 @@ Matt Porter mpor...@ti.com
ti814x_evm ARM ARMV7 (TI814x Soc)
+Jiri Prchal jiri.prc...@aksignal.cz
+ cdu9g25 ARM926EJS (AT91SAM9G25 SoC)
+
Dave Purdy david.c.pu...@gmail.com
pogo_e02ARM926EJS (Kirkwood SoC)
diff --git a/board/cdu9g25/Makefile b/board/cdu9g25/Makefile
new file mode 100644
index 000..b644a83
--- /dev/null
+++ b/board/cdu9g25/Makefile
@@ -0,0 +1,34 @@
+#
+# U-boot - Makefile
+#
+# (C) Copyright 2013
+# Jiri Prchal jiri.prc...@aksignal.cz
+# AK signal www.aksignal.cz
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS-y+= cdu9g25.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/cdu9g25/cdu9g25.c b/board/cdu9g25/cdu9g25.c
new file mode 100644
index 000..c7e78e3
--- /dev/null
+++ b/board/cdu9g25/cdu9g25.c
@@ -0,0 +1,204 @@
+/*
+ * (C) Copyright 2013
+ * Jiri Prchal jiri.prc...@aksignal.cz
+ * AK signal www.aksignal.cz
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include malloc.h
+#include asm/io.h
+#include asm/arch/at91sam9x5_matrix.h
+#include asm/arch/at91sam9_smc.h
+#include asm/arch/at91_common.h
+#include asm/arch/at91_pmc.h
+#include asm/arch/at91_rstc.h
+#include asm/arch/at91_spi.h
+#include asm/arch/gpio.h
+#include asm/arch/clk.h
+#include atmel_hlcdc.h
+#include atmel_mci.h
+#include spi.h
+#include net.h
+#include netdev.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* - */
+/*
+ * Miscelaneous platform dependent initialisations
+ */
+
+static void cdu9g25_nand_hw_init(void)
+{
+ struct at91_smc *smc = (struct at91_smc *)ATMEL_BASE_SMC;
+ struct at91_matrix *matrix = (struct at91_matrix *)ATMEL_BASE_MATRIX;
+ struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
+ unsigned long csa;
+
+ /* Enable CS3 */
+ csa = readl(matrix-ebicsa);
+ csa |= AT91_MATRIX_EBI_CS3A_SMC_SMARTMEDIA;
+ writel(csa, matrix-ebicsa);
+
+ /* Configure SMC CS3 for NAND/SmartMedia */
+ writel(AT91_SMC_SETUP_NWE(1) | AT91_SMC_SETUP_NCS_WR(0) |
+ AT91_SMC_SETUP_NRD(1) | AT91_SMC_SETUP_NCS_RD(0),
+ smc-cs[3].setup);
+ writel(AT91_SMC_PULSE_NWE(3) | AT91_SMC_PULSE_NCS_WR(5) |
+ AT91_SMC_PULSE_NRD(4) | AT91_SMC_PULSE_NCS_RD(6),
+ smc-cs[3].pulse);
+ writel(AT91_SMC_CYCLE_NWE(5) | AT91_SMC_CYCLE_NRD(6),
+ smc-cs[3].cycle);
+ writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
+ AT91_SMC_MODE_EXNW_DISABLE |
+ AT91_SMC_MODE_DBW_8 |
+ AT91_SMC_MODE_TDF_CYCLE(1),
+ smc-cs[3].mode);
+
+ writel(1 ATMEL_ID_PIOCD, pmc-pcer);
+
+ /* Configure RDY/BSY */
+ at91_set_gpio_input(CONFIG_SYS_NAND_READY_PIN, 1);
+
+ /* Enable NandFlash */
+ at91_set_gpio_output(CONFIG_SYS_NAND_ENABLE_PIN, 1);
+
+ at91_set_a_periph(AT91_PIO_PORTD, 0, 1);/* NAND OE */
+ at91_set_a_periph(AT91_PIO_PORTD, 1, 1);/* NAND WE */
+ at91_set_a_periph(AT91_PIO_PORTD, 2, 1);/* NAND ALE */
+ at91_set_a_periph(AT91_PIO_PORTD, 3, 1);/* NAND CLE */
+}
+
+int spi_cs_is_valid(unsigned int bus, unsigned int cs)
[U-Boot] [PATCH] boards.cfg: show info about boards.cfg instead of MAINTAINERS
Signed-off-by: Roger Meier ro...@bufferoverflow.ch
---
tools/checkpatch.pl |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/checkpatch.pl b/tools/checkpatch.pl
index 896e2bc..88c5bc7 100755
--- a/tools/checkpatch.pl
+++ b/tools/checkpatch.pl
@@ -398,7 +398,7 @@ sub top_of_kernel_tree {
my ($root) = @_;
my @tree_check = (
- COPYING, CREDITS, Kbuild, MAINTAINERS, Makefile,
+ COPYING, CREDITS, Kbuild, Makefile,
README, Documentation, arch, include, drivers,
fs, init, ipc, kernel, lib, scripts,
);
@@ -3701,7 +3701,7 @@ sub process {
$vname has style problems, please review.
If any of these errors are false positives, please report
-them to the maintainer, see CHECKPATCH in MAINTAINERS.
+them to the maintainer, see boards.cfg.
EOM
}
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] powerpc SPL framework: Avoiding relocate_code
On 09/12/2013 11:28 PM, Scott Wood wrote:
On Mon, 2013-09-09 at 16:43 +0530, Prabhakar Kushwaha wrote:
Hi,
SPL framework is used to support multi-stage booting. Where first
level boot loader is created via SPL having relocate_code() function.
I am working on a Freescale's SoC which has less internal SRAM.
I don't want to use relocate_code() as to support this function, I need
to reduce SPL bin to SRAM/2 size.
is there way to avoid relocate_code function ?
I tried with below sequence, but it is not working for me :(
.globlrelocate_code
relocate_code:
mrr1,r3/* Set new stack pointer*/
mrr9,r4/* Save copy of Init Data pointer*/
mrr10,r5/* Save copy of Destination Address*/
GET_GOT
#ifndef CONFIG_SPL_BUILD
--
--
#endif
.globlin_ram
in_ram:
Well, you certainly don't want to disable it for all SPLs...
it should be disabled for those SPL which relocate itself in SRAM, for
other no
The reason is bss variables which are mapped to 0x_ onwards
because bsssection are mapped after 0xfffc in lds. They are not
available during SPL execution. is there way to relocate bss section in
the execution range of SPL?
Are you talking about a scenario in which the SPL is loaded into SRAM
rather than (e.g.) the NAND buffer? In that case, why is U-Boot not
linked at the actual SRAM address? No copy should be needed in that
case, and the BSS will not be at zero.
I am linking SPL with the address of SRAM as I want resetvec at
0xfffc but still I am finding bss at 0x0
in u-boot-spl.lds we have :-
#ifdef CONFIG_SYS_MPC85XX_NO_RESETVEC
.bootpg ADDR(.text) - 0x1000 :
{
KEEP(*(.bootpg))
} :text = 0x
#else
.resetvec ADDR(.text) + RESET_VECTOR_OFFSET : {
KEEP(*(.resetvec))
} = 0x
#endif
/*
* Make sure that the bss segment isn't linked at 0x0, otherwise its
* address won't be updated during relocation fixups.
*/
. |= 0x10;
. = ALIGN(4);
__bss_start = .;
.bss : {
*(.sbss*)
*(.bss*)
}
. = ALIGN(4);
__bss_end = .;
from above lds, we put resetvec at 0xfffc And place BSS just after
it. Hence at 0x0.
Ideally __bss_start should not be put after 0xfffc as it is making
relocation a requirement.
Regards,
Prabhakar
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] dfu: ram support
Hi Afzal, DFU spec mentions it as a method to upgrade firmware (software stored in writable non-volatile memory). It also says other potential uses of DFU is beyond scope of the spec. Here such a beyond the scope use is being attempted - directly pumping binary images from host via USB to RAM. This facility is a developer centric one in that it gives advantage over upgrading non-volatile memory for testing new images every time during development and/or testing. Directly putting image onto RAM would speed up upgrade process. This and convenience was the initial thoughts that led to doing this, speed improvement over MMC was only 1 second though - 6 sec on RAM as opposed to 7 sec on MMC in beagle bone, perhaps enabling cache and/or optimizing DFU framework to avoid multiple copy for ram (if worth) may help, and on other platforms and other boot media like NAND maybe improvement would be higher. And for a platform that doesn't yet have proper DFU suppport for non-volatile media's, DFU to RAM can be used. Another minor advantage would be to increase life of mmc/nand as it would be less used during development/testing. usage: image name ram start address size eg. kernel ram 0x8100 0x100 Downloading images to RAM using DFU is not something new, this is acheived in openmoko also. DFU on RAM can be used for extracting RAM contents to host using dfu upload. Perhaps this can be extended to io for squeezing out register dump through usb, if it is worth. Signed-off-by: Afzal Mohammed afzal.mohd...@gmail.com Cc: Marek Vasut ma...@denx.de Cc: Lukasz Majewski l.majew...@samsung.com Cc: Pantelis Antoniou pa...@antoniou-consulting.com --- v3: error used instead of printf v2: remove read/write enumerator define's, instead use new common ones Acked-by: Lukasz Majewski l.majew...@samsung.com -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RFC] usb: Prevent using reserved registers on DM36x usb
The musb driver defines and uses MUSB_CSR0_H_DIS_PING, however this
bit is reserved on the DM36x. Thus this patch ensures that the
reserved bit is not accesssed.
It has been observed that some USB devices will fail to enumerate
with errors such as 'error in inquiry' without this patch.
See http://www.ti.com/litv/pdf/sprufh9a for details.
Cc: Marek Vasut ma...@denx.de
Cc: Tom Rini tr...@ti.com
Signed-off-by: Andrew Murray amur...@embedded-bits.co.uk
---
drivers/usb/musb/musb_core.h |4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index ec8a038..c9a9d66 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -216,7 +216,11 @@ struct musb_regs {
#define MUSB_CSR0_P_SENTSTALL 0x0004
/* CSR0 in Host mode */
+#if defined(CONFIG_SOC_DM365)
+#define MUSB_CSR0_H_DIS_PING 0x
+#else
#define MUSB_CSR0_H_DIS_PING 0x0800
+#endif
#define MUSB_CSR0_H_WR_DATATOGGLE 0x0400 /* Set to allow setting: */
#define MUSB_CSR0_H_DATATOGGLE 0x0200 /* Data toggle control */
#define MUSB_CSR0_H_NAKTIMEOUT 0x0080
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] at91: add support for CDU9G25 board
Hi Jiri Prchal,
Quickly go through the code, please take the following comments as a
reference.
Add Andreas in loop.
On 9/13/2013 17:00, Jiri Prchal wrote:
This patch adds support for our companies board CDU9G25 with Atmel AT91SAM9G25,
128MB DDR2, 256MB NAND.
Signed-off-by: Jiri Prchal jiri.prc...@aksignal.cz
---
v.2
Fixed static IP and MAC addr cofiguration by random MAC and DHCP.
Added entry to MAINTAINERS.
Fixed line lenght, trailing spaces and other cosmetics.
v.3
Removed static eth_gadget addresses.
MAC address set from serial number of F-RAM.
v.4
Changed debug to printf if used random MAC addr, print that addr.
Keep MAC addr set in enviroment.
MAINTAINERS |3 +
board/cdu9g25/Makefile| 34 +++
board/cdu9g25/cdu9g25.c | 204 ++
board/cdu9g25/config.mk |1 +
boards.cfg|1 +
include/configs/cdu9g25.h | 216 +
6 files changed, 459 insertions(+)
create mode 100644 board/cdu9g25/Makefile
create mode 100644 board/cdu9g25/cdu9g25.c
create mode 100644 board/cdu9g25/config.mk
create mode 100644 include/configs/cdu9g25.h
diff --git a/MAINTAINERS b/MAINTAINERS
index bd0f3a0..9d0008a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -851,6 +851,9 @@ Matt Porter mpor...@ti.com
ti814x_evm ARM ARMV7 (TI814x Soc)
+Jiri Prchal jiri.prc...@aksignal.cz
+ cdu9g25 ARM926EJS (AT91SAM9G25 SoC)
+
Dave Purdy david.c.pu...@gmail.com
pogo_e02ARM926EJS (Kirkwood SoC)
Consider to rebase to u-boot master branch, as the MAINTAINERS file is
merged into boards.cfg file
diff --git a/board/cdu9g25/Makefile b/board/cdu9g25/Makefile
new file mode 100644
index 000..b644a83
--- /dev/null
+++ b/board/cdu9g25/Makefile
@@ -0,0 +1,34 @@
+#
+# U-boot - Makefile
+#
+# (C) Copyright 2013
+# Jiri Prchal jiri.prc...@aksignal.cz
+# AK signal www.aksignal.cz
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS-y+= cdu9g25.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/cdu9g25/cdu9g25.c b/board/cdu9g25/cdu9g25.c
new file mode 100644
index 000..c7e78e3
--- /dev/null
+++ b/board/cdu9g25/cdu9g25.c
@@ -0,0 +1,204 @@
+/*
+ * (C) Copyright 2013
+ * Jiri Prchal jiri.prc...@aksignal.cz
+ * AK signal www.aksignal.cz
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include malloc.h
+#include asm/io.h
+#include asm/arch/at91sam9x5_matrix.h
+#include asm/arch/at91sam9_smc.h
+#include asm/arch/at91_common.h
+#include asm/arch/at91_pmc.h
+#include asm/arch/at91_rstc.h
+#include asm/arch/at91_spi.h
+#include asm/arch/gpio.h
+#include asm/arch/clk.h
+#include atmel_hlcdc.h
+#include atmel_mci.h
+#include spi.h
+#include net.h
+#include netdev.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* - */
+/*
+ * Miscelaneous platform dependent initialisations
+ */
I think this is no meaning to put this comment here.
+static void cdu9g25_nand_hw_init(void)
+{
+ struct at91_smc *smc = (struct at91_smc *)ATMEL_BASE_SMC;
+ struct at91_matrix *matrix = (struct at91_matrix *)ATMEL_BASE_MATRIX;
+ struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
+ unsigned long csa;
+
+ /* Enable CS3 */
+ csa = readl(matrix-ebicsa);
+ csa |= AT91_MATRIX_EBI_CS3A_SMC_SMARTMEDIA;
+ writel(csa, matrix-ebicsa);
+
+ /* Configure SMC CS3 for NAND/SmartMedia */
+ writel(AT91_SMC_SETUP_NWE(1) | AT91_SMC_SETUP_NCS_WR(0) |
+ AT91_SMC_SETUP_NRD(1) | AT91_SMC_SETUP_NCS_RD(0),
+ smc-cs[3].setup);
+ writel(AT91_SMC_PULSE_NWE(3) | AT91_SMC_PULSE_NCS_WR(5) |
+ AT91_SMC_PULSE_NRD(4) | AT91_SMC_PULSE_NCS_RD(6),
+ smc-cs[3].pulse);
+ writel(AT91_SMC_CYCLE_NWE(5) | AT91_SMC_CYCLE_NRD(6),
+ smc-cs[3].cycle);
+ writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
+ AT91_SMC_MODE_EXNW_DISABLE |
+ AT91_SMC_MODE_DBW_8 |
+ AT91_SMC_MODE_TDF_CYCLE(1),
+ smc-cs[3].mode);
+
+ writel(1 ATMEL_ID_PIOCD, pmc-pcer);
+
+ /* Configure RDY/BSY */
+ at91_set_gpio_input(CONFIG_SYS_NAND_READY_PIN, 1);
+
+ /* Enable NandFlash */
+ at91_set_gpio_output(CONFIG_SYS_NAND_ENABLE_PIN, 1);
+
+
Re: [U-Boot] [PATCH v9 2/5] board support of vexpress_aemv8a
Hi David, -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of feng...@phytium.com.cn Sent: Friday, September 13, 2013 2:09 PM To: u-boot@lists.denx.de Cc: tr...@ti.com; David Feng; Wood Scott-B07421 Subject: [U-Boot] [PATCH v9 2/5] board support of vexpress_aemv8a From: David Feng feng...@phytium.com.cn Signed-off-by: David Feng feng...@phytium.com.cn and Sharma Bhupesh b45...@freescale.com --- I would prefer that you add the S-o-b's in the following way (suggested in submitting patch guidelines) and also correct my S-o-b: Signed-off-by: David Feng feng...@phytium.com.cn Signed-off-by: Bhupesh Sharma bhupesh.sha...@freescale.com [snip..] Regards, Bhupesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
On 2013-09-12 21:37, Fabio Estevam wrote: On Thu, Sep 12, 2013 at 3:53 PM, Wolfgang Denk w...@denx.de wrote: Dear Fabio Estevam, In message caomzo5by6kdocown_srwhpe7ssmjarez2bcfxggff-_wrdg...@mail.gmail.com you wrote: It makes perfect sense to allocate variable with function scope only on the stack. That's what the stack has been invented for. This buffer in the fec driver will be used in DMA transfer, so maybe that's the reason we should use malloc instead of using the stack? What has DMA to do with that? We're talking about alignment only. I mentioned DMA because we align the buffer with __aligned(ARCH_DMA_MINALIGN). Will try to see if I can reproduce the problem here, but the last time I tried I was not able to. Maybe the gcc version that Robert and Hector pointed out may explain the different behaviour. Regards, Fabio Estevam Ok. Then what about if I would use the stack, but align the buffer manually. From: Robert Hodaszi robert.hoda...@digi.com Date: Fri, 13 Sep 2013 13:07:52 +0200 Subject: [PATCH] net: fec: fix invalid temporary RX buffer alignment because of GCC bug Older GCC versions don't handle well alignment on stack variables. The temporary RX buffer is a local variable, so it is on the stack. Because the FEC driver is using DMA for transmission, receive and transmit buffers should be align on 64 byte. The transmit buffers are not allocated in the driver internally, it sends the packets directly as it gets them. So these packets should be aligned. When the ARP layer wants to reply to an ARP request, it uses the FEC driver's temporary RX buffer (used to pass data to the ARP layer) to store the new packet, and pass it back to the FEC driver's send function. Because of a GCC bug, this buffer is not aligned well, and when the driver tries to send it, it first rounds the address down to the alignment boundary. That causes invalid data. To fix it, allocate more space on the stack, and align the buffer manually. Signed-off-by: Robert Hodaszi robert.hoda...@digi.com --- drivers/net/fec_mxc.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index f4f72b7..09d816d 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -828,7 +828,9 @@ static int fec_recv(struct eth_device *dev) uint16_t bd_status; uint32_t addr, size, end; int i; - uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN); + /* Align the receive buffer */ + uchar buff_unaligned[FEC_MAX_PKT_SIZE + (ARCH_DMA_MINALIGN - 1)]; + uchar *buff = ((uint32_t)buff_unaligned + (ARCH_DMA_MINALIGN - 1)) ~(ARCH_DMA_MINALIGN - 1); /* * Check if any critical events have happened Best regards, Robert Hodaszi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
On 2013-09-13 13:11, Robert Hodaszi wrote: On 2013-09-12 21:37, Fabio Estevam wrote: On Thu, Sep 12, 2013 at 3:53 PM, Wolfgang Denk w...@denx.de wrote: Dear Fabio Estevam, In message caomzo5by6kdocown_srwhpe7ssmjarez2bcfxggff-_wrdg...@mail.gmail.com you wrote: It makes perfect sense to allocate variable with function scope only on the stack. That's what the stack has been invented for. This buffer in the fec driver will be used in DMA transfer, so maybe that's the reason we should use malloc instead of using the stack? What has DMA to do with that? We're talking about alignment only. I mentioned DMA because we align the buffer with __aligned(ARCH_DMA_MINALIGN). Will try to see if I can reproduce the problem here, but the last time I tried I was not able to. Maybe the gcc version that Robert and Hector pointed out may explain the different behaviour. Regards, Fabio Estevam Ok. Then what about if I would use the stack, but align the buffer manually. From: Robert Hodaszi robert.hoda...@digi.com Date: Fri, 13 Sep 2013 13:07:52 +0200 Subject: [PATCH] net: fec: fix invalid temporary RX buffer alignment because of GCC bug Older GCC versions don't handle well alignment on stack variables. The temporary RX buffer is a local variable, so it is on the stack. Because the FEC driver is using DMA for transmission, receive and transmit buffers should be align on 64 byte. The transmit buffers are not allocated in the driver internally, it sends the packets directly as it gets them. So these packets should be aligned. When the ARP layer wants to reply to an ARP request, it uses the FEC driver's temporary RX buffer (used to pass data to the ARP layer) to store the new packet, and pass it back to the FEC driver's send function. Because of a GCC bug, this buffer is not aligned well, and when the driver tries to send it, it first rounds the address down to the alignment boundary. That causes invalid data. To fix it, allocate more space on the stack, and align the buffer manually. Signed-off-by: Robert Hodaszi robert.hoda...@digi.com --- drivers/net/fec_mxc.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index f4f72b7..09d816d 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -828,7 +828,9 @@ static int fec_recv(struct eth_device *dev) uint16_t bd_status; uint32_t addr, size, end; int i; - uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN); + /* Align the receive buffer */ + uchar buff_unaligned[FEC_MAX_PKT_SIZE + (ARCH_DMA_MINALIGN - 1)]; + uchar *buff = ((uint32_t)buff_unaligned + (ARCH_DMA_MINALIGN - 1)) ~(ARCH_DMA_MINALIGN - 1); /* * Check if any critical events have happened Best regards, Robert Hodaszi I think, I sent it again in HTML format... Sorry... Best regards, Robert Hodaszi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cosmetic: doc: uImage.FIT: fix typos
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- doc/uImage.FIT/command_syntax_extensions.txt | 2 +- doc/uImage.FIT/source_file_format.txt| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/uImage.FIT/command_syntax_extensions.txt b/doc/uImage.FIT/command_syntax_extensions.txt index 002818c..6c99b1c 100644 --- a/doc/uImage.FIT/command_syntax_extensions.txt +++ b/doc/uImage.FIT/command_syntax_extensions.txt @@ -170,7 +170,7 @@ bootm 20 In case of the new uImage argument syntax, the address portion of any argument can be omitted. If addr3 is omitted, then it is assumed that image at -addr2 should be used. Similarly, when addr2 is omitted, is is assumed that +addr2 should be used. Similarly, when addr2 is omitted, it is assumed that image at addr1 should be used. If addr1 is omitted, it is assumed that the current image address is to be used. For example, consider the following commands: diff --git a/doc/uImage.FIT/source_file_format.txt b/doc/uImage.FIT/source_file_format.txt index 6d20707..160b2d0 100644 --- a/doc/uImage.FIT/source_file_format.txt +++ b/doc/uImage.FIT/source_file_format.txt @@ -62,7 +62,7 @@ c) Image building procedure The following picture shows how the new uImage is prepared. Input consists of image source file (.its) and a set of data files. Image is created with the help of standard U-boot mkimage tool which in turn uses dtc (device tree -compiler) to produce image tree blob (.itb). Resulting .itb file is is the +compiler) to produce image tree blob (.itb). Resulting .itb file is the actual binary of a new uImage. -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc:sdhci: Fix card ready status timeout.
Dear Pantelis, On 09/09/2013 02:58 PM, Przemyslaw Marczak wrote: According to JEDEC eMMC specification, after data transfer (multiple or single block) host must wait for card ready status. This is done by waiting for command and data lines to be at idle state after transfer. JEDEC does not specify maximum timeout. Before this change max timeout was 10 ms but in case of UMS - when system does multiple read/write operations on random card blocks - timeout causes I/O errors. The timeout has been increased to 200ms after data transfer. For other transfers it stays unchanged. Default values are now defined with if defined directive so it can be redefined at board config if needed. Tested on Goni and Trats. Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com Cc: Pantelis Antoniou pa...@antoniou-consulting.com Please do not apply this patch yet due to still not enough results on some targets. Timeout value should depends on internal cards operations execution time but this time is unpredictably and that is why JEDEC not specifies it. Maybe u-boot sdhci driver needs some more changes to be more flexible for such operations. In example sdhci background operations timeout at kernel is specified to 4 minutes. I need to make more research. Regards, -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5] at91: add support for CDU9G25 board
This patch adds support for our companies board CDU9G25 with Atmel AT91SAM9G25,
128MB DDR2, 256MB NAND.
Signed-off-by: Jiri Prchal jiri.prc...@aksignal.cz
---
v.2
Fixed static IP and MAC addr cofiguration by random MAC and DHCP.
Added entry to MAINTAINERS.
Fixed line lenght, trailing spaces and other cosmetics.
v.3
Removed static eth_gadget addresses.
MAC address set from serial number of F-RAM.
v.4
Changed debug to printf if used random MAC addr, print that addr.
Keep MAC addr set in enviroment.
v.5
Changes to Bo Shen comments.
Signed-off-by: Jiri Prchal jiri.prc...@aksignal.cz
---
arch/arm/include/asm/mach-types.h |1 +
board/AKsignal/cdu9g25/Makefile | 34 ++
board/AKsignal/cdu9g25/cdu9g25.c | 202 +++
boards.cfg|1 +
include/configs/cdu9g25.h | 210 +
5 files changed, 448 insertions(+)
create mode 100644 board/AKsignal/cdu9g25/Makefile
create mode 100644 board/AKsignal/cdu9g25/cdu9g25.c
create mode 100644 include/configs/cdu9g25.h
diff --git a/arch/arm/include/asm/mach-types.h
b/arch/arm/include/asm/mach-types.h
index 440b041..9b274ba 100644
--- a/arch/arm/include/asm/mach-types.h
+++ b/arch/arm/include/asm/mach-types.h
@@ -986,6 +986,7 @@ extern unsigned int __machine_arch_type;
#define MACH_TYPE_VIT_IBOX 3371
#define MACH_TYPE_DM6441_ESP 3372
#define MACH_TYPE_AT91SAM9X5EK 3373
+#define MACH_TYPE_CDU9G25 3373
#define MACH_TYPE_LIBRA3374
#define MACH_TYPE_EASYCRRH 3375
#define MACH_TYPE_TRIPEL 3376
diff --git a/board/AKsignal/cdu9g25/Makefile b/board/AKsignal/cdu9g25/Makefile
new file mode 100644
index 000..b644a83
--- /dev/null
+++ b/board/AKsignal/cdu9g25/Makefile
@@ -0,0 +1,34 @@
+#
+# U-boot - Makefile
+#
+# (C) Copyright 2013
+# Jiri Prchal jiri.prc...@aksignal.cz
+# AK signal www.aksignal.cz
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS-y+= cdu9g25.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/AKsignal/cdu9g25/cdu9g25.c b/board/AKsignal/cdu9g25/cdu9g25.c
new file mode 100644
index 000..7321a02
--- /dev/null
+++ b/board/AKsignal/cdu9g25/cdu9g25.c
@@ -0,0 +1,202 @@
+/*
+ * (C) Copyright 2013
+ * Jiri Prchal jiri.prc...@aksignal.cz
+ * AK signal www.aksignal.cz
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include malloc.h
+#include asm/io.h
+#include asm/arch/at91sam9x5_matrix.h
+#include asm/arch/at91sam9_smc.h
+#include asm/arch/at91_common.h
+#include asm/arch/at91_pmc.h
+#include asm/arch/at91_rstc.h
+#include asm/arch/at91_spi.h
+#include asm/arch/gpio.h
+#include asm/arch/clk.h
+#include atmel_hlcdc.h
+#include atmel_mci.h
+#include spi.h
+#include net.h
+#include netdev.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static void cdu9g25_nand_hw_init(void)
+{
+ struct at91_smc *smc = (struct at91_smc *)ATMEL_BASE_SMC;
+ struct at91_matrix *matrix = (struct at91_matrix *)ATMEL_BASE_MATRIX;
+ struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
+ unsigned long csa;
+
+ /* Enable CS3 */
+ csa = readl(matrix-ebicsa);
+ csa |= AT91_MATRIX_EBI_CS3A_SMC_SMARTMEDIA;
+ writel(csa, matrix-ebicsa);
+
+ /* Configure SMC CS3 for NAND/SmartMedia */
+ writel(AT91_SMC_SETUP_NWE(1) | AT91_SMC_SETUP_NCS_WR(0) |
+ AT91_SMC_SETUP_NRD(1) | AT91_SMC_SETUP_NCS_RD(0),
+ smc-cs[3].setup);
+ writel(AT91_SMC_PULSE_NWE(3) | AT91_SMC_PULSE_NCS_WR(5) |
+ AT91_SMC_PULSE_NRD(4) | AT91_SMC_PULSE_NCS_RD(6),
+ smc-cs[3].pulse);
+ writel(AT91_SMC_CYCLE_NWE(5) | AT91_SMC_CYCLE_NRD(6),
+ smc-cs[3].cycle);
+ writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
+ AT91_SMC_MODE_EXNW_DISABLE |
+ AT91_SMC_MODE_DBW_8 |
+ AT91_SMC_MODE_TDF_CYCLE(1),
+ smc-cs[3].mode);
+
+ writel(1 ATMEL_ID_PIOCD, pmc-pcer);
+
+ /* Configure RDY/BSY */
+ at91_set_gpio_input(CONFIG_SYS_NAND_READY_PIN, 1);
+
+ /* Enable NandFlash */
+ at91_set_gpio_output(CONFIG_SYS_NAND_ENABLE_PIN, 1);
+
+ at91_set_a_periph(AT91_PIO_PORTD, 0, 1);/* NAND OE */
+ at91_set_a_periph(AT91_PIO_PORTD, 1, 1);/* NAND WE */
+ at91_set_a_periph(AT91_PIO_PORTD, 2, 1);/*
Re: [U-Boot] [PATCH v2 1/2] mx6sabresd: Avoid hang when HDMI cable is not connected
Hi Stefano, On Fri, Sep 13, 2013 at 5:16 AM, Stefano Babic sba...@denx.de wrote: Hi Eric, On 12/09/2013 17:02, Eric Nelson wrote: This isn't needed yet in the stock (main-line) code base, since we haven't added any panels without detection. ok, thanks - I will then apply Fabio's patches for the Freescale's boards. Cool, thanks. I admit that using DT also for u-boot seems a better solution. You're right about i.MX6 in kernel, but on the other hand I like how it is described for i.MX28 boards. The display-timings node contain all information we need. It would be nice to have the same for i.MX6. We currently have the same in DT for mx6 as well. Check this commit, for example: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/imx6q-sabrelite.dts?id=722cfacd2e719b6447fb4bd5cd3372725876336d Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Dear Robert Hodaszi, On 2013-09-13 13:11, Robert Hodaszi wrote: On 2013-09-12 21:37, Fabio Estevam wrote: On Thu, Sep 12, 2013 at 3:53 PM, Wolfgang Denk w...@denx.de wrote: Dear Fabio Estevam, In message caomzo5by6kdocown_srwhpe7ssmjarez2bcfxggff-_wrdg...@mail.gmail.com you wrote: It makes perfect sense to allocate variable with function scope only on the stack. That's what the stack has been invented for. This buffer in the fec driver will be used in DMA transfer, so maybe that's the reason we should use malloc instead of using the stack? What has DMA to do with that? We're talking about alignment only. I mentioned DMA because we align the buffer with __aligned(ARCH_DMA_MINALIGN). Will try to see if I can reproduce the problem here, but the last time I tried I was not able to. Maybe the gcc version that Robert and Hector pointed out may explain the different behaviour. Regards, Fabio Estevam Ok. Then what about if I would use the stack, but align the buffer manually. From: Robert Hodaszi robert.hoda...@digi.com Date: Fri, 13 Sep 2013 13:07:52 +0200 Subject: [PATCH] net: fec: fix invalid temporary RX buffer alignment because of GCC bug Older GCC versions don't handle well alignment on stack variables. The temporary RX buffer is a local variable, so it is on the stack. Because the FEC driver is using DMA for transmission, receive and transmit buffers should be align on 64 byte. The transmit buffers are not allocated in the driver internally, it sends the packets directly as it gets them. So these packets should be aligned. When the ARP layer wants to reply to an ARP request, it uses the FEC driver's temporary RX buffer (used to pass data to the ARP layer) to store the new packet, and pass it back to the FEC driver's send function. Because of a GCC bug, this buffer is not aligned well, and when the driver tries to send it, it first rounds the address down to the alignment boundary. That causes invalid data. To fix it, allocate more space on the stack, and align the buffer manually. Signed-off-by: Robert Hodaszi robert.hoda...@digi.com --- drivers/net/fec_mxc.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index f4f72b7..09d816d 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -828,7 +828,9 @@ static int fec_recv(struct eth_device *dev) uint16_t bd_status; uint32_t addr, size, end; int i; - uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN); + /* Align the receive buffer */ + uchar buff_unaligned[FEC_MAX_PKT_SIZE + (ARCH_DMA_MINALIGN - 1)]; + uchar *buff = ((uint32_t)buff_unaligned + (ARCH_DMA_MINALIGN - 1)) ~(ARCH_DMA_MINALIGN - 1); /* * Check if any critical events have happened Best regards, Robert Hodaszi I think, I sent it again in HTML format... Sorry... OK, but as Wolfgang already pointed out, can you tell use what compiler exposes this behavior and show us the details WD requested please ? 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 2/3] dfu: ram support
Dear Afzal Mohammed,
[...]
+int dfu_fill_entity_ram(struct dfu_entity *dfu, char *s)
+{
+ char *st;
+
+ dfu-dev_type = DFU_DEV_RAM;
+ st = strsep(s, );
+ if (strcmp(st, ram)) {
+ error(unsupported device: %s\n, st);
+ return -ENODEV;
+ }
+
+ dfu-layout = DFU_RAM_ADDR;
+ dfu-data.ram.start = (void *)simple_strtoul(s, s, 16);
+ dfu-data.ram.size = simple_strtoul(++s, s, 16);
This ++s, s is quite crazy ;-)
Otheriwse
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] [PATCH v3 0/3] dfu: ram support
Dear Afzal Mohammed, Hi, DFU spec mentions it as a method to upgrade firmware (software stored in writable non-volatile memory). It also says other potential uses of DFU is beyond scope of the spec. Here such a beyond the scope use is being attempted - directly pumping binary images from host via USB to RAM. This facility is a developer centric one in that it gives advantage over upgrading non-volatile memory for testing new images every time during development and/or testing. Directly putting image onto RAM would speed up upgrade process. This and convenience was the initial thoughts that led to doing this, speed improvement over MMC was only 1 second though - 6 sec on RAM as opposed to 7 sec on MMC in beagle bone, perhaps enabling cache and/or optimizing DFU framework to avoid multiple copy for ram (if worth) may help, and on other platforms and other boot media like NAND maybe improvement would be higher. And for a platform that doesn't yet have proper DFU suppport for non-volatile media's, DFU to RAM can be used. Another minor advantage would be to increase life of mmc/nand as it would be less used during development/testing. usage: image name ram start address size eg. kernel ram 0x8100 0x100 Downloading images to RAM using DFU is not something new, this is acheived in openmoko also. DFU on RAM can be used for extracting RAM contents to host using dfu upload. Perhaps this can be extended to io for squeezing out register In addition to ram support, a minor unification of dfu read/write enum's currently duplicated in mmc/nand is done, helping ram support too. Also dfu ram support is added for am335x SoC based boards. Based on: usb master branch CCing Heiko, can you please ACK/NAK ? 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 RFC] usb: Prevent using reserved registers on DM36x usb
Dear Andrew Murray,
The musb driver defines and uses MUSB_CSR0_H_DIS_PING, however this
bit is reserved on the DM36x. Thus this patch ensures that the
reserved bit is not accesssed.
It has been observed that some USB devices will fail to enumerate
with errors such as 'error in inquiry' without this patch.
See http://www.ti.com/litv/pdf/sprufh9a for details.
Cc: Marek Vasut ma...@denx.de
Cc: Tom Rini tr...@ti.com
Signed-off-by: Andrew Murray amur...@embedded-bits.co.uk
---
drivers/usb/musb/musb_core.h |4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index ec8a038..c9a9d66 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -216,7 +216,11 @@ struct musb_regs {
#define MUSB_CSR0_P_SENTSTALL0x0004
/* CSR0 in Host mode */
+#if defined(CONFIG_SOC_DM365)
+#define MUSB_CSR0_H_DIS_PING 0x
+#else
#define MUSB_CSR0_H_DIS_PING 0x0800
+#endif
#define MUSB_CSR0_H_WR_DATATOGGLE0x0400 /* Set to allow setting: */
#define MUSB_CSR0_H_DATATOGGLE 0x0200 /* Data toggle control
*/
#define MUSB_CSR0_H_NAKTIMEOUT 0x0080
It would be much nicer if you avoided using this bit in musb_hcd.c instead of
hacking it like 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 1/3] dfu: unify mmc/nand read/write ops enum
Dear Afzal Mohammed, MMC and NAND independently defines same enumerators for read/write. Unify them by defining enum in dfu header. RAM support that is being added newly also can make use of it. Signed-off-by: Afzal Mohammed afzal.mohd...@gmail.com Cc: Marek Vasut ma...@denx.de Cc: Lukasz Majewski l.majew...@samsung.com Cc: Pantelis Antoniou pa...@antoniou-consulting.com Acked-by: Lukasz Majewski l.majew...@samsung.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] [PATCH v5] at91: add support for CDU9G25 board
Dear Jiri Prchal,
On 09/13/2013 03:00 PM, Jiri Prchal wrote:
This patch adds support for our companies board CDU9G25 with Atmel
AT91SAM9G25, 128MB DDR2, 256MB NAND.
Signed-off-by: Jiri Prchal jiri.prc...@aksignal.cz
---
v.2
Fixed static IP and MAC addr cofiguration by random MAC and DHCP.
Added entry to MAINTAINERS.
Fixed line lenght, trailing spaces and other cosmetics.
v.3
Removed static eth_gadget addresses.
MAC address set from serial number of F-RAM.
v.4
Changed debug to printf if used random MAC addr, print that addr.
Keep MAC addr set in enviroment.
v.5
Changes to Bo Shen comments.
Signed-off-by: Jiri Prchal jiri.prc...@aksignal.cz
---
arch/arm/include/asm/mach-types.h |1 +
board/AKsignal/cdu9g25/Makefile | 34 ++
board/AKsignal/cdu9g25/cdu9g25.c | 202 +++
boards.cfg|1 +
include/configs/cdu9g25.h | 210
+
5 files changed, 448 insertions(+)
create mode 100644 board/AKsignal/cdu9g25/Makefile
create mode 100644 board/AKsignal/cdu9g25/cdu9g25.c
create mode 100644 include/configs/cdu9g25.h
diff --git a/arch/arm/include/asm/mach-types.h
b/arch/arm/include/asm/mach-types.h
index 440b041..9b274ba 100644
--- a/arch/arm/include/asm/mach-types.h
+++ b/arch/arm/include/asm/mach-types.h
@@ -986,6 +986,7 @@ extern unsigned int __machine_arch_type;
#define MACH_TYPE_VIT_IBOX 3371
#define MACH_TYPE_DM6441_ESP 3372
#define MACH_TYPE_AT91SAM9X5EK 3373
+#define MACH_TYPE_CDU9G25 3373
NAK, please obtain a mach type:
http://www.arm.linux.org.uk/developer/machines/?action=new
#define MACH_TYPE_LIBRA3374
#define MACH_TYPE_EASYCRRH 3375
#define MACH_TYPE_TRIPEL 3376
diff --git a/board/AKsignal/cdu9g25/Makefile b/board/AKsignal/cdu9g25/Makefile
new file mode 100644
index 000..b644a83
--- /dev/null
+++ b/board/AKsignal/cdu9g25/Makefile
@@ -0,0 +1,34 @@
+#
+# U-boot - Makefile
+#
+# (C) Copyright 2013
+# Jiri Prchal jiri.prc...@aksignal.cz
+# AK signal www.aksignal.cz
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+include $(TOPDIR)/config.mk
+
+LIB = $(obj)lib$(BOARD).o
+
+COBJS-y += cdu9g25.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+SOBJS:= $(addprefix $(obj),$(SOBJS))
+
+$(LIB): $(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/AKsignal/cdu9g25/cdu9g25.c
b/board/AKsignal/cdu9g25/cdu9g25.c
new file mode 100644
index 000..7321a02
--- /dev/null
+++ b/board/AKsignal/cdu9g25/cdu9g25.c
@@ -0,0 +1,202 @@
+/*
+ * (C) Copyright 2013
+ * Jiri Prchal jiri.prc...@aksignal.cz
+ * AK signal www.aksignal.cz
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include malloc.h
+#include asm/io.h
+#include asm/arch/at91sam9x5_matrix.h
+#include asm/arch/at91sam9_smc.h
+#include asm/arch/at91_common.h
+#include asm/arch/at91_pmc.h
+#include asm/arch/at91_rstc.h
+#include asm/arch/at91_spi.h
+#include asm/arch/gpio.h
+#include asm/arch/clk.h
+#include atmel_hlcdc.h
+#include atmel_mci.h
+#include spi.h
+#include net.h
+#include netdev.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static void cdu9g25_nand_hw_init(void)
+{
+ struct at91_smc *smc = (struct at91_smc *)ATMEL_BASE_SMC;
+ struct at91_matrix *matrix = (struct at91_matrix *)ATMEL_BASE_MATRIX;
+ struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
+ unsigned long csa;
+
+ /* Enable CS3 */
+ csa = readl(matrix-ebicsa);
+ csa |= AT91_MATRIX_EBI_CS3A_SMC_SMARTMEDIA;
+ writel(csa, matrix-ebicsa);
+
+ /* Configure SMC CS3 for NAND/SmartMedia */
+ writel(AT91_SMC_SETUP_NWE(1) | AT91_SMC_SETUP_NCS_WR(0) |
+ AT91_SMC_SETUP_NRD(1) | AT91_SMC_SETUP_NCS_RD(0),
+ smc-cs[3].setup);
+ writel(AT91_SMC_PULSE_NWE(3) | AT91_SMC_PULSE_NCS_WR(5) |
+AT91_SMC_PULSE_NRD(4) | AT91_SMC_PULSE_NCS_RD(6),
+smc-cs[3].pulse);
+ writel(AT91_SMC_CYCLE_NWE(5) | AT91_SMC_CYCLE_NRD(6),
+smc-cs[3].cycle);
+ writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
+ AT91_SMC_MODE_EXNW_DISABLE |
+ AT91_SMC_MODE_DBW_8 |
+ AT91_SMC_MODE_TDF_CYCLE(1),
+ smc-cs[3].mode);
+
+ writel(1 ATMEL_ID_PIOCD, pmc-pcer);
+
+ /* Configure RDY/BSY */
+ at91_set_gpio_input(CONFIG_SYS_NAND_READY_PIN, 1);
+
+ /* Enable NandFlash */
+
Re: [U-Boot] [PATCH v2 1/2] mx6sabresd: Avoid hang when HDMI cable is not connected
Hi Fabio, On 13/09/2013 15:58, Fabio Estevam wrote: We currently have the same in DT for mx6 as well. Check this commit, for example: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/imx6q-sabrelite.dts?id=722cfacd2e719b6447fb4bd5cd3372725876336d Cool, thanks for the hint ! Regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
OK, but as Wolfgang already pointed out, can you tell use what compiler exposes
this behavior and show us the details WD requested please ?
Best regards,
Marek Vasut
You can find the informations below.
Please, use my patch or don't use it, or feel free to modify it as you
wish, but sorry, I really don't have more time to work on this problem.
/ $ arm-linux-gcc --version//
//arm-linux-gcc (crosstool-NG 1.12.1) 4.4.6//
//Copyright (C) 2010 Free Software Foundation, Inc.//
//This is free software; see the source for copying conditions. There
is NO//
//warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.//
//
// $ arm-linux-ld --version//
//GNU ld (crosstool-NG 1.12.1) 2.20.1.20100303//
//Copyright 2009 Free Software Foundation, Inc.//
//This program is free software; you may redistribute it under the terms
of//
//the GNU General Public License version 3 or (at your option) a later
version.//
//This program has absolutely no warranty./
*Before**:
*/4003ff5c fec_recv://
//4003ff5c: e92d44f0push{r4, r5, r6, r7, sl, lr}//
//4003ff60: e590403cldr r4, [r0, #60] ; 0x3c//
//4003ff64: e24ddc06sub sp, sp, #1536 ; 0x600//
//4003ff68: e5943000ldr r3, [r4]//
//4003ff6c: e594600cldr r6, [r4, #12]//
//4003ff70: e5935004ldr r5, [r3, #4]//
//4003ff74: e594a008ldr sl, [r4, #8]//
//4003ff78: e1a07000mov r7, r0//
//4003ff7c: e5943000ldr r3, [r4]//
//4003ff80: e3150101tst r5, #1073741824 ; 0x4000//
//4003ff84: e5835004str r5, [r3, #4]//
//4003ff88: 0a07beq 4003ffac fec_recv+0x50//
//4003ff8c: ebfffd9ebl 4003f60c fec_halt//
//4003ff90: e5941018ldr r1, [r4, #24]//
//4003ff94: e1a7mov r0, r7//
//4003ff98: ebfffef1bl 4003fb64 fec_init//
//4003ff9c: e1a01005mov r1, r5//
//4003ffa0: e59f01a4ldr r0, [pc, #420] ; 4004014c
fec_recv+0x1f0//
//4003ffa4: ebff76b7bl 4001da88 printf//
//4003ffa8: ea1db 40040024 fec_recv+0xc8//
//4003ffac: e355cmp r5, #0//
//4003ffb0: aa03bge 4003ffc4 fec_recv+0x68//
//4003ffb4: e59320c4ldr r2, [r3, #196] ; 0xc4//
//4003ffb8: e3822001orr r2, r2, #1//
//4003ffbc: e5943000ldr r3, [r4]//
//4003ffc0: e58320c4str r2, [r3, #196] ; 0xc4//
//4003ffc4: e3150201tst r5, #268435456 ; 0x1000//
//4003ffc8: 0a0dbeq 40040004 fec_recv+0xa8//
//4003ffcc: e5943000ldr r3, [r4]//
//4003ffd0: e59330c4ldr r3, [r3, #196] ; 0xc4//
//4003ffd4: e3130001tst r3, #1//
//4003ffd8: 0a09beq 40040004 fec_recv+0xa8//
//4003ffdc: e1a7mov r0, r7//
//4003ffe0: ebfffd89bl 4003f60c fec_halt//
//4003ffe4: e5943000ldr r3, [r4]//
//4003ffe8: e59320c4ldr r2, [r3, #196] ; 0xc4//
//4003ffec: e3c22001bic r2, r2, #1//
//4003fff0: e5943000ldr r3, [r4]//
//4003fff4: e1a7mov r0, r7//
//4003fff8: e58320c4str r2, [r3, #196] ; 0xc4//
//4003fffc: e5941018ldr r1, [r4, #24]//
//4004: ebfffed7bl 4003fb64 fec_init//
//40040004: e1a05186lsl r5, r6, #3//
//40040008: e08a6005add r6, sl, r5//
//4004000c: e3c6003fbic r0, r6, #63 ; 0x3f//
//40040010: e2801040add r1, r0, #64 ; 0x40//
//40040014: ebff0152bl 4564
invalidate_dcache_range//
//40040018: e1d620b2ldrhr2, [r6, #2]//
//4004001c: e3120902tst r2, #32768 ; 0x8000//
//40040020: 0a01beq 4004002c fec_recv+0xd0//
//40040024: e3a05000mov r5, #0//
//40040028: ea44b 40040140 fec_recv+0x1e4//
//4004002c: e59f311cldr r3, [pc, #284] ; 40040150
fec_recv+0x1f4//
//40040030: e0023003and r3, r2, r3//
//40040034: e3530b02cmp r3, #2048 ; 0x800//
//40040038: 1a16bne 40040098 fec_recv+0x13c//
//4004003c: e19a30b5ldrhr3, [sl, r5]//
//40040040: e3530012cmp r3, #18//
//40040044: da13ble 40040098 fec_recv+0x13c//
//40040048: e5967004ldr r7, [r6, #4]//
//4004004c: e19a50b5ldrhr5, [sl, r5]//
//40040050: e2455004sub r5, r5, #4//
//40040054: e287103fadd r1, r7, #63 ; 0x3f//
//40040058: e0811005add r1, r1, r5//
//4004005c: e3c7003fbic r0,
Re: [U-Boot] [PATCH v5] at91: add support for CDU9G25 board
Hi Andreas,
Dne 13.9.2013 16:10, Andreas Bießmann napsal(a):
Dear Jiri Prchal,
On 09/13/2013 03:00 PM, Jiri Prchal wrote:
This patch adds support for our companies board CDU9G25 with Atmel AT91SAM9G25,
128MB DDR2, 256MB NAND.
Signed-off-by: Jiri Prchal jiri.prc...@aksignal.cz
---
v.2
Fixed static IP and MAC addr cofiguration by random MAC and DHCP.
Added entry to MAINTAINERS.
Fixed line lenght, trailing spaces and other cosmetics.
v.3
Removed static eth_gadget addresses.
MAC address set from serial number of F-RAM.
v.4
Changed debug to printf if used random MAC addr, print that addr.
Keep MAC addr set in enviroment.
v.5
Changes to Bo Shen comments.
Signed-off-by: Jiri Prchal jiri.prc...@aksignal.cz
---
arch/arm/include/asm/mach-types.h |1 +
board/AKsignal/cdu9g25/Makefile | 34 ++
board/AKsignal/cdu9g25/cdu9g25.c | 202 +++
boards.cfg|1 +
include/configs/cdu9g25.h | 210 +
5 files changed, 448 insertions(+)
create mode 100644 board/AKsignal/cdu9g25/Makefile
create mode 100644 board/AKsignal/cdu9g25/cdu9g25.c
create mode 100644 include/configs/cdu9g25.h
diff --git a/arch/arm/include/asm/mach-types.h
b/arch/arm/include/asm/mach-types.h
index 440b041..9b274ba 100644
--- a/arch/arm/include/asm/mach-types.h
+++ b/arch/arm/include/asm/mach-types.h
@@ -986,6 +986,7 @@ extern unsigned int __machine_arch_type;
#define MACH_TYPE_VIT_IBOX 3371
#define MACH_TYPE_DM6441_ESP 3372
#define MACH_TYPE_AT91SAM9X5EK 3373
+#define MACH_TYPE_CDU9G25 3373
NAK, please obtain a mach type:
http://www.arm.linux.org.uk/developer/machines/?action=new
Should I register machine? I develop DT only:
NOTE 1:If you are developing a DT-only platform, you do not need to register a
machine type for it.
Please do not register a machine type. Thanks.
Do I need this MACH_TYPE_* at all?
#define MACH_TYPE_LIBRA3374
#define MACH_TYPE_EASYCRRH 3375
#define MACH_TYPE_TRIPEL 3376
diff --git a/board/AKsignal/cdu9g25/Makefile b/board/AKsignal/cdu9g25/Makefile
new file mode 100644
index 000..b644a83
--- /dev/null
+++ b/board/AKsignal/cdu9g25/Makefile
@@ -0,0 +1,34 @@
+#
+# U-boot - Makefile
+#
+# (C) Copyright 2013
+# Jiri Prchal jiri.prc...@aksignal.cz
+# AK signal www.aksignal.cz
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS-y+= cdu9g25.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/AKsignal/cdu9g25/cdu9g25.c b/board/AKsignal/cdu9g25/cdu9g25.c
new file mode 100644
index 000..7321a02
--- /dev/null
+++ b/board/AKsignal/cdu9g25/cdu9g25.c
@@ -0,0 +1,202 @@
+/*
+ * (C) Copyright 2013
+ * Jiri Prchal jiri.prc...@aksignal.cz
+ * AK signal www.aksignal.cz
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include malloc.h
+#include asm/io.h
+#include asm/arch/at91sam9x5_matrix.h
+#include asm/arch/at91sam9_smc.h
+#include asm/arch/at91_common.h
+#include asm/arch/at91_pmc.h
+#include asm/arch/at91_rstc.h
+#include asm/arch/at91_spi.h
+#include asm/arch/gpio.h
+#include asm/arch/clk.h
+#include atmel_hlcdc.h
+#include atmel_mci.h
+#include spi.h
+#include net.h
+#include netdev.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static void cdu9g25_nand_hw_init(void)
+{
+ struct at91_smc *smc = (struct at91_smc *)ATMEL_BASE_SMC;
+ struct at91_matrix *matrix = (struct at91_matrix *)ATMEL_BASE_MATRIX;
+ struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
+ unsigned long csa;
+
+ /* Enable CS3 */
+ csa = readl(matrix-ebicsa);
+ csa |= AT91_MATRIX_EBI_CS3A_SMC_SMARTMEDIA;
+ writel(csa, matrix-ebicsa);
+
+ /* Configure SMC CS3 for NAND/SmartMedia */
+ writel(AT91_SMC_SETUP_NWE(1) | AT91_SMC_SETUP_NCS_WR(0) |
+ AT91_SMC_SETUP_NRD(1) | AT91_SMC_SETUP_NCS_RD(0),
+ smc-cs[3].setup);
+ writel(AT91_SMC_PULSE_NWE(3) | AT91_SMC_PULSE_NCS_WR(5) |
+ AT91_SMC_PULSE_NRD(4) | AT91_SMC_PULSE_NCS_RD(6),
+ smc-cs[3].pulse);
+ writel(AT91_SMC_CYCLE_NWE(5) | AT91_SMC_CYCLE_NRD(6),
+ smc-cs[3].cycle);
+ writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
+ AT91_SMC_MODE_EXNW_DISABLE |
+ AT91_SMC_MODE_DBW_8 |
+
Re: [U-Boot] [PATCH v2 1/2] mx6sabresd: Avoid hang when HDMI cable is not connected
Hi Fabio, On 09/13/2013 06:58 AM, Fabio Estevam wrote: Hi Stefano, On Fri, Sep 13, 2013 at 5:16 AM, Stefano Babic sba...@denx.de wrote: I admit that using DT also for u-boot seems a better solution. You're right about i.MX6 in kernel, but on the other hand I like how it is described for i.MX28 boards. The display-timings node contain all information we need. It would be nice to have the same for i.MX6. We currently have the same in DT for mx6 as well. Check this commit, for example: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/imx6q-sabrelite.dts?id=722cfacd2e719b6447fb4bd5cd3372725876336d Nice! So, how should we get this done? We have support for parsing individual lines of DT, and the primary thing(s) needed by U-Boot's display are in the timing block of the device tree, but I wonder whether it makes sense to implement a full parser for that, or a simpler parser for fb_videomode. Since both cfb_console in U-Boot and the of_get_fb_videomode() routine in the kernel use fb_videomode, it should be straightforward to hand the information off. I don't think the outer information (the lvds-channel@0 and ldb blocks in imx6q-sabrelite.dts) should be parsed by U-Boot as device-tree code since that path leads to having a full device-tree compiler that seems inappropriate. Let me know your thoughts. Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] AES: Encryption of u-boot.img
Hi everyone, I want to implement a minimal secure boot architecture into u-boot by letting the u-boot.img be decrypted during SPL execution. Thus, the u-boot.img is present on the MMC in an encrypted version. I already implemented a basic AES-128 en-/decryption algorithm into the SPL. Everything will be implement on a PandaBoard (OMAP4460). Now my questions are: 1.) What would be the general architecture? u-boot.img is loaded into external memory (DRAM)at address 0x8010. To decrypt it, the whole file needs to be processed by SPL, which will not be able to load the data since the SPL can not exceed a certain size (~49 kByte I guess). - Thus, would it be somehow possible to implement the algorithm in the SPL but let the u-boot.img data be stored in DRAM for processing? 2.) Furthermore, where could be a good place to put the actual algorithm in? I figured that in my situation the function call flow is something like this: ... omap_boot_device() boot_device() spl_mmc_load_image() mmc_load_image_fat file_fat_read() do_fat_read() _jump_to_image_noargs() where u-boot.img is eventually called using the image_entry() function. Thanks a lot, -b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] dfu: ram support
On Fri, Sep 13, 2013 at 15:51 +0200, Marek Vasut wrote:
Dear Afzal Mohammed,
[...]
+int dfu_fill_entity_ram(struct dfu_entity *dfu, char *s)
+{
+ char *st;
+
+ dfu-dev_type = DFU_DEV_RAM;
+ st = strsep(s, );
+ if (strcmp(st, ram)) {
+ error(unsupported device: %s\n, st);
+ return -ENODEV;
+ }
+
+ dfu-layout = DFU_RAM_ADDR;
+ dfu-data.ram.start = (void *)simple_strtoul(s, s, 16);
+ dfu-data.ram.size = simple_strtoul(++s, s, 16);
This ++s, s is quite crazy ;-)
Actually it's not just a neat trick, but instead it's not
guaranteed to work. It's an inviation for problems that you
don't need.
The order in which arguments for the call get evaluated isn't
specified, so behaviour is uncertain here. Read: the
construction happens to work by coincidence for individual
setups, but isn't correct and need not work elsewhere, and may
break in arbitrary ways at any occasion, and then is hard to
track down since things may seem to work often enough or the
bug won't show up when you are diagnosing the problem.
The code needs to get fixed before getting picked up. Doing the
increment in a separate instruction is cheap and simple, the
terse form is wrong.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] powerpc/eeprom: update MAX_NUM_PORTS to adapt non-256-bytes EEPROM
On 09/12/2013 11:46 PM, Shengzhou Liu wrote: Some boards use System EEPROM with 128-bytes instead of 256-bytes. Since we regard 256-bytes EEPROM as standard EEPROM with default value for MAX_NUM_PORTS. For those non-256-bytes EEPROM, we can redefine MAX_NUM_PORTS in board-specific file to override the default MAX_NUM_PORTS. This patch doesn't impact on previous existing boards. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- Verified with 128B and 256B EEPROM, CRC works. I would appreciate it if you update the version number and put a change log under the --- line, even there is no change. With a clear version number and change log, reviewers will be able to identify this is a resend and not spending much time on it. You are also encouraged to mark previous patch as superseded. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 0/5] arm64 patch
Dear feng...@phytium.com.cn, In message 1379061539-38972-1-git-send-email-feng...@phytium.com.cn you wrote: From: David Feng feng...@phytium.com.cn The porting has been merged with arm architecture. Most architecture codes are placed in arch/arm/cpu/armv8 directory. Generic board is also supported after a few bugs are fixed. u-boot could be running at EL1 or EL2. Changes for v8: - add Signed-off-by information to patch board support of vexpress_aemv8a which SMC9 support is integrated from Sharma Bhupesh's patch. - adjust pt_regs struct and add exception state preservation in exception.S. what exactly are the changes for V9 ? 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 Remember thee Ay, thou poor ghost while memory holds a seat In this distracted globe. Remember thee! Yea, from the table of my memory I'll wipe away all trivial fond records, All saws of books, all forms, all pressures past, That youth and observation copied there. Hamlet, I : v : 95 William Shakespeare ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Dear Wolfgang Denk, Dear Robert Hodaszi, In message 5232f2e7.4050...@digi.com you wrote: Ok. Then what about if I would use the stack, but align the buffer manually. Has this been tested? Does it work? - uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN); + /* Align the receive buffer */ + uchar buff_unaligned[FEC_MAX_PKT_SIZE + (ARCH_DMA_MINALIGN - 1)]; + uchar *buff = ((uint32_t)buff_unaligned + (ARCH_DMA_MINALIGN - 1)) ~(ARCH_DMA_MINALIGN - 1); You should use the ALIGN() macro here. We already have this stuff in include/common.h ... ALLOC_CACHE_ALIGNED_BUFFER it is called IIRC Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] i.MX6DL/S: add drive-strength back to pads DISP0_DAT2/DAT10
This patch fixes a regression introduced by commit 87d720e0.
Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
---
arch/arm/include/asm/arch-mx6/mx6dl_pins.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
b/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
index c3d0b70..ad537b4 100644
--- a/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
@@ -235,7 +235,7 @@ enum {
MX6_PAD_DISP0_DAT1__GPIO_4_22 = IOMUX_PAD(0x03C8, 0x00B4, 5,
0x, 0, 0),
MX6_PAD_DISP0_DAT1__MMDC_MMDC_DEBUG_6 = IOMUX_PAD(0x03C8, 0x00B4, 6,
0x, 0, 0),
MX6_PAD_DISP0_DAT1__PL301_SIM_MX6DL_PER1_HADDR_12 =
IOMUX_PAD(0x03C8, 0x00B4, 7, 0x, 0, 0),
- MX6_PAD_DISP0_DAT10__IPU1_DISP0_DAT_10 = IOMUX_PAD(0x03CC, 0x00B8, 0,
0x, 0, 0),
+ MX6_PAD_DISP0_DAT10__IPU1_DISP0_DAT_10 = IOMUX_PAD(0x03CC, 0x00B8, 0,
0x, 0, PAD_CTL_DSE_120ohm),
MX6_PAD_DISP0_DAT10__LCDIF_DAT_10 = IOMUX_PAD(0x03CC, 0x00B8, 1,
0x, 0, PAD_CTL_DSE_120ohm),
MX6_PAD_DISP0_DAT10__USDHC1_USDHC_DEBUG_6 = IOMUX_PAD(0x03CC,
0x00B8, 3, 0x, 0, 0),
MX6_PAD_DISP0_DAT10__SDMA_DEBUG_EVENT_CHANNEL_3 = IOMUX_PAD(0x03CC,
0x00B8, 4, 0x, 0, 0),
@@ -309,7 +309,7 @@ enum {
MX6_PAD_DISP0_DAT19__GPIO_5_13 = IOMUX_PAD(0x03F0, 0x00DC, 5,
0x, 0, 0),
MX6_PAD_DISP0_DAT19__MMDC_MMDC_DEBUG_24 = IOMUX_PAD(0x03F0, 0x00DC, 6,
0x, 0, 0),
MX6_PAD_DISP0_DAT19__WEIM_WEIM_CS_3 = IOMUX_PAD(0x03F0, 0x00DC, 7,
0x, 0, 0),
- MX6_PAD_DISP0_DAT2__IPU1_DISP0_DAT_2= IOMUX_PAD(0x03F4, 0x00E0, 0,
0x, 0, 0),
+ MX6_PAD_DISP0_DAT2__IPU1_DISP0_DAT_2= IOMUX_PAD(0x03F4, 0x00E0, 0,
0x, 0, PAD_CTL_DSE_120ohm),
MX6_PAD_DISP0_DAT2__LCDIF_DAT_2 = IOMUX_PAD(0x03F4, 0x00E0, 1,
0x, 0, 0),
MX6_PAD_DISP0_DAT2__ECSPI3_MISO = IOMUX_PAD(0x03F4, 0x00E0, 2,
0x, 0, 0),
MX6_PAD_DISP0_DAT2__USDHC1_USDHC_DEBUG_2= IOMUX_PAD(0x03F4,
0x00E0, 3, 0x, 0, 0),
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Dear Robert Hodaszi, In message 5232f2e7.4050...@digi.com you wrote: Ok. Then what about if I would use the stack, but align the buffer manually. Has this been tested? Does it work? - uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN); + /* Align the receive buffer */ + uchar buff_unaligned[FEC_MAX_PKT_SIZE + (ARCH_DMA_MINALIGN - 1)]; + uchar *buff = ((uint32_t)buff_unaligned + (ARCH_DMA_MINALIGN - 1)) ~(ARCH_DMA_MINALIGN - 1); You should use the ALIGN() macro here. 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 Niklaus Wirth has lamented that, whereas Europeans pronounce his name correctly (Ni-klows Virt), Americans invariably mangle it into (Nick- les Worth). Which is to say that Europeans call him by name, but Americans call him by value. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] dfu: ram support
Dear Gerhard Sittig,
On Fri, Sep 13, 2013 at 15:51 +0200, Marek Vasut wrote:
Dear Afzal Mohammed,
[...]
+int dfu_fill_entity_ram(struct dfu_entity *dfu, char *s)
+{
+ char *st;
+
+ dfu-dev_type = DFU_DEV_RAM;
+ st = strsep(s, );
+ if (strcmp(st, ram)) {
+ error(unsupported device: %s\n, st);
+ return -ENODEV;
+ }
+
+ dfu-layout = DFU_RAM_ADDR;
+ dfu-data.ram.start = (void *)simple_strtoul(s, s, 16);
+ dfu-data.ram.size = simple_strtoul(++s, s, 16);
This ++s, s is quite crazy ;-)
Actually it's not just a neat trick, but instead it's not
guaranteed to work. It's an inviation for problems that you
don't need.
The order in which arguments for the call get evaluated isn't
specified, so behaviour is uncertain here. Read: the
construction happens to work by coincidence for individual
setups, but isn't correct and need not work elsewhere, and may
break in arbitrary ways at any occasion, and then is hard to
track down since things may seem to work often enough or the
bug won't show up when you are diagnosing the problem.
The code needs to get fixed before getting picked up. Doing the
increment in a separate instruction is cheap and simple, the
terse form is wrong.
Full ACK.
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 2/3] dfu: ram support
Hi Gerhard,
On Fri, Sep 13, 2013 at 15:51 +0200, Marek Vasut wrote:
Dear Afzal Mohammed,
[...]
+int dfu_fill_entity_ram(struct dfu_entity *dfu, char *s)
+{
+ char *st;
+
+ dfu-dev_type = DFU_DEV_RAM;
+ st = strsep(s, );
+ if (strcmp(st, ram)) {
+ error(unsupported device: %s\n, st);
+ return -ENODEV;
+ }
+
+ dfu-layout = DFU_RAM_ADDR;
+ dfu-data.ram.start = (void *)simple_strtoul(s, s, 16);
+ dfu-data.ram.size = simple_strtoul(++s, s, 16);
This ++s, s is quite crazy ;-)
Actually it's not just a neat trick, but instead it's not
guaranteed to work. It's an inviation for problems that you
don't need.
The order in which arguments for the call get evaluated isn't
specified, so behaviour is uncertain here. Read: the
construction happens to work by coincidence for individual
setups, but isn't correct and need not work elsewhere, and may
break in arbitrary ways at any occasion, and then is hard to
track down since things may seem to work often enough or the
bug won't show up when you are diagnosing the problem.
The code needs to get fixed before getting picked up. Doing the
increment in a separate instruction is cheap and simple, the
terse form is wrong.
It was me, who by some obscure reason introduced this faulty (non
standard) code.
And probably Afzal copied it from dfu_mmc.c file.
So f...g embarrassing...
However the fix for that code at dfu_mmc.c file was already posted to
ML.
virtually yours
Gerhard Sittig
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC 0/22] i.MX6: Update pad declarations for multiple-arch binaries
Hi Eric, Thanks for your analyses On 13/09/2013 19:01, Eric Nelson wrote: I recommend that we simply adopt the main-line kernel naming, and work up a couple of initial patches: I fully agree - this makes also code more maintainable if we will be in sync with kernel. 1. simply replace all of the names with their main-line equivalent, and 2. remove all of the unused (NO_PAD_I,NO_MUX_I) pad declarations Agree. Each of these should be easy to inspect for correctness and then we can focus on how to handle the differences and produce binaries that support both variants. I think you proposed the right way to go on ;-) Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AES: Encryption of u-boot.img
Hi On Fri, Sep 13, 2013 at 4:57 PM, bin4ry 0xbin...@gmail.com wrote: Hi everyone, I want to implement a minimal secure boot architecture into u-boot by letting the u-boot.img be decrypted during SPL execution. Thus, the u-boot.img is present on the MMC in an encrypted version. I already implemented a basic AES-128 en-/decryption algorithm into the SPL. Everything will be implement on a PandaBoard (OMAP4460). Now my questions are: 1.) What would be the general architecture? u-boot.img is loaded into external memory (DRAM)at address 0x8010. To decrypt it, the whole file needs to be processed by SPL, which will not be able to load the data since the SPL can not exceed a certain size (~49 kByte I guess). - Thus, would it be somehow possible to implement the algorithm in the SPL but let the u-boot.img data be stored in DRAM for processing? 2.) Furthermore, where could be a good place to put the actual algorithm in? I figured that in my situation the function call flow is something like this: ... omap_boot_device() boot_device() spl_mmc_load_image() mmc_load_image_fat file_fat_read() do_fat_read() ... omap_boot_device() boot_device() spl_mmc_load_image() file_fat_read() do_fat_read() I don't understand you can decrypt it after load. Why just verify the signature? Michael _jump_to_image_noargs() where u-boot.img is eventually called using the image_entry() function. Thanks a lot, -b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/mpc85xx: Add workaround for erratum A006379
Erratum A006379 says CPCHDBCR0 bit field [10:14] has incorrect default
value after POR. The workaround is to set this field before enabling
CPC to 0x1e.
Signed-off-by: York Sun york...@freescale.com
---
arch/powerpc/cpu/mpc85xx/cmd_errata.c |8
arch/powerpc/cpu/mpc85xx/cpu_init.c | 11 +++
arch/powerpc/include/asm/config_mpc85xx.h |5 +
arch/powerpc/include/asm/immap_85xx.h |1 +
4 files changed, 25 insertions(+)
diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index c441bd2..a78e227 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -245,6 +245,14 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
#ifdef CONFIG_SYS_FSL_ERRATUM_A006593
puts(Work-around for Erratum A006593 enabled\n);
#endif
+#ifdef CONFIG_SYS_FSL_ERRATUM_A006379
+ if (
+#ifdef CONFIG_SYS_FSL_ERRATUM_A006379_SVR_REV2
+ ((svr 0xff) == CONFIG_SYS_FSL_ERRATUM_A006379_SVR_REV2) ||
+#endif
+ ((svr 0xff) == CONFIG_SYS_FSL_ERRATUM_A006379_SVR_REV))
+ puts(Work-around for Erratum A006379 enabled\n);
+#endif
#ifdef CONFIG_SYS_FSL_ERRATUM_SEC_A003571
if (IS_SVR_REV(svr, 1, 0))
puts(Work-around for Erratum A003571 enabled\n);
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 6036333..aff8cec 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -126,6 +126,7 @@ void config_8560_ioports (volatile ccsr_cpm_t * cpm)
#ifdef CONFIG_SYS_FSL_CPC
static void enable_cpc(void)
{
+__maybe_unused u32 svr = get_svr();
int i;
u32 size = 0;
@@ -160,6 +161,16 @@ static void enable_cpc(void)
#ifdef CONFIG_SYS_FSL_ERRATUM_A006593
setbits_be32(cpc-cpchdbcr0, 1 (31 - 21));
#endif
+#ifdef CONFIG_SYS_FSL_ERRATUM_A006379
+ if (
+#ifdef CONFIG_SYS_FSL_ERRATUM_A006379_SVR_REV2
+ ((svr 0xff) == CONFIG_SYS_FSL_ERRATUM_A006379_SVR_REV2) ||
+#endif
+ ((svr 0xff) == CONFIG_SYS_FSL_ERRATUM_A006379_SVR_REV)) {
+ setbits_be32(cpc-cpchdbcr0,
+CPC_HDBCR0_SPLRU_LEVEL_EN);
+ }
+#endif
out_be32(cpc-cpccsr0, CPC_CSR0_CE | CPC_CSR0_PE);
/* Read back to sync write */
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index bec8966..83684cf 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -593,6 +593,8 @@
#define CONFIG_SYS_FSL_ERRATUM_A004468
#define CONFIG_SYS_FSL_ERRATUM_A_004934
#define CONFIG_SYS_FSL_ERRATUM_A005871
+#define CONFIG_SYS_FSL_ERRATUM_A006379
+#define CONFIG_SYS_FSL_ERRATUM_A006379_SVR_REV 0x10
#define CONFIG_SYS_FSL_ERRATUM_A006593
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xfe00
#define CONFIG_SYS_FSL_PCI_VER_3_X
@@ -617,6 +619,9 @@
#define CONFIG_SYS_FSL_USB1_PHY_ENABLE
#define CONFIG_SYS_FSL_ERRATUM_A_004934
#define CONFIG_SYS_FSL_ERRATUM_A005871
+#define CONFIG_SYS_FSL_ERRATUM_A006379
+#define CONFIG_SYS_FSL_ERRATUM_A006379_SVR_REV 0x10
+#define CONFIG_SYS_FSL_ERRATUM_A006379_SVR_REV20x20
#define CONFIG_SYS_FSL_ERRATUM_A006593
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xfe00
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index 3a10d77..a938143 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1671,6 +1671,7 @@ typedef struct cpc_corenet {
#define CPC_HDBCR0_CDQ_SPEC_DIS0x0800
#define CPC_HDBCR0_TAG_ECC_SCRUB_DIS 0x0100
#define CPC_HDBCR0_DATA_ECC_SCRUB_DIS 0x0040
+#define CPC_HDBCR0_SPLRU_LEVEL_EN 0x003c
#endif /* CONFIG_SYS_FSL_CPC */
/* Global Utilities Block */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/3] dfu ram support
Hi, DFU spec mentions it as a method to upgrade firmware (software stored in writable non-volatile memory). It also says other potential uses of DFU is beyond scope of the spec. Here such a beyond the scope use is being attempted - directly pumping binary images from host via USB to RAM. This facility is a developer centric one in that it gives advantage over upgrading non-volatile memory for testing new images every time during development and/or testing. Directly putting image onto RAM would speed up upgrade process. This and convenience was the initial thoughts that led to doing this, speed improvement over MMC was only 1 second though - 6 sec on RAM as opposed to 7 sec on MMC in beagle bone, perhaps enabling cache and/or optimizing DFU framework to avoid multiple copy for ram (if worth) may help, and on other platforms and other boot media like NAND maybe improvement would be higher. And for a platform that doesn't yet have proper DFU suppport for non-volatile media's, DFU to RAM can be used. Another minor advantage would be to increase life of mmc/nand as it would be less used during development/testing. usage: image name ram start address size eg. kernel ram 0x8100 0x100 Downloading images to RAM using DFU is not something new, this is acheived in openmoko also. DFU on RAM can be used for extracting RAM contents to host using dfu upload. Perhaps this can be extended to io for squeezing out register dump through usb, if it is worth. In addition to ram support, a minor unification of dfu read/write enum's currently duplicated in mmc/nand is done, helping ram support too. Also dfu ram support is added for am335x SoC based boards. Based on: usb master branch Regards Afzal v4: avoid doing prefix increment in argument of simple_strtoul() collect more tags v3: collected tags, error used instead of printf v2: unified read/write dfu ops enum, added am335x support Afzal Mohammed (3): dfu: unify mmc/nand read/write ops enum dfu: ram support am335x_evm: enable DFU RAM drivers/dfu/Makefile | 1 + drivers/dfu/dfu.c| 7 ++-- drivers/dfu/dfu_mmc.c| 9 ++ drivers/dfu/dfu_nand.c | 7 +--- drivers/dfu/dfu_ram.c| 77 include/configs/am335x_evm.h | 6 include/dfu.h| 23 + 7 files changed, 115 insertions(+), 15 deletions(-) create mode 100644 drivers/dfu/dfu_ram.c -- 1.8.2.135.g7b592fa ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/3] dfu: unify mmc/nand read/write ops enum
MMC and NAND independently defines same enumerators for read/write.
Unify them by defining enum in dfu header. RAM support that is being
added newly also can make use of it.
Signed-off-by: Afzal Mohammed afzal.mohd...@gmail.com
Cc: Heiko Schocher h...@denx.de
Cc: Marek Vasut ma...@denx.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
Acked-by: Lukasz Majewski l.majew...@samsung.com
Acked-by: Marek Vasut ma...@denx.de
---
v4: collect more tag
v3: collected tag
v2: new
drivers/dfu/dfu_mmc.c | 9 ++---
drivers/dfu/dfu_nand.c | 7 +--
include/dfu.h | 5 +
3 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 0871a77..f942758 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -13,16 +13,11 @@
#include div64.h
#include dfu.h
-enum dfu_mmc_op {
- DFU_OP_READ = 1,
- DFU_OP_WRITE,
-};
-
static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE)
dfu_file_buf[CONFIG_SYS_DFU_MAX_FILE_SIZE];
static long dfu_file_buf_len;
-static int mmc_block_op(enum dfu_mmc_op op, struct dfu_entity *dfu,
+static int mmc_block_op(enum dfu_op op, struct dfu_entity *dfu,
u64 offset, void *buf, long *len)
{
char cmd_buf[DFU_CMD_BUF_SIZE];
@@ -65,7 +60,7 @@ static int mmc_file_buffer(struct dfu_entity *dfu, void *buf,
long *len)
return 0;
}
-static int mmc_file_op(enum dfu_mmc_op op, struct dfu_entity *dfu,
+static int mmc_file_op(enum dfu_op op, struct dfu_entity *dfu,
void *buf, long *len)
{
char cmd_buf[DFU_CMD_BUF_SIZE];
diff --git a/drivers/dfu/dfu_nand.c b/drivers/dfu/dfu_nand.c
index 0ec12cf..edbf5a9 100644
--- a/drivers/dfu/dfu_nand.c
+++ b/drivers/dfu/dfu_nand.c
@@ -19,12 +19,7 @@
#include jffs2/load_kernel.h
#include nand.h
-enum dfu_nand_op {
- DFU_OP_READ = 1,
- DFU_OP_WRITE,
-};
-
-static int nand_block_op(enum dfu_nand_op op, struct dfu_entity *dfu,
+static int nand_block_op(enum dfu_op op, struct dfu_entity *dfu,
u64 offset, void *buf, long *len)
{
loff_t start, lim;
diff --git a/include/dfu.h b/include/dfu.h
index 392cef1..6a3e253 100644
--- a/include/dfu.h
+++ b/include/dfu.h
@@ -29,6 +29,11 @@ enum dfu_layout {
DFU_FS_EXT4,
};
+enum dfu_op {
+ DFU_OP_READ = 1,
+ DFU_OP_WRITE,
+};
+
struct mmc_internal_data {
/* RAW programming */
unsigned int lba_start;
--
1.8.2.135.g7b592fa
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/3] dfu: ram support
DFU spec mentions it as a method to upgrade firmware (software stored
in writable non-volatile memory). It also says other potential uses of
DFU is beyond scope of the spec.
Here such a beyond the scope use is being attempted - directly pumping
binary images from host via USB to RAM. This facility is a developer
centric one in that it gives advantage over upgrading non-volatile
memory for testing new images every time during development and/or
testing.
Directly putting image onto RAM would speed up upgrade process. This and
convenience was the initial thoughts that led to doing this, speed
improvement over MMC was only 1 second though - 6 sec on RAM as opposed
to 7 sec on MMC in beagle bone, perhaps enabling cache and/or optimizing
DFU framework to avoid multiple copy for ram (if worth) may help, and
on other platforms and other boot media like NAND maybe improvement
would be higher.
And for a platform that doesn't yet have proper DFU suppport for
non-volatile media's, DFU to RAM can be used.
Another minor advantage would be to increase life of mmc/nand as it
would be less used during development/testing.
usage: image name ram start address size
eg. kernel ram 0x8100 0x100
Downloading images to RAM using DFU is not something new, this is
acheived in openmoko also.
DFU on RAM can be used for extracting RAM contents to host using dfu
upload. Perhaps this can be extended to io for squeezing out register
dump through usb, if it is worth.
Signed-off-by: Afzal Mohammed afzal.mohd...@gmail.com
Cc: Heiko Schocher h...@denx.de
Cc: Marek Vasut ma...@denx.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
Cc: Gerhard Sittig g...@denx.de
Acked-by: Marek Vasut ma...@denx.de
Acked-by: Lukasz Majewski l.majew...@samsung.com
---
v4:
avoid doing prefix increment in argument of simple_strtoul()
collect more tags
v3: error used instead of printf
v2: remove read/write enumerator define's, instead use new common ones
drivers/dfu/Makefile | 1 +
drivers/dfu/dfu.c | 7 +++--
drivers/dfu/dfu_ram.c | 77 +++
include/dfu.h | 18
4 files changed, 101 insertions(+), 2 deletions(-)
create mode 100644 drivers/dfu/dfu_ram.c
diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile
index fca370a..de9e44e 100644
--- a/drivers/dfu/Makefile
+++ b/drivers/dfu/Makefile
@@ -12,6 +12,7 @@ LIB = $(obj)libdfu.o
COBJS-$(CONFIG_DFU_FUNCTION) += dfu.o
COBJS-$(CONFIG_DFU_MMC) += dfu_mmc.o
COBJS-$(CONFIG_DFU_NAND) += dfu_nand.o
+COBJS-$(CONFIG_DFU_RAM) += dfu_ram.o
SRCS:= $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS-y))
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 689f5db..56b21c7 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -348,6 +348,9 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char *s,
int alt,
} else if (strcmp(interface, nand) == 0) {
if (dfu_fill_entity_nand(dfu, s))
return -1;
+ } else if (strcmp(interface, ram) == 0) {
+ if (dfu_fill_entity_ram(dfu, s))
+ return -1;
} else {
printf(%s: Device %s not (yet) supported!\n,
__func__, interface);
@@ -397,14 +400,14 @@ int dfu_config_entities(char *env, char *interface, int
num)
const char *dfu_get_dev_type(enum dfu_device_type t)
{
- const char *dev_t[] = {NULL, eMMC, OneNAND, NAND };
+ const char *dev_t[] = {NULL, eMMC, OneNAND, NAND, RAM };
return dev_t[t];
}
const char *dfu_get_layout(enum dfu_layout l)
{
const char *dfu_layout[] = {NULL, RAW_ADDR, FAT, EXT2,
- EXT3, EXT4 };
+ EXT3, EXT4, RAM_ADDR };
return dfu_layout[l];
}
diff --git a/drivers/dfu/dfu_ram.c b/drivers/dfu/dfu_ram.c
new file mode 100644
index 000..335a8e1
--- /dev/null
+++ b/drivers/dfu/dfu_ram.c
@@ -0,0 +1,77 @@
+/*
+ * (C) Copyright 2013
+ * Afzal Mohammed afzal.mohd...@gmail.com
+ *
+ * Reference: dfu_mmc.c
+ * Copyright (C) 2012 Samsung Electronics
+ * author: Lukasz Majewski l.majew...@samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include malloc.h
+#include errno.h
+#include dfu.h
+
+static int dfu_transfer_medium_ram(enum dfu_op op, struct dfu_entity *dfu,
+ u64 offset, void *buf, long *len)
+{
+ if (dfu-layout != DFU_RAM_ADDR) {
+ error(unsupported layout: %s\n, dfu_get_layout(dfu-layout));
+ return -EINVAL;
+ }
+
+ if (offset dfu-data.ram.size) {
+ error(request exceeds allowed area\n);
+ return -EINVAL;
+ }
+
+ if (op == DFU_OP_WRITE)
+ memcpy(dfu-data.ram.start + offset, buf, *len);
+ else
+ memcpy(buf, dfu-data.ram.start + offset, *len);
+
+ return
[U-Boot] Help with a PPCXXX port
I'm trying to port a custom board running a AMCC 460SX processor to a more recent version of U-Boot. I'm digging around the configuration registers trying to figure out why my initial printout is showing: U-Boot 2013.03932a-dirty (Sep 12 2013 - 14:57:13) CPU: AMCC PowerPC 460SX Rev. A at 231.291 MHz (PLB=33 OPB=16 EBC=4) Security support Bootstrap Option A - Boot ROM Location EBC (8 bits) Internal PCI arbiter enabled 32 kche 32 kB D-Cache While the older version is: U-Boot 1.3.4 (Oct 20 2012 - 11:14:42) CPU: AMCC PowerPC 460SX Rev. B at 800 MHz (PLB=200 MHz, OPB=100 MHz, EBC=100 MHz, DDR=400 MHz) Bootstrap Option A - Boot ROM Location EBC (16 bits) Internal PCI arbiter disabled 32 kB I-Cache 32 kB D-Cache The Rev, Clock Frequency, PLB, OPB, EBC and DDR values are either different or non-existent. I'm going to continue to dig, but if anyone is willing to provide some guidance it would be greatly appreciated. Thanks! -- View this message in context: http://u-boot.10912.n7.nabble.com/Help-with-a-PPCXXX-port-tp163128.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] net: fec: Avoid MX28 bus sync issue
Dear Marek Vasut, In message 201309131824.52506.ma...@denx.de you wrote: - uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN); + /* Align the receive buffer */ + uchar buff_unaligned[FEC_MAX_PKT_SIZE + (ARCH_DMA_MINALIGN - 1)]; + uchar *buff = ((uint32_t)buff_unaligned + (ARCH_DMA_MINALIGN - 1)) ~(ARCH_DMA_MINALIGN - 1); You should use the ALIGN() macro here. We already have this stuff in include/common.h ... ALLOC_CACHE_ALIGNED_BUFFER it is called IIRC That's ALLOC_CACHE_ALIGN_BUFFER. Thanks. 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 Anyone who isn't confused here doesn't really know what's going on. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC 0/22] i.MX6: Update pad declarations for multiple-arch binaries
On Fri, Sep 13, 2013 at 2:01 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: On 09/01/2013 11:21 AM, Eric Nelson wrote: ... Shawn appears to have implemented things in a clean way for the main-line kernel: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/imx6q-pinfunc.h?id=c56009b2f6134e5943a03cf26e4d7fce9745d56b I recommend that we simply adopt the main-line kernel naming, and work up a couple of initial patches: 1. simply replace all of the names with their main-line equivalent, and 2. remove all of the unused (NO_PAD_I,NO_MUX_I) pad declarations Each of these should be easy to inspect for correctness and then we can focus on how to handle the differences and produce binaries that support both variants. Let me know your thoughts. ... I fully support this idea; this easy: * comparing code against Linux kernel; * backporting code from Linux kernel; * correctness (as we don't need to change it every time we add something new); * avoid continuous inspection of this during U-Boot work (often we need to double check the pins are known and which name has been used); Regards, -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] dfu: ram support
+ Gerhard On Fri, Sep 13, 2013 at 10:35:45PM +0530, Afzal Mohammed wrote: Hi Gerhard, Marek, On Fri, Sep 13, 2013 at 05:37:36PM +0200, Gerhard Sittig wrote: On Fri, Sep 13, 2013 at 15:51 +0200, Marek Vasut wrote: + dfu-data.ram.size = simple_strtoul(++s, s, 16); This ++s, s is quite crazy ;-) Actually it's not just a neat trick, but instead it's not guaranteed to work. It's an inviation for problems that you don't need. The order in which arguments for the call get evaluated isn't specified, so behaviour is uncertain here. Read: the construction happens to work by coincidence for individual setups, but isn't correct and need not work elsewhere, and may break in arbitrary ways at any occasion, and then is hard to track down since things may seem to work often enough or the bug won't show up when you are diagnosing the problem. The code needs to get fixed before getting picked up. Doing the increment in a separate instruction is cheap and simple, the terse form is wrong. Yes wrong me, I realize that result is compiler dependent and not guaranteed to work always, v4 posted taking care of the above. Regards Afzal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] dfu: ram support
Hi Gerhard, Marek, On Fri, Sep 13, 2013 at 05:37:36PM +0200, Gerhard Sittig wrote: On Fri, Sep 13, 2013 at 15:51 +0200, Marek Vasut wrote: + dfu-data.ram.size = simple_strtoul(++s, s, 16); This ++s, s is quite crazy ;-) Actually it's not just a neat trick, but instead it's not guaranteed to work. It's an inviation for problems that you don't need. The order in which arguments for the call get evaluated isn't specified, so behaviour is uncertain here. Read: the construction happens to work by coincidence for individual setups, but isn't correct and need not work elsewhere, and may break in arbitrary ways at any occasion, and then is hard to track down since things may seem to work often enough or the bug won't show up when you are diagnosing the problem. The code needs to get fixed before getting picked up. Doing the increment in a separate instruction is cheap and simple, the terse form is wrong. Yes wrong me, I realize that result is compiler dependent and not guaranteed to work always, v4 posted taking care of the above. Regards Afzal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] mx6sabresd: Avoid hang when HDMI cable is not connected
Hi Fabio, On 09/13/2013 11:11 AM, Fabio Estevam wrote: Hi Eric, On Fri, Sep 13, 2013 at 11:51 AM, Eric Nelson eric.nel...@boundarydevices.com wrote: Nice! So, how should we get this done? We have support for parsing individual lines of DT, and the primary thing(s) needed by U-Boot's display are in the timing block of the device tree, but I wonder whether it makes sense to implement a full parser for that, or a simpler parser for fb_videomode. Looks like the parser for fb_videomode is enough. I am not familiar with the usage of device tree in U-boot yet. How do other SoC families handle the video display-timings in dt currently in U-boot? AFAIK, with a full device-tree blob, but without any means of updating it, which ends up in the same place as the compiled-in settings. In order to configure for a new kernel, you have to compile the DTB and save it to the boot media. This is a perfectly reasonable thing to do late in the development process, but makes connecting new panels cumbersome. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix wrong sdhci host control register read and write
The patch fixes the improper read and write of sdhci host control register for sdma transfer. The problem comes when reading and writing 1 byte long host control register with the sdhci_readl() and sdhci_writel(). The misuse of these functions overwrite the value of the next registers which are in 4 bytes boundary. This patch replaces four byte register read/write functions with one byte read/write ones. Beside, it eliminates unnecessary bit operation. i.e. or-ing zero against a variable. Signed-off-by: Juhyun (Justin) Oh juhyun...@sigmadesigns.com --- drivers/mmc/sdhci.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index 4261991..9740cca 100644 --- a/drivers/mmc/sdhci.c +++ b/drivers/mmc/sdhci.c @@ -68,10 +68,9 @@ static int sdhci_transfer_data(struct sdhci_host *host, struct mmc_data *data, unsigned int stat, rdy, mask, timeout, block = 0; #ifdef CONFIG_MMC_SDMA unsigned char ctrl; - ctrl = sdhci_readl(host, SDHCI_HOST_CONTROL); + ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL); ctrl = ~SDHCI_CTRL_DMA_MASK; - ctrl |= SDHCI_CTRL_SDMA; - sdhci_writel(host, ctrl, SDHCI_HOST_CONTROL); + sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL); #endif timeout = 100; ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] mx6sabresd: Avoid hang when HDMI cable is not connected
Hi Eric, On Fri, Sep 13, 2013 at 11:51 AM, Eric Nelson eric.nel...@boundarydevices.com wrote: Nice! So, how should we get this done? We have support for parsing individual lines of DT, and the primary thing(s) needed by U-Boot's display are in the timing block of the device tree, but I wonder whether it makes sense to implement a full parser for that, or a simpler parser for fb_videomode. Looks like the parser for fb_videomode is enough. I am not familiar with the usage of device tree in U-boot yet. How do other SoC families handle the video display-timings in dt currently in U-boot? Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX6DL/S: add drive-strength back to pads DISP0_DAT2/DAT10
On Fri, Sep 13, 2013 at 1:19 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: This patch fixes a regression introduced by commit 87d720e0. Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com Acked-by: Otavio Salvador ota...@ossystems.com.br -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC 0/22] i.MX6: Update pad declarations for multiple-arch binaries
On 09/01/2013 11:21 AM, Eric Nelson wrote: Hi Stefano, On 09/01/2013 10:08 AM, Stefano Babic wrote: Hi Otavio, On 31/08/2013 23:55, Otavio Salvador wrote: On Sat, Aug 31, 2013 at 6:38 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: The primary reason this patch set is sent as an RFC is the overall feeling that there must be a better way and the fact that none of these pads is actually used by any current code in U-Boot and the vast majority of these changes will never do so (OBSERVABILITY pads, for instance). I think it is better to have all the pads there so we don't need to always recheck if the pad is known or not and make changes on this all the time. I am not sure I have understood your sentence: what do you mean with there ? Are you suggesting another place for the pads ? Note that not all of the defined pad options are currently present in these headers, including some that are being used by some down-stream boards: https://github.com/boundarydevices/u-boot-imx6/commit/b9a39fd1756ab95554f4c49b9cf1cde73a9dbda9 I'm taking a look at the XML files distributed as a part of the IOMux tool to see if they can be used to produce a more complete set. I finally took some time to walk through the XML files that are a part of the IOMux tool (scraped through strings). They seem to be more complete than any of the other canonical sources, but only slightly so. AFAIK, there are six main repositories of this pin-mux declarations. -- Freescale's 2009.08 U-Boot has files mx6_pins.h for Dual/Quad, and mx6dl_pins.h for Solo/Dual-Lite: http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/include/asm-arm/arch-mx6?h=imx_v2009.08_3.0.35_4.1.0 -- Main-line U-Boot has files mx6q_pins.h for Quad/Dual and mx6dl_pins.h for Dual-Lite/Solo: http://git.denx.de/u-boot.git/?p=u-boot.git;a=tree;f=arch/arm/include/asm/arch-mx6;h=bec3aaf4de0813965b19bb6cf8a43b1c78f5e7f1;hb=HEAD -- The main-line Linux kernel has files imx6q-pinfunc.h for Quad/Dual and imx6dl-pinfunc.h for Dual-Lite/Solo: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts?id=refs/tags/v3.11 -- Freescale's 3.5.7 tree appears to share the headers with main-line. http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/boot/dts?h=imx_3.5.7_1.0.0_alpha -- Freescale's 3.0.35 tree has files iomux-mx6q.h for Quad/Dual and iomux-mx6dl.h for Dual-Lite/Solo: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/plat-mxc/include/mach Freescale's IOMux tool has two embedded XML files that describe all of the pads, mux and pad registers : https://www.freescale.com/webapp/sps/download/license.jsp?colCode=IMX6_IOMUX_TOOLappType=file1 The two U-Boot trees and the 3.0.35 Linux kernel appear to have the same origins, and each seem to have extra declarations for things that are unlikely to be used or are completely useless like this declaration: MX6_PAD_DRAM_D40__MMDC_DRAM_D_40 = IOMUX_PAD(NO_PAD_I, NO_MUX_I, 0, 0x, 0, 0), If a pad has no mux or pad register, I don't think we need a declaration. The main-line Linux kernel appears to have been generated from the IOMux tool (or a similar ancestor), though there are a number of subtle differences, especially in the use of the _B suffix on some declarations. Comparing the two (IOMux and main-line) showed that some pin muxing options aren't represented in main-line yet and there are some declarations in main-line that I'm not sure how to produce from the XML (those involving input-select registers). Shawn appears to have implemented things in a clean way for the main-line kernel: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/imx6q-pinfunc.h?id=c56009b2f6134e5943a03cf26e4d7fce9745d56b I recommend that we simply adopt the main-line kernel naming, and work up a couple of initial patches: 1. simply replace all of the names with their main-line equivalent, and 2. remove all of the unused (NO_PAD_I,NO_MUX_I) pad declarations Each of these should be easy to inspect for correctness and then we can focus on how to handle the differences and produce binaries that support both variants. Let me know your thoughts. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 3/3] am335x_evm: enable DFU RAM
Enable DFU for RAM, provide example dfu_alt_info
Signed-off-by: Afzal Mohammed afzal.mohd...@gmail.com
Cc: Heiko Schocher h...@denx.de
Cc: Tom Rini tr...@ti.com
Cc: Marek Vasut ma...@denx.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
Reviewed-by: Lukasz Majewski l.majew...@samsung.com
---
v3: collected tag
v2: new
include/configs/am335x_evm.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 3de30fc..978fdf9 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -100,6 +100,7 @@
loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0 \
importbootenv=echo Importing environment from mmc ...; \
env import -t $loadaddr $filesize\0 \
+ dfu_alt_info_ram= DFU_ALT_INFO_RAM \0 \
ramargs=setenv bootargs console=${console} \
${optargs} \
root=${ramroot} \
@@ -321,6 +322,11 @@
kernel part 0 8; \
rootfs part 0 9
#endif
+#define CONFIG_DFU_RAM
+#define DFU_ALT_INFO_RAM \
+ kernel ram 0x8020 0xD8; \
+ fdt ram 0x80F8 0x8; \
+ ramdisk ram 0x8100 0x400
/*
* Default to using SPI for environment, etc.
--
1.8.2.135.g7b592fa
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 0/5] arm64 patch
-原始邮件- 发件人: Wolfgang Denk w...@denx.de 发送时间: 2013年9月14日 星期六 收件人: feng...@phytium.com.cn 抄送: u-boot@lists.denx.de, tr...@ti.com, albert.u.b...@aribaud.net, scottw...@freescale.com 主题: Re: [PATCH v9 0/5] arm64 patch Dear feng...@phytium.com.cn, In message 1379061539-38972-1-git-send-email-feng...@phytium.com.cn you wrote: From: David Feng feng...@phytium.com.cn The porting has been merged with arm architecture. Most architecture codes are placed in arch/arm/cpu/armv8 directory. Generic board is also supported after a few bugs are fixed. u-boot could be running at EL1 or EL2. Changes for v8: - add Signed-off-by information to patch board support of vexpress_aemv8a which SMC9 support is integrated from Sharma Bhupesh's patch. - adjust pt_regs struct and add exception state preservation in exception.S. what exactly are the changes for V9 ? The number is incorrect, the changes for v8 is actually for v9, I will correct it in the next. 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 Remember thee Ay, thou poor ghost while memory holds a seat In this distracted globe. Remember thee! Yea, from the table of my memory I'll wipe away all trivial fond records, All saws of books, all forms, all pressures past, That youth and observation copied there. Hamlet, I : v : 95 William Shakespeare ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-mpc85xx
On Thu, Sep 12, 2013 at 10:36:45AM -0700, York Sun wrote: Tom, The following changes since commit 985a71d15b8bd9cfbeae1ac1b08a5319abfd246c: Merge branch 'master' of git://www.denx.de/git/u-boot-ppc4xx (2013-09-09 09:59:30 -0400) are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master for you to fetch changes up to 954a1a4776d135f2c6ee5276a96c0da71744cd6d: powerpc/mpc85xx: Add workaround for erratum A-005125 (2013-09-10 14:31:47 -0700) Shaohui Xie (1): powerpc/p2041: fix I2C controller's offset York Sun (1): powerpc/mpc85xx: Add workaround for erratum A-005125 arch/powerpc/cpu/mpc85xx/cmd_errata.c |3 +++ arch/powerpc/cpu/mpc85xx/start.S |8 arch/powerpc/include/asm/config_mpc85xx.h | 21 + include/configs/P2041RDB.h|4 ++-- 4 files changed, 34 insertions(+), 2 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
