March 2013 - U-Boot

[U-Boot] [PATCH] EXYNOS: SPI: Minimise access to SPI FIFO level
by Rajeshwari Shinde 11 May '13

11 May '13

Accessing SPI registers is slow, but access to the FIFO level register in particular seems to be extraordinarily expensive (I measure up to 600ns). Perhaps it is required to synchronise with the SPI byte output logic which might run at 1/8th of the 40MHz SPI speed (just a guess). Reduce access to this register by filling up and emptying FIFOs more completely, rather than just one word each time around the inner loop. Since the rxfifo value will now likely be much greater that what we read before we fill the txfifo, we only fill the txfifo halfway. This is because if the txfifo is empty, but the rxfifo has data in it, then writing too much data to the txfifo may overflow the rxfifo as data arrives. This speeds up SPI flash reading from about 1MB/s to about 2MB/s on snow. Signed-off-by: Simon Glass <sjg(a)chromium.org> Signed-off-by: Rajeshwari Shinde <rajeshwari.s(a)samsung.com> --- drivers/spi/exynos_spi.c | 31 +++++++++++++++++-------------- 1 files changed, 17 insertions(+), 14 deletions(-) diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c index c19e227..7bbf9ce 100644 --- a/drivers/spi/exynos_spi.c +++ b/drivers/spi/exynos_spi.c @@ -260,33 +260,36 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo, /* Keep the fifos full/empty. */ spi_get_fifo_levels(regs, &rx_lvl, &tx_lvl); - if (tx_lvl < spi_slave->fifo_size && out_bytes) { + while (tx_lvl < spi_slave->fifo_size / 2 && out_bytes) { temp = txp ? *txp++ : 0xff; writel(temp, &regs->tx_data); out_bytes--; + tx_lvl++; } if (rx_lvl > 0 && in_bytes) { - temp = readl(&regs->rx_data); - if (!rxp && !stopping) { - in_bytes--; - } else if (spi_slave->skip_preamble) { - if (temp == SPI_PREAMBLE_END_BYTE) { - spi_slave->skip_preamble = 0; - stopping = 0; + while (rx_lvl > 0 && in_bytes) { + temp = readl(&regs->rx_data); + if (!rxp && !stopping) { + in_bytes--; + } else if (spi_slave->skip_preamble) { + if (temp == SPI_PREAMBLE_END_BYTE) { + spi_slave->skip_preamble = 0; + stopping = 0; + } + } else { + *rxp++ = temp; + in_bytes--; } - } else { - *rxp++ = temp; - in_bytes--; + toread--; + rx_lvl--; } - toread--; - } /* * We have run out of input data, but haven't read enough * bytes after the preamble yet. Read some more, and make * sure that we transmit dummy bytes too, to keep things * going. */ - else if (in_bytes && !toread) { + } else if (in_bytes && !toread) { assert(!out_bytes); toread = out_bytes = in_bytes; txp = NULL; -- 1.7.4.4

2 1

[U-Boot] Beagle-XM: u-boot SPL fat support (was Re: [opensuse-arm] Beagleboard Xm CPU speed)
by Nishanth Menon 11 May '13

11 May '13

Change in subject. Original thread start: http://lists.opensuse.org/opensuse-arm/2013-03/msg00076.html On 17:15-20130319, Guillaume Gardet wrote: > > Le 19/03/2013 17:04, Nishanth Menon a écrit : > >On 08:47-20130319, gary wrote: > >>Just a FYI, here is the the boot text dumped to the serial port. It > >>indicates a 1GHz max clock rate, but maybe that is just a > >>"capability" of the board (as in a designation) and not a parameter > >>that has been set. > >> > >>I see in the boot text there is a way to interrupt the automatic > >>boot, which I presume is a way to set parameters. Could someone give > >>me what such a line would look like for forcing the mpurate? > >> > >>--------------------------------------- > >>Texas Instruments X-Loader 1.5.0 (Sep 8 2012 - 02:21:18) > >>Beagle xM > >>Reading boot sector > >>Error: reading boot sector > >>fat load failed, trying ext2 > >>Loading u-boot.bin from mmc > >Why are we still using old x-loader - we should be using SPL MLO from > >u-boot master - it works straight on beagleXM. > > Our last tests with SPL and latest u-boot were unsuccessful! And we have to port ext2 support to it because we have no FAT partition. Quote from an internal query I just did: "There shouldn't be a case where xM has memory that X-Loader works for that SPL did not. There _may_ be a UART issue that needs work-arounding however. And of course if they used mainline they could pretty easily do RAW for SPL/U-Boot.img and then do everything else with ext2/3/4 and ignore FAT. " I am ccying u-boot Mailing list to see how we can help. -- Regards, Nishanth Menon

4 7

[U-Boot] [PATCH 0/5] Add Support for Storage Devices with Blocksizes != 512.
by egbert.eich＠googlemail.com 10 May '13

10 May '13

From: Egbert Eich <eich(a)suse.com> The patches provide fixes for partition tables: - GPT - ISO (to ignore devices with blocksize != 512) The ext4 fs code also got fixed. I've reviewed the fat code, it seems to be ok already (except for a bug that I came across). I may be persuaded to take a shot at other fs which are supported by a vanilla Linux kernel. Cheers, Egbert. Egbert Eich (5): disk/gpt: Fix GPT Partition handling for Blocksize != 512. disk/iso: Add Support for Block Sizes > 512 Byte to ISO partition support. fs/fat: Don't multiply fatsize with sector size. part/dev_desc: Add log2 of Blocksize to block_dev_desc data struct. fs/ext4: Support device block sizes != 512 bytes. common/cmd_ide.c | 4 +++ common/cmd_sata.c | 1 + common/cmd_scsi.c | 2 + common/usb_storage.c | 1 + disk/part_efi.c | 32 +++++++++++++------------- disk/part_iso.c | 3 ++ drivers/block/ata_piix.c | 1 + drivers/block/pata_bfin.c | 1 + drivers/block/systemace.c | 1 + drivers/mmc/mmc.c | 1 + fs/ext4/dev.c | 52 +++++++++++++++++++++++++++----------------- fs/ext4/ext4_common.c | 26 ++++++++++------------ fs/ext4/ext4_common.h | 2 +- fs/ext4/ext4_journal.c | 6 +--- fs/ext4/ext4_write.c | 27 +++++++++++------------ fs/ext4/ext4fs.c | 11 +++++---- fs/fat/fat_write.c | 1 - include/common.h | 12 +++++++-- include/ext4fs.h | 1 + include/ext_common.h | 9 +------- include/part.h | 8 +++++++ include/part_efi.h | 2 - 22 files changed, 116 insertions(+), 88 deletions(-) -- 1.7.7

5 16

[U-Boot] [PATCH] at91sam9260ek: move board id setup to config header
by Andreas Bießmann 10 May '13

10 May '13

Signed-off-by: Andreas Bießmann <andreas.devel(a)googlemail.com> Cc: Bo Shen <voice.shen(a)atmel.com> --- board/atmel/at91sam9260ek/at91sam9260ek.c | 12 ------------ include/configs/at91sam9260ek.h | 20 ++++++++++++++++++++ 2 files changed, 20 insertions(+), 12 deletions(-) diff --git a/board/atmel/at91sam9260ek/at91sam9260ek.c b/board/atmel/at91sam9260ek/at91sam9260ek.c index 3aa394a..049b3d7 100644 --- a/board/atmel/at91sam9260ek/at91sam9260ek.c +++ b/board/atmel/at91sam9260ek/at91sam9260ek.c @@ -157,18 +157,6 @@ int board_early_init_f(void) int board_init(void) { -#ifdef CONFIG_AT91SAM9G20EK_2MMC - /* arch number of AT91SAM9G20EK_2MMC-Board */ - gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9G20EK_2MMC; -#else -#ifdef CONFIG_AT91SAM9G20EK - /* arch number of AT91SAM9G20EK-Board */ - gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9G20EK; -#else - /* arch number of AT91SAM9260EK-Board */ - gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9260EK; -#endif -#endif /* adress of boot parameters */ gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100; diff --git a/include/configs/at91sam9260ek.h b/include/configs/at91sam9260ek.h index 02696b3..2d2efb2 100644 --- a/include/configs/at91sam9260ek.h +++ b/include/configs/at91sam9260ek.h @@ -125,6 +125,26 @@ (ATMEL_BASE_SRAM1 + 0x1000 - GENERATED_GBL_DATA_SIZE) #endif +/* + * The (arm)linux board id set by generic code depending on configured board + * (see boards.cfg for different boards) + */ +#ifdef CONFIG_AT91SAM9G20 + /* the sam9g20 variants have two different board ids */ +# ifdef CONFIG_AT91SAM9G20EK_2MMC + /* we may be setup for the 2MMC variant of at91sam9g20ek */ +# define CONFIG_MACH_TYPE MACH_TYPE_AT91SAM9G20EK_2MMC +# else +# ifdef CONFIG_AT91SAM9G20EK + /* or the normal at91sam9g20ek */ +# define CONFIG_MACH_TYPE MACH_TYPE_AT91SAM9G20EK +# endif +# endif +#else + /* otherwise default to good old at91sam9260ek */ +# define CONFIG_MACH_TYPE MACH_TYPE_AT91SAM9260EK +#endif + /* DataFlash */ #ifndef CONFIG_AT91SAM9G20EK_2MMC #define CONFIG_ATMEL_DATAFLASH_SPI -- 1.7.10.4

2 4

Re: [U-Boot] Displaying characters on the display in u-boot
by Anatolij Gustschin 10 May '13

10 May '13

Hi, please keep the U-Boot list address on Cc, other users may find the discussion helpful. On Wed, 27 Mar 2013 19:40:33 +0530 Bhargav A K <bhargav.ak(a)sasken.com> wrote: ... > Now I will have to define video_set_lut() also, isn't it ? It depends. What U-Boot version do you use? If you use mainline U-Boot recent versions like v2013.01.01, then this function already exists as a week default empty function. You do not always need video_set_lut() functionality unless you want to use a frame buffer configuration with 8 bits per pixel colour depth. > Can I please get more information on what I have to handle inside the function ? This video_set_lut() function is only needed if you use 8 bits per pixel frame buffer. I doubt that you want to use it since the splash screen quality will be really bad in this color depth mode. If you want to use this depth, then this function should fill the color palette (look up table) of the display controller using the index argument of the function as an index into look-up table and using other arguments as values for the look-up table entries under that index. > Also, Is there any place where I can of getting more information on the structure members > of "struct GraphicDevice" ? the needed struct members are more or less self-explanatory, so these are not documented anywhere, I think. You need to init only: winSizeX - the width of the display in pixels winSizeY - the height of the display in pixels gdfBytesPP - frame buffer color depth in bytes per pixel gdfIndex - graphics data format of the frame buffer, it is one of GDF__8BIT_INDEX GDF_15BIT_555RGB GDF_16BIT_565RGB GDF_32BIT_X888RGB GDF_24BIT_888RGB GDF__8BIT_332RGB frameAdrs - the starting frame buffer address in the video ram You do not need to initialise other members. Thanks, Anatolij

2 8

[U-Boot] [PATCH] EXYNOS: SPI: Support word transfers
by Rajeshwari Shinde 09 May '13

09 May '13

Since SPI register access is so expensive, it is worth transferring data a word at a time if we can. This complicates the driver unfortunately. Use the byte-swapping feature to avoid having to convert to/from big endian in software. This change increases speed from about 2MB/s to about 4.5MB/s. Based on "EXYNOS: SPI: Minimise access to SPI FIFO level" link: http://patchwork.ozlabs.org/patch/230034/ Signed-off-by: Simon Glass <sjg(a)chromium.org> Signed-off-by: Rajeshwari Shinde <rajeshwari.s(a)samsung.com> --- arch/arm/include/asm/arch-exynos/spi.h | 11 ++++- drivers/spi/exynos_spi.c | 77 +++++++++++++++++++++++++------ 2 files changed, 72 insertions(+), 16 deletions(-) diff --git a/arch/arm/include/asm/arch-exynos/spi.h b/arch/arm/include/asm/arch-exynos/spi.h index 7cab1e9..e67ad27 100644 --- a/arch/arm/include/asm/arch-exynos/spi.h +++ b/arch/arm/include/asm/arch-exynos/spi.h @@ -34,7 +34,7 @@ struct exynos_spi { unsigned int rx_data; /* 0x1c */ unsigned int pkt_cnt; /* 0x20 */ unsigned char reserved2[4]; - unsigned char reserved3[4]; + unsigned int swap_cfg; /* 0x28 */ unsigned int fb_clk; /* 0x2c */ unsigned char padding[0xffd0]; }; @@ -74,5 +74,14 @@ struct exynos_spi { /* Packet Count */ #define SPI_PACKET_CNT_EN (1 << 16) +/* Swap config */ +#define SPI_TX_SWAP_EN (1 << 0) +#define SPI_TX_BYTE_SWAP (1 << 2) +#define SPI_TX_HWORD_SWAP (1 << 3) +#define SPI_TX_BYTE_SWAP (1 << 2) +#define SPI_RX_SWAP_EN (1 << 4) +#define SPI_RX_BYTE_SWAP (1 << 6) +#define SPI_RX_HWORD_SWAP (1 << 7) + #endif /* __ASSEMBLY__ */ #endif diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c index 7bbf9ce..d1918cf 100644 --- a/drivers/spi/exynos_spi.c +++ b/drivers/spi/exynos_spi.c @@ -218,12 +218,29 @@ static void spi_get_fifo_levels(struct exynos_spi *regs, * * @param regs SPI peripheral registers * @param count Number of bytes to transfer + * @param step Number of bytes to transfer in each packet (1 or 4) */ -static void spi_request_bytes(struct exynos_spi *regs, int count) +static void spi_request_bytes(struct exynos_spi *regs, int count, int step) { + /* For word address we need to swap bytes */ + if (step == 4) { + setbits_le32(&regs->mode_cfg, + SPI_MODE_CH_WIDTH_WORD | SPI_MODE_BUS_WIDTH_WORD); + count /= 4; + setbits_le32(&regs->swap_cfg, SPI_TX_SWAP_EN | SPI_RX_SWAP_EN | + SPI_TX_BYTE_SWAP | SPI_RX_BYTE_SWAP | + SPI_TX_HWORD_SWAP | SPI_RX_HWORD_SWAP); + } else { + /* Select byte access and clear the swap configuration */ + clrbits_le32(&regs->mode_cfg, + SPI_MODE_CH_WIDTH_WORD | SPI_MODE_BUS_WIDTH_WORD); + writel(0, &regs->swap_cfg); + } + assert(count && count < (1 << 16)); setbits_le32(&regs->ch_cfg, SPI_CH_RST); clrbits_le32(&regs->ch_cfg, SPI_CH_RST); + writel(count | SPI_PACKET_CNT_EN, &regs->pkt_cnt); } @@ -238,6 +255,7 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo, int toread, preamable_count = 0; unsigned start = get_timer(0); int stopping; + int step; out_bytes = in_bytes = todo; @@ -245,10 +263,19 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo, !(spi_slave->mode & SPI_SLAVE); /* + * Try to transfer words if we can. This helps read performance at + * SPI clock speeds above about 20MHz. + */ + step = 1; + if (!((todo | (uintptr_t)rxp | (uintptr_t)txp) & 3) && + !spi_slave->skip_preamble) + step = 4; + + /* * If there's something to send, do a software reset and set a * transaction size. */ - spi_request_bytes(regs, todo); + spi_request_bytes(regs, todo, step); /* * Bytes are transmitted/received in pairs. Wait to receive all the @@ -260,28 +287,44 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo, /* Keep the fifos full/empty. */ spi_get_fifo_levels(regs, &rx_lvl, &tx_lvl); + + /* + * Don't completely fill the txfifo, since we don't want our + * rxfifo to overflow, and it may already contain data. + */ while (tx_lvl < spi_slave->fifo_size / 2 && out_bytes) { - temp = txp ? *txp++ : 0xff; + if (!txp) + temp = -1; + else if (step == 4) + temp = *(uint32_t *)txp; + else + temp = *txp; writel(temp, &regs->tx_data); - out_bytes--; - tx_lvl++; + out_bytes -= step; + if (txp) + txp += step; + tx_lvl += step; } - if (rx_lvl > 0 && in_bytes) { - while (rx_lvl > 0 && in_bytes) { + if (rx_lvl >= step && in_bytes) { + while (rx_lvl >= step && in_bytes) { temp = readl(&regs->rx_data); if (!rxp && !stopping) { - in_bytes--; + in_bytes -= step; } else if (spi_slave->skip_preamble) { if (temp == SPI_PREAMBLE_END_BYTE) { spi_slave->skip_preamble = 0; stopping = 0; } } else { - *rxp++ = temp; - in_bytes--; + if (step == 4) + *(uint32_t *)rxp = temp; + else + *rxp = temp; + in_bytes -= step; + rxp += step; } - toread--; - rx_lvl--; + toread -= step; + rx_lvl -= step; } /* * We have run out of input data, but haven't read enough @@ -293,7 +336,7 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo, assert(!out_bytes); toread = out_bytes = in_bytes; txp = NULL; - spi_request_bytes(regs, toread); + spi_request_bytes(regs, toread, step); } if (spi_slave->skip_preamble && get_timer(start) > 100) { printf("SPI timeout: in_bytes=%d, out_bytes=%d, ", @@ -336,10 +379,14 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout, if ((flags & SPI_XFER_BEGIN)) spi_cs_activate(slave); - /* Exynos SPI limits each transfer to 65535 bytes */ + /* + * Exynos SPI limits each transfer to 65535 transfers. To keep + * things simple, allow a maximum of 65532 bytes. We could allow + * more in word mode, but the performance difference is small. + */ bytelen = bitlen / 8; for (upto = 0; !ret && upto < bytelen; upto += todo) { - todo = min(bytelen - upto, (1 << 16) - 1); + todo = min(bytelen - upto, (1 << 16) - 4); ret = spi_rx_tx(spi_slave, todo, &din, &dout, flags); } -- 1.7.4.4

2 1

[U-Boot] [Patch v2, batch 1 01/10] doc/ramboot.mpc85xx: Documented the RAMBOOT for MPC85xx
by York Sun 08 May '13

08 May '13

From: Poonam Aggrwal <poonam.aggrwal(a)freescale.com> There could be scenarios where the user would like to manually(via JTAG) configure the DDR/L2SRAM and load the bootloader binary onto DDR/L2SRAM. This document explains thse usecases and the detailed explanation of what needs to be done to use it. Most of the code from CONFIG_SYS_RAMBOOT will be used except for small changes of CCSRBAR etc. The changes are not very large, but it is good to document them so that user can get it working at once. Signed-off-by: Poonam Aggrwal <poonam.aggrwal(a)freescale.com> --- doc/README.ramboot-ppc85xx | 102 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 102 insertions(+) create mode 100644 doc/README.ramboot-ppc85xx diff --git a/doc/README.ramboot-ppc85xx b/doc/README.ramboot-ppc85xx new file mode 100644 index 0000000..8ed45fb --- /dev/null +++ b/doc/README.ramboot-ppc85xx @@ -0,0 +1,102 @@ + RAMBOOT for MPC85xx Platforms + ============================== + +RAMBOOT literally means boot from DDR. But since DDR is volatile memory some +pre-mechanism is required to load the DDR with the bootloader binary. +- In case of SD and SPI boot this is done by BootROM code inside the chip + itself. +- In case of NAND boot FCM supports loading initial 4K code from NAND flash + which can initialize the DDR and get the complete bootloader copied to DDR. + +In addition to the above there could be some more methods to initialize the DDR +and load it manually. +Two of them are described below.There is also an explanation as to where these +methods could be handy. +1. Load the RAM based bootloader onto DDR via JTAG/BDI interface. And then + execute the bootloader from DDR. + This may be handy in the following cases: + - In very early stage of platform bringup where other boot options are not + functional because of various reasons. + - In case the support to program the flashes on the board is not available. + +2. Load the RAM based bootloader onto DDR using already existing bootloader on + the board.And then execute the bootloader from DDR. + Some usecases where this may be used: + - While developing some new feature of u-boot, for example USB driver or + SPI driver. + Suppose the board already has a working bootloader on it. And you would + prefer to keep it intact, at the same time want to test your bootloader. + In this case you can get your test bootloader binary into DDR via tftp + for example. Then execute the test bootloader. + - Suppose a platform already has a propreitery bootloader which does not + support for example AMP boot. In this case also RAM boot loader can be + utilized. + + So basically when the original bootloader is required to be kept intact + RAM based bootloader can offer an updated bootloader on the system. + +Both the above Bootloaders are slight variants of SDcard or SPI Flash +bootloader or for that matter even NAND bootloader. +All of them define CONFIG_SYS_RAMBOOT. +The main difference among all of them is the way the pre-environment is getting +configured and who is doing that. +- In case of SD card and SPI flash bootloader this is done by On Chip BootROM inside the Si itself. +- In case of NAND boot SPL/TPL code does it with some support from Si itself. +- In case of the pure RAM based bootloaders we have to do it by JTAG manually or already existing bootloader. + +How to use them: +1. Using JTAG + Boot up in core hold off mode or stop the core after reset using JTAG + interface. + Preconfigure DDR/L2SRAM through JTAG interface. + - setup DDR controller registers. + - setup DDR LAWs + - setup DDR TLB + Load the RAM based boot loader to the proper location in DDR/L2SRAM. + set up IAR (Instruction counter properly) + Enable the core to execute. + +2. Using already existing bootloader. + get the rambased boot loader binary into DDR/L2SRAM via tftp. + execute the RAM based bootloader. + => tftp 11000000 u-boot-ram.bin + => go 1107f000 + +Please note that L2SRAM can also be used instead of DDR if the SOC has +sufficient size of L2SRAM. + +Necessary Code changes Required: +===================================== +Please note that below mentioned changes are for 85xx platforms. +They have been tested on P1020/P2020/P1010 RDB. + +The main difference between the above two methods from technical perspective is +that in 1st case SOC is just out of reset so it is in default configuration. +(CCSRBAR is at 0xff700000). +In the 2nd case bootloader has already re-located CCSRBAR to 0xffe00000 + +1. File name-> boards.cfg + There can be added specific Make options for RAMBoot. We can keep different + options for the two cases mentioned above. + for example + P1020RDB_JTAG_RAMBOOT and P1020RDB_GO_RAMBOOT. + +2. platform config file + for example include/configs/P1_P2_RDB.h + + #ifdef CONFIG_RAMBOOT + #define CONFIG_SDCARD + #endif + + This will finally use the CONFIG_SYS_RAMBOOT. + +3. File name-> arch/powerpc/include/asm/config_mpc85xx.h + In the section of the particular SOC, for example P1020, + + #if defined(CONFIG_GO) + #define CONFIG_SYS_CCSRBAR_DEFAULT 0xffe00000 + #else + #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff700000 + #endif + +For JTAG RAMBOOT this is not required because CCSRBAR is at ff700000. -- 1.7.9.5

2 10

[U-Boot] [PATCH 1/7] powerpc/doc: Update the README.srio-pcie-boot-corenet
by Liu Gang 07 May '13

07 May '13

1. Misalignment will be found in the doc/README.srio-pcie-boot-corenet file when the tabs are set to 8 characters. And the standard for u-boot should be 8 character tabs! So this issue should be amended. 2. Add a NOTE for the ENV parameters of the Slave. Signed-off-by: Liu Gang <Gang.Liu(a)freescale.com> --- doc/README.srio-pcie-boot-corenet | 34 ++++++++++++++++++++-------------- 1 files changed, 20 insertions(+), 14 deletions(-) diff --git a/doc/README.srio-pcie-boot-corenet b/doc/README.srio-pcie-boot-corenet index cd7e7ee..2b1f76b 100644 --- a/doc/README.srio-pcie-boot-corenet +++ b/doc/README.srio-pcie-boot-corenet @@ -21,13 +21,13 @@ Environment of the SRIO or PCIE boot: e) Slave's RCW should configure the SerDes for SRIO or PCIE boot port, set the boot location to SRIO or PCIE, and holdoff all the cores. - ---------- ----------- ----------- - | | | | | | - | | | | | | + ----------- ----------- ----------- + | | | | | | + | | | | | | | NorFlash|<----->| Master |SRIO or PCIE | Slave |<---->[EEPROM] - | | | |<===========>| | - | | | | | | - ---------- ----------- ----------- + | | | |<===========>| | + | | | | | | + ----------- ----------- ----------- The example based on P4080DS platform: Two P4080DS platforms can be used to implement the boot from SRIO or PCIE. @@ -87,26 +87,32 @@ How to use this feature: Please refer to the examples given above. 2. U-Boot image's compilation. - For master, U-Boot image should be generated normally. + For master, U-Boot image should be generated normally. - For example, master U-Boot image used on P4080DS should be compiled with + For example, master U-Boot image used on P4080DS should be compiled with make P4080DS_config. - For slave, U-Boot image should be generated specifically by + For slave, U-Boot image should be generated specifically by make xxxx_SRIO_PCIE_BOOT_config. - For example, slave U-Boot image used on P4080DS should be compiled with + For example, slave U-Boot image used on P4080DS should be compiled with make P4080DS_SRIO_PCIE_BOOT_config. 3. Necessary modifications based on a specific environment. - For a specific environment, the addresses of the slave's U-Boot image, - UCode, ENV stored in master's NorFlash, and any other configurations - can be modified in the file: - include/configs/corenet_ds.h. + For a specific environment, the addresses of the slave's U-Boot image, + UCode, ENV stored in master's NorFlash, and any other configurations + can be modified in the file: + include/configs/corenet_ds.h. 4. Set and save the environment variable "bootmaster" with "SRIO1", "SRIO2" or "PCIE1", "PCIE2", "PCIE3" for master, and then restart it in order to perform the role as a master for boot from SRIO or PCIE. + +NOTE: When the Slave's ENV parameters are stored in Master's NorFlash, + it can fetch them through PCIE or SRIO interface. But the ENV + parameters can not be modified by "saveenv" or other commands under + the Slave's u-boot environment, because the Slave can not erase, + write Master's NorFlash by PCIE or SRIO link. -- 1.7.1

2 10

[U-Boot] Fwd: Your message to U-Boot awaits moderator approval
by Сергей Янович 06 May '13

06 May '13

How long does usually moderation take? ---------- Forwarded message ---------- From: <u-boot-bounces(a)lists.denx.de> Date: 18 February 2013 21:39 Subject: Your message to U-Boot awaits moderator approval To: ynvich(a)gmail.com Your mail to 'U-Boot' with the subject [PATCH] arm: pxa: Add support for ICP DAS LP-8x4x Is being held until the list moderator can review it for approval. The reason it is being held: Post to moderated list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.denx.de/mailman/confirm/u-boot/9c7f34e253b98128a0b73d945a10d78…

6 9

[U-Boot] [PATCH v0] davinci, mmc: Added a delay reading ext CSD register
by Davide Bonfanti 06 May '13

06 May '13

Without this additional delay, some eMMC don't negotiate properly bus width Tested on: - Toshiba THGBM2G8D8FBAIB - Toshiba THGBM4G4D1HBAR - Micron MTFC4GMVEA (the one giving the problem) - Hynix H26M64002BNR - SanDisk SDIN5E1-32G Signed-off-by: Davide Bonfanti <davide.bonfanti(a)bticino.it> --- drivers/mmc/davinci_mmc.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/davinci_mmc.c b/drivers/mmc/davinci_mmc.c index ee8f261..d5a38a7 100644 --- a/drivers/mmc/davinci_mmc.c +++ b/drivers/mmc/davinci_mmc.c @@ -285,8 +285,11 @@ dmmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct mmc_data *data) */ if (bytes_left > fifo_bytes) dmmc_wait_fifo_status(regs, 0x4a); - else if (bytes_left == fifo_bytes) + else if (bytes_left == fifo_bytes) { dmmc_wait_fifo_status(regs, 0x40); + if (cmd->cmdidx == MMC_CMD_SEND_EXT_CSD) + udelay(600); + } for (i = 0; bytes_left && (i < fifo_words); i++) { cmddata = get_val(&regs->mmcdrr); -- 1.7.9.5 Ce message, ainsi que tous les fichiers joints à ce message, peuvent contenir des informations sensibles et/ ou confidentielles ne devant pas être divulguées. Si vous n'êtes pas le destinataire de ce message (ou que vous recevez ce message par erreur), nous vous remercions de le notifier immédiatement à son expéditeur, et de détruire ce message. Toute copie, divulgation, modification, utilisation ou diffusion, non autorisée, directe ou indirecte, de tout ou partie de ce message, est strictement interdite. This e-mail, and any document attached hereby, may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized, direct or indirect, copying, disclosure, distribution or other use of the material or parts thereof is strictly forbidden.

3 2