[U-Boot] [PATCH] i2c, omap24xx: add i2c deblock sequenz
If a bus busy is detected when intializing the driver,
toggle 9 times the scl pin. Therefore enable the test mode
of the controller, in which the scl, sda pins can be
controlled manually.
Tested on the siemens boards pxm2, rut and dxr2.
Signed-off-by: Heiko Schocher
Cc: Tom Rini
Cc: Hannes Petermaier
Cc: Lubomir Popov
Cc: Steve Sakoman
Cc: Sandeep Paulraj
Cc: Vincent Stehlé
Cc: Samuel Egli
---
drivers/i2c/omap24xx_i2c.c | 57 ++
1 file changed, 57 insertions(+)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index a39b591..0f1e35c 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -153,11 +153,60 @@ static uint omap24_i2c_setspeed(struct i2c_adapter *adap,
uint speed)
return 0;
}
+
+static void omap24_i2c_deblock(struct i2c_adapter *adap)
+{
+ struct i2c *i2c_base = omap24_get_base(adap);
+ int i;
+ u16 systest;
+ u16 orgsystest;
+
+ /* set test mode ST_EN = 1 */
+ orgsystest = readw(&i2c_base->systest);
+ systest = orgsystest;
+ /* enable testmode */
+ systest |= I2C_SYSTEST_ST_EN;
+ writew(systest, &i2c_base->systest);
+ systest &= ~I2C_SYSTEST_TMODE_MASK;
+ systest |= 3 << I2C_SYSTEST_TMODE_SHIFT;
+ writew(systest, &i2c_base->systest);
+
+ /* set SCL, SDA = 1 */
+ systest |= I2C_SYSTEST_SCL_O | I2C_SYSTEST_SDA_O;
+ writew(systest, &i2c_base->systest);
+ udelay(10);
+
+ /* toggle scl 9 clocks */
+ for (i = 0; i < 9; i++) {
+ /* SCL = 0 */
+ systest &= ~I2C_SYSTEST_SCL_O;
+ writew(systest, &i2c_base->systest);
+ udelay(10);
+ /* SCL = 1 */
+ systest |= I2C_SYSTEST_SCL_O;
+ writew(systest, &i2c_base->systest);
+ udelay(10);
+ }
+
+ /* send stop */
+ systest &= ~I2C_SYSTEST_SDA_O;
+ writew(systest, &i2c_base->systest);
+ udelay(10);
+ systest |= I2C_SYSTEST_SCL_O | I2C_SYSTEST_SDA_O;
+ writew(systest, &i2c_base->systest);
+ udelay(10);
+
+ /* restore original mode */
+ writew(orgsystest, &i2c_base->systest);
+}
+
static void omap24_i2c_init(struct i2c_adapter *adap, int speed, int slaveadd)
{
struct i2c *i2c_base = omap24_get_base(adap);
int timeout = I2C_TIMEOUT;
+ int deblock = 1;
+retry:
if (readw(&i2c_base->con) & I2C_CON_EN) {
writew(0, &i2c_base->con);
udelay(5);
@@ -194,6 +243,14 @@ static void omap24_i2c_init(struct i2c_adapter *adap, int
speed, int slaveadd)
udelay(1000);
flush_fifo(adap);
writew(0x, &i2c_base->stat);
+
+ /* Handle possible failed I2C state */
+ if (wait_for_bb(adap))
+ if (deblock == 1) {
+ omap24_i2c_deblock(adap);
+ deblock = 0;
+ goto retry;
+ }
}
static void flush_fifo(struct i2c_adapter *adap)
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Why spi flash probe runs twice on Xilinx Zynq board ?
Hello Abdul Basit: > .I noticed that the following lines are coming twice: > > SF: Detected S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB > > This corresponds to the function spi_flash_probe from > drivers/mtd/spi/spi_flash.c > > I need to know: > > 1- Why it is probed twice? > 2- The name and location of the file from where it is called (twice). > 3- The second time it is being probed is considerably slow, why it is so? It is hard to tell what is happening here because so much information is missing, but I will venture a few guesses: The first probe probably occurs when the environment is read, in env_sf.c; I am assuming that the environment is located in QSPI flash. The second probe is probably due to a boot command which reads the Linux kernel from QSPI flash, and runs 'sf probe' from cmd_sf.c; try running 'printenv'. The flash probe itself should always take the same (rather short) amount of time. Reading a Linux kernel from flash is slower than reading a small environment block, though, because the kernel is much bigger. Hope that helps, Thomas Betker ___ 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/27/2014 10:20 PM, Jeroen Hofstee wrote:
Hello Przemyslaw,
On 27-06-14 13:34, 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
Cc: Minkyu Kang
Cc: Jean-Christophe PLAGNIOL-VILLARD
Cc: Albert ARIBAUD
Cc: Tom Rini
---
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
+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..
Regards,
Jeroen
Thanks, I will add the __weak prefix there.
The prototype of this new function is in file common.h,
so this is type safe.
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.
Thank you,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] please pull u-boot-samsung master
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 -- Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Issues configuring Samsung K4B2G1646Q DDR3 on am3352
Hi Tom, I observed some issues on our Siemens CPU boards with am3352 configuring 2Gbit DDR3 from Samsung (K4B2G1646Q). Before we used a 1 Gbit DDR3 memory from Samsung as well and other manufacturers that worked fine. With 2 Gbit I noticed, after some trial and error (and adapting tRFC parameters to the new size), that for Samsung I need to wait some extra time (around 200us) after calling the configuration function config_ddr(...) before proceeding. This is necessary when a soft reset happens but not when the device makes a power cycle. And this is only an issue for Samsung K4B2G1646Q. We also have some hardware with 2Gbit DDR3 from ISSI that don't see this issue. From a datasheet perspective there shouldn't be any significant differences but of course I cannot vouch for it. So my question is now if you know somebody that observed similar issues with K4B2G1646Q DDR3 and if there is a better solution than adding a udelay(200) after the configuration call? I don't understand the issue completely, so I guess there might be a better solution out there. Kind regards Sam Siemens Schweiz AG, Building Technologies Division, International Headquarters Infrastructure & Cities Sector Building Technologies Division Control Products & Systems IC BT CPS R&D ZG FW CCP Gubelstrasse 22 6300 Zug, Schweiz Tel: +41 41 724-3024 mailto:samuel.e...@siemens.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC
On Sunday, June 29, 2014 at 10:33:26 PM, Jörg Krause wrote:
> On 06/28/2014 10:53 PM, Jörg Krause wrote:
> > [snip]
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
>
> I did some tests this weekend on u-boot-usb/master branch.
>
> If I run "env default -a" and then "saveenv" after a reset, I get the
> same error as running three time "tftp file" in a row.
> Log:
>
> U-Boot 2014.07-rc3-g18e0313-dirty (Jun 29 2014 - 21:56:02)
>
> 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
> => env default -a
> ## Resetting to default environment
> => saveenv
> Saving Environment to NAND...
> Erasing NAND...
> Erasing at 0x36 -- 100% complete.
> Writing to NAND... OK
> => tftp rootfs.ubifs
> 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()
>
> "env default -a" removes stdin, stdout, stderr, and ver from the output
> of "printenv".
>
> Looking at drivers/usb/gadget/ether.c:usb_eth_init I found the
> environment variable "cdc_connect_timeout". I played a little bit with
> the settings.
>
> 1) Using "setenv cdc_connect_timeout 1" from the command line: tftp runs
> more then three time in a row. Actually I can run tftp more than ten
> times in row and it produces no error. I tested the values 1, 3, and 15
> for cdc_connect_timeout.
>
> 2) Setting #define CONFIG_EXTRA_ENV_SETTINGS "cdc_connect_timeout=1\0" \
> in my config header file. This does not help and produces the error on
> the fourth run of tfpd. Tested with values 1 and 3 for timeout.
I just tested the CDC ethernet on M28EVK with u-boot-usb/master and loading
64MiB file from a TFTP server running on a local machine. It seems that for
some
reason, in the udc_gadget_handle_interrupts() or somewhere there, it starts not
getting interrupts. Can you try with this change:
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index a6433e8..1af6d12 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -727,14 +727,8 @@ void udc_irq(void)
int usb_gadget_handle_interrupts(void)
{
- u32 value;
- struct ci_udc *udc = (struct ci_udc *)controller.ctrl->hcor;
-
- value = readl(&udc->usbsts);
- if (value)
- udc_irq();
-
- return value;
+ udc_irq();
+ return 0;
}
void udc_disconnect(void)
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 2/2] ARM: atmel: sama5d3xek: enable NOR flash support
Hi Bo, > -/* No NOR flash */ > +/* NOR flash */ > +#define CONFIG_CMD_FLASH > + > +#ifdef CONFIG_CMD_FLASH > +#define CONFIG_SYS_FLASH_CFI > +#define CONFIG_FLASH_CFI_DRIVER > +#define CONFIG_SYS_FLASH_BASE0x1000 > +#define CONFIG_SYS_MAX_FLASH_SECT0x2 > +#define CONFIG_SYS_MAX_FLASH_BANKS 1 > +#else > #define CONFIG_SYS_NO_FLASH > +#endif The NOR flash device on the SAMA5D3x CPU modules supports hardware sector protection and according to the flash datasheet: "All blocks power-up in a locked state to protect array data from being altered during power transitions". In order to make your patch set work: #define CONFIG_SYS_FLASH_PROTECTION needs adding into the include/configs/sama5d3xek.h file. Andy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] m68k: Fix bug, "address of" operator was forgotten
in_be16() shall be passed a pointer to register and not its value. This is clearly a typo resulting in a wrong memory access, so fix it. Cc: Alison Wang , Jason Jin Signed-off-by: Vasili Galka --- arch/m68k/cpu/mcf5445x/speed.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/m68k/cpu/mcf5445x/speed.c b/arch/m68k/cpu/mcf5445x/speed.c index 07a9b35..4e363a4 100644 --- a/arch/m68k/cpu/mcf5445x/speed.c +++ b/arch/m68k/cpu/mcf5445x/speed.c @@ -115,7 +115,7 @@ void setup_5441x_clocks(void) gd->cpu_clk = vco / temp; /* cpu clock */ gd->arch.flb_clk = vco / temp; /* FlexBus clock */ gd->arch.flb_clk >>= 1; - if (in_be16(ccm->misccr2) & 2) /* fsys/4 */ + if (in_be16(&ccm->misccr2) & 2) /* fsys/4 */ gd->arch.flb_clk >>= 1; temp = ((pdr & PLL_DR_OUTDIV2_BITS) >> 5) + 1; -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] m68k: Fix incorrect memory access on M5235
The csarX and cscrX registers in the fbcs_t struct are 16-bit for CONFIG_M5235 and 32-bit wide otherwise. The code in cpu_init.c accessed them always as 32-bit, effectively creating a wrong memory access on M5235. Fixed that by choosing out_be16/out_be32 depending on whether CONFIG_M5235 is defined or not. Cc: Jason Jin Signed-off-by: Vasili Galka --- arch/m68k/cpu/mcf523x/cpu_init.c | 39 ++--- 1 files changed, 23 insertions(+), 16 deletions(-) diff --git a/arch/m68k/cpu/mcf523x/cpu_init.c b/arch/m68k/cpu/mcf523x/cpu_init.c index 5a78954..af1fd56 100644 --- a/arch/m68k/cpu/mcf523x/cpu_init.c +++ b/arch/m68k/cpu/mcf523x/cpu_init.c @@ -20,6 +20,13 @@ #include #endif +/* The registers in fbcs_t struct can be 16-bit for CONFIG_M5235 or 32-bit wide otherwise. */ +#ifdef CONFIG_M5235 +#define out_be_fbcs_regout_be16 +#else +#define out_be_fbcs_regout_be32 +#endif + /* * Breath some life into the CPU... * @@ -45,57 +52,57 @@ void cpu_init_f(void) out_8(&gpio->par_cs, 0); #if (defined(CONFIG_SYS_CS0_BASE) && defined(CONFIG_SYS_CS0_MASK) && defined(CONFIG_SYS_CS0_CTRL)) - out_be32(&fbcs->csar0, CONFIG_SYS_CS0_BASE); - out_be32(&fbcs->cscr0, CONFIG_SYS_CS0_CTRL); + out_be_fbcs_reg(&fbcs->csar0, CONFIG_SYS_CS0_BASE); + out_be_fbcs_reg(&fbcs->cscr0, CONFIG_SYS_CS0_CTRL); out_be32(&fbcs->csmr0, CONFIG_SYS_CS0_MASK); #endif #if (defined(CONFIG_SYS_CS1_BASE) && defined(CONFIG_SYS_CS1_MASK) && defined(CONFIG_SYS_CS1_CTRL)) setbits_8(&gpio->par_cs, GPIO_PAR_CS_CS1); - out_be32(&fbcs->csar1, CONFIG_SYS_CS1_BASE); - out_be32(&fbcs->cscr1, CONFIG_SYS_CS1_CTRL); + out_be_fbcs_reg(&fbcs->csar1, CONFIG_SYS_CS1_BASE); + out_be_fbcs_reg(&fbcs->cscr1, CONFIG_SYS_CS1_CTRL); out_be32(&fbcs->csmr1, CONFIG_SYS_CS1_MASK); #endif #if (defined(CONFIG_SYS_CS2_BASE) && defined(CONFIG_SYS_CS2_MASK) && defined(CONFIG_SYS_CS2_CTRL)) setbits_8(&gpio->par_cs, GPIO_PAR_CS_CS2); - out_be32(&fbcs->csar2, CONFIG_SYS_CS2_BASE); - out_be32(&fbcs->cscr2, CONFIG_SYS_CS2_CTRL); + out_be_fbcs_reg(&fbcs->csar2, CONFIG_SYS_CS2_BASE); + out_be_fbcs_reg(&fbcs->cscr2, CONFIG_SYS_CS2_CTRL); out_be32(&fbcs->csmr2, CONFIG_SYS_CS2_MASK); #endif #if (defined(CONFIG_SYS_CS3_BASE) && defined(CONFIG_SYS_CS3_MASK) && defined(CONFIG_SYS_CS3_CTRL)) setbits_8(&gpio->par_cs, GPIO_PAR_CS_CS3); - out_be32(&fbcs->csar3, CONFIG_SYS_CS3_BASE); - out_be32(&fbcs->cscr3, CONFIG_SYS_CS3_CTRL); + out_be_fbcs_reg(&fbcs->csar3, CONFIG_SYS_CS3_BASE); + out_be_fbcs_reg(&fbcs->cscr3, CONFIG_SYS_CS3_CTRL); out_be32(&fbcs->csmr3, CONFIG_SYS_CS3_MASK); #endif #if (defined(CONFIG_SYS_CS4_BASE) && defined(CONFIG_SYS_CS4_MASK) && defined(CONFIG_SYS_CS4_CTRL)) setbits_8(&gpio->par_cs, GPIO_PAR_CS_CS4); - out_be32(&fbcs->csar4, CONFIG_SYS_CS4_BASE); - out_be32(&fbcs->cscr4, CONFIG_SYS_CS4_CTRL); + out_be_fbcs_reg(&fbcs->csar4, CONFIG_SYS_CS4_BASE); + out_be_fbcs_reg(&fbcs->cscr4, CONFIG_SYS_CS4_CTRL); out_be32(&fbcs->csmr4, CONFIG_SYS_CS4_MASK); #endif #if (defined(CONFIG_SYS_CS5_BASE) && defined(CONFIG_SYS_CS5_MASK) && defined(CONFIG_SYS_CS5_CTRL)) setbits_8(&gpio->par_cs, GPIO_PAR_CS_CS5); - out_be32(&fbcs->csar5, CONFIG_SYS_CS5_BASE); - out_be32(&fbcs->cscr5, CONFIG_SYS_CS5_CTRL); + out_be_fbcs_reg(&fbcs->csar5, CONFIG_SYS_CS5_BASE); + out_be_fbcs_reg(&fbcs->cscr5, CONFIG_SYS_CS5_CTRL); out_be32(&fbcs->csmr5, CONFIG_SYS_CS5_MASK); #endif #if (defined(CONFIG_SYS_CS6_BASE) && defined(CONFIG_SYS_CS6_MASK) && defined(CONFIG_SYS_CS6_CTRL)) setbits_8(&gpio->par_cs, GPIO_PAR_CS_CS6); - out_be32(&fbcs->csar6, CONFIG_SYS_CS6_BASE); - out_be32(&fbcs->cscr6, CONFIG_SYS_CS6_CTRL); + out_be_fbcs_reg(&fbcs->csar6, CONFIG_SYS_CS6_BASE); + out_be_fbcs_reg(&fbcs->cscr6, CONFIG_SYS_CS6_CTRL); out_be32(&fbcs->csmr6, CONFIG_SYS_CS6_MASK); #endif #if (defined(CONFIG_SYS_CS7_BASE) && defined(CONFIG_SYS_CS7_MASK) && defined(CONFIG_SYS_CS7_CTRL)) setbits_8(&gpio->par_cs, GPIO_PAR_CS_CS7); - out_be32(&fbcs->csar7, CONFIG_SYS_CS7_BASE); - out_be32(&fbcs->cscr7, CONFIG_SYS_CS7_CTRL); + out_be_fbcs_reg(&fbcs->csar7, CONFIG_SYS_CS7_BASE); + out_be_fbcs_reg(&fbcs->cscr7, CONFIG_SYS_CS7_CTRL); out_be32(&fbcs->csmr7, CONFIG_SYS_CS7_MASK); #endif -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] blackfin: Fix warning about undefined function
get_sclk() was not defined in bfin_wdt.c, include the corresponding header. Cc: Sonic Zhang Signed-off-by: Vasili Galka --- drivers/watchdog/bfin_wdt.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/watchdog/bfin_wdt.c b/drivers/watchdog/bfin_wdt.c index 7a6756b..6a8db59 100644 --- a/drivers/watchdog/bfin_wdt.c +++ b/drivers/watchdog/bfin_wdt.c @@ -9,6 +9,7 @@ #include #include #include +#include #include void hw_watchdog_reset(void) -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] blackfin: Add more dcache functions
Add invalidate_dcache_range() and flush_dcache_range() for the blackfin
architecture. Such functions already exist on this arch with different
names, so just forward the call.
This fixes the build of bf609-ezkit board as it uses
drivers/net/designware.c which requires the above functions.
Cc: Sonic Zhang , Alexey Brodkin
Signed-off-by: Vasili Galka
---
arch/blackfin/lib/cache.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/blackfin/lib/cache.c b/arch/blackfin/lib/cache.c
index 0a321a4..e8a0cb5 100644
--- a/arch/blackfin/lib/cache.c
+++ b/arch/blackfin/lib/cache.c
@@ -111,3 +111,13 @@ int dcache_status(void)
{
return bfin_read_DMEM_CONTROL() & ACACHE_BCACHE;
}
+
+void invalidate_dcache_range(unsigned long start, unsigned long stop)
+{
+ blackfin_dcache_flush_invalidate_range((const void *)start, (const void
*)stop);
+}
+
+void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+ blackfin_dcache_flush_range((const void *)start, (const void *)stop);
+}
--
1.7.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: atmel: sama5d3xek: enable NOR flash support
Hi Andy, On 06/30/2014 05:55 PM, Andy Pont wrote: Hi Bo, -/* No NOR flash */ +/* NOR flash */ +#define CONFIG_CMD_FLASH + +#ifdef CONFIG_CMD_FLASH +#define CONFIG_SYS_FLASH_CFI +#define CONFIG_FLASH_CFI_DRIVER +#define CONFIG_SYS_FLASH_BASE 0x1000 +#define CONFIG_SYS_MAX_FLASH_SECT 0x2 +#define CONFIG_SYS_MAX_FLASH_BANKS 1 +#else #define CONFIG_SYS_NO_FLASH +#endif The NOR flash device on the SAMA5D3x CPU modules supports hardware sector protection and according to the flash datasheet: "All blocks power-up in a locked state to protect array data from being altered during power transitions". In order to make your patch set work: #define CONFIG_SYS_FLASH_PROTECTION needs adding into the include/configs/sama5d3xek.h file. Thanks for your information. I will add it into next version. Thanks again. Andy. Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Why spi flash probe runs twice on Xilinx Zynq board ?
I guess - your using Xilinx github u-boot-xlnx The reason for two prints is like, for 1) Initial probe print, by default done in env calls 2) Added in sf probe again on auto-boot commands [1] [1] https://github.com/Xilinx/u-boot-xlnx/blob/master/include/configs/zynq-common.h On Sat, Jun 28, 2014 at 10:51 PM, Heshsham Abdul Basit wrote: > Hi, > > I am re-sending this email because earlier I forgot to put the subject line > properly. I am struggling to figure out few things in u-boot , but I failed > to get a good resource or help. > > This is a section of the log from u-boot running on Avnet Microzed board: > > > [Thu Jun 26 17:40:53.656 2014] > > [Thu Jun 26 17:40:53.656 2014] > > [Thu Jun 26 17:40:53.656 2014] U-Boot 2013.07 (Jun 26 2014 - 17:34:41) > > [Thu Jun 26 17:40:53.656 2014] > > [Thu Jun 26 17:40:53.656 2014] 1 GiB > > [Thu Jun 26 17:40:53.671 2014] SF: Detected > S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB > > [Thu Jun 26 17:40:53.703 2014] *** Warning - bad CRC, using default > environment > > [Thu Jun 26 17:40:53.703 2014] > > [Thu Jun 26 17:40:53.703 2014] In:serial > > [Thu Jun 26 17:40:53.703 2014] Out: serial > > [Thu Jun 26 17:40:53.703 2014] Err: serial > > [Thu Jun 26 17:40:53.703 2014] U-BOOT for suheb_24 > > [Thu Jun 26 17:40:53.703 2014] > > [Thu Jun 26 17:40:53.703 2014] > > [Thu Jun 26 17:40:53.703 2014] SF: Detected > S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB > > [Thu Jun 26 17:40:54.453 2014] SF: 5242880 bytes @ 0x52 Read: OK > > [Thu Jun 26 17:40:54.453 2014] Description: PetaLinux Kernel > > [Thu Jun 26 17:40:54.453 2014] 0x01f0 > > [Thu Jun 26 17:40:54.453 2014] 4620145 Bytes = 4.4 MiB > > [Thu Jun 26 17:40:54.453 2014] Description: Flattened Device Tree blob > > [Thu Jun 26 17:40:54.453 2014] 0x01468114 > > [Thu Jun 26 17:40:54.453 2014] 9766 Bytes = 9.5 KiB > > [Thu Jun 26 17:40:54.453 2014] Hash algo:crc32 > > [Thu Jun 26 17:40:54.453 2014] Hash value: 9a94aca8 > > [Thu Jun 26 17:40:54.453 2014] Hash algo:sha1 > > [Thu Jun 26 17:40:54.453 2014] Hash value: > 97b81e3014decb706ff19e61e1227dace97d4232 > > [Thu Jun 26 17:40:54.453 2014] crc32+ sha1+ Uncompressing Kernel Image ... > OK > > . > .I noticed that the following lines are coming twice: > > SF: Detected S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB > > This corresponds to the function spi_flash_probe from > drivers/mtd/spi/spi_flash.c > > > I need to know: > > 1- Why it is probed twice? > 2- The name and location of the file from where it is called (twice). > 3- The second time it is being probed is considerably slow, why it is so? > > > I have searched many forums and have looked in the code but still I am not > able to figure out these things. > > > > Thanks and regards, > > Abdul Basit > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: atmel: sama5d3xek: enable NOR flash support
Hi Bo, > >> +#ifdef CONFIG_CMD_FLASH > >> +#define CONFIG_SYS_FLASH_CFI > >> +#define CONFIG_FLASH_CFI_DRIVER > >> +#define CONFIG_SYS_FLASH_BASE 0x1000 > >> +#define CONFIG_SYS_MAX_FLASH_SECT 0x2 Is this the correct value for CONFIG_SYS_MAX_FLASH_SECT? Shouldn't it be 127 (if we ignore the top boot block) or 131 if they are included? Regards, Andy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Why spi flash probe runs twice on Xilinx Zynq board ?
Thanks for your comments Thomas and Jagan! On 30 June 2014 15:58, Jagan Teki wrote: > I guess - your using Xilinx github u-boot-xlnx > > Yes > The reason for two prints is like, for > 1) Initial probe print, by default done in env calls > 2) Added in sf probe again on auto-boot commands [1] > > [1] > https://github.com/Xilinx/u-boot-xlnx/blob/master/include/configs/zynq-common.h > > Ok. I will study it. BTW is it technically possible to completely get rid of the second probing which I boot from flash? Thanks > On Sat, Jun 28, 2014 at 10:51 PM, Heshsham Abdul Basit > wrote: > > Hi, > > > > I am re-sending this email because earlier I forgot to put the subject > line > > properly. I am struggling to figure out few things in u-boot , but I > failed > > to get a good resource or help. > > > > This is a section of the log from u-boot running on Avnet Microzed board: > > > > > > [Thu Jun 26 17:40:53.656 2014] > > > > [Thu Jun 26 17:40:53.656 2014] > > > > [Thu Jun 26 17:40:53.656 2014] U-Boot 2013.07 (Jun 26 2014 - 17:34:41) > > > > [Thu Jun 26 17:40:53.656 2014] > > > > [Thu Jun 26 17:40:53.656 2014] 1 GiB > > > > [Thu Jun 26 17:40:53.671 2014] SF: Detected > > S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB > > > > [Thu Jun 26 17:40:53.703 2014] *** Warning - bad CRC, using default > > environment > > > > [Thu Jun 26 17:40:53.703 2014] > > > > [Thu Jun 26 17:40:53.703 2014] In:serial > > > > [Thu Jun 26 17:40:53.703 2014] Out: serial > > > > [Thu Jun 26 17:40:53.703 2014] Err: serial > > > > [Thu Jun 26 17:40:53.703 2014] U-BOOT for suheb_24 > > > > [Thu Jun 26 17:40:53.703 2014] > > > > [Thu Jun 26 17:40:53.703 2014] > > > > [Thu Jun 26 17:40:53.703 2014] SF: Detected > > S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB > > > > [Thu Jun 26 17:40:54.453 2014] SF: 5242880 bytes @ 0x52 Read: OK > > > > [Thu Jun 26 17:40:54.453 2014] Description: PetaLinux Kernel > > > > [Thu Jun 26 17:40:54.453 2014] 0x01f0 > > > > [Thu Jun 26 17:40:54.453 2014] 4620145 Bytes = 4.4 MiB > > > > [Thu Jun 26 17:40:54.453 2014] Description: Flattened Device Tree > blob > > > > [Thu Jun 26 17:40:54.453 2014] 0x01468114 > > > > [Thu Jun 26 17:40:54.453 2014] 9766 Bytes = 9.5 KiB > > > > [Thu Jun 26 17:40:54.453 2014] Hash algo:crc32 > > > > [Thu Jun 26 17:40:54.453 2014] Hash value: 9a94aca8 > > > > [Thu Jun 26 17:40:54.453 2014] Hash algo:sha1 > > > > [Thu Jun 26 17:40:54.453 2014] Hash value: > > 97b81e3014decb706ff19e61e1227dace97d4232 > > > > [Thu Jun 26 17:40:54.453 2014] crc32+ sha1+ Uncompressing Kernel Image > ... > > OK > > > > . > > .I noticed that the following lines are coming twice: > > > > SF: Detected S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 > MiB > > > > This corresponds to the function spi_flash_probe from > > drivers/mtd/spi/spi_flash.c > > > > > > I need to know: > > > > 1- Why it is probed twice? > > 2- The name and location of the file from where it is called (twice). > > 3- The second time it is being probed is considerably slow, why it is > so? > > > > > > I have searched many forums and have looked in the code but still I am > not > > able to figure out these things. > > > > > > > > Thanks and regards, > > > > Abdul Basit > > > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot > > > > thanks! > -- > Jagan. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Why spi flash probe runs twice on Xilinx Zynq board ?
On Mon, Jun 30, 2014 at 4:18 PM, Heshsham Abdul Basit wrote: > Thanks for your comments Thomas and Jagan! > > > On 30 June 2014 15:58, Jagan Teki wrote: >> >> I guess - your using Xilinx github u-boot-xlnx >> > > Yes > >> >> The reason for two prints is like, for >> 1) Initial probe print, by default done in env calls >> 2) Added in sf probe again on auto-boot commands [1] >> >> [1] >> https://github.com/Xilinx/u-boot-xlnx/blob/master/include/configs/zynq-common.h >> > > Ok. I will study it. > > > BTW is it technically possible to completely get rid of the second probing > which I boot from flash? Do you have any issue with the second print, it's probing once aging before reading? > > Thanks > >> >> On Sat, Jun 28, 2014 at 10:51 PM, Heshsham Abdul Basit >> wrote: >> > Hi, >> > >> > I am re-sending this email because earlier I forgot to put the subject >> > line >> > properly. I am struggling to figure out few things in u-boot , but I >> > failed >> > to get a good resource or help. >> > >> > This is a section of the log from u-boot running on Avnet Microzed >> > board: >> > >> > >> > [Thu Jun 26 17:40:53.656 2014] >> > >> > [Thu Jun 26 17:40:53.656 2014] >> > >> > [Thu Jun 26 17:40:53.656 2014] U-Boot 2013.07 (Jun 26 2014 - 17:34:41) >> > >> > [Thu Jun 26 17:40:53.656 2014] >> > >> > [Thu Jun 26 17:40:53.656 2014] 1 GiB >> > >> > [Thu Jun 26 17:40:53.671 2014] SF: Detected >> > S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB >> > >> > [Thu Jun 26 17:40:53.703 2014] *** Warning - bad CRC, using default >> > environment >> > >> > [Thu Jun 26 17:40:53.703 2014] >> > >> > [Thu Jun 26 17:40:53.703 2014] In:serial >> > >> > [Thu Jun 26 17:40:53.703 2014] Out: serial >> > >> > [Thu Jun 26 17:40:53.703 2014] Err: serial >> > >> > [Thu Jun 26 17:40:53.703 2014] U-BOOT for suheb_24 >> > >> > [Thu Jun 26 17:40:53.703 2014] >> > >> > [Thu Jun 26 17:40:53.703 2014] >> > >> > [Thu Jun 26 17:40:53.703 2014] SF: Detected >> > S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB >> > >> > [Thu Jun 26 17:40:54.453 2014] SF: 5242880 bytes @ 0x52 Read: OK >> > >> > [Thu Jun 26 17:40:54.453 2014] Description: PetaLinux Kernel >> > >> > [Thu Jun 26 17:40:54.453 2014] 0x01f0 >> > >> > [Thu Jun 26 17:40:54.453 2014] 4620145 Bytes = 4.4 MiB >> > >> > [Thu Jun 26 17:40:54.453 2014] Description: Flattened Device Tree >> > blob >> > >> > [Thu Jun 26 17:40:54.453 2014] 0x01468114 >> > >> > [Thu Jun 26 17:40:54.453 2014] 9766 Bytes = 9.5 KiB >> > >> > [Thu Jun 26 17:40:54.453 2014] Hash algo:crc32 >> > >> > [Thu Jun 26 17:40:54.453 2014] Hash value: 9a94aca8 >> > >> > [Thu Jun 26 17:40:54.453 2014] Hash algo:sha1 >> > >> > [Thu Jun 26 17:40:54.453 2014] Hash value: >> > 97b81e3014decb706ff19e61e1227dace97d4232 >> > >> > [Thu Jun 26 17:40:54.453 2014] crc32+ sha1+ Uncompressing Kernel Image >> > ... >> > OK >> > >> > . >> > .I noticed that the following lines are coming twice: >> > >> > SF: Detected S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 >> > MiB >> > >> > This corresponds to the function spi_flash_probe from >> > drivers/mtd/spi/spi_flash.c >> > >> > >> > I need to know: >> > >> > 1- Why it is probed twice? >> > 2- The name and location of the file from where it is called (twice). >> > 3- The second time it is being probed is considerably slow, why it is >> > so? >> > >> > >> > I have searched many forums and have looked in the code but still I am >> > not >> > able to figure out these things. >> > >> > >> > >> > Thanks and regards, >> > >> > Abdul Basit >> > >> > ___ >> > U-Boot mailing list >> > U-Boot@lists.denx.de >> > http://lists.denx.de/mailman/listinfo/u-boot >> > >> >> thanks! >> -- >> Jagan. > > -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Why spi flash probe runs twice on Xilinx Zynq board ?
On 30 June 2014 16:30, Jagan Teki wrote: > On Mon, Jun 30, 2014 at 4:18 PM, Heshsham Abdul Basit > wrote: > > Thanks for your comments Thomas and Jagan! > > > > > > On 30 June 2014 15:58, Jagan Teki wrote: > >> > >> I guess - your using Xilinx github u-boot-xlnx > >> > > > > Yes > > > >> > >> The reason for two prints is like, for > >> 1) Initial probe print, by default done in env calls > >> 2) Added in sf probe again on auto-boot commands [1] > >> > >> [1] > >> > https://github.com/Xilinx/u-boot-xlnx/blob/master/include/configs/zynq-common.h > >> > > > > Ok. I will study it. > > > > > > BTW is it technically possible to completely get rid of the second > probing > > which I boot from flash? > > Do you have any issue with the second print, it's probing once aging > before reading? > > The only problem is , it is taking significant time for my application. I though if I remove this second probing I could save some time! > > > > Thanks > > > >> > >> On Sat, Jun 28, 2014 at 10:51 PM, Heshsham Abdul Basit > >> wrote: > >> > Hi, > >> > > >> > I am re-sending this email because earlier I forgot to put the subject > >> > line > >> > properly. I am struggling to figure out few things in u-boot , but I > >> > failed > >> > to get a good resource or help. > >> > > >> > This is a section of the log from u-boot running on Avnet Microzed > >> > board: > >> > > >> > > >> > [Thu Jun 26 17:40:53.656 2014] > >> > > >> > [Thu Jun 26 17:40:53.656 2014] > >> > > >> > [Thu Jun 26 17:40:53.656 2014] U-Boot 2013.07 (Jun 26 2014 - 17:34:41) > >> > > >> > [Thu Jun 26 17:40:53.656 2014] > >> > > >> > [Thu Jun 26 17:40:53.656 2014] 1 GiB > >> > > >> > [Thu Jun 26 17:40:53.671 2014] SF: Detected > >> > S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB > >> > > >> > [Thu Jun 26 17:40:53.703 2014] *** Warning - bad CRC, using default > >> > environment > >> > > >> > [Thu Jun 26 17:40:53.703 2014] > >> > > >> > [Thu Jun 26 17:40:53.703 2014] In:serial > >> > > >> > [Thu Jun 26 17:40:53.703 2014] Out: serial > >> > > >> > [Thu Jun 26 17:40:53.703 2014] Err: serial > >> > > >> > [Thu Jun 26 17:40:53.703 2014] U-BOOT for suheb_24 > >> > > >> > [Thu Jun 26 17:40:53.703 2014] > >> > > >> > [Thu Jun 26 17:40:53.703 2014] > >> > > >> > [Thu Jun 26 17:40:53.703 2014] SF: Detected > >> > S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB > >> > > >> > [Thu Jun 26 17:40:54.453 2014] SF: 5242880 bytes @ 0x52 Read: OK > >> > > >> > [Thu Jun 26 17:40:54.453 2014] Description: PetaLinux Kernel > >> > > >> > [Thu Jun 26 17:40:54.453 2014] 0x01f0 > >> > > >> > [Thu Jun 26 17:40:54.453 2014] 4620145 Bytes = 4.4 MiB > >> > > >> > [Thu Jun 26 17:40:54.453 2014] Description: Flattened Device > Tree > >> > blob > >> > > >> > [Thu Jun 26 17:40:54.453 2014] 0x01468114 > >> > > >> > [Thu Jun 26 17:40:54.453 2014] 9766 Bytes = 9.5 KiB > >> > > >> > [Thu Jun 26 17:40:54.453 2014] Hash algo:crc32 > >> > > >> > [Thu Jun 26 17:40:54.453 2014] Hash value: 9a94aca8 > >> > > >> > [Thu Jun 26 17:40:54.453 2014] Hash algo:sha1 > >> > > >> > [Thu Jun 26 17:40:54.453 2014] Hash value: > >> > 97b81e3014decb706ff19e61e1227dace97d4232 > >> > > >> > [Thu Jun 26 17:40:54.453 2014] crc32+ sha1+ Uncompressing Kernel > Image > >> > ... > >> > OK > >> > > >> > . > >> > .I noticed that the following lines are coming twice: > >> > > >> > SF: Detected S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total > 16 > >> > MiB > >> > > >> > This corresponds to the function spi_flash_probe from > >> > drivers/mtd/spi/spi_flash.c > >> > > >> > > >> > I need to know: > >> > > >> > 1- Why it is probed twice? > >> > 2- The name and location of the file from where it is called (twice). > >> > 3- The second time it is being probed is considerably slow, why it is > >> > so? > >> > > >> > > >> > I have searched many forums and have looked in the code but still I am > >> > not > >> > able to figure out these things. > >> > > >> > > >> > > >> > Thanks and regards, > >> > > >> > Abdul Basit > >> > > >> > ___ > >> > U-Boot mailing list > >> > U-Boot@lists.denx.de > >> > http://lists.denx.de/mailman/listinfo/u-boot > >> > > >> > >> thanks! > >> -- > >> Jagan. > > > > > > > > -- > Jagan. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 0/2] Add CONFIG_SYS_GENERIC_BOARD to all gdsys boards
From: Dirk Eibach Dirk Eibach (2): ppc: Make ppc4xx ready for CONFIG_SYS_GENERIC_BOARD board: Add CONFIG_SYS_GENERIC_BOARD to all gdsys boards arch/powerpc/cpu/ppc4xx/cpu_init.c | 2 ++ include/configs/controlcenterd.h | 2 ++ include/configs/dlvision-10g.h | 1 + include/configs/dlvision.h | 1 + include/configs/gdppc440etx.h | 1 + include/configs/intip.h| 1 + include/configs/io.h | 1 + include/configs/io64.h | 1 + include/configs/iocon.h| 1 + include/configs/neo.h | 1 + 10 files changed, 12 insertions(+) -- 1.8.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 1/2] ppc: Make ppc4xx ready for CONFIG_SYS_GENERIC_BOARD
From: Dirk Eibach The generic board infrastructure assumes that gd is set by arch code. Signed-off-by: Dirk Eibach --- arch/powerpc/cpu/ppc4xx/cpu_init.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/cpu/ppc4xx/cpu_init.c b/arch/powerpc/cpu/ppc4xx/cpu_init.c index d465dcd..86891c1 100644 --- a/arch/powerpc/cpu/ppc4xx/cpu_init.c +++ b/arch/powerpc/cpu/ppc4xx/cpu_init.c @@ -451,6 +451,8 @@ cpu_init_f (void) mtdcr(PLB4A1_ACR, (mfdcr(PLB4A1_ACR) & ~PLB4Ax_ACR_RDP_MASK) | PLB4Ax_ACR_RDP_4DEEP); #endif /* CONFIG_440SP/SPE || CONFIG_460EX/GT || CONFIG_405EX */ + + gd = (gd_t *)(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET); } /* -- 1.8.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 2/2] board: Add CONFIG_SYS_GENERIC_BOARD to all gdsys boards
From: Dirk Eibach Add the generic board infrastructure to all gdsys boards. Signed-off-by: Dirk Eibach --- include/configs/controlcenterd.h | 2 ++ include/configs/dlvision-10g.h | 1 + include/configs/dlvision.h | 1 + include/configs/gdppc440etx.h| 1 + include/configs/intip.h | 1 + include/configs/io.h | 1 + include/configs/io64.h | 1 + include/configs/iocon.h | 1 + include/configs/neo.h| 1 + 9 files changed, 10 insertions(+) diff --git a/include/configs/controlcenterd.h b/include/configs/controlcenterd.h index 868813f..ed07a0f 100644 --- a/include/configs/controlcenterd.h +++ b/include/configs/controlcenterd.h @@ -45,6 +45,8 @@ #define CONFIG_CONTROLCENTERD #define CONFIG_MP /* support multiple processors */ +#define CONFIG_SYS_GENERIC_BOARD + #define CONFIG_SYS_NO_FLASH #define CONFIG_ENABLE_36BIT_PHYS #define CONFIG_FSL_LAW /* Use common FSL init code */ diff --git a/include/configs/dlvision-10g.h b/include/configs/dlvision-10g.h index 7877897..ec85db2 100644 --- a/include/configs/dlvision-10g.h +++ b/include/configs/dlvision-10g.h @@ -24,6 +24,7 @@ #define CONFIG_BOARD_EARLY_INIT_R #define CONFIG_MISC_INIT_R #define CONFIG_LAST_STAGE_INIT +#define CONFIG_SYS_GENERIC_BOARD #define CONFIG_SYS_CLK_FREQ /* external frequency to pll */ diff --git a/include/configs/dlvision.h b/include/configs/dlvision.h index 1e86c55..af0d602 100644 --- a/include/configs/dlvision.h +++ b/include/configs/dlvision.h @@ -22,6 +22,7 @@ #define CONFIG_BOARD_EARLY_INIT_F /* call board_early_init_f */ #define CONFIG_MISC_INIT_R /* call misc_init_r */ +#define CONFIG_SYS_GENERIC_BOARD #define CONFIG_SYS_CLK_FREQ /* external frequency to pll */ diff --git a/include/configs/gdppc440etx.h b/include/configs/gdppc440etx.h index 6810b3b..12fd75d 100644 --- a/include/configs/gdppc440etx.h +++ b/include/configs/gdppc440etx.h @@ -32,6 +32,7 @@ #define CONFIG_BOARD_EARLY_INIT_F 1 /* call board_early_init_f*/ #define CONFIG_MISC_INIT_R 1 /* call misc_init_r() */ +#define CONFIG_SYS_GENERIC_BOARD #undef CONFIG_ZERO_BOOTDELAY_CHECK /* ignore keypress on bootdelay==0 */ #define CONFIG_AUTOBOOT_KEYED /* use key strings to stop autoboot */ diff --git a/include/configs/intip.h b/include/configs/intip.h index b56b3aa..928eb5b 100644 --- a/include/configs/intip.h +++ b/include/configs/intip.h @@ -45,6 +45,7 @@ #define CONFIG_BOARD_EARLY_INIT_F 1 /* Call board_early_init_f */ #define CONFIG_BOARD_EARLY_INIT_R 1 /* Call board_early_init_r */ #define CONFIG_MISC_INIT_R 1 /* Call misc_init_r */ +#define CONFIG_SYS_GENERIC_BOARD #define CONFIG_BOARD_TYPES 1 /* support board types */ #define CONFIG_FIT #define CFG_ALT_MEMTEST diff --git a/include/configs/io.h b/include/configs/io.h index 9da6cc6..8c8afef 100644 --- a/include/configs/io.h +++ b/include/configs/io.h @@ -24,6 +24,7 @@ #define CONFIG_BOARD_EARLY_INIT_R #define CONFIG_MISC_INIT_R #define CONFIG_LAST_STAGE_INIT +#define CONFIG_SYS_GENERIC_BOARD #define CONFIG_SYS_CLK_FREQ /* external frequency to pll */ diff --git a/include/configs/io64.h b/include/configs/io64.h index 6915b20..2a9ff37 100644 --- a/include/configs/io64.h +++ b/include/configs/io64.h @@ -43,6 +43,7 @@ #define CONFIG_BOARD_EARLY_INIT_R #define CONFIG_MISC_INIT_R #define CONFIG_LAST_STAGE_INIT +#define CONFIG_SYS_GENERIC_BOARD #undef CONFIG_ZERO_BOOTDELAY_CHECK /* ignore keypress on bootdelay==0 */ #define CONFIG_AUTOBOOT_KEYED /* use key strings to stop autoboot */ diff --git a/include/configs/iocon.h b/include/configs/iocon.h index 79c4736..7fd7527 100644 --- a/include/configs/iocon.h +++ b/include/configs/iocon.h @@ -23,6 +23,7 @@ #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_BOARD_EARLY_INIT_R #define CONFIG_LAST_STAGE_INIT +#define CONFIG_SYS_GENERIC_BOARD #define CONFIG_SYS_CLK_FREQ /* external frequency to pll */ diff --git a/include/configs/neo.h b/include/configs/neo.h index d549985..5fdeff1 100644 --- a/include/configs/neo.h +++ b/include/configs/neo.h @@ -25,6 +25,7 @@ #define CONFIG_BOARD_EARLY_INIT_R #define CONFIG_MISC_INIT_R #define CONFIG_LAST_STAGE_INIT +#define CONFIG_SYS_GENERIC_BOARD #define CONFIG_SYS_CLK_FREQ /* external frequency to pll */ -- 1.8.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Why spi flash probe runs twice on Xilinx Zynq board ?
On Mon, Jun 30, 2014 at 4:32 PM, Heshsham Abdul Basit wrote: > > > > On 30 June 2014 16:30, Jagan Teki wrote: >> >> On Mon, Jun 30, 2014 at 4:18 PM, Heshsham Abdul Basit >> wrote: >> > Thanks for your comments Thomas and Jagan! >> > >> > >> > On 30 June 2014 15:58, Jagan Teki wrote: >> >> >> >> I guess - your using Xilinx github u-boot-xlnx >> >> >> > >> > Yes >> > >> >> >> >> The reason for two prints is like, for >> >> 1) Initial probe print, by default done in env calls >> >> 2) Added in sf probe again on auto-boot commands [1] >> >> >> >> [1] >> >> >> >> https://github.com/Xilinx/u-boot-xlnx/blob/master/include/configs/zynq-common.h >> >> >> > >> > Ok. I will study it. >> > >> > >> > BTW is it technically possible to completely get rid of the second >> > probing >> > which I boot from flash? >> >> Do you have any issue with the second print, it's probing once aging >> before reading? >> > > The only problem is , it is taking significant time for my application. I > though if I remove this second probing I could save some time! Yes - you can please post your query to g...@xilinx.com as it's Xilinx git specific. > > >> >> > >> > Thanks >> > >> >> >> >> On Sat, Jun 28, 2014 at 10:51 PM, Heshsham Abdul Basit >> >> wrote: >> >> > Hi, >> >> > >> >> > I am re-sending this email because earlier I forgot to put the >> >> > subject >> >> > line >> >> > properly. I am struggling to figure out few things in u-boot , but I >> >> > failed >> >> > to get a good resource or help. >> >> > >> >> > This is a section of the log from u-boot running on Avnet Microzed >> >> > board: >> >> > >> >> > >> >> > [Thu Jun 26 17:40:53.656 2014] >> >> > >> >> > [Thu Jun 26 17:40:53.656 2014] >> >> > >> >> > [Thu Jun 26 17:40:53.656 2014] U-Boot 2013.07 (Jun 26 2014 - >> >> > 17:34:41) >> >> > >> >> > [Thu Jun 26 17:40:53.656 2014] >> >> > >> >> > [Thu Jun 26 17:40:53.656 2014] 1 GiB >> >> > >> >> > [Thu Jun 26 17:40:53.671 2014] SF: Detected >> >> > S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB >> >> > >> >> > [Thu Jun 26 17:40:53.703 2014] *** Warning - bad CRC, using default >> >> > environment >> >> > >> >> > [Thu Jun 26 17:40:53.703 2014] >> >> > >> >> > [Thu Jun 26 17:40:53.703 2014] In:serial >> >> > >> >> > [Thu Jun 26 17:40:53.703 2014] Out: serial >> >> > >> >> > [Thu Jun 26 17:40:53.703 2014] Err: serial >> >> > >> >> > [Thu Jun 26 17:40:53.703 2014] U-BOOT for suheb_24 >> >> > >> >> > [Thu Jun 26 17:40:53.703 2014] >> >> > >> >> > [Thu Jun 26 17:40:53.703 2014] >> >> > >> >> > [Thu Jun 26 17:40:53.703 2014] SF: Detected >> >> > S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB >> >> > >> >> > [Thu Jun 26 17:40:54.453 2014] SF: 5242880 bytes @ 0x52 Read: OK >> >> > >> >> > [Thu Jun 26 17:40:54.453 2014] Description: PetaLinux Kernel >> >> > >> >> > [Thu Jun 26 17:40:54.453 2014] 0x01f0 >> >> > >> >> > [Thu Jun 26 17:40:54.453 2014] 4620145 Bytes = 4.4 MiB >> >> > >> >> > [Thu Jun 26 17:40:54.453 2014] Description: Flattened Device >> >> > Tree >> >> > blob >> >> > >> >> > [Thu Jun 26 17:40:54.453 2014] 0x01468114 >> >> > >> >> > [Thu Jun 26 17:40:54.453 2014] 9766 Bytes = 9.5 KiB >> >> > >> >> > [Thu Jun 26 17:40:54.453 2014] Hash algo:crc32 >> >> > >> >> > [Thu Jun 26 17:40:54.453 2014] Hash value: 9a94aca8 >> >> > >> >> > [Thu Jun 26 17:40:54.453 2014] Hash algo:sha1 >> >> > >> >> > [Thu Jun 26 17:40:54.453 2014] Hash value: >> >> > 97b81e3014decb706ff19e61e1227dace97d4232 >> >> > >> >> > [Thu Jun 26 17:40:54.453 2014] crc32+ sha1+ Uncompressing Kernel >> >> > Image >> >> > ... >> >> > OK >> >> > >> >> > . >> >> > .I noticed that the following lines are coming twice: >> >> > >> >> > SF: Detected S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total >> >> > 16 >> >> > MiB >> >> > >> >> > This corresponds to the function spi_flash_probe from >> >> > drivers/mtd/spi/spi_flash.c >> >> > >> >> > >> >> > I need to know: >> >> > >> >> > 1- Why it is probed twice? >> >> > 2- The name and location of the file from where it is called (twice). >> >> > 3- The second time it is being probed is considerably slow, why it >> >> > is >> >> > so? >> >> > >> >> > >> >> > I have searched many forums and have looked in the code but still I >> >> > am >> >> > not >> >> > able to figure out these things. >> >> > >> >> > >> >> > >> >> > Thanks and regards, >> >> > >> >> > Abdul Basit >> >> > >> >> > ___ >> >> > U-Boot mailing list >> >> > U-Boot@lists.denx.de >> >> > http://lists.denx.de/mailman/listinfo/u-boot >> >> > >> >> >> >> thanks! >> >> -- >> >> Jagan. >> > >> > >> >> >> >> -- >> Jagan. > > -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Why spi flash probe runs twice on Xilinx Zynq board ?
On 30 June 2014 16:37, Jagan Teki wrote: > On Mon, Jun 30, 2014 at 4:32 PM, Heshsham Abdul Basit > wrote: > > > > > > > > On 30 June 2014 16:30, Jagan Teki wrote: > >> > >> On Mon, Jun 30, 2014 at 4:18 PM, Heshsham Abdul Basit > >> wrote: > >> > Thanks for your comments Thomas and Jagan! > >> > > >> > > >> > On 30 June 2014 15:58, Jagan Teki wrote: > >> >> > >> >> I guess - your using Xilinx github u-boot-xlnx > >> >> > >> > > >> > Yes > >> > > >> >> > >> >> The reason for two prints is like, for > >> >> 1) Initial probe print, by default done in env calls > >> >> 2) Added in sf probe again on auto-boot commands [1] > >> >> > >> >> [1] > >> >> > >> >> > https://github.com/Xilinx/u-boot-xlnx/blob/master/include/configs/zynq-common.h > >> >> > >> > > >> > Ok. I will study it. > >> > > >> > > >> > BTW is it technically possible to completely get rid of the second > >> > probing > >> > which I boot from flash? > >> > >> Do you have any issue with the second print, it's probing once aging > >> before reading? > >> > > > > The only problem is , it is taking significant time for my application. I > > though if I remove this second probing I could save some time! > > Yes - you can please post your query to g...@xilinx.com as it's Xilinx > git specific. > Ok, I will post it now in g...@xilinx.com Many thanks for your suggestions. > > > > > >> > >> > > >> > Thanks > >> > > >> >> > >> >> On Sat, Jun 28, 2014 at 10:51 PM, Heshsham Abdul Basit > >> >> wrote: > >> >> > Hi, > >> >> > > >> >> > I am re-sending this email because earlier I forgot to put the > >> >> > subject > >> >> > line > >> >> > properly. I am struggling to figure out few things in u-boot , but > I > >> >> > failed > >> >> > to get a good resource or help. > >> >> > > >> >> > This is a section of the log from u-boot running on Avnet Microzed > >> >> > board: > >> >> > > >> >> > > >> >> > [Thu Jun 26 17:40:53.656 2014] > >> >> > > >> >> > [Thu Jun 26 17:40:53.656 2014] > >> >> > > >> >> > [Thu Jun 26 17:40:53.656 2014] U-Boot 2013.07 (Jun 26 2014 - > >> >> > 17:34:41) > >> >> > > >> >> > [Thu Jun 26 17:40:53.656 2014] > >> >> > > >> >> > [Thu Jun 26 17:40:53.656 2014] 1 GiB > >> >> > > >> >> > [Thu Jun 26 17:40:53.671 2014] SF: Detected > >> >> > S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB > >> >> > > >> >> > [Thu Jun 26 17:40:53.703 2014] *** Warning - bad CRC, using default > >> >> > environment > >> >> > > >> >> > [Thu Jun 26 17:40:53.703 2014] > >> >> > > >> >> > [Thu Jun 26 17:40:53.703 2014] In:serial > >> >> > > >> >> > [Thu Jun 26 17:40:53.703 2014] Out: serial > >> >> > > >> >> > [Thu Jun 26 17:40:53.703 2014] Err: serial > >> >> > > >> >> > [Thu Jun 26 17:40:53.703 2014] U-BOOT for suheb_24 > >> >> > > >> >> > [Thu Jun 26 17:40:53.703 2014] > >> >> > > >> >> > [Thu Jun 26 17:40:53.703 2014] > >> >> > > >> >> > [Thu Jun 26 17:40:53.703 2014] SF: Detected > >> >> > S25FL129P_64K/S25FL128S_64K with page size 64 KiB, total 16 MiB > >> >> > > >> >> > [Thu Jun 26 17:40:54.453 2014] SF: 5242880 bytes @ 0x52 Read: > OK > >> >> > > >> >> > [Thu Jun 26 17:40:54.453 2014] Description: PetaLinux Kernel > >> >> > > >> >> > [Thu Jun 26 17:40:54.453 2014] 0x01f0 > >> >> > > >> >> > [Thu Jun 26 17:40:54.453 2014] 4620145 Bytes = 4.4 MiB > >> >> > > >> >> > [Thu Jun 26 17:40:54.453 2014] Description: Flattened Device > >> >> > Tree > >> >> > blob > >> >> > > >> >> > [Thu Jun 26 17:40:54.453 2014] 0x01468114 > >> >> > > >> >> > [Thu Jun 26 17:40:54.453 2014] 9766 Bytes = 9.5 KiB > >> >> > > >> >> > [Thu Jun 26 17:40:54.453 2014] Hash algo:crc32 > >> >> > > >> >> > [Thu Jun 26 17:40:54.453 2014] Hash value: 9a94aca8 > >> >> > > >> >> > [Thu Jun 26 17:40:54.453 2014] Hash algo:sha1 > >> >> > > >> >> > [Thu Jun 26 17:40:54.453 2014] Hash value: > >> >> > 97b81e3014decb706ff19e61e1227dace97d4232 > >> >> > > >> >> > [Thu Jun 26 17:40:54.453 2014] crc32+ sha1+ Uncompressing Kernel > >> >> > Image > >> >> > ... > >> >> > OK > >> >> > > >> >> > . > >> >> > .I noticed that the following lines are coming twice: > >> >> > > >> >> > SF: Detected S25FL129P_64K/S25FL128S_64K with page size 64 KiB, > total > >> >> > 16 > >> >> > MiB > >> >> > > >> >> > This corresponds to the function spi_flash_probe from > >> >> > drivers/mtd/spi/spi_flash.c > >> >> > > >> >> > > >> >> > I need to know: > >> >> > > >> >> > 1- Why it is probed twice? > >> >> > 2- The name and location of the file from where it is called > (twice). > >> >> > 3- The second time it is being probed is considerably slow, why it > >> >> > is > >> >> > so? > >> >> > > >> >> > > >> >> > I have searched many forums and have looked in the code but still I > >> >> > am > >> >> > not > >> >> > able to figure out these things. > >> >> > > >> >> > > >> >> > > >> >> > Thanks and regards, > >> >> > > >> >> > Abdul Basit > >> >> > > >> >> > ___ > >> >> > U-Boot mailing list > >> >> > U-Boot@
Re: [U-Boot] [PATCH] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC
On 06/30/2014 11:37 AM, Marek Vasut wrote:
On Sunday, June 29, 2014 at 10:33:26 PM, Jörg Krause wrote:
On 06/28/2014 10:53 PM, Jörg Krause wrote:
[snip]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
I did some tests this weekend on u-boot-usb/master branch.
If I run "env default -a" and then "saveenv" after a reset, I get the
same error as running three time "tftp file" in a row.
Log:
U-Boot 2014.07-rc3-g18e0313-dirty (Jun 29 2014 - 21:56:02)
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
=> env default -a
## Resetting to default environment
=> saveenv
Saving Environment to NAND...
Erasing NAND...
Erasing at 0x36 -- 100% complete.
Writing to NAND... OK
=> tftp rootfs.ubifs
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()
"env default -a" removes stdin, stdout, stderr, and ver from the output
of "printenv".
Looking at drivers/usb/gadget/ether.c:usb_eth_init I found the
environment variable "cdc_connect_timeout". I played a little bit with
the settings.
1) Using "setenv cdc_connect_timeout 1" from the command line: tftp runs
more then three time in a row. Actually I can run tftp more than ten
times in row and it produces no error. I tested the values 1, 3, and 15
for cdc_connect_timeout.
2) Setting #define CONFIG_EXTRA_ENV_SETTINGS "cdc_connect_timeout=1\0" \
in my config header file. This does not help and produces the error on
the fourth run of tfpd. Tested with values 1 and 3 for timeout.
I just tested the CDC ethernet on M28EVK with u-boot-usb/master and loading
64MiB file from a TFTP server running on a local machine. It seems that for some
reason, in the udc_gadget_handle_interrupts() or somewhere there, it starts not
getting interrupts. Can you try with this change:
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index a6433e8..1af6d12 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -727,14 +727,8 @@ void udc_irq(void)
int usb_gadget_handle_interrupts(void)
{
- u32 value;
- struct ci_udc *udc = (struct ci_udc *)controller.ctrl->hcor;
-
- value = readl(&udc->usbsts);
- if (value)
- udc_irq();
-
- return value;
+ udc_irq();
+ return 0;
}
void udc_disconnect(void)
Does not help, sorry.
Best regards,
Marek Vasut
I run the test with a smaller file of around 18 KB and DEBUG messages
enabled in ci_udc.c. I attached the output for the first run of tftp
imx28-airlino.dtb and the fourth rund of tftp imx28-airlino.dtb, which
fails with an error. Maybe this helps.
using ci_udc, OUT ep- IN ep- STATUS ep-
MAC 00:19:b8:00:00:02
HOST MAC 00:19:b8:00:00:01
-- suspend --
-- reset --
-- portchange 2 High
handle setup GET_DESCRIPTOR, 80, 6 index 0 value 100 length 40
handle_setup: Set ep0 to IN for Data Stage
ept0 in pre-queue req 43b844c0, buffer 43b84580
ept0 in queue len 12, req 43b844c0, buffer 43b84580
ept0 in req 43b844c0, complete 0
handle_ep_complete: flip ep0 dir for Status Stage
flip_ep0_direction: Flipping ep0 to OUT
ept0 out pre-queue req 43b844c0, buffer 43febd20
ept0 out queue len 0, req 43b844c0, buffer 43febd20
ept0 out req 43b844c0, complete 0
-- reset --
-- portchange 2 High
handle setup SET_ADDRESS, 0, 5 index 0 value 1c length 0
handle_setup: Set ep0 to OUT for Data Stage
handle_setup: 0 length: flip ep0 dir for Status Stage
flip_ep0_direction: Flipping ep0 to IN
ept0 in pre-queue req 43b844c0, buffer 43febd20
ept0 in queue len 0, req 43b844c0, buffer 43febd20
ept0 in req 43b844c0, complete 0
handle setup GET_DESCRIPTOR, 80, 6 index 0 value 100 length 12
handle_setup: Set ep0 to IN for Data Stage
ept0 in pre-queue req 43b844c0, buffer 43b84580
ept0 in queue len 12, req 43b844c0, buffer 43b84580
ept0 in req 43b844c0, complete 0
handle_ep_complete: flip ep0 dir for Status Stage
flip_ep0_direction: Flipping ep0 to OUT
ept0 out pre-queue req 43b844c0, buffer 43febd20
ept0 out queue len 0, req 43b844c0, buffer 43febd20
ept0 out req 43b844c0, complete 0
handle setup GET_DESCRIPTOR, 80, 6 index 0 value 200 length 9
handle_setup: Set ep0 to IN for Data Stage
ept0 in pre-queue req 43b844c0, buffer 43b84580
ept0 in queue len 9, req 43b844c0, buffer 43b84580
ept0 in req 43b844c0, complete 0
handle_ep_complete: flip ep0 dir for Status Stage
flip_ep0_direction: Flipping ep0 to OUT
ept0 out pre-queue req 43b844c0, buffer 43febd20
ept0 out queue len 0, req 43b844c0, buffer 43febd20
ept0 out req 43b844c0, complete 0
handle setup GET
Re: [U-Boot] [PATCH v5 0/5] mtd, ubi, ubifs: resync with Linux-3.14
On 06/28/2014 01:34 PM, Jörg Krause wrote: > Dear Wolfgang, > > On 06/28/2014 01:44 PM, Wolfgang Denk wrote: >> Dear J�rg, >> >> In message <53adfff5.7050...@posteo.de> you wrote: >>> I applied this series of patches on top of a patch from Stephen Warren >>> from 2014-06-23: [PATCH] usb: ci_udc: fix interaction with >>> CONFIG_USB_ETH_CDC. >>> >>> Now my USB Ethernet driver does not work anymore. I am using tfpd for >>> downloading files over USB Ethernet Gadget from my notebook to an >>> Freescale i.MX28 board. >> It is definitely not wise to testseveral independent changes at once, >> as you will never know which of them (or any interacton between these) >> caused the problem. > I understand. > > Since commit 2813006fecdab740c3745b2dcbb06777cdd51dff on u-boot-imx > branch the USB Ethernet driver on my custom i.MX28 board is broken. I > cannot use tftp for downloading a file. The patch from Stephen Warren > fixed most (but not all) problems with the driver. >> >> I strongly recommend to apply only one of these patches iitially, then >> test it, and only if it works, then apply the second patch (series) >> > Stephen Warren, Marek Vasut and I am trying to figure out, why USB > Ethernet driver is broken since the stated commit. One assumption of > Stephen Warren was that is has something to do with mtd or ubifs. That's > why I am reporting this. That's not quite true. I had asked you to bisect your branch to find out *which* commit caused the problems. Anyway, hopefully the issue will become clearer once I read the responses to the ci_udc patch... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC
On 06/27/2014 07:34 PM, Jörg Krause wrote: > > On 06/28/2014 01:37 AM, Stephen Warren wrote: >> On 06/27/2014 05:16 PM, Jörg Krause wrote: >>> On 06/27/2014 11:55 PM, Stephen Warren wrote: On 06/27/2014 03:37 PM, Jörg Krause wrote: > I added the last series of patches beginning from 2014-06-10 for > testing > purposes. The patches from 2014-05-29 were already applied. > > First series of patches: > > Applying: usb: ci_udc: call udc_disconnect() from ci_pullup() > Applying: usb: ci_udc: fix freeing of ep0 req > Applying: usb: ci_udc: fix probe error cleanup > Applying: usb: ci_udc: clean up all allocations in unregister > > Calling tftp the first time after a reset runs fine, I thought the issue you reported was that the *first* time you run the "tftp" command, it has issues such as timeouts? Did I misunderstand, or did that issue somehow go away? >>> That's right! This was the state before applying a series of patches >>> after allow multiple buffer allocs per ep. Now, the first run of tftp >>> runs without any errors. >> Just to make sure I understand, here's what you saw: >> >> 1) tftp works fine to start with. No timeouts even on repeated >> invocation. > I went back in time and now I can be more precise. Everything worked > fine until commit usb: ci_udc: allow multiple buffer allocs per ep which > introduces timeouts in almost all tftp file downloads. Even the first > run of tfpt can end in a timeout. > >> >> 2) You applied "allow multiple buffer allocs per ep" > Setting #define CONFIG_SYS_CACHELINE_SIZE 32 to my config file helped > here. But still timeouts. First run almost always runs fine, only > sometimes timeouts while receiving a packet, but always running to the > end. Running tftp after this a second time and more fails with a ERROR: > The remote end did not respond in time. at > drivers/usb/gadget/ether.c:2388/usb_eth_init(), but sometimes it works. > > Setting CONFIG_SYS_CACHELINE_SIZE 32 does not make it better (as I > previously wrote it). > > Removing CONFIG_USB_GADGET_DUALSPEED helps a little bit, but I am > getting also errors after the second or third run. Sigh. There's been a lot of flip-flopping re: whether the cacheline size affects the issue or not, and whether the first TFTP download always works fine, or whether only the 3rd fails. This makes it very hard for me to understand the issue that you're seeing. For instance, if even the first TFTP download can fail (even if intermittently), then there's clearly a problem with basic driver operation. However, if only the 2nd or 3rd TFTP ever fails, then the problem is likely isolated to some part of the cleanup/shutdown code. Given that your reports of the problem keep flip-flopping about, it makes it hard to decide which part of the code to look at. For now, I'm going to simply assume that any TFTP download (1st, 2nd, or 100th) can fail intermittently, and that cache line size is irrelevant. I'll look at the problematic commit you mentioned (2813006fecda "usb: ci_udc: allow multiple buffer allocs per ep") and see if I can create a series of patches that do the same thing, and have you bisect that. If I can do that, I will ask you to test 100 times each: the commit before the bad commit, then each of the commits in my series, always resetting the board between each test and doing a single TFTP download. Then I'd like to see the raw results from those tests. ___ 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 Przemyslaw.
[...]
#include
+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.
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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC
On 06/30/2014 10:02 AM, Stephen Warren wrote: > On 06/27/2014 07:34 PM, Jörg Krause wrote: >> >> On 06/28/2014 01:37 AM, Stephen Warren wrote: >>> On 06/27/2014 05:16 PM, Jörg Krause wrote: On 06/27/2014 11:55 PM, Stephen Warren wrote: > On 06/27/2014 03:37 PM, Jörg Krause wrote: >> I added the last series of patches beginning from 2014-06-10 for >> testing >> purposes. The patches from 2014-05-29 were already applied. >> >> First series of patches: >> >> Applying: usb: ci_udc: call udc_disconnect() from ci_pullup() >> Applying: usb: ci_udc: fix freeing of ep0 req >> Applying: usb: ci_udc: fix probe error cleanup >> Applying: usb: ci_udc: clean up all allocations in unregister >> >> Calling tftp the first time after a reset runs fine, > I thought the issue you reported was that the *first* time you run the > "tftp" command, it has issues such as timeouts? Did I misunderstand, or > did that issue somehow go away? That's right! This was the state before applying a series of patches after allow multiple buffer allocs per ep. Now, the first run of tftp runs without any errors. >>> >>> Just to make sure I understand, here's what you saw: >>> >>> 1) tftp works fine to start with. No timeouts even on repeated >>> invocation. >> >> I went back in time and now I can be more precise. Everything worked >> fine until commit usb: ci_udc: allow multiple buffer allocs per ep which >> introduces timeouts in almost all tftp file downloads. Even the first >> run of tfpt can end in a timeout. I've pushed out some branches for you to test at: git://github.com/swarren/u-boot.git I looked back to see where the problematic commit 2813006fecda "usb: ci_udc: allow multiple buffer allocs per ep" was first applied. I then started with that same commit, and split up the problematic commit into tiny pieces, and applied each piece in turn. The result is in branch ci-udc-debug-base. If you could please test every commit in that branch: > fabf0df9523a usb: ci_udc: remainder of "allow multiple buffer allocs" > 373098f12a1d usb: ci_udc: dynamically alloc USB request objects > 43fff2b11860 usb: ci_udc: dynamically alloc bounce buffer > f21b9989bf83 usb: ci_udc: bounce only actual (rounded) packet len not buffer > len for small pkts > 09ba064f9a99 usb: ci_udc: debounce only actual packet len not buffer len > 7e90ae0e4973 usb: ci_udc: use ci_req-> not ep-> a bit more > 9663ff89c764 usb: ci_udc: pass ci_req not ep to bounce/debounce > b9fdf9dd3f96 usb: ci_udc: move buffer fields from ep to req > 82f35a839e31 usb: ci_udc: introduce struct ci_req > c9396bc55069 usb: ci_udc: create "req" variable in bounce/unbounce > 173d294b94cf Merge branch 'serial' of git://www.denx.de/git/u-boot-microblaze ... and tell me which commit causes the problem, that would be useful. Since the problem is intermittent, please make sure you test each commit many times (at least 10-20, preferably nearer 100). You can stop early if you see the problem, but if you don't, please test many times to make sure there is no problem. You mentioned that your board support is not upstream. In order to test, you should probably do: For each commit I mention above, check it out, apply the minimal set of patches needed to support your board, and test. Please don't apply any other patches while testing this series. Please only test TFTP download, and not ubifs writes, etc. I've also pushed out branch ci-udc-debug-tegra-dfu-working which has a whole load of other commits I needed to test the split up patches. These were needed to add board support for the board I'm currently using, and to fix/enhance the core DFU code. Most of these commits are already applied in u-boot.git/master, it's just that I cherry-picked them on top of the old base commit so I would have something to test with. BTW, I'm going on vacation from Jul 3rd-July 20th. I might answer some limited email during this time, but I certainly won't have access to any test HW. ___ 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
On Thu, 2014-06-26 at 09:51 +0200, Wolfgang Denk wrote: > Dear Scott, > > In message <1403637570.26908.38.ca...@snotra.buserror.net> you wrote: > > > > I still disagree with #ifndef __UBOOT__ as it will hurt more than it > > helps with future merges. > > I agree that #ifdef's should be avoided, but then here they also serve > a documentation purpose as they clearly mark areas of code that are > specific to U-Boot, or that are not used in U-Boot. git diff can do that too, without reducing readability or increasing the likelihood of mismerges. > Do you think just of a removal, so there will be no trace left of > which code was added for U-Boot, and which was removed? Or should > these be turned into comments, something like > > /* BEGIN U-Boot specific code */ > ... > /* END U-Boot specific code */ > > [but that would not handle code removal well]. > > So what exactly is your proposal how the #fdef's should be removed? My proposal is to just remove them, similar to how the NAND code has been handled. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC
On 06/30/2014 06:02 PM, Stephen Warren wrote: On 06/27/2014 07:34 PM, Jörg Krause wrote: On 06/28/2014 01:37 AM, Stephen Warren wrote: On 06/27/2014 05:16 PM, Jörg Krause wrote: On 06/27/2014 11:55 PM, Stephen Warren wrote: On 06/27/2014 03:37 PM, Jörg Krause wrote: I added the last series of patches beginning from 2014-06-10 for testing purposes. The patches from 2014-05-29 were already applied. First series of patches: Applying: usb: ci_udc: call udc_disconnect() from ci_pullup() Applying: usb: ci_udc: fix freeing of ep0 req Applying: usb: ci_udc: fix probe error cleanup Applying: usb: ci_udc: clean up all allocations in unregister Calling tftp the first time after a reset runs fine, I thought the issue you reported was that the *first* time you run the "tftp" command, it has issues such as timeouts? Did I misunderstand, or did that issue somehow go away? That's right! This was the state before applying a series of patches after allow multiple buffer allocs per ep. Now, the first run of tftp runs without any errors. Just to make sure I understand, here's what you saw: 1) tftp works fine to start with. No timeouts even on repeated invocation. I went back in time and now I can be more precise. Everything worked fine until commit usb: ci_udc: allow multiple buffer allocs per ep which introduces timeouts in almost all tftp file downloads. Even the first run of tfpt can end in a timeout. 2) You applied "allow multiple buffer allocs per ep" Setting #define CONFIG_SYS_CACHELINE_SIZE 32 to my config file helped here. But still timeouts. First run almost always runs fine, only sometimes timeouts while receiving a packet, but always running to the end. Running tftp after this a second time and more fails with a ERROR: The remote end did not respond in time. at drivers/usb/gadget/ether.c:2388/usb_eth_init(), but sometimes it works. Setting CONFIG_SYS_CACHELINE_SIZE 32 does not make it better (as I previously wrote it). Sorry, this is a typo. It should be CONFIG_SYS_CACHELINE_SIZE 16 (not 32). Removing CONFIG_USB_GADGET_DUALSPEED helps a little bit, but I am getting also errors after the second or third run. Sigh. There's been a lot of flip-flopping re: whether the cacheline size affects the issue or not, and whether the first TFTP download always works fine, or whether only the 3rd fails. This makes it very hard for me to understand the issue that you're seeing. For instance, if even the first TFTP download can fail (even if intermittently), then there's clearly a problem with basic driver operation. However, if only the 2nd or 3rd TFTP ever fails, then the problem is likely isolated to some part of the cleanup/shutdown code. Given that your reports of the problem keep flip-flopping about, it makes it hard to decide which part of the code to look at. I am very sorry if I confused you with my attempt to explain you what I am seeing. The "flip-flopping" comes from the different results and behaviour after applying a patch or a series of patches. And I also tried this and that and looked if it changes the behaviour. I must admit that this is not good testing practise. For now, I'm going to simply assume that any TFTP download (1st, 2nd, or 100th) can fail intermittently, and that cache line size is irrelevant. I'll look at the problematic commit you mentioned (2813006fecda "usb: ci_udc: allow multiple buffer allocs per ep") and see if I can create a series of patches that do the same thing, and have you bisect that. If I can do that, I will ask you to test 100 times each: the commit before the bad commit, then each of the commits in my series, always resetting the board between each test and doing a single TFTP download. Then I'd like to see the raw results from those tests. I will do this and I hope it brings some clarifications. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: tegra: Add support for norrin board
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.
Signed-off-by: Allen Martin
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/tegra124-norrin.dts | 91 ++
board/nvidia/venice2/as3722_init.h | 2 +-
boards.cfg | 1 +
include/configs/venice2.h | 9
5 files changed, 104 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/dts/tegra124-norrin.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 55546152b94b..414f206cb6f0 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -23,7 +23,8 @@ dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
tegra30-tec-ng.dtb \
tegra114-dalmore.dtb \
tegra124-jetson-tk1.dtb \
- tegra124-venice2.dtb
+ tegra124-venice2.dtb \
+ tegra124-norrin.dtb
dtb-$(CONFIG_ZYNQ) += zynq-zc702.dtb \
zynq-zc706.dtb \
zynq-zed.dtb \
diff --git a/arch/arm/dts/tegra124-norrin.dts b/arch/arm/dts/tegra124-norrin.dts
new file mode 100644
index ..fdf000cf75ec
--- /dev/null
+++ b/arch/arm/dts/tegra124-norrin.dts
@@ -0,0 +1,91 @@
+/dts-v1/;
+
+#include "tegra124.dtsi"
+
+/ {
+ model = "NVIDIA Norrin";
+ compatible = "nvidia,norrin", "nvidia,tegra124";
+
+ aliases {
+ i2c0 = "/i2c@7000d000";
+ i2c1 = "/i2c@7000c000";
+ i2c2 = "/i2c@7000c400";
+ i2c3 = "/i2c@7000c500";
+ i2c4 = "/i2c@7000c700";
+ i2c5 = "/i2c@7000d100";
+ sdhci0 = "/sdhci@700b0600";
+ sdhci1 = "/sdhci@700b0400";
+ spi0 = "/spi@7000d400";
+ spi1 = "/spi@7000da00";
+ usb0 = "/usb@7d00";
+ usb1 = "/usb@7d008000";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x8000>;
+ };
+
+ i2c@7000c000 {
+ status = "okay";
+ clock-frequency = <10>;
+ };
+
+ i2c@7000c400 {
+ status = "okay";
+ clock-frequency = <10>;
+ };
+
+ i2c@7000c500 {
+ status = "okay";
+ clock-frequency = <10>;
+ };
+
+ i2c@7000c700 {
+ status = "okay";
+ clock-frequency = <10>;
+ };
+
+ i2c@7000d000 {
+ status = "okay";
+ clock-frequency = <40>;
+ };
+
+ i2c@7000d100 {
+ status = "okay";
+ clock-frequency = <40>;
+ };
+
+ spi@7000d400 {
+ status = "okay";
+ spi-max-frequency = <2500>;
+ };
+
+ spi@7000da00 {
+ status = "okay";
+ spi-max-frequency = <2500>;
+ };
+
+ sdhci@700b0400 {
+ status = "okay";
+ cd-gpios = <&gpio 170 1>; /* gpio PV2 */
+ power-gpios = <&gpio 136 0>; /* gpio PR0 */
+ bus-width = <4>;
+ };
+
+ sdhci@700b0600 {
+ status = "okay";
+ bus-width = <8>;
+ };
+
+ usb@7d00 {
+ status = "okay";
+ dr_mode = "otg";
+ nvidia,vbus-gpio = <&gpio 108 0>; /* gpio PN4, USB_VBUS_EN0 */
+ };
+
+ usb@7d008000 {
+ status = "okay";
+ nvidia,vbus-gpio = <&gpio 109 0>; /* gpio PN5, USB_VBUS_EN1 */
+ };
+};
diff --git a/board/nvidia/venice2/as3722_init.h
b/board/nvidia/venice2/as3722_init.h
index a7b24039f6aa..7c80ef09387b 100644
--- a/board/nvidia/venice2/as3722_init.h
+++ b/board/nvidia/venice2/as3722_init.h
@@ -18,7 +18,7 @@
#define AS3722_LDO6VOLTAGE_REG 0x16/* VDD_SDMMC */
#define AS3722_LDCONTROL_REG 0x4E
-#ifdef CONFIG_BOARD_JETSON_TK1
+#if defined(CONFIG_BOARD_JETSON_TK1) || defined(CONFIG_BOARD_NORRIN)
#define AS3722_SD0VOLTAGE_DATA (0x3C00 | AS3722_SD0VOLTAGE_REG)
#else
#define AS3722_SD0VOLTAGE_DATA (0x2800 | AS3722_SD0VOLTAGE_REG)
diff --git a/boards.cfg b/boards.cfg
index 5a85fad48095..3950688ba30b 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -395,6 +395,7 @@ Active arm armv7 zynqxilinx
zynq
Active arm armv7:arm720t tegra114nvidia dalmore
dalmore -
Tom Warren
Active arm armv7:arm720t tegra124nvidia jetson-tk1
jetson-tk1jetson-tk1:BOARD_JETSON_TK1=
Re: [U-Boot] Pull request v2: u-boot-sh/rmobile into u-boot-arm/master
Hi Nobuhiro, On Wed, 18 Jun 2014 12:24:47 +0900, Nobuhiro Iwamatsu wrote: > Dear Albert Aribaud, > > Please pull u-boot-sh/rmobile into u-boot-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-sh.git rmobile > > for you to fetch changes up to 2f7b27caf4e6bdc6cb4047ef3ee4021f20e14c5f: > > arm: rmobile: lager: Remove NOR-Flash support from boards.cfg > (2014-06-11 06:59:36 +0900) > > > Nobuhiro Iwamatsu (2): > arm: rmobile: koelsch: Remove NOR-Flash support from boards.cfg > arm: rmobile: lager: Remove NOR-Flash support from boards.cfg > > boards.cfg | 2 -- > 1 file changed, 2 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
Re: [U-Boot] [PATCH] ARM: tegra: Add support for norrin board
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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC
On Monday, June 30, 2014 at 10:55:37 PM, Jörg Krause wrote: [...] > >>> 2) You applied "allow multiple buffer allocs per ep" > >> > >> Setting #define CONFIG_SYS_CACHELINE_SIZE 32 to my config file helped > >> here. But still timeouts. First run almost always runs fine, only > >> sometimes timeouts while receiving a packet, but always running to the > >> end. Running tftp after this a second time and more fails with a ERROR: > >> The remote end did not respond in time. at > >> drivers/usb/gadget/ether.c:2388/usb_eth_init(), but sometimes it works. > >> > >> Setting CONFIG_SYS_CACHELINE_SIZE 32 does not make it better (as I > >> previously wrote it). > > Sorry, this is a typo. It should be CONFIG_SYS_CACHELINE_SIZE 16 (not 32). MX28 has 32b-long cachelines. Setting this to 16 is nonsense. [...] 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] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC
On 06/30/2014 11:15 PM, Marek Vasut wrote: On Monday, June 30, 2014 at 10:55:37 PM, Jörg Krause wrote: [...] 2) You applied "allow multiple buffer allocs per ep" Setting #define CONFIG_SYS_CACHELINE_SIZE 32 to my config file helped here. But still timeouts. First run almost always runs fine, only sometimes timeouts while receiving a packet, but always running to the end. Running tftp after this a second time and more fails with a ERROR: The remote end did not respond in time. at drivers/usb/gadget/ether.c:2388/usb_eth_init(), but sometimes it works. Setting CONFIG_SYS_CACHELINE_SIZE 32 does not make it better (as I previously wrote it). Sorry, this is a typo. It should be CONFIG_SYS_CACHELINE_SIZE 16 (not 32). MX28 has 32b-long cachelines. Setting this to 16 is nonsense. [...] Yes it is. But if I do not set cacheline size to 32 in my config header file it will be 64, as I stated in a previous mail. I checked this and I found that ARCH_DMA_MINALIGN is set to 64, which is not true for Freescale i.MX28. This processor has an ARM926EJ-S, which has an cache line size of 32. In arch/arm/include/asm/cache.h the macro ARCH_DMA_MINALIGN is defined as followed: #ifdef CONFIG_SYS_CACHELINE_SIZE #define ARCH_DMA_MINALIGNCONFIG_SYS_CACHELINE_SIZE #else #define ARCH_DMA_MINALIGN64 #endif And in /arch/arm/cpu/arm926ejs/cache.c as followed: #ifndef CONFIG_SYS_CACHELINE_SIZE #define CONFIG_SYS_CACHELINE_SIZE32 #endif arch/arm/include/asm/cache.h does not see the definition of CONFIG_SYS_CACHELINE_SIZE in /arch/arm/cpu/arm926ejs/cache.c, so it's a bad place to put it in there. I was just curious of the impact on the behaviour of the USB ethernet gadget driver. 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] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC
On Monday, June 30, 2014 at 11:43:24 PM, Jörg Krause wrote: > On 06/30/2014 11:15 PM, Marek Vasut wrote: > > On Monday, June 30, 2014 at 10:55:37 PM, Jörg Krause wrote: > > [...] > > > > 2) You applied "allow multiple buffer allocs per ep" > > Setting #define CONFIG_SYS_CACHELINE_SIZE 32 to my config file helped > here. But still timeouts. First run almost always runs fine, only > sometimes timeouts while receiving a packet, but always running to the > end. Running tftp after this a second time and more fails with a > ERROR: The remote end did not respond in time. at > drivers/usb/gadget/ether.c:2388/usb_eth_init(), but sometimes it > works. > > Setting CONFIG_SYS_CACHELINE_SIZE 32 does not make it better (as I > previously wrote it). > >> > >> Sorry, this is a typo. It should be CONFIG_SYS_CACHELINE_SIZE 16 (not > >> 32). > > > > MX28 has 32b-long cachelines. Setting this to 16 is nonsense. > > [...] > > Yes it is. But if I do not set cacheline size to 32 in my config header > file it will be 64, as I stated in a previous mail. > > I checked this and I found that ARCH_DMA_MINALIGN is set to 64, > which is not true for Freescale i.MX28. This processor has an > ARM926EJ-S, which has an cache line size of 32. In > arch/arm/include/asm/cache.h the macro ARCH_DMA_MINALIGN is defined > as followed: > #ifdef CONFIG_SYS_CACHELINE_SIZE > #define ARCH_DMA_MINALIGNCONFIG_SYS_CACHELINE_SIZE > #else > #define ARCH_DMA_MINALIGN64 > #endif > > And in /arch/arm/cpu/arm926ejs/cache.c as followed: > #ifndef CONFIG_SYS_CACHELINE_SIZE > #define CONFIG_SYS_CACHELINE_SIZE32 > #endif > > arch/arm/include/asm/cache.h does not see the definition of > CONFIG_SYS_CACHELINE_SIZE in /arch/arm/cpu/arm926ejs/cache.c, so > it's a bad place to put it in there. > > > I was just curious of the impact on the behaviour of the USB ethernet > gadget driver. Well okay, cacheline length and DMA alignment needs are two different things. Larger than necessary ARCH_DMA_MINALIGN cannot hurt, though there should be a patch adding CONFIG_SYS_CACHELINE_SIZE 32 for MXS into include/configs/mxs.h it seems. 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] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC
On 06/30/2014 09:55 PM, Stephen Warren wrote:
On 06/30/2014 10:02 AM, Stephen Warren wrote:
On 06/27/2014 07:34 PM, Jörg Krause wrote:
On 06/28/2014 01:37 AM, Stephen Warren wrote:
On 06/27/2014 05:16 PM, Jörg Krause wrote:
On 06/27/2014 11:55 PM, Stephen Warren wrote:
On 06/27/2014 03:37 PM, Jörg Krause wrote:
I added the last series of patches beginning from 2014-06-10 for
testing
purposes. The patches from 2014-05-29 were already applied.
First series of patches:
Applying: usb: ci_udc: call udc_disconnect() from ci_pullup()
Applying: usb: ci_udc: fix freeing of ep0 req
Applying: usb: ci_udc: fix probe error cleanup
Applying: usb: ci_udc: clean up all allocations in unregister
Calling tftp the first time after a reset runs fine,
I thought the issue you reported was that the *first* time you run the
"tftp" command, it has issues such as timeouts? Did I misunderstand, or
did that issue somehow go away?
That's right! This was the state before applying a series of patches
after allow multiple buffer allocs per ep. Now, the first run of tftp
runs without any errors.
Just to make sure I understand, here's what you saw:
1) tftp works fine to start with. No timeouts even on repeated
invocation.
I went back in time and now I can be more precise. Everything worked
fine until commit usb: ci_udc: allow multiple buffer allocs per ep which
introduces timeouts in almost all tftp file downloads. Even the first
run of tfpt can end in a timeout.
I've pushed out some branches for you to test at:
git://github.com/swarren/u-boot.git
I looked back to see where the problematic commit 2813006fecda "usb:
ci_udc: allow multiple buffer allocs per ep" was first applied. I then
started with that same commit, and split up the problematic commit into
tiny pieces, and applied each piece in turn. The result is in branch
ci-udc-debug-base. If you could please test every commit in that branch:
fabf0df9523a usb: ci_udc: remainder of "allow multiple buffer allocs"
373098f12a1d usb: ci_udc: dynamically alloc USB request objects
43fff2b11860 usb: ci_udc: dynamically alloc bounce buffer
f21b9989bf83 usb: ci_udc: bounce only actual (rounded) packet len not buffer
len for small pkts
09ba064f9a99 usb: ci_udc: debounce only actual packet len not buffer len
7e90ae0e4973 usb: ci_udc: use ci_req-> not ep-> a bit more
9663ff89c764 usb: ci_udc: pass ci_req not ep to bounce/debounce
b9fdf9dd3f96 usb: ci_udc: move buffer fields from ep to req
82f35a839e31 usb: ci_udc: introduce struct ci_req
c9396bc55069 usb: ci_udc: create "req" variable in bounce/unbounce
173d294b94cf Merge branch 'serial' of git://www.denx.de/git/u-boot-microblaze
... and tell me which commit causes the problem, that would be useful.
Since the problem is intermittent, please make sure you test each commit
many times (at least 10-20, preferably nearer 100). You can stop early
if you see the problem, but if you don't, please test many times to make
sure there is no problem.
Commit 373098f12a1d usb: ci_udc: dynamically alloc USB request objects
cannot be build.
The error is introduced with the latest commit fabf0df9523a usb: ci_udc:
remainder of "allow multiple buffer allocs". I attached the output
message for this commit.
You mentioned that your board support is not upstream. In order to test,
you should probably do: For each commit I mention above, check it out,
apply the minimal set of patches needed to support your board, and test.
Done. Just added board support.
Please don't apply any other patches while testing this series. Please
only test TFTP download, and not ubifs writes, etc.
This is my test script:
"test_usb=" \
"setenv i 64; " \
"while test ${i} -gt 0; do " \
"echo ${i}; " \
"tftp ${rootfs_file}; " \
"setexpr i ${i} - 1; " \
"done; " \
"setenv i; " \
"\0"
I've also pushed out branch ci-udc-debug-tegra-dfu-working which has a
whole load of other commits I needed to test the split up patches. These
were needed to add board support for the board I'm currently using, and
to fix/enhance the core DFU code. Most of these commits are already
applied in u-boot.git/master, it's just that I cherry-picked them on top
of the old base commit so I would have something to test with.
BTW, I'm going on vacation from Jul 3rd-July 20th. I might answer some
limited email during this time, but I certainly won't have access to any
test HW.
=> reset
resetting ...
HTLLCLLC
U-Boot 2014.04-gfabf0df-dirty (Jul 01 2014 - 00:36:11)
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]
Warning: Your board does not use generic board. Please read
doc/README.generic-board and take action. Boards not
upgraded by the late 2014 may break or be removed.
Hit any key to stop autoboot: 0
=> run test_usb
64
using ci_udc, OUT ep- IN ep- STATUS ep-
MAC 00:19:b8:00:00:02
HOST MA
Re: [U-Boot] [PATCH] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC
On 06/30/2014 04:44 PM, Jörg Krause wrote: > > On 06/30/2014 09:55 PM, Stephen Warren wrote: >> On 06/30/2014 10:02 AM, Stephen Warren wrote: >>> On 06/27/2014 07:34 PM, Jörg Krause wrote: On 06/28/2014 01:37 AM, Stephen Warren wrote: > On 06/27/2014 05:16 PM, Jörg Krause wrote: >> On 06/27/2014 11:55 PM, Stephen Warren wrote: >>> On 06/27/2014 03:37 PM, Jörg Krause wrote: I added the last series of patches beginning from 2014-06-10 for testing purposes. The patches from 2014-05-29 were already applied. First series of patches: Applying: usb: ci_udc: call udc_disconnect() from ci_pullup() Applying: usb: ci_udc: fix freeing of ep0 req Applying: usb: ci_udc: fix probe error cleanup Applying: usb: ci_udc: clean up all allocations in unregister Calling tftp the first time after a reset runs fine, >>> I thought the issue you reported was that the *first* time you run the >>> "tftp" command, it has issues such as timeouts? Did I misunderstand, or >>> did that issue somehow go away? >> That's right! This was the state before applying a series of patches >> after allow multiple buffer allocs per ep. Now, the first run of tftp >> runs without any errors. > Just to make sure I understand, here's what you saw: > > 1) tftp works fine to start with. No timeouts even on repeated > invocation. I went back in time and now I can be more precise. Everything worked fine until commit usb: ci_udc: allow multiple buffer allocs per ep which introduces timeouts in almost all tftp file downloads. Even the first run of tfpt can end in a timeout. >> >> I've pushed out some branches for you to test at: >> git://github.com/swarren/u-boot.git >> >> I looked back to see where the problematic commit 2813006fecda "usb: >> ci_udc: allow multiple buffer allocs per ep" was first applied. I then >> started with that same commit, and split up the problematic commit into >> tiny pieces, and applied each piece in turn. The result is in branch >> ci-udc-debug-base. If you could please test every commit in that branch: >> >>> fabf0df9523a usb: ci_udc: remainder of "allow multiple buffer allocs" >>> 373098f12a1d usb: ci_udc: dynamically alloc USB request objects >>> 43fff2b11860 usb: ci_udc: dynamically alloc bounce buffer >>> f21b9989bf83 usb: ci_udc: bounce only actual (rounded) packet len not >>> buffer len for small pkts >>> 09ba064f9a99 usb: ci_udc: debounce only actual packet len not buffer len >>> 7e90ae0e4973 usb: ci_udc: use ci_req-> not ep-> a bit more >>> 9663ff89c764 usb: ci_udc: pass ci_req not ep to bounce/debounce >>> b9fdf9dd3f96 usb: ci_udc: move buffer fields from ep to req >>> 82f35a839e31 usb: ci_udc: introduce struct ci_req >>> c9396bc55069 usb: ci_udc: create "req" variable in bounce/unbounce >>> 173d294b94cf Merge branch 'serial' of >>> git://www.denx.de/git/u-boot-microblaze >> >> ... and tell me which commit causes the problem, that would be useful. >> Since the problem is intermittent, please make sure you test each commit >> many times (at least 10-20, preferably nearer 100). You can stop early >> if you see the problem, but if you don't, please test many times to make >> sure there is no problem. Thanks very much for testing. (when you remove the blank lines between the message you're replying to and your response, it's much harder to read. Perhaps this is because you're writing HTML email. Most people won't read that; please use plain text). > Commit 373098f12a1d usb: ci_udc: dynamically alloc USB request objects > cannot be build. Oh dear. Differentiating between that commit and the next one is perhaps the most important thing. Can you please apply the following patch to that commit and retest it: diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c index b00fc2613779..c8c64d755195 100644 --- a/drivers/usb/gadget/ci_udc.c +++ b/drivers/usb/gadget/ci_udc.c @@ -423,7 +423,7 @@ static void handle_ep_complete(struct ci_ep *ep) num, in ? "in" : "out", item->info, item->page0); len = (item->info >> 16) & 0x7fff; - ci_ep->current_req = 0; + ep->current_req = 0; ci_req->req.actual = ci_req->req.length - len; ci_debounce(ci_req, in); > The error is introduced with the latest commit fabf0df9523a usb: ci_udc: > remainder of "allow multiple buffer allocs". I attached the output > message for this commit. OK, at least we can rule out all the bounce buffer and cache handling changes. ___ 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 <1404159636.2435.165.ca...@snotra.buserror.net> you wrote: > > > I agree that #ifdef's should be avoided, but then here they also serve > > a documentation purpose as they clearly mark areas of code that are > > specific to U-Boot, or that are not used in U-Boot. > > git diff can do that too, without reducing readability or increasing the > likelihood of mismerges. (git) diff needs a reference to diff against. Maybe I missed some earlier comments about that, but how exactly should this be done here? If we want to have strictly bisectable code in mainline, I don't really see how to provide an unmodified source reference to show the U-Boot specific diffs. Can you please explain (maybe again, sorry) how you think the code update should be done do both allow such a git diff and remain bisectable? The ways I can see all require a non-working / non-com- piling intermediate step. 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'm what passes for a Unix guru in my office. This is a frightening concept. - Lee Ann Goldstein, in <3k55ba$c...@butch.lmsc.lockheed.com> ___ 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
On Tue, 2014-07-01 at 00:56 +0200, Wolfgang Denk wrote: > Dear Scott, > > In message <1404159636.2435.165.ca...@snotra.buserror.net> you wrote: > > > > > I agree that #ifdef's should be avoided, but then here they also serve > > > a documentation purpose as they clearly mark areas of code that are > > > specific to U-Boot, or that are not used in U-Boot. > > > > git diff can do that too, without reducing readability or increasing the > > likelihood of mismerges. > > (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. > If we want to have strictly bisectable code in mainline, I don't > really see how to provide an unmodified source reference to show the > U-Boot specific diffs. > > Can you please explain (maybe again, sorry) how you think the code > update should be done do both allow such a git diff and remain > bisectable? The ways I can see all require a non-working / non-com- > piling intermediate step. 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 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. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC
On 07/01/2014 12:51 AM, Stephen Warren wrote: On 06/30/2014 04:44 PM, Jörg Krause wrote: On 06/30/2014 09:55 PM, Stephen Warren wrote: On 06/30/2014 10:02 AM, Stephen Warren wrote: On 06/27/2014 07:34 PM, Jörg Krause wrote: On 06/28/2014 01:37 AM, Stephen Warren wrote: On 06/27/2014 05:16 PM, Jörg Krause wrote: On 06/27/2014 11:55 PM, Stephen Warren wrote: On 06/27/2014 03:37 PM, Jörg Krause wrote: I added the last series of patches beginning from 2014-06-10 for testing purposes. The patches from 2014-05-29 were already applied. First series of patches: Applying: usb: ci_udc: call udc_disconnect() from ci_pullup() Applying: usb: ci_udc: fix freeing of ep0 req Applying: usb: ci_udc: fix probe error cleanup Applying: usb: ci_udc: clean up all allocations in unregister Calling tftp the first time after a reset runs fine, I thought the issue you reported was that the *first* time you run the "tftp" command, it has issues such as timeouts? Did I misunderstand, or did that issue somehow go away? That's right! This was the state before applying a series of patches after allow multiple buffer allocs per ep. Now, the first run of tftp runs without any errors. Just to make sure I understand, here's what you saw: 1) tftp works fine to start with. No timeouts even on repeated invocation. I went back in time and now I can be more precise. Everything worked fine until commit usb: ci_udc: allow multiple buffer allocs per ep which introduces timeouts in almost all tftp file downloads. Even the first run of tfpt can end in a timeout. I've pushed out some branches for you to test at: git://github.com/swarren/u-boot.git I looked back to see where the problematic commit 2813006fecda "usb: ci_udc: allow multiple buffer allocs per ep" was first applied. I then started with that same commit, and split up the problematic commit into tiny pieces, and applied each piece in turn. The result is in branch ci-udc-debug-base. If you could please test every commit in that branch: fabf0df9523a usb: ci_udc: remainder of "allow multiple buffer allocs" 373098f12a1d usb: ci_udc: dynamically alloc USB request objects 43fff2b11860 usb: ci_udc: dynamically alloc bounce buffer f21b9989bf83 usb: ci_udc: bounce only actual (rounded) packet len not buffer len for small pkts 09ba064f9a99 usb: ci_udc: debounce only actual packet len not buffer len 7e90ae0e4973 usb: ci_udc: use ci_req-> not ep-> a bit more 9663ff89c764 usb: ci_udc: pass ci_req not ep to bounce/debounce b9fdf9dd3f96 usb: ci_udc: move buffer fields from ep to req 82f35a839e31 usb: ci_udc: introduce struct ci_req c9396bc55069 usb: ci_udc: create "req" variable in bounce/unbounce 173d294b94cf Merge branch 'serial' of git://www.denx.de/git/u-boot-microblaze ... and tell me which commit causes the problem, that would be useful. Since the problem is intermittent, please make sure you test each commit many times (at least 10-20, preferably nearer 100). You can stop early if you see the problem, but if you don't, please test many times to make sure there is no problem. Thanks very much for testing. (when you remove the blank lines between the message you're replying to and your response, it's much harder to read. Perhaps this is because you're writing HTML email. Most people won't read that; please use plain text). Done, I hope it is better now. Commit 373098f12a1d usb: ci_udc: dynamically alloc USB request objects cannot be build. Oh dear. Differentiating between that commit and the next one is perhaps the most important thing. Can you please apply the following patch to that commit and retest it: diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c index b00fc2613779..c8c64d755195 100644 --- a/drivers/usb/gadget/ci_udc.c +++ b/drivers/usb/gadget/ci_udc.c @@ -423,7 +423,7 @@ static void handle_ep_complete(struct ci_ep *ep) num, in ? "in" : "out", item->info, item->page0); len = (item->info >> 16) & 0x7fff; - ci_ep->current_req = 0; + ep->current_req = 0; ci_req->req.actual = ci_req->req.length - len; ci_debounce(ci_req, in); Applied and tested. This commit produces also an error, but it differs to the previous one. I attached a log. The error is introduced with the latest commit fabf0df9523a usb: ci_udc: remainder of "allow multiple buffer allocs". I attached the output message for this commit. OK, at least we can rule out all the bounce buffer and cache handling changes. Just FYI: I added CONFIG_SYS_CACHE_SIZE 32 to my config header for all tests. => reset resetting ... HTLLCLLC U-Boot 2014.04-g72d5154-dirty (Jul 01 2014 - 00:58:41) 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] Warning: Your board does not use generic board. Please read doc/README.generic-board and take action. Boards not upgraded by the late 2014 may break or be removed
[U-Boot] [PATCH] usb: ci_udc: Allocate the qTD list directly
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
Cc: Jörg Krause
Cc: Stephen Warren
---
drivers/usb/gadget/ci_udc.c | 18 +++---
drivers/usb/gadget/ci_udc.h | 3 +--
2 files changed, 8 insertions(+), 13 deletions(-)
Note: Please test, it's too late and I'm barely conscious anymore ...
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index 334b5d2..8d92324 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -137,7 +137,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);
}
/**
@@ -727,7 +727,8 @@ static int ci_udc_probe(void)
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)
+ controller.epts = memalign(eplist_align, eplist_sz);
if (!controller.epts)
return -ENOMEM;
memset(controller.epts, 0, eplist_sz);
@@ -738,12 +739,13 @@ 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) {
+ if (!controller.items)
+ 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++) {
/*
@@ -763,12 +765,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);
diff --git a/drivers/usb/gadget/ci_udc.h b/drivers/usb/gadget/ci_udc.h
index 7d76af8..d464368 100644
--- a/drivers/usb/gadget/ci_udc.h
+++ b/drivers/usb/gadget/ci_udc.h
@@ -101,8 +101,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];
};
--
2.0.0.rc2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ci_udc: Allocate the qTD list directly
On Tuesday, July 01, 2014 at 01:53:18 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 > Cc: Jörg Krause > Cc: Stephen Warren Ah yes, this will complain about unused *imem , I will fix it when applying if this is the right 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] usb: ci_udc: fix interaction with CONFIG_USB_ETH_CDC
On Tuesday, July 01, 2014 at 01:17:54 AM, Jörg Krause wrote: [...] > > OK, at least we can rule out all the bounce buffer and cache handling > > changes. > > Just FYI: I added CONFIG_SYS_CACHE_SIZE 32 to my config header for all > tests. Feel free to join our slumber party at #u-boot IRC channel ... and btw. I just sent out a patch , so please test that one. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] usb: ci_udc: Allocate the qTD list directly
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
Cc: Jörg Krause
Cc: Stephen Warren
---
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];
};
--
2.0.0.rc2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: atmel: sama5d3xek: enable NOR flash support
Hi Andy, On 06/30/2014 06:46 PM, Andy Pont wrote: Hi Bo, +#ifdef CONFIG_CMD_FLASH +#define CONFIG_SYS_FLASH_CFI +#define CONFIG_FLASH_CFI_DRIVER +#define CONFIG_SYS_FLASH_BASE 0x1000 +#define CONFIG_SYS_MAX_FLASH_SECT 0x2 Is this the correct value for CONFIG_SYS_MAX_FLASH_SECT? Shouldn't it be 127 (if we ignore the top boot block) or 131 if they are included? oops, I fill this with the sector size. Thanks point it out. Here, I think we should fill with 131. Regards, Andy. Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot elf generation for arm64
Hi, I compiled the u-boot for arm64 and got two elf files(u-boot and u-boot.elf). I just want to know what is the difference between these two files? Regards, DurgaPrasad ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 17/25] i2c: mvtwsi: Add support for Marvell Armada XP
Hello Stefan, Am 27.06.2014 11:55, schrieb Stefan Roese: To support the Armada XP SoC, we just need to include the correct header. Signed-off-by: Stefan Roese Cc: Heiko Schocher --- drivers/i2c/mvtwsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] : Please pull u-boot-imx
Hi Stefano, On Thu, 26 Jun 2014 10:25:19 +0200, Stefano Babic wrote: > Hi Albert, > > please pull from u-boot-imx, thanks ! > > The following changes since commit 49692c5f517d8e44ed9db0de778728fe7d2a300c: > > net/designware: Make DMA burst length configurable and reduce by > default (2014-05-25 17:23:58 +0200) > > are available in the git repository at: > > git://www.denx.de/git/u-boot-imx.git master > > for you to fetch changes up to 3f4c01d9f9d38e383f004dcd06c0d5661f2a57e0: > > mx25pdk: Remove CONFIG_SYS_GENERIC_BOARD (2014-06-26 10:17:19 +0200) > > > Eric Nelson (1): > serial_mxc: disable new features of autobaud detection > > Fabio Estevam (10): > mx6sabreauto: Add the mx6dual-lite variant > mx6sabred: Add PFUZE100 PMIC support > mx25pdk: Add generic board support > mx6: Fix definition of IOMUXC_GPR12_DEVICE_TYPE_RC > embestmx6boards: Fix CONFIG_CONSOLE_DEV > embestmx6boards: Fix the dtb file name for riotboard > mx28evk: Fix warning when CONFIG_ENV_IS_IN_SPI_FLASH is selected > mx28evk: Add a target for SPI NOR boot > mx28evk: Add documentation on how to boot from SPI NOR > mx25pdk: Remove CONFIG_SYS_GENERIC_BOARD > > Marek Vasut (1): > arm: mx5: Enable CONFIG_SYS_GENERIC_BOARD on M53EVK > > Masahiro Yamada (1): > spl: consolidate arch/arm/include/asm/arch-*/spl.h > > Shawn Guo (1): > mx6: drop ARM errata 742230 > > Stefano Babic (3): > MX25: fix build due to missing sys_proto.h > imx: correct HAB status for new chip TO > vf610: fix build due to missing sys_proto.h > > Tim Harvey (12): > spl: nand: add support for mxs nand > mx6: add common SPL configuration > mx6: add boot device support for SPL > imx: add comments and remove unused struct fields > mx6: add structs for mmdc and ddr iomux registers > mx6: add mmdc configuration for MX6Q/MX6DL > imx: iomux: add macros to setup iomux for multiple SoC types > imx: ventana: split read_eeprom into standalone file > imx: ventana: auto-configure for IMX6Q vs IMX6DL > imx: ventana: switch to SPL > dwc_ahsata: return failure for MX6 if not IMX6Q/IMX6D > imx: sata: return failure if not IMX6Q/IMX6D > > arch/arm/cpu/arm720t/tegra-common/spl.c | 2 +- > arch/arm/cpu/armv7/mx6/Makefile | 1 + > arch/arm/cpu/armv7/mx6/ddr.c| 490 +++ > arch/arm/cpu/armv7/mx6/hab.c| 73 +++- > arch/arm/imx-common/Makefile| 1 + > arch/arm/imx-common/cpu.c | 16 +- > arch/arm/imx-common/iomux-v3.c | 18 +- > arch/arm/imx-common/sata.c | 7 +- > arch/arm/imx-common/spl.c | 81 > arch/arm/include/asm/arch-at91/spl.h| 24 -- > arch/arm/include/asm/arch-davinci/spl.h | 16 - > arch/arm/include/asm/arch-mx35/spl.h| 22 - > arch/arm/include/asm/arch-mx5/spl.h | 13 - > arch/arm/include/asm/arch-mx6/hab.h | 17 +- > arch/arm/include/asm/arch-mx6/imx-regs.h| 2 + > arch/arm/include/asm/arch-mx6/iomux.h | 2 +- > arch/arm/include/asm/arch-mx6/mx6-ddr.h | 231 +++ > arch/arm/include/asm/arch-mx6/sys_proto.h | 4 +- > arch/arm/include/asm/arch-tegra114/spl.h| 22 - > arch/arm/include/asm/arch-tegra124/spl.h| 13 - > arch/arm/include/asm/arch-tegra20/spl.h | 12 - > arch/arm/include/asm/arch-tegra30/spl.h | 12 - > arch/arm/include/asm/imx-common/iomux-v3.h | 25 ++ > arch/arm/include/asm/spl.h | 20 + > board/denx/m53evk/m53evk.c | 2 +- > board/freescale/mx28evk/README | 22 +- > board/freescale/mx6qsabreauto/mx6dl.cfg | 130 ++ > board/freescale/mx6sabresd/mx6sabresd.c | 84 > board/gateworks/gw_ventana/Makefile | 3 +- > board/gateworks/gw_ventana/README | 92 +++-- > board/gateworks/gw_ventana/eeprom.c | 89 + > board/gateworks/gw_ventana/gw_ventana.c | 597 > +++- > board/gateworks/gw_ventana/gw_ventana.cfg | 15 - > board/gateworks/gw_ventana/gw_ventana_spl.c | 419 +++ > board/gateworks/gw_ventana/ventana_eeprom.h | 11 + > boards.cfg | 8 +- > doc/README.mxs | 26 ++ > drivers/block/dwc_ahsata.c | 5 + > drivers/mtd/nand/Makefile | 1 + > drivers/mtd/nand/mxs_nand_spl.c | 231 +++ > drivers/serial/serial_mxc.c | 4 +- > include/configs/embestmx6boards.h | 4 +- > include/configs/gw_ventana.h| 11 + > include/configs/imx6_spl.h | 71 > include/configs/m53evk.h| 1 + > include/configs/mx28evk.h |
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
Cc: Jörg Krause
Cc: Stephen Warren
---
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: #
#
#
#
