Re: [U-Boot] [PATCH V2] usb: ci_udc: Allocate the qTD list directly
On 07/01/2014 02:04 AM, Marek Vasut wrote:
Instead of weird allocation of ci_drv-items_mem and then even weirder
distribution of offsets in this memory area into ci_drv-items array,
just allocate ci_drv-items as a big slab of aligned memory (replaces
ci_drv-items_mem) and let ci_get_qtd() do the distribution of offsets
in this memory area.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Jörg Krause jkra...@posteo.de
Cc: Stephen Warren swar...@wwwdotorg.org
---
drivers/usb/gadget/ci_udc.c | 19 ++-
drivers/usb/gadget/ci_udc.h | 3 +--
2 files changed, 7 insertions(+), 15 deletions(-)
V2: Rebase on top of u-boot-usb/master instead of the research branch
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index 1af6d12..8333db2 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -130,7 +130,7 @@ static struct ept_queue_head *ci_get_qh(int ep_num, int
dir_in)
*/
static struct ept_queue_item *ci_get_qtd(int ep_num, int dir_in)
{
- return controller.items[(ep_num * 2) + dir_in];
+ return controller.items + ((ep_num * 2) + dir_in);
}
/**
@@ -769,7 +769,6 @@ static int ci_pullup(struct usb_gadget *gadget, int is_on)
static int ci_udc_probe(void)
{
struct ept_queue_head *head;
- uint8_t *imem;
int i;
const int num = 2 * NUM_ENDPOINTS;
@@ -796,12 +795,12 @@ static int ci_udc_probe(void)
* only one of them is used for the endpoint at time, so we can group
* them together.
*/
- controller.items_mem = memalign(ilist_align, ilist_sz);
- if (!controller.items_mem) {
+ controller.items = memalign(ilist_align, ilist_sz);
+ if (!controller.items) {
free(controller.epts);
return -ENOMEM;
}
- memset(controller.items_mem, 0, ilist_sz);
+ memset(controller.items, 0, ilist_sz);
for (i = 0; i 2 * NUM_ENDPOINTS; i++) {
/*
@@ -821,12 +820,6 @@ static int ci_udc_probe(void)
head-next = TERMINATE;
head-info = 0;
- imem = controller.items_mem + ((i 1) * ilist_ent_sz);
- if (i 1)
- imem += sizeof(struct ept_queue_item);
-
- controller.items[i] = (struct ept_queue_item *)imem;
-
if (i 1) {
ci_flush_qh(i - 1);
ci_flush_qtd(i - 1);
@@ -855,7 +848,7 @@ static int ci_udc_probe(void)
ci_ep_alloc_request(controller.ep[0].ep, 0);
if (!controller.ep0_req) {
- free(controller.items_mem);
+ free(controller.items);
free(controller.epts);
return -ENOMEM;
}
@@ -910,7 +903,7 @@ int usb_gadget_unregister_driver(struct usb_gadget_driver
*driver)
controller.driver = NULL;
ci_ep_free_request(controller.ep[0].ep, controller.ep0_req-req);
- free(controller.items_mem);
+ free(controller.items);
free(controller.epts);
return 0;
diff --git a/drivers/usb/gadget/ci_udc.h b/drivers/usb/gadget/ci_udc.h
index c214402..3115b15 100644
--- a/drivers/usb/gadget/ci_udc.h
+++ b/drivers/usb/gadget/ci_udc.h
@@ -102,8 +102,7 @@ struct ci_drv {
struct usb_gadget_driver*driver;
struct ehci_ctrl*ctrl;
struct ept_queue_head *epts;
- struct ept_queue_item *items[2 * NUM_ENDPOINTS];
- uint8_t *items_mem;
+ struct ept_queue_item *items;
struct ci_epep[NUM_ENDPOINTS];
};
I made a test on u-boot-arm/master before (Test#1) and after applying
this patch (Test#2). After a reset I run this script:
test_usb=setenv i 64; while test ${i} -gt 0; do echo ${i}; tftp
${rootfs_file}; setexpr i ${i} - 1; done; setenv i;
Both tests (Test#1 and Test#2) runs fine with the script. But if I do
run tftp ${rootfs_file} manually from the console, I get the known error
starting the fourth run for both Test#1 and Test#2.
I attached a log file for the error.
= reset
resetting ...
HTLLCLLC
U-Boot 2014.07-rc3-g18e0313 (Jul 01 2014 - 08:32:45)
CPU: Freescale i.MX28 rev1.2 at 454 MHz
BOOT: NAND, 3V3
DRAM: 64 MiB
NAND: 128 MiB
In:serial
Out: serial
Err: serial
Net: usb_ether [PRIME]
Hit any key to stop autoboot: 0
= tftp ${rootfs_file}
using ci_udc, OUT ep- IN ep- STATUS ep-
MAC 00:19:b8:00:00:02
HOST MAC 00:19:b8:00:00:01
high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet
USB network up!
Using usb_ether device
TFTP from server 10.0.0.1; our IP address is 10.0.0.2
Filename 'rootfs.ubifs'.
Load address: 0x40008000
Loading: #
#
#
[U-Boot] [PATCH] powerpc/t1040: fix i2c2 address on t1040qds and t104xrdb
The base address of I2C2 is 0x118100 instead of 0x119000. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- include/configs/T1040QDS.h | 2 +- include/configs/T104xRDB.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/T1040QDS.h b/include/configs/T1040QDS.h index 2215ac8..5b75562 100644 --- a/include/configs/T1040QDS.h +++ b/include/configs/T1040QDS.h @@ -443,7 +443,7 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_SYS_FSL_I2C2_SPEED 5 /* I2C speed in Hz */ #define CONFIG_SYS_FSL_I2C2_SLAVE 0x7F #define CONFIG_SYS_FSL_I2C_OFFSET 0x118000 -#define CONFIG_SYS_FSL_I2C2_OFFSET 0x119000 +#define CONFIG_SYS_FSL_I2C2_OFFSET 0x118100 #define I2C_MUX_PCA_ADDR 0x77 #define I2C_MUX_PCA_ADDR_PRI 0x77 /* Primary Mux*/ diff --git a/include/configs/T104xRDB.h b/include/configs/T104xRDB.h index e564cb7..e265786 100644 --- a/include/configs/T104xRDB.h +++ b/include/configs/T104xRDB.h @@ -441,7 +441,7 @@ #define CONFIG_SYS_FSL_I2C2_SPEED 40 /* I2C speed in Hz */ #define CONFIG_SYS_FSL_I2C2_SLAVE 0x7F #define CONFIG_SYS_FSL_I2C_OFFSET 0x118000 -#define CONFIG_SYS_FSL_I2C2_OFFSET 0x119000 +#define CONFIG_SYS_FSL_I2C2_OFFSET 0x118100 /* I2C bus multiplexer */ #define I2C_MUX_PCA_ADDR0x70 -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/t1040: fix i2c2 address on t1040qds and t104xrdb
Hello Shengzhou, T1040 has two dual I2C controller. First Dual I2C Controller : 0x118 (first i2c bus), 0x1181000(second I2C bus) Second Dual I2C Controller : 0x119 (third i2c bus), 0x1191000(fourth I2C bus) My understanding is CONFIG_SYS_FSL_I2C_OFFSET is offset for first I2C controller and CONFIG_SYS_FSL_I2C2_OFFSET is offset for second I2C controller. Have you checked for dual I2C controller, CONFIG_SYS_FSL_I2C2_OFFSET implies offset for second I2C bus, not the controller? Regards Priyanka -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Shengzhou Liu Sent: Tuesday, July 01, 2014 11:32 AM To: u-boot@lists.denx.de; Sun York-R58495 Subject: [U-Boot] [PATCH] powerpc/t1040: fix i2c2 address on t1040qds and t104xrdb The base address of I2C2 is 0x118100 instead of 0x119000. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- include/configs/T1040QDS.h | 2 +- include/configs/T104xRDB.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/T1040QDS.h b/include/configs/T1040QDS.h index 2215ac8..5b75562 100644 --- a/include/configs/T1040QDS.h +++ b/include/configs/T1040QDS.h @@ -443,7 +443,7 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_SYS_FSL_I2C2_SPEED5 /* I2C speed in Hz */ #define CONFIG_SYS_FSL_I2C2_SLAVE0x7F #define CONFIG_SYS_FSL_I2C_OFFSET0x118000 -#define CONFIG_SYS_FSL_I2C2_OFFSET 0x119000 +#define CONFIG_SYS_FSL_I2C2_OFFSET 0x118100 #define I2C_MUX_PCA_ADDR 0x77 #define I2C_MUX_PCA_ADDR_PRI 0x77 /* Primary Mux*/ diff --git a/include/configs/T104xRDB.h b/include/configs/T104xRDB.h index e564cb7..e265786 100644 --- a/include/configs/T104xRDB.h +++ b/include/configs/T104xRDB.h @@ -441,7 +441,7 @@ #define CONFIG_SYS_FSL_I2C2_SPEED40 /* I2C speed in Hz */ #define CONFIG_SYS_FSL_I2C2_SLAVE0x7F #define CONFIG_SYS_FSL_I2C_OFFSET0x118000 -#define CONFIG_SYS_FSL_I2C2_OFFSET 0x119000 +#define CONFIG_SYS_FSL_I2C2_OFFSET 0x118100 /* I2C bus multiplexer */ #define I2C_MUX_PCA_ADDR0x70 -- 1.8.0 ___ 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 RFC 3/3] arm:vf610-twr:Add fsl-spi-interface config and board info
From: Chao Fu b44...@freescale.com
Add spi device info for vf610-twr board.
Enable fsl-spi-interface for compatibility of fsl-dspi and fsl-qspi.
Signed-off-by: Chao Fu b44...@freescale.com
---
board/freescale/vf610twr/vf610twr.c | 24
include/configs/vf610twr.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/board/freescale/vf610twr/vf610twr.c
b/board/freescale/vf610twr/vf610twr.c
index 54a9f2c..356fcdc 100644
--- a/board/freescale/vf610twr/vf610twr.c
+++ b/board/freescale/vf610twr/vf610twr.c
@@ -402,6 +402,30 @@ int board_phy_config(struct phy_device *phydev)
return 0;
}
+int board_spi_find_bus(unsigned int bus, unsigned int cs)
+{
+ switch(bus) {
+ case SPI_BUS_FSL_QSPI0:
+ break;
+ default:
+ return -1;
+ }
+
+ switch(bus) {
+ case SPI_BUS_FSL_QSPI0:
+ if(cs == 0)
+ return 0;
+ default:
+ return -1;
+ }
+}
+
+void board_print_spi_device(void)
+{
+ printf(VF610-TWR spi flash info:\n);
+ printf(S25FL128S is on spi bus 0 cs 0\n);
+}
+
int board_early_init_f(void)
{
clock_init();
diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h
index 0342550..05e2dcc 100644
--- a/include/configs/vf610twr.h
+++ b/include/configs/vf610twr.h
@@ -68,6 +68,8 @@
#define CONFIG_PHYLIB
#define CONFIG_PHY_MICREL
+#define CONFIG_FSL_SPI_INTERFACE
+
/* QSPI Configs*/
#define CONFIG_FSL_QSPI
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RFC 1/3] spi:fsl_spi:Add compatibility for fsl-qspi and fsl-dspi modules driver
From: Chao Fu b44...@freescale.com
Freescale has some series of chips(e.g. vf610) contain two kinds of
SPI modules, DSPI and QSPI. U-boot spi current code can't compile and
enable the two modules at same time. So add fsl-spi-interface make two
spi driver code work together.
Usage:(e.g.)
SPI bus defination can be find in SOC level:
SPI_BUS_FSL_QSPI0 0
SPI_BUS_FSL_DSPI1 1
SPI_BUS_FSL_DSPI2 2
SPI devices info can be find in board level:
AT45DB021 is on spi bus 1 cs 0
S25FL064 is on spi bus 2 cs 0
S25FL128S is on spi bus 0 cs 0
Before using any SPI bus and SPI flash, execute sf probe bus:cs in uboot cmdline
Such as use S25FL064, sf probe 2:0.
Then sf read / sf write can be excuted.
Signed-off-by: Chao Fu b44...@freescale.com
---
drivers/spi/Makefile| 1 +
drivers/spi/fsl_qspi.c | 33 ++---
drivers/spi/fsl_spi_interface.c | 275
3 files changed, 286 insertions(+), 23 deletions(-)
create mode 100644 drivers/spi/fsl_spi_interface.c
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index b587308..9c5d25c 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -40,4 +40,5 @@ obj-$(CONFIG_TEGRA114_SPI) += tegra114_spi.o
obj-$(CONFIG_TI_QSPI) += ti_qspi.o
obj-$(CONFIG_XILINX_SPI) += xilinx_spi.o
obj-$(CONFIG_ZYNQ_SPI) += zynq_spi.o
+obj-$(CONFIG_FSL_SPI_INTERFACE) += fsl_spi_interface.o
obj-$(CONFIG_FSL_QSPI) += fsl_qspi.o
diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index ba20bef..328f154 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -51,14 +51,6 @@
#define qspi_write32 out_be32
#endif
-static unsigned long spi_bases[] = {
- QSPI0_BASE_ADDR,
-};
-
-static unsigned long amba_bases[] = {
- QSPI0_AMBA_BASE,
-};
-
struct fsl_qspi {
struct spi_slave slave;
unsigned long reg_base;
@@ -67,6 +59,9 @@ struct fsl_qspi {
u8 cur_seqid;
};
+unsigned long get_spi_bus_base(unsigned int bus);
+unsigned long get_qspi_amba_base(unsigned int bus);
+
/* QSPI support swapping the flash read/write data
* in hardware for LS102xA, but not for VF610 */
static inline u32 qspi_endian_xchg(u32 data)
@@ -176,12 +171,7 @@ static void qspi_set_lut(struct fsl_qspi *qspi)
qspi_write32(regs-lckcr, QSPI_LCKCR_LOCK);
}
-void spi_init()
-{
- /* do nothing */
-}
-
-struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+struct spi_slave *qspi_setup_slave(unsigned int bus, unsigned int cs,
unsigned int max_hz, unsigned int mode)
{
struct fsl_qspi *qspi;
@@ -189,15 +179,12 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
u32 reg_val, smpr_val;
u32 total_size, seq_id;
- if (bus = ARRAY_SIZE(spi_bases))
- return NULL;
-
qspi = spi_alloc_slave(struct fsl_qspi, bus, cs);
if (!qspi)
return NULL;
- qspi-reg_base = spi_bases[bus];
- qspi-amba_base = amba_bases[bus];
+ qspi-reg_base = get_spi_bus_base(bus);
+ qspi-amba_base = get_qspi_amba_base(bus);
qspi-slave.max_write_size = TX_BUFFER_SIZE;
@@ -232,14 +219,14 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
return qspi-slave;
}
-void spi_free_slave(struct spi_slave *slave)
+void qspi_free_slave(struct spi_slave *slave)
{
struct fsl_qspi *qspi = to_qspi_spi(slave);
free(qspi);
}
-int spi_claim_bus(struct spi_slave *slave)
+int qspi_claim_bus(struct spi_slave *slave)
{
return 0;
}
@@ -436,7 +423,7 @@ static void qspi_op_se(struct fsl_qspi *qspi)
qspi_write32(regs-mcr, mcr_reg);
}
-int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
+int qspi_xfer(struct spi_slave *slave, unsigned int bitlen,
const void *dout, void *din, unsigned long flags)
{
struct fsl_qspi *qspi = to_qspi_spi(slave);
@@ -476,7 +463,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
return 0;
}
-void spi_release_bus(struct spi_slave *slave)
+void qspi_release_bus(struct spi_slave *slave)
{
/* Nothing to do */
}
diff --git a/drivers/spi/fsl_spi_interface.c b/drivers/spi/fsl_spi_interface.c
new file mode 100644
index 000..4af6be1
--- /dev/null
+++ b/drivers/spi/fsl_spi_interface.c
@@ -0,0 +1,275 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * Freescale Muti Serial Peripheral Interface (QSPI and DSPI) driver support
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include malloc.h
+#include spi.h
+#include asm/io.h
+#include asm/errno.h
+
+void dspi_init(void);
+int dspi_claim_bus(struct spi_slave *slave);
+int dspi_release_bus(struct spi_slave *slave);
+int dspi_cs_is_valid(unsigned int bus, unsigned int cs);
+struct spi_slave
[U-Boot] [PATCH RFC 2/3] arm:vf610:Add SPI bus num in SOC level for SPI compatibility
From: Chao Fu b44...@freescale.com Add DSPI and QSPI bus definition in SOC level. Sf probe command parameter bus will decide which module will work. Add register base definition. Signed-off-by: Chao Fu b44...@freescale.com --- arch/arm/include/asm/arch-vf610/imx-regs.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/arch-vf610/imx-regs.h b/arch/arm/include/asm/arch-vf610/imx-regs.h index bd6f680..3076975 100644 --- a/arch/arm/include/asm/arch-vf610/imx-regs.h +++ b/arch/arm/include/asm/arch-vf610/imx-regs.h @@ -95,6 +95,8 @@ #define FEC_QUIRK_ENET_MAC #define I2C_QUIRK_REG +#define SPI_BUS_FSL_QSPI0 0 + /* MSCM interrupt rounter */ #define MSCM_IRSPRC_CP0_EN 1 #define MSCM_IRSPRC_NUM112 -- 1.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] usb: ci_udc: Allocate the qTD list directly
On Tuesday, July 01, 2014 at 08:51:45 AM, Jörg Krause wrote:
On 07/01/2014 02:04 AM, Marek Vasut wrote:
Instead of weird allocation of ci_drv-items_mem and then even weirder
distribution of offsets in this memory area into ci_drv-items array,
just allocate ci_drv-items as a big slab of aligned memory (replaces
ci_drv-items_mem) and let ci_get_qtd() do the distribution of offsets
in this memory area.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Jörg Krause jkra...@posteo.de
Cc: Stephen Warren swar...@wwwdotorg.org
---
drivers/usb/gadget/ci_udc.c | 19 ++-
drivers/usb/gadget/ci_udc.h | 3 +--
2 files changed, 7 insertions(+), 15 deletions(-)
V2: Rebase on top of u-boot-usb/master instead of the research branch
[...]
I made a test on u-boot-arm/master before (Test#1) and after applying
this patch (Test#2).
Can we please sync on the same codebase (u-boot-usb/master) ?
After a reset I run this script:
test_usb=setenv i 64; while test ${i} -gt 0; do echo ${i}; tftp
${rootfs_file}; setexpr i ${i} - 1; done; setenv i;
Both tests (Test#1 and Test#2) runs fine with the script. But if I do
run tftp ${rootfs_file} manually from the console, I get the known error
starting the fourth run for both Test#1 and Test#2.
Can you edit arch/arm/cpu/arm926ejs/cache.c and change the debug() to printf()
,
then re-test please ? I suspect this might trap something still. Ah, and please
test on u-boot-usb/master with this patch.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/3] mtd, ubi, ubifs: resync with Linux-3.14
Dear Scott, In message 1404169793.2435.204.ca...@snotra.buserror.net you wrote: (git) diff needs a reference to diff against. Maybe I missed some earlier comments about that, but how exactly should this be done here? When the code is synced, the corresponding Linux SHA1 or tag should be placed in the commit message. This is the case for the NAND code. Unfortunately it has never been true of the mtd/ubi code, but this do-over in those trees is an opportunity to fix that. Heiko already did that. There is no intermediate step. The unmodified source is in the Linux tree -- most likely in a more accurate/complete form than the ifdefs convey, since minor differences and subsequent local changes are unlikely to be marked. You can either fetch the Linux tree into your local U-Boot repo (or vice versa) so that git diff can compare them, or you can check out separate repositories to the proper tags/SHAs and use ordinary diff. It's not something that I'd expect one to want to do very often, though. Usually Are you talking here about the theoretitical possibility to do that, or have you actually done that - and found the result useful? Maybe I'm doing something wrong, but I get such a huge volume of new resp. deleted files that I find it really, really hard to see any diffs at all. you want to know how things work in the codebase you're working on, or you want to compare some specific aspect of the code which can more easily be done manually. Hm... I think I know what you have in mind. But did you actually try this out with the given code base? One problem I see is that the changes are scattered across the directory tree; we have changes in drivers/mtd, fs/ubifs, include/linux/mtd, and in include/mtd . I am not connvinced that this is a reliable way to study all changes; it seems too easy to me to miss some. Note that I would like to follow your advice, but it is just not working in a sensible way to me, and I wonder if I'm doing something wrong. Maybe you could share the commands to generate such a diff between the U-Boot and the Linux sources - something that generates output equivalent running git-format-patch --stdout HEAD^.. in Heiko's tree? 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 I read part of it all the way through. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] usb: ci_udc: Allocate the qTD list directly
On 07/01/2014 12:17 PM, Marek Vasut wrote:
On Tuesday, July 01, 2014 at 08:51:45 AM, Jörg Krause wrote:
On 07/01/2014 02:04 AM, Marek Vasut wrote:
Instead of weird allocation of ci_drv-items_mem and then even weirder
distribution of offsets in this memory area into ci_drv-items array,
just allocate ci_drv-items as a big slab of aligned memory (replaces
ci_drv-items_mem) and let ci_get_qtd() do the distribution of offsets
in this memory area.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Jörg Krause jkra...@posteo.de
Cc: Stephen Warren swar...@wwwdotorg.org
---
drivers/usb/gadget/ci_udc.c | 19 ++-
drivers/usb/gadget/ci_udc.h | 3 +--
2 files changed, 7 insertions(+), 15 deletions(-)
V2: Rebase on top of u-boot-usb/master instead of the research branch
[...]
I made a test on u-boot-arm/master before (Test#1) and after applying
this patch (Test#2).
Can we please sync on the same codebase (u-boot-usb/master) ?
Sorry, this is a type. I tested on u-boot-usb/master.
After a reset I run this script:
test_usb=setenv i 64; while test ${i} -gt 0; do echo ${i}; tftp
${rootfs_file}; setexpr i ${i} - 1; done; setenv i;
Both tests (Test#1 and Test#2) runs fine with the script. But if I do
run tftp ${rootfs_file} manually from the console, I get the known error
starting the fourth run for both Test#1 and Test#2.
Can you edit arch/arm/cpu/arm926ejs/cache.c and change the debug() to printf() ,
then re-test please ? I suspect this might trap something still. Ah, and please
test on u-boot-usb/master with this patch.
No additional output on the console.
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 V2] usb: ci_udc: Allocate the qTD list directly
On Tuesday, July 01, 2014 at 01:03:25 PM, Jörg Krause wrote:
On 07/01/2014 12:17 PM, Marek Vasut wrote:
On Tuesday, July 01, 2014 at 08:51:45 AM, Jörg Krause wrote:
On 07/01/2014 02:04 AM, Marek Vasut wrote:
Instead of weird allocation of ci_drv-items_mem and then even weirder
distribution of offsets in this memory area into ci_drv-items array,
just allocate ci_drv-items as a big slab of aligned memory (replaces
ci_drv-items_mem) and let ci_get_qtd() do the distribution of offsets
in this memory area.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Jörg Krause jkra...@posteo.de
Cc: Stephen Warren swar...@wwwdotorg.org
---
drivers/usb/gadget/ci_udc.c | 19 ++-
drivers/usb/gadget/ci_udc.h | 3 +--
2 files changed, 7 insertions(+), 15 deletions(-)
V2: Rebase on top of u-boot-usb/master instead of the research branch
[...]
I made a test on u-boot-arm/master before (Test#1) and after applying
this patch (Test#2).
Can we please sync on the same codebase (u-boot-usb/master) ?
Sorry, this is a type. I tested on u-boot-usb/master.
After a reset I run this script:
test_usb=setenv i 64; while test ${i} -gt 0; do echo ${i}; tftp
${rootfs_file}; setexpr i ${i} - 1; done; setenv i;
Both tests (Test#1 and Test#2) runs fine with the script. But if I do
run tftp ${rootfs_file} manually from the console, I get the known error
starting the fourth run for both Test#1 and Test#2.
Can you edit arch/arm/cpu/arm926ejs/cache.c and change the debug() to
printf() , then re-test please ? I suspect this might trap something
still. Ah, and please test on u-boot-usb/master with this patch.
No additional output on the console.
What does this mean? Do you see warning messages prefixed with CACHE: ?
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 V2] usb: ci_udc: Allocate the qTD list directly
On 07/01/2014 01:19 PM, Marek Vasut wrote: [snip] Can you edit arch/arm/cpu/arm926ejs/cache.c and change the debug() to printf() , then re-test please ? I suspect this might trap something still. Ah, and please test on u-boot-usb/master with this patch. No additional output on the console. What does this mean? Do you see warning messages prefixed with CACHE: ? No messages prefixed with CACHE: . Just the usual error message. = using ci_udc, OUT ep- IN ep- STATUS ep- MAC 00:19:b8:00:00:02 HOST MAC 00:19:b8:00:00:01 high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet ERROR: The remote end did not respond in time. at drivers/usb/gadget/ether.c:2392/usb_eth_init() 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 V2] usb: ci_udc: Allocate the qTD list directly
On Tuesday, July 01, 2014 at 01:22:41 PM, Jörg Krause wrote: On 07/01/2014 01:19 PM, Marek Vasut wrote: [snip] Can you edit arch/arm/cpu/arm926ejs/cache.c and change the debug() to printf() , then re-test please ? I suspect this might trap something still. Ah, and please test on u-boot-usb/master with this patch. No additional output on the console. What does this mean? Do you see warning messages prefixed with CACHE: ? No messages prefixed with CACHE: . Just the usual error message. = using ci_udc, OUT ep- IN ep- STATUS ep- MAC 00:19:b8:00:00:02 HOST MAC 00:19:b8:00:00:01 high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet ERROR: The remote end did not respond in time. at drivers/usb/gadget/ether.c:2392/usb_eth_init() Just to make sure, did you remove any CDC ethernet tunables (like cdc_connect_timeout) from your env ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] README: document CONFIG_ENV_IS_IN_SPI_FLASH
The option can be used to save the environment in spi flash. Implementation code is already exist in command/env_sf.c. But the documentation is missing. This patch add the details for this option to the README file. Signed-off-by: Josh Wu josh...@atmel.com --- README | 37 + 1 file changed, 37 insertions(+) diff --git a/README b/README index fe5cacb..794cfb0 100644 --- a/README +++ b/README @@ -4069,6 +4069,43 @@ to save the current settings. environment area within the total memory of your DataFlash placed at the specified address. +- CONFIG_ENV_IS_IN_SPI_FLASH: + + Define this if you have a SPI Flash memory device which you + want to use for the environment. + + - CONFIG_ENV_OFFSET: + - CONFIG_ENV_SIZE: + + These two #defines specify the offset and size of the + environment area within the SPI Flash. CONFIG_ENV_OFFSET must be + aligned to an erase sector boundary. + + - CONFIG_ENV_SECT_SIZE: + + Define the SPI flash's sector size. + + - CONFIG_ENV_OFFSET_REDUND (optional): + + This setting describes a second storage area of CONFIG_ENV_SIZE + size used to hold a redundant copy of the environment data, so + that there is a valid backup copy in case there is a power failure + during a saveenv operation. CONFIG_ENV_OFFSET_RENDUND must be + aligned to an erase sector boundary. + + - CONFIG_ENV_SPI_BUS (optional): + - CONFIG_ENV_SPI_CS (optional): + + Define the SPI bus and chip select. If not defined they will be 0. + + - CONFIG_ENV_SPI_MAX_HZ (optional): + + Define the SPI max work clock. If not defined then use 1MHz. + + - CONFIG_ENV_SPI_MODE (optional): + + Define the SPI work mode. If not defined then use SPI_MODE_3. + - CONFIG_ENV_IS_IN_REMOTE: Define this if you have a remote memory space which you -- 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 V2] usb: ci_udc: Allocate the qTD list directly
On 07/01/2014 01:35 PM, Marek Vasut wrote: On Tuesday, July 01, 2014 at 01:22:41 PM, Jörg Krause wrote: On 07/01/2014 01:19 PM, Marek Vasut wrote: [snip] Can you edit arch/arm/cpu/arm926ejs/cache.c and change the debug() to printf() , then re-test please ? I suspect this might trap something still. Ah, and please test on u-boot-usb/master with this patch. No additional output on the console. What does this mean? Do you see warning messages prefixed with CACHE: ? No messages prefixed with CACHE: . Just the usual error message. = using ci_udc, OUT ep- IN ep- STATUS ep- MAC 00:19:b8:00:00:02 HOST MAC 00:19:b8:00:00:01 high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet ERROR: The remote end did not respond in time. at drivers/usb/gadget/ether.c:2392/usb_eth_init() Just to make sure, did you remove any CDC ethernet tunables (like cdc_connect_timeout) from your env ? = printenv cdc_connect_timeout ## Error: cdc_connect_timeout not defined Also, no other CDC ethernet variables. These are the related env variables from my config header file: #define CONFIG_IPADDR 10.0.0.2 #define CONFIG_SERVERIP 10.0.0.1 #define CONFIG_NETMASK 255.255.255.0 #define CONFIG_EXTRA_ENV_SETTINGS \ ethact=usb_ether\0 \ ethprime=usb_ether\0 \ usbnet_hostaddr=00:19:B8:00:00:01\0 \ usbnet_devaddr=00:19:B8:00:00:02\0 \ [...] And these are my settings for USB: /* USB */ #ifdefCONFIG_CMD_USB #define CONFIG_EHCI_MXS_PORT0 #define CONFIG_USB_MAX_CONTROLLER_COUNT1 #define CONFIG_CI_UDC/* ChipIdea CI13xxx UDC */ #define CONFIG_USB_REG_BASE0x8008 #define CONFIG_USBD_HS/* High speed support for usb device and usbtty. */ #define CONFIG_USB_GADGET_DUALSPEED #define CONFIG_USB_ETHER #define CONFIG_USB_ETH_CDC #endif Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] SPL broken on i.mx31 platforms
Hi, the commit 41623c91 breaks the SPL on i.mx31 platforms. The original startup code (start.S) was position independent to allow relocation in board_init_f. This is necessary as the internal RAM used by the IPL to load the first 2kB from NAND is also used by the NAND controller to buffer pages. Does changing the startup code back to PIC generate any drawbacks on other ARM platforms? What was the intention of the change besides unifying? Could someone verify the issue on a i.mx31 platform. Helmut -- Scanned by MailScanner. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Hi Tom,
On Thu, 19 Jun 2014 18:03:25 -0400, Tom Rini tr...@ti.com wrote:
Hey,
The following changes since commit 0a26e1d6c394aacbf1153977b7348d1dff85db3f:
arm: fix a double-definition error of _start symbol (2014-06-09 10:36:40
+0200)
are available in the git repository at:
git://git.denx.de/u-boot-ti.git master
for you to fetch changes up to 12cc54376768461533b55ada1b0b6d4979f40579:
omap3: overo: Select fdtfile for expansion board (2014-06-19 17:53:59 -0400)
Ash Charles (3):
omap: Don't enable GPMC CS0 with nothing attached
omap4: duovero: Correct name of default device tree
omap3: overo: Select fdtfile for expansion board
Axel Lin (1):
spi: davinci: Fix register address for SPI1_BUS
Felipe Balbi (5):
board: ti: am43xx: print unsupported board name
cpu: armv7: am33x: ddr: write emif ref_ctrl_shadow register
board: ti: am43xx: add support for AM43xx Starter Kit
board: ti: am43xx: add AM437x SK PHY Address
board: ti: am43xx: enable QSPI and Gbit Ethernet on AM437x SK
Jeroen Hofstee (1):
omap3: board: trivial: add void for no args
Khoronzhuk, Ivan (2):
mtd: nand: davinci: add header file for driver definitions
ARM: keystone: aemif: move aemif driver to drivers/memory/ti-aemif.c
Stefano Babic (1):
OMAP: disable gpmc timeout safely for reenabling
arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c|2 +-
arch/arm/cpu/arm926ejs/davinci/dm365_lowlevel.c|1 +
arch/arm/cpu/armv7/am33xx/ddr.c|1 +
arch/arm/cpu/armv7/keystone/Makefile |1 -
arch/arm/cpu/armv7/omap-common/mem-common.c|6 +-
arch/arm/cpu/armv7/omap3/board.c |4 +-
arch/arm/include/asm/arch-davinci/emif_defs.h | 72 --
arch/arm/include/asm/arch-davinci/hardware.h |1 -
arch/arm/include/asm/arch-davinci/nand_defs.h | 38 --
arch/arm/include/asm/arch-keystone/hardware-k2hk.h |7 --
arch/arm/include/asm/arch-keystone/hardware.h | 30 +---
arch/arm/include/asm/arch-keystone/nand_defs.h | 23 --
arch/arm/include/asm/arch-tnetv107x/emif_defs.h|1 -
arch/arm/include/asm/arch-tnetv107x/hardware.h |2 +
arch/arm/include/asm/arch-tnetv107x/nand_defs.h| 23 --
.../emif_defs.h = ti-common/davinci_nand.h} | 55 ++
arch/arm/include/asm/ti-common/ti-aemif.h | 39 ++
board/Barix/ipam390/ipam390.c |2 +-
board/ait/cam_enc_4xx/cam_enc_4xx.c|2 +-
board/davinci/da8xxevm/da830evm.c |3 +-
board/davinci/da8xxevm/da850evm.c |2 +-
board/davinci/dm355evm/dm355evm.c |3 +-
board/davinci/dm355leopard/dm355leopard.c |2 +-
board/davinci/dm365evm/dm365evm.c |3 +-
board/davinci/dm6467evm/dm6467evm.c|3 +-
board/davinci/ea20/ea20.c |2 +-
board/davinci/sonata/sonata.c |2 +-
board/enbw/enbw_cmc/enbw_cmc.c |2 +-
board/omicron/calimain/calimain.c |2 +-
board/overo/overo.c| 14
board/ti/am43xx/board.c| 79
+++-
board/ti/am43xx/board.h|5 ++
board/ti/am43xx/mux.c |3 +
board/ti/k2hk_evm/board.c | 10 +--
board/ti/tnetv107xevm/sdb_board.c |2 +-
drivers/Makefile |1 +
drivers/memory/Makefile|1 +
.../keystone/aemif.c = drivers/memory/ti-aemif.c | 37 +
drivers/mtd/nand/davinci_nand.c|3 +-
drivers/spi/davinci_spi.c |2 +-
include/configs/am43xx_evm.h |2 +
include/configs/davinci_dm6467evm.h|2 +
include/configs/k2hk_evm.h |6 ++
include/configs/omap3_overo.h | 10 +--
include/configs/ti_omap4_common.h |2 +-
45 files changed, 255 insertions(+), 258 deletions(-)
delete mode 100644 arch/arm/include/asm/arch-davinci/emif_defs.h
delete mode 100644 arch/arm/include/asm/arch-davinci/nand_defs.h
delete mode 100644 arch/arm/include/asm/arch-keystone/nand_defs.h
delete mode 100644 arch/arm/include/asm/arch-tnetv107x/emif_defs.h
delete mode 100644 arch/arm/include/asm/arch-tnetv107x/nand_defs.h
rename arch/arm/include/asm/{arch-keystone/emif_defs.h =
ti-common/davinci_nand.h} (56%)
create mode 100644 arch/arm/include/asm/ti-common/ti-aemif.h
create mode 100644 drivers/memory/Makefile
rename
Re: [U-Boot] SPL broken on i.mx31 platforms
Hi Helmut, On Tue, Jul 1, 2014 at 10:33 AM, Helmut Raiger helmut.rai...@hale.at wrote: Hi, the commit 41623c91 breaks the SPL on i.mx31 platforms. The original startup code (start.S) was position independent to allow relocation in board_init_f. This is necessary as the internal RAM used by the IPL to load the first 2kB from NAND is also used by the NAND controller to buffer pages. Does changing the startup code back to PIC generate any drawbacks on other ARM platforms? What was the intention of the change besides unifying? Could someone verify the issue on a i.mx31 platform. Magnus also reported the same issue to me recently. I don't have access to a mx31 board at the moment to investigate this bug. Maybe Albert, Stefano or Magnus could help? Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/11] arm:reset: call the reset_misc() before the cpu reset
Hello Jeroen,
On 06/30/2014 08:30 PM, Jeroen Hofstee wrote:
Hello Przemyslaw.
[...]
#include common.h
+void __reset_misc(void) {}
+
+void reset_misc(void)
+__attribute((weak, alias(__reset_misc)));
+
can you please use __weak here and provide a prototype, wherever it
ends up in the end. It prevents 3 warnings and makes it type safe..
Thanks, I will add the __weak prefix there.
thanks
The prototype of this new function is in file common.h,
so this is type safe.
yup, I see, don't know how I missed that.
No problem.
I checked the compilation with options: -W and -pedantic
on two configs: trats and odroid, and there was no warnings about the
function reset_misc.
You won't see the warning with -Wall -Wpendantic, but when running make
W=1,
which adds -Wmissing-declarations. The alias version typically warns
with something
like __reset_misc has no previous declaration. That is useful at times,
since it would e.g. complain about [1].
Regards,
Jeroen
[1] http://lists.denx.de/pipermail/u-boot/2014-June/182781.html
Thanks for useful info.
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
Re: [U-Boot] [PATCH v3 06/11] arm:reset: call the reset_misc() before the cpu reset
Hello Minkyu,
On 06/27/2014 01:34 PM, Przemyslaw Marczak wrote:
On 06/27/2014 11:40 AM, Minkyu Kang wrote:
Dear Przemyslaw Marczak,
On 26/06/14 23:15, Przemyslaw Marczak wrote:
On an Odroid U3 board, the SOC is unable to reset the eMMC card
in the DWMMC mode by the cpu software reset. Manual reset of the card
by switching proper gpio pin - fixes this issue.
Such solution needs to add a call to pre reset function.
This is done by the reset_misc() function, which is called before
reset_cpu().
The function reset_misc() is a weak function.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Cc: Tom Rini tr...@ti.com
---
arch/arm/lib/reset.c | 7 +++
include/common.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c
index 7a03580..3b39466 100644
--- a/arch/arm/lib/reset.c
+++ b/arch/arm/lib/reset.c
@@ -23,6 +23,11 @@
#include common.h
+void __reset_misc(void) {}
+
+void reset_misc(void)
+__attribute((weak, alias(__reset_misc)));
+
int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[])
{
puts (resetting ...\n);
@@ -30,6 +35,8 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
udelay (5);/* wait 50 ms */
disable_interrupts();
+
+reset_misc();
reset_cpu(0);
/*NOTREACHED*/
diff --git a/include/common.h b/include/common.h
index 232136c..04bab78 100644
--- a/include/common.h
+++ b/include/common.h
@@ -629,6 +629,7 @@ intcheckicache (void);
intcheckdcache (void);
voidupmconfig (unsigned int, unsigned int *, unsigned int);
ulongget_tbclk (void);
+voidreset_misc(void);
voidreset_cpu (ulong addr);
#if defined (CONFIG_OF_LIBFDT) defined (CONFIG_OF_BOARD_SETUP)
void ft_cpu_setup(void *blob, bd_t *bd);
I'm not sure that we really need to add this function to arm common.
We can do this in reset_cpu (arch/arm/cpu/armv7/exynos/soc.c).
But if other SoCs also need to add such things then, it can be added
as arm common.
Thanks,
Minkyu Kang.
No one used this before, so probably better is to move it into exynos
soc.c code.
Thank you,
I'm working on a next patch set version. And the idea with calling
reset_misc() from soc.c is quite bad. Function reset_cpu() is actually
dedicated only for cpu software reset - as its name suggest.
So I prefer leave the reset_misc call inside do_reset().
Thanks,
--
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
Re: [U-Boot] [PATCH V2] usb: ci_udc: Allocate the qTD list directly
On 06/30/2014 06:04 PM, Marek Vasut wrote: Instead of weird allocation of ci_drv-items_mem and then even weirder distribution of offsets in this memory area into ci_drv-items array, just allocate ci_drv-items as a big slab of aligned memory (replaces ci_drv-items_mem) and let ci_get_qtd() do the distribution of offsets in this memory area. As I mentioned on IRC, this patch isn't correct. The existing code ensures that each pair of QTDs are correctly aligned, hence the slight complexity. The new code only actively ensures that the first QTD is correctly aligned; the subsequent QTDs will only be correctly aligned if the sizeof the QTD structure is an exact multiple of the alignment requirements. In practice, it is on my system at least, but that may not be generally true. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] usb: ci_udc: Allocate the qTD list directly
On Tuesday, July 01, 2014 at 05:03:17 PM, Stephen Warren wrote: On 06/30/2014 06:04 PM, Marek Vasut wrote: Instead of weird allocation of ci_drv-items_mem and then even weirder distribution of offsets in this memory area into ci_drv-items array, just allocate ci_drv-items as a big slab of aligned memory (replaces ci_drv-items_mem) and let ci_get_qtd() do the distribution of offsets in this memory area. As I mentioned on IRC, this patch isn't correct. The existing code ensures that each pair of QTDs are correctly aligned, hence the slight complexity. The new code only actively ensures that the first QTD is correctly aligned; the subsequent QTDs will only be correctly aligned if the sizeof the QTD structure is an exact multiple of the alignment requirements. In practice, it is on my system at least, but that may not be generally true. It is on every system with 32b cachelines. On system with 64b cachelines, you won't be able to use one endpoint as both in and out, which I don't think is doable now either. 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 V2] usb: ci_udc: Allocate the qTD list directly
On 07/01/2014 09:13 AM, Marek Vasut wrote: On Tuesday, July 01, 2014 at 05:03:17 PM, Stephen Warren wrote: On 06/30/2014 06:04 PM, Marek Vasut wrote: Instead of weird allocation of ci_drv-items_mem and then even weirder distribution of offsets in this memory area into ci_drv-items array, just allocate ci_drv-items as a big slab of aligned memory (replaces ci_drv-items_mem) and let ci_get_qtd() do the distribution of offsets in this memory area. As I mentioned on IRC, this patch isn't correct. The existing code ensures that each pair of QTDs are correctly aligned, hence the slight complexity. The new code only actively ensures that the first QTD is correctly aligned; the subsequent QTDs will only be correctly aligned if the sizeof the QTD structure is an exact multiple of the alignment requirements. In practice, it is on my system at least, but that may not be generally true. It is on every system with 32b cachelines. Sure. On system with 64b cachelines, you won't be able to use one endpoint as both in and out, which I don't think is doable now either. Yes, the 2nd QTD in each pair isn't correctly aligned at present for 64byte cachelines. I was thinking about sending a patch to fix that (perhaps theoretical) issue. Actually, I wonder if that's related to Jörg's issue at all; his system has the cache line size set to 64 even though that's incorrect, perhaps that influences the behaviour of the cache code... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] usb: ci_udc: Allocate the qTD list directly
On Tuesday, July 01, 2014 at 05:16:26 PM, Stephen Warren wrote: On 07/01/2014 09:13 AM, Marek Vasut wrote: On Tuesday, July 01, 2014 at 05:03:17 PM, Stephen Warren wrote: On 06/30/2014 06:04 PM, Marek Vasut wrote: Instead of weird allocation of ci_drv-items_mem and then even weirder distribution of offsets in this memory area into ci_drv-items array, just allocate ci_drv-items as a big slab of aligned memory (replaces ci_drv-items_mem) and let ci_get_qtd() do the distribution of offsets in this memory area. As I mentioned on IRC, this patch isn't correct. The existing code ensures that each pair of QTDs are correctly aligned, hence the slight complexity. The new code only actively ensures that the first QTD is correctly aligned; the subsequent QTDs will only be correctly aligned if the sizeof the QTD structure is an exact multiple of the alignment requirements. In practice, it is on my system at least, but that may not be generally true. It is on every system with 32b cachelines. Sure. On system with 64b cachelines, you won't be able to use one endpoint as both in and out, which I don't think is doable now either. Yes, the 2nd QTD in each pair isn't correctly aligned at present for 64byte cachelines. I was thinking about sending a patch to fix that (perhaps theoretical) issue. Ah bah, you're right. Actually, I wonder if that's related to Jörg's issue at all; his system has the cache line size set to 64 even though that's incorrect, perhaps that influences the behaviour of the cache code... My understanding of his test is that he uses u-boot-usb/master + this patch and there are not modifications to the CPU support code. If there are, then his test is useless of course. With u-boot-usb/master + this patch , on MX28 there should be no problem. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pull request for u-boot-tegra/master into ARM/master
Hi Tom, On Thu, 19 Jun 2014 10:53:11 -0700, Tom Warren twarren.nvi...@gmail.com wrote: Albert, Please pull u-boot-tegra/master into ARM/master. Thanks! ./MAKEALL -s tegra AOK, checkpatch.pl is OK, and ./MAKEALL -a arm only shows failures that were already present in ARM/master. The following changes since commit 0a26e1d6c394aacbf1153977b7348d1dff85db3f: arm: fix a double-definition error of _start symbol (2014-06-09 10:36:40 +0200) are available in the git repository at: git://git.denx.de/u-boot-tegra.git master for you to fetch changes up to fe7b7cd26683b29bed407bf5ab778e8d80201d73: ARM: tegra: set initrd_high so boot scripts work (2014-06-19 10:47:20 -0700) Jeroen Hofstee (2): tegra20: display: fix checking of return value ARM: tegra: fix include guard Stephen Warren (2): ARM: tegra: fix extlinux.conf search location ARM: tegra: set initrd_high so boot scripts work arch/arm/cpu/armv7/tegra20/display.c | 2 +- include/configs/tegra-common-post.h | 9 + include/configs/tegra-common-ums.h | 2 +- 3 files changed, 7 insertions(+), 6 deletions(-) Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] usb: ci_udc: don't memalign() struct ci_req allocations
From: Stephen Warren swar...@nvidia.com struct ci_req is a purely software structure, and needs no specific memory alignment. Hence, allocate it with calloc() rather than memalign(). The use of memalign() was left-over from when struct ci_req was going to hold the aligned bounce buffer, but this is now dynamically allocated. Signed-off-by: Stephen Warren swar...@nvidia.com --- drivers/usb/gadget/ci_udc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c index 89138675c32f..b8c36523eb1d 100644 --- a/drivers/usb/gadget/ci_udc.c +++ b/drivers/usb/gadget/ci_udc.c @@ -222,12 +222,11 @@ ci_ep_alloc_request(struct usb_ep *ep, unsigned int gfp_flags) if (num == 0 controller.ep0_req) return controller.ep0_req-req; - ci_req = memalign(ARCH_DMA_MINALIGN, sizeof(*ci_req)); + ci_req = calloc(1, sizeof(*ci_req)); if (!ci_req) return NULL; INIT_LIST_HEAD(ci_req-queue); - ci_req-b_buf = 0; if (num == 0) controller.ep0_req = ci_req; -- 1.8.1.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] usb: ci_udc: remove controller.items array
From: Stephen Warren swar...@nvidia.com
There's no need to store an array of QTD pointers in the controller.
Since the calculation is so simple, just have ci_get_qtd() perform it
at run-time, rather than pre-calculating everything.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
drivers/usb/gadget/ci_udc.c | 8 +++-
drivers/usb/gadget/ci_udc.h | 1 -
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index abaf8985503f..89138675c32f 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -146,7 +146,9 @@ static struct ept_queue_head *ci_get_qh(int ep_num, int
dir_in)
*/
static struct ept_queue_item *ci_get_qtd(int ep_num, int dir_in)
{
- return controller.items[(ep_num * 2) + dir_in];
+ int index = (ep_num * 2) + dir_in;
+ uint8_t *imem = controller.items_mem + (index * ILIST_ENT_SZ);
+ return (struct ept_queue_item *)imem;
}
/**
@@ -790,7 +792,6 @@ static int ci_pullup(struct usb_gadget *gadget, int is_on)
static int ci_udc_probe(void)
{
struct ept_queue_head *head;
- uint8_t *imem;
int i;
const int num = 2 * NUM_ENDPOINTS;
@@ -831,9 +832,6 @@ static int ci_udc_probe(void)
head-next = TERMINATE;
head-info = 0;
- imem = controller.items_mem + (i * ILIST_ENT_SZ);
- controller.items[i] = (struct ept_queue_item *)imem;
-
if (i 1) {
ci_flush_qh(i / 2);
ci_flush_qtd(i / 2);
diff --git a/drivers/usb/gadget/ci_udc.h b/drivers/usb/gadget/ci_udc.h
index c2144021e675..346164a64132 100644
--- a/drivers/usb/gadget/ci_udc.h
+++ b/drivers/usb/gadget/ci_udc.h
@@ -102,7 +102,6 @@ struct ci_drv {
struct usb_gadget_driver*driver;
struct ehci_ctrl*ctrl;
struct ept_queue_head *epts;
- struct ept_queue_item *items[2 * NUM_ENDPOINTS];
uint8_t *items_mem;
struct ci_epep[NUM_ENDPOINTS];
};
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/6] usb: ci_udc: fixes and cleanups
From: Stephen Warren swar...@nvidia.com
This is a series of small fixes and cleanups either required by those
fixes, or enabled now that the fixes are made.
I hope that either patch 1 or 4 might fix the issues Jörg is seeing, but
I'm not sure that will happen. The other patches shouldn't change any
behaviour.
Stephen Warren (6):
usb: ci_udc: fix ci_flush_{qh,qtd} calls in ci_udc_probe()
usb: ci_udc: don't assume QTDs are adjacent when transmitting ZLPs
usb: ci_udc: lift ilist size calculations to global scope
usb: ci_udc: fix items array size/stride calculation
usb: ci_udc: remove controller.items array
usb: ci_udc: don't memalign() struct ci_req allocations
drivers/usb/gadget/ci_udc.c | 62 ++---
drivers/usb/gadget/ci_udc.h | 1 -
2 files changed, 30 insertions(+), 33 deletions(-)
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/6] usb: ci_udc: don't assume QTDs are adjacent when transmitting ZLPs
From: Stephen Warren swar...@nvidia.com Fix ci_ep_submit_next_request()'s ZLP transmission code to explicitly call ci_get_qtd() to find the address of the other QTD to use. This will allow us to correctly align each QTD individually in the future, which may involve leaving a gap between the QTDs. Signed-off-by: Stephen Warren swar...@nvidia.com --- drivers/usb/gadget/ci_udc.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c index 8ba604841c47..4115cd5dab0f 100644 --- a/drivers/usb/gadget/ci_udc.c +++ b/drivers/usb/gadget/ci_udc.c @@ -404,10 +404,11 @@ static void ci_ep_submit_next_request(struct ci_ep *ci_ep) * only 1 is used at a time since either an IN or an OUT but * not both is queued. For an IN transaction, item currently * points at the second of these items, so we know that we -* can use (item - 1) to transmit the extra zero-length packet +* can use the other to transmit the extra zero-length packet. */ - item-next = (unsigned)(item - 1); - item--; + struct ept_queue_item *other_item = ci_get_qtd(num, 0); + item-next = (unsigned)other_item; + item = other_item; item-info = INFO_ACTIVE; } -- 1.8.1.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/6] usb: ci_udc: fix items array size/stride calculation
From: Stephen Warren swar...@nvidia.com
2 QTDs are allocated for each EP. The current allocation scheme aligns
the first QTD in each pair, but simply adds the struct size to calculate
the second QTD's address. This will result in a non-cache-aligned
addresss IF the system's ARCH_DMA_MINALIGN is not 32 bytes (i.e. the
size of struct ept_queue_item).
Similarly, the original ilist_ent_sz calculation aligned the value to
ARCH_DMA_MINALIGN but didn't take the USB HW's 32-byte alignment
requirement into account. This doesn't cause a practical issue unless
ARCH_DMA_MINALIGN 32 (which I suspect is quite unlikely), but we may
as well fix the code to be explicit, so it's obviously completely
correct.
The new value of ILIST_ENT_SZ takes all alignment requirements into
account, so we can simplify ci_{flush,invalidate}_qtd() by simply using
that macro rather than calling roundup().
Similarly, the calculation of controller.items[i] can be simplified,
since each QTD is evenly spaced at its individual alignment requirement,
rather than each pair being aligned, and entries within the pair being
spaced apart only by structure size.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
drivers/usb/gadget/ci_udc.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index 3a114cf11e17..abaf8985503f 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -35,15 +35,20 @@
#endif
/*
- * Each qTD item must be 32-byte aligned, each qTD touple must be
- * cacheline aligned. There are two qTD items for each endpoint and
- * only one of them is used for the endpoint at time, so we can group
- * them together.
+ * Every QTD must be individually aligned, since we can program any
+ * QTD's address into HW. Cache flushing requires ARCH_DMA_MINALIGN,
+ * and the USB HW requires 32-byte alignment. Align to both:
*/
#define ILIST_ALIGNroundup(ARCH_DMA_MINALIGN, 32)
-#define ILIST_ENT_RAW_SZ (2 * sizeof(struct ept_queue_item))
-#define ILIST_ENT_SZ roundup(ILIST_ENT_RAW_SZ, ARCH_DMA_MINALIGN)
-#define ILIST_SZ (NUM_ENDPOINTS * ILIST_ENT_SZ)
+/* Each QTD is this size */
+#define ILIST_ENT_RAW_SZ sizeof(struct ept_queue_item)
+/*
+ * Align the size of the QTD too, so we can add this value to each
+ * QTD's address to get another aligned address.
+ */
+#define ILIST_ENT_SZ roundup(ILIST_ENT_RAW_SZ, ILIST_ALIGN)
+/* For each endpoint, we need 2 QTDs, one for each of IN and OUT */
+#define ILIST_SZ (NUM_ENDPOINTS * 2 * ILIST_ENT_SZ)
#ifndef DEBUG
#define DBG(x...) do {} while (0)
@@ -184,8 +189,7 @@ static void ci_flush_qtd(int ep_num)
{
struct ept_queue_item *item = ci_get_qtd(ep_num, 0);
const uint32_t start = (uint32_t)item;
- const uint32_t end_raw = start + 2 * sizeof(*item);
- const uint32_t end = roundup(end_raw, ARCH_DMA_MINALIGN);
+ const uint32_t end = start + 2 * ILIST_ENT_SZ;
flush_dcache_range(start, end);
}
@@ -200,8 +204,7 @@ static void ci_invalidate_qtd(int ep_num)
{
struct ept_queue_item *item = ci_get_qtd(ep_num, 0);
const uint32_t start = (uint32_t)item;
- const uint32_t end_raw = start + 2 * sizeof(*item);
- const uint32_t end = roundup(end_raw, ARCH_DMA_MINALIGN);
+ const uint32_t end = start + 2 * ILIST_ENT_SZ;
invalidate_dcache_range(start, end);
}
@@ -828,10 +831,7 @@ static int ci_udc_probe(void)
head-next = TERMINATE;
head-info = 0;
- imem = controller.items_mem + ((i 1) * ILIST_ENT_SZ);
- if (i 1)
- imem += sizeof(struct ept_queue_item);
-
+ imem = controller.items_mem + (i * ILIST_ENT_SZ);
controller.items[i] = (struct ept_queue_item *)imem;
if (i 1) {
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/6] usb: ci_udc: fix ci_flush_{qh, qtd} calls in ci_udc_probe()
From: Stephen Warren swar...@nvidia.com
ci_udc_probe() initializes a pair of QHs and QTDs for each EP. After
each pair has been initialized, the pair is cache-flushed. The
conversion from QH/QTD index [0..2*NUM_END_POINTS) to EP index
[0..NUM_ENDPOINTS] is incorrect; it simply subtracts 1 (which yields
the QH/QTD index of the first entry in the pair) rather than dividing
by two (which scales the range). Fix this.
On my system, this avoids cache debug prints due to requests to flush
unaligned ranges. This is caused because the flush calls happen before
the items[] array entries are initialized for all but EP0.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
drivers/usb/gadget/ci_udc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index a6433e8d2d8d..8ba604841c47 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -834,8 +834,8 @@ static int ci_udc_probe(void)
controller.items[i] = (struct ept_queue_item *)imem;
if (i 1) {
- ci_flush_qh(i - 1);
- ci_flush_qtd(i - 1);
+ ci_flush_qh(i / 2);
+ ci_flush_qtd(i / 2);
}
}
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/6] usb: ci_udc: lift ilist size calculations to global scope
From: Stephen Warren swar...@nvidia.com
This will allow functions other than ci_udc_probe() to make use of the
constants in a future change.
This in turn requires converting the const int variables to #defines,
since the initialization of one global const int can't depend on the
value of another const int; the compiler thinks it's non-constant if
that dependency exists.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
drivers/usb/gadget/ci_udc.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index 4115cd5dab0f..3a114cf11e17 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -34,6 +34,17 @@
#error This driver can not work on systems with caches longer than 128b
#endif
+/*
+ * Each qTD item must be 32-byte aligned, each qTD touple must be
+ * cacheline aligned. There are two qTD items for each endpoint and
+ * only one of them is used for the endpoint at time, so we can group
+ * them together.
+ */
+#define ILIST_ALIGNroundup(ARCH_DMA_MINALIGN, 32)
+#define ILIST_ENT_RAW_SZ (2 * sizeof(struct ept_queue_item))
+#define ILIST_ENT_SZ roundup(ILIST_ENT_RAW_SZ, ARCH_DMA_MINALIGN)
+#define ILIST_SZ (NUM_ENDPOINTS * ILIST_ENT_SZ)
+
#ifndef DEBUG
#define DBG(x...) do {} while (0)
#else
@@ -786,29 +797,18 @@ static int ci_udc_probe(void)
const int eplist_raw_sz = num * sizeof(struct ept_queue_head);
const int eplist_sz = roundup(eplist_raw_sz, ARCH_DMA_MINALIGN);
- const int ilist_align = roundup(ARCH_DMA_MINALIGN, 32);
- const int ilist_ent_raw_sz = 2 * sizeof(struct ept_queue_item);
- const int ilist_ent_sz = roundup(ilist_ent_raw_sz, ARCH_DMA_MINALIGN);
- const int ilist_sz = NUM_ENDPOINTS * ilist_ent_sz;
-
/* The QH list must be aligned to 4096 bytes. */
controller.epts = memalign(eplist_align, eplist_sz);
if (!controller.epts)
return -ENOMEM;
memset(controller.epts, 0, eplist_sz);
- /*
-* Each qTD item must be 32-byte aligned, each qTD touple must be
-* cacheline aligned. There are two qTD items for each endpoint and
-* only one of them is used for the endpoint at time, so we can group
-* them together.
-*/
- controller.items_mem = memalign(ilist_align, ilist_sz);
+ controller.items_mem = memalign(ILIST_ALIGN, ILIST_SZ);
if (!controller.items_mem) {
free(controller.epts);
return -ENOMEM;
}
- memset(controller.items_mem, 0, ilist_sz);
+ memset(controller.items_mem, 0, ILIST_SZ);
for (i = 0; i 2 * NUM_ENDPOINTS; i++) {
/*
@@ -828,7 +828,7 @@ static int ci_udc_probe(void)
head-next = TERMINATE;
head-info = 0;
- imem = controller.items_mem + ((i 1) * ilist_ent_sz);
+ imem = controller.items_mem + ((i 1) * ILIST_ENT_SZ);
if (i 1)
imem += sizeof(struct ept_queue_item);
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: sdhci: Fixed timeout for sdhci_send_command()
On Fri, Jun 27, 2014 at 4:37 AM, Pantelis Antoniou
pantelis.anton...@gmail.com wrote:
Hi Eli,
On Jun 12, 2014, at 12:41 PM, Eli Billauer wrote:
The current wait loop just reads the status 1 times, which makes the
actual timeout period platform-dependent. The udelay() call within the
loop
makes the new timeout ~100 ms.
Signed-off-by: Eli Billauer eli.billa...@gmail.com
---
drivers/mmc/sdhci.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 3125d13..80f3a91 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -226,6 +226,7 @@ int sdhci_send_command(struct mmc *mmc, struct
mmc_cmd *cmd,
break;
if (--retry == 0)
break;
+ udelay(10);
} while ((stat mask) != mask);
if (retry == 0) {
--
1.7.2.3
Looking at the linux sources is no good, cause linux is interrupt driven.
This delay is used because the driver is not interrupt driven, so you have
to wait until the interrupt indication is delivered.
The only reference to interrupt latency I found is related to tuning and is
set to 50ms which I supposed is very pessimistic.
I think a timeout of 100ms would be fine.
I suspect the timeout of 100ms is fine (though it's always nice when we tie
such numbers to something more concrete than: it works if I make it wait
longer). My main point was that this actually *adds* 100ms to the
preexisting timeout, instead of making the timeout ~100ms. If we reduced
the number of checks and increased the delay, the delay would completely
dominate the timeout loop, and total time would become closer to ~100ms.
Andy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: Add support for norrin board
On Mon, Jun 30, 2014 at 02:32:20PM -0700, Stephen Warren wrote: On 06/30/2014 02:53 PM, Allen Martin wrote: Norrin (PM370) is a Tegra124 clamshell board that is very similar to venice2, but it has a different panel, the sdcard cd sense is flipped, and it has a different revision of the AS3722 PMIC. Reuse the venice2 config with a norrin dtb. This board is also refered to as nyan in the ChromeOS trees. Isn't the pinmux different too? I think this patch should contain board/nvidia/norrin/pinmux-config-norrin.h shouldn't it? That in turn would mean adding Norrin support to tegra-pinmux-scripts. Of course, if they really do have 100% identical pinmux, then there's no issue. I'm skeptical though. AFAIK they really do have identical pinmux, I'll double check the pinmux spreadsheet to make sure. There's another unintended side effect of reusing the venice2 board this way that I discovered after posting this. It causes CONFIG_SYS_BOARD to be set to venice2 still, which causes the board_name environment variable to be set to venice2, which causes boot.scr to look for a venice2 dtb. It may be cleaner to make norrin a proper board, and just have it #include the vencie2 pinmux. -Allen nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] dfu: fix readback buffer overflow test
From: Stephen Warren swar...@nvidia.com
The buffer is too small if it's size to read, not if it's = the size.
This fixes the 1MB test case on Tegra, which has a 1MB buffer.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
drivers/dfu/dfu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 6cd3fbb58ae4..3512b149c560 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -332,7 +332,7 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
case DFU_RAM_ADDR:
break;
default:
- if (dfu-r_left = dfu_buf_size) {
+ if (dfu-r_left dfu_buf_size) {
printf(%s: File too big for buffer\n,
__func__);
return -EOVERFLOW;
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] test: dfu: add some more test cases
From: Stephen Warren swar...@nvidia.com On Tegra, the DFU buffer size is 1M. Consequently, the 8M test always fails. Add tests for the 1M size, and one byte less as a corner case, so that some large tests are executed and expected to pass. Signed-off-by: Stephen Warren swar...@nvidia.com --- test/dfu/dfu_gadget_test_init.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/dfu/dfu_gadget_test_init.sh b/test/dfu/dfu_gadget_test_init.sh index fb54ad8c55ee..2163a685a55d 100755 --- a/test/dfu/dfu_gadget_test_init.sh +++ b/test/dfu/dfu_gadget_test_init.sh @@ -9,7 +9,7 @@ COLOUR_DEFAULT=\33[0m LOG_DIR=./log -TEST_FILES_SIZES=63 64 65 127 128 129 4095 4096 4097 959 960 961 8M +TEST_FILES_SIZES=63 64 65 127 128 129 4095 4096 4097 959 960 961 1048575 1048576 8M printf Init script for generating data necessary for DFU test script -- 1.8.1.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] test: dfu: cleanup before execution
From: Stephen Warren swar...@nvidia.com Call cleanup() before running tests too. If a previous test was CTRL-C'd some stale files may have been left around. dfu-util refuses to receive a file to a filename that already exists, which results in false test failures if the files aren't cleaned up first. Signed-off-by: Stephen Warren swar...@nvidia.com --- test/dfu/dfu_gadget_test.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/test/dfu/dfu_gadget_test.sh b/test/dfu/dfu_gadget_test.sh index c5c5f1d957f1..4133155ae97d 100755 --- a/test/dfu/dfu_gadget_test.sh +++ b/test/dfu/dfu_gadget_test.sh @@ -66,6 +66,7 @@ printf $COLOUR_GREEN=== echo DFU EP0 transmission test program echo Trouble shoot - disable DBG (even the KERN_DEBUG) in the UDC driver echo @ - TRATS2 # dfu 0 mmc 0 +cleanup mkdir -p $DIR$RCV_DIR touch $LOG_FILE -- 1.8.1.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung master
Hi Minkyu, On Mon, 30 Jun 2014 17:42:38 +0900, Minkyu Kang mk7.k...@samsung.com wrote: Dear Albert, The following changes since commit 0a26e1d6c394aacbf1153977b7348d1dff85db3f: arm: fix a double-definition error of _start symbol (2014-06-09 10:36:40 +0200) are available in the git repository at: http://git.denx.de/u-boot-samsung for you to fetch changes up to 5287d595449512385e25f5afcb68a130bf08bae6: Samsung: Goni: change maintainer to Robert Baldyga (2014-06-30 14:02:42 +0900) Akshay Saraswat (9): Exynos5: DMC: Modify the definition of ddr3_mem_ctrl_init Exynos5420: Remove code for enabling read leveling Exynos5420: DMC: Add software read leveling Exynos: SPI: Fix reading data from SPI flash Exynos5420: Let macros be used for exynos5420 Exynos5420: Introduce support for the Peach-Pit board Exynos5: Config: Place environment at the end of SPI flash Exynos5: Config: Increase SPL footprint for Exynos5420 Exynos5: Config: Enable USB boot mode for all Exynos5 SoCs Doug Anderson (1): DMC: exynos5420: Gate CLKM to when reading PHY_CON13 Jeroen Hofstee (1): PMIC: MAX77686: fix invalid bus check Michael Pratt (1): Exynos: Split 5250 and 5420 memory bank configuration Minkyu Kang (1): Revert exynos: Enable PSHOLD in SPL Przemyslaw Marczak (2): trats/trats2: exynos_power_init: return 0 if no battery detected. Samsung: Goni: change maintainer to Robert Baldyga Tushar Behera (1): Arndale: Enable preboot support Łukasz Majewski (2): FIX: config: goni: Change goni configuration to use Tizen's THOR downlodader FIX: config: goni: Change goni configuration to store envs at eMMC arch/arm/cpu/armv7/exynos/dmc_common.c|2 +- arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c | 369 ++--- arch/arm/cpu/armv7/exynos/exynos5_setup.h | 21 +- arch/arm/cpu/armv7/exynos/lowlevel_init.c |2 - arch/arm/dts/Makefile |3 +- arch/arm/dts/exynos5420-peach-pit.dts | 127 ++ arch/arm/dts/exynos5420-smdk5420.dts | 23 +- arch/arm/dts/exynos5420.dtsi | 70 -- arch/arm/dts/exynos54xx.dtsi | 151 arch/arm/include/asm/arch-exynos/dmc.h|3 + arch/arm/include/asm/arch-exynos/power.h |4 +- board/samsung/trats/trats.c |2 +- board/samsung/trats2/trats2.c |2 +- boards.cfg|3 +- drivers/power/pmic/pmic_max77686.c| 13 +- drivers/spi/exynos_spi.c |5 +- include/configs/arndale.h |2 + include/configs/exynos5-dt.h | 15 +- include/configs/exynos5250-dt.h | 13 +- include/configs/exynos5420.h | 52 include/configs/peach-pit.h | 25 ++ include/configs/s5p_goni.h| 17 +- include/configs/smdk5420.h| 49 +--- 23 files changed, 717 insertions(+), 256 deletions(-) create mode 100644 arch/arm/dts/exynos5420-peach-pit.dts delete mode 100644 arch/arm/dts/exynos5420.dtsi create mode 100644 arch/arm/dts/exynos54xx.dtsi create mode 100644 include/configs/exynos5420.h create mode 100644 include/configs/peach-pit.h Applied to u-boot-arm/master (with a manual fix to a trivial merge conflict on boards.cfg), thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL broken on i.mx31 platforms
Hi Fabio, On Tue, 1 Jul 2014 10:53:57 -0300, Fabio Estevam feste...@gmail.com wrote: Hi Helmut, On Tue, Jul 1, 2014 at 10:33 AM, Helmut Raiger helmut.rai...@hale.at wrote: Hi, the commit 41623c91 breaks the SPL on i.mx31 platforms. The original startup code (start.S) was position independent to allow relocation in board_init_f. This is necessary as the internal RAM used by the IPL to load the first 2kB from NAND is also used by the NAND controller to buffer pages. As far as the issue goes: where and how exactly is the code not position independent now? Does changing the startup code back to PIC generate any drawbacks on other ARM platforms? How would this changing back to PIC be implemented? Not by reverting the patch, I hope. What was the intention of the change besides unifying? Any other intent would be stated in the commit message. Could someone verify the issue on a i.mx31 platform. Magnus also reported the same issue to me recently. I don't have access to a mx31 board at the moment to investigate this bug. Maybe Albert, Stefano or Magnus could help? I don't have mx31 hardware either. Thanks, Fabio Estevam Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] kirkwood: Rename dns325 to dnskw
Hi Bastien, On Sun, 8 Jun 2014 18:30:25 +0200, Bastien ROUCARIÈS roucaries.bast...@gmail.com wrote: From: Jamie Lentin j...@lentin.co.uk So we can re-use DNS-325 configuration for the DNS-320 without things getting confusing, rename all common parts from dns325 to dnskw, and use a config option to configure DNS-325 specifics. Signed-off-by: Jamie Lentin j...@lentin.co.uk Cc: prafu...@marvell.com Cc: albert.u.b...@aribaud.net --- board/d-link/dns325/Makefile | 13 --- board/d-link/dns325/dns325.c | 132 --- board/d-link/dns325/dns325.h | 32 -- board/d-link/dns325/kwbimage.cfg | 192 - board/d-link/dnskw/Makefile| 13 +++ board/d-link/dnskw/dnskw.c | 132 +++ board/d-link/dnskw/dnskw.h | 36 +++ board/d-link/dnskw/kwbimage.dns325.cfg | 192 + boards.cfg | 2 +- include/configs/dns325.h | 170 - include/configs/dnskw.h| 175 ++ 11 files changed, 549 insertions(+), 540 deletions(-) delete mode 100644 board/d-link/dns325/Makefile delete mode 100644 board/d-link/dns325/dns325.c delete mode 100644 board/d-link/dns325/dns325.h delete mode 100644 board/d-link/dns325/kwbimage.cfg create mode 100644 board/d-link/dnskw/Makefile create mode 100644 board/d-link/dnskw/dnskw.c create mode 100644 board/d-link/dnskw/dnskw.h create mode 100644 board/d-link/dnskw/kwbimage.dns325.cfg delete mode 100644 include/configs/dns325.h create mode 100644 include/configs/dnskw.h Were the files renamed using git mv, and was this generated with patman or with git format-patch -M or -C? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] kirkwood: Rename dns325 to dnskw
Le 1 juil. 2014 22:03, Albert ARIBAUD albert.u.b...@aribaud.net a écrit : Hi Bastien, On Sun, 8 Jun 2014 18:30:25 +0200, Bastien ROUCARIÈS roucaries.bast...@gmail.com wrote: From: Jamie Lentin j...@lentin.co.uk So we can re-use DNS-325 configuration for the DNS-320 without things getting confusing, rename all common parts from dns325 to dnskw, and use a config option to configure DNS-325 specifics. Signed-off-by: Jamie Lentin j...@lentin.co.uk Cc: prafu...@marvell.com Cc: albert.u.b...@aribaud.net --- board/d-link/dns325/Makefile | 13 --- board/d-link/dns325/dns325.c | 132 --- board/d-link/dns325/dns325.h | 32 -- board/d-link/dns325/kwbimage.cfg | 192 - board/d-link/dnskw/Makefile| 13 +++ board/d-link/dnskw/dnskw.c | 132 +++ board/d-link/dnskw/dnskw.h | 36 +++ board/d-link/dnskw/kwbimage.dns325.cfg | 192 + boards.cfg | 2 +- include/configs/dns325.h | 170 - include/configs/dnskw.h| 175 ++ 11 files changed, 549 insertions(+), 540 deletions(-) delete mode 100644 board/d-link/dns325/Makefile delete mode 100644 board/d-link/dns325/dns325.c delete mode 100644 board/d-link/dns325/dns325.h delete mode 100644 board/d-link/dns325/kwbimage.cfg create mode 100644 board/d-link/dnskw/Makefile create mode 100644 board/d-link/dnskw/dnskw.c create mode 100644 board/d-link/dnskw/dnskw.h create mode 100644 board/d-link/dnskw/kwbimage.dns325.cfg delete mode 100644 include/configs/dns325.h create mode 100644 include/configs/dnskw.h Were the files renamed using git mv, and was this generated with patman or with git format-patch -M or -C? i might forget for resend to use gît format-patch -M Will check tomorrow Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: ci_udc: use var name ep/ci_ep consistently
From: Stephen Warren swar...@nvidia.com
Almost all of ci_udc.c uses variable name ep for a struct usb_ep and
ci_ep for a struct ci_ep. This is nice and consistent, and helps people
know what type a variable is without searching for the declaration.
handle_ep_complete() doesn't do this, so fix it to be consistent.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
drivers/usb/gadget/ci_udc.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index b8c36523eb1d..4cd19c3afd22 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -495,14 +495,14 @@ static void flip_ep0_direction(void)
}
}
-static void handle_ep_complete(struct ci_ep *ep)
+static void handle_ep_complete(struct ci_ep *ci_ep)
{
struct ept_queue_item *item;
int num, in, len;
struct ci_req *ci_req;
- num = ep-desc-bEndpointAddress USB_ENDPOINT_NUMBER_MASK;
- in = (ep-desc-bEndpointAddress USB_DIR_IN) != 0;
+ num = ci_ep-desc-bEndpointAddress USB_ENDPOINT_NUMBER_MASK;
+ in = (ci_ep-desc-bEndpointAddress USB_DIR_IN) != 0;
item = ci_get_qtd(num, in);
ci_invalidate_qtd(num);
@@ -511,12 +511,12 @@ static void handle_ep_complete(struct ci_ep *ep)
printf(EP%d/%s FAIL info=%x pg0=%x\n,
num, in ? in : out, item-info, item-page0);
- ci_req = list_first_entry(ep-queue, struct ci_req, queue);
+ ci_req = list_first_entry(ci_ep-queue, struct ci_req, queue);
list_del_init(ci_req-queue);
- ep-req_primed = false;
+ ci_ep-req_primed = false;
- if (!list_empty(ep-queue))
- ci_ep_submit_next_request(ep);
+ if (!list_empty(ci_ep-queue))
+ ci_ep_submit_next_request(ci_ep);
ci_req-req.actual = ci_req-req.length - len;
ci_debounce(ci_req, in);
@@ -524,7 +524,7 @@ static void handle_ep_complete(struct ci_ep *ep)
DBG(ept%d %s req %p, complete %x\n,
num, in ? in : out, ci_req, len);
if (num != 0 || controller.ep0_data_phase)
- ci_req-req.complete(ep-ep, ci_req-req);
+ ci_req-req.complete(ci_ep-ep, ci_req-req);
if (num == 0 controller.ep0_data_phase) {
/*
* Data Stage is complete, so flip ep0 dir for Status Stage,
@@ -534,7 +534,7 @@ static void handle_ep_complete(struct ci_ep *ep)
flip_ep0_direction();
controller.ep0_data_phase = false;
ci_req-req.length = 0;
- usb_ep_queue(ep-ep, ci_req-req, 0);
+ usb_ep_queue(ci_ep-ep, ci_req-req, 0);
}
}
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] usb: ci_udc: fixes and cleanups
On 07/01/2014 07:41 PM, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
This is a series of small fixes and cleanups either required by those
fixes, or enabled now that the fixes are made.
I hope that either patch 1 or 4 might fix the issues Jörg is seeing, but
I'm not sure that will happen. The other patches shouldn't change any
behaviour.
Stephen Warren (6):
usb: ci_udc: fix ci_flush_{qh,qtd} calls in ci_udc_probe()
usb: ci_udc: don't assume QTDs are adjacent when transmitting ZLPs
usb: ci_udc: lift ilist size calculations to global scope
usb: ci_udc: fix items array size/stride calculation
usb: ci_udc: remove controller.items array
usb: ci_udc: don't memalign() struct ci_req allocations
drivers/usb/gadget/ci_udc.c | 62 ++---
drivers/usb/gadget/ci_udc.h | 1 -
2 files changed, 30 insertions(+), 33 deletions(-)
Good news! The last patch usb: ci_udc: don't memalign() struct ci_req
allocations removes the timeout error after starting the fourth run of
tftp in a row.
This is how I tested. Checked out u-boot-usb/master branch. Applied the
necessary patches to support our board. Applied the patches step after
step. After applying a patch reset the board and run tftp from console
until an error occured, which is always the fourth run. This is the case
until applying patch usb: ci_udc: don't memalign() struct ci_req
allocations, which throws no timeout error within running tftp about 60
times in a row.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] usb: ci_udc: fixes and cleanups
On 07/01/2014 03:25 PM, Jörg Krause wrote:
On 07/01/2014 07:41 PM, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
This is a series of small fixes and cleanups either required by those
fixes, or enabled now that the fixes are made.
I hope that either patch 1 or 4 might fix the issues Jörg is seeing, but
I'm not sure that will happen. The other patches shouldn't change any
behaviour.
Stephen Warren (6):
usb: ci_udc: fix ci_flush_{qh,qtd} calls in ci_udc_probe()
usb: ci_udc: don't assume QTDs are adjacent when transmitting ZLPs
usb: ci_udc: lift ilist size calculations to global scope
usb: ci_udc: fix items array size/stride calculation
usb: ci_udc: remove controller.items array
usb: ci_udc: don't memalign() struct ci_req allocations
drivers/usb/gadget/ci_udc.c | 62
++---
drivers/usb/gadget/ci_udc.h | 1 -
2 files changed, 30 insertions(+), 33 deletions(-)
Good news! The last patch usb: ci_udc: don't memalign() struct ci_req
allocations removes the timeout error after starting the fourth run of
tftp in a row.
This is how I tested. Checked out u-boot-usb/master branch. Applied the
necessary patches to support our board. Applied the patches step after
step. After applying a patch reset the board and run tftp from console
until an error occured, which is always the fourth run.
How many times did you boot the board for each patch? I'm more
interested in how often the first TFTP after a reset/power-on passes or
fails, so it would be nice to boot the board many times to see what
happens to the first TFTP invocation too. This is especially true since
you'd indicated before that the problem was (at least sometimes) visible
on the first TFTP invocation, and this it fails the fourth time
symptom is something completely new.
This is the case
until applying patch usb: ci_udc: don't memalign() struct ci_req
allocations, which throws no timeout error within running tftp about 60
times in a row.
That's quite odd. That patch definitely should not affect behaviour (and
indeed I only sent it as an after-thought). If it does, then the only
explanation I can think of is that the malloc heap's alignment changed,
which just happens to hide the bug you're seeing. No doubt, there is
still some lingering cache-flushing bug or similar...
BTW, did you fix the U-Boot header files in your board support patches,
so that everything correctly knows that the cache line size is 32? I
think it's mandatory to fix that issue before testing the USB code.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] usb: ci_udc: fixes and cleanups
On 07/01/2014 03:31 PM, Stephen Warren wrote:
On 07/01/2014 03:25 PM, Jörg Krause wrote:
On 07/01/2014 07:41 PM, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
This is a series of small fixes and cleanups either required by those
fixes, or enabled now that the fixes are made.
I hope that either patch 1 or 4 might fix the issues Jörg is seeing, but
I'm not sure that will happen. The other patches shouldn't change any
behaviour.
Stephen Warren (6):
usb: ci_udc: fix ci_flush_{qh,qtd} calls in ci_udc_probe()
usb: ci_udc: don't assume QTDs are adjacent when transmitting ZLPs
usb: ci_udc: lift ilist size calculations to global scope
usb: ci_udc: fix items array size/stride calculation
usb: ci_udc: remove controller.items array
usb: ci_udc: don't memalign() struct ci_req allocations
drivers/usb/gadget/ci_udc.c | 62
++---
drivers/usb/gadget/ci_udc.h | 1 -
2 files changed, 30 insertions(+), 33 deletions(-)
Good news! The last patch usb: ci_udc: don't memalign() struct ci_req
allocations removes the timeout error after starting the fourth run of
tftp in a row.
This is how I tested. Checked out u-boot-usb/master branch. Applied the
necessary patches to support our board. Applied the patches step after
step. After applying a patch reset the board and run tftp from console
until an error occured, which is always the fourth run.
How many times did you boot the board for each patch? I'm more
interested in how often the first TFTP after a reset/power-on passes or
fails, so it would be nice to boot the board many times to see what
happens to the first TFTP invocation too. This is especially true since
you'd indicated before that the problem was (at least sometimes) visible
on the first TFTP invocation, and this it fails the fourth time
symptom is something completely new.
This is the case
until applying patch usb: ci_udc: don't memalign() struct ci_req
allocations, which throws no timeout error within running tftp about 60
times in a row.
That's quite odd. That patch definitely should not affect behaviour (and
indeed I only sent it as an after-thought). If it does, then the only
explanation I can think of is that the malloc heap's alignment changed,
which just happens to hide the bug you're seeing. No doubt, there is
still some lingering cache-flushing bug or similar...
BTW, did you fix the U-Boot header files in your board support patches,
so that everything correctly knows that the cache line size is 32? I
think it's mandatory to fix that issue before testing the USB code.
Can you please try one more thing:
Go back to u-boot-usb/master plus just your board support patches. Apply
the following and test that:
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index a6433e8d2d8d..13be1b73d3d1 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -209,9 +209,9 @@ ci_ep_alloc_request(struct usb_ep *ep, unsigned int
gfp_flags)
ci_req = memalign(ARCH_DMA_MINALIGN, sizeof(*ci_req));
if (!ci_req)
return NULL;
+ memset(ci_req, 0, sizeof(*ci_req));
INIT_LIST_HEAD(ci_req-queue);
- ci_req-b_buf = 0;
if (num == 0)
controller.ep0_req = ci_req;
Thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] usb: ci_udc: fixes and cleanups
On 07/01/2014 11:31 PM, Stephen Warren wrote:
On 07/01/2014 03:25 PM, Jörg Krause wrote:
On 07/01/2014 07:41 PM, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
This is a series of small fixes and cleanups either required by those
fixes, or enabled now that the fixes are made.
I hope that either patch 1 or 4 might fix the issues Jörg is seeing, but
I'm not sure that will happen. The other patches shouldn't change any
behaviour.
Stephen Warren (6):
usb: ci_udc: fix ci_flush_{qh,qtd} calls in ci_udc_probe()
usb: ci_udc: don't assume QTDs are adjacent when transmitting ZLPs
usb: ci_udc: lift ilist size calculations to global scope
usb: ci_udc: fix items array size/stride calculation
usb: ci_udc: remove controller.items array
usb: ci_udc: don't memalign() struct ci_req allocations
drivers/usb/gadget/ci_udc.c | 62
++---
drivers/usb/gadget/ci_udc.h | 1 -
2 files changed, 30 insertions(+), 33 deletions(-)
Good news! The last patch usb: ci_udc: don't memalign() struct ci_req
allocations removes the timeout error after starting the fourth run of
tftp in a row.
This is how I tested. Checked out u-boot-usb/master branch. Applied the
necessary patches to support our board. Applied the patches step after
step. After applying a patch reset the board and run tftp from console
until an error occured, which is always the fourth run.
How many times did you boot the board for each patch? I'm more
interested in how often the first TFTP after a reset/power-on passes or
fails, so it would be nice to boot the board many times to see what
happens to the first TFTP invocation too. This is especially true since
you'd indicated before that the problem was (at least sometimes) visible
on the first TFTP invocation, and this it fails the fourth time
symptom is something completely new.
The problem with the problems on the first run was before applying the
patch usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC, which was
not upstream on u-boot-imx branch at the moment of writing the error
report. After applying the patch and setting the cachline size to 32,
the first three runs of tftp works fine, but always the fourth time it
fails.
This is the case
until applying patch usb: ci_udc: don't memalign() struct ci_req
allocations, which throws no timeout error within running tftp about 60
times in a row.
That's quite odd. That patch definitely should not affect behaviour (and
indeed I only sent it as an after-thought). If it does, then the only
explanation I can think of is that the malloc heap's alignment changed,
which just happens to hide the bug you're seeing. No doubt, there is
still some lingering cache-flushing bug or similar...
BTW, did you fix the U-Boot header files in your board support patches,
so that everything correctly knows that the cache line size is 32? I
think it's mandatory to fix that issue before testing the USB code.
Yes, I did this: #define CONFIG_SYS_CACHELINE_SIZE 32
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] usb: ci_udc: Allocate the qTD list directly
On 07/01/2014 01:22 PM, Jörg Krause wrote: On 07/01/2014 01:19 PM, Marek Vasut wrote: [snip] Can you edit arch/arm/cpu/arm926ejs/cache.c and change the debug() to printf() , then re-test please ? I suspect this might trap something still. Ah, and please test on u-boot-usb/master with this patch. No additional output on the console. What does this mean? Do you see warning messages prefixed with CACHE: ? No messages prefixed with CACHE: . Just the usual error message. I am sorry, but maybe I edited arch/arm/cpu/arm926ejs/ in a another branch and compiled in u-boot-usb. If I run now tftp with printf enabled in arch/arm/cpu/arm926ejs/cache.c I get the following CACHE: messages: CACHE: Misaligned operation at range [40008000, 4000c653] CACHE: Misaligned operation at range [43fd0b0c, 43fd0b60] = using ci_udc, OUT ep- IN ep- STATUS ep- MAC 00:19:b8:00:00:02 HOST MAC 00:19:b8:00:00:01 high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet ERROR: The remote end did not respond in time. at drivers/usb/gadget/ether.c:2392/usb_eth_init() 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 V2] usb: ci_udc: Allocate the qTD list directly
On 07/01/2014 04:34 PM, Jörg Krause wrote:
On 07/01/2014 01:22 PM, Jörg Krause wrote:
On 07/01/2014 01:19 PM, Marek Vasut wrote:
[snip]
Can you edit arch/arm/cpu/arm926ejs/cache.c and change the debug() to
printf() , then re-test please ? I suspect this might trap something
still. Ah, and please test on u-boot-usb/master with this patch.
No additional output on the console.
What does this mean? Do you see warning messages prefixed with
CACHE: ?
No messages prefixed with CACHE: . Just the usual error message.
I am sorry, but maybe I edited arch/arm/cpu/arm926ejs/ in a another
branch and compiled in u-boot-usb. If I run now tftp with printf enabled
in arch/arm/cpu/arm926ejs/cache.c I get the following CACHE: messages:
CACHE: Misaligned operation at range [40008000, 4000c653]
CACHE: Misaligned operation at range [43fd0b0c, 43fd0b60]
That happens right when you first use the UDC driver right? If so, I
hope that [U-Boot] [PATCH 1/6] usb: ci_udc: fix ci_flush_{qh, qtd}
calls in ci_udc_probe() will fix that.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] usb: ci_udc: fixes and cleanups
On 07/01/2014 11:36 PM, Stephen Warren wrote: [snip] Can you please try one more thing: Go back to u-boot-usb/master plus just your board support patches. Apply the following and test that: diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c index a6433e8d2d8d..13be1b73d3d1 100644 --- a/drivers/usb/gadget/ci_udc.c +++ b/drivers/usb/gadget/ci_udc.c @@ -209,9 +209,9 @@ ci_ep_alloc_request(struct usb_ep *ep, unsigned int gfp_flags) ci_req = memalign(ARCH_DMA_MINALIGN, sizeof(*ci_req)); if (!ci_req) return NULL; + memset(ci_req, 0, sizeof(*ci_req)); INIT_LIST_HEAD(ci_req-queue); - ci_req-b_buf = 0; if (num == 0) controller.ep0_req = ci_req; Thanks. Applied and tested with printf in cache.c enabled. ttp runs more than three times in row without a timeout error. = reset resetting ... HTLLCLLC U-Boot 2014.07-rc3-g88eca85-dirty (Jul 02 2014 - 00:39:20) CPU: Freescale i.MX28 rev1.2 at 454 MHz BOOT: NAND, 3V3 DRAM: 64 MiB NAND: 128 MiB In:serial Out: serial Err: serial Net: usb_ether [PRIME] Hit any key to stop autoboot: 0 = tftp imx28-airlino.dtb using ci_udc, OUT ep- IN ep- STATUS ep- MAC 00:19:b8:00:00:02 HOST MAC 00:19:b8:00:00:01 high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet USB network up! Using usb_ether device TFTP from server 10.0.0.1; our IP address is 10.0.0.2 Filename 'imx28-airlino.dtb'. Load address: 0x40008000 Loading: ## 2.1 MiB/s done Bytes transferred = 18003 (4653 hex) CACHE: Misaligned operation at range [40008000, 4000c653] = CACHE: Misaligned operation at range [43fd0b08, 43fd0b60] CACHE: Misaligned operation at range [43fd0b14, 43fd0b60] using ci_udc, OUT ep- IN ep- STATUS ep- MAC 00:19:b8:00:00:02 HOST MAC 00:19:b8:00:00:01 high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet USB network up! Using usb_ether device TFTP from server 10.0.0.1; our IP address is 10.0.0.2 Filename 'imx28-airlino.dtb'. Load address: 0x40008000 Loading: ## 3.4 MiB/s done Bytes transferred = 18003 (4653 hex) CACHE: Misaligned operation at range [40008000, 4000c653] = CACHE: Misaligned operation at range [43fd0b08, 43fd0b60] CACHE: Misaligned operation at range [43fd0b14, 43fd0b60] using ci_udc, OUT ep- IN ep- STATUS ep- MAC 00:19:b8:00:00:02 HOST MAC 00:19:b8:00:00:01 high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet USB network up! Using usb_ether device TFTP from server 10.0.0.1; our IP address is 10.0.0.2 Filename 'imx28-airlino.dtb'. Load address: 0x40008000 Loading: ## 4.3 MiB/s done Bytes transferred = 18003 (4653 hex) CACHE: Misaligned operation at range [40008000, 4000c653] = CACHE: Misaligned operation at range [43fd0b08, 43fd0b60] CACHE: Misaligned operation at range [43fd0b14, 43fd0b60] using ci_udc, OUT ep- IN ep- STATUS ep- MAC 00:19:b8:00:00:02 HOST MAC 00:19:b8:00:00:01 high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet USB network up! Using usb_ether device TFTP from server 10.0.0.1; our IP address is 10.0.0.2 Filename 'imx28-airlino.dtb'. Load address: 0x40008000 Loading: ## 5.7 MiB/s done Bytes transferred = 18003 (4653 hex) CACHE: Misaligned operation at range [40008000, 4000c653] = CACHE: Misaligned operation at range [43fd0b08, 43fd0b60] CACHE: Misaligned operation at range [43fd0b14, 43fd0b60] using ci_udc, OUT ep- IN ep- STATUS ep- MAC 00:19:b8:00:00:02 HOST MAC 00:19:b8:00:00:01 high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet USB network up! Using usb_ether device TFTP from server 10.0.0.1; our IP address is 10.0.0.2 Filename 'imx28-airlino.dtb'. Load address: 0x40008000 Loading: ## 4.3 MiB/s done Bytes transferred = 18003 (4653 hex) CACHE: Misaligned operation at range [40008000, 4000c653] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] usb: ci_udc: Allocate the qTD list directly
On 07/02/2014 12:36 AM, Stephen Warren wrote:
On 07/01/2014 04:34 PM, Jörg Krause wrote:
On 07/01/2014 01:22 PM, Jörg Krause wrote:
On 07/01/2014 01:19 PM, Marek Vasut wrote:
[snip]
Can you edit arch/arm/cpu/arm926ejs/cache.c and change the debug() to
printf() , then re-test please ? I suspect this might trap something
still. Ah, and please test on u-boot-usb/master with this patch.
No additional output on the console.
What does this mean? Do you see warning messages prefixed with
CACHE: ?
No messages prefixed with CACHE: . Just the usual error message.
I am sorry, but maybe I edited arch/arm/cpu/arm926ejs/ in a another
branch and compiled in u-boot-usb. If I run now tftp with printf enabled
in arch/arm/cpu/arm926ejs/cache.c I get the following CACHE: messages:
CACHE: Misaligned operation at range [40008000, 4000c653]
CACHE: Misaligned operation at range [43fd0b0c, 43fd0b60]
That happens right when you first use the UDC driver right? If so, I
hope that [U-Boot] [PATCH 1/6] usb: ci_udc: fix ci_flush_{qh, qtd}
calls in ci_udc_probe() will fix that.
Checkout clean u-boot-usb/master, applied board specific patches and
applied the mentioned patch. Running tftp three times in a row:
= reset
resetting ...
HTLLCLLC
U-Boot 2014.07-rc3-g0b32423-dirty (Jul 02 2014 - 00:44:53)
CPU: Freescale i.MX28 rev1.2 at 454 MHz
BOOT: NAND, 3V3
DRAM: 64 MiB
NAND: 128 MiB
In:serial
Out: serial
Err: serial
Net: usb_ether [PRIME]
Hit any key to stop autoboot: 0
= tftp imx28-airlino.dtb
using ci_udc, OUT ep- IN ep- STATUS ep-
MAC 00:19:b8:00:00:02
HOST MAC 00:19:b8:00:00:01
high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet
USB network up!
Using usb_ether device
TFTP from server 10.0.0.1; our IP address is 10.0.0.2
Filename 'imx28-airlino.dtb'.
Load address: 0x40008000
Loading: ##
4.3 MiB/s
done
Bytes transferred = 18003 (4653 hex)
CACHE: Misaligned operation at range [40008000, 4000c653]
=
using ci_udc, OUT ep- IN ep- STATUS ep-
MAC 00:19:b8:00:00:02
HOST MAC 00:19:b8:00:00:01
high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet
USB network up!
Using usb_ether device
TFTP from server 10.0.0.1; our IP address is 10.0.0.2
Filename 'imx28-airlino.dtb'.
Load address: 0x40008000
Loading: ##
1.7 MiB/s
done
Bytes transferred = 18003 (4653 hex)
CACHE: Misaligned operation at range [40008000, 4000c653]
=
using ci_udc, OUT ep- IN ep- STATUS ep-
MAC 00:19:b8:00:00:02
HOST MAC 00:19:b8:00:00:01
high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet
USB network up!
Using usb_ether device
TFTP from server 10.0.0.1; our IP address is 10.0.0.2
Filename 'imx28-airlino.dtb'.
Load address: 0x40008000
Loading: ##
3.4 MiB/s
done
Bytes transferred = 18003 (4653 hex)
CACHE: Misaligned operation at range [40008000, 4000c653]
=
using ci_udc, OUT ep- IN ep- STATUS ep-
MAC 00:19:b8:00:00:02
HOST MAC 00:19:b8:00:00:01
high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet
ERROR: The remote end did not respond in time.
at drivers/usb/gadget/ether.c:2388/usb_eth_init()
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] usb: ci_udc: fixes and cleanups
On Wednesday, July 02, 2014 at 12:42:40 AM, Jörg Krause wrote: On 07/01/2014 11:36 PM, Stephen Warren wrote: [snip] Can you please try one more thing: Go back to u-boot-usb/master plus just your board support patches. Apply the following and test that: diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c index a6433e8d2d8d..13be1b73d3d1 100644 --- a/drivers/usb/gadget/ci_udc.c +++ b/drivers/usb/gadget/ci_udc.c @@ -209,9 +209,9 @@ ci_ep_alloc_request(struct usb_ep *ep, unsigned int gfp_flags) ci_req = memalign(ARCH_DMA_MINALIGN, sizeof(*ci_req)); if (!ci_req) return NULL; + memset(ci_req, 0, sizeof(*ci_req)); INIT_LIST_HEAD(ci_req-queue); - ci_req-b_buf = 0; if (num == 0) controller.ep0_req = ci_req; Thanks. Applied and tested with printf in cache.c enabled. ttp runs more than three times in row without a timeout error. It might really be worth if you ran git log --oneline and showed us exactly which patches were applied for each particular test. I am really getting lost sometimes ... = reset resetting ... HTLLCLLC U-Boot 2014.07-rc3-g88eca85-dirty (Jul 02 2014 - 00:39:20) CPU: Freescale i.MX28 rev1.2 at 454 MHz BOOT: NAND, 3V3 DRAM: 64 MiB NAND: 128 MiB In:serial Out: serial Err: serial Net: usb_ether [PRIME] Hit any key to stop autoboot: 0 = tftp imx28-airlino.dtb using ci_udc, OUT ep- IN ep- STATUS ep- MAC 00:19:b8:00:00:02 HOST MAC 00:19:b8:00:00:01 high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet USB network up! Using usb_ether device TFTP from server 10.0.0.1; our IP address is 10.0.0.2 Filename 'imx28-airlino.dtb'. Load address: 0x40008000 Loading: ## 2.1 MiB/s done Bytes transferred = 18003 (4653 hex) CACHE: Misaligned operation at range [40008000, 4000c653] This is a bug somewhere. = CACHE: Misaligned operation at range [43fd0b08, 43fd0b60] This is a bug. CACHE: Misaligned operation at range [43fd0b14, 43fd0b60] This is a bug. It would be nice to figure out where these unaligned accesses come from. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] usb: ci_udc: Allocate the qTD list directly
On 07/01/2014 04:47 PM, Jörg Krause wrote:
On 07/02/2014 12:36 AM, Stephen Warren wrote:
On 07/01/2014 04:34 PM, Jörg Krause wrote:
On 07/01/2014 01:22 PM, Jörg Krause wrote:
On 07/01/2014 01:19 PM, Marek Vasut wrote:
[snip]
Can you edit arch/arm/cpu/arm926ejs/cache.c and change the debug() to
printf() , then re-test please ? I suspect this might trap something
still. Ah, and please test on u-boot-usb/master with this patch.
No additional output on the console.
What does this mean? Do you see warning messages prefixed with
CACHE: ?
No messages prefixed with CACHE: . Just the usual error message.
I am sorry, but maybe I edited arch/arm/cpu/arm926ejs/ in a another
branch and compiled in u-boot-usb. If I run now tftp with printf enabled
in arch/arm/cpu/arm926ejs/cache.c I get the following CACHE: messages:
CACHE: Misaligned operation at range [40008000, 4000c653]
CACHE: Misaligned operation at range [43fd0b0c, 43fd0b60]
That happens right when you first use the UDC driver right? If so, I
hope that [U-Boot] [PATCH 1/6] usb: ci_udc: fix ci_flush_{qh, qtd}
calls in ci_udc_probe() will fix that.
Checkout clean u-boot-usb/master, applied board specific patches and
applied the mentioned patch. Running tftp three times in a row:
...
U-Boot 2014.07-rc3-g0b32423-dirty (Jul 02 2014 - 00:44:53)
...
= tftp imx28-airlino.dtb
...
Loading: ##
4.3 MiB/s
done
Bytes transferred = 18003 (4653 hex)
CACHE: Misaligned operation at range [40008000, 4000c653]
OK, that particular error happens well after the network transfer phase
of the tftp command, so is likely nothing to do with ci_udc. It'd be
great if you could track it down and fix it though.
Ah, I bet that 40008000 is your load address; the address that the
downloaded data is being copied to?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] usb: ci_udc: fixes and cleanups
On 07/01/2014 04:42 PM, Jörg Krause wrote: On 07/01/2014 11:36 PM, Stephen Warren wrote: [snip] Can you please try one more thing: Go back to u-boot-usb/master plus just your board support patches. Apply the following and test that: diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c index a6433e8d2d8d..13be1b73d3d1 100644 --- a/drivers/usb/gadget/ci_udc.c +++ b/drivers/usb/gadget/ci_udc.c @@ -209,9 +209,9 @@ ci_ep_alloc_request(struct usb_ep *ep, unsigned int gfp_flags) ci_req = memalign(ARCH_DMA_MINALIGN, sizeof(*ci_req)); if (!ci_req) return NULL; + memset(ci_req, 0, sizeof(*ci_req)); INIT_LIST_HEAD(ci_req-queue); - ci_req-b_buf = 0; if (num == 0) controller.ep0_req = ci_req; Thanks. Applied and tested with printf in cache.c enabled. ttp runs more than three times in row without a timeout error. Excellent, I guess that does make sense now. An equivalent of that change is included in patch 6/6, so that explains why you saw it fix your problem. s3c_udc also needs the change above, so I'll go send a patch for that. Thanks for testing, and it's great that we got to the bottom of this. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] usb: ci_udc: Allocate the qTD list directly
On 07/02/2014 12:51 AM, Stephen Warren wrote: [...] Loading: ## 4.3 MiB/s done Bytes transferred = 18003 (4653 hex) CACHE: Misaligned operation at range [40008000, 4000c653] OK, that particular error happens well after the network transfer phase of the tftp command, so is likely nothing to do with ci_udc. It'd be great if you could track it down and fix it though. Oh, any idea where to look at? Ah, I bet that 40008000 is your load address; the address that the downloaded data is being copied to? You're right, 40008000 is my load address. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] USB: gadget: atmel: zero out allocated requests
From: Stephen Warren swar...@nvidia.com A UDC's alloc_request method should zero out the newly allocated request. Ensure the Atmel driver does so. This issue was found by code inspection, following the investigation of an intermittent issue with ci_udc, which was tracked down to failing to zero out allocated requests following some of my changes. All other UDC drivers already zero out requests in one way or another. Signed-off-by: Stephen Warren swar...@nvidia.com --- drivers/usb/gadget/atmel_usba_udc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/atmel_usba_udc.c b/drivers/usb/gadget/atmel_usba_udc.c index c99208d10200..2c709738a3cb 100644 --- a/drivers/usb/gadget/atmel_usba_udc.c +++ b/drivers/usb/gadget/atmel_usba_udc.c @@ -314,7 +314,7 @@ usba_ep_alloc_request(struct usb_ep *_ep, gfp_t gfp_flags) DBG(DBG_GADGET, ep_alloc_request: %p, 0x%x\n, _ep, gfp_flags); - req = malloc(sizeof(struct usba_request)); + req = calloc(1, sizeof(struct usba_request)); if (!req) return NULL; -- 1.8.1.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] usb: ci_udc: Allocate the qTD list directly
On 07/01/2014 04:57 PM, Jörg Krause wrote: On 07/02/2014 12:51 AM, Stephen Warren wrote: [...] Loading: ## 4.3 MiB/s done Bytes transferred = 18003 (4653 hex) CACHE: Misaligned operation at range [40008000, 4000c653] OK, that particular error happens well after the network transfer phase of the tftp command, so is likely nothing to do with ci_udc. It'd be great if you could track it down and fix it though. Oh, any idea where to look at? My guess is common/cmd_net.c netboot_common() which does: /* flush cache */ flush_cache(load_addr, size); That seems pointless and wrong: * The Ethernet driver should do any cache management it requires as part of its low-level IO code, before copying the data to the load address. * A cache flush after copying data into RAM seems pointless. A cache *invalidate* /might/ make sense in some circumstances (e.g. after DMA before CPU reads), but that's not the case here. * The top-level TFTP code can't do the cache management, since it can't be sure that the file length is an exact multiple of the cache line size, and hence can't guarantee that cache management won't corrupt other adjacent data. That's why the cache management must be performed by the low-level network driver on its own aligned buffers. In summary, I think we should remove that flush_cache() call, but I'm not going to send a patch for that right before I go on vacation right before a release... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 20/25] arm: kirkwood: Remove some dead code from cpu.c
On Fri, Jun 27, 2014 at 11:55:06AM +0200, Stefan Roese wrote: All those functions removed with this patch are not accessed at all. So lets remove them. Signed-off-by: Stefan Roese s...@denx.de --- arch/arm/cpu/arm926ejs/kirkwood/cpu.c | 55 --- 1 file changed, 55 deletions(-) Up until this patch I have tested the series without problems on ib62x0. This is the last patch that I can apply and still boot the board. That said, for this patch and those before it: Tested-by: Luka Perkov l...@openwrt.org After the next patch in series is applied uboot does not come up - there is no output on the console. I've used kwboot in testing: $ sudo ./tools/kwboot -t -p -B 115200 -b u-boot.kwb /dev/ttyUSB0 Unrelated to this series I am going to mail a couple of kirkwood patches. Those can be applied without conflicts before or after this series. Luka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/t1040: fix i2c2 address on t1040qds and t104xrdb
Shengzhou, If u-boot uses 2nd I2C controller, it is good to have some comments. Please complete with four I2C controllers' offset. York On 07/01/2014 12:37 AM, Jain Priyanka-B32167 wrote: Hello Shengzhou, T1040 has two dual I2C controller. First Dual I2C Controller : 0x118 (first i2c bus), 0x1181000(second I2C bus) Second Dual I2C Controller : 0x119 (third i2c bus), 0x1191000(fourth I2C bus) My understanding is CONFIG_SYS_FSL_I2C_OFFSET is offset for first I2C controller and CONFIG_SYS_FSL_I2C2_OFFSET is offset for second I2C controller. Have you checked for dual I2C controller, CONFIG_SYS_FSL_I2C2_OFFSET implies offset for second I2C bus, not the controller? Regards Priyanka -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Shengzhou Liu Sent: Tuesday, July 01, 2014 11:32 AM To: u-boot@lists.denx.de; Sun York-R58495 Subject: [U-Boot] [PATCH] powerpc/t1040: fix i2c2 address on t1040qds and t104xrdb The base address of I2C2 is 0x118100 instead of 0x119000. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- include/configs/T1040QDS.h | 2 +- include/configs/T104xRDB.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/T1040QDS.h b/include/configs/T1040QDS.h index 2215ac8..5b75562 100644 --- a/include/configs/T1040QDS.h +++ b/include/configs/T1040QDS.h @@ -443,7 +443,7 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_SYS_FSL_I2C2_SPEED 5 /* I2C speed in Hz */ #define CONFIG_SYS_FSL_I2C2_SLAVE 0x7F #define CONFIG_SYS_FSL_I2C_OFFSET 0x118000 -#define CONFIG_SYS_FSL_I2C2_OFFSET 0x119000 +#define CONFIG_SYS_FSL_I2C2_OFFSET 0x118100 #define I2C_MUX_PCA_ADDR0x77 #define I2C_MUX_PCA_ADDR_PRI0x77 /* Primary Mux*/ diff --git a/include/configs/T104xRDB.h b/include/configs/T104xRDB.h index e564cb7..e265786 100644 --- a/include/configs/T104xRDB.h +++ b/include/configs/T104xRDB.h @@ -441,7 +441,7 @@ #define CONFIG_SYS_FSL_I2C2_SPEED 40 /* I2C speed in Hz */ #define CONFIG_SYS_FSL_I2C2_SLAVE 0x7F #define CONFIG_SYS_FSL_I2C_OFFSET 0x118000 -#define CONFIG_SYS_FSL_I2C2_OFFSET 0x119000 +#define CONFIG_SYS_FSL_I2C2_OFFSET 0x118100 /* I2C bus multiplexer */ #define I2C_MUX_PCA_ADDR0x70 -- 1.8.0 ___ 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] kirkwood: cosmetic: style fixes in kwbimage.cfg files
When diffing through the various kwbimage.cfg files only show relevant changes. Signed-off-by: Luka Perkov l...@openwrt.org CC: Prafulla Wadaskar prafu...@marvell.com CC: Stefan Roese s...@denx.de --- board/iomega/iconnect/kwbimage.cfg | 4 ++-- board/raidsonic/ib62x0/kwbimage.cfg | 22 +++--- 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/board/iomega/iconnect/kwbimage.cfg b/board/iomega/iconnect/kwbimage.cfg index 3c63a03..f4260fa 100644 --- a/board/iomega/iconnect/kwbimage.cfg +++ b/board/iomega/iconnect/kwbimage.cfg @@ -20,7 +20,7 @@ NAND_PAGE_SIZE0x0800 # Configure RGMII-0 interface pad voltage to 1.8V DATA 0xffd100e0 0x1b1b1b9b -#Dram initalization for SINGLE x16 CL=5 @ 400MHz +# Dram initalization for SINGLE x16 CL=5 @ 400MHz DATA 0xffd01400 0x43000c30 # DDR Configuration register # bit13-0: 0xc30, (3120 DDR2 clks refresh rate) # bit23-14: 0x0, @@ -87,7 +87,7 @@ DATA 0xffd0141c 0x0c52# DDR Mode # bit6-4: 0x4, CL=5 # bit7: 0x0, TestMode=0 normal # bit8: 0x0, DLL reset=0 normal -# bit11-9: 0x6, auto-precharge write recovery +# bit11-9: 0x6, auto-precharge write recovery # bit12:0x0, PD must be zero # bit31-13: 0x0, required diff --git a/board/raidsonic/ib62x0/kwbimage.cfg b/board/raidsonic/ib62x0/kwbimage.cfg index 596071f..ec00c15 100644 --- a/board/raidsonic/ib62x0/kwbimage.cfg +++ b/board/raidsonic/ib62x0/kwbimage.cfg @@ -11,7 +11,7 @@ # # Boot Media configurations -BOOT_FROM nand# change from nand to uart if building UART image +BOOT_FROM nand NAND_ECC_MODE default NAND_PAGE_SIZE 0x0800 @@ -21,12 +21,12 @@ NAND_PAGE_SIZE 0x0800 # Configure RGMII-0 interface pad voltage to 1.8V DATA 0xffd100e0 0x1b1b1b9b -#Dram initalization for SINGLE x16 CL=5 @ 400MHz +# Dram initalization for SINGLE x16 CL=5 @ 400MHz DATA 0xffd01400 0x43000c30 # DDR Configuration register # bit13-0: 0xc30, (3120 DDR2 clks refresh rate) # bit23-14: 0x0, -# bit24:0x1, enable exit self refresh mode on DDR access -# bit25:0x1, required +# bit24:0x1, enable exit self refresh mode on DDR access +# bit25:0x1, required # bit29-26: 0x0, # bit31-30: 0x1, @@ -64,10 +64,10 @@ DATA 0xffd01410 0x000c # DDR Address Control # bit3-2: 11, Cs0size (1Gb) # bit5-4: 00, Cs1width (x8) # bit7-6: 11, Cs1size (1Gb) -# bit9-8: 00, Cs2width (nonexistent -# bit11-10: 00, Cs2size (nonexistent -# bit13-12: 00, Cs3width (nonexistent -# bit15-14: 00, Cs3size (nonexistent +# bit9-8: 00, Cs2width (nonexistent) +# bit11-10: 00, Cs2size (nonexistent) +# bit13-12: 00, Cs3width (nonexistent) +# bit15-14: 00, Cs3size (nonexistent) # bit16:0, Cs0AddrSel # bit17:0, Cs1AddrSel # bit18:0, Cs2AddrSel @@ -88,7 +88,7 @@ DATA 0xffd0141c 0x0c52# DDR Mode # bit6-4: 0x4, CL=5 # bit7: 0x0, TestMode=0 normal # bit8: 0x0, DLL reset=0 normal -# bit11-9: 0x6, auto-precharge write recovery +# bit11-9: 0x6, auto-precharge write recovery # bit12:0x0, PD must be zero # bit31-13: 0x0, required @@ -148,8 +148,8 @@ DATA 0xffd0149c 0xe803 # CPU ODT Control DATA 0xffd01480 0x0001 # DDR Initialization Control # bit0: 0x1, enable DDR init upon this register write -DATA 0xFFD20134 0x # L2 RAM Timing 0 Register -DATA 0xFFD20138 0x # L2 RAM Timing 1 Register +DATA 0xffd20134 0x # L2 RAM Timing 0 Register +DATA 0xffd20138 0x # L2 RAM Timing 1 Register # End of Header extension DATA 0x0 0x0 -- 2.0.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: kirkwood: fix cpu info for 6282 device id
Signed-off-by: Luka Perkov l...@openwrt.org
CC: Prafulla Wadaskar prafu...@marvell.com
CC: Stefan Roese s...@denx.de
---
arch/arm/cpu/arm926ejs/kirkwood/cpu.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/kirkwood/cpu.c
b/arch/arm/cpu/arm926ejs/kirkwood/cpu.c
index da80240..312d2b2 100644
--- a/arch/arm/cpu/arm926ejs/kirkwood/cpu.c
+++ b/arch/arm/cpu/arm926ejs/kirkwood/cpu.c
@@ -252,7 +252,7 @@ static void kw_sysrst_check(void)
#if defined(CONFIG_DISPLAY_CPUINFO)
int print_cpuinfo(void)
{
- char *rev;
+ char *rev = ??;
u16 devid = (readl(KW_REG_PCIE_DEVID) 16) 0x;
u8 revid = readl(KW_REG_PCIE_REVID) 0xff;
@@ -263,7 +263,13 @@ int print_cpuinfo(void)
switch (revid) {
case 0:
- rev = Z0;
+ if (devid == 0x6281)
+ rev = Z0;
+ else if (devid == 0x6282)
+ rev = A0;
+ break;
+ case 1:
+ rev = A1;
break;
case 2:
rev = A0;
@@ -272,7 +278,6 @@ int print_cpuinfo(void)
rev = A1;
break;
default:
- rev = ??;
break;
}
--
2.0.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] kirkwood: define empty CONFIG_MVGBE_PORTS by default
Each board with defines it's own set of values. If we do not define
CONFIG_MVGBE_PORTS we will hit following error:
mvgbe.c: In function 'mvgbe_initialize':
mvgbe.c:700:34: error: 'CONFIG_MVGBE_PORTS' undeclared (first use in this
function)
u8 used_ports[MAX_MVGBE_DEVS] = CONFIG_MVGBE_PORTS;
This patch fixes above described problem.
Signed-off-by: Luka Perkov l...@openwrt.org
CC: Prafulla Wadaskar prafu...@marvell.com
CC: Stefan Roese s...@denx.de
---
drivers/net/mvgbe.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/mvgbe.c b/drivers/net/mvgbe.c
index 0cd06b6..d558f59 100644
--- a/drivers/net/mvgbe.c
+++ b/drivers/net/mvgbe.c
@@ -35,6 +35,10 @@
DECLARE_GLOBAL_DATA_PTR;
+#ifndef CONFIG_MVGBE_PORTS
+# define CONFIG_MVGBE_PORTS {0, 0}
+#endif
+
#define MV_PHY_ADR_REQUEST 0xee
#define MVGBE_SMI_REG (((struct mvgbe_registers *)MVGBE0_BASE)-smi)
--
2.0.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] kirkwood: ib62x0: add CONFIG_SYS_GENERIC_BOARD define
Signed-off-by: Luka Perkov l...@openwrt.org CC: Prafulla Wadaskar prafu...@marvell.com CC: Stefan Roese s...@denx.de --- include/configs/ib62x0.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/ib62x0.h b/include/configs/ib62x0.h index 186fd35..cd38577 100644 --- a/include/configs/ib62x0.h +++ b/include/configs/ib62x0.h @@ -9,6 +9,8 @@ #ifndef _CONFIG_IB62x0_H #define _CONFIG_IB62x0_H +#define CONFIG_SYS_GENERIC_BOARD + /* * Version number information */ -- 2.0.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB: gadget: atmel: zero out allocated requests
Hi Stephen Warren, On 07/02/2014 06:59 AM, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com A UDC's alloc_request method should zero out the newly allocated request. Ensure the Atmel driver does so. This issue was found by code inspection, following the investigation of an intermittent issue with ci_udc, which was tracked down to failing to zero out allocated requests following some of my changes. All other UDC drivers already zero out requests in one way or another. Signed-off-by: Stephen Warren swar...@nvidia.com --- drivers/usb/gadget/atmel_usba_udc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Thanks. Acked-by: Bo Shen voice.s...@atmel.com diff --git a/drivers/usb/gadget/atmel_usba_udc.c b/drivers/usb/gadget/atmel_usba_udc.c index c99208d10200..2c709738a3cb 100644 --- a/drivers/usb/gadget/atmel_usba_udc.c +++ b/drivers/usb/gadget/atmel_usba_udc.c @@ -314,7 +314,7 @@ usba_ep_alloc_request(struct usb_ep *_ep, gfp_t gfp_flags) DBG(DBG_GADGET, ep_alloc_request: %p, 0x%x\n, _ep, gfp_flags); - req = malloc(sizeof(struct usba_request)); + req = calloc(1, sizeof(struct usba_request)); if (!req) return NULL; Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] ARM: tegra: Disable VPR
Tom, is this patch ok for you? If yes, do you plan to merge it? On Sat, Jun 28, 2014 at 1:21 AM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Jun 24, 2014 at 11:45:29AM +0900, Alexandre Courbot wrote: From: Bryan Wu pe...@nvidia.com On Tegra114 and Tegra124 platforms, certain display-related registers cannot be accessed unless the VPR registers are programmed. For bootloader, we probably don't care about VPR, so we disable it (which counts as programming it, and allows those display-related registers to be accessed. This patch is based on the commit 5f499646c83ba08079f3fdff6591f638a0ce4c0c in Chromium OS U-Boot project. Signed-off-by: Andrew Chew ac...@nvidia.com Signed-off-by: Jimmy Zhang jimmzh...@nvidia.com Signed-off-by: Bryan Wu pe...@nvidia.com [acourbot: ensure write went through, vpr.c style changes] Signed-off-by: Alexandre Courbot acour...@nvidia.com Reviewed-by: Stephen Warren swar...@nvidia.com Cc: Tom Warren twar...@nvidia.com Cc: Stephen Warren swar...@nvidia.com Cc: Terje Bergstrom tbergst...@nvidia.com --- Changes since v2: - Remove useless switch case Changes since v1: - Use proper defines for fields values - Move MC layout to T124 arch as it is exclusive to it - Only compile VPR support if T124 is enabled arch/arm/cpu/tegra-common/Makefile | 1 + arch/arm/cpu/tegra-common/ap.c | 3 ++ arch/arm/cpu/tegra-common/vpr.c | 35 +++ arch/arm/include/asm/arch-tegra/ap.h| 9 ++ arch/arm/include/asm/arch-tegra124/mc.h | 49 + 5 files changed, 97 insertions(+) create mode 100644 arch/arm/cpu/tegra-common/vpr.c create mode 100644 arch/arm/include/asm/arch-tegra124/mc.h Tested-by: Thierry Reding tred...@nvidia.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
