September 2013 - U-Boot

Re: [U-Boot] When to create a SoC directory for ARM
by FengHua 26 Sep '13

26 Sep '13

> Date: Wed, 25 Sep 2013 20:10:13 -0500 > From: Scott Wood <scottwood(a)freescale.com> > Subject: Re: [U-Boot] When to create a SoC directory for ARM > To: sun york-R58495 <R58495(a)freescale.com> > Cc: Rini <trini(a)ti.com>, Wood Scott-B07421 <B07421(a)freescale.com>, > "u-boot(a)lists.denx.de" <u-boot(a)lists.denx.de>, Tom > Message-ID: <1380157813.24959.237.camel(a)snotra.buserror.net> > Content-Type: text/plain; charset="UTF-8" > On Wed, 2013-09-25 at 20:04 -0500, sun york-R58495 wrote: > > On Sep 25, 2013, at 4:52 PM, Scott Wood wrote: > > > > > On Wed, 2013-09-25 at 16:30 -0700, York Sun wrote: > > >> Dear Wolfgang, > > >> > > >> I failed to find the guideline, here is my question. Pardon me if this > > >> is a dump question as I am still new to ARM. > > >> > > >> As David Feng post his patch set to add ARMv8 support, I am trying to > > >> enable it for Freescale implementation. Let's name it as LS2 for this > > >> discussion. I am thinking to reuse as much as possible for existing > > >> codes, which include copying some header files from powerpc partially. I > > >> noticed the SoC field in boards.cfg file and I am wondering how to use > > >> it effectively. I want to put LS2 specific headers to > > >> arch/arm/include/asm/arch-ls2. Do I need to copy all files from > > >> arch/arm/include/asm/arch-armv8/? There aren't many but I see mmu.h is > > >> included in start.S. I have been searching case like this in ARMv7 but > > >> didn't see shared header file (maybe I missed it). Please advise. > > > > > > LS2 is (or perhaps more accurately, contains) an implementation of > > > ARMv8, so you should be using arch-armv8 rather than copying it. > > > > True. But I guess LS2 won't be the only "LS" Freescale is going to > > make. Where is the best place to put the header file for chassis > > related registers, like CCSR we have for mpc8xxx. > Anything that isn't deeply tied to the ARM architecture should probably > just go in include/. > > I am thinking the > > best place is arch/arm/include/asm/ls2 (or a better name). Like other > > ARMv7 variants, I am thinking to put ls2 under arch/arm/cpu/armv8/ as > > well, to host LS-specific code. > Likewise, if it's specifically tied to armv8 it should go in > arch/arm/include/asm/arch-armv8, but I'm not sure what would be tied to > both armv8 and ls2. Most likely anything LS-specific that needs to go > under arch/arm/ should go somewhere like arch/arm/include/asm/ls/ > (similar to arch/arm/include/asm/imx-common). > -Scott all SOC specific include file should be in arch/arm/include/asm/arch-SOC/ or some common directory(like include/asm/imx-common). Currently, u-boot only link SOC specific(arch-SOC) include directory. You could touch a mmu.h file in arch/arm/include/asm/arch-ls2/ and include arch/arm/include/asm/arch-armv8/mmu.h. or move arch-armv8/mmu.h to arch/arm/include/asm/ to make it as a generic file. Maybe we should distinguish architecture specific include directory and SOC specific include directory. -David

6 20

[U-Boot] MAKEALL build error on usb/master branch
by Troy Kisky 26 Sep '13

26 Sep '13

Hi Marek I thought you might like to be aware of this error, if not already known. Thanks Troy /u-boot-imx6/LOG$ cat mx28evk.ERR mxsimage.c:18:25: fatal error: openssl/evp.h: No such file or directory compilation terminated. make[1]: *** [mxsimage.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: *** wait: No child processes. Stop. make: *** [tools] Error 2

2 2

[U-Boot] [PATCH v10 0/6] arm64 patch
by fenghua＠phytium.com.cn 26 Sep '13

26 Sep '13

From: David Feng <fenghua(a)phytium.com.cn> Changes for v10: - add weak definition to include/linux/linkage.h and make setup_el2/setup_el3/lowlevel_init weak routines, so them can be easily overridden by processor specific code. - modify s-o-f of 0002-board-support-of-vexpress_aemv8a which use wrong mail address of Bhupesh Sharma. Changes for v9: - add Signed-off-by information to patch "board support of vexpress_aemv8a" which SMC91111 support is integrated from Sharma Bhupesh's patch. - adjust pt_regs struct and add exception state preservation in exception.S. Changes for v8: - Integrate SMC91111 patch of sharma bhupesh. - remove v8_outer_cache* which is not need currently. - Change license tag. - Mov crt0.S/relocate.S/interrupts.c to arm/lib and rename them with _64 suffix. - Make el3/el2 initializing process of start.S as two separate routines. It could be easier to be replaced with processor specific codes. - Remove exception stack save and restore routine, it is unnecessary now. - simplify __weak function declaration. Changes for v7: - Check the patches with checkpatch.pl and get rid of almost all warnings. There are a few warnings still, but I think it should be that. - change printf format in cmd_pxe.c, use %zd indtead of %ld to format size_t type variable. - add macro PGTABLE_SIZE to identify tlb table size. Changes for v6: - Make modification to inappropriate licensed file and bugs according to ScottWood's advice. Thanks Scott for his checking to these patches. - Enable u-boot's running at EL1. - Get rid of compiling warnings originated from cmd_pxe.c. Changes for v5: - fix the generic board_f.c, remove zero_global_data from init_sequence_f array and move it to board_init_f() function with CONFIG_X86 switch. The previous fixup is inaccurate. - Replace __ARMEB__ with __AARCH64EB__ in byteorder.h and unaligned.h, gcc for aarch64 use __AARCH64EB__ and __AARCH64EL__ to identify endian. - Some modification to README.armv8 Changes for v4: - merge arm64 to arm architecture. David Feng (6): core support of arm64 board support of vexpress_aemv8a generic board patch of manual reloc and zero gd_t 64bit initrd start address support remove compiling warnings add weak entry definition MAINTAINERS | 4 + arch/arm/config.mk | 4 + arch/arm/cpu/armv8/Makefile | 38 +++ arch/arm/cpu/armv8/cache.S | 130 +++++++++ arch/arm/cpu/armv8/cache_v8.c | 228 ++++++++++++++++ arch/arm/cpu/armv8/config.mk | 16 ++ arch/arm/cpu/armv8/cpu.c | 67 +++++ arch/arm/cpu/armv8/exceptions.S | 115 ++++++++ arch/arm/cpu/armv8/start.S | 238 +++++++++++++++++ arch/arm/cpu/armv8/timer.c | 80 ++++++ arch/arm/cpu/armv8/tlb.S | 30 +++ arch/arm/cpu/armv8/u-boot.lds | 71 +++++ arch/arm/include/asm/arch-armv8/gpio.h | 11 + arch/arm/include/asm/arch-armv8/mmu.h | 106 ++++++++ arch/arm/include/asm/byteorder.h | 12 + arch/arm/include/asm/cache.h | 5 + arch/arm/include/asm/config.h | 10 + arch/arm/include/asm/global_data.h | 6 +- arch/arm/include/asm/io.h | 15 +- arch/arm/include/asm/macro.h | 20 ++ arch/arm/include/asm/posix_types.h | 10 + arch/arm/include/asm/proc-armv/ptrace.h | 21 ++ arch/arm/include/asm/proc-armv/system.h | 59 ++++- arch/arm/include/asm/system.h | 77 ++++++ arch/arm/include/asm/types.h | 4 + arch/arm/include/asm/u-boot.h | 4 + arch/arm/include/asm/unaligned.h | 2 +- arch/arm/lib/Makefile | 14 + arch/arm/lib/board.c | 16 +- arch/arm/lib/bootm.c | 16 ++ arch/arm/lib/crt0_64.S | 116 ++++++++ arch/arm/lib/interrupts_64.c | 120 +++++++++ arch/arm/lib/relocate_64.S | 57 ++++ board/armltd/dts/vexpress64.dts | 439 +++++++++++++++++++++++++++++++ board/armltd/vexpress64/Makefile | 27 ++ board/armltd/vexpress64/vexpress64.c | 70 +++++ boards.cfg | 1 + common/board_f.c | 18 +- common/board_r.c | 18 ++ common/cmd_pxe.c | 4 +- common/fdt_support.c | 66 ++--- common/image.c | 1 + doc/README.armv8 | 18 ++ examples/standalone/stubs.c | 15 ++ include/configs/vexpress_aemv8a.h | 191 ++++++++++++++ include/image.h | 1 + include/linux/linkage.h | 4 + 47 files changed, 2544 insertions(+), 51 deletions(-) create mode 100644 arch/arm/cpu/armv8/Makefile create mode 100644 arch/arm/cpu/armv8/cache.S create mode 100644 arch/arm/cpu/armv8/cache_v8.c create mode 100644 arch/arm/cpu/armv8/config.mk create mode 100644 arch/arm/cpu/armv8/cpu.c create mode 100644 arch/arm/cpu/armv8/exceptions.S create mode 100644 arch/arm/cpu/armv8/start.S create mode 100644 arch/arm/cpu/armv8/timer.c create mode 100644 arch/arm/cpu/armv8/tlb.S create mode 100644 arch/arm/cpu/armv8/u-boot.lds create mode 100644 arch/arm/include/asm/arch-armv8/gpio.h create mode 100644 arch/arm/include/asm/arch-armv8/mmu.h create mode 100644 arch/arm/lib/crt0_64.S create mode 100644 arch/arm/lib/interrupts_64.c create mode 100644 arch/arm/lib/relocate_64.S create mode 100644 board/armltd/dts/vexpress64.dts create mode 100644 board/armltd/vexpress64/Makefile create mode 100644 board/armltd/vexpress64/vexpress64.c create mode 100644 doc/README.armv8 create mode 100644 include/configs/vexpress_aemv8a.h -- 1.7.9.5

5 12

Re: [U-Boot] [PATCH 1/1] am33xx: add CONFIG_SYS_NAND_DEVICE_WIDTH to determine NAND device bus-width
by Scott Wood 26 Sep '13

26 Sep '13

On Thu, 2013-09-26 at 13:14 +0000, Gupta, Pekon wrote: > > > From: Gupta, Pekon <pekon(a)ti.com> > > > > > > NAND driver needs to know bus-width of the connected NAND device, in > > order to perform proper I/O and initialize itself. Currently there is no CONFIG > > option to provide this information to NAND driver. > > > - SPL NAND driver does not have framework to parse ONFI parameter > > page. > > > > Is this about SPL? It looks like a more general change. > > > Yes, actually I would have loved to see a generic SPL driver for all platforms, How could that possibly work? > because SPL is mostly statically configured, and it just does plain NAND read > (it doesn’t even support NAND write, etc). > But I do not know the hardware configurations tweaks of other SoC, > So at-least have common CONFIG_SYS_NAND_xx which all SPL drivers can use. Again, are you introducing this symbol for use only in SPL? It looked like you were removing the code that does dynamic detection, which would also affect non-SPL. -Scott

1 0

[U-Boot] [PATCH] I2C: Zynq: Support for 0-length register address
by Michael Burr 26 Sep '13

26 Sep '13

> Fixed bug with alen == 0 in 'i2c_write', 'i2c_read' Further minor corrections: > Write 'address' register before 'data' register. > Write 'transfer_size' register before 'address' register. Tested: Xilinx ZC702 eval board. Write and read registers with addresses of length 0 and 1. Signed-off-by: Michael Burr <michael.burr(a)logicpd.com> Cc: Heiko Schocher <hs(a)denx.de> Cc: Michal Simek <monstr(a)monstr.eu> --- drivers/i2c/zynq_i2c.c | 43 +++++++++++++++++++++++-------------------- 1 file changed, 23 insertions(+), 20 deletions(-) diff --git a/drivers/i2c/zynq_i2c.c b/drivers/i2c/zynq_i2c.c index ce2d23f..9cbd3e4 100644 --- a/drivers/i2c/zynq_i2c.c +++ b/drivers/i2c/zynq_i2c.c @@ -187,20 +187,22 @@ int i2c_read(u8 dev, uint addr, int alen, u8 *data, int length) * Temporarily disable restart (by clearing hold) * It doesn't seem to work. */ - clrbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_RW | - ZYNQ_I2C_CONTROL_HOLD); + clrbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_HOLD); writel(0xFF, &zynq_i2c->interrupt_status); - while (alen--) - writel(addr >> (8*alen), &zynq_i2c->data); - writel(dev, &zynq_i2c->address); + if (alen) { + clrbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_RW); + writel(dev, &zynq_i2c->address); + while (alen--) + writel(addr >> (8*alen), &zynq_i2c->data); - /* Wait for the address to be sent */ - if (!zynq_i2c_wait(ZYNQ_I2C_INTERRUPT_COMP)) { - /* Release the bus */ - clrbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_HOLD); - return -ETIMEDOUT; + /* Wait for the address to be sent */ + if (!zynq_i2c_wait(ZYNQ_I2C_INTERRUPT_COMP)) { + /* Release the bus */ + clrbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_HOLD); + return -ETIMEDOUT; + } + debug("Device acked address\n"); } - debug("Device acked address\n"); setbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_CLR_FIFO | ZYNQ_I2C_CONTROL_RW); @@ -244,17 +246,18 @@ int i2c_write(u8 dev, uint addr, int alen, u8 *data, int length) ZYNQ_I2C_CONTROL_HOLD); clrbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_RW); writel(0xFF, &zynq_i2c->interrupt_status); - while (alen--) - writel(addr >> (8*alen), &zynq_i2c->data); - /* Start the tranfer */ writel(dev, &zynq_i2c->address); - if (!zynq_i2c_wait(ZYNQ_I2C_INTERRUPT_COMP)) { - /* Release the bus */ - clrbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_HOLD); - return -ETIMEDOUT; + if (alen) { + while (alen--) + writel(addr >> (8*alen), &zynq_i2c->data); + /* Start the tranfer */ + if (!zynq_i2c_wait(ZYNQ_I2C_INTERRUPT_COMP)) { + /* Release the bus */ + clrbits_le32(&zynq_i2c->control, ZYNQ_I2C_CONTROL_HOLD); + return -ETIMEDOUT; + } + debug("Device acked address\n"); } - - debug("Device acked address\n"); while (length--) { writel(*(cur_data++), &zynq_i2c->data); if (readl(&zynq_i2c->transfer_size) == ZYNQ_I2C_FIFO_DEPTH) { -- 1.7.9.5

2 2

Re: [U-Boot] [PATCH 1/1] am33xx: add CONFIG_SYS_NAND_DEVICE_WIDTH to determine NAND device bus-width
by Gupta, Pekon 26 Sep '13

26 Sep '13

> From: Scott Wood [mailto:scottwood@freescale.com] > > > On Wed, 2013-09-25 at 22:08 +0000, Woodruff, Richard wrote: > > Short comment. Apologies for top posting: > > > > The first incarnations of SPL and loader mainly cared about the boot flash > device. > > Is there an SPL that cares about something other than the boot device > now? > AFAIK about SPL driver in drivers/mtd/nand/am335x_spl_bch.c This driver depends on CONFIG_SYS_NAND_xx for deriving all device parameter - CONFIG_SYS_NAND_BLOCK_SIZE - CONFIG_SYS_NAND_PAGE_SIZE - CONFIG_SYS_NAND_ECCSIZE - CONFIG_SYS_NAND_ECCBYTES Thus, IMO SPL drivers are written for following two uses: (1) load secondary boot-loader, which can further do dynamic device probing And based on that enables some device specific features. (2) load linux kernel image directly (in falcon-mode SPL_OS_BOOT), which will reduce the boot-time as all configurations are static. So, in either usage SPL drivers need to be statically configured to keep their foot-print small and boot them fast. > > OMAPs require a resistor strap to specify the width of the boot device. The > values is latched for SW to read. > > > > As such always a run time check of width was sufficient for boot device. > > > > On dev board we would have many devices and use DIP switch to select > which one was in use. A run time not compile time was way to support this. > > > > If information is dynamically available it is better to use this if focus is boot > device management. > > Agree, This was done on TI814x EVM boards which are development boards. but if you refer actual production board (custom boards of end-user), having even a single extra resistor means adding BOM cost. Also in production boards everything is known, (like NAND bus-width, page-size, etc), so dynamic detection becomes redundant because linux would anyways re-do the device probing when it boots. And if anyone really wants to do dynamic device probing in u-boot. Then go till u-boot second stage which has most of device probing capabilities same as linux kernel. (atleast in case of NAND driver). > > Other tricks writing patterns and reading results is also possible but > simplicity of compile vs. that is debatable. > > > > Regards, > > Richard W. > > I agree. Outside of SPL (where hardcoding can be useful due to size > constraints, and you only care about the boot device), it's best to let > drivers determine the best way to learn about such configuration. > > > From: Gupta, Pekon <pekon(a)ti.com> > > > > NAND driver needs to know bus-width of the connected NAND device, in > order to perform proper I/O and initialize itself. Currently there is no CONFIG > option to provide this information to NAND driver. > > - SPL NAND driver does not have framework to parse ONFI parameter > page. > > Is this about SPL? It looks like a more general change. > Yes, actually I would have loved to see a generic SPL driver for all platforms, because SPL is mostly statically configured, and it just does plain NAND read (it doesn’t even support NAND write, etc). But I do not know the hardware configurations tweaks of other SoC, So at-least have common CONFIG_SYS_NAND_xx which all SPL drivers can use. > > - NAND drivers which cannot self initialize > !defined(CONFIG_SYS_NAND_SELF_INIT) > > do not have any information about device bus-width during > board_nand_init(), > > So, any device-width specific configurations are not possible there. > > Convert to self-init. That's what it's for. > I read it in doc/README.nand: CONFIG_SYS_NAND_SELF_INIT And this path is applicable only for second-stage u-boot loader. But today not many drivers are using this model. So just mentioned it here. With regards, pekon

1 1

[U-Boot] [PATCH v4 31/36] sf: Add extended read commands support
by Jagannadha Sutradharudu Teki 26 Sep '13

26 Sep '13

Current sf uses FAST_READ command, this patch adds support to use the different/extended read command. This implementation will determine the fastest command by taking the supported commands from the flash and the controller, controller is always been a priority. Signed-off-by: Jagannadha Sutradharudu Teki <jaganna(a)xilinx.com> --- Changes for v4: - none Changes for v3: - none Changes for v2: - none doc/SPI/status.txt | 2 +- drivers/mtd/spi/spi_flash_ops.c | 2 +- drivers/mtd/spi/spi_flash_probe.c | 180 +++++++++++++++++++++----------------- drivers/spi/spi.c | 2 + include/spi.h | 2 + include/spi_flash.h | 18 ++++ 6 files changed, 122 insertions(+), 84 deletions(-) diff --git a/doc/SPI/status.txt b/doc/SPI/status.txt index be5aebd..cca3ae4 100644 --- a/doc/SPI/status.txt +++ b/doc/SPI/status.txt @@ -10,12 +10,12 @@ SPI FLASH (drivers/mtd/spi): - spi_flash_ops.c: SPI flash operations code. - spi_flash.c: SPI flash interface, which interacts controller driver. - Common probe support for all supported flash vendors except, ramtron. +- Extended read commands support(Array slow/fast, dual output fast, dual IO fast) SPI DRIVERS (drivers/spi): - TODO: -- Extended read commands support(dual read, dual IO read) - Quad Page Program support. - Quad Read support(quad fast read, quad IO read) - Dual flash connection topology support(accessing two spi flash memories with single cs) diff --git a/drivers/mtd/spi/spi_flash_ops.c b/drivers/mtd/spi/spi_flash_ops.c index b4e1c40..9fd1d6b 100644 --- a/drivers/mtd/spi/spi_flash_ops.c +++ b/drivers/mtd/spi/spi_flash_ops.c @@ -273,7 +273,7 @@ int spi_flash_cmd_read_fast(struct spi_flash *flash, u32 offset, return 0; } - cmd[0] = CMD_READ_ARRAY_FAST; + cmd[0] = flash->read_cmd; cmd[4] = 0x00; while (len) { diff --git a/drivers/mtd/spi/spi_flash_probe.c b/drivers/mtd/spi/spi_flash_probe.c index daf53ac..e08d66e 100644 --- a/drivers/mtd/spi/spi_flash_probe.c +++ b/drivers/mtd/spi/spi_flash_probe.c @@ -18,6 +18,13 @@ DECLARE_GLOBAL_DATA_PTR; +static const u32 spi_read_cmds_array[] = { + CMD_READ_ARRAY_SLOW, + CMD_READ_ARRAY_FAST, + CMD_READ_DUAL_OUTPUT_FAST, + CMD_READ_DUAL_IO_FAST, +}; + /* * struct spi_flash_params - SPI/QSPI flash device params structure * @@ -26,6 +33,7 @@ DECLARE_GLOBAL_DATA_PTR; * @ext_jedec: Device ext_jedec ID * @sector_size: Sector size of this device * @nr_sectors: No.of sectors on this device + * @rd_cmd: Read command * @flags: Importent param, for flash specific behaviour */ struct spi_flash_params { @@ -34,107 +42,104 @@ struct spi_flash_params { u16 ext_jedec; u32 sector_size; u32 nr_sectors; + u8 rd_cmd; u16 flags; }; static const struct spi_flash_params spi_flash_params_table[] = { #ifdef CONFIG_SPI_FLASH_ATMEL /* ATMEL */ - {"AT45DB011D", 0x1f2200, 0x0, 64 * 1024, 4, SECT_4K}, - {"AT45DB021D", 0x1f2300, 0x0, 64 * 1024, 8, SECT_4K}, - {"AT45DB041D", 0x1f2400, 0x0, 64 * 1024, 8, SECT_4K}, - {"AT45DB081D", 0x1f2500, 0x0, 64 * 1024, 16, SECT_4K}, - {"AT45DB161D", 0x1f2600, 0x0, 64 * 1024, 32, SECT_4K}, - {"AT45DB321D", 0x1f2700, 0x0, 64 * 1024, 64, SECT_4K}, - {"AT45DB641D", 0x1f2800, 0x0, 64 * 1024, 128, SECT_4K}, + {"AT45DB011D", 0x1f2200, 0x0, 64 * 1024, 4, 0, SECT_4K}, + {"AT45DB021D", 0x1f2300, 0x0, 64 * 1024, 8, 0, SECT_4K}, + {"AT45DB041D", 0x1f2400, 0x0, 64 * 1024, 8, 0, SECT_4K}, + {"AT45DB081D", 0x1f2500, 0x0, 64 * 1024, 16, 0, SECT_4K}, + {"AT45DB161D", 0x1f2600, 0x0, 64 * 1024, 32, 0, SECT_4K}, + {"AT45DB321D", 0x1f2700, 0x0, 64 * 1024, 64, 0, SECT_4K}, + {"AT45DB641D", 0x1f2800, 0x0, 64 * 1024, 128, 0, SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_EON /* EON */ - {"EN25Q32B", 0x1c3016, 0x0, 64 * 1024, 64, 0}, - {"EN25Q64", 0x1c3017, 0x0, 64 * 1024, 128, SECT_4K}, - {"EN25Q128B", 0x1c3018, 0x0, 64 * 1024, 256, 0}, + {"EN25Q32B", 0x1c3016, 0x0, 64 * 1024, 64, 0, 0}, + {"EN25Q64", 0x1c3017, 0x0, 64 * 1024, 128, 0, SECT_4K}, + {"EN25Q128B", 0x1c3018, 0x0, 64 * 1024, 256, 0, 0}, #endif #ifdef CONFIG_SPI_FLASH_GIGADEVICE /* GIGADEVICE */ - {"GD25Q64B", 0xc84017, 0x0, 64 * 1024, 128, SECT_4K}, - {"GD25LQ32", 0xc86016, 0x0, 64 * 1024, 64, SECT_4K}, + {"GD25Q64B", 0xc84017, 0x0, 64 * 1024, 128, 0, SECT_4K}, + {"GD25LQ32", 0xc86016, 0x0, 64 * 1024, 64, 0, SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_MACRONIX /* MACRONIX */ - {"MX25L4005", 0xc22013, 0x0, 64 * 1024, 8, 0}, - {"MX25L8005", 0xc22014, 0x0, 64 * 1024, 16, 0}, - {"MX25L1605D", 0xc22015, 0x0, 64 * 1024, 32, 0}, - {"MX25L3205D", 0xc22016, 0x0, 64 * 1024, 64, 0}, - {"MX25L6405D", 0xc22017, 0x0, 64 * 1024, 128, 0}, - {"MX25L12805", 0xc22018, 0x0, 64 * 1024, 256, 0}, - {"MX25L25635F", 0xc22019, 0x0, 64 * 1024, 512, 0}, - {"MX25L51235F", 0xc2201A, 0x0, 64 * 1024, 1024, 0}, - {"MX25L12855E", 0xc22618, 0x0, 64 * 1024, 256, 0}, + {"MX25L4005", 0xc22013, 0x0, 64 * 1024, 8, 0, 0}, + {"MX25L8005", 0xc22014, 0x0, 64 * 1024, 16, 0, 0}, + {"MX25L1605D", 0xc22015, 0x0, 64 * 1024, 32, 0, 0}, + {"MX25L3205D", 0xc22016, 0x0, 64 * 1024, 64, 0, 0}, + {"MX25L6405D", 0xc22017, 0x0, 64 * 1024, 128, 0, 0}, + {"MX25L12805", 0xc22018, 0x0, 64 * 1024, 256, 0, 0}, + {"MX25L12855E", 0xc22618, 0x0, 64 * 1024, 256, 0, 0}, #endif #ifdef CONFIG_SPI_FLASH_SPANSION /* SPANSION */ - {"S25FL008A", 0x010213, 0x0, 64 * 1024, 16, 0}, - {"S25FL016A", 0x010214, 0x0, 64 * 1024, 32, 0}, - {"S25FL032A", 0x010215, 0x0, 64 * 1024, 64, 0}, - {"S25FL064A", 0x010216, 0x0, 64 * 1024, 128, 0}, - {"S25FL128P_256K", 0x012018, 0x0300, 256 * 1024, 64, 0}, - {"S25FL128P_64K", 0x012018, 0x0301, 64 * 1024, 256, 0}, - {"S25FL032P", 0x010215, 0x4d00, 64 * 1024, 64, 0}, - {"S25FL064P", 0x010216, 0x4d00, 64 * 1024, 128, 0}, - {"S25FL128S_64K", 0x012018, 0x4d01, 64 * 1024, 256, 0}, - {"S25FL256S_256K", 0x010219, 0x4d00, 64 * 1024, 512, 0}, - {"S25FL256S_64K", 0x010219, 0x4d01, 64 * 1024, 512, 0}, - {"S25FL512S_256K", 0x010220, 0x4d00, 64 * 1024, 1024, 0}, - {"S25FL512S_64K", 0x010220, 0x4d01, 64 * 1024, 1024, 0}, + {"S25FL008A", 0x010213, 0x0, 64 * 1024, 16, 0, 0}, + {"S25FL016A", 0x010214, 0x0, 64 * 1024, 32, 0, 0}, + {"S25FL032A", 0x010215, 0x0, 64 * 1024, 64, 0, 0}, + {"S25FL064A", 0x010216, 0x0, 64 * 1024, 128, 0, 0}, + {"S25FL128P_256K", 0x012018, 0x0300, 256 * 1024, 64, RD_CMD_FULL, 0}, + {"S25FL128P_64K", 0x012018, 0x0301, 64 * 1024, 256, RD_CMD_FULL, 0}, + {"S25FL032P", 0x010215, 0x4d00, 64 * 1024, 64, RD_CMD_FULL, 0}, + {"S25FL064P", 0x010216, 0x4d00, 64 * 1024, 128, RD_CMD_FULL, 0}, + {"S25FL128S_64K", 0x012018, 0x4d01, 64 * 1024, 256, RD_CMD_FULL, 0}, + {"S25FL256S_64K", 0x010219, 0x4d01, 64 * 1024, 512, RD_CMD_FULL, 0}, + {"S25FL512S_64K", 0x010220, 0x4d01, 64 * 1024, 1024, RD_CMD_FULL, 0}, #endif #ifdef CONFIG_SPI_FLASH_STMICRO /* STMICRO */ - {"M25P10", 0x202011, 0x0, 32 * 1024, 4, 0}, - {"M25P20", 0x202012, 0x0, 64 * 1024, 4, 0}, - {"M25P40", 0x202013, 0x0, 64 * 1024, 8, 0}, - {"M25P80", 0x202014, 0x0, 64 * 1024, 16, 0}, - {"M25P16", 0x202015, 0x0, 64 * 1024, 32, 0}, - {"M25P32", 0x202016, 0x0, 64 * 1024, 64, 0}, - {"M25P64", 0x202017, 0x0, 64 * 1024, 128, 0}, - {"M25P128", 0x202018, 0x0, 256 * 1024, 64, 0}, - {"N25Q32", 0x20ba16, 0x0, 64 * 1024, 64, SECT_4K}, - {"N25Q32A", 0x20bb16, 0x0, 64 * 1024, 64, SECT_4K}, - {"N25Q64", 0x20ba17, 0x0, 64 * 1024, 128, SECT_4K}, - {"N25Q64A", 0x20bb17, 0x0, 64 * 1024, 128, SECT_4K}, - {"N25Q128", 0x20ba18, 0x0, 64 * 1024, 256, SECT_4K}, - {"N25Q128A", 0x20bb18, 0x0, 64 * 1024, 256, SECT_4K}, - {"N25Q256", 0x20ba19, 0x0, 64 * 1024, 512, SECT_4K}, - {"N25Q256A", 0x20bb19, 0x0, 64 * 1024, 512, SECT_4K}, - {"N25Q512", 0x20ba20, 0x0, 64 * 1024, 1024, E_FSR | SECT_4K}, - {"N25Q512A", 0x20bb20, 0x0, 64 * 1024, 1024, E_FSR | SECT_4K}, - {"N25Q1024", 0x20ba21, 0x0, 64 * 1024, 2048, E_FSR | SECT_4K}, - {"N25Q1024A", 0x20bb21, 0x0, 64 * 1024, 2048, E_FSR | SECT_4K}, + {"M25P10", 0x202011, 0x0, 32 * 1024, 4, 0, 0}, + {"M25P20", 0x202012, 0x0, 64 * 1024, 4, 0, 0}, + {"M25P40", 0x202013, 0x0, 64 * 1024, 8, 0, 0}, + {"M25P80", 0x202014, 0x0, 64 * 1024, 16, 0, 0}, + {"M25P16", 0x202015, 0x0, 64 * 1024, 32, 0, 0}, + {"M25P32", 0x202016, 0x0, 64 * 1024, 64, 0, 0}, + {"M25P64", 0x202017, 0x0, 64 * 1024, 128, 0, 0}, + {"M25P128", 0x202018, 0x0, 256 * 1024, 64, 0, 0}, + {"N25Q32", 0x20ba16, 0x0, 64 * 1024, 64, RD_CMD_FULL, SECT_4K}, + {"N25Q32A", 0x20bb16, 0x0, 64 * 1024, 64, RD_CMD_FULL, SECT_4K}, + {"N25Q64", 0x20ba17, 0x0, 64 * 1024, 128, RD_CMD_FULL, SECT_4K}, + {"N25Q64A", 0x20bb17, 0x0, 64 * 1024, 128, RD_CMD_FULL, SECT_4K}, + {"N25Q128", 0x20ba18, 0x0, 64 * 1024, 256, RD_CMD_FULL, SECT_4K}, + {"N25Q128A", 0x20bb18, 0x0, 64 * 1024, 256, RD_CMD_FULL, SECT_4K}, + {"N25Q256", 0x20ba19, 0x0, 64 * 1024, 512, RD_CMD_FULL, SECT_4K}, + {"N25Q256A", 0x20bb19, 0x0, 64 * 1024, 512, RD_CMD_FULL, SECT_4K}, + {"N25Q512", 0x20ba20, 0x0, 64 * 1024, 1024, RD_CMD_FULL, E_FSR | SECT_4K}, + {"N25Q512A", 0x20bb20, 0x0, 64 * 1024, 1024, RD_CMD_FULL, E_FSR | SECT_4K}, + {"N25Q1024", 0x20ba21, 0x0, 64 * 1024, 2048, RD_CMD_FULL, E_FSR | SECT_4K}, + {"N25Q1024A", 0x20bb21, 0x0, 64 * 1024, 2048, RD_CMD_FULL, E_FSR | SECT_4K}, #endif #ifdef CONFIG_SPI_FLASH_SST /* SST */ - {"SST25VF040B", 0xbf258d, 0x0, 64 * 1024, 8, SECT_4K | SST_WP}, - {"SST25VF080B", 0xbf258e, 0x0, 64 * 1024, 16, SECT_4K | SST_WP}, - {"SST25VF016B", 0xbf2541, 0x0, 64 * 1024, 32, SECT_4K | SST_WP}, - {"SST25VF032B", 0xbf254a, 0x0, 64 * 1024, 64, SECT_4K | SST_WP}, - {"SST25VF064C", 0xbf254b, 0x0, 64 * 1024, 128, SECT_4K}, - {"SST25WF512", 0xbf2501, 0x0, 64 * 1024, 1, SECT_4K | SST_WP}, - {"SST25WF010", 0xbf2502, 0x0, 64 * 1024, 2, SECT_4K | SST_WP}, - {"SST25WF020", 0xbf2503, 0x0, 64 * 1024, 4, SECT_4K | SST_WP}, - {"SST25WF040", 0xbf2504, 0x0, 64 * 1024, 8, SECT_4K | SST_WP}, - {"SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, SECT_4K | SST_WP}, + {"SST25VF040B", 0xbf258d, 0x0, 64 * 1024, 8, 0, SECT_4K | SST_WP}, + {"SST25VF080B", 0xbf258e, 0x0, 64 * 1024, 16, 0, SECT_4K | SST_WP}, + {"SST25VF016B", 0xbf2541, 0x0, 64 * 1024, 32, 0, SECT_4K | SST_WP}, + {"SST25VF032B", 0xbf254a, 0x0, 64 * 1024, 64, 0, SECT_4K | SST_WP}, + {"SST25VF064C", 0xbf254b, 0x0, 64 * 1024, 128, 0 SECT_4K}, + {"SST25WF512", 0xbf2501, 0x0, 64 * 1024, 1, 0, SECT_4K | SST_WP}, + {"SST25WF010", 0xbf2502, 0x0, 64 * 1024, 2, 0, SECT_4K | SST_WP}, + {"SST25WF020", 0xbf2503, 0x0, 64 * 1024, 4, 0, SECT_4K | SST_WP}, + {"SST25WF040", 0xbf2504, 0x0, 64 * 1024, 8, 0, SECT_4K | SST_WP}, + {"SST25WF080", 0xbf2505, 0x0, 64 * 1024, 16, 0, SECT_4K | SST_WP}, #endif #ifdef CONFIG_SPI_FLASH_WINBOND /* WINBOND */ - {"W25P80", 0xef2014, 0x0, 64 * 1024, 16, 0}, - {"W25P16", 0xef2015, 0x0, 64 * 1024, 32, 0}, - {"W25P32", 0xef2016, 0x0, 64 * 1024, 64, 0}, - {"W25X40", 0xef3013, 0x0, 4 * 1024, 128, SECT_4K}, - {"W25X16", 0xef3015, 0x0, 4 * 1024, 512, SECT_4K}, - {"W25X32", 0xef3016, 0x0, 4 * 1024, 1024, SECT_4K}, - {"W25X64", 0xef3017, 0x0, 4 * 1024, 2048, SECT_4K}, - {"W25Q80BL", 0xef4014, 0x0, 4 * 1024, 256, SECT_4K}, - {"W25Q16CL", 0xef4015, 0x0, 4 * 1024, 512, SECT_4K}, - {"W25Q32BV", 0xef4016, 0x0, 4 * 1024, 1024, SECT_4K}, - {"W25Q64CV", 0xef4017, 0x0, 4 * 1024, 2048, SECT_4K}, - {"W25Q128BV", 0xef4018, 0x0, 4 * 1024, 4096, SECT_4K}, - {"W25Q256", 0xef4019, 0x0, 4 * 1024, 8192, SECT_4K}, - {"W25Q80BW", 0xef5014, 0x0, 4 * 1024, 256, SECT_4K}, - {"W25Q16DW", 0xef6015, 0x0, 4 * 1024, 512, SECT_4K}, - {"W25Q32DW", 0xef6016, 0x0, 4 * 1024, 1024, SECT_4K}, - {"W25Q64DW", 0xef6017, 0x0, 4 * 1024, 2048, SECT_4K}, - {"W25Q128FW", 0xef6018, 0x0, 4 * 1024, 4096, SECT_4K}, + {"W25P80", 0xef2014, 0x0, 64 * 1024, 16, 0, 0}, + {"W25P16", 0xef2015, 0x0, 64 * 1024, 32, 0, 0}, + {"W25P32", 0xef2016, 0x0, 64 * 1024, 64, 0, 0}, + {"W25X40", 0xef3013, 0x0, 4 * 1024, 128, 0, SECT_4K}, + {"W25X16", 0xef3015, 0x0, 4 * 1024, 512, 0, SECT_4K}, + {"W25X32", 0xef3016, 0x0, 4 * 1024, 1024, 0, SECT_4K}, + {"W25X64", 0xef3017, 0x0, 4 * 1024, 2048, 0, SECT_4K}, + {"W25Q80BL", 0xef4014, 0x0, 4 * 1024, 256, RD_CMD_FULL, SECT_4K}, + {"W25Q16CL", 0xef4015, 0x0, 4 * 1024, 512, RD_CMD_FULL, SECT_4K}, + {"W25Q32BV", 0xef4016, 0x0, 4 * 1024, 1024, RD_CMD_FULL, SECT_4K}, + {"W25Q64CV", 0xef4017, 0x0, 4 * 1024, 2048, RD_CMD_FULL, SECT_4K}, + {"W25Q128BV", 0xef4018, 0x0, 4 * 1024, 4096, RD_CMD_FULL, SECT_4K}, + {"W25Q256", 0xef4019, 0x0, 4 * 1024, 8192, RD_CMD_FULL, SECT_4K}, + {"W25Q80BW", 0xef5014, 0x0, 4 * 1024, 256, RD_CMD_FULL, SECT_4K}, + {"W25Q16DW", 0xef6015, 0x0, 4 * 1024, 512, RD_CMD_FULL, SECT_4K}, + {"W25Q32DW", 0xef6016, 0x0, 4 * 1024, 1024, RD_CMD_FULL, SECT_4K}, + {"W25Q64DW", 0xef6017, 0x0, 4 * 1024, 2048, RD_CMD_FULL, SECT_4K}, + {"W25Q128FW", 0xef6018, 0x0, 4 * 1024, 4096, RD_CMD_FULL, SECT_4K}, #endif /* * Note: @@ -158,6 +163,7 @@ struct spi_flash *spi_flash_validate_ids(struct spi_slave *spi, u8 *idcode) int i; u16 jedec = idcode[1] << 8 | idcode[2]; u16 ext_jedec = idcode[3] << 8 | idcode[4]; + u8 cmd; /* Get the flash id (jedec = manuf_id + dev_id, ext_jedec) */ for (i = 0; i < ARRAY_SIZE(spi_flash_params_table); i++) { @@ -203,6 +209,16 @@ struct spi_flash *spi_flash_validate_ids(struct spi_slave *spi, u8 *idcode) flash->sector_size = params->sector_size; flash->size = flash->sector_size * params->nr_sectors; + /* Look for the fastest read cmd */ + cmd = fls(params->rd_cmd & flash->spi->rd_cmd); + if (cmd) { + cmd = spi_read_cmds_array[cmd - 1]; + flash->read_cmd = cmd; + } else { + /* Go for controller supported command */ + flash->read_cmd = flash->spi->rd_cmd; + } + /* Compute erase sector and command */ if (params->flags & SECT_4K) { flash->erase_cmd = CMD_ERASE_4K; diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index ea39d1a..0ac9fab 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -7,6 +7,7 @@ #include <common.h> #include <malloc.h> #include <spi.h> +#include <spi_flash.h> void *spi_do_alloc_slave(int offset, int size, unsigned int bus, unsigned int cs) @@ -20,6 +21,7 @@ void *spi_do_alloc_slave(int offset, int size, unsigned int bus, slave = (struct spi_slave *)(ptr + offset); slave->bus = bus; slave->cs = cs; + slave->rd_cmd = CMD_READ_ARRAY_FAST; } return ptr; diff --git a/include/spi.h b/include/spi.h index c0dab57..093847e 100644 --- a/include/spi.h +++ b/include/spi.h @@ -40,11 +40,13 @@ * cs: ID of the chip select connected to the slave. * max_write_size: If non-zero, the maximum number of bytes which can * be written at once, excluding command bytes. + * rd_cmd: Read command. */ struct spi_slave { unsigned int bus; unsigned int cs; unsigned int max_write_size; + u8 rd_cmd; }; /*----------------------------------------------------------------------- diff --git a/include/spi_flash.h b/include/spi_flash.h index 2b1151d..e630913 100644 --- a/include/spi_flash.h +++ b/include/spi_flash.h @@ -27,6 +27,22 @@ #define SECT_32K (1 << 1) #define E_FSR (1 << 2) +/* Read commands */ +#define CMD_READ_ARRAY_SLOW 0x03 +#define CMD_READ_ARRAY_FAST 0x0b +#define CMD_READ_DUAL_OUTPUT_FAST 0x3b +#define CMD_READ_DUAL_IO_FAST 0xbb + +enum spi_read_cmds { + ARRAY_SLOW = 1 << 0, + ARRAY_FAST = 1 << 1, + DUAL_OUTPUT_FAST = 1 << 2, + DUAL_IO_FAST = 1 << 3, +}; + +#define RD_CMD_FULL ARRAY_SLOW | ARRAY_FAST | DUAL_OUTPUT_FAST | \ + DUAL_IO_FAST + /* SST specific macros */ #ifdef CONFIG_SPI_FLASH_SST # define SST_WP 0x01 /* Supports AAI word program */ @@ -48,6 +64,7 @@ * @bank_curr: Current flash bank * @poll_cmd: Poll cmd - for flash erase/program * @erase_cmd: Erase cmd 4K, 32K, 64K + * @read_cmd: Read cmd SA, FA, DOF, DIOF * @memory_map: Address of read-only SPI flash access * @read: Flash read ops * @write: Flash write ops @@ -68,6 +85,7 @@ struct spi_flash { #endif u8 poll_cmd; u8 erase_cmd; + u8 read_cmd; void *memory_map; int (*read)(struct spi_flash *flash, u32 offset, size_t len, void *buf); -- 1.8.3

3 8

[U-Boot] [PATCH 00/19] First step towards Kbuild: Use Kbuild style makefiles
by Masahiro Yamada 26 Sep '13

26 Sep '13

Kbuild in U-Boot has been talked for a while and RFC patches were posted by Simon Glass. (Refer to "RFC: Add Kbuild system to U-Boot" posted by Simon, May 12, 2013) Simon's effort is a good start point but varous critical features were missing from his patch series. I have also been eager to introduce Kbuild to U-Boot. So I have been working on this task for a while with a little different migration path from Simon's way. And I succeeded to build a few boards with support of SPL build, Out-of-tree build, correct output file names, which were missing from Simon's patches. While I were working on my local branch, the build system and makefiles in U-Boot master repository always kept changing, of course. So, my fruit does not fit with the current master repository anymore. But if someone is interested in my work, I can push my local branch to somewhere in my GitHub space. (RFC quality, but might be helpful for just discussions) I recognize these patches are so rough that they support only a few ARM boards. Perfectly covering all architectures and all boards without breaking any U-Boot features is a too big task for a sigle indivisual. Even if I could do that, the patch series would be extremely big size and the adjustment for U-Boot would be complecated. So the review would probably take very long time. Along with the review process, as time goes by, the posted patches would become not appled to the master branch. So we would need to repeat post, review, fix, rebase on the master and post again, reviwe, ... again and again for a very big patch series. I began to be wondering it is possible to switch to Kbuild in this way. So I decided to begin with what I can do, one by one. By stepping little by litte, we can get close to Kbuild and finally we will arrive at our goal. I think this strategy is more realistic rather than adding a big change at one time. Before adding a real Kbuild, I'd like to adjust our build system in a form suitable for Kbuild. First of all, this series convert makefiles in sub directories to Kbuild style. What this series do is quite simple: - Moving common lines in sub makefiles to a new file 'scripts/Makefile.build' - Renaming COBJS-y and SOBJS-y to obj-y in each sub makefile. - A little bit more tweaks That's all. 0001 creates scripts/Makefile.build and tweaks Makefile and spl/Makefile to use scripts/Makefile.build. U-Boot conventional makefiles are like this: include $(TOPDIR)/config.mk LIB = $(obj)libfoo.o COBJS := ... COBJS += ... SOBJS := ... SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) all: $(obj).depend $(LIB) $(LIB): $(OBJS) $(call cmd_link_o_target, $(OBJS)) ######################################################################### include $(SRCTREE)/rules.mk sinclude $(obj).depend ######################################################################### Top and bottom parts are common in almost all makefiles. Writing those lines in all makefiles is a big waste. So common lines have been pushed into scripts/Makefile.build. In addition, scripts/Makefile.build includes a glue code for supporting 'obj-y'. Be aware U-Boot conventional makefile sytle is still supported. So we can change sub makefiles little by little in the following patches. 0002-0019 change sub makefiles into a Kbuild suitable form using obj-y. In order to avoid creating a big patch file, they are divided by CPU architectures and categories. 0002-0007: refactor under arch/arm/ 0008-0016: refactor libraries which are common for all architectures 0017 : refactor under arch/powerpc/ 0018 : refactor under board/ti/ Note arch/arm/cpu/s3c44b0/Makefile was kept untouched. It is the remainder of dead board and should be deleted. (See 'ARM: s3c44b0: remove remainders of dead board' posted by me Aug 19) (I am not a maintainer of TI boards, but I just wanted to demonstrate in 0018 for example how easily board maintainers can do this conversion) Conversion rule is pretty easy: (1) Delete common parts at top and bottom. (2) Rename COBJS -> obj-y SOBJS -> obj-y COBJS-$(CONFIG_FOO) -> obj-$(CONFIG_FOO) SOBJS-$(CONFIG_FOO) -> obj-$(CONFIG_FOO) START -> extra-y We can convert almost automatically althogh in some cases we may need to tweak a little. I refactored more than 150 makefiles in this series. But we still have more than 600 makefiles. (Most of them reside under board/ directory) We can convert them lator little by little. Your contribution is welcome! :-) Note1: This series breaks _NO_ features in U-Boot. Beucase it just moves common parts into scripts/Makefile.build I believe no boards are broken by this refactoring, but it is humans who can make a mistake. So, it is very important to do build check before patches are applied. I tested for ARM and Sandbox like this: $ CROSS_COMPILE_ARM=arm-linux-gnueabi- ./MAKEALL -a arm -a sandbox and I got: --------------------- SUMMARY ---------------------------- Boards compiled: 336 ---------------------------------------------------------- I could not test other architectures because I don't have suitable compiler. Especially PowerPC boards must be checked since I changed under arch/powerpc/ in 0017. I will be grateful for any custodians' help. Note2: This series is _NOT_ RFC. I believe what these patches are doing is clear. 0001 changes less than 100 lines. 0002-0019 changes lots of makefiles, but the conversion rule is simple. So, I expect this series will be reviewed in a few weeks and hopefully applied to master while the next merge window if the review passed. Note3: obj-y := foo/ (descending into foo sub directory) syntax is not supprted in this series. It is implemented in upcoming patch series. The reason why I postpone this feature is I don't want to add a big change at one time. Adjusting for Kbuild little by litte is my strategy here for easy review. Note4: Of course, scripts/Makefile.build added by 0001 patch is temporary. It shall be replaced with the one of Linux Kernel in future. Note5: I confirmed these patches can be apply on v2013.10-rc2 tag. Cc: Simon Glass <sjg(a)chromium.org> Cc: Tom Rini <trini(a)ti.com> Masahiro Yamada (19): Makefile: prepare for using Kbuild-style Makefile armv7: convert makefiles to Kbuild style arm926ejs: convert makefiles to Kbuild style arm920t: convert makefiles to Kbuild style arm720t: convert makefiles to Kbuild style ARM: convert makefiles to Kbuild style ARM: imx-common: convert makefiles to Kbuild style drivers: net: convert makefiles to Kbuild style drivers: mtd: convert makefiles to Kbuild style drivers: usb: convert makefiles to Kbuild style drivers: convert makefiles to Kbuild style fs: convert makefiles to Kbuild style common: convert makefiles to Kbuild style net: convert a makefile to Kbuild style lib: convert makefiles to Kbuild style disk: convert a makefile to Kbuild style sandbox: convert makefiles to Kbuild style powerpc: convert makefiles to Kbuild style board: ti: convert makefiles to Kbuild style Makefile | 42 +++- arch/arm/cpu/arm1136/Makefile | 26 +- arch/arm/cpu/arm1136/mx31/Makefile | 27 +- arch/arm/cpu/arm1136/mx35/Makefile | 28 +-- arch/arm/cpu/arm1176/Makefile | 26 +- arch/arm/cpu/arm1176/bcm2835/Makefile | 25 +- arch/arm/cpu/arm1176/tnetv107x/Makefile | 27 +- arch/arm/cpu/arm720t/Makefile | 26 +- arch/arm/cpu/arm720t/tegra-common/Makefile | 25 +- arch/arm/cpu/arm720t/tegra114/Makefile | 25 +- arch/arm/cpu/arm720t/tegra20/Makefile | 23 +- arch/arm/cpu/arm720t/tegra30/Makefile | 23 +- arch/arm/cpu/arm920t/Makefile | 28 +-- arch/arm/cpu/arm920t/a320/Makefile | 25 +- arch/arm/cpu/arm920t/at91/Makefile | 33 +-- arch/arm/cpu/arm920t/ep93xx/Makefile | 24 +- arch/arm/cpu/arm920t/imx/Makefile | 27 +- arch/arm/cpu/arm920t/ks8695/Makefile | 26 +- arch/arm/cpu/arm920t/s3c24x0/Makefile | 29 +-- arch/arm/cpu/arm925t/Makefile | 30 +-- arch/arm/cpu/arm926ejs/Makefile | 28 +-- arch/arm/cpu/arm926ejs/armada100/Makefile | 23 +- arch/arm/cpu/arm926ejs/at91/Makefile | 59 ++--- arch/arm/cpu/arm926ejs/davinci/Makefile | 48 +--- arch/arm/cpu/arm926ejs/kirkwood/Makefile | 31 +-- arch/arm/cpu/arm926ejs/lpc32xx/Makefile | 23 +- arch/arm/cpu/arm926ejs/mb86r0x/Makefile | 25 +- arch/arm/cpu/arm926ejs/mx25/Makefile | 23 +- arch/arm/cpu/arm926ejs/mx27/Makefile | 23 +- arch/arm/cpu/arm926ejs/mxs/Makefile | 26 +- arch/arm/cpu/arm926ejs/nomadik/Makefile | 25 +- arch/arm/cpu/arm926ejs/omap/Makefile | 26 +- arch/arm/cpu/arm926ejs/orion5x/Makefile | 29 +-- arch/arm/cpu/arm926ejs/pantheon/Makefile | 23 +- arch/arm/cpu/arm926ejs/spear/Makefile | 36 +-- arch/arm/cpu/arm926ejs/versatile/Makefile | 26 +- arch/arm/cpu/arm946es/Makefile | 26 +- arch/arm/cpu/arm_intcm/Makefile | 26 +- arch/arm/cpu/armv7/Makefile | 32 +-- arch/arm/cpu/armv7/am33xx/Makefile | 51 +--- arch/arm/cpu/armv7/at91/Makefile | 31 +-- arch/arm/cpu/armv7/exynos/Makefile | 34 +-- arch/arm/cpu/armv7/highbank/Makefile | 24 +- arch/arm/cpu/armv7/mx5/Makefile | 25 +- arch/arm/cpu/armv7/mx6/Makefile | 23 +- arch/arm/cpu/armv7/omap-common/Makefile | 43 +--- arch/arm/cpu/armv7/omap3/Makefile | 41 +-- arch/arm/cpu/armv7/omap4/Makefile | 31 +-- arch/arm/cpu/armv7/omap5/Makefile | 33 +-- arch/arm/cpu/armv7/rmobile/Makefile | 51 +--- arch/arm/cpu/armv7/s5p-common/Makefile | 29 +-- arch/arm/cpu/armv7/s5pc1xx/Makefile | 27 +- arch/arm/cpu/armv7/socfpga/Makefile | 29 +-- arch/arm/cpu/armv7/tegra-common/Makefile | 24 +- arch/arm/cpu/armv7/tegra114/Makefile | 22 +- arch/arm/cpu/armv7/tegra20/Makefile | 26 +- arch/arm/cpu/armv7/tegra30/Makefile | 22 +- arch/arm/cpu/armv7/u8500/Makefile | 25 +- arch/arm/cpu/armv7/vf610/Makefile | 25 +- arch/arm/cpu/armv7/zynq/Makefile | 29 +-- arch/arm/cpu/ixp/Makefile | 30 +-- arch/arm/cpu/pxa/Makefile | 36 +-- arch/arm/cpu/sa1100/Makefile | 28 +-- arch/arm/cpu/tegra-common/Makefile | 25 +- arch/arm/cpu/tegra114-common/Makefile | 23 +- arch/arm/cpu/tegra20-common/Makefile | 29 +-- arch/arm/cpu/tegra30-common/Makefile | 26 +- arch/arm/imx-common/Makefile | 35 +-- arch/arm/lib/Makefile | 86 ++----- arch/powerpc/cpu/74xx_7xx/Makefile | 28 +-- arch/powerpc/cpu/mpc512x/Makefile | 51 ++-- arch/powerpc/cpu/mpc5xx/Makefile | 27 +- arch/powerpc/cpu/mpc5xxx/Makefile | 54 ++-- arch/powerpc/cpu/mpc824x/Makefile | 28 +-- arch/powerpc/cpu/mpc8260/Makefile | 30 +-- arch/powerpc/cpu/mpc83xx/Makefile | 58 ++--- arch/powerpc/cpu/mpc85xx/Makefile | 233 ++++++++--------- arch/powerpc/cpu/mpc86xx/Makefile | 50 ++-- arch/powerpc/cpu/mpc8xx/Makefile | 58 ++--- arch/powerpc/cpu/mpc8xxx/Makefile | 30 +-- arch/powerpc/cpu/mpc8xxx/ddr/Makefile | 30 +-- arch/powerpc/cpu/ppc4xx/Makefile | 90 +++---- arch/powerpc/lib/Makefile | 78 ++---- arch/sandbox/cpu/Makefile | 23 +- arch/sandbox/lib/Makefile | 25 +- board/ti/am335x/Makefile | 29 +-- board/ti/am3517crane/Makefile | 19 +- board/ti/am43xx/Makefile | 29 +-- board/ti/beagle/Makefile | 24 +- board/ti/dra7xx/Makefile | 27 +- board/ti/evm/Makefile | 19 +- board/ti/omap1510inn/Makefile | 24 +- board/ti/omap5912osk/Makefile | 24 +- board/ti/omap5_uevm/Makefile | 27 +- board/ti/omap730p2/Makefile | 24 +- board/ti/panda/Makefile | 21 +- board/ti/sdp3430/Makefile | 21 +- board/ti/sdp4430/Makefile | 23 +- board/ti/ti814x/Makefile | 29 +-- board/ti/ti816x/Makefile | 27 +- board/ti/tnetv107xevm/Makefile | 25 +- common/Makefile | 389 ++++++++++++++--------------- common/spl/Makefile | 36 +-- disk/Makefile | 34 +-- drivers/bios_emulator/Makefile | 23 +- drivers/block/Makefile | 52 ++-- drivers/bootcount/Makefile | 30 +-- drivers/crypto/Makefile | 25 +- drivers/dfu/Makefile | 25 +- drivers/dma/Makefile | 30 +-- drivers/fpga/Makefile | 44 +--- drivers/gpio/Makefile | 73 ++---- drivers/hwmon/Makefile | 40 +-- drivers/i2c/Makefile | 70 ++---- drivers/input/Makefile | 36 +-- drivers/misc/Makefile | 52 ++-- drivers/mmc/Makefile | 69 ++--- drivers/mtd/Makefile | 44 +--- drivers/mtd/nand/Makefile | 102 +++----- drivers/mtd/onenand/Makefile | 27 +- drivers/mtd/spi/Makefile | 48 +--- drivers/mtd/ubi/Makefile | 28 +-- drivers/net/Makefile | 136 +++++----- drivers/net/fm/Makefile | 59 ++--- drivers/net/npe/Makefile | 24 +- drivers/net/phy/Makefile | 60 ++--- drivers/pci/Makefile | 44 +--- drivers/pcmcia/Makefile | 34 +-- drivers/power/Makefile | 47 +--- drivers/power/battery/Makefile | 25 +- drivers/power/fuel_gauge/Makefile | 25 +- drivers/power/pmic/Makefile | 31 +-- drivers/qe/Makefile | 25 +- drivers/rtc/Makefile | 110 ++++---- drivers/serial/Makefile | 82 +++--- drivers/sound/Makefile | 30 +-- drivers/spi/Makefile | 82 +++--- drivers/tpm/Makefile | 29 +-- drivers/twserial/Makefile | 24 +- drivers/usb/eth/Makefile | 28 +-- drivers/usb/gadget/Makefile | 54 ++-- drivers/usb/host/Makefile | 74 ++---- drivers/usb/musb-new/Makefile | 36 +-- drivers/usb/musb/Makefile | 36 +-- drivers/usb/phy/Makefile | 24 +- drivers/usb/ulpi/Makefile | 28 +-- drivers/video/Makefile | 84 +++---- drivers/watchdog/Makefile | 36 +-- fs/Makefile | 24 +- fs/cbfs/Makefile | 24 +- fs/cramfs/Makefile | 29 +-- fs/ext4/Makefile | 27 +- fs/fat/Makefile | 31 +-- fs/fdos/Makefile | 27 +- fs/jffs2/Makefile | 38 +-- fs/reiserfs/Makefile | 26 +- fs/sandbox/Makefile | 23 +- fs/ubifs/Makefile | 29 +-- fs/yaffs2/Makefile | 33 +-- fs/zfs/Makefile | 25 +- lib/Makefile | 114 ++++----- lib/libfdt/Makefile | 27 +- lib/lzma/Makefile | 24 +- lib/lzo/Makefile | 24 +- lib/rsa/Makefile | 22 +- lib/tizen/Makefile | 24 +- lib/zlib/Makefile | 22 +- net/Makefile | 46 +--- scripts/Makefile.build | 48 ++++ spl/Makefile | 24 +- 170 files changed, 1511 insertions(+), 5095 deletions(-) create mode 100644 scripts/Makefile.build -- 1.8.1.2

2 24

[U-Boot] How do ARM platform initialize DDR?
by York Sun 26 Sep '13

26 Sep '13

Albert, Pardon me if this is a dumb question. I have been working on powerpc platforms in the past. Now we (the developers I work with) are exploring ARM cores. I am searching how memory is initialized and found different solutions. Some platforms have memory ready before u-boot even starts, some simply write to a set of registers. I understand many platforms don't share the IP of DDR controller. I am wondering if there is generic DDR driver used by many ARM platforms, like the one we have for powerpc/mpc85xx SoCs. Regards, York

9 19

[U-Boot] [PATCH v2] drivers/net/designware - fix alignment of buffer descriptors
by Alexey Brodkin 26 Sep '13

26 Sep '13

It's important that buffer descriptors are aligned in accordance to GMAC data bus width (32/64/128-bit). It's safe to align to 128-bit (16-bytes) for every bus width type. If buffer descriptor is improperly aligned GMAC discards lower bits of provided address and as a result reads from improper location that doesn't match expected fields. Commit ef76025a99247cdb8f927a2c9f15400678dfb599 "net: Multiple updates/enhancements to designware.c" introduced another structure member "link_printed" right before buffer descriptors while "padding" member was left untouched. This together with alignment of structure itself to 16-byte boundary forces buffer descriptoprs always to be 4-byte aligned that causes driver complete disfunction if GMAC bus width is 64 or 128-bit. Proposed change makes sure all buffer descriptors are 16-byte (128-bit) aligned. Signed-off-by: Alexey Brodkin <abrodkin(a)synopsys.com> Compared to V1 "dw_eth_dev" structure was left aligned, because I realized that it's address will be used as a base for all the members. And only this way I may be sure arrays of buffer descriptors are properly aligned. --- drivers/net/designware.h | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/net/designware.h b/drivers/net/designware.h index d668f8f..137acb0 100644 --- a/drivers/net/designware.h +++ b/drivers/net/designware.h @@ -128,7 +128,7 @@ struct dmamacdescr { u32 dmamac_cntl; void *dmamac_addr; struct dmamacdescr *dmamac_next; -}; +} __aligned(16); /* * txrx_status definitions @@ -240,8 +240,7 @@ struct dw_eth_dev { u32 tx_currdescnum; u32 rx_currdescnum; u32 phy_configured; - int link_printed; - u32 padding; + u32 link_printed; struct dmamacdescr tx_mac_descrtable[CONFIG_TX_DESCR_NUM]; struct dmamacdescr rx_mac_descrtable[CONFIG_RX_DESCR_NUM]; @@ -253,7 +252,7 @@ struct dw_eth_dev { struct eth_dma_regs *dma_regs_p; struct eth_device *dev; -} __attribute__ ((aligned(8))); +}; /* Speed specific definitions */ #define SPEED_10M 1 -- 1.8.1.2

3 3