Re: [U-Boot] [RFC] lib/fdtdec: Fix compiling warning for debug
Hello York, On Wed, 15 Jul 2015 13:26:46 -0700, York Sun wrote: > fdt_addr_t and fdt_size_t can be either 64-bit or 32-bit, depending > on the architecture. Change the type to phys_addr_t and phys_size_t. If the only reason for changing the type is to avoid warnings in debug() then I don't think this is the right approach (see my message re PRIu64). If, on the other hand, there is reason to believe the fdt_addr_t and fdt_size_t are wrongly defined and should be typedef'd or ~define's as phys_*_t, then the rationale for this should be exposed. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] lpc32xx: devkit3250: update of board configuration
Hello Vladimir, On Thu, 16 Jul 2015 02:33:47 +0300, Vladimir Zapolskiy wrote: > This change adds more peripherals to Timll DevKit3250 board, namely > MAC and SMSC phy, SLC NAND, GPIO, SPI and I2C. > > Also the default serial console is changed to UART5, added an option > to pass device tree blob by means of bootm, predefined environment > variables are slightly extended and reserved space on NAND to store > user defined U-boot environment. > > Signed-off-by: Vladimir Zapolskiy > --- > board/timll/devkit3250/devkit3250.c | 31 - > configs/devkit3250_defconfig| 3 ++ > include/configs/devkit3250.h| 92 > +++-- > 3 files changed, 120 insertions(+), 6 deletions(-) > > diff --git a/board/timll/devkit3250/devkit3250.c > b/board/timll/devkit3250/devkit3250.c > index 6acc416..4b3c94e 100644 > --- a/board/timll/devkit3250/devkit3250.c > +++ b/board/timll/devkit3250/devkit3250.c > @@ -1,23 +1,52 @@ > /* > * Embest/Timll DevKit3250 board support > * > - * Copyright (C) 2011 Vladimir Zapolskiy > + * Copyright (C) 2011-2015 Vladimir Zapolskiy > * > * SPDX-License-Identifier: GPL-2.0+ > */ > > #include > #include > +#include > #include > #include > +#include > +#include > > DECLARE_GLOBAL_DATA_PTR; > > static struct emc_regs *emc = (struct emc_regs *)EMC_BASE; > +static struct clk_pm_regs *clk = (struct clk_pm_regs *)CLK_PM_BASE; > +static struct wdt_regs *wdt = (struct wdt_regs *)WDT_BASE; > + > +void reset_periph(void) > +{ > + /* This function resets peripherals by triggering RESOUT_N */ > + setbits_le32(&clk->timclk_ctrl, CLK_TIMCLK_WATCHDOG); > + writel(WDTIM_MCTRL_RESFRC1, &wdt->mctrl); > + udelay(300); > + > + writel(0, &wdt->mctrl); > + clrbits_le32(&clk->timclk_ctrl, CLK_TIMCLK_WATCHDOG); > + > + /* Such a long delay is needed to initialize SMSC phy */ > + udelay(1); > +} > > int board_early_init_f(void) > { > lpc32xx_uart_init(CONFIG_SYS_LPC32XX_UART); > + lpc32xx_i2c_init(1); > + lpc32xx_i2c_init(2); > + lpc32xx_ssp_init(); > + lpc32xx_mac_init(); > + > + /* > + * nWP may be controlled by GPO19, but unpopulated by default R23 > + * makes no sense to configure this GPIO level, nWP is always high > + */ > + lpc32xx_slc_nand_init(); > > return 0; > } > diff --git a/configs/devkit3250_defconfig b/configs/devkit3250_defconfig > index f0c4ee1..56d719f 100644 > --- a/configs/devkit3250_defconfig > +++ b/configs/devkit3250_defconfig > @@ -1,3 +1,6 @@ > CONFIG_ARM=y > CONFIG_TARGET_DEVKIT3250=y > +# CONFIG_CMD_FPGA is not set > # CONFIG_CMD_SETEXPR is not set > +CONFIG_DM=y > +CONFIG_DM_GPIO=y > diff --git a/include/configs/devkit3250.h b/include/configs/devkit3250.h > index 4f35234..b8218b5 100644 > --- a/include/configs/devkit3250.h > +++ b/include/configs/devkit3250.h > @@ -1,7 +1,7 @@ > /* > * Embest/Timll DevKit3250 board configuration file > * > - * Copyright (C) 2011 Vladimir Zapolskiy > + * Copyright (C) 2011-2015 Vladimir Zapolskiy > * > * SPDX-License-Identifier: GPL-2.0+ > */ > @@ -43,10 +43,44 @@ > /* > * Serial Driver > */ > -#define CONFIG_SYS_LPC32XX_UART 2 /* UART2 */ > +#define CONFIG_SYS_LPC32XX_UART 5 /* UART5 */ This will affect existing users of this board, who expect it to use UART2 as console. Was this expectation wrong, or can both UART2 and UART5 be used as console? IOW, is this change required or is it just easier for you secifically? > #define CONFIG_BAUDRATE 115200 > > /* > + * I2C > + */ > +#define CONFIG_SYS_I2C > +#define CONFIG_SYS_I2C_LPC32XX > +#define CONFIG_SYS_I2C_SPEED 10 > +#define CONFIG_CMD_I2C > + > +/* > + * GPIO > + */ > +#define CONFIG_LPC32XX_GPIO > +#define CONFIG_CMD_GPIO > + > +/* > + * SSP/SPI > + */ > +#define CONFIG_LPC32XX_SSP > +#define CONFIG_LPC32XX_SSP_TIMEOUT 10 > +#define CONFIG_CMD_SPI > + > +/* > + * Ethernet > + */ > +#define CONFIG_RMII > +#define CONFIG_PHY_SMSC > +#define CONFIG_LPC32XX_ETH > +#define CONFIG_PHYLIB > +#define CONFIG_PHY_ADDR 0x1F > +#define CONFIG_SYS_FAULT_ECHO_LINK_DOWN > +#define CONFIG_CMD_MII > +#define CONFIG_CMD_PING > +#define CONFIG_CMD_DHCP > + > +/* > * NOR Flash > */ > #define CONFIG_SYS_MAX_FLASH_BANKS 1 > @@ -56,6 +90,29 @@ > #define CONFIG_SYS_FLASH_CFI > > /* > + * NAND controller > + */ > +#define CONFIG_NAND_LPC32XX_SLC > +#define CONFIG_SYS_NAND_BASE SLC_NAND_BASE > +#define CONFIG_SYS_MAX_NAND_DEVICE 1 > +#define CONFIG_SYS_NAND_BASE_LIST{ CONFIG_SYS_NAND_BASE } > + > +/* > + * NAND chip timings > + */ > +#define CONFIG_LPC32XX_NAND_SLC_WDR_CLKS 14 > +#define CONFIG_LPC32XX_NAND_SLC_WWIDTH > +#define CONFIG_LPC32XX_NAND_SLC_WHOLD2 > +#define CONFIG_LPC32XX_NAND_SLC_WSETUP 5000 > +#define CONFIG_LPC32XX_NAND_SLC_RDR_C
Re: [U-Boot] [PATCH 11/20] dm: serial: Update binding for PL01x serial UART
Hi Arnd, On Wed, Jul 15, 2015 at 12:17 PM, Arnd Bergmann wrote: > On Wednesday 15 July 2015 12:08:05 Linus Walleij wrote: >> On Wed, Jul 15, 2015 at 11:38 AM, Arnd Bergmann wrote: >> >> > The CHRP ISA binding defines that a 8250 compatible UART must have this >> > property: >> > >> > "clock-frequency" S >> > >> > Standard property, encoded as with encode-int, that shall be the >> > baud-rate >> > generator's clock input frequency (in hertz). >> > Typically, the clock frequency is nominally 1,843,200 Hz. Some devices >> > generate the baud rate input clock by dividing a higher-frequency clock >> > source that is not an exact multiple of 1,843,200 Hz, resulting in a >> > small but acceptable error in the nominal clock frequency. In such cases, >> > the "clock-frequency" shall report the actual nominal frequency. For >> > example, if the baud rate input clock is generated by dividing a 24 >> > MHz clock by 13, the value of the "clock-frequency" property shall be >> > 1846153. >> >> Isn't that for the case where the clock frequency will never change at >> runtime? >> >> The problem (I think) with many systems using PL011 is that they can >> actually change the serial port clock at runtime (software controlled clock), >> so providing a "clock-frequency" would imply that they cannot, and the clock >> frequency is fixed to that value. >> >> I think it's better to use boot-clock-frequency or so to indicate that a >> richer >> OS will provide more refined clocks. For example that frequency can >> typically change if the SoC changes operating point or so, though it would >> be awkward to handle in the driver, admittedly and I haven't seen a >> piece of code that actually go and change the UART input frequency. >> >> Still for completion it is better for the UART to tie into the clk framework >> as the OS gets up, and just providing clock-frequency seems to imply >> that it need not do that or something. The semantical effect of providing >> both >> clock-frequency = and clocks =< &..> must be clarified in any case. >> Like the latter overrides the former if clock phandles can be handled by >> the environment. (And this should be stated in the binding.) > > Ah right. I don't think that naming is super critical though, as a lot > of properties in the DT just describe how things are at boot time. Hence those don't describe the hardware... Shouldn't they be in /chosen instead? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] spl: nand: simple: replace readb() with chip specific read_buf()
Hello Vladimir, On Thu, 16 Jul 2015 02:33:45 +0300, Vladimir Zapolskiy wrote: > Some NAND controllers define custom functions to read data out, > respect this in order to correctly support bad block handling in > simple SPL NAND framework. > > NAND controller specific read_buf() is used even to read 1 byte in > case of connected 8-bit NAND device, it turns out that read_byte() > may become outdated. > > Signed-off-by: Vladimir Zapolskiy > --- > drivers/mtd/nand/nand_spl_simple.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/mtd/nand/nand_spl_simple.c > b/drivers/mtd/nand/nand_spl_simple.c > index 700ca32..e69f662 100644 > --- a/drivers/mtd/nand/nand_spl_simple.c > +++ b/drivers/mtd/nand/nand_spl_simple.c > @@ -115,6 +115,7 @@ static int nand_command(int block, int page, uint32_t > offs, > static int nand_is_bad_block(int block) > { > struct nand_chip *this = mtd.priv; > + u_char bb_data[2]; > > nand_command(block, 0, CONFIG_SYS_NAND_BAD_BLOCK_POS, > NAND_CMD_READOOB); > @@ -123,10 +124,12 @@ static int nand_is_bad_block(int block) >* Read one byte (or two if it's a 16 bit chip). >*/ > if (this->options & NAND_BUSWIDTH_16) { > - if (readw(this->IO_ADDR_R) != 0x) > + this->read_buf(&mtd, bb_data, 2); > + if (bb_data[0] != 0xff || bb_data[1] != 0xff) > return 1; > } else { > - if (readb(this->IO_ADDR_R) != 0xff) > + this->read_buf(&mtd, bb_data, 1); > + if (bb_data[0] != 0xff) > return 1; > } > > -- > 2.1.4 > The way you describe this patch, it looks like a bug that should have bitten way more boards than lpc32xx. Did you have a look at some other boards to see why this did not affect them? Conversively, what is the actual failure scenario that led you to writing this patch? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] BayTrail FSP release v4
Hi Simon, Andrew, Just noticed that Intel has released the FSP for BayTrail version 4. The release notes is at here: http://www.intel.com/content/www/us/en/embedded/software/fsp/atom-e3800-fsp-g4-release-notes.html Like Andrew contacted Intel and got the message, that Intel does not plan to release an FSP spec v2 complaint FSP for BayTrail, which looks like so. The v4 version is still FSP spec v1 :( But we should consider update MinnowMax instructions to use v4? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] spl: nand: simple: replace readb() with chip specific read_buf()
Hello Albert, On 16.07.2015 11:02, Albert ARIBAUD wrote: > Hello Vladimir, > > On Thu, 16 Jul 2015 02:33:45 +0300, Vladimir Zapolskiy > wrote: >> Some NAND controllers define custom functions to read data out, >> respect this in order to correctly support bad block handling in >> simple SPL NAND framework. >> >> NAND controller specific read_buf() is used even to read 1 byte in >> case of connected 8-bit NAND device, it turns out that read_byte() >> may become outdated. >> >> Signed-off-by: Vladimir Zapolskiy >> --- >> drivers/mtd/nand/nand_spl_simple.c | 7 +-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/mtd/nand/nand_spl_simple.c >> b/drivers/mtd/nand/nand_spl_simple.c >> index 700ca32..e69f662 100644 >> --- a/drivers/mtd/nand/nand_spl_simple.c >> +++ b/drivers/mtd/nand/nand_spl_simple.c >> @@ -115,6 +115,7 @@ static int nand_command(int block, int page, uint32_t >> offs, >> static int nand_is_bad_block(int block) >> { >> struct nand_chip *this = mtd.priv; >> +u_char bb_data[2]; >> >> nand_command(block, 0, CONFIG_SYS_NAND_BAD_BLOCK_POS, >> NAND_CMD_READOOB); >> @@ -123,10 +124,12 @@ static int nand_is_bad_block(int block) >> * Read one byte (or two if it's a 16 bit chip). >> */ >> if (this->options & NAND_BUSWIDTH_16) { >> -if (readw(this->IO_ADDR_R) != 0x) >> +this->read_buf(&mtd, bb_data, 2); >> +if (bb_data[0] != 0xff || bb_data[1] != 0xff) >> return 1; >> } else { >> -if (readb(this->IO_ADDR_R) != 0xff) >> +this->read_buf(&mtd, bb_data, 1); >> +if (bb_data[0] != 0xff) >> return 1; >> } >> >> -- >> 2.1.4 >> > > The way you describe this patch, it looks like a bug that should have > bitten way more boards than lpc32xx. Did you have a look at some other > boards to see why this did not affect them? Yes, it is a bug IMHO. Grepping for CONFIG_SPL_NAND_SIMPLE I see that TI and Tegra boards may be impacted (positively or negatively): * CONFIG_NAND_OMAP_GPMC --- own .read_buf(), default .read_byte() * CONFIG_NAND_DAVINCI --- own .read_buf(), default .read_byte() * CONFIG_TEGRA_NAND --- own .read_byte(), own .read_buf() > Conversively, what is the actual failure scenario that led you to > writing this patch? The failure scenario is quite simple, the ARM core gets stuck on first attempt to access SLC NAND data register -- traced with JTAG. The same happens, if I remove custom .read_byte()/.read_buf() from SLC NAND driver. The only difference between custom .read_byte() and shared read_byte() is in readb()/readl() access to the data register, it is essential to have only 32-bit wide access to SLC NAND registers. -- With best wishes, Vladimir ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] lpc32xx: devkit3250: update of board configuration
Hello Albert, On 16.07.2015 10:27, Albert ARIBAUD wrote: > Hello Vladimir, > > On Thu, 16 Jul 2015 02:33:47 +0300, Vladimir Zapolskiy > wrote: >> This change adds more peripherals to Timll DevKit3250 board, namely >> MAC and SMSC phy, SLC NAND, GPIO, SPI and I2C. >> >> Also the default serial console is changed to UART5, added an option >> to pass device tree blob by means of bootm, predefined environment >> variables are slightly extended and reserved space on NAND to store >> user defined U-boot environment. >> >> Signed-off-by: Vladimir Zapolskiy >> --- >> board/timll/devkit3250/devkit3250.c | 31 - >> configs/devkit3250_defconfig| 3 ++ >> include/configs/devkit3250.h| 92 >> +++-- >> 3 files changed, 120 insertions(+), 6 deletions(-) >> >> diff --git a/board/timll/devkit3250/devkit3250.c >> b/board/timll/devkit3250/devkit3250.c >> index 6acc416..4b3c94e 100644 >> --- a/board/timll/devkit3250/devkit3250.c >> +++ b/board/timll/devkit3250/devkit3250.c >> @@ -1,23 +1,52 @@ >> /* >> * Embest/Timll DevKit3250 board support >> * >> - * Copyright (C) 2011 Vladimir Zapolskiy >> + * Copyright (C) 2011-2015 Vladimir Zapolskiy >> * >> * SPDX-License-Identifier: GPL-2.0+ >> */ >> >> #include >> #include >> +#include >> #include >> #include >> +#include >> +#include >> >> DECLARE_GLOBAL_DATA_PTR; >> >> static struct emc_regs *emc = (struct emc_regs *)EMC_BASE; >> +static struct clk_pm_regs *clk = (struct clk_pm_regs *)CLK_PM_BASE; >> +static struct wdt_regs *wdt = (struct wdt_regs *)WDT_BASE; >> + >> +void reset_periph(void) >> +{ >> +/* This function resets peripherals by triggering RESOUT_N */ >> +setbits_le32(&clk->timclk_ctrl, CLK_TIMCLK_WATCHDOG); >> +writel(WDTIM_MCTRL_RESFRC1, &wdt->mctrl); >> +udelay(300); >> + >> +writel(0, &wdt->mctrl); >> +clrbits_le32(&clk->timclk_ctrl, CLK_TIMCLK_WATCHDOG); >> + >> +/* Such a long delay is needed to initialize SMSC phy */ >> +udelay(1); >> +} >> >> int board_early_init_f(void) >> { >> lpc32xx_uart_init(CONFIG_SYS_LPC32XX_UART); >> +lpc32xx_i2c_init(1); >> +lpc32xx_i2c_init(2); >> +lpc32xx_ssp_init(); >> +lpc32xx_mac_init(); >> + >> +/* >> + * nWP may be controlled by GPO19, but unpopulated by default R23 >> + * makes no sense to configure this GPIO level, nWP is always high >> + */ >> +lpc32xx_slc_nand_init(); >> >> return 0; >> } >> diff --git a/configs/devkit3250_defconfig b/configs/devkit3250_defconfig >> index f0c4ee1..56d719f 100644 >> --- a/configs/devkit3250_defconfig >> +++ b/configs/devkit3250_defconfig >> @@ -1,3 +1,6 @@ >> CONFIG_ARM=y >> CONFIG_TARGET_DEVKIT3250=y >> +# CONFIG_CMD_FPGA is not set >> # CONFIG_CMD_SETEXPR is not set >> +CONFIG_DM=y >> +CONFIG_DM_GPIO=y >> diff --git a/include/configs/devkit3250.h b/include/configs/devkit3250.h >> index 4f35234..b8218b5 100644 >> --- a/include/configs/devkit3250.h >> +++ b/include/configs/devkit3250.h >> @@ -1,7 +1,7 @@ >> /* >> * Embest/Timll DevKit3250 board configuration file >> * >> - * Copyright (C) 2011 Vladimir Zapolskiy >> + * Copyright (C) 2011-2015 Vladimir Zapolskiy >> * >> * SPDX-License-Identifier: GPL-2.0+ >> */ >> @@ -43,10 +43,44 @@ >> /* >> * Serial Driver >> */ >> -#define CONFIG_SYS_LPC32XX_UART 2 /* UART2 */ >> +#define CONFIG_SYS_LPC32XX_UART 5 /* UART5 */ > > This will affect existing users of this board, who expect it to use > UART2 as console. Was this expectation wrong, or can both UART2 and > UART5 be used as console? IOW, is this change required or is it just > easier for you secifically? The board has 8 UARTs (provided by LPC32xx and SC16IS752IPW), 4 of them can be used as a console interchangeably, namely LPC32xx UART2, UART3, UART4 and UART5. Previously UART2 was selected as a default UART, because it is a faster 14-clock UART, this plays a role if e.g. an image is downloaded over ymodem. Now with MAC support in Uboot this is not needed, and preferably to use UART5, which is mapped as a default serial console in Linux. >> #define CONFIG_BAUDRATE 115200 >> >> /* >> + * I2C >> + */ >> +#define CONFIG_SYS_I2C >> +#define CONFIG_SYS_I2C_LPC32XX >> +#define CONFIG_SYS_I2C_SPEED10 >> +#define CONFIG_CMD_I2C >> + >> +/* >> + * GPIO >> + */ >> +#define CONFIG_LPC32XX_GPIO >> +#define CONFIG_CMD_GPIO >> + >> +/* >> + * SSP/SPI >> + */ >> +#define CONFIG_LPC32XX_SSP >> +#define CONFIG_LPC32XX_SSP_TIMEOUT 10 >> +#define CONFIG_CMD_SPI >> + >> +/* >> + * Ethernet >> + */ >> +#define CONFIG_RMII >> +#define CONFIG_PHY_SMSC >> +#define CONFIG_LPC32XX_ETH >> +#define CONFIG_PHYLIB >> +#define CONFIG_PHY_ADDR 0x1F >> +#define CONFIG_SYS_FAULT_ECHO_LINK_DOWN >> +#define CONFIG_CMD_MII >> +#define CONFIG_CMD_PING >> +#define CONFIG_CMD_DHCP >> + >> +/* >> * NOR Flash >> */ >> #define CONF
Re: [U-Boot] [PATCH 1/4] spl: nand: simple: replace readb() with chip specific read_buf()
Hello Vladimir, On Thu, 16 Jul 2015 14:31:26 +0300, Vladimir Zapolskiy wrote: > Hello Albert, > > On 16.07.2015 11:02, Albert ARIBAUD wrote: > > Hello Vladimir, > > > > On Thu, 16 Jul 2015 02:33:45 +0300, Vladimir Zapolskiy > > wrote: > >> Some NAND controllers define custom functions to read data out, > >> respect this in order to correctly support bad block handling in > >> simple SPL NAND framework. > >> > >> NAND controller specific read_buf() is used even to read 1 byte in > >> case of connected 8-bit NAND device, it turns out that read_byte() > >> may become outdated. > >> > >> Signed-off-by: Vladimir Zapolskiy > >> --- > >> drivers/mtd/nand/nand_spl_simple.c | 7 +-- > >> 1 file changed, 5 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/mtd/nand/nand_spl_simple.c > >> b/drivers/mtd/nand/nand_spl_simple.c > >> index 700ca32..e69f662 100644 > >> --- a/drivers/mtd/nand/nand_spl_simple.c > >> +++ b/drivers/mtd/nand/nand_spl_simple.c > >> @@ -115,6 +115,7 @@ static int nand_command(int block, int page, uint32_t > >> offs, > >> static int nand_is_bad_block(int block) > >> { > >>struct nand_chip *this = mtd.priv; > >> + u_char bb_data[2]; > >> > >>nand_command(block, 0, CONFIG_SYS_NAND_BAD_BLOCK_POS, > >>NAND_CMD_READOOB); > >> @@ -123,10 +124,12 @@ static int nand_is_bad_block(int block) > >> * Read one byte (or two if it's a 16 bit chip). > >> */ > >>if (this->options & NAND_BUSWIDTH_16) { > >> - if (readw(this->IO_ADDR_R) != 0x) > >> + this->read_buf(&mtd, bb_data, 2); > >> + if (bb_data[0] != 0xff || bb_data[1] != 0xff) > >>return 1; > >>} else { > >> - if (readb(this->IO_ADDR_R) != 0xff) > >> + this->read_buf(&mtd, bb_data, 1); > >> + if (bb_data[0] != 0xff) > >>return 1; > >>} > >> > >> -- > >> 2.1.4 > >> > > > > The way you describe this patch, it looks like a bug that should have > > bitten way more boards than lpc32xx. Did you have a look at some other > > boards to see why this did not affect them? > > Yes, it is a bug IMHO. If it is, then it has hit no board which defines CONFIG_SPL_NAND_SIMPLE and we should understand why. > Grepping for CONFIG_SPL_NAND_SIMPLE I see that TI and Tegra boards may > be impacted (positively or negatively): > > * CONFIG_NAND_OMAP_GPMC --- own .read_buf(), default .read_byte() > * CONFIG_NAND_DAVINCI --- own .read_buf(), default .read_byte() > * CONFIG_TEGRA_NAND --- own .read_byte(), own .read_buf() They may be impacted by your change, but they are working now -- they are not obscure models. Let's dig a bit... > > Conversively, what is the actual failure scenario that led you to > > writing this patch? > > The failure scenario is quite simple, the ARM core gets stuck on first > attempt to access SLC NAND data register -- traced with JTAG. > > The same happens, if I remove custom .read_byte()/.read_buf() from SLC > NAND driver. The only difference between custom .read_byte() and shared > read_byte() is in readb()/readl() access to the data register, it is > essential to have only 32-bit wide access to SLC NAND registers. README describes CONFIG_SPL_NAND_SIMPLE as "Support for NAND boot using simple NAND drivers that expose the cmd_ctrl() interface". The cmd_ctrl interface actually contains the cmd_ctrl() function *and* the IO_ADDR_[RW] fields. IOW, a simple NAND driver provides byte or word access to the NAND's I/O lines on which command, address and data are passed. If the NAND is 8 bits, then there are 8 lines; if it is 16 bit, then there are 16 lines. I reckon that the OMAP/DAVINCI and TEGRA simple drivers just do that: set IO_ADDR_[RW] to the IP register through which direct access to the NAND's I/O lines can be performed, byte or word depending on the chip width. As such, there is no bug in the way nand_simple.c uses IO_ADDR_[RW]. OTOH, the SLC IP does not provide direct access to the NAND I/O lines through a general register; what it provides is a set of three specialized registers one for commands, one for addresses and one for data. Plus, even though only 8 bit NANDs are supported, the data register does not physically support 8-bit wide accesses (NXP: I am still struggling to understand what you were trying to achieve there). All this basically makes the SLC controller a 'not simple NAND IP', and its driver a 'not simple NAND driver' incompatible with nand_simple.c. Your solution to this incompatibility is to change nand_simple.c to support other types of drivers; but by doing that, you're changing the API between nand_simple.c and all simple drivers, possibly changing the established behavior. I personally don't think this is the right way; nand_simple.c should be left unchanged and the board should simply not use it since it does not have a simple NAND controller, and instead it should provide its own nand_spl_load_image(). But hey, I'm not then NAND custodian. S
Re: [U-Boot] [PATCH 3/4] lpc32xx: devkit3250: update of board configuration
Hello Vladimir, Thanks for the explanations, OK for both. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] nand: lpc32xx: add SLC NAND controller support
Hello Vladimir, On Thu, 16 Jul 2015 02:33:46 +0300, Vladimir Zapolskiy wrote: > diff --git a/drivers/mtd/nand/lpc32xx_nand_slc.c > b/drivers/mtd/nand/lpc32xx_nand_slc.c > new file mode 100644 > +int board_nand_init(struct nand_chip *lpc32xx_chip) > +{ > + lpc32xx_chip->IO_ADDR_R = &lpc32xx_nand_slc_registers->data; > + lpc32xx_chip->IO_ADDR_W = &lpc32xx_nand_slc_registers->data; Consistent with my comment re nand_simpl.c, I think that the two assignments above are incorrect since the data register may not provide general access to the NAND's I/O lines, and is not 8-bit accessible even though the NAND is 8-bit wide. If Scott give his go, though, disregard my comment. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] am33xx: CONFIG_REVISION_TAG ifdef check for get_board_rev
Despite being defined with __weak, this declaration of get_board_rev will conflict with the fallback one when ONFIG_REVISION_TAG is not defined. Signed-off-by: Paul Kocialkowski --- arch/arm/cpu/armv7/am33xx/sys_info.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/cpu/armv7/am33xx/sys_info.c b/arch/arm/cpu/armv7/am33xx/sys_info.c index 781d83f..9d5a5d3 100644 --- a/arch/arm/cpu/armv7/am33xx/sys_info.c +++ b/arch/arm/cpu/armv7/am33xx/sys_info.c @@ -54,10 +54,12 @@ u32 get_cpu_type(void) * get_board_rev() - setup to pass kernel board revision information * returns: 0 for the ATAG REVISION tag value. */ +#ifdef CONFIG_REVISION_TAG u32 __weak get_board_rev(void) { return 0; } +#endif /** * get_device_type(): tell if GP/HS/EMU/TST -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] omap3: CONFIG_REVISION_TAG ifdef check for get_board_rev
Despite being defined with __weak, this declaration of get_board_rev will conflict with the fallback one when ONFIG_REVISION_TAG is not defined. Signed-off-by: Paul Kocialkowski --- arch/arm/cpu/armv7/omap3/sys_info.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/cpu/armv7/omap3/sys_info.c b/arch/arm/cpu/armv7/omap3/sys_info.c index bbb65bb..ab60a03 100644 --- a/arch/arm/cpu/armv7/omap3/sys_info.c +++ b/arch/arm/cpu/armv7/omap3/sys_info.c @@ -196,10 +196,12 @@ u32 get_gpmc0_width(void) * get_board_rev() - setup to pass kernel board revision information * returns:(bit[0-3] sub version, higher bit[7-4] is higher version) */ +#ifdef CONFIG_REVISION_TAG u32 __weak get_board_rev(void) { return 0x20; } +#endif / * get_base(); get upper addr of current execution -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] am33xx: CONFIG_REVISION_TAG ifdef check for get_board_rev
On Thu, Jul 16, 2015 at 03:10:21PM +0200, Paul Kocialkowski wrote: > Despite being defined with __weak, this declaration of get_board_rev will > conflict with the fallback one when ONFIG_REVISION_TAG is not defined. > > Signed-off-by: Paul Kocialkowski There is no support for am33xx boards and Linux-kernel board-file kernels so lets just drop this weak default one and let boards that must have this for various reasons implement a real one. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86
On Wed, Jul 15, 2015 at 08:29:09AM -0600, Simon Glass wrote: > Hi Tom, > > Here's the first pull request for x86. It includes fixes and improvements > with PCI, multi-core init, Intel FSP init and adds graphics support for > crownbay. > > The following changes since commit f4815763b410d8657f6f617067a1d53024b05220: > > RFC: Deprecate MAKEALL (2015-07-14 13:50:16 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-x86.git > > for you to fetch changes up to f110da9984c0aa0aba9e1c4178b67b7abecf7e8d: > > pci: Disable expansion ROM address decoding when signature check fails > (2015-07-14 18:03:20 -0600) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] config: ti_omap5_common: Palmas power support in SPL
On Wed, Jul 15, 2015 at 02:56:23PM +0200, Paul Kocialkowski wrote: > Le jeudi 02 juillet 2015 à 00:20 +0200, Paul Kocialkowski a écrit : > > Palmas power support is required for OMAP5 devices such as the OMAP5 uEVM, > > that > > need to e.g. enable MMC power at SPL stage. > > > > This is especially important when booting from a peripheral (such as USB, > > UART), > > where the bootrom will not enable power for the MMC device that will hold > > the > > main U-Boot. > > I sent this a while back and it hasn't been picked up yet. Anything > holding it back in particular? > > > Signed-off-by: Paul Kocialkowski > > --- > > include/configs/ti_armv7_common.h | 1 + > > include/configs/ti_omap5_common.h | 2 -- > > 2 files changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/include/configs/ti_armv7_common.h > > b/include/configs/ti_armv7_common.h > > index 0aea7d1..34756de 100644 > > --- a/include/configs/ti_armv7_common.h > > +++ b/include/configs/ti_armv7_common.h > > @@ -261,6 +261,7 @@ > > #define CONFIG_SPL_LIBCOMMON_SUPPORT > > #define CONFIG_SPL_LIBGENERIC_SUPPORT > > #define CONFIG_SPL_SERIAL_SUPPORT > > +#define CONFIG_SPL_POWER_SUPPORT > > #define CONFIG_SPL_GPIO_SUPPORT > > #define CONFIG_SPL_BOARD_INIT > > > > diff --git a/include/configs/ti_omap5_common.h > > b/include/configs/ti_omap5_common.h > > index 4179a57..b33feb6 100644 > > --- a/include/configs/ti_omap5_common.h > > +++ b/include/configs/ti_omap5_common.h > > @@ -40,9 +40,7 @@ > > #define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS > > #endif > > > > -#ifndef CONFIG_SPL_BUILD > > #define CONFIG_PALMAS_POWER > > -#endif > > > > #include > > #include Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] omap3: CONFIG_REVISION_TAG ifdef check for get_board_rev
On Thu, Jul 16, 2015 at 03:10:20PM +0200, Paul Kocialkowski wrote: > Despite being defined with __weak, this declaration of get_board_rev will > conflict with the fallback one when ONFIG_REVISION_TAG is not defined. > > Signed-off-by: Paul Kocialkowski Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_fdt: save fdtaddr in hex format
On Fri, Jul 10, 2015 at 6:18 PM, Sudeep Holla wrote: > Commit 90fbee3e4051 ("cmd_fdt: Actually fix fdt command in sandbox") > changed the format(from hex address to unsigned long) in which "fdtaddr" > is saved . However do_fdt continues reads the "fdtaddr" assuming it to > be in hex format. This may lead to fdt being either loaded or attempted > to load at erroneous address generating fault if the address is out of > memory. > > This patch changes back the format to hex while saving the "fdtaddr" > as it was done before. > > Signed-off-by: Sudeep Holla > Cc: Linus Walleij > Cc: Tom Rini > Cc: Simon Glass > Cc: Hua Yanghao > Cc: Heiko Schocher Looks like the right fix: Acked-by: Linus Walleij Yours, Linus Walleij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/6] ARM64: hikey: hi6220: Add u-boot support for the 96boards CE HiKey board.
On Wed, Jul 15, 2015 at 7:41 PM, Peter Griffin wrote: > Hi Rob, > > On Fri, 10 Jul 2015, Rob Herring wrote: > >> On Wed, Jul 8, 2015 at 10:57 AM, Peter Griffin >> wrote: >> > HiKey is the first 96boards consumer edition compliant board. It features >> > a hi6220 >> > SoC which has eight ARM A53 cpu's. >> > [...] >> > +#define CONFIG_BAUDRATE115200 >> > +#define CONFIG_SYS_SERIAL0 0xF8015000 >> >> Just do: >> >> #define CONFIG_PL01x_PORTS {(void *)0xf8015000} > > Ok, fixed in V3 > >> >> You are probably going to want to setup multiple serial consoles >> (debug + LS header). That can come later, but I've figured out how to >> enable that if you are interested. > > Yes I'm interested, please do let me know :) See this commit: https://git.linaro.org/people/rob.herring/u-boot.git/commitdiff/f1d0aef06ae7fe09793d46589bd94fa36c45bbc0 This may be 8250 specific and require more work for pl011 driver. The mixture of 0 and 1 based indexing makes it fun too. >> > +#define CONFIG_EXTRA_ENV_SETTINGS \ >> > + "kernel_name=Image\0" \ >> > + "kernel_addr=0x000\0" \ >> >> Shouldn't this be 0x8 to avoid copying from 0x0 to 0x8. > > I've updated this. Kernel boot time is much reduced with this and also the > icache being enabled. Also, this should be kernel_addr_r > >> >> > + "fdt_name=hi6220-hikey.dtb\0" \ >> > + "fdt_addr=0x030\0" \ and fdt_addr_r >> > + "max_fdt=0x10\0" \ >> >> I don't think this is needed. > > Removed in V3 >> >> > + "fdt_high=0x\0" \ >> > + "initrd_high=0x\0" \ >> > + >> > +/* Assume we boot with root on the first partition of a USB stick */ >> > +#define CONFIG_BOOTARGS"console=ttyAMA0,115200n8 >> > /dev/mmcblk0p7 rw " >> >> /dev/mmcblk0p7 doesn't look right. You mean "root=/dev/..."? > > Good spot, yes your right. Plus now you highlight it the comment above also > needs updating. > > Will fix in V3. > >> >> > + >> > +/* Copy the kernel and FDT to DRAM memory and boot */ >> > +#define CONFIG_BOOTCOMMAND "booti $kernel_addr_r - $fdt_addr_r" >> >> Don't you need to set these variables? >> >> Also, don't you need to load the kernel and dtb first? > > Yes, but I'm not sure quite what to make the default here. My personal > workflow is: - > > "usb start; dhcp; tftp $kernel_addr $kernel_name; tftp $fdt_addr $fdt_name; >booti $kernel_addr - $fdt_addr" > > So I could use that unless you have a better idea? Not really as everyone has their own preferences. I have some thing like this: #define CONFIG_BOOTCOMMAND \ "while true; do " \ "mmc read ${fdt_addr_r} 0x1 0x1000; " \ "fastboot; " \ "mmc read ${fdt_addr_r} 0x1 0x1000; " \ "mmc read ${kernel_addr_r} 0x8000 0x8000 && " \ "bootm ${kernel_addr_r} ${kernel_addr_r} ${fdt_addr_r};" \ "done" This relies on fastboot doing USB cable detection and it exits if no USB connection. USB ethernet is as good a default as any. Otherwise reading Image and dtb from the 1st or bootable partition (the default) would be reasonable. >> > +/* Preserve enviroment onto sd card */ >> > +#define CONFIG_ENV_IS_IN_MMC >> > +#define CONFIG_SYS_MMC_ENV_DEV 1 >> > +#define CONFIG_SYS_MMC_ENV_PART0 >> >> Don't you have these reversed? The first MMC device is 0 and I think >> partition numbering starts at 1. > > Having CONFIG_SYS_MMC_ENV_DEV 1 was deliberate, as the first device is eMMC, > and > I don't have a "official" partition to save the u-boot enviroment in. > So as not to corrupt anything folks may have flashed into eMMC from the > official > builds I opted to save the u-boot env to SD card which is device 1. Okay, but don't you have spare space in the partition with u-boot? I have a single bootloader partition 1MB in size and the last 8? KB is the env. > However that seems to have been working by luck with ENC_PART being 0, and it > was > actually corrupting the partition table of the SD card. Looking more closely > I think > what I should of used is > > #define CONFIG_ENV_IS_IN_FAT > #define FAT_ENV_INTERFACE "mmc" > #define FAT_ENV_DEVICE_AND_PART "1:1" > #define FAT_ENV_FILE"uboot.env" > > This then saves the enviroment on a fat formatted SD card with the filename > u-boot.env. This is what I plan on using for v3. > > Maybe I should additionally request some space in the official eMMC parition > table and then we could switch over to using that. > >> >> > +#define CONFIG_ENV_OFFSET 0x0 >> > +#define CONFIG_ENV_SIZE0x1000 >> > +#define CONFIG_ENV_OFFSET_REDUND(CONFIG_ENV_OFFSET + >> > CONFIG_ENV_SIZE) >> > +#define CONFIG_SYS_REDUNDAND_ENVIRONMENT >> >> Is redundant env necessary? It seems like this was
Re: [U-Boot] [PATCH 2/2] am33xx: CONFIG_REVISION_TAG ifdef check for get_board_rev
Le jeudi 16 juillet 2015 à 09:20 -0400, Tom Rini a écrit : > On Thu, Jul 16, 2015 at 03:10:21PM +0200, Paul Kocialkowski wrote: > > > Despite being defined with __weak, this declaration of get_board_rev will > > conflict with the fallback one when ONFIG_REVISION_TAG is not defined. > > > > Signed-off-by: Paul Kocialkowski > > There is no support for am33xx boards and Linux-kernel board-file kernels > so lets just drop this weak default one and let boards that must have > this for various reasons implement a real one. That's right, we can actually simply remove the whole function. If that's okay, I'll just send another patch that replaces 2/2 and 1/2 should still be good for merging without another iteration. Thanks for the review! -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ signature.asc Description: This is a digitally signed message part ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/6] ARM64: hikey: hi6220: Add u-boot support for the 96boards CE HiKey board.
On Thu, Jul 16, 2015 at 08:28:03AM -0500, Rob Herring wrote: > On Wed, Jul 15, 2015 at 7:41 PM, Peter Griffin > wrote: [snip] > >> > +#define CONFIG_ENV_OFFSET 0x0 > >> > +#define CONFIG_ENV_SIZE0x1000 > >> > +#define CONFIG_ENV_OFFSET_REDUND(CONFIG_ENV_OFFSET + > >> > CONFIG_ENV_SIZE) > >> > +#define CONFIG_SYS_REDUNDAND_ENVIRONMENT > >> > >> Is redundant env necessary? It seems like this was more for raw NAND > >> and shouldn't really be needed for MMC. > > > > README file documents it as being valid for CONFIG_ENV_IS_IN_MMC, and a > > bunch of boards > > declare it with their CONFIG_ENV_IS_IN_MMC such as omap5_uevm.h, > > dra7xx_evm.h, > > am335x_evm.h. Whilst using managed NAND should be more reliable, I think it > > is still used in case there is a power failure whilst issuing 'saveenv'. > > Perhaps a bunch of cut and paste. I'd guess there are many more > platforms that use MMC and don't enable redundant. No, we turn it on, on purpose, out of a certain level of paranoia (and for ref boards like those, showing everything one could do, let $company and their experts argue of which failure possibilities are the important ones). > > Anyways with moving to CONFIG_ENV_IS_IN_FAT I won't need it anymore so it > > will be > > removed in V3. > > Storing in FAT probably only increases your chance of failure from > power failure. :) True but IMHO env in FAT is the most friendly option for a community board. "Broke your ENV? Stick the SD card in your PC, delete .." "Here, take a look at my env, copy this file ..." and all that. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] am33xx: Unused get_board_rev function removal
On Thu, Jul 16, 2015 at 03:36:41PM +0200, Paul Kocialkowski wrote: > All am33xx device tree are using device-tree, so get_board_rev is never > actually > called. Thus, we can get rid of it to make the code easier to maintain. > > Signed-off-by: Paul Kocialkowski Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] am33xx: Unused get_board_rev function removal
All am33xx device tree are using device-tree, so get_board_rev is never actually called. Thus, we can get rid of it to make the code easier to maintain. Signed-off-by: Paul Kocialkowski --- arch/arm/cpu/armv7/am33xx/sys_info.c | 9 - 1 file changed, 9 deletions(-) diff --git a/arch/arm/cpu/armv7/am33xx/sys_info.c b/arch/arm/cpu/armv7/am33xx/sys_info.c index 781d83f..52a6824 100644 --- a/arch/arm/cpu/armv7/am33xx/sys_info.c +++ b/arch/arm/cpu/armv7/am33xx/sys_info.c @@ -51,15 +51,6 @@ u32 get_cpu_type(void) } /** - * get_board_rev() - setup to pass kernel board revision information - * returns: 0 for the ATAG REVISION tag value. - */ -u32 __weak get_board_rev(void) -{ - return 0; -} - -/** * get_device_type(): tell if GP/HS/EMU/TST */ u32 get_device_type(void) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] spl: nand: simple: replace readb() with chip specific read_buf()
Hello Albert, On 16.07.2015 15:43, Albert ARIBAUD wrote: > Hello Vladimir, > > On Thu, 16 Jul 2015 14:31:26 +0300, Vladimir Zapolskiy > wrote: >> Hello Albert, >> >> On 16.07.2015 11:02, Albert ARIBAUD wrote: >>> Hello Vladimir, >>> >>> On Thu, 16 Jul 2015 02:33:45 +0300, Vladimir Zapolskiy >>> wrote: Some NAND controllers define custom functions to read data out, respect this in order to correctly support bad block handling in simple SPL NAND framework. NAND controller specific read_buf() is used even to read 1 byte in case of connected 8-bit NAND device, it turns out that read_byte() may become outdated. Signed-off-by: Vladimir Zapolskiy --- drivers/mtd/nand/nand_spl_simple.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/nand_spl_simple.c b/drivers/mtd/nand/nand_spl_simple.c index 700ca32..e69f662 100644 --- a/drivers/mtd/nand/nand_spl_simple.c +++ b/drivers/mtd/nand/nand_spl_simple.c @@ -115,6 +115,7 @@ static int nand_command(int block, int page, uint32_t offs, static int nand_is_bad_block(int block) { struct nand_chip *this = mtd.priv; + u_char bb_data[2]; nand_command(block, 0, CONFIG_SYS_NAND_BAD_BLOCK_POS, NAND_CMD_READOOB); @@ -123,10 +124,12 @@ static int nand_is_bad_block(int block) * Read one byte (or two if it's a 16 bit chip). */ if (this->options & NAND_BUSWIDTH_16) { - if (readw(this->IO_ADDR_R) != 0x) + this->read_buf(&mtd, bb_data, 2); + if (bb_data[0] != 0xff || bb_data[1] != 0xff) return 1; } else { - if (readb(this->IO_ADDR_R) != 0xff) + this->read_buf(&mtd, bb_data, 1); + if (bb_data[0] != 0xff) return 1; } -- 2.1.4 >>> >>> The way you describe this patch, it looks like a bug that should have >>> bitten way more boards than lpc32xx. Did you have a look at some other >>> boards to see why this did not affect them? >> >> Yes, it is a bug IMHO. > > If it is, then it has hit no board which defines CONFIG_SPL_NAND_SIMPLE > and we should understand why. > >> Grepping for CONFIG_SPL_NAND_SIMPLE I see that TI and Tegra boards may >> be impacted (positively or negatively): >> >> * CONFIG_NAND_OMAP_GPMC --- own .read_buf(), default .read_byte() >> * CONFIG_NAND_DAVINCI --- own .read_buf(), default .read_byte() >> * CONFIG_TEGRA_NAND --- own .read_byte(), own .read_buf() > > They may be impacted by your change, but they are working now -- they > are not obscure models. Let's dig a bit... For simplicity let's neglect 16-bit NANDs at the moment, readb() can be replaced by readw() etc. in my message. You may notice that nand_spl_simple.c exploits NAND driver specific .read_buf(), therefore the latter one must be defined (by driver or NAND framework), can it happen that .read_buf(..., 1) returns a different result from readb()? I hope in all cases above .read_buf(..., 1) is equal to common readb(), so okay, this is not a bug fix for currently supported drivers, but a misfeature, which does not allow to reuse nand_spl_simple.c for a slightly different NAND controller. Fortunately the proposed generalization of nand_spl_simple.c is straightforward. >>> Conversively, what is the actual failure scenario that led you to >>> writing this patch? >> >> The failure scenario is quite simple, the ARM core gets stuck on first >> attempt to access SLC NAND data register -- traced with JTAG. >> >> The same happens, if I remove custom .read_byte()/.read_buf() from SLC >> NAND driver. The only difference between custom .read_byte() and shared >> read_byte() is in readb()/readl() access to the data register, it is >> essential to have only 32-bit wide access to SLC NAND registers. > > README describes CONFIG_SPL_NAND_SIMPLE as "Support for NAND boot using > simple NAND drivers that expose the cmd_ctrl() interface". The cmd_ctrl > interface actually contains the cmd_ctrl() function *and* the > IO_ADDR_[RW] fields. IOW, a simple NAND driver provides byte or word > access to the NAND's I/O lines on which command, address and data are > passed. If the NAND is 8 bits, then there are 8 lines; if it is 16 > bit, then there are 16 lines. Please see my note above about read_buf(). nand_spl_simple.c is designed in such a way that it uses NAND driver specific interfaces (ECC specific interfaces are omitted here): * cmd_ctrl() * dev_ready() * read_buf() I agree that some of these interfaces may be populated by default NAND framework, if it is a deliberate intention to have only default functions, it might be better to hardcode default functions into nand_spl_simple.c , but this destroys flexibility. I would say README description of CONFIG_SPL_NAND_SIMPLE is not precisely correct. > I reckon that
Re: [U-Boot] [PATCH 1/4] spl: nand: simple: replace readb() with chip specific read_buf()
Hello Vladimir, On Thu, 16 Jul 2015 16:48:26 +0300, Vladimir Zapolskiy wrote: (cutting short to the essential point remaining) > > I personally don't think this is the right way; nand_simple.c should be > > left unchanged and the board should simply not use it since it does not > > have a simple NAND controller, and instead it should provide its own > > nand_spl_load_image(). > > For me an alternative change to the proposed one is to duplicate > nand_spl_simple.c functionality in LPC32xx SLC NAND driver. From > maintenance point of view this is not the best thing to do IMHO. You're right that some of the functionality present in nand_simple.c is duplicated elsewhere; however, that functionality is not the one specific to nand_simple; actually, it is nand_spl_load_image(), the overall load functionality which should be in no driver at all but of which I see ten incarnations in ten drivers. There should be only one nand_spl_load_image(), in its own file, with placeholders for driver-specific actions such as page read, bad page check, etc. One day, maybe, there will be a patch for that. Anyway: you propose changes in the design of the NAND subsystem so that the SLC controller driver can use the "simple" model, while I think the SLC controller is not "simple" so it should not be managed as one. This dilemma is about the NAND subsystem design, which is wy outside my province -- hence my deferring to Scott, who will decide which way this should go. > > But hey, I'm not then NAND custodian. Scott: your call. :) > > Anyway thank you for review and comments. You're welcome! > -- > With best wishes, > Vladimir Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/11] imx: mx7 dm thermal driver support
Hi Adrian, On Wed, Jul 15, 2015 at 7:49 PM, Adrian Alonso wrote: > diff --git a/include/configs/mx6cuboxi.h b/include/configs/mx6cuboxi.h > index 3d5bba7..d42b7f0 100644 > --- a/include/configs/mx6cuboxi.h > +++ b/include/configs/mx6cuboxi.h > @@ -14,7 +14,7 @@ > #define CONFIG_SPL_MMC_SUPPORT > #include "imx6_spl.h" > > -#define CONFIG_IMX6_THERMAL > +#define CONFIG_IMX_THERMAL This would cause a conflict with Peter Robinson's series that centralizas CONFIG_IMX6_THERMAL ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/11] imx: power: add pmic pfuze300 support
On Wed, Jul 15, 2015 at 7:49 PM, Adrian Alonso wrote: > * Add pmic pfuze300 support for imx7 and iMX6 DL/SL/SX SoC's The PMIC support is independent of the CPU that is used, so I would remove the "imx7 and iMX6 DL/SL/SX SoC's". Also, in the subject you should remove imx, as this patch is not related to imx. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net: phy: broadcom: Add BCM Cygnus PHY
Hello Steve, On Wed, 15 Jul 2015 16:28:13 -0700, Steve Rae wrote: > From: Jiandong Zheng > > Add Ethernet PHY for BCM Cygnus SoC > > Signed-off-by: Jiandong Zheng > Signed-off-by: Steve Rae > --- > > drivers/net/phy/broadcom.c | 29 + > 1 file changed, 29 insertions(+) This patch does not add the PHY in drivers/net/phy/Makefile. How does the object file ever get built? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net: phy: broadcom: Add BCM Cygnus PHY
On Thu, 16 Jul 2015 16:29:45 +0200, Albert ARIBAUD wrote: > Hello Steve, > > On Wed, 15 Jul 2015 16:28:13 -0700, Steve Rae wrote: > > From: Jiandong Zheng > > > > Add Ethernet PHY for BCM Cygnus SoC > > > > Signed-off-by: Jiandong Zheng > > Signed-off-by: Steve Rae > > --- > > > > drivers/net/phy/broadcom.c | 29 + > > 1 file changed, 29 insertions(+) > > This patch does not add the PHY in drivers/net/phy/Makefile. > How does the object file ever get built? Scratch that, I misread this as an addition. Time for a coffee break. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] sunxi: nand: Basic NAND driver with SPL support
This is a basic driver for the sunxi NAND controller for Allwinner A20. It supports both SPL and U-Boot. The driver uses DMA for data transfers. It does not support writing. To enable user reading from NADN, the a20_nandread command was added. Piotr Zierhoffer (4): sunxi: nand: Add basic sunxi NAND driver with DMA support sunxi: nand: Add board configuration options sunxi: nand: Add a20_nandread command to load image from NAND in SPL sunxi: nand: Add information to sunxi that it was run from NAND in SPL arch/arm/cpu/armv7/sunxi/board.c | 4 + board/sunxi/Kconfig | 10 ++ board/sunxi/Makefile | 1 + board/sunxi/nand.c | 315 +++ board/sunxi/nand.h | 146 ++ common/Makefile | 1 + common/cmd_a20_nandread.c| 25 include/configs/sunxi-common.h | 13 ++ 8 files changed, 515 insertions(+) create mode 100644 board/sunxi/nand.c create mode 100644 board/sunxi/nand.h create mode 100644 common/cmd_a20_nandread.c -- 2.3.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] sunxi: nand: Add basic sunxi NAND driver with DMA support
From: Piotr Zierhoffer This driver adds NAND support to both SPL and full U-Boot. It was tested on AllWinner A20. Signed-off-by: Peter Gielda Signed-off-by: Tomasz Gorochowik Signed-off-by: Mateusz Holenko Signed-off-by: Piotr Zierhoffer --- board/sunxi/Makefile | 1 + board/sunxi/nand.c | 315 +++ board/sunxi/nand.h | 146 3 files changed, 462 insertions(+) create mode 100644 board/sunxi/nand.c create mode 100644 board/sunxi/nand.h diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile index 43766e0..6f1d571 100644 --- a/board/sunxi/Makefile +++ b/board/sunxi/Makefile @@ -9,6 +9,7 @@ # SPDX-License-Identifier: GPL-2.0+ # obj-y += board.o +obj-$(CONFIG_SUNXI_NAND) += nand.o obj-$(CONFIG_SUNXI_GMAC) += gmac.o obj-$(CONFIG_SUNXI_AHCI) += ahci.o obj-$(CONFIG_MACH_SUN4I) += dram_sun4i_auto.o diff --git a/board/sunxi/nand.c b/board/sunxi/nand.c new file mode 100644 index 000..16e8e4d --- /dev/null +++ b/board/sunxi/nand.c @@ -0,0 +1,315 @@ +/* + * Copyright (c) 2014-2015, Antmicro Ltd + * Copyright (c) 2015, AW-SOM Technologies + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include +#include +#include +#include +#include "nand.h" /* sunxi specific header */ + +/* minimal "boot0" style NAND support for Allwinner A20 */ + +/* temporary buffer in internal ram */ +#ifdef CONFIG_SPL_BUILD +/* in SPL temporary buffer cannot be @ 0x0 */ +unsigned char temp_buf[SPL_WRITE_SIZE] __aligned(0x10) __section(".text#"); +#else +/* put temporary buffer @ 0x0 */ +unsigned char *temp_buf = (unsigned char *)0x0; +#endif + +#define MAX_RETRIES 10 + +static int check_value_inner(int offset, int expected_bits, + int max_number_of_retries, int negation) +{ + int retries = 0; + do { + int val = readl(offset) & expected_bits; + if (negation ? !val : val) + return 1; + mdelay(1); + retries++; + } while (retries < max_number_of_retries); + + return 0; +} + +static inline int check_value(int offset, int expected_bits, + int max_number_of_retries) +{ + return check_value_inner(offset, expected_bits, + max_number_of_retries, 0); +} + +static inline int check_value_negated(int offset, int unexpected_bits, + int max_number_of_retries) +{ + return check_value_inner(offset, unexpected_bits, + max_number_of_retries, 1); +} + +void nand_set_clocks(void) +{ + uint32_t val; + + writel(PORTC_PC_CFG0_NRB1 | + PORTC_PC_CFG0_NRB0 | + PORTC_PC_CFG0_NRE | + PORTC_PC_CFG0_NCE0 | + PORTC_PC_CFG0_NCE1 | + PORTC_PC_CFG0_NCLE | + PORTC_PC_CFG0_NALE | + PORTC_PC_CFG0_NWE, PORTC_BASE + PORTC_PC_CFG0); + + writel(PORTC_PC_CFG1_NDQ7 | + PORTC_PC_CFG1_NDQ6 | + PORTC_PC_CFG1_NDQ5 | + PORTC_PC_CFG1_NDQ4 | + PORTC_PC_CFG1_NDQ3 | + PORTC_PC_CFG1_NDQ2 | + PORTC_PC_CFG1_NDQ1 | + PORTC_PC_CFG1_NDQ0, PORTC_BASE + PORTC_PC_CFG1); + + writel(PORTC_PC_CFG2_NCE7 | + PORTC_PC_CFG2_NCE6 | + PORTC_PC_CFG2_NCE5 | + PORTC_PC_CFG2_NCE4 | + PORTC_PC_CFG2_NCE3 | + PORTC_PC_CFG2_NCE2 | + PORTC_PC_CFG2_NWP, PORTC_BASE + PORTC_PC_CFG2); + + writel(PORTC_PC_CFG3_NDQS, PORTC_BASE + PORTC_PC_CFG3); + + val = readl(CCU_BASE + CCU_AHB_GATING_REG0); + writel(CCU_AHB_GATING_REG0_NAND | val, CCU_BASE + CCU_AHB_GATING_REG0); + + val = readl(CCU_BASE + CCU_NAND_SCLK_CFG_REG); + writel(val | CCU_NAND_SCLK_CFG_REG_SCLK_GATING + | CCU_NAND_SCLK_CFG_REG_CLK_DIV_RATIO, + CCU_BASE + CCU_NAND_SCLK_CFG_REG); +} + +int nand_initialized; + +void nand_init(void) +{ + board_nand_init(NULL); +} + +uint32_t ecc_errors; + +/* read 0x400 bytes from real_addr to temp_buf */ +void nand_read_block(unsigned int real_addr, int syndrome) +{ + uint32_t val; + int ECC_OFF = 0; + uint16_t ecc_mode = 0; + uint16_t rand_seed; + uint32_t page; + uint16_t column; + uint32_t oob_offset; + + if (!nand_initialized) + board_nand_init(NULL); + + switch (CONFIG_SUNXI_ECC_STRENGTH) { + case 16: + ecc_mode = 0; + ECC_OFF = 0x20; + break; + case 24: + ecc_mode = 1; + ECC_OFF = 0x2e; + break; + case 28: + ecc_mode = 2; + ECC_OFF = 0x32; + break; + case 32: + ecc_mode = 3; + ECC_OFF = 0x3c; +
[U-Boot] [PATCH 2/4] sunxi: nand: Add board configuration options
From: Piotr Zierhoffer When SUNXI_NAND option is selected in config, set some configuration options for sunxi NAND. This commit also introduces the configurable options in Kconfig. Signed-off-by: Peter Gielda Signed-off-by: Tomasz Gorochowik Signed-off-by: Mateusz Holenko Signed-off-by: Piotr Zierhoffer --- board/sunxi/Kconfig| 10 ++ include/configs/sunxi-common.h | 11 +++ 2 files changed, 21 insertions(+) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 2a1cd3c..3b76d64 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -227,6 +227,16 @@ config OLD_SUNXI_KERNEL_COMPAT Set this to enable various workarounds for old kernels, this results in sub-optimal settings for newer kernels, only enable if needed. +config SUNXI_NAND + bool "Support for NAND on Allwinner A20" + depends on MACH_SUN7I + ---help--- + Enable support for internal NAND. This option allows U-Boot to read from + sunxi NAND using DMA transfers. It also adds the a20_nandread command + that allows user to transfer a specified amount of data from NAND to + memory. Both SPL and full U-Boot driver are enabled. Writing is not + supported. + config MMC0_CD_PIN string "Card detect pin for mmc0" default "" diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 9576bc1..83922ab 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -139,6 +139,17 @@ #define CONFIG_INITRD_TAG #define CONFIG_SERIAL_TAG +#if defined(CONFIG_SUNXI_NAND) +#define CONFIG_SPL_NAND_DRIVERS +#define CONFIG_SPL_NAND_SUPPORT +#define CONFIG_CMD_SPL_WRITE_SIZE 0x000400 /* 1024 byte */ + +#define CONFIG_SYS_NAND_SPL_KERNEL_OFFS 0x28 +#define CONFIG_SYS_NAND_U_BOOT_OFFS 0x008000 +#define CONFIG_SYS_NAND_PAGE_SIZE 0x002000 /* 8kb*/ +#define CONFIG_SUNXI_ECC_STRENGTH 40 +#endif + /* mmc config */ #if !defined(CONFIG_UART0_PORT_F) #define CONFIG_MMC -- 2.3.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] sunxi: nand: Add information to sunxi that it was run from NAND in SPL
As SPL does not know which source to choose when booting U-Boot, choose NAND if it is capable of doing so. Signed-off-by: Peter Gielda Signed-off-by: Tomasz Gorochowik Signed-off-by: Mateusz Holenko Signed-off-by: Piotr Zierhoffer --- arch/arm/cpu/armv7/sunxi/board.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c index 5f39aa0..e4b7d63 100644 --- a/arch/arm/cpu/armv7/sunxi/board.c +++ b/arch/arm/cpu/armv7/sunxi/board.c @@ -128,6 +128,9 @@ void s_init(void) */ u32 spl_boot_device(void) { +#ifdef CONFIG_SPL_NAND_SUPPORT + return BOOT_DEVICE_NAND; +#else /* * When booting from the SD card, the "eGON.BT0" signature is expected * to be found in memory at the address 0x0004 (see the "mksunxiboot" @@ -148,6 +151,7 @@ u32 spl_boot_device(void) return BOOT_DEVICE_MMC1; else return BOOT_DEVICE_BOARD; +#endif } /* No confirmation data available in SPL yet. Hardcode bootmode */ -- 2.3.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] sunxi: nand: Add a20_nandread command to load image from NAND in SPL
From: Piotr Zierhoffer The usage of the command is: a20_nandread It allows user to copy data from NAND to memory. It employs nand_spl_load_image from the sunxi NAND driver. It is added only when the NAND support is enabled. Signed-off-by: Peter Gielda Signed-off-by: Tomasz Gorochowik Signed-off-by: Mateusz Holenko Signed-off-by: Piotr Zierhoffer --- common/Makefile| 1 + common/cmd_a20_nandread.c | 25 + include/configs/sunxi-common.h | 2 ++ 3 files changed, 28 insertions(+) create mode 100644 common/cmd_a20_nandread.c diff --git a/common/Makefile b/common/Makefile index d6c1d48..ef31646 100644 --- a/common/Makefile +++ b/common/Makefile @@ -126,6 +126,7 @@ obj-$(CONFIG_ID_EEPROM) += cmd_mac.o obj-$(CONFIG_CMD_MD5SUM) += cmd_md5sum.o obj-$(CONFIG_CMD_MEMORY) += cmd_mem.o obj-$(CONFIG_CMD_IO) += cmd_io.o +obj-$(CONFIG_CMD_A20_NANDREAD) += cmd_a20_nandread.o obj-$(CONFIG_CMD_MFSL) += cmd_mfsl.o obj-$(CONFIG_MII) += miiphyutil.o obj-$(CONFIG_CMD_MII) += miiphyutil.o diff --git a/common/cmd_a20_nandread.c b/common/cmd_a20_nandread.c new file mode 100644 index 000..6469535 --- /dev/null +++ b/common/cmd_a20_nandread.c @@ -0,0 +1,25 @@ +#include +#include +#include + +static int do_a20_nandread(cmd_tbl_t *cmdtp, int flag, int argc, + char * const argv[]) +{ + if (argc != 4) { + printf("usage: a20_nandread \n"); + return 1; + } + + uint32_t dst = simple_strtoul(argv[1], NULL, 16); + uint32_t src = simple_strtoul(argv[2], NULL, 16); + uint32_t cnt = simple_strtoul(argv[3], NULL, 16); + printf("Reading 0x%08X bytes from NAND @ 0x%08X to MEM @ 0x%08X...\n", + cnt, src, dst); + nand_spl_load_image(src, cnt, (void *)dst); + printf("\n"); + return 0; +} + +U_BOOT_CMD(a20_nandread, CONFIG_SYS_MAXARGS, 3, + do_a20_nandread, "a20_nandread", "[destination source size]\n" " " +); diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 83922ab..e9cfa9a 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -148,6 +148,8 @@ #define CONFIG_SYS_NAND_U_BOOT_OFFS 0x008000 #define CONFIG_SYS_NAND_PAGE_SIZE 0x002000 /* 8kb*/ #define CONFIG_SUNXI_ECC_STRENGTH 40 + +#define CONFIG_CMD_A20_NANDREAD #endif /* mmc config */ -- 2.3.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
On Mon 2015-07-13 22:52:58, Stephen Warren wrote: > On 07/11/2015 08:04 AM, Simon Glass wrote: > > Hi Stephen, > > > > On 10 July 2015 at 23:34, Stephen Warren wrote: > >> On 07/07/2015 08:53 PM, Simon Glass wrote: > >>> Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor. > >>> Neither of these currently support driver model. > >>> > >>> This series does the following: > >>> - Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead of > >>> u-boot.bin) > >> > >> I'd strongly prefer not to do this. For one thing, it means we'd need > >> different U-Boot builds for each of the different RPi models, and we > >> currently don't need that (or perhaps we require users to create their > >> own u-boot-dtb.bin by choosing the right DTB to append). If it > > > > Why does device tree change how things work now? The get_board_rev() > > function currently deals with this. It doesn't look like rpi_board_rev > > is used anywhere else. > > Without a DT, the code is free to make all the board-rev-specific > decisions at run-time without external influence. > > With a DT, we either have to: > > a) Pick the DT for one particular board and use that everywhere, even if > it's incorrect for the actual board in use. Is that an option? I mean... if you can tolerate incorrect values for something, perhaps that something should not be in the dtb in the first place? > b) Build a different U-Boot + DTB image for each board-rev, and put the > correct one on the SD card. d) Build U-Boot + set of DTB images, then pick up the right one at the runtime? > Neither of those options seem like a good idea to me. Stuff that can be autodetected does not belong to the device tree... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board: ks2: README: fix typos
Fix up a few typos in documentation. Signed-off-by: Nishanth Menon --- board/ti/ks2_evm/README | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/board/ti/ks2_evm/README b/board/ti/ks2_evm/README index 9ee90a4f9d03..6586faba32eb 100644 --- a/board/ti/ks2_evm/README +++ b/board/ti/ks2_evm/README @@ -47,7 +47,6 @@ Board configuration files: include/configs/k2hk_evm.h include/configs/k2e_evm.h include/configs/k2l_evm.h -include/configs/k2l_evm.h As u-boot is migrating to Kconfig there is also board defconfig files configs/k2e_evm_defconfig @@ -71,7 +70,7 @@ Don't forget to add ARCH=arm and CROSS_COMPILE. To build u-boot.bin >make k2hk_evm_defconfig - >make u-boot-spi.gph + >make u-boot.bin To build u-boot-spi.gph >make k2hk_evm_defconfig -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] configs: make keystone2 config to start using arm_v7_common header
For legacy reasons, keystone2 had kind of stayed completely seperated from the rest of the TI SoC families. This makes no sense since there are a lot of common definitions that can be reused between all SoC configuration allowing for a consistent user experience. So make keystone2 follow the rest of the TI SoCs based on OMAP architecture as well. Test log: K2H: http://pastebin.ubuntu.com/11888160/ (using https://patchwork.ozlabs.org/patch/440665/) I have no other platform to verify on. Series based on master 4905dfc65d9a Merge branch 'master' of git://git.denx.de/u-boot-spi Nishanth Menon (3): configs: split ti_armv7_common into a omap generic header configs: rename ks2_evm into ti_armv7_keystone2 configs: ti_armv7_keystone2: start using armv7_common include/configs/am43xx_evm.h | 2 +- include/configs/k2e_evm.h | 4 +- include/configs/k2hk_evm.h | 4 +- include/configs/k2l_evm.h | 4 +- include/configs/ti_am335x_common.h | 2 +- include/configs/ti_armv7_common.h | 31 -- .../configs/{ks2_evm.h => ti_armv7_keystone2.h}| 50 +++--- include/configs/ti_armv7_omap.h| 49 + include/configs/ti_omap3_common.h | 2 +- include/configs/ti_omap4_common.h | 2 +- include/configs/ti_omap5_common.h | 2 +- 11 files changed, 81 insertions(+), 71 deletions(-) rename include/configs/{ks2_evm.h => ti_armv7_keystone2.h} (90%) create mode 100644 include/configs/ti_armv7_omap.h -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] configs: split ti_armv7_common into a omap generic header
TI armv7 based SoCs are based on two architectures - one based on OMAP generation architecture and others based on Keystone architecture. Many of the options are architecture specific, however a lot are common with v7 architecture. So, step 1 will be to move out OMAP specific stuff from ti_armv7_common into a ti_armv7_omap.h header which is then used by all the relevant architecture headers. Signed-off-by: Nishanth Menon --- include/configs/am43xx_evm.h | 2 +- include/configs/ti_am335x_common.h | 2 +- include/configs/ti_armv7_common.h | 21 include/configs/ti_armv7_omap.h| 49 ++ include/configs/ti_omap3_common.h | 2 +- include/configs/ti_omap4_common.h | 2 +- include/configs/ti_omap5_common.h | 2 +- 7 files changed, 54 insertions(+), 26 deletions(-) create mode 100644 include/configs/ti_armv7_omap.h diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h index 33e534a76583..65ac8ef34eb8 100644 --- a/include/configs/am43xx_evm.h +++ b/include/configs/am43xx_evm.h @@ -80,7 +80,7 @@ #endif /* Now bring in the rest of the common code. */ -#include +#include /* Always 64 KiB env size */ #define CONFIG_ENV_SIZE(64 << 10) diff --git a/include/configs/ti_am335x_common.h b/include/configs/ti_am335x_common.h index 4d2ae280e7f1..9697431b4496 100644 --- a/include/configs/ti_am335x_common.h +++ b/include/configs/ti_am335x_common.h @@ -94,6 +94,6 @@ #endif /* Now bring in the rest of the common code. */ -#include +#include #endif /* __CONFIG_TI_AM335X_COMMON_H__ */ diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h index 0aea7d12ec16..63244dbc83ff 100644 --- a/include/configs/ti_armv7_common.h +++ b/include/configs/ti_armv7_common.h @@ -18,8 +18,6 @@ #define __CONFIG_TI_ARMV7_COMMON_H__ /* Common define for many platforms. */ -#define CONFIG_OMAP -#define CONFIG_OMAP_COMMON #define CONFIG_SYS_GENERIC_BOARD /* @@ -86,39 +84,20 @@ #define CONFIG_I2C #define CONFIG_CMD_I2C #define CONFIG_SYS_I2C -#define CONFIG_SYS_OMAP24_I2C_SPEED10 -#define CONFIG_SYS_OMAP24_I2C_SLAVE1 -#define CONFIG_SYS_I2C_OMAP24XX /* MMC/SD IP block */ #define CONFIG_MMC #define CONFIG_GENERIC_MMC -#define CONFIG_OMAP_HSMMC #define CONFIG_CMD_MMC /* McSPI IP block */ #define CONFIG_SPI -#define CONFIG_OMAP3_SPI #define CONFIG_CMD_SPI /* GPIO block */ -#define CONFIG_OMAP_GPIO #define CONFIG_CMD_GPIO /* - * GPMC NAND block. We support 1 device and the physical address to - * access CS0 at is 0x800. - */ -#ifdef CONFIG_NAND -#define CONFIG_NAND_OMAP_GPMC -#ifndef CONFIG_SYS_NAND_BASE -#define CONFIG_SYS_NAND_BASE 0x800 -#endif -#define CONFIG_SYS_MAX_NAND_DEVICE 1 -#define CONFIG_CMD_NAND -#endif - -/* * The following are general good-enough settings for U-Boot. We set a * large malloc pool as we generally have a lot of DDR, and we opt for * function over binary size in the main portion of U-Boot as this is diff --git a/include/configs/ti_armv7_omap.h b/include/configs/ti_armv7_omap.h new file mode 100644 index ..7548170afcf7 --- /dev/null +++ b/include/configs/ti_armv7_omap.h @@ -0,0 +1,49 @@ +/* + * ti_armv7_omap.h + * + * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/ + * + * SPDX-License-Identifier:GPL-2.0+ + * + * The various ARMv7 SoCs from TI all share a number of IP blocks when + * implementing a given feature. This is meant to isolate the features + * that are based on OMAP architecture. + */ +#ifndef __CONFIG_TI_ARMV7_OMAP_H__ +#define __CONFIG_TI_ARMV7_OMAP_H__ + +/* Common defines for all OMAP architecture based SoCs */ +#define CONFIG_OMAP +#define CONFIG_OMAP_COMMON + +/* I2C IP block */ +#define CONFIG_SYS_OMAP24_I2C_SPEED10 +#define CONFIG_SYS_OMAP24_I2C_SLAVE1 +#define CONFIG_SYS_I2C_OMAP24XX + +/* MMC/SD IP block */ +#define CONFIG_OMAP_HSMMC + +/* SPI IP Block */ +#define CONFIG_OMAP3_SPI + +/* GPIO block */ +#define CONFIG_OMAP_GPIO + +/* + * GPMC NAND block. We support 1 device and the physical address to + * access CS0 at is 0x800. + */ +#ifdef CONFIG_NAND +#define CONFIG_NAND_OMAP_GPMC +#ifndef CONFIG_SYS_NAND_BASE +#define CONFIG_SYS_NAND_BASE 0x800 +#endif +#define CONFIG_SYS_MAX_NAND_DEVICE 1 +#define CONFIG_CMD_NAND +#endif + +/* Now for the remaining common defines */ +#include + +#endif /* __CONFIG_TI_ARMV7_OMAP_H__ */ diff --git a/include/configs/ti_omap3_common.h b/include/configs/ti_omap3_common.h index 429b109afa23..be231a551361 100644 --- a/include/configs/ti_omap3_common.h +++ b/include/configs/ti_omap3_common.h @@ -84,6 +84,6 @@ #endif /* Now bring in the rest of the common code. */ -#include +#include #endif /* __CONFIG_TI_OMAP3_COMMON_H__ */ diff --git a/include/configs/ti_omap4_common.h b/include/configs/ti_omap4_common.h index e96613406b3b..959f312edb5b 100644 --- a/include/configs/t
[U-Boot] [PATCH 3/3] configs: ti_armv7_keystone2: start using armv7_common
Try to maintain as much commonality by conditionally including stuff in armv7_common as necessary and removing the common defines from keystone2 header. Signed-off-by: Nishanth Menon --- note: this has a minor 80char checkpatch warning for definition, which i kind of left alone considering bit of readability subjective view.. include/configs/k2e_evm.h| 2 -- include/configs/k2hk_evm.h | 2 -- include/configs/k2l_evm.h| 2 -- include/configs/ti_armv7_common.h| 10 +++- include/configs/ti_armv7_keystone2.h | 50 +++- 5 files changed, 24 insertions(+), 42 deletions(-) diff --git a/include/configs/k2e_evm.h b/include/configs/k2e_evm.h index ac50a01b2980..f1e650141ae1 100644 --- a/include/configs/k2e_evm.h +++ b/include/configs/k2e_evm.h @@ -15,8 +15,6 @@ #define CONFIG_K2E_EVM /* U-Boot general configuration */ -#define CONFIG_SYS_PROMPT "K2E EVM # " - #define CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS\ "addr_mon=0x0c14\0" \ "args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs "\ diff --git a/include/configs/k2hk_evm.h b/include/configs/k2hk_evm.h index 29e3403aa082..f8e83de64b63 100644 --- a/include/configs/k2hk_evm.h +++ b/include/configs/k2hk_evm.h @@ -15,8 +15,6 @@ #define CONFIG_K2HK_EVM /* U-Boot general configuration */ -#define CONFIG_SYS_PROMPT "K2HK EVM # " - #define CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS\ "addr_mon=0x0c5f\0" \ "args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs "\ diff --git a/include/configs/k2l_evm.h b/include/configs/k2l_evm.h index 50d5c991a0bb..395608a5f6db 100644 --- a/include/configs/k2l_evm.h +++ b/include/configs/k2l_evm.h @@ -15,8 +15,6 @@ #define CONFIG_K2L_EVM /* U-Boot general configuration */ -#define CONFIG_SYS_PROMPT "K2L EVM # " - #define CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS\ "addr_mon=0x0c14\0" \ "args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs "\ diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h index 63244dbc83ff..477454ce6d37 100644 --- a/include/configs/ti_armv7_common.h +++ b/include/configs/ti_armv7_common.h @@ -38,7 +38,9 @@ * However, set this to a 32MB offset to allow for easier Linux kernel * booting as the default is often used as the kernel load address. */ +#ifndef CONFIG_SYS_LOAD_ADDR #define CONFIG_SYS_LOAD_ADDR 0x8200 +#endif /* * We setup defaults based on constraints from the Linux kernel, which should @@ -73,9 +75,15 @@ #ifndef CONFIG_NR_DRAM_BANKS #define CONFIG_NR_DRAM_BANKS 1 #endif + +#ifndef CONFIG_SYS_SDRAM_BASE #define CONFIG_SYS_SDRAM_BASE 0x8000 +#endif + +#ifndef CONFIG_SYS_INIT_SP_ADDR #define CONFIG_SYS_INIT_SP_ADDR (NON_SECURE_SRAM_END - \ GENERATED_GBL_DATA_SIZE) +#endif /* Timer information. */ #define CONFIG_SYS_PTV 2 /* Divisor: 2^(PTV+1) => 8 */ @@ -140,7 +148,7 @@ * mtdparts, both for ease of use in U-Boot and for passing information * on to the Linux kernel. */ -#if defined(CONFIG_SPI_BOOT) || defined(CONFIG_NOR) || defined(CONFIG_NAND) +#if defined(CONFIG_SPI_BOOT) || defined(CONFIG_NOR) || defined(CONFIG_NAND) || defined(CONFIG_NAND_DAVINCI) #define CONFIG_MTD_DEVICE /* Required for mtdparts */ #define CONFIG_CMD_MTDPARTS #endif diff --git a/include/configs/ti_armv7_keystone2.h b/include/configs/ti_armv7_keystone2.h index e05d56cd8262..35d0ab09a6d3 100644 --- a/include/configs/ti_armv7_keystone2.h +++ b/include/configs/ti_armv7_keystone2.h @@ -14,10 +14,7 @@ /* U-Boot Build Configuration */ #define CONFIG_SKIP_LOWLEVEL_INIT /* U-Boot is a 2nd stage loader */ -#define CONFIG_SYS_NO_FLASH/* that is, no *NOR* flash */ -#define CONFIG_SYS_CONSOLE_INFO_QUIET #define CONFIG_BOARD_EARLY_INIT_F -#define CONFIG_SYS_THUMB_BUILD /* SoC Configuration */ #define CONFIG_ARCH_CPU_INIT @@ -32,7 +29,6 @@ #define CONFIG_SYS_LPAE_SDRAM_BASE 0x8 #define CONFIG_MAX_RAM_BANK_SIZE (2 << 30) /* 2GB */ #define CONFIG_STACKSIZE (512 << 10) /* 512 KiB */ -#define CONFIG_SYS_MALLOC_LEN (4 << 20) /* 4 MiB */ #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_TEXT_BASE - \ GENERATED_GBL_DATA_SIZE) @@ -49,15 +45,10 @@ #define CONFIG_SPL_STACK (CONFIG_SYS_SPL_MALLOC_START + \ CONFIG_SYS_SPL_MALLOC_SIZE + \ CONFIG_SPL_STACK_SIZE - 4) -#define CONFIG_SPL_LIBCOMMON_SUPPORT -#define CONFIG_SPL_LIBGENERIC_SUPPORT -#define CON
[U-Boot] [PATCH 2/3] configs: rename ks2_evm into ti_armv7_keystone2
rename the keystone2 common header into an keystone2 architecture specific header which can then reuse the common ti_armv7 config headers. Signed-off-by: Nishanth Menon --- include/configs/k2e_evm.h | 2 +- include/configs/k2hk_evm.h | 2 +- include/configs/k2l_evm.h | 2 +- include/configs/{ks2_evm.h => ti_armv7_keystone2.h} | 0 4 files changed, 3 insertions(+), 3 deletions(-) rename include/configs/{ks2_evm.h => ti_armv7_keystone2.h} (100%) diff --git a/include/configs/k2e_evm.h b/include/configs/k2e_evm.h index a28ceb7064a7..ac50a01b2980 100644 --- a/include/configs/k2e_evm.h +++ b/include/configs/k2e_evm.h @@ -27,7 +27,7 @@ "name_uboot=u-boot-spi-k2e-evm.gph\0" \ "name_fs=arago-console-image-k2e-evm.cpio.gz\0" -#include +#include /* SPL SPI Loader Configuration */ #define CONFIG_SPL_TEXT_BASE 0x0c10 diff --git a/include/configs/k2hk_evm.h b/include/configs/k2hk_evm.h index eae772178338..29e3403aa082 100644 --- a/include/configs/k2hk_evm.h +++ b/include/configs/k2hk_evm.h @@ -27,7 +27,7 @@ "name_uboot=u-boot-spi-k2hk-evm.gph\0" \ "name_fs=arago-console-image-k2hk-evm.cpio.gz\0" -#include +#include /* SPL SPI Loader Configuration */ #define CONFIG_SPL_TEXT_BASE 0x0c20 diff --git a/include/configs/k2l_evm.h b/include/configs/k2l_evm.h index 57da0579255a..50d5c991a0bb 100644 --- a/include/configs/k2l_evm.h +++ b/include/configs/k2l_evm.h @@ -27,7 +27,7 @@ "name_uboot=u-boot-spi-k2l-evm.gph\0" \ "name_fs=arago-console-image-k2l-evm.cpio.gz\0" -#include +#include /* SPL SPI Loader Configuration */ #define CONFIG_SPL_TEXT_BASE 0x0c10 diff --git a/include/configs/ks2_evm.h b/include/configs/ti_armv7_keystone2.h similarity index 100% rename from include/configs/ks2_evm.h rename to include/configs/ti_armv7_keystone2.h -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/11] imx: mx7dsabresd: Add support for MX7D SABRESD board
On Wed, Jul 15, 2015 at 7:49 PM, Adrian Alonso wrote: > * Add i.MX7D SABRESD board BSP codes, with enabled modules: Better to remove "board BSP codes" as this is too vague. > UART, PMIC, USB/OTG, SD, eMMC, ENET, I2C, 74LV IOX. > > Build target: mx7dsabresd_config > > Signed-off-by: Peng Fan > Signed-off-by: Fugang Duan > Signed-off-by: Ye.Li > Signed-off-by: Adrian Alonso > --- > board/freescale/mx7dsabresd/Kconfig | 15 + > board/freescale/mx7dsabresd/Makefile | 6 + > board/freescale/mx7dsabresd/imximage.cfg | 110 + > board/freescale/mx7dsabresd/mx7dsabresd.c | 656 > ++ > configs/mx7dsabresd_defconfig | 10 + > include/configs/mx7_common.h | 22 + > include/configs/mx7dsabresd.h | 382 + > 7 files changed, 1201 insertions(+) > create mode 100644 board/freescale/mx7dsabresd/Kconfig > create mode 100644 board/freescale/mx7dsabresd/Makefile > create mode 100644 board/freescale/mx7dsabresd/imximage.cfg > create mode 100644 board/freescale/mx7dsabresd/mx7dsabresd.c > create mode 100644 configs/mx7dsabresd_defconfig > create mode 100644 include/configs/mx7_common.h > create mode 100644 include/configs/mx7dsabresd.h You missed to add a MAINTAINERS file for this board. > --- /dev/null > +++ b/board/freescale/mx7dsabresd/imximage.cfg > @@ -0,0 +1,110 @@ > +/* > + * Copyright (C) 2015 Freescale Semiconductor, Inc. > + * > + * SPDX-License-Identifier:GPL-2.0+ > + * > + * Refer docs/README.imxmage for more details about how-to configure > + * and create imximage boot image > + * > + * The syntax is taken as close as possible with the kwbimage > + */ > + > +#define __ASSEMBLY__ > +#include > + > +/* image version */ > + > +IMAGE_VERSION 2 > + > +/* > + * Boot Device : one of > + * spi/sd/nand/onenand, qspi/nor > + */ > + > +#ifdef CONFIG_SYS_BOOT_QSPI > +BOOT_FROM qspi > +#elif defined(CONFIG_SYS_BOOT_EIMNOR) > +BOOT_FROM nor > +#else > +BOOT_FROM sd > +#endif > + > +#ifdef CONFIG_USE_PLUGIN This option only exists in the FSL U-boot, not in mainline. > +/*PLUGINplugin-binary-fileIRAM_FREE_START_ADDR*/ > +PLUGIN board/freescale/mx7dsabresd/plugin.bin 0x0091 > +#else > + > +#ifdef CONFIG_SECURE_BOOT > +CSF CONFIG_CSF_SIZE > +#endif > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include "../common/pfuze.h" > +#ifdef CONFIG_SYS_I2C_MXC No need to use ifdef for header files. > +static struct fsl_esdhc_cfg usdhc_cfg[3] = { > + {USDHC1_BASE_ADDR, 0, 4}, > + {USDHC3_BASE_ADDR}, > +}; > + > +int mmc_get_env_devno(void) static > +{ > + struct bootrom_sw_info **p = > + (struct bootrom_sw_info **)ROM_SW_INFO_ADDR; > + > + u8 boot_type = (*p)->boot_dev_type; > + u8 dev_no = (*p)->boot_dev_instance; > + > + /* If not boot from sd/mmc, use default value */ > + if ((boot_type != BOOT_TYPE_SD) && (boot_type != BOOT_TYPE_MMC)) > + return CONFIG_SYS_MMC_ENV_DEV; > + > + if (2 == dev_no) > + dev_no--; > + > + return dev_no; > +} > + > +int mmc_map_to_kernel_blk(int dev_no) static > +{ > + if (1 == dev_no) > + dev_no++; > + > + return dev_no; > +} > + > +int board_mmc_getcd(struct mmc *mmc) > +{ > + struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv; > + int ret = 0; > + > + switch (cfg->esdhc_base) { > + case USDHC1_BASE_ADDR: > + ret = !gpio_get_value(USDHC1_CD_GPIO); > + break; > + case USDHC3_BASE_ADDR: > + ret = 1; /* Assume uSDHC3 emmc is always present */ > + break; > + } > + > + return ret; > +} > + > +int board_mmc_init(bd_t *bis) > +{ > + int i, ret; > + /* > +* According to the board_mmc_init() the following map is done: > +* (U-boot device node)(Physical Port) > +* mmc0USDHC1 > +* mmc2USDHC3 (eMMC) > +*/ > + for (i = 0; i < CONFIG_SYS_FSL_USDHC_NUM; i++) { > + switch (i) { > + case 0: > + imx_iomux_v3_setup_multiple_pads( > + usdhc1_pads, ARRAY_SIZE(usdhc1_pads)); > + gpio_request(USDHC1_CD_GPIO, "usdhc1_cd"); > + gpio_direction_input(USDHC1_CD_GPIO); > + gpio_request(USDHC1_PWR_GPIO, "usdhc1_pwr"); > + gpio_direction_output(USDHC1_PWR_GPIO, 0); > + udelay(500); > + gpio_direction_output(USDHC1_PWR_GPIO, 1); > + usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK); > + break; > + case 1: > +
Re: [U-Boot] [PATCH 03/11] imx: usb: ehci-mx7 add usb driver for i.MX7D
On Wed, Jul 15, 2015 at 7:49 PM, Adrian Alonso wrote: > * Add support for usb driver for i.MX7D SoC > > Signed-off-by: Adrian Alonso > Signed-off-by: Ye.Li > Signed-off-by: Peng Fan You missed to send this to the USB maintainer (Marek Vasut). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] patman: add distutils based installer
On 15 July 2015 at 04:06, Chris Packham wrote: > To make it easier to use patman on other projects add a distutils style > installer. Now patman can be installed with > > cd u-boot/tools/patman && python setup.py install > > There are also the usual distutils options for creating source/binary > distributions of patman. > > Signed-off-by: Chris Packham > --- > I've been playing with using patman for Linux development and it > occurred to me that patman should really be something that lives on my > default $PATH. That's what I do. > > It's simple enough to create a distutils configuration that makes this a > reality. > > One thing that would make sense for this is to make patman a python > package to avoid polluting site-packages with generic names like 'test' > and 'command'. With a little restructuring it would probably be possible > to setup something that works both as an installable package and in-tree > as it does today. But before I go down that path I wanted to see if > there was a desire for such packaging or do people just add > u-boot/tools/patman to their $PATH. I think it's a good idea, thanks for looking at it. > > Thanks, > Chris > > tools/patman/setup.py | 11 +++ > 1 file changed, 11 insertions(+) > create mode 100644 tools/patman/setup.py Acked-by: Simon Glass > > diff --git a/tools/patman/setup.py b/tools/patman/setup.py > new file mode 100644 > index 000..d14ac77 > --- /dev/null > +++ b/tools/patman/setup.py > @@ -0,0 +1,11 @@ > +# > +# SPDX-License-Identifier: GPL-2.0+ > +# > +from distutils.core import setup > +setup(name='patman', > + version='1.0', > + license='GPL-2.0+', > + scripts=['patman'], > + py_modules=['checkpatch', 'command', 'commit', 'cros_subprocess', > + 'get_maintainer', 'gitutil', 'patchstream', 'project', > + 'series', 'settings', 'terminal', 'test']) > -- > 2.5.0.rc0 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_fdt: save fdtaddr in hex format
On 16 July 2015 at 07:26, Linus Walleij wrote: > On Fri, Jul 10, 2015 at 6:18 PM, Sudeep Holla wrote: > >> Commit 90fbee3e4051 ("cmd_fdt: Actually fix fdt command in sandbox") >> changed the format(from hex address to unsigned long) in which "fdtaddr" >> is saved . However do_fdt continues reads the "fdtaddr" assuming it to >> be in hex format. This may lead to fdt being either loaded or attempted >> to load at erroneous address generating fault if the address is out of >> memory. >> >> This patch changes back the format to hex while saving the "fdtaddr" >> as it was done before. >> >> Signed-off-by: Sudeep Holla >> Cc: Linus Walleij >> Cc: Tom Rini >> Cc: Simon Glass >> Cc: Hua Yanghao >> Cc: Heiko Schocher > > Looks like the right fix: > Acked-by: Linus Walleij > > Yours, > Linus Walleij Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] lib/fdtdec: Fix compiling warning for debug
Hi, On 16 July 2015 at 01:01, Albert ARIBAUD wrote: > Hello York, > > On Wed, 15 Jul 2015 13:26:46 -0700, York Sun > wrote: >> fdt_addr_t and fdt_size_t can be either 64-bit or 32-bit, depending >> on the architecture. Change the type to phys_addr_t and phys_size_t. > > If the only reason for changing the type is to avoid warnings in > debug() then I don't think this is the right approach (see my message > re PRIu64). > > If, on the other hand, there is reason to believe the fdt_addr_t and > fdt_size_t are wrongly defined and should be typedef'd or ~define's as > phys_*_t, then the rationale for this should be exposed. > > Amicalement, > -- > Albert. For LBA we do this in ide.h: #ifdef CONFIG_SYS_64BIT_LBA typedef uint64_t lbaint_t; #define LBAF "%llx" #define LBAFU "%llu" #else typedef ulong lbaint_t; #define LBAF "%lx" #define LBAFU "%lu" #endif How about something similar for this case? It would be nice to avoid promoting everything to 64-bit given that very few platforms are actually 64-bit. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] lib/fdtdec: Fix compiling warning for debug
On 07/16/2015 09:40 AM, Simon Glass wrote: > Hi, > > On 16 July 2015 at 01:01, Albert ARIBAUD wrote: >> Hello York, >> >> On Wed, 15 Jul 2015 13:26:46 -0700, York Sun >> wrote: >>> fdt_addr_t and fdt_size_t can be either 64-bit or 32-bit, depending >>> on the architecture. Change the type to phys_addr_t and phys_size_t. >> >> If the only reason for changing the type is to avoid warnings in >> debug() then I don't think this is the right approach (see my message >> re PRIu64). >> >> If, on the other hand, there is reason to believe the fdt_addr_t and >> fdt_size_t are wrongly defined and should be typedef'd or ~define's as >> phys_*_t, then the rationale for this should be exposed. >> >> Amicalement, >> -- >> Albert. > > For LBA we do this in ide.h: > > #ifdef CONFIG_SYS_64BIT_LBA > typedef uint64_t lbaint_t; > #define LBAF "%llx" > #define LBAFU "%llu" > #else > typedef ulong lbaint_t; > #define LBAF "%lx" > #define LBAFU "%lu" > #endif > > How about something similar for this case? It would be nice to avoid > promoting everything to 64-bit given that very few platforms are > actually 64-bit. > Simon, Do you think fdt_addr_t should be phys_addr_t? According to the comments you put in file, "A typedef for a physical address". If yes, I can change the commit message. On the other hand, if we want to keep the current typedef, we can use Albert's PRIu64 technique, we then don't have to define the format string. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] lib/fdtdec: Fix compiling warning for debug
Hi York, On 16 July 2015 at 11:00, York Sun wrote: > > > On 07/16/2015 09:40 AM, Simon Glass wrote: >> Hi, >> >> On 16 July 2015 at 01:01, Albert ARIBAUD wrote: >>> Hello York, >>> >>> On Wed, 15 Jul 2015 13:26:46 -0700, York Sun >>> wrote: fdt_addr_t and fdt_size_t can be either 64-bit or 32-bit, depending on the architecture. Change the type to phys_addr_t and phys_size_t. >>> >>> If the only reason for changing the type is to avoid warnings in >>> debug() then I don't think this is the right approach (see my message >>> re PRIu64). >>> >>> If, on the other hand, there is reason to believe the fdt_addr_t and >>> fdt_size_t are wrongly defined and should be typedef'd or ~define's as >>> phys_*_t, then the rationale for this should be exposed. >>> >>> Amicalement, >>> -- >>> Albert. >> >> For LBA we do this in ide.h: >> >> #ifdef CONFIG_SYS_64BIT_LBA >> typedef uint64_t lbaint_t; >> #define LBAF "%llx" >> #define LBAFU "%llu" >> #else >> typedef ulong lbaint_t; >> #define LBAF "%lx" >> #define LBAFU "%lu" >> #endif >> >> How about something similar for this case? It would be nice to avoid >> promoting everything to 64-bit given that very few platforms are >> actually 64-bit. >> > > Simon, > > Do you think fdt_addr_t should be phys_addr_t? According to the comments you > put > in file, "A typedef for a physical address". If yes, I can change the commit > message. Sounds good to me. > > On the other hand, if we want to keep the current typedef, we can use Albert's > PRIu64 technique, we then don't have to define the format string. The only reason for a difference typedef is the big endian nature of FDT data. So I think your patch is fine on that front. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PCIe driver for a new Freescale ARM64 SOC
Hello Aurelian, On Wed, 15 Jul 2015 12:33:04 +, Aurelian Floricica Voicu wrote: > Hi! > > I'm with Freescale and we are currently working on bringing up a ARM64 > SOC platform. > The PCIe module is similar with the one used by the iMX family, being > a Synopsys IP. > However there are many differences in terms of the SOC integration > (clocking, pin muxing, control registers) plus an additional internal > DMA engine. > I would like to address a question about the U-Boot driver approach. > What would be an acceptable solution if we plan to make this driver > upstreamable : > 1. Use existing pcie-imx.c driver and parameterize according to the > SOC platform > 2. Create another driver file specific for the new family of SOCs > Thank you! My .02 EUR: Clocking and pinmuxing should be done in the board code, not in the driver -- that's system integration, as you point out. The driver code should simply assume that clocking and pinmuxing was done. If there is a need for system-level functions, they can be passed to the driver at init time, kept in function pointers an called back as ncessary. Control registers -- depends. Do you mean tour version of the Synopsis IP has registers and/or fields that the code does not know about? You could put them under some _VERSION preprocessor macro so that your board can define the macro and use the 'new' registers while 'older' boards, which do not define the macro, would be protected from using registers that don't exist for them. In the end, it all boils down to how much of the current driver's code would be common with the new driver. Lots of common code => single driver, a few #if/#else/#endif. Otherwise, two drivers. > Aurelian Floricica Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/4] configs: split ti_armv7_common into a omap generic header
TI armv7 based SoCs are based on two architectures - one based on OMAP generation architecture and others based on Keystone architecture. Many of the options are architecture specific, however a lot are common with v7 architecture. So, step 1 will be to move out OMAP specific stuff from ti_armv7_common into a ti_armv7_omap.h header which is then used by all the relevant architecture headers. Signed-off-by: Nishanth Menon --- V2: no change. V1: https://patchwork.ozlabs.org/patch/496726/ include/configs/am43xx_evm.h | 2 +- include/configs/ti_am335x_common.h | 2 +- include/configs/ti_armv7_common.h | 21 include/configs/ti_armv7_omap.h| 49 ++ include/configs/ti_omap3_common.h | 2 +- include/configs/ti_omap4_common.h | 2 +- include/configs/ti_omap5_common.h | 2 +- 7 files changed, 54 insertions(+), 26 deletions(-) create mode 100644 include/configs/ti_armv7_omap.h diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h index 33e534a76583..65ac8ef34eb8 100644 --- a/include/configs/am43xx_evm.h +++ b/include/configs/am43xx_evm.h @@ -80,7 +80,7 @@ #endif /* Now bring in the rest of the common code. */ -#include +#include /* Always 64 KiB env size */ #define CONFIG_ENV_SIZE(64 << 10) diff --git a/include/configs/ti_am335x_common.h b/include/configs/ti_am335x_common.h index 4d2ae280e7f1..9697431b4496 100644 --- a/include/configs/ti_am335x_common.h +++ b/include/configs/ti_am335x_common.h @@ -94,6 +94,6 @@ #endif /* Now bring in the rest of the common code. */ -#include +#include #endif /* __CONFIG_TI_AM335X_COMMON_H__ */ diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h index 0aea7d12ec16..63244dbc83ff 100644 --- a/include/configs/ti_armv7_common.h +++ b/include/configs/ti_armv7_common.h @@ -18,8 +18,6 @@ #define __CONFIG_TI_ARMV7_COMMON_H__ /* Common define for many platforms. */ -#define CONFIG_OMAP -#define CONFIG_OMAP_COMMON #define CONFIG_SYS_GENERIC_BOARD /* @@ -86,39 +84,20 @@ #define CONFIG_I2C #define CONFIG_CMD_I2C #define CONFIG_SYS_I2C -#define CONFIG_SYS_OMAP24_I2C_SPEED10 -#define CONFIG_SYS_OMAP24_I2C_SLAVE1 -#define CONFIG_SYS_I2C_OMAP24XX /* MMC/SD IP block */ #define CONFIG_MMC #define CONFIG_GENERIC_MMC -#define CONFIG_OMAP_HSMMC #define CONFIG_CMD_MMC /* McSPI IP block */ #define CONFIG_SPI -#define CONFIG_OMAP3_SPI #define CONFIG_CMD_SPI /* GPIO block */ -#define CONFIG_OMAP_GPIO #define CONFIG_CMD_GPIO /* - * GPMC NAND block. We support 1 device and the physical address to - * access CS0 at is 0x800. - */ -#ifdef CONFIG_NAND -#define CONFIG_NAND_OMAP_GPMC -#ifndef CONFIG_SYS_NAND_BASE -#define CONFIG_SYS_NAND_BASE 0x800 -#endif -#define CONFIG_SYS_MAX_NAND_DEVICE 1 -#define CONFIG_CMD_NAND -#endif - -/* * The following are general good-enough settings for U-Boot. We set a * large malloc pool as we generally have a lot of DDR, and we opt for * function over binary size in the main portion of U-Boot as this is diff --git a/include/configs/ti_armv7_omap.h b/include/configs/ti_armv7_omap.h new file mode 100644 index ..7548170afcf7 --- /dev/null +++ b/include/configs/ti_armv7_omap.h @@ -0,0 +1,49 @@ +/* + * ti_armv7_omap.h + * + * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/ + * + * SPDX-License-Identifier:GPL-2.0+ + * + * The various ARMv7 SoCs from TI all share a number of IP blocks when + * implementing a given feature. This is meant to isolate the features + * that are based on OMAP architecture. + */ +#ifndef __CONFIG_TI_ARMV7_OMAP_H__ +#define __CONFIG_TI_ARMV7_OMAP_H__ + +/* Common defines for all OMAP architecture based SoCs */ +#define CONFIG_OMAP +#define CONFIG_OMAP_COMMON + +/* I2C IP block */ +#define CONFIG_SYS_OMAP24_I2C_SPEED10 +#define CONFIG_SYS_OMAP24_I2C_SLAVE1 +#define CONFIG_SYS_I2C_OMAP24XX + +/* MMC/SD IP block */ +#define CONFIG_OMAP_HSMMC + +/* SPI IP Block */ +#define CONFIG_OMAP3_SPI + +/* GPIO block */ +#define CONFIG_OMAP_GPIO + +/* + * GPMC NAND block. We support 1 device and the physical address to + * access CS0 at is 0x800. + */ +#ifdef CONFIG_NAND +#define CONFIG_NAND_OMAP_GPMC +#ifndef CONFIG_SYS_NAND_BASE +#define CONFIG_SYS_NAND_BASE 0x800 +#endif +#define CONFIG_SYS_MAX_NAND_DEVICE 1 +#define CONFIG_CMD_NAND +#endif + +/* Now for the remaining common defines */ +#include + +#endif /* __CONFIG_TI_ARMV7_OMAP_H__ */ diff --git a/include/configs/ti_omap3_common.h b/include/configs/ti_omap3_common.h index 429b109afa23..be231a551361 100644 --- a/include/configs/ti_omap3_common.h +++ b/include/configs/ti_omap3_common.h @@ -84,6 +84,6 @@ #endif /* Now bring in the rest of the common code. */ -#include +#include #endif /* __CONFIG_TI_OMAP3_COMMON_H__ */ diff --git a/include/configs/ti_omap4_common.h b/include/configs/ti_omap4_common.h
[U-Boot] [PATCH V2 0/4] configs: make keystone2 config to start using arm_v7_common header
For legacy reasons, keystone2 had kind of stayed completely seperated from the rest of the TI SoC families. This makes no sense since there are a lot of common definitions that can be reused between all SoC configuration allowing for a consistent user experience. So make keystone2 follow the rest of the TI SoCs based on OMAP architecture as well. Test log: K2H: http://pastebin.ubuntu.com/11889270/ (using https://patchwork.ozlabs.org/patch/440665/) I have no other platform to verify on. Series based on master 4905dfc65d9a Merge branch 'master' of git://git.denx.de/u-boot-spi Changes in V2: - got rid of the bogus CONFIG_LINUX_BOOT_PARAM_ADDR - few additional config cleanups based on off line comment from Tom Rini. V1: http://marc.info/?l=u-boot&m=143706008602124&w=2 Nishanth Menon (4): configs: split ti_armv7_common into a omap generic header board: ks2_evm: get rid of bogus CONFIG_LINUX_BOOT_PARAM_ADDR configs: rename ks2_evm into ti_armv7_keystone2 configs: ti_armv7_keystone2: start using armv7_common board/ti/ks2_evm/board.c | 2 +- include/configs/am43xx_evm.h | 2 +- include/configs/k2e_evm.h | 4 +- include/configs/k2hk_evm.h | 4 +- include/configs/k2l_evm.h | 4 +- include/configs/ti_am335x_common.h | 2 +- include/configs/ti_armv7_common.h | 27 ++- .../configs/{ks2_evm.h => ti_armv7_keystone2.h}| 53 ++ include/configs/ti_armv7_omap.h| 49 include/configs/ti_omap3_common.h | 2 +- include/configs/ti_omap4_common.h | 2 +- include/configs/ti_omap5_common.h | 2 +- 12 files changed, 78 insertions(+), 75 deletions(-) rename include/configs/{ks2_evm.h => ti_armv7_keystone2.h} (89%) create mode 100644 include/configs/ti_armv7_omap.h -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/4] board: ks2_evm: get rid of bogus CONFIG_LINUX_BOOT_PARAM_ADDR
CONFIG_LINUX_BOOT_PARAM_ADDR is not a valid configuration option. Do just like what the rest of the world does. Suggested-by: Tom Rini Signed-off-by: Nishanth Menon --- New patch. board/ti/ks2_evm/board.c | 2 +- include/configs/ks2_evm.h | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/board/ti/ks2_evm/board.c b/board/ti/ks2_evm/board.c index 8892a2843df4..0cefb3404403 100644 --- a/board/ti/ks2_evm/board.c +++ b/board/ti/ks2_evm/board.c @@ -48,7 +48,7 @@ int dram_init(void) int board_init(void) { - gd->bd->bi_boot_params = CONFIG_LINUX_BOOT_PARAM_ADDR; + gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100; return 0; } diff --git a/include/configs/ks2_evm.h b/include/configs/ks2_evm.h index e05d56cd8262..d838f270018b 100644 --- a/include/configs/ks2_evm.h +++ b/include/configs/ks2_evm.h @@ -307,7 +307,6 @@ #define CONFIG_OF_BOARD_SETUP #define CONFIG_SYS_BARGSIZE1024 #define CONFIG_SYS_LOAD_ADDR (CONFIG_SYS_SDRAM_BASE + 0x0800) -#define CONFIG_LINUX_BOOT_PARAM_ADDR (CONFIG_SYS_SDRAM_BASE + 0x100) #define CONFIG_SUPPORT_RAW_INITRD -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 3/4] configs: rename ks2_evm into ti_armv7_keystone2
rename the keystone2 common header into an keystone2 architecture specific header which can then reuse the common ti_armv7 config headers. Signed-off-by: Nishanth Menon --- no change V1: https://patchwork.ozlabs.org/patch/496728/ include/configs/k2e_evm.h | 2 +- include/configs/k2hk_evm.h | 2 +- include/configs/k2l_evm.h | 2 +- include/configs/{ks2_evm.h => ti_armv7_keystone2.h} | 0 4 files changed, 3 insertions(+), 3 deletions(-) rename include/configs/{ks2_evm.h => ti_armv7_keystone2.h} (100%) diff --git a/include/configs/k2e_evm.h b/include/configs/k2e_evm.h index a28ceb7064a7..ac50a01b2980 100644 --- a/include/configs/k2e_evm.h +++ b/include/configs/k2e_evm.h @@ -27,7 +27,7 @@ "name_uboot=u-boot-spi-k2e-evm.gph\0" \ "name_fs=arago-console-image-k2e-evm.cpio.gz\0" -#include +#include /* SPL SPI Loader Configuration */ #define CONFIG_SPL_TEXT_BASE 0x0c10 diff --git a/include/configs/k2hk_evm.h b/include/configs/k2hk_evm.h index eae772178338..29e3403aa082 100644 --- a/include/configs/k2hk_evm.h +++ b/include/configs/k2hk_evm.h @@ -27,7 +27,7 @@ "name_uboot=u-boot-spi-k2hk-evm.gph\0" \ "name_fs=arago-console-image-k2hk-evm.cpio.gz\0" -#include +#include /* SPL SPI Loader Configuration */ #define CONFIG_SPL_TEXT_BASE 0x0c20 diff --git a/include/configs/k2l_evm.h b/include/configs/k2l_evm.h index 57da0579255a..50d5c991a0bb 100644 --- a/include/configs/k2l_evm.h +++ b/include/configs/k2l_evm.h @@ -27,7 +27,7 @@ "name_uboot=u-boot-spi-k2l-evm.gph\0" \ "name_fs=arago-console-image-k2l-evm.cpio.gz\0" -#include +#include /* SPL SPI Loader Configuration */ #define CONFIG_SPL_TEXT_BASE 0x0c10 diff --git a/include/configs/ks2_evm.h b/include/configs/ti_armv7_keystone2.h similarity index 100% rename from include/configs/ks2_evm.h rename to include/configs/ti_armv7_keystone2.h -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 4/4] configs: ti_armv7_keystone2: start using armv7_common
Try to maintain as much commonality by conditionally including stuff in armv7_common as necessary and removing the common defines from keystone2 header. Signed-off-by: Nishanth Menon --- Changes in V2: - common CONFIG_SYS_SDRAM_BASE - common CONFIG_SYS_LOAD_ADDR - rebased to new series V1: https://patchwork.ozlabs.org/patch/496730/ include/configs/k2e_evm.h| 2 -- include/configs/k2hk_evm.h | 2 -- include/configs/k2l_evm.h| 2 -- include/configs/ti_armv7_common.h| 6 - include/configs/ti_armv7_keystone2.h | 52 +++- 5 files changed, 20 insertions(+), 44 deletions(-) diff --git a/include/configs/k2e_evm.h b/include/configs/k2e_evm.h index ac50a01b2980..f1e650141ae1 100644 --- a/include/configs/k2e_evm.h +++ b/include/configs/k2e_evm.h @@ -15,8 +15,6 @@ #define CONFIG_K2E_EVM /* U-Boot general configuration */ -#define CONFIG_SYS_PROMPT "K2E EVM # " - #define CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS\ "addr_mon=0x0c14\0" \ "args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs "\ diff --git a/include/configs/k2hk_evm.h b/include/configs/k2hk_evm.h index 29e3403aa082..f8e83de64b63 100644 --- a/include/configs/k2hk_evm.h +++ b/include/configs/k2hk_evm.h @@ -15,8 +15,6 @@ #define CONFIG_K2HK_EVM /* U-Boot general configuration */ -#define CONFIG_SYS_PROMPT "K2HK EVM # " - #define CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS\ "addr_mon=0x0c5f\0" \ "args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs "\ diff --git a/include/configs/k2l_evm.h b/include/configs/k2l_evm.h index 50d5c991a0bb..395608a5f6db 100644 --- a/include/configs/k2l_evm.h +++ b/include/configs/k2l_evm.h @@ -15,8 +15,6 @@ #define CONFIG_K2L_EVM /* U-Boot general configuration */ -#define CONFIG_SYS_PROMPT "K2L EVM # " - #define CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS\ "addr_mon=0x0c14\0" \ "args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs "\ diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h index 63244dbc83ff..814da3409c46 100644 --- a/include/configs/ti_armv7_common.h +++ b/include/configs/ti_armv7_common.h @@ -73,9 +73,13 @@ #ifndef CONFIG_NR_DRAM_BANKS #define CONFIG_NR_DRAM_BANKS 1 #endif + #define CONFIG_SYS_SDRAM_BASE 0x8000 + +#ifndef CONFIG_SYS_INIT_SP_ADDR #define CONFIG_SYS_INIT_SP_ADDR (NON_SECURE_SRAM_END - \ GENERATED_GBL_DATA_SIZE) +#endif /* Timer information. */ #define CONFIG_SYS_PTV 2 /* Divisor: 2^(PTV+1) => 8 */ @@ -140,7 +144,7 @@ * mtdparts, both for ease of use in U-Boot and for passing information * on to the Linux kernel. */ -#if defined(CONFIG_SPI_BOOT) || defined(CONFIG_NOR) || defined(CONFIG_NAND) +#if defined(CONFIG_SPI_BOOT) || defined(CONFIG_NOR) || defined(CONFIG_NAND) || defined(CONFIG_NAND_DAVINCI) #define CONFIG_MTD_DEVICE /* Required for mtdparts */ #define CONFIG_CMD_MTDPARTS #endif diff --git a/include/configs/ti_armv7_keystone2.h b/include/configs/ti_armv7_keystone2.h index d838f270018b..7d89bd78e43b 100644 --- a/include/configs/ti_armv7_keystone2.h +++ b/include/configs/ti_armv7_keystone2.h @@ -14,10 +14,7 @@ /* U-Boot Build Configuration */ #define CONFIG_SKIP_LOWLEVEL_INIT /* U-Boot is a 2nd stage loader */ -#define CONFIG_SYS_NO_FLASH/* that is, no *NOR* flash */ -#define CONFIG_SYS_CONSOLE_INFO_QUIET #define CONFIG_BOARD_EARLY_INIT_F -#define CONFIG_SYS_THUMB_BUILD /* SoC Configuration */ #define CONFIG_ARCH_CPU_INIT @@ -28,11 +25,9 @@ /* Memory Configuration */ #define CONFIG_NR_DRAM_BANKS 2 -#define CONFIG_SYS_SDRAM_BASE 0x8000 #define CONFIG_SYS_LPAE_SDRAM_BASE 0x8 #define CONFIG_MAX_RAM_BANK_SIZE (2 << 30) /* 2GB */ #define CONFIG_STACKSIZE (512 << 10) /* 512 KiB */ -#define CONFIG_SYS_MALLOC_LEN (4 << 20) /* 4 MiB */ #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_TEXT_BASE - \ GENERATED_GBL_DATA_SIZE) @@ -49,15 +44,10 @@ #define CONFIG_SPL_STACK (CONFIG_SYS_SPL_MALLOC_START + \ CONFIG_SYS_SPL_MALLOC_SIZE + \ CONFIG_SPL_STACK_SIZE - 4) -#define CONFIG_SPL_LIBCOMMON_SUPPORT -#define CONFIG_SPL_LIBGENERIC_SUPPORT -#define CONFIG_SPL_SERIAL_SUPPORT #define CONFIG_SPL_SPI_FLASH_SUPPORT #define CONFIG_SPL_SPI_SUPPORT -#define CONFIG_SPL_BOARD_INIT #define CONFIG_SPL_SPI_LOAD #define CONFIG_SYS_SPI_U_BOOT_OFFS CONFIG_SPL_PAD_TO -#define CONFI
Re: [U-Boot] [PATCH 1/4] spl: nand: simple: replace readb() with chip specific read_buf()
On Thu, 2015-07-16 at 16:12 +0200, Albert ARIBAUD wrote: > Hello Vladimir, > > On Thu, 16 Jul 2015 16:48:26 +0300, Vladimir Zapolskiy > wrote: > > (cutting short to the essential point remaining) > > > > I personally don't think this is the right way; nand_simple.c should be > > > left unchanged and the board should simply not use it since it does not > > > have a simple NAND controller, and instead it should provide its own > > > nand_spl_load_image(). I don't have a problem with expanding the definition of "simple" to include custom read_byte and such, as long as we make sure that existing targets don't break. For drivers that don't supply these functions, where are the default functions coming from? I don't see nand_spl_simple's nand_init() initializing them. > > For me an alternative change to the proposed one is to duplicate > > nand_spl_simple.c functionality in LPC32xx SLC NAND driver. From > > maintenance point of view this is not the best thing to do IMHO. > > You're right that some of the functionality present in nand_simple.c is > duplicated elsewhere; however, that functionality is not the one specific > to nand_simple; actually, it is nand_spl_load_image(), the overall load > functionality which should be in no driver at all but of which I see ten > incarnations in ten drivers. > > There should be only one nand_spl_load_image(), in its own file, with > placeholders for driver-specific actions such as page read, bad page > check, etc. One day, maybe, there will be a patch for that. You'll never get it down to just one, since there are some targets that rely on the tight integration within a single file to squeak in under a 4 KiB size limit. Maybe some of the implementations could be replaced with an optional generic version, though. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nand: lpc32xx: add SLC NAND controller support
Hi Vladimir, Thanks for taking time to read my feedback. You can see my comments and my answer below. Sylvain > -Original Message- > From: Vladimir Zapolskiy [mailto:v...@mleia.com] > Sent: 15-Jul-15 8:20 PM > To: LEMIEUX, SYLVAIN; Albert ARIBAUD > Cc: Scott Wood; u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH] nand: lpc32xx: add SLC NAND controller support > > Hi Sylvain, > > On 15.07.2015 22:23, LEMIEUX, SYLVAIN wrote: > > Hi Vladimir and Albert, > > > > During this merge window (once our issues with our exchange server are > resolve), we were planning on submitting a few patches for the LPC32xx. > > great, feel free to add me to Cc. Will do; > > > Some of the patches are the porting of the legacy NXP BSP (u-boot) drivers > into the latest version; the drivers are the DMA, the SLC NAND and the USB. > > If DMA and USB are added, I'll gratefully reuse this on my board :) I will submit the LPC32xx patches using an alternate e-mail for now, until the problem with our e-mail infrastructure is resolve. First, I need to do some rework (matching the naming convention of your NAND SLC patch and update our porting effort based on the feedback from Albert). > > > This original NXP implementation of the SLC NAND was using the DMA. I am > also planning on testing this patch to compare the flashing time, with and > without the DMA. > > Sounds good. Also since DMA is going to be supported it would be nice to > add HW ECC calculation to the SLC NAND driver. Hardware ECC was already supported in the legacy BSP; it will be part of the patches I will submit. > > FYI here are performance test results of my PIO version: > > => gettime; nand read.raw 0x8000 0x0 0x6000; gettime > Timer val: 63952 > Seconds : 63 > Remainder : 952 > sys_hz = 1000 > > NAND read: 51904512 bytes read: OK > Timer val: 113352 > Seconds : 113 > Remainder : 352 > sys_hz = 1000 > > > 1.002 MiB per second, quite slow, but not drastically slow. FYI, I did the same testing on my side using the legacy NXP BSP implementation; the test was done with the CPU clock at 208MHz and 266MHz. For those test, we have no timing optimization for the SLC NAND. Clock configuration: CPU clock: 266MHz / AHB bus clock: 133MHz / Peripheral clock: 13MHz ==> gettime; nand read.raw 0x8000 0xd0 0x6000; gettime Timer val: 22949 Seconds : 22 Remainder : 949 sys_hz = 1000 NAND read: 51904512 bytes read: OK Timer val: 44803 Seconds : 44 Remainder : 803 sys_hz = 1000 --> 2.265 MiB per second ==> gettime; nand read.e 0x8000 0xd0 0x318; gettime Timer val: 66054 Seconds : 66 Remainder : 54 sys_hz = 1000 NAND read: device 0 offset 0xd0, size 0x318 51904512 bytes read: OK Timer val: 89214 Seconds : 89 Remainder : 214 sys_hz = 1000 --> 2.137 MiB per second Clock configuration: CPU clock: 208MHz / AHB bus clock: 104MHz / Peripheral clock: 13MHz ==> gettime; nand read.raw 0x8000 0xd0 0x6000; gettime Timer val: 24605 Seconds : 24 Remainder : 605 sys_hz = 1000 NAND read: 51904512 bytes read: OK Timer val: 52458 Seconds : 52 Remainder : 458 sys_hz = 1000 --> 1.777 MiB per second ==> gettime; nand read.e 0x8000 0x00d0 0x318; gettime Timer val: 134819 Seconds : 134 Remainder : 819 sys_hz = 1000 NAND read: device 0 offset 0xd0, size 0x318 51904512 bytes read: OK Timer val: 164465 Seconds : 164 Remainder : 465 sys_hz = 1000 --> 1.669 MiB per second > > > I have two questions: > > 1) How do you suggest to approach this, as some patches may be similar or > conflicting with what Vladimir is planning on submitting? > > I presume the only conflicting place is SLC NAND driver. Yes, this will be the only conflicting patch. > > Here I see some benefits of my version: > > * the driver is very tiny, practically it is read_buf()/write_buf() and timing > configuration, all the rest I managed to offload to existing mtd/nand and > spl/nand frameworks at the price of more added CONFIG_* defines in a > board header file, > * not sure what OOB layout is coming from NXP BSP (I don't have this BSP to > check, unfortunately), but I would prefer to see the same OOB layout in U- > boot and in vanilla Linux --- this is done in my version, > * the driver can be included to SPL binary, > * the driver is well tested on my environment, > * the code has been published for review. This is the benefits (I am thinking we get) from the legacy NXP BSP porting: * The driver went through multiple iteration (the latest version of the legacy patch was 1.07). * The BSP, from LPC Linux, was most likely review and tested by multiple users; it was the initial u-boot reference for the LPC32xx development boards. * The SLC NAND implementation is integrated with the DMA, and already support hardware ECC. * The OOB layout from the legacy BSP is matching the LPC32xx NAND SLC Linux driver. > > The only two missing things from the driver I see at the moment are based > on working DMA driver: > * data transfer by mean
Re: [U-Boot] [PATCH 1/8] doc: dfu: tftp: README entry for TFTP extension of DFU
Hi Joe, Thank you for your review. > Hi Lukasz, > > On Sun, Jul 12, 2015 at 10:30 AM, Lukasz Majewski > wrote: > > Documentation file for DFU extension. With this functionality it is > > now possible to transfer FIT images with firmware updates via TFTP > > and use DFU backend for storing them. > > > > Signed-off-by: Lukasz Majewski > > --- > > doc/README.dfutftp | 153 > > + 1 file > > changed, 153 insertions(+) create mode 100644 doc/README.dfutftp > > > > diff --git a/doc/README.dfutftp b/doc/README.dfutftp > > new file mode 100644 > > index 000..4636321 > > --- /dev/null > > +++ b/doc/README.dfutftp > > @@ -0,0 +1,153 @@ > > +Device Firmware Upgrade (DFU) - extension to use TFTP > > += > > + > > +Why? > > + > > + > > +* Update TFTP (CONFIG_UPDATE_TFTP) only supports writing > > +code to NAND memory via TFTP. > > +* DFU supports writing data to variety of mediums (NAND, > > +eMMC, SD, partitions, RAM, etc) via USB. > > + > > +Combination of both solves their shortcomings! > > + > > + > > +Overview > > + > > + > > +This document briefly describes how to use BF for > > BF? It should be DFU. > > > +upgrading firmware (e.g. kernel, u-boot, rootfs, etc.) > > +via TFTP protocol. > > + > > +By using Ethernet (TFTP protocol to be precise) it was > > +possible to overcome the major problem of USB based DFU - > > +the relatively low transfer speed for large files. > > +This was caused by DFU standard, which imposed utilization > > +of only EP0 for transfer. By using Ethernet we can circumvent > > +this shortcoming. > > + > > +Beagle Bone Black (BBB) powered by TI's am335x CPU has been used > > +as a demo board. > > + > > +To utilize this feature, one needs to first enable support > > +for USB based DFU (CONFIG_DFU_*) and TFTP update > > +(CONFIG_UPDATE_TFTP) described in ./doc/README.update. > > Does it really make sense to reuse this UPDATE_TFTP config? Why not > DFU_TFTP? Enabling CONFIG_UPDATE_TFTP allows reusing parts of the legacy update_tftp() code. What I mean is that one should enable legacy CONFIG_UPDATE_TFTP as a prerequisite for using dfu tftp transfer. > > > +New "dfutftp" command has been introduced to comply with present > > +USB related commands' syntax. > > + > > +This code works without "fitupd" command enabled. > > + > > +As of this writing (SHA1:241746e618fa725491e9ff689710c5f73ffd9139) > > the +update.c code is not enabled (CONFIG_UPDATE_TFTP) by any board > > in the +contemporary u-boot tree. > > So maybe we should remove it. This is IMHO a tricky issue. On the one hand there hasn't left any board supporting this feature in mainline (recently some old PPC boards have been removed from u-boot). One the other hand _probably_ there are deployed systems (as a derivative of the boards supported in u-boot and using this feature) which depend on this feature. I'd opt for leaving the original code in the tree with a fat big note about the plan to remove the legacy code in a near future (as we do it with MAKEALL script). > > > + > > +Environment variables > > +- > > + > > +To preserve legacy behavior of TFTP update (./common/update.c) > > +code following new environment variables had been introduced: > > Another example of why you should use a new config instead of the > existing one. Could you be more specific here? > > > +* "update_tftp_exec_at_boot" ["true"|"false"] > > + > > + New usage of update_tftp allows setting the > > + "update_tftp_exec_at_boot" env variable to allow it running > > + at boot time. > > + In this way update_tftp will not be executed at startup and > > reduce > > + boot time. > > + > > + To preserve backward compatibility for legacy boards this > > variable > > + should be set to "true". > > + > > + BBB note: > > + When update tftp is not working after boot one need to > > + increase values of following two configs: > > + CONFIG_UPDATE_TFTP_MSEC_MAX and > > CONFIG_UPDATE_TFTP_CNT_MAX. > > + Values of namely 1000 and 5 solve the issue for BBB. > > + > > +* "update_tftp_dfu" ["true"|"false"] > > + > > + By "update_tftp_dfu" env variable we inform update_tftp that > > + it should use dfu for writing data - in this way support for > > + legacy usage is preserved. > > Same here... presumably a user only wants support for one or the other > compiled in. Please use a different config. The most appealing thing about update.c is that I had to add only a few lines of code to use it for my purpose. For that reason I've decided to keep as much as possible of the legacy code. > > > +* "update_tftp_dfu_interface" ["mmc"] > > +* "update_tftp_dfu_devstring" ["1"] > > + > > + Both variables - namely "update_tftp_dfu_{interface|devstring}" > > are > > + only taken into account when "update_tftp_dfu" is defined. > > + They store information about interface (e.g. "mmc") and de
Re: [U-Boot] [PATCH 6/8] update: tftp: dfu: Extend update_tftp() function to support DFU
Hi Joe, > Hi Lukasz, > > On Sun, Jul 12, 2015 at 10:30 AM, Lukasz Majewski > wrote: > > This code allows using DFU defined mediums for storing data > > received via TFTP protocol. > > > > It reuses legacy code at common/update.c. > > > > To run update_tftp() during boot one needs to define > > "update_tftp_exec_at_boot=true". > > > > Signed-off-by: Lukasz Majewski > > --- > > common/update.c | 37 - > > 1 file changed, 28 insertions(+), 9 deletions(-) > > > > diff --git a/common/update.c b/common/update.c > > index 75c6d62..f3ed036 100644 > > --- a/common/update.c > > +++ b/common/update.c > > @@ -18,6 +18,7 @@ > > #include > > #include > > #include > > +#include > > > > /* env variable holding the location of the update file */ > > #define UPDATE_FILE_ENV"updatefile" > > @@ -224,11 +225,18 @@ static int update_fit_getparams(const void > > *fit, int noffset, ulong *addr, > > > > int update_tftp(ulong addr) > > { > > - char *filename, *env_addr; > > - int images_noffset, ndepth, noffset; > > + char *filename, *env_addr, *fit_image_name; > > ulong update_addr, update_fladdr, update_size; > > - void *fit; > > + int images_noffset, ndepth, noffset; > > + bool update_tftp_dfu = false; > > int ret = 0; > > + void *fit; > > + > > + if (!getenv("update_tftp_exec_at_boot")) > > + return 0; > > + > > + if (getenv("update_tftp_dfu")) > > + update_tftp_dfu = true; > > As I mentioned in the documentation patch, it would be nice to split > these out and drop the env vars. This would be difficult since update_tftp() is used at dfutftp() and legacy fitupd command. Moreover it is called in the early stage of booting to perform auto firmware upgrade. Those env variables give some control over its behavior. > > > > > /* use already present image */ > > if (addr) > > @@ -277,8 +285,8 @@ got_update_file: > > if (ndepth != 1) > > goto next_node; > > > > - printf("Processing update '%s' :", > > - fit_get_name(fit, noffset, NULL)); > > + fit_image_name = (char *)fit_get_name(fit, noffset, > > NULL); > > + printf("Processing update '%s' :", fit_image_name); > > > > if (!fit_image_verify(fit, noffset)) { > > printf("Error: invalid update hash, > > aborting\n"); @@ -294,10 +302,21 @@ got_update_file: > > ret = 1; > > goto next_node; > > } > > - if (update_flash(update_addr, update_fladdr, > > update_size)) { > > - printf("Error: can't flash update, > > aborting\n"); > > - ret = 1; > > - goto next_node; > > + > > + if (!update_tftp_dfu) { > > + if (update_flash(update_addr, update_fladdr, > > +update_size)) { > > + printf("Error: can't flash update, > > aborting\n"); > > + ret = 1; > > + goto next_node; > > + } > > + } else if (fit_image_check_type(fit, noffset, > > + IH_TYPE_FIRMWARE)) { > > + if (dfu_tftp_write(fit_image_name, > > + update_addr, > > update_size)) { > > + ret = 1; > > + goto next_node; > > + } > > } > > next_node: > > noffset = fdt_next_node(fit, noffset, &ndepth); > > -- > > 2.1.4 > > > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot Best regards, Lukasz Majewski pgpZ36YHZePSU.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] nand: lpc32xx: add SLC NAND controller support
On Thu, 2015-07-16 at 14:53 +0200, Albert ARIBAUD wrote: > Hello Vladimir, > > On Thu, 16 Jul 2015 02:33:46 +0300, Vladimir Zapolskiy > wrote: > > > diff --git a/drivers/mtd/nand/lpc32xx_nand_slc.c > > b/drivers/mtd/nand/lpc32xx_nand_slc.c > > new file mode 100644 > > > +int board_nand_init(struct nand_chip *lpc32xx_chip) > > +{ > > + lpc32xx_chip->IO_ADDR_R = &lpc32xx_nand_slc_registers->data; > > + lpc32xx_chip->IO_ADDR_W = &lpc32xx_nand_slc_registers->data; > > Consistent with my comment re nand_simpl.c, I think that the two > assignments above are incorrect since the data register may not provide > general access to the NAND's I/O lines, and is not 8-bit accessible > even though the NAND is 8-bit wide. > > If Scott give his go, though, disregard my comment. I agree with Albert -- if you need custom accessors, there's no benefit to using IO_ADDR_R/W, and it could make it harder to debug if some user of IO_ADDR_R/W is missed. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] dfu: tftp: update: Provide tftp support for the DFU subsystem
Hi Joe, > Hi Lukasz, > > On Sun, Jul 12, 2015 at 10:30 AM, Lukasz Majewski > wrote: > > This commit adds initial support for using tftp for downloading and > > upgrading firmware on the device. > > > > Signed-off-by: Lukasz Majewski > > --- > > drivers/dfu/Makefile | 1 + > > drivers/dfu/dfu_tftp.c | 76 > > ++ > > include/dfu.h | 11 3 files changed, 88 > > insertions(+) create mode 100644 drivers/dfu/dfu_tftp.c > > > > diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile > > index 5cc535e..43249ce 100644 > > --- a/drivers/dfu/Makefile > > +++ b/drivers/dfu/Makefile > > @@ -10,3 +10,4 @@ obj-$(CONFIG_DFU_MMC) += dfu_mmc.o > > obj-$(CONFIG_DFU_NAND) += dfu_nand.o > > obj-$(CONFIG_DFU_RAM) += dfu_ram.o > > obj-$(CONFIG_DFU_SF) += dfu_sf.o > > +obj-$(CONFIG_DFU_TFTP) += dfu_tftp.o > > diff --git a/drivers/dfu/dfu_tftp.c b/drivers/dfu/dfu_tftp.c > > new file mode 100644 > > index 000..26539f2 > > --- /dev/null > > +++ b/drivers/dfu/dfu_tftp.c > > @@ -0,0 +1,76 @@ > > +/* > > + * (C) Copyright 2015 > > + * Lukasz Majewski > > + * > > + * SPDX-License-Identifier:GPL-2.0+ > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > + > > +int dfu_tftp_write(char *dfu_entity_name, unsigned int addr, > > unsigned int len) +{ > > + char *s, *sb, *interface, *devstring; > > + int alt_setting_num, ret; > > + struct dfu_entity *dfu; > > + > > + debug("%s: name: %s addr: 0x%x len: %d\n", __func__, > > dfu_entity_name, > > + addr, len); > > + > > + interface = getenv("update_tftp_dfu_interface"); > > + if (interface == NULL) { > > + error("TFTP DFU: 'interface' not defined\n"); > > + return -EINVAL; > > + } > > + > > + devstring = getenv("update_tftp_dfu_devstring"); > > + if (devstring == NULL) { > > + error("TFTP DFU: 'devstring' not defined\n"); > > + return -EINVAL; > > + } > > It would be great if these env vars could be moved to command > parameters. Those parameters are necessary to perform update (via update_tftp()) during boot time. Normally - when user call 'dfutftp' command he/she needs to specify this informaiton. (e.g. 'dfutftp 0 mmc 1'). > > > + > > + ret = dfu_init_env_entities(interface, devstring); > > + if (ret) > > + goto done; > > + > > + /* > > +* We need to copy name pointed by *dfu_entity_name since > > this text > > +* is the integral part of the FDT image. > > +* Any implicit modification (i.e. done by strsep()) will > > corrupt > > +* the FDT image and prevent other images to be stored. > > +*/ > > + s = strdup(dfu_entity_name); > > + sb = s; > > + if (!s) { > > + ret = -ENOMEM; > > + goto done; > > + } > > + > > + strsep(&s, "@"); > > + debug("%s: image name: %s strlen: %d\n", __func__, sb, > > strlen(sb)); + > > + alt_setting_num = dfu_get_alt(sb); > > + free(sb); > > + if (alt_setting_num < 0) { > > + error("Alt setting [%d] to write not found!", > > + alt_setting_num); > > + ret = -ENODEV; > > + goto done; > > + } > > + > > + dfu = dfu_get_entity(alt_setting_num); > > + if (!dfu) { > > + error("DFU entity for alt: %d not found!", > > alt_setting_num); > > + ret = -ENODEV; > > + goto done; > > + } > > + > > + ret = dfu_write_from_mem_addr(dfu, (void *)addr, len); > > + > > +done: > > + dfu_free_entities(); > > + > > + return ret; > > +} > > diff --git a/include/dfu.h b/include/dfu.h > > index 7d31abd..adad863 100644 > > --- a/include/dfu.h > > +++ b/include/dfu.h > > @@ -207,5 +207,16 @@ static inline int dfu_fill_entity_sf(struct > > dfu_entity *dfu, char *devstr, } > > #endif > > > > +#ifdef CONFIG_DFU_TFTP > > +int dfu_tftp_write(char *dfu_entity_name, unsigned int addr, > > unsigned int len); +#else > > +static inline int dfu_tftp_write(char *dfu_entity_name, unsigned > > int addr, > > +unsigned int len) > > +{ > > + puts("TFTP write support for DFU not available!\n"); > > + return -1; > > This should be -ENOSYS probably. Good point - thanks! > > > +} > > +#endif > > + > > int dfu_add(struct usb_configuration *c); > > #endif /* __DFU_ENTITY_H_ */ > > -- > > 2.1.4 > > > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot Best regards, Lukasz Majewski pgpCnlN10McDk.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] nand: lpc32xx: add SLC NAND controller support
Hello Scott, On 16.07.2015 23:14, Scott Wood wrote: > On Thu, 2015-07-16 at 14:53 +0200, Albert ARIBAUD wrote: >> Hello Vladimir, >> >> On Thu, 16 Jul 2015 02:33:46 +0300, Vladimir Zapolskiy >> wrote: >> >>> diff --git a/drivers/mtd/nand/lpc32xx_nand_slc.c >>> b/drivers/mtd/nand/lpc32xx_nand_slc.c >>> new file mode 100644 >> >>> +int board_nand_init(struct nand_chip *lpc32xx_chip) >>> +{ >>> + lpc32xx_chip->IO_ADDR_R = &lpc32xx_nand_slc_registers->data; >>> + lpc32xx_chip->IO_ADDR_W = &lpc32xx_nand_slc_registers->data; >> >> Consistent with my comment re nand_simpl.c, I think that the two >> assignments above are incorrect since the data register may not provide >> general access to the NAND's I/O lines, and is not 8-bit accessible >> even though the NAND is 8-bit wide. >> >> If Scott give his go, though, disregard my comment. > > I agree with Albert -- if you need custom accessors, there's no benefit to > using IO_ADDR_R/W, and it could make it harder to debug if some user of > IO_ADDR_R/W is missed. No objections from my side regarding this notice, I'll remove these two lines in v2. Please let me know, if you notice something else, what can be improved. -- With best wishes, Vladimir ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] net: tftp: Move tftp.h file from ./net to ./include
Hi Joe, > Hi Lukasz, > > On Sun, Jul 12, 2015 at 10:30 AM, Lukasz Majewski > wrote: > > This change gives the ability to reuse the header file by > > other subsystems (like e.g. dfu). > > > > Without this change compilation error emerges for the legacy > > update.c file. > > > > Signed-off-by: Lukasz Majewski > > --- > > common/update.c | 2 +- > > include/tftp.h | 30 ++ > > I'd like to start moving net headers to include/net/*... lets start > here. Ok, no problem. > > > net/bootp.c | 2 +- > > net/net.c | 2 +- > > net/rarp.c | 2 +- > > net/tftp.c | 2 +- > > net/tftp.h | 30 -- > > 7 files changed, 35 insertions(+), 35 deletions(-) > > create mode 100644 include/tftp.h > > delete mode 100644 net/tftp.h > > > > diff --git a/common/update.c b/common/update.c > > index 1c6aa18..7bd7e94 100644 > > --- a/common/update.c > > +++ b/common/update.c > > @@ -20,7 +20,7 @@ > > #include > > #include > > #include > > -#include > > +#include > > #include > > > > /* env variable holding the location of the update file */ > > diff --git a/include/tftp.h b/include/tftp.h > > new file mode 100644 > > index 000..c411c9b > > --- /dev/null > > +++ b/include/tftp.h > > @@ -0,0 +1,30 @@ > > +/* > > + * LiMon - BOOTP/TFTP. > > + * > > + * Copyright 1994, 1995, 2000 Neil Russell. > > + * Copyright 2011 Comelit Group SpA > > + *Luca Ceresoli > > + * (See License) > > + */ > > + > > +#ifndef __TFTP_H__ > > +#define __TFTP_H__ > > + > > +/**/ > > +/* > > + * Global functions and variables. > > + */ > > + > > +/* tftp.c */ > > +void tftp_start(enum proto_t protocol);/* Begin TFTP > > get/put */ + > > +#ifdef CONFIG_CMD_TFTPSRV > > +void tftp_start_server(void); /* Wait for incoming TFTP put */ > > +#endif > > + > > +extern ulong tftp_timeout_ms; > > +extern int tftp_timeout_count_max; > > + > > +/**/ > > + > > +#endif /* __TFTP_H__ */ > > diff --git a/net/bootp.c b/net/bootp.c > > index 43466af..d325cd0 100644 > > --- a/net/bootp.c > > +++ b/net/bootp.c > > @@ -11,8 +11,8 @@ > > #include > > #include > > #include > > +#include > > #include "bootp.h" > > -#include "tftp.h" > > #include "nfs.h" > > #ifdef CONFIG_STATUS_LED > > #include > > diff --git a/net/net.c b/net/net.c > > index 67e0ad2..8460a51 100644 > > --- a/net/net.c > > +++ b/net/net.c > > @@ -86,6 +86,7 @@ > > #include > > #include > > #include > > +#include > > #if defined(CONFIG_STATUS_LED) > > #include > > #include > > @@ -105,7 +106,6 @@ > > #if defined(CONFIG_CMD_SNTP) > > #include "sntp.h" > > #endif > > -#include "tftp.h" > > > > DECLARE_GLOBAL_DATA_PTR; > > > > diff --git a/net/rarp.c b/net/rarp.c > > index 4ce2f37..2693d4b 100644 > > --- a/net/rarp.c > > +++ b/net/rarp.c > > @@ -8,10 +8,10 @@ > > #include > > #include > > #include > > +#include > > #include "nfs.h" > > #include "bootp.h" > > #include "rarp.h" > > -#include "tftp.h" > > > > #define TIMEOUT 5000UL /* Milliseconds before trying BOOTP again */ > > #ifndefCONFIG_NET_RETRY_COUNT > > diff --git a/net/tftp.c b/net/tftp.c > > index 3e99e73..f95f737 100644 > > --- a/net/tftp.c > > +++ b/net/tftp.c > > @@ -10,7 +10,7 @@ > > #include > > #include > > #include > > -#include "tftp.h" > > +#include > > #include "bootp.h" > > #ifdef CONFIG_SYS_DIRECT_FLASH_TFTP > > #include > > diff --git a/net/tftp.h b/net/tftp.h > > deleted file mode 100644 > > index c411c9b..000 > > --- a/net/tftp.h > > +++ /dev/null > > @@ -1,30 +0,0 @@ > > -/* > > - * LiMon - BOOTP/TFTP. > > - * > > - * Copyright 1994, 1995, 2000 Neil Russell. > > - * Copyright 2011 Comelit Group SpA > > - *Luca Ceresoli > > - * (See License) > > - */ > > - > > -#ifndef __TFTP_H__ > > -#define __TFTP_H__ > > - > > -/**/ > > -/* > > - * Global functions and variables. > > - */ > > - > > -/* tftp.c */ > > -void tftp_start(enum proto_t protocol);/* Begin TFTP > > get/put */ - > > -#ifdef CONFIG_CMD_TFTPSRV > > -void tftp_start_server(void); /* Wait for incoming TFTP put */ > > -#endif > > - > > -extern ulong tftp_timeout_ms; > > -extern int tftp_timeout_count_max; > > - > > -/**/ > > - > > -#endif /* __TFTP_H__ */ > > -- > > 2.1.4 > > > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot Best regards, Lukasz Majewski pgp0oIprLXU4Q.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] nand: lpc32xx: add SLC NAND controller support
On Thu, 2015-07-16 at 02:33 +0300, Vladimir Zapolskiy wrote: > +static void lpc32xx_read_buf(struct mtd_info *mtd, uint8_t *buf, int len) > +{ > + while (len-- > 0) > + *buf++ = (uint8_t)readl(&lpc32xx_nand_slc_registers->data); > +} > + > +static uint8_t lpc32xx_read_byte(struct mtd_info *mtd) > +{ > + return (uint8_t)readl(&lpc32xx_nand_slc_registers->data); > +} > + > +static void lpc32xx_write_buf(struct mtd_info *mtd, const uint8_t *buf, > int len) > +{ > + while (len-- > 0) > + writel((uint32_t)*buf++, &lpc32xx_nand_slc_registers->data); > +} > + > +static void lpc32xx_write_byte(struct mtd_info *mtd, uint8_t byte) > +{ > + writel((uint32_t)byte, &lpc32xx_nand_slc_registers->data); > +} Unnecessary casts. > + /* > + * Hardware ECC calculation is not supported by the driver, because it > + * requires DMA support, see Note after SLC_ECC register description > + */ > + lpc32xx_chip->ecc.mode = NAND_ECC_SOFT; Where can I find this note? I don't see any "SLC_ECC register description". > +#if defined(CONFIG_SPL_BUILD) > + lpc32xx_chip->options |= NAND_SKIP_BBTSCAN; > +#endif Does this make any difference? nand_spl_simple will not do a bbt scan in any case. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8] dfu: tftp: update: Add dfu_write_from_mem_addr() function
Hi Joe, > Hi Lukasz, > > On Sun, Jul 12, 2015 at 10:30 AM, Lukasz Majewski > wrote: > > This function allows writing via DFU data stored from fixed buffer > > address (like e.g. loadaddr env variable). > > > > Such predefined buffers are used in the update_tftp() code. In fact > > this function is a wrapper on the dfu_write() and dfu_flush(). > > > > Signed-off-by: Lukasz Majewski > > --- > > drivers/dfu/dfu.c | 48 > > include/dfu.h > > | 1 + 2 files changed, 49 insertions(+) > > > > diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c > > index 332be67..3fbbecc 100644 > > --- a/drivers/dfu/dfu.c > > +++ b/drivers/dfu/dfu.c > > @@ -568,3 +568,51 @@ int dfu_get_alt(char *name) > > > > return -ENODEV; > > } > > + > > +/** > > + * dfu_write_from_mem_addr - this function adds support for > > writing data > > + * starting from fixed memory address > > (like $loadaddr) > > + * to dfu managed medium (e.g. NAND, MMC) > > + * > > + * @param dfu - dfu entity to which we want to store data > > + * @param buf - fixed memory addres from where data starts > > + * @param size - number of bytes to write > > + * > > + * @return - 0 on success, other value on failure > > + */ > > +int dfu_write_from_mem_addr(struct dfu_entity *dfu, void *buf, int > > size) +{ > > + unsigned long dfu_buf_size, write; > > + int i, ret = 0, left = size; > > + void *dp = buf; > > + > > + /* > > +* Here we must call dfu_get_buf(dfu) first to be sure that > > dfu_buf_size > > +* has been properly initialized - e.g. if "dfu_bufsiz" has > > been taken > > +* into account. > > +*/ > > + dfu_get_buf(dfu); > > + dfu_buf_size = dfu_get_buf_size(); > > + debug("%s: dfu buf size: %lu\n", __func__, dfu_buf_size); > > + > > + for (i = 0; left > 0; i++) { > > + write = (dfu_buf_size < left ? dfu_buf_size : left); > > Please use min() here. Ok. > > > + > > + debug("%s: dp: 0x%p left: %d write: %lu\n", > > __func__, > > + dp, left, write); > > + ret = dfu_write(dfu, dp, write, i); > > + if (ret) { > > + error("DFU write failed\n"); > > + return ret; > > + } > > + > > + dp += write; > > + left -= write; > > + } > > + > > + ret = dfu_flush(dfu, NULL, 0, i); > > + if (ret) > > + error("DFU flush failed!"); > > + > > + return ret; > > +} > > diff --git a/include/dfu.h b/include/dfu.h > > index adad863..ff4db5d 100644 > > --- a/include/dfu.h > > +++ b/include/dfu.h > > @@ -162,6 +162,7 @@ bool dfu_usb_get_reset(void); > > int dfu_read(struct dfu_entity *de, void *buf, int size, int > > blk_seq_num); int dfu_write(struct dfu_entity *de, void *buf, int > > size, int blk_seq_num); int dfu_flush(struct dfu_entity *de, void > > *buf, int size, int blk_seq_num); +int > > dfu_write_from_mem_addr(struct dfu_entity *dfu, void *buf, int > > size); /* Device specific */ #ifdef CONFIG_DFU_MMC > > extern int dfu_fill_entity_mmc(struct dfu_entity *dfu, char > > *devstr, char *s); -- > > 2.1.4 > > > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot Best regards, Lukasz Majewski pgpLS1OsQJG2H.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] nand: lpc32xx: add SLC NAND controller support
On 16.07.2015 23:20, Scott Wood wrote: > On Thu, 2015-07-16 at 02:33 +0300, Vladimir Zapolskiy wrote: >> +static void lpc32xx_read_buf(struct mtd_info *mtd, uint8_t *buf, int len) >> +{ >> + while (len-- > 0) >> + *buf++ = (uint8_t)readl(&lpc32xx_nand_slc_registers->data); >> +} >> + >> +static uint8_t lpc32xx_read_byte(struct mtd_info *mtd) >> +{ >> + return (uint8_t)readl(&lpc32xx_nand_slc_registers->data); >> +} >> + >> +static void lpc32xx_write_buf(struct mtd_info *mtd, const uint8_t *buf, >> int len) >> +{ >> + while (len-- > 0) >> + writel((uint32_t)*buf++, &lpc32xx_nand_slc_registers->data); >> +} >> + >> +static void lpc32xx_write_byte(struct mtd_info *mtd, uint8_t byte) >> +{ >> + writel((uint32_t)byte, &lpc32xx_nand_slc_registers->data); >> +} > > Unnecessary casts. Ok. >> + /* >> + * Hardware ECC calculation is not supported by the driver, because it >> + * requires DMA support, see Note after SLC_ECC register description >> + */ >> + lpc32xx_chip->ecc.mode = NAND_ECC_SOFT; > > Where can I find this note? I don't see any "SLC_ECC register description". This is a reference to SLC_ECC register description from LPC32xx User's Manual, will state it clearly in v2. >> +#if defined(CONFIG_SPL_BUILD) >> + lpc32xx_chip->options |= NAND_SKIP_BBTSCAN; >> +#endif > > Does this make any difference? nand_spl_simple will not do a bbt scan in any > case. Agree, I will remove it. -- With best wishes, Vladimir ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] dfu: command: Provide support for 'dfutftp' command to handle receiving data via TFTP
Hi Joe, > Hi Lukasz, > > On Sun, Jul 12, 2015 at 10:30 AM, Lukasz Majewski > wrote: > > The new 'dfutftp' command has syntax similar to 'dfu' command. > > This new command however, requires some extra env variables to allow > > update_tftp() code to work properly. For more explanation, please > > consult ./doc/README.dfutftp > > It would be great if it didn't require them. I've described reasoning for them in the previous reply. > It would also be great if > there were just a dfu command and "tftp" were a subcommand. It's a > more common pattern now instead of adding new, top-level commands. Good point. However, I've tried to avoid #ifdefs in the cmd_dfu.c code. Some boards only use USB and they would not need support for tftp in the cmd_dfu.c command. Separate command allows adding the code only when it is needed. > > > Signed-off-by: Lukasz Majewski > > --- > > common/Makefile | 1 + > > common/cmd_dfutftp.c | 43 > > +++ 2 files changed, 44 > > insertions(+) create mode 100644 common/cmd_dfutftp.c > > > > diff --git a/common/Makefile b/common/Makefile > > index d6c1d48..483905c 100644 > > --- a/common/Makefile > > +++ b/common/Makefile > > @@ -211,6 +211,7 @@ obj-$(CONFIG_UPDATE_TFTP) += update.o > > obj-$(CONFIG_USB_KEYBOARD) += usb_kbd.o > > obj-$(CONFIG_CMD_DFU) += cmd_dfu.o > > obj-$(CONFIG_CMD_GPT) += cmd_gpt.o > > +obj-$(CONFIG_CMD_DFUTFTP) += cmd_dfutftp.o > > > > # Power > > obj-$(CONFIG_CMD_PMIC) += cmd_pmic.o > > diff --git a/common/cmd_dfutftp.c b/common/cmd_dfutftp.c > > new file mode 100644 > > index 000..2b75a09 > > --- /dev/null > > +++ b/common/cmd_dfutftp.c > > @@ -0,0 +1,43 @@ > > +/* > > + * cmd_dfutftp.c -- dfutftp command > > + * > > + * Copyright (C) 2015 > > + * Lukasz Majewski > > + * > > + * SPDX-License-Identifier:GPL-2.0+ > > + */ > > + > > +#include > > +#include > > + > > +static > > +int do_dfutftp(cmd_tbl_t *cmdtp, int flag, int argc, char * const > > argv[]) +{ > > + unsigned long addr = 0; > > + > > + if (argc < 4 || argc > 5) > > + return CMD_RET_USAGE; > > + > > + char *interface = argv[2]; > > + char *devstring = argv[3]; > > + > > + if (argc == 5) > > + addr = simple_strtoul(argv[4], NULL, 0); > > + > > + /* Below env variables are descibed in detail > > at ./doc/README.dfutftp */ > > + setenv("update_tftp_exec_at_boot", "true"); > > + setenv("update_tftp_dfu", "true"); > > + setenv("update_tftp_dfu_interface", interface); > > + setenv("update_tftp_dfu_devstring", devstring); > > + > > + return update_tftp(addr); > > +} > > + > > +U_BOOT_CMD(dfutftp, CONFIG_SYS_MAXARGS, 1, do_dfutftp, > > + "Device Firmware Upgrade via TFTP", > > + " \n" > > + " - device firmware upgrade via \n" > > + "using TFTP protocol on device , attached\n" > > + "to interface \n" > > + "[addr] - address where FIT image has been stored\n" > > +); > > -- > > 2.1.4 > > > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot Best regards, Lukasz Majewski pgpNjEdd3D9Or.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] sunxi: nand: Add basic sunxi NAND driver with DMA support
On Thu, 2015-07-16 at 13:25 +0200, Piotr Zierhoffer wrote: > From: Piotr Zierhoffer > > This driver adds NAND support to both SPL and full U-Boot. > It was tested on AllWinner A20. It looks a lot like an SPL-only driver to me... > > Signed-off-by: Peter Gielda > Signed-off-by: Tomasz Gorochowik > Signed-off-by: Mateusz Holenko > Signed-off-by: Piotr Zierhoffer > --- > > board/sunxi/Makefile | 1 + > board/sunxi/nand.c | 315 > +++ > board/sunxi/nand.h | 146 > 3 files changed, 462 insertions(+) > create mode 100644 board/sunxi/nand.c > create mode 100644 board/sunxi/nand.h Please keep NAND drivers in drivers/mtd/nand/. > > diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile > index 43766e0..6f1d571 100644 > --- a/board/sunxi/Makefile > +++ b/board/sunxi/Makefile > @@ -9,6 +9,7 @@ > # SPDX-License-Identifier: GPL-2.0+ > # > obj-y+= board.o > +obj-$(CONFIG_SUNXI_NAND) += nand.o > obj-$(CONFIG_SUNXI_GMAC) += gmac.o > obj-$(CONFIG_SUNXI_AHCI) += ahci.o > obj-$(CONFIG_MACH_SUN4I) += dram_sun4i_auto.o > diff --git a/board/sunxi/nand.c b/board/sunxi/nand.c > new file mode 100644 > index 000..16e8e4d > --- /dev/null > +++ b/board/sunxi/nand.c > @@ -0,0 +1,315 @@ > +/* > + * Copyright (c) 2014-2015, Antmicro Ltd > + * Copyright (c) 2015, AW-SOM Technologies > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#include > +#include > +#include > +#include > +#include "nand.h" /* sunxi specific header */ > + > +/* minimal "boot0" style NAND support for Allwinner A20 */ > + > +/* temporary buffer in internal ram */ > +#ifdef CONFIG_SPL_BUILD > +/* in SPL temporary buffer cannot be @ 0x0 */ > +unsigned char temp_buf[SPL_WRITE_SIZE] __aligned(0x10) __section(".text#"); > +#else > +/* put temporary buffer @ 0x0 */ > +unsigned char *temp_buf = (unsigned char *)0x0; > +#endif If 0x0 is the address of an SRAM, its address should be symbolically defined. Also consider mapping it to a different virtual address, to avoid potential compiler mischief. > +#define MAX_RETRIES 10 > + > +static int check_value_inner(int offset, int expected_bits, > + int max_number_of_retries, int negation) > +{ > + int retries = 0; > + do { > + int val = readl(offset) & expected_bits; > + if (negation ? !val : val) > + return 1; > + mdelay(1); > + retries++; > + } while (retries < max_number_of_retries); > + > + return 0; > +} > + > +static inline int check_value(int offset, int expected_bits, > + int max_number_of_retries) > +{ > + return check_value_inner(offset, expected_bits, > + max_number_of_retries, 0); > +} > + > +static inline int check_value_negated(int offset, int unexpected_bits, > + int max_number_of_retries) > +{ > + return check_value_inner(offset, unexpected_bits, > + max_number_of_retries, 1); > +} > + > +void nand_set_clocks(void) > +{ Here and elsewhere, please either use static or less generic name. +int nand_initialized; static bool nand_initialized; Or better yet, get rid of this and stop using init-on-first-use. > + > +void nand_init(void) > +{ > + board_nand_init(NULL); > +} nand_init() is defined in drivers/mtd/nand/nand.c, which is only optional for SPL -- and I don't see an SPL ifdef here. > +uint32_t ecc_errors; static > + > +/* read 0x400 bytes from real_addr to temp_buf */ > +void nand_read_block(unsigned int real_addr, int syndrome) I don't know of any NAND chips whose erase blocks are as small as 0x400 bytes. The read/program unit is called a page, not a block. Is there a reason to hardcode the page size here? Especially since the comment doesn't appear to match the code, which uses SPL_WRITE_SIZE. > +{ > + uint32_t val; > + int ECC_OFF = 0; Why is this capitalized? > + uint16_t ecc_mode = 0; > + uint16_t rand_seed; > + uint32_t page; > + uint16_t column; > + uint32_t oob_offset; > + > + if (!nand_initialized) > + board_nand_init(NULL); board_nand_init() is called from nand_init(). Why are you calling it here? > + switch (CONFIG_SUNXI_ECC_STRENGTH) { No documentation for this symbol. If it's an attribute of the hardware rather than something the user selects, it should be CONFIG_SYS_SUNXI_ECC_STRENGTH, or just SUNXI_ECC_STRENGTH if it doesn't need to integrate with kconfig or makefiles. > + /* clear temp_buf */ > + memset((void *)temp_buf, 0, SPL_WRITE_SIZE); Unnecessary cast. > + > + /* set CMD */ > + writel(NFC_SEND_CMD1 | NFC_WAIT_FLAG | 0xff, > +NANDFLASHC_BASE + NANDFLASHC_CMD); > + > + if (!check_value(NANDFLASHC_BASE + NANDFLASHC_ST, (1 << 1), > + MAX_RETRIES)) { > +
Re: [U-Boot] [PATCH 1/4] sunxi: nand: Add basic sunxi NAND driver with DMA support
On Thursday, July 16, 2015 at 11:15:58 PM, Scott Wood wrote: [...] > > +/* temporary buffer in internal ram */ > > +#ifdef CONFIG_SPL_BUILD > > +/* in SPL temporary buffer cannot be @ 0x0 */ > > +unsigned char temp_buf[SPL_WRITE_SIZE] __aligned(0x10) > > __section(".text#"); +#else > > +/* put temporary buffer @ 0x0 */ > > +unsigned char *temp_buf = (unsigned char *)0x0; > > +#endif > > If 0x0 is the address of an SRAM, its address should be symbolically > defined. Also consider mapping it to a different virtual address, to avoid > potential compiler mischief. The DMA I believe accesses it via PA anyway, so mapping it elsewhere would only confuse everyone who's hacking on the driver. Just my 5 cents ;-) [...] 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 3/4] sunxi: nand: Add a20_nandread command to load image from NAND in SPL
On Thu, 2015-07-16 at 13:25 +0200, Piotr Zierhoffer wrote: > From: Piotr Zierhoffer > > The usage of the command is: > > a20_nandread > > It allows user to copy data from NAND to memory. It employs > nand_spl_load_image from the sunxi NAND driver. > > It is added only when the NAND support is enabled. Please respond to the comments received when it was posted at http://patchwork.ozlabs.org/patch/466149/ > Signed-off-by: Peter Gielda > Signed-off-by: Tomasz Gorochowik > Signed-off-by: Mateusz Holenko > Signed-off-by: Piotr Zierhoffer Why does the same code now have a completely different author and sign-off chain? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] sunxi: nand: Add basic sunxi NAND driver with DMA support
On Thu, 2015-07-16 at 23:26 +0200, Marek Vasut wrote: > On Thursday, July 16, 2015 at 11:15:58 PM, Scott Wood wrote: > > [...] > > > > +/* temporary buffer in internal ram */ > > > +#ifdef CONFIG_SPL_BUILD > > > +/* in SPL temporary buffer cannot be @ 0x0 */ > > > +unsigned char temp_buf[SPL_WRITE_SIZE] __aligned(0x10) > > > __section(".text#"); +#else > > > +/* put temporary buffer @ 0x0 */ > > > +unsigned char *temp_buf = (unsigned char *)0x0; > > > +#endif > > > > If 0x0 is the address of an SRAM, its address should be symbolically > > defined. Also consider mapping it to a different virtual address, to avoid > > potential compiler mischief. > > The DMA I believe accesses it via PA anyway, so mapping it elsewhere would > only confuse everyone who's hacking on the driver. Just my 5 cents ;-) Hey, if it wakes people up to the fact that they ought to be using virt_to_phys() (or better yet, something that distinguishes DMA addresses from physical), great! :-) And yes, people go on to do the same "everything is u32" crap in non-platform- specific files. Just look at drivers/block/ahci.c. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] silence u-boot and kernel console output
U-Boot 2014.07 Kernel 3.14.33 System: MX51 board with touchscreen lcd. I'm trying to figure out the right combination of bootargs or enviroment variables or #define's to silence the console and make everything else work as normal all the way through shutdown. In old kernel and u-boot our bootargs were "console=null root=/dev/mmcblk0p rootwait rw jtag=on fbcon=map:1" In new u-boot and kernel I have narrowed down a few issues... fbcon=map:1 causes our display not to display anything when the system is booted. console=null causes the kernel to hang for about a minute before any log messages appear in sys.log So I got rid of console=null and fbcon=map:1. I replaced it with #defines in config file... #define CONFIG_SILENT_CONSOLE #define CONFIG_SYS_DEVICE_NULLDEV #define CONFIG_SILENT_CONSOLE_UPDATE_ON_SET #define CONFIG_EXTRA_ENV_SETTINGS \ "silent=1\0" \ It boots quick and lcd works, but now when I issue a reboot command I get shutdown messages on the lcd. How can I silence those? -- View this message in context: http://u-boot.10912.n7.nabble.com/silence-u-boot-and-kernel-console-output-tp219794.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] sunxi: nand: Add basic sunxi NAND driver with DMA support
On Thursday, July 16, 2015 at 11:36:08 PM, Scott Wood wrote: > On Thu, 2015-07-16 at 23:26 +0200, Marek Vasut wrote: > > On Thursday, July 16, 2015 at 11:15:58 PM, Scott Wood wrote: > > > > [...] > > > > > > +/* temporary buffer in internal ram */ > > > > +#ifdef CONFIG_SPL_BUILD > > > > +/* in SPL temporary buffer cannot be @ 0x0 */ > > > > +unsigned char temp_buf[SPL_WRITE_SIZE] __aligned(0x10) > > > > __section(".text#"); +#else > > > > +/* put temporary buffer @ 0x0 */ > > > > +unsigned char *temp_buf = (unsigned char *)0x0; > > > > +#endif > > > > > > If 0x0 is the address of an SRAM, its address should be symbolically > > > defined. Also consider mapping it to a different virtual address, to > > > avoid potential compiler mischief. > > > > The DMA I believe accesses it via PA anyway, so mapping it elsewhere > > would only confuse everyone who's hacking on the driver. Just my 5 cents > > ;-) > > Hey, if it wakes people up to the fact that they ought to be using > virt_to_phys() (or better yet, something that distinguishes DMA addresses > from physical), great! :-) Not really useful here, but whatever. > And yes, people go on to do the same "everything is u32" crap in > non-platform- specific files. Just look at drivers/block/ahci.c. Errr, this file is platform specific. 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 1/4] sunxi: nand: Add basic sunxi NAND driver with DMA support
On Fri, 2015-07-17 at 00:06 +0200, Marek Vasut wrote: > On Thursday, July 16, 2015 at 11:36:08 PM, Scott Wood wrote: > > On Thu, 2015-07-16 at 23:26 +0200, Marek Vasut wrote: > > > On Thursday, July 16, 2015 at 11:15:58 PM, Scott Wood wrote: > > > > > > [...] > > > > > > > > +/* temporary buffer in internal ram */ > > > > > +#ifdef CONFIG_SPL_BUILD > > > > > +/* in SPL temporary buffer cannot be @ 0x0 */ > > > > > +unsigned char temp_buf[SPL_WRITE_SIZE] __aligned(0x10) > > > > > __section(".text#"); +#else > > > > > +/* put temporary buffer @ 0x0 */ > > > > > +unsigned char *temp_buf = (unsigned char *)0x0; > > > > > +#endif > > > > > > > > If 0x0 is the address of an SRAM, its address should be symbolically > > > > defined. Also consider mapping it to a different virtual address, to > > > > avoid potential compiler mischief. > > > > > > The DMA I believe accesses it via PA anyway, so mapping it elsewhere > > > would only confuse everyone who's hacking on the driver. Just my 5 cents > > > ;-) > > > > Hey, if it wakes people up to the fact that they ought to be using > > virt_to_phys() (or better yet, something that distinguishes DMA addresses > > from physical), great! :-) > > Not really useful here, but whatever. > > > And yes, people go on to do the same "everything is u32" crap in > > non-platform- specific files. Just look at drivers/block/ahci.c. > > Errr, this file is platform specific. (I'm assuming that by "this file" you mean the sunxi file, not the ahci file.) The point is that establishing good habits everywhere reduces the likelihood of the bad habits migrating to places where things break. And no, I don't seriously expect my suggestion of remapping the virtual address to be implemented, but GCC has been known to do all sorts of weird stuff when it thinks it knows a NULL pointer is being dereferenced. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] sunxi: nand: Add basic sunxi NAND driver with DMA support
On Friday, July 17, 2015 at 12:12:15 AM, Scott Wood wrote: > On Fri, 2015-07-17 at 00:06 +0200, Marek Vasut wrote: > > On Thursday, July 16, 2015 at 11:36:08 PM, Scott Wood wrote: > > > On Thu, 2015-07-16 at 23:26 +0200, Marek Vasut wrote: > > > > On Thursday, July 16, 2015 at 11:15:58 PM, Scott Wood wrote: > > > > > > > > [...] > > > > > > > > > > +/* temporary buffer in internal ram */ > > > > > > +#ifdef CONFIG_SPL_BUILD > > > > > > +/* in SPL temporary buffer cannot be @ 0x0 */ > > > > > > +unsigned char temp_buf[SPL_WRITE_SIZE] __aligned(0x10) > > > > > > __section(".text#"); +#else > > > > > > +/* put temporary buffer @ 0x0 */ > > > > > > +unsigned char *temp_buf = (unsigned char *)0x0; > > > > > > +#endif > > > > > > > > > > If 0x0 is the address of an SRAM, its address should be > > > > > symbolically defined. Also consider mapping it to a different > > > > > virtual address, to avoid potential compiler mischief. > > > > > > > > The DMA I believe accesses it via PA anyway, so mapping it elsewhere > > > > would only confuse everyone who's hacking on the driver. Just my 5 > > > > cents ;-) > > > > > > Hey, if it wakes people up to the fact that they ought to be using > > > virt_to_phys() (or better yet, something that distinguishes DMA > > > addresses from physical), great! :-) > > > > Not really useful here, but whatever. > > > > > And yes, people go on to do the same "everything is u32" crap in > > > non-platform- specific files. Just look at drivers/block/ahci.c. > > > > Errr, this file is platform specific. > > (I'm assuming that by "this file" you mean the sunxi file, not the ahci > file.) > > The point is that establishing good habits everywhere reduces the > likelihood of the bad habits migrating to places where things break. > > And no, I don't seriously expect my suggestion of remapping the virtual > address to be implemented, but GCC has been known to do all sorts of weird > stuff when it thinks it knows a NULL pointer is being dereferenced. OK, you have a point there. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] buildman: Correct '--fetch-arch' command documentation
The doc wrongly put sandbox in the '--fetch-arch' command. Remove it. Signed-off-by: Bin Meng --- tools/buildman/README | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/buildman/README b/tools/buildman/README index 8ecdd8f..10c7135 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -318,7 +318,7 @@ settings file to find them. To make this easier, buildman can automatically download and install toolchains from kernel.org. First list the available architectures: -$ ./tools/buildman/buildman sandbox --fetch-arch list +$ ./tools/buildman/buildman --fetch-arch list Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/ Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.2/ Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/ @@ -329,7 +329,7 @@ sparc sparc64 tilegx x86_64 xtensa Then pick one and download it: -$ ./tools/buildman/buildman sandbox --fetch-arch or32 +$ ./tools/buildman/buildman --fetch-arch or32 Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/ Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.2/ Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/ -- 1.8.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Trouble with mmc 1 on exynos snow chromebook
Hello I have a samsung "snow" chromebook. Building u-boot from git clone git://git.denx.de/u-boot.git and changing #define CONFIG_SYS_TEXT_BASE 0x43E0 to #define CONFIG_SYS_TEXT_BASE 0x4240 in include/configs/exynos5250-common.h I get a chained u-boot that boots. (if I don't make that change I just get a blank screen) The problem that I'm have is that dev mmc 1 (mmcblk1) doesn't seem to work. dev mmc 0 (mmcblk0) does work as far as I have tested it. Below are some of the messages that I get. (btw there are no mmc init or mmcinit commands) snow> mmc rescan dwmci_send_cmd: data ERROR! snow> mmc dev 1 dwmci_send_cmd: Timeout snow> mmc list EXYNOS DWMMC 0 (eMMC) EXYNOS DWMMC 1 snow> ext2load mmc 1:2 ${loadaddr} env.txt dwmci_send_cmd: Timeout ** bad device mmc 1 ** The ext2load command I regularly use on mmc1 using a precompiled version of u-boot works fine so mmc 1 (and the filesystem) is okay Thanks Bruce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] git server, FTP server
Dear Bin, In message you wrote: > > >> I just downloaded several tarballs from ACD. Looks the download speed > >> is OK for me (average 200KB/s). > > > > Ouch, that's awfully slow. Are you sure the bottleneck is on the ACD > > side? How fast is your link usually? > > I have a 15Mbps bandwidth link to the internet. Is the ACD supposed to > choose wherever the nearest download site to the downloader for better > speed? Yes. Hm, other prople have reported (ok - for bigger files, say 4+ GiB) download rates of 11 MiB/s (MegaBYTES per second) on a 100 Mbps fibre link, which is close to the theoretical limit there. So you should get better rates, I think. > The reason that I felt it is OK for me, is that for the > original ftp.denx.de I could only get average 30KB/s when loading a > tarball. Thus I am thankful for the new ACD :) I'm glad if it helps, even though I can't explain why you don't get the full bandwidth. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "It may be that our role on this planet is not to worship God but to create him." - Arthur C. Clarke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot