[U-Boot] Pull request - microblaze
Dear Wolfgang, please pull the following changes to your tree. Thanks, Michal The following changes since commit bfc7bea6adc46e1db2f5a5e3464d7652ed67c864: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-x86 are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git master Michal Simek (3): microblaze: Fix microblaze-generic config file microblaze: Add support for NET_MULTI api microblaze: Support little-endian microblaze target Stephan Linz (2): microblaze: generic: adding DHCP support microblaze: generic: rename MTD partition set to 'flash-0' arch/microblaze/cpu/start.S| 60 +- arch/microblaze/include/asm/byteorder.h|4 + arch/microblaze/lib/board.c| 12 +- .../xilinx/microblaze-generic/microblaze-generic.c | 13 + include/configs/microblaze-generic.h | 236 +++- 5 files changed, 207 insertions(+), 118 deletions(-) -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] drivers/net/at91_emac.c: increase timeout for autonegotiation
Dear Ben Warren, > Applied to net repo. OOPS, I already caught them in the AT91 repo and they are on the way to mainstream already. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request - net
Wolfgang, The following changes since commit bfc7bea6adc46e1db2f5a5e3464d7652ed67c864: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-x86 are available in the git repository at: git://git.denx.de/u-boot-net.git master Andreas Bießmann (2): drivers/net/at91_emac.c: increase timeout for autonegotiation drivers/net/at91_emac.c: change return values Ben Gardiner (1): davinci_emac: davinci_eth_set_mac_addr to ->write_hwaddr Ben Warren (1): Net: Remove redundant CONFIG_NET_MULTI directives Ilya Yanok (1): mpc5xxx_fec: add call to reset_phy() after PHY initialization Joakim Tjernlund (4): net: Fix faulty definition of uec_initialize() UEC: Don't udelay needlessly UEC PHY: Remove strange 0.5 sec delay UEC PHY: Speed up initial PHY neg. Michal Simek (2): net: Fix emaclite driver to support little-endian microblaze net: Move Emaclite to NET_MULTI Peter Tyser (1): rarp: Condtionally compile rarp support Reinhard Meyer (1): NET: add ENC28J60 driver using SPI framework Reinhard Meyer (-VC) (1): NET: move legacy enc28j60.c to sidetrack as enc28j60_lpc2292.c Thomas Chou (1): smc9: add write_hwaddr arch/arm/include/asm/arch-davinci/emac_defs.h |1 - arch/arm/lib/board.c | 19 - board/davinci/common/misc.c | 41 +- board/davinci/common/misc.h |2 +- board/davinci/da8xxevm/da830evm.c | 12 +- board/davinci/dm365evm/dm365evm.c |2 +- board/davinci/dvevm/dvevm.c |2 +- board/davinci/sffsdr/sffsdr.c |2 +- board/davinci/sonata/sonata.c |2 +- common/cmd_net.c |2 + drivers/net/Makefile |1 + drivers/net/at91_emac.c | 20 +- drivers/net/davinci_emac.c| 80 +- drivers/net/enc28j60.c| 1548 - drivers/net/enc28j60.h| 251 drivers/net/enc28j60_lpc2292.c| 983 drivers/net/mpc5xxx_fec.c |7 + drivers/net/smc9.c| 40 +- drivers/net/xilinx_emaclite.c | 88 +- drivers/qe/uec.c |4 +- drivers/qe/uec_phy.c | 10 +- include/config_cmd_all.h |1 + include/configs/SMN42.h |2 +- include/configs/lpc2292sodimm.h |2 +- include/netdev.h |4 +- net/Makefile |2 +- net/eth.c | 16 +- net/net.c | 11 +- 28 files changed, 2192 insertions(+), 963 deletions(-) create mode 100644 drivers/net/enc28j60.h create mode 100644 drivers/net/enc28j60_lpc2292.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] net: Move Emaclite to NET_MULTI
Hi Michal, On 10/10/2010 6:41 PM, Michal Simek wrote: > Emaclite was using old net api that's why > this patch move emaclite to NET_MULTI api. > > Signed-off-by: Michal Simek > CC: Ben Warren > > --- > > v2: Pass base_addr as parameter > > v1: Initial version > --- > drivers/net/xilinx_emaclite.c | 84 > +++-- > include/netdev.h |1 + > 2 files changed, 48 insertions(+), 37 deletions(-) Applied to net repo. thanks, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: Fix emaclite driver to support little-endian microblaze
Hi Michal,
On 10/10/2010 6:41 PM, Michal Simek wrote:
> Support New emaclite AXI IP.
>
> Signed-off-by: Michal Simek
> CC: Ben Warren
> ---
> drivers/net/xilinx_emaclite.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
> index 455ce0c..76af939 100644
> --- a/drivers/net/xilinx_emaclite.c
> +++ b/drivers/net/xilinx_emaclite.c
> @@ -309,7 +309,7 @@ static int emaclite_recv(struct eth_device *dev)
> #endif
> }
> /* Get the length of the frame that arrived */
> - switch(((in_be32 (baseaddress + XEL_RXBUFF_OFFSET + 0xC))&
> + switch(((ntohl(in_be32 (baseaddress + XEL_RXBUFF_OFFSET + 0xC)))&
> 0x )>> 16) {
> case 0x806:
> length = 42 + 20; /* FIXME size of ARP */
> @@ -317,7 +317,7 @@ static int emaclite_recv(struct eth_device *dev)
> break;
> case 0x800:
> length = 14 + 14 +
> - (((in_be32 (baseaddress + XEL_RXBUFF_OFFSET + 0x10))&
> + (((ntohl(in_be32 (baseaddress + XEL_RXBUFF_OFFSET +
> 0x10)))&
> 0x)>> 16); /* FIXME size of IP packet */
> debug ("IP Packet\n");
> break;
Applied to net repo.
thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] drivers/net/at91_emac.c: change return values
HI Andreas, On 10/7/2010 12:44 AM, Andreas Bießmann wrote: > Some return values pretended correct pass. This patch changes them according > to README.drivers.net. This patch changes e.g. command 'dhcp' to stop after > errorneous autonegotiation. > > Signed-off-by: Andreas Bießmann > --- > drivers/net/at91_emac.c | 18 +- > 1 files changed, 9 insertions(+), 9 deletions(-) Applied to net repo. thanks, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] drivers/net/at91_emac.c: increase timeout for autonegotiation
Hi Andreas,
On 10/7/2010 12:44 AM, Andreas Bießmann wrote:
> This patch increases timeout for autonegotiation from 1 second to 3 seconds.
> Some boards (e.g. at91rm9200ek) did not negotiate within 1 second.
>
> Signed-off-by: Andreas Bießmann
> ---
> drivers/net/at91_emac.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/at91_emac.c b/drivers/net/at91_emac.c
> index ca2b16b..4626398 100644
> --- a/drivers/net/at91_emac.c
> +++ b/drivers/net/at91_emac.c
> @@ -220,7 +220,7 @@ static int at91emac_phy_reset(struct eth_device *netdev)
> at91emac_write(emac, CONFIG_DRIVER_AT91EMAC_PHYADDR, MII_BMCR,
> (BMCR_ANENABLE | BMCR_ANRESTART));
>
> - for (i = 0; i< 10 / 100; i++) {
> + for (i = 0; i< 3; i++) {
> at91emac_read(emac, CONFIG_DRIVER_AT91EMAC_PHYADDR,
> MII_BMSR,&status);
> if (status& BMSR_ANEGCOMPLETE)
Applied to net repo.
thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] smc91111: add write_hwaddr
Hi Thomas, On 10/5/2010 6:16 PM, Thomas Chou wrote: > Add smc_write_hwaddr() to set mac address. > Clear dev before use. > > Signed-off-by: Thomas Chou > --- > drivers/net/smc9.c | 40 > 1 files changed, 24 insertions(+), 16 deletions(-) Applied to net repo. thanks, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] rarp: Condtionally compile rarp support
Hi Peter, On 9/30/2010 9:25 AM, Peter Tyser wrote: > Most people don't use the 'rarpboot' command, so only enable it when > CONFIG_CMD_RARP is defined. > > Signed-off-by: Peter Tyser > --- > common/cmd_net.c |2 ++ > include/config_cmd_all.h |1 + > net/Makefile |2 +- > net/net.c| 11 +-- > 4 files changed, 13 insertions(+), 3 deletions(-) Applied to net repo. thanks, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 1/2][NEXT] davinci_emac: davinci_eth_set_mac_addr to ->write_hwaddr
Hi Ben, On 9/23/2010 6:58 AM, Ben Gardiner wrote: > This patch proposes to migrate the davinci_emac driver to using the > eth_device->write_hwaddr function pointer as suggested by Ben Warren. > > All the davinci boards had the behaviour, prior to this patch, of > sync'ing the environment variable enetaddr with the MAC address read > from non-volatile storage on boot -- when the two locations disagreed, > the environment variable value took precendence. This patch keeps the > same behaviour but lets eth_initialize take care of it. > > This patch refactors davinci_emac setup in the boards so that the MAC > address is read from non-volatile storage into the environment variable > and then the environment variable value is use in eth_intialize. The > only exception is the direct call to davinci_eth_set_mac_addr made by > the da830evm board init which was changed into an assignment of the > enetaddr field. > > Signed-off-by: Ben Gardiner > Tested-by: Nick Thompson > CC: Ben Warren > Added to net repo. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc5xxx_fec: add call to reset_phy() after PHY initialization
Hi Ilya, On 8/19/2010 2:09 AM, Ilya Yanok wrote: > Some boards need their board-specific PHY quirks to be called > to PHY to work normally. As mpc5xxx_fec driver uses on demand > PHY initialization and can even reinit PHY during normal operation > we can't count on reset_phy() call from arch//lib/board.c > (it is most likely called _before_ we init the PHY from the > driver) so we need to add call to reset_phy() directly in the > driver. > > Cc: Ben Warren > Signed-off-by: Ilya Yanok > --- > drivers/net/mpc5xxx_fec.c |7 +++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/drivers/net/mpc5xxx_fec.c b/drivers/net/mpc5xxx_fec.c > index c88e596..bc8c922 100644 > --- a/drivers/net/mpc5xxx_fec.c > +++ b/drivers/net/mpc5xxx_fec.c > @@ -250,6 +250,13 @@ static int mpc5xxx_fec_init(struct eth_device *dev, bd_t > * bis) > mpc5xxx_fec_init_phy(dev, bis); > > /* > + * Call board-specific PHY fixups (if any) > + */ > +#ifdef CONFIG_RESET_PHY_R > + reset_phy(); > +#endif > + > + /* >* Initialize RxBD/TxBD rings >*/ > mpc5xxx_fec_rbd_init(fec); Applied to net repo. Please accept my sincere apologies for taking so long to process. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request u-boot-marvell.git
Hi Wolfgang/Tom Pls pull The following changes since commit d778a2fbb360530395dfbc0dbe1f80b7bf959028: Albert Aribaud (1): orion5x: fix relocation-incompatible code are available in the git repository at: u-boot-marvell.git master branch Albert Aribaud (2): mvsata_ide: adjust port init sequence orion5x: optimize window size computation Prafulla Wadaskar (4): Kirkwood: print_cpuinfo fixed for valid devid revid Kirkwood: dram_init is moved to dram.c kirkwood: added common config file mv-common.h Kirkwood: Changes specific to ARM relocation support arch/arm/cpu/arm926ejs/kirkwood/cpu.c | 34 +++- arch/arm/cpu/arm926ejs/kirkwood/dram.c | 38 arch/arm/cpu/arm926ejs/orion5x/cpu.c| 32 ++- arch/arm/include/asm/arch-kirkwood/cpu.h|2 + board/Marvell/guruplug/guruplug.c | 11 - board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c | 11 - board/Marvell/openrd_base/openrd_base.c | 11 - board/Marvell/rd6281a/rd6281a.c | 11 - board/Marvell/sheevaplug/sheevaplug.c | 11 - drivers/block/mvsata_ide.c | 42 - include/configs/guruplug.h | 103 +-- include/configs/keymile-common.h|1 + include/configs/mv-common.h | 230 +++ include/configs/mv88f6281gtw_ge.h | 120 ++--- include/configs/openrd_base.h | 146 +-- include/configs/rd6281a.h | 101 +- include/configs/sheevaplug.h| 104 +-- 17 files changed, 389 insertions(+), 619 deletions(-) create mode 100644 include/configs/mv-common.h Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] user-space ===>> U-Boot ====>> user-space ?
Dear bosmith, In message <29939469.p...@talk.nabble.com> you wrote: > > Is there a simple way to send data from a Linux user-space program to > U-Boot? > How about from U-Boot up to a user-space program? I know of two communication methods: Using the environment (and fw_printenv/fw_setenv in Linux user space), and using a shared log buffer (which may be a bit difficult to read / process in U-Boot if that should be needed). > The data may change often enough that using fw_printenv and fw_setenv might > wear out the NAND storage area for the environment. Then put all this stuff in a UBI partition, and use the "env import" / "env export" features in U-Boot to access it (or extend the code to handle environment in a UBI partition directly). > The use-case is to have two kernel images, two root file systems, and to let > a user-space application specify which to use and then force a reboot. The > system will not lose power during this reboot. And you think you will switch betweent these two so often that using the environment would wear out the NAND? I think you are too pessimistic. > This seems like a common enough problem. Has anyone solved it before? Most people use the environment for this purpose. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Today is the yesterday you worried about tomorrow. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Driver for RTC (PT7C4338) chip
Dear Jain Priyanka-B32167, In message you wrote: > > Does anyone has any idea if u-boot has support for this chip? If yes, > what is the location of this RTC driver in u-boot? RTC drivers can be found - surprise, surprise - in the drivers/rtc/ directory. The PT7C4338 is currently not supported (unless it should be compatible with any other RTC). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats." - Howard Aiken ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/3] Kirkwood: Changes specific to ARM relocation support
> -Original Message- > From: Prafulla Wadaskar [mailto:prafu...@marvell.com] > Sent: Thursday, October 07, 2010 8:29 PM > To: u-boot@lists.denx.de > Cc: Prabhanjan Sarnaik; Ashish Karkare; Prafulla Wadaskar > Subject: [PATCH V2 3/3] Kirkwood: Changes specific to ARM > relocation support > > All Kirkwood based boards are supported for this new implementation > ref: docs/README.arm-relocation > > Signed-off-by: Prafulla Wadaskar > --- > Changelog: > v2: typo changed in the commit message > Security SRAM used for CONFIG_SYS_INIT_SP_ADDR > > include/configs/mv-common.h |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > Applied to u-boot-marvell.git master branch Regards. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/3] kirkwood: added common config file mv-common.h
> -Original Message- > From: Prafulla Wadaskar [mailto:prafu...@marvell.com] > Sent: Thursday, October 07, 2010 8:29 PM > To: u-boot@lists.denx.de > Cc: Prabhanjan Sarnaik; Ashish Karkare; Prafulla Wadaskar > Subject: [PATCH V2 2/3] kirkwood: added common config file mv-common.h > > It is observed that, in most of the board configs the code is being > duplicated, also for any common change all board files needs update > This issue was under discussion from long on mailing list and we > converge on introducing common config file. > > With this patch- > 1. Total Kirkwood specific configuration code is reduced by 210 lines > 2. All common configuration can be shared by multiple boards > 3. Easy to manage common updates like ARM relocation changes > > mv-common.h file is added to include/configs/ > It contains all common configuration supported for all Kirkwood boards > The respective board configs are updated for its usage > > Build tested for guruplug, mv88f6281gtw_ge, openrd_base, > rd6281a and sheevaplug > Binary execution tested for sheevaplug > > Todo: > 1. Other custom Kirkwood boards to be synced > 2. The support to be extended for Orion5X based boards > > Signed-off-by: Prafulla Wadaskar > --- > Changelog: > v2: patch description updated for s/mv-config/mv-common/ > SATA port configs made board specific > changed IDe typo with IDE > > include/configs/guruplug.h| 103 ++ > include/configs/mv-common.h | 225 > + > include/configs/mv88f6281gtw_ge.h | 120 ++-- > include/configs/openrd_base.h | 146 ++--- > include/configs/rd6281a.h | 101 ++--- > include/configs/sheevaplug.h | 104 +- > 6 files changed, 266 insertions(+), 533 deletions(-) > create mode 100644 include/configs/mv-common.h > Applied to u-boot-marvell.git master branch Regards. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] Kirkwood: dram_init is moved to dram.c
> -Original Message- > From: Prafulla Wadaskar [mailto:prafu...@marvell.com] > Sent: Thursday, October 07, 2010 8:29 PM > To: u-boot@lists.denx.de > Cc: Prabhanjan Sarnaik; Ashish Karkare; Prafulla Wadaskar > Subject: [PATCH V2 1/3] Kirkwood: dram_init is moved to dram.c > > For all Kirkwood boards so far dram_init function is duplicated > dram_init function is moved to dram.c and relevant code from all > board specific files removed > > If any board needs specific dram init handling than standard one, > then, a macro CONFIG_SYS_BOARD_DRAM_INIT should be defined in > board config header file and the dram_init function can be put > in board specific source file > For ex. keymile boards > > Signed-off-by: Prafulla Wadaskar > --- > Changelog > v2: > dram_init only performed for consecutive memory > removed CONFIG_SYS_WITHOUT_RELOC dependency > dram_init_banksize added to avoid re-configuration of dram bank 0 > > arch/arm/cpu/arm926ejs/kirkwood/dram.c | 38 > +++ > board/Marvell/guruplug/guruplug.c | 11 -- > board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c | 11 -- > board/Marvell/openrd_base/openrd_base.c | 11 -- > board/Marvell/rd6281a/rd6281a.c | 11 -- > board/Marvell/sheevaplug/sheevaplug.c | 11 -- > include/configs/keymile-common.h|1 + > 7 files changed, 39 insertions(+), 55 deletions(-) > Applied to u-boot-marvell.git master branch Regards. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] orion5x: optimize window size computation
> -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud > Sent: Thursday, October 07, 2010 12:17 AM > To: u-boot@lists.denx.de > Subject: [U-Boot] [PATCH V3] orion5x: optimize window size computation > > > Signed-off-by: Chris Moore > Signed-off-by: Albert Aribaud > --- > V1Initial submission > V2Double Signed-off-by as requested > V3Fixed unit mistake and moved to standard units > > arch/arm/cpu/arm926ejs/orion5x/cpu.c | 32 > +--- > 1 files changed, 21 insertions(+), 11 deletions(-) > Applied to u-boot-marvell.git master branch Regards. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Kirkwood: print_cpuinfo fixed for valid devid revid
> -Original Message- > From: Prafulla Wadaskar [mailto:prafu...@marvell.com] > Sent: Monday, September 20, 2010 9:40 PM > To: u-boot@lists.denx.de > Cc: Prabhanjan Sarnaik; Ashish Karkare; Prafulla Wadaskar; > Prafulla Wadaskar > Subject: [PATCH v2] Kirkwood: print_cpuinfo fixed for valid > devid revid > > From: Prafulla Wadaskar <[prafu...@marvell.com]> > > Earlier Device Identification register was used to detect > the type for SoC, considering 88F6282 support to be added, > It is not possible to detect the same using current > algorithm. > > With this patch, device ID is being read using PCIE devid > register, also valid chip revision ID will also be read and > displayed > > Signed-off-by: Prafulla Wadaskar > --- > Change log: > v2: Updated as per review comments for V1 > debug replaced by printf, sprintf removed > (??) kept as it is since we dont know future references > for revid > > arch/arm/cpu/arm926ejs/kirkwood/cpu.c| 34 > - > arch/arm/include/asm/arch-kirkwood/cpu.h |2 + > 2 files changed, 25 insertions(+), 11 deletions(-) > Applied to u-boot-marvell.git master branch Regards. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] mvsata_ide: adjust port init sequence
> -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud > Sent: Wednesday, September 08, 2010 11:01 PM > To: u-boot@lists.denx.de > Subject: [U-Boot] [PATCH V3] mvsata_ide: adjust port init sequence > > mvsata_ide_initialize_port(): adjust init sequence (SStatus > should be checked only after all writes to SControl) and > return success/failure to ide_preinit(). > > Also, as some tests showed init durations in the hundreds > of us, raise the time-out to 01 ms to be on the safe side. > > Signed-off-by: Albert Aribaud > --- > PATCH HISTORY > > V1Initial patch. > V2Fixed wrong placement of comment. > Fixed wrong description (was 01 ms, should have been 10). > Added Signed-off-by. > V3Replaced return status values with symbolic names. > Made error status values negative. > Renamed 'tout' to 'timeleft' for clarity. > Replaced ternary '?:' operator with '!' and if. > > Patch was run through checkscript.pl with 0 errors and warnings. > > drivers/block/mvsata_ide.c | 42 > +- > 1 files changed, 33 insertions(+), 9 deletions(-) > Applied to u-boot-marvell.git master branch Regards. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Driver for RTC (PT7C4338) chip
Hi, One of our board has PT7C4338 (Pericom Technology Inc.) as RTC chip. Does anyone has any idea if u-boot has support for this chip? If yes, what is the location of this RTC driver in u-boot? Thanks alot Priyanka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] user-space ===>> U-Boot ====>> user-space ?
Hi Is there a simple way to send data from a Linux user-space program to U-Boot? How about from U-Boot up to a user-space program? The data may change often enough that using fw_printenv and fw_setenv might wear out the NAND storage area for the environment. The use-case is to have two kernel images, two root file systems, and to let a user-space application specify which to use and then force a reboot. The system will not lose power during this reboot. This seems like a common enough problem. Has anyone solved it before? -- View this message in context: http://old.nabble.com/user-space--%3D%3D%3D%3E%3E--U-Boot--%3D%3D%3D%3D%3E%3E--user-space---tp29939469p29939469.html Sent from the Uboot - Users 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] Testing Data Cache for armv7 (beagleboard)
Thanks for the replies. I didn't realize that the MMC module was operating in 1-bit mode inside U-boot. I'll concentrate on looking at that. Has anybody done any work to try and get 4-bit mode working for OMAP3 in U-boot? Thanks, Chris On Thu, Oct 7, 2010 at 1:04 PM, Wolfgang Denk wrote: > Dear chris c, > > In message > > > you wrote: > > > > I was comparing time just by timing it manually. How did you instrument > > u-boot to display the time? > > That's no instrumentation of U-Boot, but just timestamping the output > on the serial console. See for example > ftp://ftp.denx.de/pub/tools/time_log > > > As for the small versus large file, I did the same test for 1MB of data > > using nand read and saw a x4 performance advantage. I also did a test on > > mmc with 100 MB file and saw no performance increase. Looks like file > size > > doesn't matter. > > > > So does that mean that MMC file loading will not benefit from dcache > > enabled? Can anybody explain this? > > It depends on where the time is actually spent. If you have a slow > (say, bit-banging) MMC driver and a low-performance CPU then the > transfer from MMC might simply not depend as much on caches. It is > wrong to check just a simple use case. Try a number of different > operations, like umcompressing a large image in RAM or from NOR to > RAM, or downloading over the net, or ... > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > "Remember, Information is not knowledge; Knowledge is not Wisdom; > Wisdom is not truth; Truth is not beauty; Beauty is not love; Love is > not music; Music is the best." - Frank Zappa > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: fix 837x MDS PCI HOST build
On Thu, 30 Sep 2010 13:40:34 -0500 Kim Phillips wrote: > commit 6aa3d3bfaa986f1aff5e21a9b9f68d087715b1a9 > "83xx: Remove warmboot parameter from PCI init functions" missed > one mpc83xx_pcie_init callsite, causing this build error: > > Configuring for MPC837XEMDS_HOST board... > pci.c: In function 'pci_init_board': > pci.c:141: error: too many arguments to function 'mpc83xx_pcie_init' > > this patch extends the commit to include that callsite. > > Signed-off-by: Kim Phillips > --- applied to u-boot-mpc83xx master. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot] MPC8360E ATM Quad OC3 External Phys u-boot patch
On Mon, 11 Oct 2010 15:41:44 +0100 Popa Stefan-R89990 wrote: Hello Stefan Popa, > Attached you can find the patch for it. It doesn't apply: $ git am 358 Patch is empty. Was it split wrong? If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". $ patch -p1 < 358 patch: Only garbage was found in the patch input. $ Most likely because it's an attachment, which also makes reviewing with inline responses more difficult: please re-review the instructions on how to submit a patch: http://www.denx.de/wiki/U-Boot/Patches and resubmit. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] OMAP3: Add support for the OMAP3 IGEP module.
The IGEP module is a low-power, high performance production-ready system-on-module (SOM) based on TI's OMAP3 family.The IGEP module solution based upon TI OMAP3 provides a low-power/low-cost platform for a variety of consumer/industrial/medical devices. Signed-off-by: Enric Balletbo i Serra --- MAINTAINERS|1 + MAKEALL|1 + board/isee/igep0030/Makefile | 49 + board/isee/igep0030/config.mk | 34 +++ board/isee/igep0030/igep0030.c | 71 + board/isee/igep0030/igep0030.h | 147 +++ boards.cfg |1 + include/configs/igep0030.h | 215 8 files changed, 519 insertions(+), 0 deletions(-) create mode 100644 board/isee/igep0030/Makefile create mode 100644 board/isee/igep0030/config.mk create mode 100644 board/isee/igep0030/igep0030.c create mode 100644 board/isee/igep0030/igep0030.h create mode 100644 include/configs/igep0030.h diff --git a/MAINTAINERS b/MAINTAINERS index 99728ae..5581080 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -821,6 +821,7 @@ Alex Z Enric Balletbo i Serra igep0020ARM ARMV7 (OMAP3xx SoC) + igep0030ARM ARMV7 (OMAP3xx SoC) - diff --git a/MAKEALL b/MAKEALL index 78dce8b..a241181 100755 --- a/MAKEALL +++ b/MAKEALL @@ -491,6 +491,7 @@ LIST_ARMV7="\ am3517_evm \ devkit8000 \ igep0020\ + igep0030\ mx51evk \ omap3_beagle\ omap3_overo \ diff --git a/board/isee/igep0030/Makefile b/board/isee/igep0030/Makefile new file mode 100644 index 000..cfc0411 --- /dev/null +++ b/board/isee/igep0030/Makefile @@ -0,0 +1,49 @@ +# +# (C) Copyright 2000, 2001, 2002 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := igep0030.o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/isee/igep0030/config.mk b/board/isee/igep0030/config.mk new file mode 100644 index 000..35865e0 --- /dev/null +++ b/board/isee/igep0030/config.mk @@ -0,0 +1,34 @@ +# +# (C) Copyright 2009 +# ISEE 2007 SL, +# +# IGEP0030 uses OMAP3 (ARM-CortexA8) cpu +# see http://www.ti.com/ for more information on Texas Instruments +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# +# Physical Address: +# 8000' (bank0) +# A000/ (bank1) +# Linux-Kernel is expected to be at 8000'8000, entry 8000'8000 +# (mem base + reserved) + +# For use with external or internal boots. +TEXT_BASE = 0x80008000 + diff --git a/board/isee/igep0030/igep0030.c b/board/isee/igep0030/igep0030.c new file mode 100644 index 000..9244259 --- /dev/null +++ b/board/isee/igep0030/igep0030.c @@ -0,0 +1,71 @@ +/* + * (C) Copyright 2010 + * ISEE 2007 SL, + * + * See file C
[U-Boot] [PATCH 0/1] Add support for the OMAP3 IGEP module
Hello, This is the first version of patch series to add initial support for OMAP3 IGEP module. Please, consider to add in next merge window. Thanks. $ git diff --stat origin/master MAINTAINERS|1 + MAKEALL|1 + board/isee/igep0030/Makefile | 49 + board/isee/igep0030/config.mk | 34 +++ board/isee/igep0030/igep0030.c | 71 + board/isee/igep0030/igep0030.h | 147 +++ boards.cfg |1 + include/configs/igep0030.h | 215 8 files changed, 519 insertions(+), 0 deletions(-) Cheers, Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] nand: allow demand initialization
On Mon, 11 Oct 2010 17:02:00 -0400
Mike Frysinger wrote:
> On Monday, October 11, 2010 16:29:41 Scott Wood wrote:
> > On Sun, Oct 10, 2010 at 06:37:40AM -0400, Mike Frysinger wrote:
> > > --- a/common/cmd_nand.c
> > > +++ b/common/cmd_nand.c
> > > @@ -309,6 +309,8 @@
> > >
> > > if (argc < 2)
> > > goto usage;
> > >
> > > + nand_init();
> > > +
> >
> > Also do_nandboot().
>
> does it need to be before the mtdparts init stuff, or can it be in
> nand_load_image() ?
I think before -- the mtdparts init checks whether an mtd device
actually exists. Though in that case, and also for things
like mtdparts.spread, nand_init() should go in mtdparts_init(), and also
nand_load_image() in case mtdparts aren't enabled.
> > > --- a/common/env_nand.c
> > > +++ b/common/env_nand.c
> > > @@ -359,6 +359,8 @@ void env_relocate_spec(void)
> > > return;
> > > }
> > >
> > > + nand_init();
> > > +
> > >
> > > if (readenv(CONFIG_ENV_OFFSET, (u_char *) tmp_env1))
> > > puts("No Valid Environment Area found\n");
> > >
> > > @@ -404,6 +406,8 @@ void env_relocate_spec(void)
> > > free(tmp_env1);
> > > free(tmp_env2);
> > >
> > > +#else
> > > + nand_init();
> > >
> > > #endif /* ! ENV_IS_EMBEDDED */
> >
> > Do we really need to initialize NAND if the environment is embedded, or
> > could it be delayed to when the environment is saved?
>
> the reason i picked env_relocate_spec() is because i'd have to push the init
> into the read/write/save code paths. and those may be executed multiple
> times
> while running. the expectation is that if you're putting the env into nand,
> it's going to get read, so you might as well initialize it.
If it's embedded, then you've already read the env out of NAND by
whatever loaded the U-Boot image. You'd only need to initialize NAND
if you're going to write it back, which is probably not the common
case. In fact, I'm not sure when I'd use embedded-env with NAND at all
unless the environment's completely read-only and thus can share an
erase block with the u-boot image.
OTOH, I'm fine with leaving that as a future refinement for someone who
is using embedded-env with NAND and cares about the boot time it adds.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] nand: allow demand initialization
On Monday, October 11, 2010 16:29:41 Scott Wood wrote:
> On Sun, Oct 10, 2010 at 06:37:40AM -0400, Mike Frysinger wrote:
> > --- a/common/cmd_nand.c
> > +++ b/common/cmd_nand.c
> > @@ -309,6 +309,8 @@
> >
> > if (argc < 2)
> > goto usage;
> >
> > + nand_init();
> > +
>
> Also do_nandboot().
does it need to be before the mtdparts init stuff, or can it be in
nand_load_image() ?
> > --- a/common/env_nand.c
> > +++ b/common/env_nand.c
> > @@ -359,6 +359,8 @@ void env_relocate_spec(void)
> > return;
> > }
> >
> > + nand_init();
> > +
> >
> > if (readenv(CONFIG_ENV_OFFSET, (u_char *) tmp_env1))
> > puts("No Valid Environment Area found\n");
> >
> > @@ -404,6 +406,8 @@ void env_relocate_spec(void)
> > free(tmp_env1);
> > free(tmp_env2);
> >
> > +#else
> > + nand_init();
> >
> > #endif /* ! ENV_IS_EMBEDDED */
>
> Do we really need to initialize NAND if the environment is embedded, or
> could it be delayed to when the environment is saved?
the reason i picked env_relocate_spec() is because i'd have to push the init
into the read/write/save code paths. and those may be executed multiple times
while running. the expectation is that if you're putting the env into nand,
it's going to get read, so you might as well initialize it.
-mike
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
[U-Boot] Pull request: nand flash
The following changes since commit bfc7bea6adc46e1db2f5a5e3464d7652ed67c864: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-x86 are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master Ben Gardiner (5): mtdparts: regroup calls to get_mtd_device_nm mtd: add an mtd method for get_len_incl_bad() mtdparts: show net size in mtdparts list mtdparts: add new sub-command "spread" mtdparts: new add.spread: add part skipping bad blocks Enric Balletbo i Serra (1): mtd: OneNAND: add support for OneNAND manufactured by Numonyx Scott Wood (7): nand util: read/write: accept unaligned length cmd_nand: some infrastructure fixes and refactoring nand erase: .spread, .part, .chip subcommands nand commands: make only "dump" repeatable. nand: remove dead code and suspend/resume Followup fixes on the mtdparts spread patchset README: Add new NAND env features README | 32 +++- common/cmd_mtdparts.c | 261 common/cmd_nand.c | 339 +++- drivers/mtd/mtdcore.c | 44 + drivers/mtd/mtdpart.c | 16 -- drivers/mtd/nand/nand_base.c | 245 +-- drivers/mtd/nand/nand_bbt.c| 19 -- drivers/mtd/nand/nand_ecc.c| 17 -- drivers/mtd/nand/nand_util.c | 159 +- drivers/mtd/onenand/onenand_base.c |1 + include/linux/mtd/mtd.h|8 +- include/linux/mtd/onenand.h|1 + include/nand.h |7 +- 13 files changed, 606 insertions(+), 543 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] nand: allow demand initialization
On Sun, Oct 10, 2010 at 06:37:40AM -0400, Mike Frysinger wrote:
> diff --git a/common/cmd_nand.c b/common/cmd_nand.c
> index 3f1d077..e0be7e5 100644
> --- a/common/cmd_nand.c
> +++ b/common/cmd_nand.c
> @@ -309,6 +309,8 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char *
> const argv[])
> if (argc < 2)
> goto usage;
>
> + nand_init();
> +
> if (quiet_str)
> quiet = simple_strtoul(quiet_str, NULL, 0) != 0;
>
Also do_nandboot().
> diff --git a/common/env_nand.c b/common/env_nand.c
> index 4e8307a..3dffebd 100644
> --- a/common/env_nand.c
> +++ b/common/env_nand.c
> @@ -359,6 +359,8 @@ void env_relocate_spec(void)
> return;
> }
>
> + nand_init();
> +
> if (readenv(CONFIG_ENV_OFFSET, (u_char *) tmp_env1))
> puts("No Valid Environment Area found\n");
>
> @@ -404,6 +406,8 @@ void env_relocate_spec(void)
> free(tmp_env1);
> free(tmp_env2);
>
> +#else
> + nand_init();
> #endif /* ! ENV_IS_EMBEDDED */
Do we really need to initialize NAND if the environment is embedded, or
could it be delayed to when the environment is saved?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv4 1/3] mtd: OneNAND: add support for OneNAND manufactured by Numonyx
On Mon, Oct 11, 2010 at 09:48:03PM +0200, Enric Balletbo i Serra wrote: > This patch adds the Numonyx manufacturer code (0x20) to > onenand manufacturers. > > Signed-off-by: Enric Balletbo i Serra > Acked-by: Kyungmin Park > Acked-by: Steve Sakoman > Tested-by: Steve Sakoman > --- > drivers/mtd/onenand/onenand_base.c |1 + > include/linux/mtd/onenand.h|1 + > 2 files changed, 2 insertions(+), 0 deletions(-) Applied to u-boot-nand-flash. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] OMAP3: Add support for the IGEP v2 board.
Sorry, this is the version 4 2010/10/11 Enric Balletbo i Serra : > The IGEP v2 board is a low-cost, fan-less and industrial temperature > range single board computer that unleashes laptop-like performance and > expandability without the bulk, expense, or noise of typical desktop > machines. Its architecture shares much in common with other OMAP3 boards. > > Signed-off-by: Enric Balletbo i Serra > Acked-by: Steve Sakoman > Tested-by: Steve Sakoman > --- > MAINTAINERS | 4 + > MAKEALL | 1 + > board/isee/igep0020/Makefile | 49 + > board/isee/igep0020/config.mk | 33 ++ > board/isee/igep0020/igep0020.c | 129 ++ > board/isee/igep0020/igep0020.h | 156 +++ > boards.cfg | 1 + > include/configs/igep0020.h | 228 > > 8 files changed, 601 insertions(+), 0 deletions(-) > create mode 100644 board/isee/igep0020/Makefile > create mode 100644 board/isee/igep0020/config.mk > create mode 100644 board/isee/igep0020/igep0020.c > create mode 100644 board/isee/igep0020/igep0020.h > create mode 100644 include/configs/igep0020.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index e003226..99728ae 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -818,6 +818,10 @@ Alex Z > lart SA1100 > dnp1110 SA1110 > > +Enric Balletbo i Serra > + > + igep0020 ARM ARMV7 (OMAP3xx SoC) > + > - > > Unknown / orphaned boards: > diff --git a/MAKEALL b/MAKEALL > index 1b506d6..78dce8b 100755 > --- a/MAKEALL > +++ b/MAKEALL > @@ -490,6 +490,7 @@ LIST_ARM11=" \ > LIST_ARMV7=" \ > am3517_evm \ > devkit8000 \ > + igep0020 \ > mx51evk \ > omap3_beagle \ > omap3_overo \ > diff --git a/board/isee/igep0020/Makefile b/board/isee/igep0020/Makefile > new file mode 100644 > index 000..2f11879 > --- /dev/null > +++ b/board/isee/igep0020/Makefile > @@ -0,0 +1,49 @@ > +# > +# (C) Copyright 2000, 2001, 2002 > +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. > +# > +# See file CREDITS for list of people who contributed to this > +# project. > +# > +# This program is free software; you can redistribute it and/or > +# modify it under the terms of the GNU General Public License as > +# published by the Free Software Foundation; either version 2 of > +# the License, or (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, > +# MA 02111-1307 USA > +# > + > +include $(TOPDIR)/config.mk > + > +LIB = $(obj)lib$(BOARD).a > + > +COBJS := igep0020.o > + > +SRCS := $(COBJS:.o=.c) > +OBJS := $(addprefix $(obj),$(COBJS)) > + > +$(LIB): $(obj).depend $(OBJS) > + $(AR) $(ARFLAGS) $@ $(OBJS) > + > +clean: > + rm -f $(OBJS) > + > +distclean: clean > + rm -f $(LIB) core *.bak $(obj).depend > + > +# > + > +# defines $(obj).depend target > +include $(SRCTREE)/rules.mk > + > +sinclude $(obj).depend > + > +# > diff --git a/board/isee/igep0020/config.mk b/board/isee/igep0020/config.mk > new file mode 100644 > index 000..b8812f9 > --- /dev/null > +++ b/board/isee/igep0020/config.mk > @@ -0,0 +1,33 @@ > +# > +# (C) Copyright 2009 > +# ISEE 2007 SL, > +# > +# IGEP0020 uses OMAP3 (ARM-CortexA8) cpu > +# see http://www.ti.com/ for more information on Texas Instruments > +# > +# See file CREDITS for list of people who contributed to this > +# project. > +# > +# This program is free software; you can redistribute it and/or > +# modify it under the terms of the GNU General Public License as > +# published by the Free Software Foundation; either version 2 of > +# the License, or (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, > +# MA 02111-1307 USA > +# > +# Physical
[U-Boot] [PATCH 3/3] OMAP3: Add support for the IGEP v2 board.
The IGEP v2 board is a low-cost, fan-less and industrial temperature range single board computer that unleashes laptop-like performance and expandability without the bulk, expense, or noise of typical desktop machines. Its architecture shares much in common with other OMAP3 boards. Signed-off-by: Enric Balletbo i Serra Acked-by: Steve Sakoman Tested-by: Steve Sakoman --- MAINTAINERS|4 + MAKEALL|1 + board/isee/igep0020/Makefile | 49 + board/isee/igep0020/config.mk | 33 ++ board/isee/igep0020/igep0020.c | 129 ++ board/isee/igep0020/igep0020.h | 156 +++ boards.cfg |1 + include/configs/igep0020.h | 228 8 files changed, 601 insertions(+), 0 deletions(-) create mode 100644 board/isee/igep0020/Makefile create mode 100644 board/isee/igep0020/config.mk create mode 100644 board/isee/igep0020/igep0020.c create mode 100644 board/isee/igep0020/igep0020.h create mode 100644 include/configs/igep0020.h diff --git a/MAINTAINERS b/MAINTAINERS index e003226..99728ae 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -818,6 +818,10 @@ Alex Z lartSA1100 dnp1110 SA1110 +Enric Balletbo i Serra + + igep0020ARM ARMV7 (OMAP3xx SoC) + - Unknown / orphaned boards: diff --git a/MAKEALL b/MAKEALL index 1b506d6..78dce8b 100755 --- a/MAKEALL +++ b/MAKEALL @@ -490,6 +490,7 @@ LIST_ARM11="\ LIST_ARMV7=" \ am3517_evm \ devkit8000 \ + igep0020\ mx51evk \ omap3_beagle\ omap3_overo \ diff --git a/board/isee/igep0020/Makefile b/board/isee/igep0020/Makefile new file mode 100644 index 000..2f11879 --- /dev/null +++ b/board/isee/igep0020/Makefile @@ -0,0 +1,49 @@ +# +# (C) Copyright 2000, 2001, 2002 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := igep0020.o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/isee/igep0020/config.mk b/board/isee/igep0020/config.mk new file mode 100644 index 000..b8812f9 --- /dev/null +++ b/board/isee/igep0020/config.mk @@ -0,0 +1,33 @@ +# +# (C) Copyright 2009 +# ISEE 2007 SL, +# +# IGEP0020 uses OMAP3 (ARM-CortexA8) cpu +# see http://www.ti.com/ for more information on Texas Instruments +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# +# Physical Address: +# 8000' (bank0) +# A000/ (bank1) +# Linux-Kernel is expected to be at 8000'8000, entry 8000'8000 +# (mem base + reserved) + +# For use with external or internal boots. +TEXT_BASE = 0x80008000 diff --git a/board/isee/igep0020/igep0020.c b/board/isee/igep0020/igep0020.c new file mode 100644 index 000..3f7eda1 -
[U-Boot] [PATCHv4 2/3] OMAP3: SDRC: Introduce Numonyx DDR type
Introduce Numonyx DDR timings and provide CONFIG_OMAP3_NUMONYX_DDR
config options to allow for platform files to setup their timings.
Signed-off-by: Enric Balletbo i Serra
Acked-by: Steve Sakoman
Tested-by: Steve Sakoman
---
arch/arm/include/asm/arch-omap3/mem.h | 43 +
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap3/mem.h
b/arch/arm/include/asm/arch-omap3/mem.h
index a78cf9f..f165949 100644
--- a/arch/arm/include/asm/arch-omap3/mem.h
+++ b/arch/arm/include/asm/arch-omap3/mem.h
@@ -128,6 +128,45 @@ enum {
(MICRON_XSR_165 << 0) | (MICRON_TXP_165 << 8) | \
(MICRON_TWTR_165 << 16))
+/*
+ * NUMONYX part of IGEP v2 (165MHz optimized) 6.06ns
+ * ACTIMA
+ * TDAL = Twr/Tck + Trp/tck = 15/6 + 18/6 = 2.5 + 3 = 5.5 -> 6
+ * TDPL (Twr) = 15/6 = 2.5 -> 3
+ * TRRD = 12/6 = 2
+ * TRCD = 22.5/6 = 3.75 -> 4
+ * TRP = 18/6 = 3
+ * TRAS = 42/6 = 7
+ * TRC = 60/6 = 10
+ * TRFC = 140/6 = 23.3 -> 24
+ * ACTIMB
+ * TWTR = 2
+ * TCKE = 2
+ * TXSR = 200/6 = 33.3 -> 34
+ * TXP = 1.0 + 1.1 = 2.1 -> 3
+ */
+#define NUMONYX_TDAL_165 6
+#define NUMONYX_TDPL_165 3
+#define NUMONYX_TRRD_165 2
+#define NUMONYX_TRCD_165 4
+#define NUMONYX_TRP_1653
+#define NUMONYX_TRAS_165 7
+#define NUMONYX_TRC_165 10
+#define NUMONYX_TRFC_165 24
+#define NUMONYX_V_ACTIMA_165 ((NUMONYX_TRFC_165 << 27) | \
+ (NUMONYX_TRC_165 << 22) | (NUMONYX_TRAS_165 << 18) | \
+ (NUMONYX_TRP_165 << 15) | (NUMONYX_TRCD_165 << 12) | \
+ (NUMONYX_TRRD_165 << 9) | (NUMONYX_TDPL_165 << 6) | \
+ (NUMONYX_TDAL_165))
+
+#define NUMONYX_TWTR_165 2
+#define NUMONYX_TCKE_165 2
+#define NUMONYX_TXP_1653
+#define NUMONYX_XSR_16534
+#define NUMONYX_V_ACTIMB_165 ((NUMONYX_TCKE_165 << 12) | \
+ (NUMONYX_XSR_165 << 0) | (NUMONYX_TXP_165 << 8) | \
+ (NUMONYX_TWTR_165 << 16))
+
#ifdef CONFIG_OMAP3_INFINEON_DDR
#define V_ACTIMA_165 INFINEON_V_ACTIMA_165
#define V_ACTIMB_165 INFINEON_V_ACTIMB_165
@@ -136,6 +175,10 @@ enum {
#define V_ACTIMA_165 MICRON_V_ACTIMA_165
#define V_ACTIMB_165 MICRON_V_ACTIMB_165
#endif
+#ifdef CONFIG_OMAP3_NUMONYX_DDR
+#define V_ACTIMA_165 NUMONYX_V_ACTIMA_165
+#define V_ACTIMB_165 NUMONYX_V_ACTIMB_165
+#endif
#if !defined(V_ACTIMA_165) || !defined(V_ACTIMB_165)
#error "Please choose the right DDR type in config header"
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv4 1/3] mtd: OneNAND: add support for OneNAND manufactured by Numonyx
This patch adds the Numonyx manufacturer code (0x20) to
onenand manufacturers.
Signed-off-by: Enric Balletbo i Serra
Acked-by: Kyungmin Park
Acked-by: Steve Sakoman
Tested-by: Steve Sakoman
---
drivers/mtd/onenand/onenand_base.c |1 +
include/linux/mtd/onenand.h|1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/onenand/onenand_base.c
b/drivers/mtd/onenand/onenand_base.c
index f9273ab..24e02c2 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -2213,6 +2213,7 @@ char *onenand_print_device_info(int device, int version)
}
static const struct onenand_manufacturers onenand_manuf_ids[] = {
+ {ONENAND_MFR_NUMONYX, "Numonyx"},
{ONENAND_MFR_SAMSUNG, "Samsung"},
};
diff --git a/include/linux/mtd/onenand.h b/include/linux/mtd/onenand.h
index 68e174e..5465562 100644
--- a/include/linux/mtd/onenand.h
+++ b/include/linux/mtd/onenand.h
@@ -154,6 +154,7 @@ struct onenand_chip {
/*
* OneNAND Flash Manufacturer ID Codes
*/
+#define ONENAND_MFR_NUMONYX0x20
#define ONENAND_MFR_SAMSUNG0xec
/**
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv4 0/3] Add support for the IGEP v2 board.
Hello, This is the version 4 of patch series to add initial support for OMAP3 IGEP v2 board. CHANGES: * since v3 - [x/3] add Acked-by and Tested-by lines - [3/3] fix warning in the build: igep0020.c: In function 'board_eth_init': igep0020.c:125: warning: implicit declaration of function 'smc911x_initialize' * since v2 - [1/3] keep lists sorted - [2/3] fix multiline comment style - [3/3] add entry to MAINTAINERS * since v1 - [2/3] fix parens in NUMONYX_V_ACTIMB_165 define - [3/3] add extra space after first &ctrl_base in file igep0020.c - [3/3] add a space after the 57600 comma in file igep0020.h - [3/3] remove CONFIG_SYS_ARM_WITHOUT_RELOC undef $ git diff --stat origin/master MAINTAINERS |4 + MAKEALL |1 + arch/arm/include/asm/arch-omap3/mem.h | 43 ++ board/isee/igep0020/Makefile | 49 +++ board/isee/igep0020/config.mk | 33 + board/isee/igep0020/igep0020.c| 129 +++ board/isee/igep0020/igep0020.h| 156 ++ boards.cfg|1 + drivers/mtd/onenand/onenand_base.c|1 + include/configs/igep0020.h| 228 + include/linux/mtd/onenand.h |1 + 11 files changed, 646 insertions(+), 0 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] mkconfig: change CONFIG_MK_ prefix into plain CONFIG_
On Monday, October 11, 2010 05:45:09 Wolfgang Denk wrote: > board/bf527-ezkit/video.c | 10 +- > include/configs/bf527-ezkit.h |2 +- these look fine ... were you going to update boards.cfg too ? this was the only reason the bf527-ezkit-v2 target exists in the top level Makefile ... -mike 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] [WIP] tools/env: cleanup host build flags
On Mon, 11 Oct 2010 18:06:46 +0200 Daniel Hobi wrote: > Hi Scott, > > In commit d984fed0 (makefiles: fixes for building build tools), > you suggest that using $(CC) with host flags (HOSTCFLAGS, etc) > is the correct way to use the cross compiler to generate binaries > for a hosted environment on the target. > > On the other hand, you use $(HOSTCC) to generate the .depend file > in rules.mk which leads to wrong dependencies. > > I think we need to differentiate three cases: > - (free-standing) U-Boot: use CC and CFLAGS > - native tools (mkimage, etc): use HOSTCC and HOSTCFLAGS > - Linux environment on the target (imls, fw_printenv): > >Can we use CC and HOSTCFLAGS, or do we need a third set of >variables for flags? > >If reusing HOSTCFLAGS: how do we fix dependency generation? I don't know if a separate set of flags is needed, but we probably want separate OBJS/SRCS lists. The dependencies are going to be different based on which toolchain you use, even if the flags are the same. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv3 0/3] Add support for the IGEP v2 board.
On Mon, Oct 11, 2010 at 10:02 AM, Enric Balletbò i Serra wrote: > Hello, > > 2010/10/11 Steve Sakoman : >> On Mon, 2010-10-11 at 00:12 +0200, Enric Balletbo i Serra wrote: >>> Hello, >>> >>> This is the version 3 of patch series to add initial support for >>> OMAP3 IGEP v2 board. >>> >>> CHANGES: >>> >>> * since v2 >>> - [1/3] keep lists sorted >>> - [2/3] fix multiline comment style >>> - [3/3] add entry to MAINTAINERS >>> >>> * since v1 >>> - [2/3] fix parens in NUMONYX_V_ACTIMB_165 define >>> - [3/3] add extra space after first &ctrl_base in file igep0020.c >>> - [3/3] add a space after the 57600 comma in file igep0020.h >>> - [3/3] remove CONFIG_SYS_ARM_WITHOUT_RELOC undef >>> >>> $ git diff --stat origin/master >>> MAINTAINERS | 4 + >>> MAKEALL | 1 + >>> arch/arm/include/asm/arch-omap3/mem.h | 43 ++ >>> board/isee/igep0020/Makefile | 49 +++ >>> board/isee/igep0020/config.mk | 33 + >>> board/isee/igep0020/igep0020.c | 128 ++ >>> board/isee/igep0020/igep0020.h | 156 ++ >>> boards.cfg | 1 + >>> drivers/mtd/onenand/onenand_base.c | 1 + >>> include/configs/igep0020.h | 228 >>> + >>> include/linux/mtd/onenand.h | 1 + >>> 11 files changed, 645 insertions(+), 0 deletions(-) >> >> I noticed that you are using the legacy mmc driver. > > Yes. > >> >> I've submitted a patch series to add support for the generic mmc driver >> on OMAP3 and OMAP4. > > Ok > >> >> Once this is upstream you might want to consider sending a patch to >> switch IGEP v2 from the legacy driver to the generic driver. > > I'll do. > > I'll fix one build warning in version 4 > > igep0020.c: In function 'board_eth_init': > igep0020.c:125: warning: implicit declaration of function > 'smc911x_initialize' > > but first I've a question. Some people acked and tested my patches, > when I send the version 4. I need to add these acks in my patch or are > automatically added ? I typically add any Acks/Testeds I've received in the next revision. It will save Sandeep a little work if he doesn't have to manually add them :-) Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 0/2] ARMV7: Add support for the Versatile Express Quad Cortex A9 platform
Hi Wolfgang, On 10/07/2010 03:48 PM, matt.wad...@linaro.org wrote: > ARMV7: Versatile Express Coretile CortexA9x4 support > ARMV7: Fixed baudrate setting in pl01x driver These 2 patches have been hanging around for a while and I've been pulling them along with the trunk changes. They've already been reviewed a couple of times, and there was one Tested-by a while back. I was wondering if there is anything else I need to do get them merged. I'm concerned they won't make it in before the merge window closes again. Thanks, Matt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv3 0/3] Add support for the IGEP v2 board.
Hello, 2010/10/11 Steve Sakoman : > On Mon, 2010-10-11 at 00:12 +0200, Enric Balletbo i Serra wrote: >> Hello, >> >> This is the version 3 of patch series to add initial support for >> OMAP3 IGEP v2 board. >> >> CHANGES: >> >> * since v2 >> - [1/3] keep lists sorted >> - [2/3] fix multiline comment style >> - [3/3] add entry to MAINTAINERS >> >> * since v1 >> - [2/3] fix parens in NUMONYX_V_ACTIMB_165 define >> - [3/3] add extra space after first &ctrl_base in file igep0020.c >> - [3/3] add a space after the 57600 comma in file igep0020.h >> - [3/3] remove CONFIG_SYS_ARM_WITHOUT_RELOC undef >> >> $ git diff --stat origin/master >> MAINTAINERS | 4 + >> MAKEALL | 1 + >> arch/arm/include/asm/arch-omap3/mem.h | 43 ++ >> board/isee/igep0020/Makefile | 49 +++ >> board/isee/igep0020/config.mk | 33 + >> board/isee/igep0020/igep0020.c | 128 ++ >> board/isee/igep0020/igep0020.h | 156 ++ >> boards.cfg | 1 + >> drivers/mtd/onenand/onenand_base.c | 1 + >> include/configs/igep0020.h | 228 >> + >> include/linux/mtd/onenand.h | 1 + >> 11 files changed, 645 insertions(+), 0 deletions(-) > > I noticed that you are using the legacy mmc driver. Yes. > > I've submitted a patch series to add support for the generic mmc driver > on OMAP3 and OMAP4. Ok > > Once this is upstream you might want to consider sending a patch to > switch IGEP v2 from the legacy driver to the generic driver. I'll do. I'll fix one build warning in version 4 igep0020.c: In function 'board_eth_init': igep0020.c:125: warning: implicit declaration of function 'smc911x_initialize' but first I've a question. Some people acked and tested my patches, when I send the version 4. I need to add these acks in my patch or are automatically added ? Cheers, Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] - Add support for HP Jornada (710/720/728) board
On Wed, Oct 06, 2010 at 09:41:04PM +0200, Kristoffer Ericson wrote:
> This patch add support for the HP Jornada 700-series with flashrom (manufact.
> 2008).
> With little effort it could also be made to support earlier flashroms (just a
> change of memory settings).
> The HP Jornada is an strongarm device (sa1110 + sa).
Bumping this since Ive gotten no feedback or indication on
wether or not its getting applied.
/Kristoffer
>
> Signed-off-by: Kristoffer Ericson
> diff --git a/board/jornada/Makefile b/board/jornada/Makefile
> new file mode 100644
> index 000..1b4e192
> --- /dev/null
> +++ b/board/jornada/Makefile
> @@ -0,0 +1,53 @@
> +#
> +# (C) Copyright 2000-2006
> +# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> +#
> +# 2004 (c) MontaVista Software, Inc.
> +#
> +# See file CREDITS for list of people who contributed to this
> +# project.
> +#
> +# This program is free software; you can redistribute it and/or
> +# modify it under the terms of the GNU General Public License as
> +# published by the Free Software Foundation; either version 2 of
> +# the License, or (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program; if not, write to the Free Software
> +# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> +# MA 02111-1307 USA
> +#
> +
> +include $(TOPDIR)/config.mk
> +
> +LIB = $(obj)lib$(BOARD).a
> +
> +COBJS:= jornada.o
> +SOBJS:= setup.o
> +
> +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
> +OBJS := $(addprefix $(obj),$(COBJS))
> +SOBJS:= $(addprefix $(obj),$(SOBJS))
> +
> +$(LIB): $(obj).depend $(OBJS) $(SOBJS)
> + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
> +
> +clean:
> + rm -f $(SOBJS) $(OBJS)
> +
> +distclean: clean
> + rm -f $(LIB) core *.bak $(obj).depend
> +
> +#
> +
> +# defines $(obj).depend target
> +include $(SRCTREE)/rules.mk
> +
> +sinclude $(obj).depend
> +
> +#
> diff --git a/board/jornada/config.mk b/board/jornada/config.mk
> new file mode 100644
> index 000..59968aa
> --- /dev/null
> +++ b/board/jornada/config.mk
> @@ -0,0 +1,6 @@
> +#
> +# SA-1110 based HP Jornada Flashrom
> +#
> +# We got 2 x 16 Intel SDRAM in total 128MB
> +#
> +TEXT_BASE = 0xc1f0
> diff --git a/board/jornada/jornada.c b/board/jornada/jornada.c
> new file mode 100644
> index 000..5cc972b
> --- /dev/null
> +++ b/board/jornada/jornada.c
> @@ -0,0 +1,63 @@
> +/*
> + * (C) Copyright 2002
> + * Sysgo Real-Time Solutions, GmbH
> + * Marius Groeger
> + *
> + * 2004 (c) MontaVista Software, Inc.
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +/* -
> */
> +
> +static void jornada_init(void)
> +{
> +
> +}
> +
> +int board_init(void)
> +{
> + gd->bd->bi_arch_number = 48;
> + gd->bd->bi_boot_params = 0xc100;
> +
> +
> + /* turn on flashing
> + * would be nice to have some protection but
> + * that would have to be implemented in the
> + * flash init function, which isnt possible yet. */
> + PPSR |= (1 << 7);
> + PPDR |= (1 << 7);
> +
> + return 0;
> +}
> +
> +int dram_init(void)
> +{
> + gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
> + gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
> + gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
> + gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE;
> +
> + return (0);
> +}
> diff --git a/board/jornada/setup.S b/board/jornada/setup.S
> new file mode 100644
> index 000..885e02f
> --- /dev/null
> +++ b/board/jornada/setup.S
> @@ -0,0 +1,210 @@
> +/*
> + * Memory Setup stuff - taken from blob memsetup.S
> + *
> + * Copyright (C) 1999 2000 2001 Erik Mouw (
[U-Boot] [WIP] tools/env: cleanup host build flags
This patch makes tools/env/Makefile more similar to tools/imls: - define HOSTSRCS and HOSTCPPFLAGS, so that .depend generation works. - include U-Boot headers using -idirafter to prevent picking up u-boot/include/errno.h. - use HOSTCFLAGS_NOPED (fw_env.c does not conform to -pedantic). - use the cross compiler again (fw_printenv is intended for a hosted environment on the target). Signed-off-by: Daniel Hobi Cc: Mike Frysinger Cc: Wolfgang Denk --- tools/env/Makefile | 15 ++- 1 files changed, 10 insertions(+), 5 deletions(-) Hi Scott, In commit d984fed0 (makefiles: fixes for building build tools), you suggest that using $(CC) with host flags (HOSTCFLAGS, etc) is the correct way to use the cross compiler to generate binaries for a hosted environment on the target. On the other hand, you use $(HOSTCC) to generate the .depend file in rules.mk which leads to wrong dependencies. I think we need to differentiate three cases: - (free-standing) U-Boot: use CC and CFLAGS - native tools (mkimage, etc): use HOSTCC and HOSTCFLAGS - Linux environment on the target (imls, fw_printenv): Can we use CC and HOSTCFLAGS, or do we need a third set of variables for flags? If reusing HOSTCFLAGS: how do we fix dependency generation? Best regards, Daniel diff --git a/tools/env/Makefile b/tools/env/Makefile index f893040..a7bed87 100644 --- a/tools/env/Makefile +++ b/tools/env/Makefile @@ -23,19 +23,24 @@ include $(TOPDIR)/config.mk -SRCS := $(obj)crc32.c fw_env.c fw_env_main.c +HOSTSRCS := $(obj)crc32.c fw_env.c fw_env_main.c HEADERS:= fw_env.h -HOSTCFLAGS += -Wall -DUSE_HOSTCC -I$(SRCTREE)/include +# Compile for a hosted environment on the target +HOSTCPPFLAGS = -idirafter $(SRCTREE)/include \ +-idirafter $(OBJTREE)/include2 \ +-idirafter $(OBJTREE)/include \ +-DUSE_HOSTCC ifeq ($(MTD_VERSION),old) -HOSTCFLAGS += -DMTD_OLD +HOSTCPPFLAGS += -DMTD_OLD endif all: $(obj)fw_printenv -$(obj)fw_printenv: $(SRCS) $(HEADERS) - $(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $(SRCS) +# Some files complain if compiled with -pedantic, use HOSTCFLAGS_NOPED +$(obj)fw_printenv: $(HOSTSRCS) $(HEADERS) + $(CC) $(HOSTCFLAGS_NOPED) $(HOSTLDFLAGS) -o $@ $(HOSTSRCS) clean: rm -f $(obj)fw_printenv $(obj)crc32.c -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tools/imls: fix comment in Makefile
Commit d984fed0 (makefiles: fixes for building build tools) changed the variable name FIT_CFLAGS to HOSTCFLAGS_NOPED but forgot to update to corresponding comment. Signed-off-by: Daniel Hobi Cc: Scott Wood Cc: Wolfgang Denk --- tools/imls/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/imls/Makefile b/tools/imls/Makefile index 8407277..0caa397 100644 --- a/tools/imls/Makefile +++ b/tools/imls/Makefile @@ -67,7 +67,7 @@ $(obj)imls: $(obj)imls.o $(obj)crc32.o $(obj)image.o $(obj)md5.o \ $(CC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^ $(STRIP) $@ -# Some files complain if compiled with -pedantic, use FIT_CFLAGS +# Some files complain if compiled with -pedantic, use HOSTCFLAGS_NOPED $(obj)image.o: $(SRCTREE)/common/image.c $(CC) -g $(HOSTCFLAGS_NOPED) -c -o $@ $< -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3] mmc: seperate block number into small parts for multi-write cmd
Constraint the mmc framework to only send no more than 65535
blocks in one go during the multi-write command. This constraint
comes due to the limitation of 16bit width block counter register
at some hardware.
Signed-off-by: Lei Wen
Cc: Reinhard Meyer
---
V3: return to the V1 solution that keep the 65535 constraint,
but cut the 512KiB dma limitation
V2: add additional members in mmc structure
drivers/mmc/mmc.c | 52
1 files changed, 36 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 80cd9bf..18980e6 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -78,17 +78,11 @@ struct mmc *find_mmc_device(int dev_num)
}
static ulong
-mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt, const void*src)
+mmc_write_blocks(struct mmc *mmc, ulong start, lbaint_t blkcnt, const void*src)
{
struct mmc_cmd cmd;
struct mmc_data data;
- int err;
- int stoperr = 0;
- struct mmc *mmc = find_mmc_device(dev_num);
- int blklen;
-
- if (!mmc)
- return -1;
+ int blklen, err;
blklen = mmc->write_bl_len;
@@ -97,12 +91,6 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt, const
void*src)
start + blkcnt, mmc->block_dev.lba);
return 0;
}
- err = mmc_set_blocklen(mmc, mmc->write_bl_len);
-
- if (err) {
- printf("set write bl len failed\n\r");
- return err;
- }
if (blkcnt > 1)
cmd.cmdidx = MMC_CMD_WRITE_MULTIPLE_BLOCK;
@@ -123,7 +111,6 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt, const
void*src)
data.flags = MMC_DATA_WRITE;
err = mmc_send_cmd(mmc, &cmd, &data);
-
if (err) {
printf("mmc write failed\n\r");
return err;
@@ -134,9 +121,42 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt,
const void*src)
cmd.cmdarg = 0;
cmd.resp_type = MMC_RSP_R1b;
cmd.flags = 0;
- stoperr = mmc_send_cmd(mmc, &cmd, NULL);
+ err = mmc_send_cmd(mmc, &cmd, NULL);
+ if (err) {
+ printf("mmc fail to send stop cmd\n\r");
+ return err;
+ }
+ }
+
+ return blkcnt;
+}
+
+static ulong
+mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt, const void*src)
+{
+ int err;
+ struct mmc *mmc = find_mmc_device(dev_num);
+ lbaint_t cur, blocks_todo = blkcnt;
+
+ if (!mmc)
+ return -1;
+
+ err = mmc_set_blocklen(mmc, mmc->write_bl_len);
+ if (err) {
+ printf("set write bl len failed\n\r");
+ return err;
}
+ do {
+ /* The 65535 constraint comes from some hardware has
+* only 16 bit width block number counter */
+ cur = (blocks_todo > 65535) ? 65535 : blocks_todo;
+ if(mmc_write_blocks(mmc, start, cur, src) != cur)
+ return -1;
+ blocks_todo -= cur;
+ start += cur;
+ src += cur * mmc->write_bl_len;
+ } while (blocks_todo > 0);
return blkcnt;
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] always relocate fdt into an lmb-allocated memory block
On Fri, Aug 20, 2010 at 2:12 PM, Timur Tabi wrote: > On Sat, Aug 7, 2010 at 6:36 PM, Wolfgang Denk wrote: > >> I would like to see any ACK or Tested-by: from actual users of this code. > > Kumar, who should ack this patch? This patch has been tested and acked by Ira Synder: http://lists.denx.de/pipermail/u-boot/2010-September/076946.html Kumar, please apply this patch for -next -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot] MPC8360E ATM Quad OC3 External Phys u-boot patch
Hi, I have a fix for MPC8360E ATM Quad OC3 External Phys on u-boot 2010-06. Changed CS4 and CS5 addresses on Local Bus for matching PMC0 and PMC1 addresses. Attached you can find the patch for it. Best regards, Stefan A. POPA Freescale Semiconductor Romania SRL 45, Tudor Vladimirescu Street Tati Business Center Bucharest 050881, Romania Phone: +40 21 3052431 This e-mail, and any associated attachments have been classified as: ( ) Public ( ) Freescale Semiconductor Internal Use Only ( ) Freescale Semiconductor Confidential Proprietary 0001-Fix-for-MPC8360E-ATM-Quad-OC3-External-Phys.patch Description: 0001-Fix-for-MPC8360E-ATM-Quad-OC3-External-Phys.patch ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv3 0/3] Add support for the IGEP v2 board.
On Mon, 2010-10-11 at 00:12 +0200, Enric Balletbo i Serra wrote: > Hello, > > This is the version 3 of patch series to add initial support for > OMAP3 IGEP v2 board. > > CHANGES: > > * since v2 > - [1/3] keep lists sorted > - [2/3] fix multiline comment style > - [3/3] add entry to MAINTAINERS > > * since v1 > - [2/3] fix parens in NUMONYX_V_ACTIMB_165 define > - [3/3] add extra space after first &ctrl_base in file igep0020.c > - [3/3] add a space after the 57600 comma in file igep0020.h > - [3/3] remove CONFIG_SYS_ARM_WITHOUT_RELOC undef > > $ git diff --stat origin/master > MAINTAINERS |4 + > MAKEALL |1 + > arch/arm/include/asm/arch-omap3/mem.h | 43 ++ > board/isee/igep0020/Makefile | 49 +++ > board/isee/igep0020/config.mk | 33 + > board/isee/igep0020/igep0020.c| 128 ++ > board/isee/igep0020/igep0020.h| 156 ++ > boards.cfg|1 + > drivers/mtd/onenand/onenand_base.c|1 + > include/configs/igep0020.h| 228 > + > include/linux/mtd/onenand.h |1 + > 11 files changed, 645 insertions(+), 0 deletions(-) I noticed that you are using the legacy mmc driver. I've submitted a patch series to add support for the generic mmc driver on OMAP3 and OMAP4. Once this is upstream you might want to consider sending a patch to switch IGEP v2 from the legacy driver to the generic driver. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv3 3/3] OMAP3: Add support for the IGEP v2 board.
On Mon, 2010-10-11 at 00:12 +0200, Enric Balletbo i Serra wrote: > The IGEP v2 board is a low-cost, fan-less and industrial temperature > range single board computer that unleashes laptop-like performance and > expandability without the bulk, expense, or noise of typical desktop > machines. Its architecture shares much in common with other OMAP3 boards. > > Signed-off-by: Enric Balletbo i Serra > --- > MAINTAINERS|4 + > MAKEALL|1 + > board/isee/igep0020/Makefile | 49 + > board/isee/igep0020/config.mk | 33 ++ > board/isee/igep0020/igep0020.c | 128 ++ > board/isee/igep0020/igep0020.h | 156 +++ > boards.cfg |1 + > include/configs/igep0020.h | 228 > > 8 files changed, 600 insertions(+), 0 deletions(-) > create mode 100644 board/isee/igep0020/Makefile > create mode 100644 board/isee/igep0020/config.mk > create mode 100644 board/isee/igep0020/igep0020.c > create mode 100644 board/isee/igep0020/igep0020.h > create mode 100644 include/configs/igep0020.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index e003226..99728ae 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -818,6 +818,10 @@ Alex Z > lartSA1100 > dnp1110 SA1110 > > +Enric Balletbo i Serra > + > + igep0020ARM ARMV7 (OMAP3xx SoC) > + > - > > Unknown / orphaned boards: > diff --git a/MAKEALL b/MAKEALL > index 1b506d6..78dce8b 100755 > --- a/MAKEALL > +++ b/MAKEALL > @@ -490,6 +490,7 @@ LIST_ARM11=" \ > LIST_ARMV7=" \ > am3517_evm \ > devkit8000 \ > + igep0020\ > mx51evk \ > omap3_beagle\ > omap3_overo \ > diff --git a/board/isee/igep0020/Makefile b/board/isee/igep0020/Makefile > new file mode 100644 > index 000..2f11879 > --- /dev/null > +++ b/board/isee/igep0020/Makefile > @@ -0,0 +1,49 @@ > +# > +# (C) Copyright 2000, 2001, 2002 > +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. > +# > +# See file CREDITS for list of people who contributed to this > +# project. > +# > +# This program is free software; you can redistribute it and/or > +# modify it under the terms of the GNU General Public License as > +# published by the Free Software Foundation; either version 2 of > +# the License, or (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, > +# MA 02111-1307 USA > +# > + > +include $(TOPDIR)/config.mk > + > +LIB = $(obj)lib$(BOARD).a > + > +COBJS:= igep0020.o > + > +SRCS := $(COBJS:.o=.c) > +OBJS := $(addprefix $(obj),$(COBJS)) > + > +$(LIB): $(obj).depend $(OBJS) > + $(AR) $(ARFLAGS) $@ $(OBJS) > + > +clean: > + rm -f $(OBJS) > + > +distclean: clean > + rm -f $(LIB) core *.bak $(obj).depend > + > +# > + > +# defines $(obj).depend target > +include $(SRCTREE)/rules.mk > + > +sinclude $(obj).depend > + > +# > diff --git a/board/isee/igep0020/config.mk b/board/isee/igep0020/config.mk > new file mode 100644 > index 000..b8812f9 > --- /dev/null > +++ b/board/isee/igep0020/config.mk > @@ -0,0 +1,33 @@ > +# > +# (C) Copyright 2009 > +# ISEE 2007 SL, > +# > +# IGEP0020 uses OMAP3 (ARM-CortexA8) cpu > +# see http://www.ti.com/ for more information on Texas Instruments > +# > +# See file CREDITS for list of people who contributed to this > +# project. > +# > +# This program is free software; you can redistribute it and/or > +# modify it under the terms of the GNU General Public License as > +# published by the Free Software Foundation; either version 2 of > +# the License, or (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, > +# MA 02111-1307 USA > +# > +# Physical Address: > +# 8000' (bank0) > +# A000/ (bank1) > +# Linux-Kernel is
Re: [U-Boot] [PATCHv3 2/3] OMAP3: SDRC: Introduce Numonyx DDR type
On Mon, 2010-10-11 at 00:12 +0200, Enric Balletbo i Serra wrote:
> Introduce Numonyx DDR timings and provide CONFIG_OMAP3_NUMONYX_DDR
> config options to allow for platform files to setup their timings.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
> arch/arm/include/asm/arch-omap3/mem.h | 43
> +
> 1 files changed, 43 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-omap3/mem.h
> b/arch/arm/include/asm/arch-omap3/mem.h
> index a78cf9f..f165949 100644
> --- a/arch/arm/include/asm/arch-omap3/mem.h
> +++ b/arch/arm/include/asm/arch-omap3/mem.h
> @@ -128,6 +128,45 @@ enum {
> (MICRON_XSR_165 << 0) | (MICRON_TXP_165 << 8) | \
> (MICRON_TWTR_165 << 16))
>
> +/*
> + * NUMONYX part of IGEP v2 (165MHz optimized) 6.06ns
> + * ACTIMA
> + * TDAL = Twr/Tck + Trp/tck = 15/6 + 18/6 = 2.5 + 3 = 5.5 -> 6
> + * TDPL (Twr) = 15/6 = 2.5 -> 3
> + * TRRD = 12/6 = 2
> + * TRCD = 22.5/6 = 3.75 -> 4
> + * TRP = 18/6 = 3
> + * TRAS = 42/6 = 7
> + * TRC = 60/6 = 10
> + * TRFC = 140/6 = 23.3 -> 24
> + * ACTIMB
> + * TWTR = 2
> + * TCKE = 2
> + * TXSR = 200/6 = 33.3 -> 34
> + * TXP = 1.0 + 1.1 = 2.1 -> 3
> + */
> +#define NUMONYX_TDAL_165 6
> +#define NUMONYX_TDPL_165 3
> +#define NUMONYX_TRRD_165 2
> +#define NUMONYX_TRCD_165 4
> +#define NUMONYX_TRP_1653
> +#define NUMONYX_TRAS_165 7
> +#define NUMONYX_TRC_165 10
> +#define NUMONYX_TRFC_165 24
> +#define NUMONYX_V_ACTIMA_165 ((NUMONYX_TRFC_165 << 27) | \
> + (NUMONYX_TRC_165 << 22) | (NUMONYX_TRAS_165 << 18) | \
> + (NUMONYX_TRP_165 << 15) | (NUMONYX_TRCD_165 << 12) | \
> + (NUMONYX_TRRD_165 << 9) | (NUMONYX_TDPL_165 << 6) | \
> + (NUMONYX_TDAL_165))
> +
> +#define NUMONYX_TWTR_165 2
> +#define NUMONYX_TCKE_165 2
> +#define NUMONYX_TXP_1653
> +#define NUMONYX_XSR_16534
> +#define NUMONYX_V_ACTIMB_165 ((NUMONYX_TCKE_165 << 12) | \
> + (NUMONYX_XSR_165 << 0) | (NUMONYX_TXP_165 << 8) | \
> + (NUMONYX_TWTR_165 << 16))
> +
> #ifdef CONFIG_OMAP3_INFINEON_DDR
> #define V_ACTIMA_165 INFINEON_V_ACTIMA_165
> #define V_ACTIMB_165 INFINEON_V_ACTIMB_165
> @@ -136,6 +175,10 @@ enum {
> #define V_ACTIMA_165 MICRON_V_ACTIMA_165
> #define V_ACTIMB_165 MICRON_V_ACTIMB_165
> #endif
> +#ifdef CONFIG_OMAP3_NUMONYX_DDR
> +#define V_ACTIMA_165 NUMONYX_V_ACTIMA_165
> +#define V_ACTIMB_165 NUMONYX_V_ACTIMB_165
> +#endif
>
> #if !defined(V_ACTIMA_165) || !defined(V_ACTIMB_165)
> #error "Please choose the right DDR type in config header"
Acked-by: Steve Sakoman
Tested-by: Steve Sakoman
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv3 1/3] mtd: OneNAND: add support for OneNAND manufactured by Numonyx
On Mon, 2010-10-11 at 00:12 +0200, Enric Balletbo i Serra wrote:
> This patch adds the Numonyx manufacturer code (0x20) to
> onenand manufacturers.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
> drivers/mtd/onenand/onenand_base.c |1 +
> include/linux/mtd/onenand.h|1 +
> 2 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mtd/onenand/onenand_base.c
> b/drivers/mtd/onenand/onenand_base.c
> index f9273ab..24e02c2 100644
> --- a/drivers/mtd/onenand/onenand_base.c
> +++ b/drivers/mtd/onenand/onenand_base.c
> @@ -2213,6 +2213,7 @@ char *onenand_print_device_info(int device, int version)
> }
>
> static const struct onenand_manufacturers onenand_manuf_ids[] = {
> + {ONENAND_MFR_NUMONYX, "Numonyx"},
> {ONENAND_MFR_SAMSUNG, "Samsung"},
> };
>
> diff --git a/include/linux/mtd/onenand.h b/include/linux/mtd/onenand.h
> index 68e174e..5465562 100644
> --- a/include/linux/mtd/onenand.h
> +++ b/include/linux/mtd/onenand.h
> @@ -154,6 +154,7 @@ struct onenand_chip {
> /*
> * OneNAND Flash Manufacturer ID Codes
> */
> +#define ONENAND_MFR_NUMONYX 0x20
> #define ONENAND_MFR_SAMSUNG 0xec
>
> /**
Acked-by: Steve Sakoman
Tested-by: Steve Sakoman
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Enable NOR flash support in sequoia_ramboot target
Until now, the Sequoia RAM-booting image disabled NOR flash support as this image was mainly created for NAND-only boards. This patch now enables NOR flash support for this RAM-booting version as well. Signed-off-by: Stefan Roese --- board/amcc/sequoia/sequoia.c |6 -- include/configs/amcc-common.h | 11 --- 2 files changed, 4 insertions(+), 13 deletions(-) diff --git a/board/amcc/sequoia/sequoia.c b/board/amcc/sequoia/sequoia.c index c523bca..b518aa7 100644 --- a/board/amcc/sequoia/sequoia.c +++ b/board/amcc/sequoia/sequoia.c @@ -155,7 +155,8 @@ int misc_init_r(void) gd->bd->bi_flashstart = 0 - gd->bd->bi_flashsize; gd->bd->bi_flashoffset = 0; -#if defined(CONFIG_NAND_U_BOOT) || defined(CONFIG_NAND_SPL) +#if defined(CONFIG_NAND_U_BOOT) || defined(CONFIG_NAND_SPL) || \ +defined(CONFIG_SYS_RAMBOOT) mtdcr(EBC0_CFGADDR, PB3CR); #else mtdcr(EBC0_CFGADDR, PB0CR); @@ -163,7 +164,8 @@ int misc_init_r(void) pbcr = mfdcr(EBC0_CFGDATA); size_val = ffs(gd->bd->bi_flashsize) - 21; pbcr = (pbcr & 0x0001) | gd->bd->bi_flashstart | (size_val << 17); -#if defined(CONFIG_NAND_U_BOOT) || defined(CONFIG_NAND_SPL) +#if defined(CONFIG_NAND_U_BOOT) || defined(CONFIG_NAND_SPL) || \ +defined(CONFIG_SYS_RAMBOOT) mtdcr(EBC0_CFGADDR, PB3CR); #else mtdcr(EBC0_CFGADDR, PB0CR); diff --git a/include/configs/amcc-common.h b/include/configs/amcc-common.h index 9c53d37..3f7eb62 100644 --- a/include/configs/amcc-common.h +++ b/include/configs/amcc-common.h @@ -81,17 +81,6 @@ #define CONFIG_CMD_PING #define CONFIG_CMD_REGINFO -#if defined(CONFIG_SYS_RAMBOOT) -/* - * Disable NOR FLASH commands on RAM-booting version. One main reason for this - * RAM-booting version is boards with NAND and without NOR. This image can - * be used for initial NAND programming. - */ -#define CONFIG_SYS_NO_FLASH -#undef CONFIG_CMD_FLASH -#undef CONFIG_CMD_IMLS -#endif - /* * Miscellaneous configurable options */ -- 1.7.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] (no subject)
Dear Stefan Roese, In message <201010111519.04457...@denx.de> you wrote: > > The Sequoia RAM-booting target has been created mainly for boards equipped > only with NAND flash (no NOR). This image can be loaded via a JTAG debugger > into RAM and started there. After this U-Boot can be used to initially > program > the NAND flash. To make porting easier for other PPC4xx NAND-only users, I > therefore removed NOR support from this RAM-booting image. But the Sequoia board has both NOR and NAND, so we should support both. > I now see two possible solutions for the current compile breakage: > > a) Enable NOR again on sequoia_ramboot > b) Keep NOR disabled and remove CONFIG_FDT_FIXUP_NOR_FLASH_SIZE for >sequoia_ramboot As a) is way more useful to customers we should do that. > Just let me know which one you would prefer and I will send a patch for it. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de God grant me the senility to accept the things I cannot change, The frustration to try to change things I cannot affect, and the wisdom to tell the difference. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] packed attribute problem
Dear all, I wanted to point out clues about why GCC manages the packed attribute in this way. The behavior is suspiciously similar to what the ARM RVDS compiler (armcc) does with the __packed qualifier: > [...] > Thus if you wish to define a pointer to a word that can be at any address > (i.e. that can be at a non-natural > alignment) then you must specify this using the __packed qualifier when > defining the pointer: > >__packed int *pi; // pointer to unaligned int > > The ARM compilers will not then use an LDR, but instead generate code which > correctly accesses the value > regardless of the alignment of the pointer. This code generated will be a > sequence of byte accesses, or > variable alignment-dependent shifting and masking (depending on the compile > options) and will therefore > incur a performance and code size penalty. > [...] ( From http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3544.html ) I am starting to suspect that the "feature" was copied from the armcc compiler, even though there shouldn't be any reason to do that. I can picture someone translating C code from armcc to GCC and changing the __packed qualifier with the packed attribute, and then obtaining undesired 32-bit accesses when he wanted 8-bit accesses. Maybe the fact that GCC packed attribute did not map globals to unaligned addresses was listed as a "bug" by someone who was more familiar with armcc, and the developers who "fixed" it were uncertain about GCC specifications. Maybe the modification was part of a big changeset and went overlooked, and changing it back now would break so much code it's better to leave it so. But these are only speculations. The file "gcc/config/arm/arm.h" inside GCC source contains possibly useful information: > /* Setting STRUCTURE_SIZE_BOUNDARY to 32 produces more efficient code, but the > value set in previous versions of this toolchain was 8, which produces more > compact structures. The command line option -mstructure_size_boundary= > can be used to change this value. For compatibility with the ARM SDK > however the value should be left at 32. ARM SDT Reference Manual (ARM DUI > 0020D) page 2-20 says "Structures are aligned on word boundaries". > The AAPCS specifies a value of 8. */ It seems, though, that using -mstructure-size-boundary=8 or 32 with a 4.4.1-based toolchain has no difference on the managing of packed structs. Another interesting scenario is the access of arrays of packed structs. If a struct is packed but not aligned(4), its sizeof() could be a number that is not a multiple of the alignment (in the case of ARM targets). Even if the first element of the array is aligned, the second element has an unaligned address. Hope it rings some bells. Regards, Francesco ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][ELF RELOC] armv7, beagle: add support for ELF relocations
Dear Heiko Schocher, In message <1286798895-28813-3-git-send-email...@denx.de> you wrote: > Signed-off-by: Heiko Schocher > --- > arch/arm/cpu/armv7/start.S | 131 > > arch/arm/cpu/armv7/u-boot.lds |7 ++ > arch/arm/lib/cache.c |2 +- > include/configs/omap3_beagle.h |2 +- > 4 files changed, 87 insertions(+), 55 deletions(-) Applied to u-boot-armn repo, elf_reloc branch. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Actual war is a very messy business. Very, very messy business. -- Kirk, "A Taste of Armageddon", stardate 3193.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (no subject)
Hi Wolfgang, On Monday 11 October 2010 09:49:52 Stefan Roese wrote: > sequoia_ramboot definitely needs a different "fix". We do want to support > NAND and NOR flash when booting from RAM (via debugger etc). I'll take a > look at it soon. The Sequoia RAM-booting target has been created mainly for boards equipped only with NAND flash (no NOR). This image can be loaded via a JTAG debugger into RAM and started there. After this U-Boot can be used to initially program the NAND flash. To make porting easier for other PPC4xx NAND-only users, I therefore removed NOR support from this RAM-booting image. I now see two possible solutions for the current compile breakage: a) Enable NOR again on sequoia_ramboot b) Keep NOR disabled and remove CONFIG_FDT_FIXUP_NOR_FLASH_SIZE for sequoia_ramboot Just let me know which one you would prefer and I will send a patch for it. Thanks. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][ELF RELOC] arm926ejs, tx25: add support for ELF relocations
Dear Heiko Schocher, In message <1286798895-28813-2-git-send-email...@denx.de> you wrote: > Signed-off-by: Heiko Schocher > --- > arch/arm/config.mk |2 ++ > arch/arm/cpu/arm926ejs/start.S |8 > board/karo/tx25/config.mk |2 +- > include/configs/tx25.h |3 ++- > nand_spl/board/karo/tx25/u-boot.lds | 13 + > 5 files changed, 22 insertions(+), 6 deletions(-) Applied to u-boot-armn repo, elf_reloc branch. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Honest error is to be pitied, not ridiculed. -- Philip Earl of Chesterfield ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][ELF RELOC] arm926ejs, magnesium: add support for ELF relocations
Dear Heiko Schocher, In message <1286798895-28813-1-git-send-email...@denx.de> you wrote: > Signed-off-by: Heiko Schocher > --- > board/logicpd/imx27lite/config.mk |3 +++ > include/configs/imx27lite-common.h |2 +- > 2 files changed, 4 insertions(+), 1 deletions(-) Applied to u-boot-armn repo, elf_reloc branch. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. - Wernher von Braun ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] env_mmc: Fix crashing bug encountered after enabling ARM relocation
env_mmc: Fix crashing bug encountered after enabling ARM relocation
The crash was occuring in env_relocate because it was being called prior
to mmc_initialize. This patch moves the MMC initialization earlier in
the init process.
This patch also cleans up the env_relocate_spec code in env_mmc.c
Signed-off-by: Steve Sakoman
Acked-by: Stefano Babic
---
v3 - remove the extra space in mmc_initialize call
v2 - remove space in puts call and add Acked-by
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 5f2dfd0..328a88d 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -779,6 +779,11 @@ void board_init_r (gd_t *id, ulong dest_addr)
onenand_init();
#endif
+#ifdef CONFIG_GENERIC_MMC
+ puts("MMC: ");
+ mmc_initialize(bd);
+#endif
+
#ifdef CONFIG_HAS_DATAFLASH
AT91F_DataflashInit();
dataflash_print_info();
@@ -854,11 +859,6 @@ extern void davinci_eth_set_mac_addr (const u_int8_t
*addr);
board_late_init ();
#endif
-#ifdef CONFIG_GENERIC_MMC
- puts ("MMC: ");
- mmc_initialize (gd->bd);
-#endif
-
#ifdef CONFIG_BITBANGMII
bb_miiphy_init();
#endif
diff --git a/common/env_mmc.c b/common/env_mmc.c
index cc288d4..d443ff5 100644
--- a/common/env_mmc.c
+++ b/common/env_mmc.c
@@ -129,18 +129,21 @@ inline int read_env(struct mmc *mmc, unsigned long size,
void env_relocate_spec(void)
{
#if !defined(ENV_IS_EMBEDDED)
+ char buf[CONFIG_ENV_SIZE];
+
struct mmc *mmc = find_mmc_device(CONFIG_SYS_MMC_ENV_DEV);
- if (init_mmc_for_env(mmc))
+ if (init_mmc_for_env(mmc)) {
+ use_default();
return;
+ }
- if (read_env(mmc, CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, env_ptr))
- return use_default();
-
- if (crc32(0, env_ptr->data, ENV_SIZE) != env_ptr->crc)
- return use_default();
+ if (read_env(mmc, CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, buf)) {
+ use_default();
+ return;
+ }
- gd->env_valid = 1;
+ env_import(buf, 1);
#endif
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] [NEXT] orion5x: fix relocation-incompatible code
Dear Albert Aribaud, In message <1285271364-21302-1-git-send-email-albert.arib...@free.fr> you wrote: > > Signed-off-by: Albert Aribaud > --- > SUMMARY > > Device address window mapping code would not run from > FLASH due to cutting access to BOOTCS. Fixed by reordering > code. > > Timer initialization would write globals, thus would not > run correctly from FLASH. Fixed by moving the writes to a > later phase in RAM. > > PATCHSET HISTORY > > V1Initial submission > V2Removed useless blank line in config.mk > Fixed typo in config file > Reordered window inits in cpu.c > Added newline at end of timer.c > > These patches show 0 error or warning with checkpatch.pl --no-tree > and have been tested on edminiv2. > > arch/arm/cpu/arm926ejs/orion5x/cpu.c| 78 +++--- > arch/arm/cpu/arm926ejs/orion5x/timer.c |6 ++- > arch/arm/include/asm/arch-orion5x/cpu.h |1 + > 3 files changed, 54 insertions(+), 31 deletions(-) Applied to "u-boot-arm" repo, "master" branch. "elf_reloc"-Branch rebased against master. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The world is coming to an end -- save your buffers! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/2] [NEXT] edminiv2: enable relocation
Dear Albert ARIBAUD, In message <4cb2f82f.2090...@free.fr> you wrote: > > > If yes, then how about the other part of this series, "[PATCH V2 1/2] > > [NEXT] orion5x: fix relocation-incompatible c..." ? > > I'd forgotten this one -- somehow I thought it was already applied since > it was a fix made above Heiko's GOT relocation patches before they were > merged from next to master. > > So yes, it is needed for relocation, but it is not ELF specific. It > should thus go to the arm master branch, and the ELF branch should be > based at or above it. OK, will do. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What is mind? No matter. What is matter? Never mind. -- Thomas Hewitt Key, 1799-1875 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/2] [NEXT] edminiv2: enable relocation
Dear Albert ARIBAUD, In message <4cb2f968.8040...@free.fr> you wrote: > Le 11/10/2010 13:42, Albert ARIBAUD a =E9crit : > > > So yes, it is needed for relocation, but it is not ELF specific. It > > should thus go to the arm master branch, and the ELF branch should be > > based at or above it. > > BTW: do you want me to resubmit it formally as a standalone patch? No, thanks, not needed. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de After a heated argument on some trivial matter Nancy [Astor] . . . shouted, ``If I were your wife I would put poison in your coffee!'' Whereupon Winston Churchill with equal heat and sincerity answered, ``And if I were your husband I would drink it.'' ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH][ELF RELOC] armv7, beagle: add support for ELF relocations
Signed-off-by: Heiko Schocher --- arch/arm/cpu/armv7/start.S | 131 arch/arm/cpu/armv7/u-boot.lds |7 ++ arch/arm/lib/cache.c |2 +- include/configs/omap3_beagle.h |2 +- 4 files changed, 87 insertions(+), 55 deletions(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index c392c5d..d5c053d 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -78,13 +78,13 @@ _armboot_start: /* * These are defined in the board-specific linker script. */ -.globl _bss_start -_bss_start: - .word __bss_start +.globl _bss_start_ofs +_bss_start_ofs: + .word __bss_start - _start -.globl _bss_end -_bss_end: - .word _end +.globl _bss_end_ofs +_bss_end_ofs: + .word _end - _start #ifdef CONFIG_USE_IRQ /* IRQ stack memory (calculated at run-time) */ @@ -104,29 +104,29 @@ FIQ_STACK_START: IRQ_STACK_START_IN: .word 0x0badc0de -.globl _datarel_start -_datarel_start: - .word __datarel_start +.globl _datarel_start_ofs +_datarel_start_ofs: + .word __datarel_start - _start -.globl _datarelrolocal_start -_datarelrolocal_start: - .word __datarelrolocal_start +.globl _datarelrolocal_start_ofs +_datarelrolocal_start_ofs: + .word __datarelrolocal_start - _start -.globl _datarellocal_start -_datarellocal_start: - .word __datarellocal_start +.globl _datarellocal_start_ofs +_datarellocal_start_ofs: + .word __datarellocal_start - _start -.globl _datarelro_start -_datarelro_start: - .word __datarelro_start +.globl _datarelro_start_ofs +_datarelro_start_ofs: + .word __datarelro_start - _start -.globl _got_start -_got_start: - .word __got_start +.globl _got_start_ofs +_got_start_ofs: + .word __got_start - _start -.globl _got_end -_got_end: - .word __got_end +.globl _got_end_Ofs +_got_end_ofs: + .word __got_end - _start /* * the actual reset code @@ -198,9 +198,8 @@ stack_setup: #ifndef CONFIG_SKIP_RELOCATE_UBOOT adr r0, _start ldr r2, _TEXT_BASE - ldr r3, _bss_start - sub r2, r3, r2 /* r2 <- size of armboot*/ - add r2, r0, r2 /* r2 <- source end address */ + ldr r3, _bss_start_ofs + add r2, r0, r3 /* r2 <- source end address */ cmp r0, r6 #ifndef CONFIG_PRELOADER beq jump_2_ram @@ -213,33 +212,51 @@ copy_loop: blo copy_loop #ifndef CONFIG_PRELOADER - /* fix got entries */ - ldr r1, _TEXT_BASE - mov r0, r7 /* reloc addr */ - ldr r2, _got_start /* addr in Flash */ - ldr r3, _got_end/* addr in Flash */ - sub r3, r3, r1 - add r3, r3, r0 - sub r2, r2, r1 - add r2, r2, r0 - + /* +* fix .rel.dyn relocations +*/ + ldr r0, _TEXT_BASE /* r0 <- Text base */ + sub r9, r7, r0 /* r9 <- relocation offset */ + ldr r10, _dynsym_start_ofs /* r10 <- sym table ofs */ + add r10, r10, r0/* r10 <- sym table in FLASH */ + ldr r2, _rel_dyn_start_ofs /* r2 <- rel dyn start ofs */ + add r2, r2, r0 /* r2 <- rel dyn start in FLASH */ + ldr r3, _rel_dyn_end_ofs/* r3 <- rel dyn end ofs */ + add r3, r3, r0 /* r3 <- rel dyn end in FLASH */ fixloop: - ldr r4, [r2] - sub r4, r4, r1 - add r4, r4, r0 - str r4, [r2] - add r2, r2, #4 + ldr r0, [r2]/* r0 <- location to fix up, IN FLASH! */ + add r0, r9 /* r0 <- location to fix up in RAM */ + ldr r1, [r2, #4] + and r8, r1, #0xff + cmp r8, #23 /* relative fixup? */ + beq fixrel + cmp r8, #2 /* absolute fixup? */ + beq fixabs + /* ignore unknown type of fixup */ + b fixnext +fixabs: + /* absolute fix: set location to (offset) symbol value */ + mov r1, r1, LSR #4 /* r1 <- symbol index in .dynsym */ + add r1, r10, r1 /* r1 <- address of symbol in table */ + ldr r1, [r1, #4]/* r1 <- symbol value */ + add r1, r9 /* r1 <- relocated sym addr */ + b fixnext +fixrel: + /* relative fix: increase location by offset */ + ldr r1, [r0] + add r1, r1, r9 +fixnext: + str r1, [r0] + add r2, r2, #8 /* each rel.dyn entry is 8 bytes */ cmp r2, r3 - bne fixloop + blo fixloop clear_bss: - ldr r0, _bss_start - ldr r1, _bss_end + ldr r0, _bss_start_ofs + ldr r1, _bss_end_ofs ldr r3, _TEXT_BASE /* Text base */ mov r4
[U-Boot] [PATCH][ELF RELOC] arm926ejs, tx25: add support for ELF relocations
Signed-off-by: Heiko Schocher
---
arch/arm/config.mk |2 ++
arch/arm/cpu/arm926ejs/start.S |8
board/karo/tx25/config.mk |2 +-
include/configs/tx25.h |3 ++-
nand_spl/board/karo/tx25/u-boot.lds | 13 +
5 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 0be47d3..21c1e33 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -70,5 +70,7 @@ LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds
ifndef CONFIG_SYS_ARM_WITHOUT_RELOC
# needed for relocation
+ifndef CONFIG_NAND_SPL
PLATFORM_LDFLAGS += -pie
endif
+endif
diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
index 49ca839..e882487 100644
--- a/arch/arm/cpu/arm926ejs/start.S
+++ b/arch/arm/cpu/arm926ejs/start.S
@@ -279,10 +279,10 @@ clbss_l:str r2, [r0]/* clear
loop...*/
*/
#ifdef CONFIG_NAND_SPL
ldr r0, _nand_boot_ofs
- adr r1, _start
- add pc, r0, r1
-_nand_boot_ofs
- : .word nand_boot - _start
+ mov pc, r0
+
+_nand_boot_ofs:
+ .word nand_boot
#else
ldr r0, _board_init_r_ofs
adr r1, _start
diff --git a/board/karo/tx25/config.mk b/board/karo/tx25/config.mk
index 51ca1ab..8be6466 100644
--- a/board/karo/tx25/config.mk
+++ b/board/karo/tx25/config.mk
@@ -1,5 +1,5 @@
ifdef CONFIG_NAND_SPL
TEXT_BASE = 0x810c
else
-TEXT_BASE = 0x81fc
+TEXT_BASE = 0x8120
endif
diff --git a/include/configs/tx25.h b/include/configs/tx25.h
index c798570..2be3699 100644
--- a/include/configs/tx25.h
+++ b/include/configs/tx25.h
@@ -41,7 +41,7 @@
#define CONFIG_SYS_NAND_U_BOOT_OFFS0x800
#define CONFIG_SYS_NAND_U_BOOT_SIZE0x3
-#define CONFIG_SYS_NAND_U_BOOT_DST (0x81fc)
+#define CONFIG_SYS_NAND_U_BOOT_DST (0x8120)
#define CONFIG_SYS_NAND_U_BOOT_STARTCONFIG_SYS_NAND_U_BOOT_DST
#define CONFIG_SYS_NAND_PAGE_SIZE 2048
@@ -178,6 +178,7 @@
/* additions for new relocation code, must added to all boards */
#undef CONFIG_SYS_ARM_WITHOUT_RELOC /* This board is tested with relocation
support */
+#define CONFIG_RELOC_FIXUP_WORKS
#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1
#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + 0x1000
- /* Fix this */ \
CONFIG_SYS_GBL_DATA_SIZE)
diff --git a/nand_spl/board/karo/tx25/u-boot.lds
b/nand_spl/board/karo/tx25/u-boot.lds
index c572557..5f95c87 100644
--- a/nand_spl/board/karo/tx25/u-boot.lds
+++ b/nand_spl/board/karo/tx25/u-boot.lds
@@ -53,6 +53,11 @@ SECTIONS
*(.data.rel.ro)
}
+ . = ALIGN(4);
+ __rel_dyn_start = .;
+ __rel_dyn_end = .;
+ __dynsym_start = .;
+
__got_start = .;
. = ALIGN(4);
.got : { *(.got) }
@@ -67,4 +72,12 @@ SECTIONS
__bss_start = .;
.bss : { *(.bss) }
_end = .;
+ /DISCARD/ : { *(.bss*) }
+ /DISCARD/ : { *(.dynstr*) }
+ /DISCARD/ : { *(.dynsym*) }
+ /DISCARD/ : { *(.dynamic*) }
+ /DISCARD/ : { *(.hash*) }
+ /DISCARD/ : { *(.plt*) }
+ /DISCARD/ : { *(.interp*) }
+ /DISCARD/ : { *(.gnu*) }
}
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH][ELF RELOC] arm926ejs, magnesium: add support for ELF relocations
Signed-off-by: Heiko Schocher --- board/logicpd/imx27lite/config.mk |3 +++ include/configs/imx27lite-common.h |2 +- 2 files changed, 4 insertions(+), 1 deletions(-) diff --git a/board/logicpd/imx27lite/config.mk b/board/logicpd/imx27lite/config.mk index 2f9c4e6..af1c82b 100644 --- a/board/logicpd/imx27lite/config.mk +++ b/board/logicpd/imx27lite/config.mk @@ -1 +1,4 @@ +# with relocation TEXT_BASE can be anything, and making it 0 +# makes relative and absolute relocation fixups interchangeable. +#TEXT_BASE = 0 TEXT_BASE = 0xc000 diff --git a/include/configs/imx27lite-common.h b/include/configs/imx27lite-common.h index 812e5f2..1ebe83b 100644 --- a/include/configs/imx27lite-common.h +++ b/include/configs/imx27lite-common.h @@ -236,7 +236,7 @@ "mtdparts=" MTDPARTS_DEFAULT "\0" \ /* additions for new relocation code, must added to all boards */ -#undef CONFIG_SYS_ARM_WITHOUT_RELOC /* This board is tested with relocation support */ +#define CONFIG_RELOC_FIXUP_WORKS #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + 0x1000 - /* Fix this */ \ CONFIG_SYS_GBL_DATA_SIZE) -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/2] [NEXT] edminiv2: enable relocation
Le 11/10/2010 13:42, Albert ARIBAUD a écrit : > So yes, it is needed for relocation, but it is not ELF specific. It > should thus go to the arm master branch, and the ELF branch should be > based at or above it. BTW: do you want me to resubmit it formally as a standalone patch? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/2] [NEXT] edminiv2: enable relocation
Le 11/10/2010 13:30, Wolfgang Denk a écrit : > Dear Albert Aribaud, > > In message<1285271364-21302-2-git-send-email-albert.arib...@free.fr> you > wrote: >> >> Signed-off-by: Albert Aribaud >> --- >> board/LaCie/edminiv2/config.mk |3 ++- >> include/configs/edminiv2.h |6 ++ >> 2 files changed, 8 insertions(+), 1 deletions(-) > > Is it correct to assume this patch has been obsoleted by the recent > "[ELF_RELOC] [PATCH V3 2/2] edminiv2: add support for ELF" submission? Yes, it is correct. > If yes, then how about the other part of this series, "[PATCH V2 1/2] > [NEXT] orion5x: fix relocation-incompatible c..." ? I'd forgotten this one -- somehow I thought it was already applied since it was a fix made above Heiko's GOT relocation patches before they were merged from next to master. So yes, it is needed for relocation, but it is not ELF specific. It should thus go to the arm master branch, and the ELF branch should be based at or above it. Apologies for missing this. > Best regards, > > Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: seperate block number into small parts for multi-write cmd
Dear Reinhard Meyer, dear Lei Wen, In message <4cb2ea80.2090...@emk-elektronik.de> you wrote: > > > Ok, I am also fine with not include the 512KiB restriction. > > So we comes to a conclusion that we still use v1 patch, but cut the > > 512KiB limitation? > > Considering the comments that were given to that one, yes. I would like to point out that, from the previous discussion, I actually think that a 512 KiB limit would be wrong. If the limitation is really in the alignment, i. e. when crossing a 512 KiB boundary, then the allowable transfer size depends on the start address, and 512 KiB is actually only the maximum possible value. > > As mmc host limitation, the max number of block in one go > > should be limited to 65535, and the max buffer size should > > not excceed 512k bytes. > > Better reads somehow like this: > Since some hardware has a 16 bit block counter, split the multiple block > write into a maximum of (2**16 - 1) blocks to be written at one go. Agreed. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. - Fred Brooks, Jr. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] timer problem with new ARM relocation feature
Hello The timer implementation for s3c24xx based SoC (arch/arm/cpu/arm920t/s3c24x0/timer.c) uses several global variables. With the newly introduced ARM relocation feature, this timer code does no longer work as expected. What is the proposed fix/workaround for this? Is moving these variables to the "global data pointer area" an acceptable solution? Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] packed attribute problem
Hi Scott, > On Thu, 7 Oct 2010 21:31:43 +0200 > Wolfgang Denk wrote: > >> Dear Scott Wood, >> >> In message <20101007135257.05a93...@udp111988uds.am.freescale.net> you wrote: >> > >> > > It is a pretty common method to use a pointer to some struct (for >> > > example, some form of PDU) and make it point to some I/O buffer. >> > >> > Yes, but at that point we are not talking about well-defined C, but >> > rather implementation-specific behavior. There's nothing wrong with >> > it, but the C standard is no longer authoritative on what happens in >> > such cases. >> >> Huch? Which part of that is not well-defined (or even not >> standard-conforming) C? > > Well, how do you obtain the unaligned pointer? [...] > Extensions like __attribute__((packed)) are obviously not > well-defined C. In ISO-IEC9899:TC3[1] I find this about dereferencing a pointer: ,[ 6.5.3.2 footnote 87 ] | [...] | Among the invalid values for dereferencing a pointer by the unary * | operator are a null pointer, an address inappropriately aligned for the | type of object pointed to, and the address of an object after the end of | its lifetime. ` So dereferencing such a pointer - however we arrive at it - is simply invalid. The same sentence is in the ANSI spec[2] also. The C FAQ[3] notes in section 16.8 that using unaligned pointers may very well lead to segmentation faults, bus errors or general protection faults. Not much documentation actually... Cheers Detlev [1] http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf [2] http://flash-gordon.me.uk/ansi.c.txt [3] http://www.c-faq.com/versions.html -- ... the tools we are trying to use and the language or notation we are using to express or record our thoughts, are the major factors determining what we can think or express at all! -- Edsger W. Dijkstra -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/2] [NEXT] edminiv2: enable relocation
Dear Albert Aribaud, In message <1285271364-21302-2-git-send-email-albert.arib...@free.fr> you wrote: > > Signed-off-by: Albert Aribaud > --- > board/LaCie/edminiv2/config.mk |3 ++- > include/configs/edminiv2.h |6 ++ > 2 files changed, 8 insertions(+), 1 deletions(-) Is it correct to assume this patch has been obsoleted by the recent "[ELF_RELOC] [PATCH V3 2/2] edminiv2: add support for ELF" submission? If yes, then how about the other part of this series, "[PATCH V2 1/2] [NEXT] orion5x: fix relocation-incompatible c..." ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Very ugly or very beautiful women should be flattered on their understanding, and mediocre ones on their beauty. -- Philip Earl of Chesterfield ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ELF_RELOC] [PATCH V3 2/2] edminiv2: add support for ELF relocations
Dear Albert Aribaud, In message <1286795609-6754-2-git-send-email-albert.arib...@free.fr> you wrote: > > Signed-off-by: Albert Aribaud > --- > board/LaCie/edminiv2/config.mk |4 ++-- > include/configs/edminiv2.h |5 + > 2 files changed, 7 insertions(+), 2 deletions(-) Applied to "u-boot-arm" repository, "elf_reloc" branch. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Just Say No." - Nancy Reagan "No."- Ronald Reagan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ELF_RELOC] [PATCH V3 1/2] arm: implement ELF relocations
Dear Albert Aribaud, In message <1286795609-6754-1-git-send-email-albert.arib...@free.fr> you wrote: > ELF relocation tables generated with linker option -pie can > be used to fixup code and data in a single loop at relocation, > removing the need for manual fixups anywhere else in the code. > > Signed-off-by: Albert Aribaud > --- > This patch set is intended for the ELF relocation branch, not > for master or next! > > V1Initial submission after RFC > V2Removed useless datarel references and sections > Defined CONFIG_RELOC_FIXUP_WORKS for all ARMs > Removed useless define of CONFIG_RELOC_FIXUP_WORKS > and undefine of CONFIG_SYS_ARM_WITHOUT_RELOC from > edminiv2 board > V3Fixed missing end-of-line > > arch/arm/config.mk| 10 +- > arch/arm/cpu/arm926ejs/start.S| 164 ++- > arch/arm/cpu/arm926ejs/u-boot.lds | 26 +++-- > arch/arm/include/asm/config.h |2 - > arch/arm/include/asm/u-boot-arm.h | 14 +- > arch/arm/lib/board.c |8 +- > doc/README.arm-relocation | 222 > +++-- > 7 files changed, 156 insertions(+), 290 deletions(-) Applied to "u-boot-arm" repository, "elf_reloc" branch. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de This message was made from 100% recycled electrons. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ELF_RELOC] [PATCH V3 1/2] arm: implement ELF relocations
ELF relocation tables generated with linker option -pie can be used to fixup code and data in a single loop at relocation, removing the need for manual fixups anywhere else in the code. Signed-off-by: Albert Aribaud --- This patch set is intended for the ELF relocation branch, not for master or next! V1 Initial submission after RFC V2 Removed useless datarel references and sections Defined CONFIG_RELOC_FIXUP_WORKS for all ARMs Removed useless define of CONFIG_RELOC_FIXUP_WORKS and undefine of CONFIG_SYS_ARM_WITHOUT_RELOC from edminiv2 board V3 Fixed missing end-of-line arch/arm/config.mk| 10 +- arch/arm/cpu/arm926ejs/start.S| 164 ++- arch/arm/cpu/arm926ejs/u-boot.lds | 26 +++-- arch/arm/include/asm/config.h |2 - arch/arm/include/asm/u-boot-arm.h | 14 +- arch/arm/lib/board.c |8 +- doc/README.arm-relocation | 222 +++-- 7 files changed, 156 insertions(+), 290 deletions(-) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 6923f6d..0be47d3 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -33,11 +33,6 @@ STANDALONE_LOAD_ADDR = 0xc10 endif endif -ifndef CONFIG_SYS_ARM_WITHOUT_RELOC -# needed for relocation -PLATFORM_RELFLAGS += -fPIC -endif - ifdef CONFIG_SYS_ARM_WITHOUT_RELOC PLATFORM_CPPFLAGS += -DCONFIG_SYS_ARM_WITHOUT_RELOC endif @@ -72,3 +67,8 @@ PLATFORM_LIBS += $(OBJTREE)/arch/arm/lib/eabi_compat.o endif endif LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds + +ifndef CONFIG_SYS_ARM_WITHOUT_RELOC +# needed for relocation +PLATFORM_LDFLAGS += -pie +endif diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 16ee972..e5099d0 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -10,6 +10,7 @@ * Copyright (c) 2002 Gary Jennejohn * Copyright (c) 2003 Richard Woodruff * Copyright (c) 2003 Kshitij + * Copyright (c) 2010 Albert Aribaud * * See file CREDITS for list of people who contributed to this * project. @@ -118,22 +119,19 @@ _fiq: _TEXT_BASE: .word TEXT_BASE -#if defined(CONFIG_SYS_ARM_WITHOUT_RELOC) -.globl _armboot_start -_armboot_start: - .word _start -#endif - /* * These are defined in the board-specific linker script. + * Subtracting _start from them lets the linker put their + * relative position in the executable instead of leaving + * them null. */ -.globl _bss_start -_bss_start: - .word __bss_start +.globl _bss_start_ofs +_bss_start_ofs: + .word __bss_start - _start -.globl _bss_end -_bss_end: - .word _end +.globl _bss_end_ofs +_bss_end_ofs: + .word _end - _start #ifdef CONFIG_USE_IRQ /* IRQ stack memory (calculated at run-time) */ @@ -153,30 +151,6 @@ FIQ_STACK_START: IRQ_STACK_START_IN: .word 0x0badc0de -.globl _datarel_start -_datarel_start: - .word __datarel_start - -.globl _datarelrolocal_start -_datarelrolocal_start: - .word __datarelrolocal_start - -.globl _datarellocal_start -_datarellocal_start: - .word __datarellocal_start - -.globl _datarelro_start -_datarelro_start: - .word __datarelro_start - -.globl _got_start -_got_start: - .word __got_start - -.globl _got_end -_got_end: - .word __got_end - /* * the actual reset code */ @@ -226,9 +200,8 @@ stack_setup: adr r0, _start ldr r2, _TEXT_BASE - ldr r3, _bss_start - sub r2, r3, r2 /* r2 <- size of armboot*/ - add r2, r0, r2 /* r2 <- source end address */ + ldr r3, _bss_start_ofs + add r2, r0, r3 /* r2 <- source end address */ cmp r0, r6 beq clear_bss @@ -240,36 +213,54 @@ copy_loop: ble copy_loop #ifndef CONFIG_PRELOADER - /* fix got entries */ - ldr r1, _TEXT_BASE /* Text base */ - mov r0, r7 /* reloc addr */ - ldr r2, _got_start /* addr in Flash */ - ldr r3, _got_end/* addr in Flash */ - sub r3, r3, r1 - add r3, r3, r0 - sub r2, r2, r1 - add r2, r2, r0 - + /* +* fix .rel.dyn relocations +*/ + ldr r0, _TEXT_BASE /* r0 <- Text base */ + sub r9, r7, r0 /* r9 <- relocation offset */ + ldr r10, _dynsym_start_ofs /* r10 <- sym table ofs */ + add r10, r10, r0/* r10 <- sym table in FLASH */ + ldr r2, _rel_dyn_start_ofs /* r2 <- rel dyn start ofs */ + add r2, r2, r0 /* r2 <- rel dyn start in FLASH */ + ldr r3, _rel_dyn_end_ofs/* r3 <- rel dyn end ofs */ + add r3, r3, r0 /* r3 <- rel dyn end in FLASH */ fixloop: - ldr r4, [r2] - sub r4, r4, r1 - add r4, r4,
[U-Boot] [ELF_RELOC] [PATCH V3 2/2] edminiv2: add support for ELF relocations
Signed-off-by: Albert Aribaud --- board/LaCie/edminiv2/config.mk |4 ++-- include/configs/edminiv2.h |5 + 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/board/LaCie/edminiv2/config.mk b/board/LaCie/edminiv2/config.mk index 3dec1aa..bf3581d 100644 --- a/board/LaCie/edminiv2/config.mk +++ b/board/LaCie/edminiv2/config.mk @@ -23,5 +23,5 @@ # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, # MA 02110-1301 USA # - -TEXT_BASE = 0x0010 +# TEXT_BASE must equal the intended FLASH location of u-boot. +TEXT_BASE = 0xfff9 diff --git a/include/configs/edminiv2.h b/include/configs/edminiv2.h index ccfc660..43e5e87 100644 --- a/include/configs/edminiv2.h +++ b/include/configs/edminiv2.h @@ -223,4 +223,9 @@ #define CONFIG_SYS_RESET_ADDRESS 0x #define CONFIG_SYS_MAXARGS 16 +/* additions for new relocation code, must be added to all boards */ +#define CONFIG_SYS_SDRAM_BASE 0 +#define CONFIG_SYS_INIT_SP_ADDR\ + (CONFIG_SYS_SDRAM_BASE + 0x1000 - CONFIG_SYS_GBL_DATA_SIZE) + #endif /* _CONFIG_EDMINIV2_H */ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: seperate block number into small parts for multi-write cmd
Dear Lei Wen,
> Ok, I am also fine with not include the 512KiB restriction.
> So we comes to a conclusion that we still use v1 patch, but cut the
> 512KiB limitation?
Considering the comments that were given to that one, yes.
> As mmc host limitation, the max number of block in one go
> should be limited to 65535, and the max buffer size should
> not excceed 512k bytes.
Better reads somehow like this:
Since some hardware has a 16 bit block counter, split the multiple block
write into a maximum of (2**16 - 1) blocks to be written at one go.
>
> Signed-off-by: Lei Wen
> ---
> drivers/mmc/mmc.c | 56 +---
> 1 files changed, 35 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 94d1ac2..ea398a5 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -77,29 +77,16 @@ struct mmc *find_mmc_device(int dev_num)
> return NULL;
> }
>
> -static ulong
> -mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt, const void*src)
> +int mmc_write_block(struct mmc *mmc, ulong *src, ulong start, uint blocknum)
should be:
static ulong mmc_write_blocks(struct_mmc *mmc, ulong start, lbaint_t blkcnt,
const void*src)
(keep parameter types and attributes (const) intact and similar to mmc_bwrite)
> {
> struct mmc_cmd cmd;
> struct mmc_data data;
> - int err;
> - int stoperr = 0;
> - struct mmc *mmc = find_mmc_device(dev_num);
> - int blklen;
> -
> - if (!mmc)
> - return -1;
> -
> + int blklen, err;
> blklen = mmc->write_bl_len;
>
> - err = mmc_set_blocklen(mmc, mmc->write_bl_len);
> -
> - if (err) {
> - printf("set write bl len failed\n\r");
> - return err;
> - }
> -
> - if (blkcnt > 1)
> + BUG_ON(blklen * blocknum > 524288);
> + BUG_ON(blocknum > 65535);
remove the BUG_ONs
> + if (blocknum > 1)
> cmd.cmdidx = MMC_CMD_WRITE_MULTIPLE_BLOCK;
> else
> cmd.cmdidx = MMC_CMD_WRITE_SINGLE_BLOCK;
> @@ -113,7 +100,7 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt,
> const void*src)
> cmd.flags = 0;
>
> data.src = src;
> - data.blocks = blkcnt;
> + data.blocks = blocknum;
that change not necessary when above parameters are kept.
> data.blocksize = blklen;
> data.flags = MMC_DATA_WRITE;
>
> @@ -124,14 +111,41 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt,
> const void*src)
> return err;
> }
>
> - if (blkcnt > 1) {
> + if (blocknum > 1) {
same here.
> cmd.cmdidx = MMC_CMD_STOP_TRANSMISSION;
> cmd.cmdarg = 0;
> cmd.resp_type = MMC_RSP_R1b;
> cmd.flags = 0;
> - stoperr = mmc_send_cmd(mmc, &cmd, NULL);
> + mmc_send_cmd(mmc, &cmd, NULL);
should be not keep checking the result for errors?
> }
>
> + return blocknum;
> +}
> +
> +static ulong
> +mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt, const void*src)
> +{
> + int err;
> + struct mmc *mmc = find_mmc_device(dev_num);
> + unsigned int max;
keep related variables the same type: lbainit_t
> + lbaint_t tmp = blkcnt, cur;
tmp is better named: blocks_todo
put cur into the loop
> +
> + if (!mmc)
> + return -1;
> +
> + err = mmc_set_blocklen(mmc, mmc->write_bl_len);
> + if (err) {
> + printf("set write bl len failed\n\r");
> + return err;
> + }
> +
> + max = 524288 / mmc->write_bl_len;
remove
> + do {
> + cur = (tmp > max) ? max : tmp;
lbaint_t chunk = blocks_todo;
if (chunk > 65535)
chunk = 65535;
> + tmp -= cur;
do that at end of loop
> + if(mmc_write_block(mmc, src, start, cur) != cur)
if (mmc_write_blocks(mmc, start, chunk, src) != chunk)
> + return -1;
I think src, start should be adjusted, too...
src += chunk * mmc->write_bl_len;
start += chunk;
blocks_todo -= chunk;
> + } while (blocks_todo > 0);
> return blkcnt;
> }
>
could the functions be reordered such that diff does not mess up so much?
It would be easier to read if the really new function would not be diffed
with the existing function and the modified existing function not seen as
a new one.
I had similar issues with one of my patches and reordered the functions so
diff did "see" it the way it should be... even if that requires a forward
declaration.
Best Regards
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [NEXT]arm: Make jadecpu use relocation
Hello Wolfgang Am 05.10.2010 20:41, schrieb Wolfgang Denk: > Dear Matthias Weisser, >> -gd->bd->bi_dram[0].start = PHYS_SDRAM; >> -gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE; >> +/* dram_init must store complete ramsize in gd->ram_size */ >> +gd->ram_size = get_ram_size((volatile void *)PHYS_SDRAM, >> +PHYS_SDRAM_SIZE); > > Unfortunately this breaks building for this board: > > jadecpu.c: In function 'dram_init': > jadecpu.c:158: error: 'gd_t' has no member named 'ram_size' > jadecpu.c: In function 'dram_init_banksize': > jadecpu.c:167: error: 'gd_t' has no member named 'ram_size' > > Can you please provide a fix? Thanks. I am not sure how to fix this. gd_t contains a member ram_size if CONFIG_SYS_ARM_WITHOUT_RELOC is not defined. This is the case for our jadecpu board. Also the patch is in current master branch and builds cleanly here. Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] Rename TEXT_BASE into CONFIG_SYS_TEXT_BASE
The change is currently needed to be able to remove the board configuration scripting from the top level Makefile and replace it by a simple, table driven script. Moving this configuration setting into the "CONFIG_*" name space is also desirable because it is needed if we ever should move forward to a Kconfig driven configuration system. Signed-off-by: Wolfgang Denk --- Makefile| 102 +++--- README |2 +- arch/arm/cpu/arm1136/start.S|2 +- arch/arm/cpu/arm1176/start.S|6 +- arch/arm/cpu/arm720t/start.S|8 +- arch/arm/cpu/arm920t/at91/lowlevel_init.S |4 +- arch/arm/cpu/arm920t/at91rm9200/lowlevel_init.S |4 +- arch/arm/cpu/arm920t/start.S|2 +- arch/arm/cpu/arm925t/start.S|2 +- arch/arm/cpu/arm926ejs/at91/lowlevel_init.S |4 +- arch/arm/cpu/arm926ejs/start.S |2 +- arch/arm/cpu/arm946es/start.S |2 +- arch/arm/cpu/arm_intcm/start.S |2 +- arch/arm/cpu/armv7/omap3/lowlevel_init.S|2 +- arch/arm/cpu/armv7/start.S |2 +- arch/arm/cpu/ixp/start.S|2 +- arch/arm/cpu/lh7a40x/start.S|2 +- arch/arm/cpu/pxa/start.S|2 +- arch/arm/cpu/s3c44b0/start.S|2 +- arch/arm/cpu/sa1100/start.S |2 +- arch/i386/lib/board.c |4 +- arch/m68k/cpu/mcf5227x/start.S | 10 +- arch/m68k/cpu/mcf52x2/start.S | 14 ++-- arch/m68k/cpu/mcf5445x/start.S |8 +- arch/microblaze/cpu/start.S |4 +- arch/microblaze/lib/board.c |2 +- arch/powerpc/cpu/mpc85xx/start.S| 18 ++-- arch/powerpc/cpu/mpc86xx/start.S|4 +- arch/powerpc/lib/board.c|2 +- arch/sh/config.mk |2 +- arch/sh/lib/board.c |2 +- arch/sparc/cpu/leon2/Makefile |5 +- arch/sparc/cpu/leon2/prom.c |4 +- arch/sparc/cpu/leon2/start.S|2 +- arch/sparc/cpu/leon3/Makefile |5 +- arch/sparc/cpu/leon3/prom.c |4 +- arch/sparc/cpu/leon3/start.S|6 +- arch/sparc/include/asm/asmmacro.h |4 +- board/BuS/EB+MCF-EV123/EB+MCF-EV123.c |2 +- board/BuS/EB+MCF-EV123/config.mk|4 +- board/BuS/EB+MCF-EV123/textbase.mk |2 +- board/BuS/eb_cpux9k2/config.mk |2 +- board/LEOX/elpt860/config.mk|4 +- board/LaCie/edminiv2/config.mk |2 +- board/Marvell/db64360/config.mk |2 +- board/Marvell/db64460/config.mk |2 +- board/Marvell/guruplug/config.mk|2 +- board/Marvell/mv88f6281gtw_ge/config.mk |2 +- board/Marvell/openrd_base/config.mk |2 +- board/Marvell/rd6281a/config.mk |2 +- board/Marvell/sheevaplug/config.mk |2 +- board/RPXClassic/config.mk |2 +- board/RPXlite/config.mk |2 +- board/RPXlite_dw/config.mk |2 +- board/RRvision/config.mk|2 +- board/a3000/config.mk |4 +- board/actux1/config.mk |2 +- board/actux2/config.mk |2 +- board/actux3/config.mk |2 +- board/actux4/config.mk |2 +- board/adder/config.mk |2 +- board/afeb9260/config.mk|2 +- board/alaska/config.mk |7 +- board/altera/nios2-generic/config.mk|2 +- board/amcc/acadia/config.mk |4 +- board/amcc/bamboo/config.mk |4 +- board/amcc/bluestone/config.mk |4 +- board/amcc/bubinga/config.mk|2 +- board/amcc/canyonlands/config.mk|4 +- board/amcc/ebony/config.mk |6 +- board/amcc/katmai/config.mk |2 +- board/amcc/kilauea/config.mk|4 +- board/amcc/luan/config.mk |6 +- board/amcc/makalu/config.mk |2 +- board/amcc/ocotea/config.mk |6 +- board/amcc/redwood/config.mk|4 +- board/amcc/sequoia/config.mk|4 +- board/amcc/taihu/config.mk |2
[U-Boot] [PATCH 2/3] mkconfig: change CONFIG_MK_ prefix into plain CONFIG_
When planning for more generalization and Makefile cleanup it became
obvious that the introduction of a separate CONFIG_MK_ name space for
config options that were set through scripting in the Makefile was
not a good idea.
Originally the idea was to provide a script-free approach to supply
configuration options - there was no real need for a separate name
space. But when we now convert the existing Makefile entries to make
use of this approach, it would mean that we have to touch a large
number of board config files and add #ifdef / #define sequences to
"convert" from the CONFIG_MK_ to the CONFIG_ name space.
It seems much cleaner to get rid of this somewhat arbitrary _MK
string now for the few boards that actually use it.
Signed-off-by: Wolfgang Denk
---
board/bf527-ezkit/video.c | 10 +-
board/freescale/mpc8315erdb/config.mk |2 +-
board/freescale/mpc8536ds/config.mk |6 +++---
board/freescale/mpc8569mds/config.mk |2 +-
board/freescale/p1_p2_rdb/config.mk |6 +++---
include/configs/MPC8315ERDB.h |2 +-
include/configs/MPC8536DS.h |8
include/configs/MPC8569MDS.h |4 ++--
include/configs/MPC8572DS.h |2 +-
include/configs/P1_P2_RDB.h | 14 +++---
include/configs/P2020DS.h |4 ++--
include/configs/SBC8540.h |2 +-
include/configs/astro_mcf5373l.h |4 ++--
include/configs/bf527-ezkit.h |2 +-
include/configs/edb93xx.h | 16
include/configs/sbc8349.h |8 ++--
include/configs/sbc8548.h |9 -
include/configs/sbc8560.h |2 +-
include/configs/spear3xx.h|6 +++---
include/configs/vme8349.h |2 +-
mkconfig |2 +-
21 files changed, 54 insertions(+), 59 deletions(-)
diff --git a/board/bf527-ezkit/video.c b/board/bf527-ezkit/video.c
index 87e7658..ca5e9b0 100644
--- a/board/bf527-ezkit/video.c
+++ b/board/bf527-ezkit/video.c
@@ -24,7 +24,7 @@
#define LCD_Y_RES 240 /* Vertical Resolution */
#define DMA_BUS_SIZE 16
-#ifdef CONFIG_MK_BF527_EZKIT_REV_2_1 /* lq035q1 */
+#ifdef CONFIG_BF527_EZKIT_REV_2_1 /* lq035q1 */
#if !defined(CONFIG_LQ035Q1_USE_RGB888_8_BIT_PPI) && \
!defined(CONFIG_LQ035Q1_USE_RGB565_8_BIT_PPI)
@@ -125,7 +125,7 @@
#define PPI_PACK_EN0x80
#define PPI_POLS_1 0x8000
-#ifdef CONFIG_MK_BF527_EZKIT_REV_2_1
+#ifdef CONFIG_BF527_EZKIT_REV_2_1
static struct spi_slave *slave;
static int lq035q1_control(unsigned char reg, unsigned short value)
{
@@ -305,7 +305,7 @@ void EnableTIMER12(void)
int video_init(void *dst)
{
-#ifdef CONFIG_MK_BF527_EZKIT_REV_2_1
+#ifdef CONFIG_BF527_EZKIT_REV_2_1
lq035q1_control(LQ035_SHUT_CTL, LQ035_ON);
lq035q1_control(LQ035_DRIVER_OUTPUT_CTL, (CONFIG_LQ035Q1_LCD_MODE &
LQ035_DRIVER_OUTPUT_MASK) | LQ035_DRIVER_OUTPUT_DEFAULT);
@@ -318,7 +318,7 @@ int video_init(void *dst)
Init_PPI();
EnablePPI();
-#ifdef CONFIG_MK_BF527_EZKIT_REV_2_1
+#ifdef CONFIG_BF527_EZKIT_REV_2_1
EnableTIMER12();
#else
/* Frame sync 2 (VS) needs to start at least one PPI clk earlier */
@@ -388,7 +388,7 @@ void video_stop(void)
DisableDMA();
DisableTIMER0();
DisableTIMER1();
-#ifdef CONFIG_MK_BF527_EZKIT_REV_2_1
+#ifdef CONFIG_BF527_EZKIT_REV_2_1
lq035q1_control(LQ035_SHUT_CTL, LQ035_SHUT);
#endif
}
diff --git a/board/freescale/mpc8315erdb/config.mk
b/board/freescale/mpc8315erdb/config.mk
index bf972fb..b601601 100644
--- a/board/freescale/mpc8315erdb/config.mk
+++ b/board/freescale/mpc8315erdb/config.mk
@@ -1,5 +1,5 @@
ifndef NAND_SPL
-ifeq ($(CONFIG_MK_NAND), y)
+ifeq ($(CONFIG_NAND), y)
TEXT_BASE = $(CONFIG_RAMBOOT_TEXT_BASE)
endif
endif
diff --git a/board/freescale/mpc8536ds/config.mk
b/board/freescale/mpc8536ds/config.mk
index 3f5447a..ac15ff3 100644
--- a/board/freescale/mpc8536ds/config.mk
+++ b/board/freescale/mpc8536ds/config.mk
@@ -24,18 +24,18 @@
# mpc8536ds board
#
ifndef NAND_SPL
-ifeq ($(CONFIG_MK_NAND), y)
+ifeq ($(CONFIG_NAND), y)
TEXT_BASE = $(CONFIG_RAMBOOT_TEXT_BASE)
LDSCRIPT := $(TOPDIR)/$(CPUDIR)/u-boot-nand.lds
endif
endif
-ifeq ($(CONFIG_MK_SDCARD), y)
+ifeq ($(CONFIG_SDCARD), y)
TEXT_BASE = $(CONFIG_RAMBOOT_TEXT_BASE)
RESET_VECTOR_ADDRESS = 0xf8fc
endif
-ifeq ($(CONFIG_MK_SPIFLASH), y)
+ifeq ($(CONFIG_SPIFLASH), y)
TEXT_BASE = $(CONFIG_RAMBOOT_TEXT_BASE)
RESET_VECTOR_ADDRESS = 0xf8fc
endif
diff --git a/board/freescale/mpc8569mds/config.mk
b/board/freescale/mpc8569mds/config.mk
index 86f138c..4f7e18d 100644
--- a/board/freescale/mpc8569mds/config.mk
+++ b/board/freescale/mpc8569mds/config.mk
@@ -24,7 +24,7 @@
# mpc8569mds board
#
ifndef NAND_SPL
-ifeq ($(CONFIG_MK_NAND), y)
+ifeq ($(CONFIG_NAND), y)
TEXT_BASE = $(CONFIG_RAMBOOT_TEXT_BASE)
LDSCRIPT
[U-Boot] [PATCH 1/3] Build: Add "board options" column to boards.cfg
From: Marek Vasut
There are some boards where it's currently not possible to detect all
board information at runtime, therefore a new column was added to
boards.cfg .
This column can contain multiple options: a board configuration name,
optionally followed by a colon (':') and a list of options, which are
separated by comma (',').
In case of simple options like '256M_U_BOOT', these expand to
"#define CONFIG_MK_256M_U_BOOT 1" in config.h . In case of
assignments like 'RAM=8192', these expand to "#define CONFIG_MK_RAM
8192" in config.h .
Example:
FOO:HAS_BAR,BAZ=64
means:
- the name of the board config file is include/configs/FOO.h
- the generated file include/config.h will contain these
lines:
#define CONFIG_HAS_BAR 1
#define CONFIG_BAZ 64
Signed-off-by: Marek Vasut
[...@denx.de: edited commit message; added code to deal with an
optional board configuration name]
Signed-off-by: Wolfgang Denk
---
boards.cfg |4 ++--
mkconfig | 34 +-
2 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/boards.cfg b/boards.cfg
index 91d75d3..1f44525 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -17,8 +17,8 @@
#
# :.,$! sort -f -k2,2 -k3,3 -k6,6 -k5,5 -k1,1
#
-# Target ARCHCPU Board name Vendor SoC
-###
+# Target ARCHCPU Board name Vendor SoC
Options
+###
qong arm arm1136 - davedenxmx31
mx31adsarm arm1136 - freescale
mx31
diff --git a/mkconfig b/mkconfig
index b661071..f3054ce 100755
--- a/mkconfig
+++ b/mkconfig
@@ -5,7 +5,7 @@
#
# Parameters: Target Architecture CPU Board [VENDOR] [SOC]
#
-# (C) 2002-2006 DENX Software Engineering, Wolfgang Denk
+# (C) 2002-2010 DENX Software Engineering, Wolfgang Denk
#
APPEND=no # Default: Create new config file
@@ -17,6 +17,7 @@ cpu=""
board=""
vendor=""
soc=""
+options=""
if [ \( $# -eq 2 \) -a \( "$1" = "-A" \) ] ; then
# Automatic mode
@@ -41,11 +42,12 @@ while [ $# -gt 0 ] ; do
done
[ $# -lt 4 ] && exit 1
-[ $# -gt 6 ] && exit 1
+[ $# -gt 7 ] && exit 1
+# Strip all options and/or _config suffixes
CONFIG_NAME="${1%_config}"
-[ "${BOARD_NAME}" ] || BOARD_NAME="${CONFIG_NAME}"
+[ "${BOARD_NAME}" ] || BOARD_NAME="${1%_config}"
arch="$2"
cpu="$3"
@@ -56,13 +58,34 @@ else
fi
[ $# -gt 4 ] && [ "$5" != "-" ] && vendor="$5"
[ $# -gt 5 ] && [ "$6" != "-" ] && soc="$6"
+[ $# -gt 6 ] && [ "$7" != "-" ] && {
+ # check if we have a board config name in the options field
+ # the options field mave have a board config name and a list
+ # of options, both separated by a colon (':'); the options are
+ # separated by commas (',').
+ #
+ # Check for board name
+ tmp="${7%:*}"
+ if [ "$tmp" ] ; then
+ CONFIG_NAME="$tmp"
+ fi
+ # Check if we only have a colon...
+ if [ "${tmp}" != "$7" ] ; then
+ options=${7#*:}
+ TARGETS="`echo ${options} | sed 's:,: :g'` ${TARGETS}"
+ fi
+}
if [ "${ARCH}" -a "${ARCH}" != "${arch}" ]; then
echo "Failed: \$ARCH=${ARCH}, should be '${arch}' for ${BOARD_NAME}"
1>&2
exit 1
fi
-echo "Configuring for ${BOARD_NAME} board..."
+if [ "$options" ] ; then
+ echo "Configuring for ${BOARD_NAME} - Board: ${CONFIG_NAME}, Options:
${options}"
+else
+ echo "Configuring for ${BOARD_NAME} board..."
+fi
#
# Create link to architecture specific headers
@@ -126,7 +149,8 @@ fi
echo "/* Automatically generated - do not edit */" >>config.h
for i in ${TARGETS} ; do
- echo "#define CONFIG_MK_${i} 1" >>config.h ;
+ i="`echo ${i} | sed '/=/ {s/=/\t/;q } ; { s/$/\t1/ }'`"
+ echo "#define CONFIG_MK_${i}" >>config.h ;
done
cat << EOF >> config.h
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] Makefile cleanup
The following series of patches prepares the ground to move the
remaining board configuration entries out of the Makefile into the
boards.cfg file, replacing multi-line scripts to fiddle with config.h
and config.mk files into simple, single-line entries.
[PATCH 1/3] Build: Add "board options" column to boards.cfg
Build: Add "board options" column to boards.cfg
There are some boards where it's currently not possible to detect all
board information at runtime, therefore a new column was added to
boards.cfg .
This column can contain multiple options: a board configuration name,
optionally followed by a colon (':') and a list of options, which are
separated by comma (',').
In case of simple options like '256M_U_BOOT', these expand to
"#define CONFIG_MK_256M_U_BOOT 1" in config.h . In case of
assignments like 'RAM=8192', these expand to "#define CONFIG_MK_RAM
8192" in config.h .
Example:
FOO:HAS_BAR,BAZ=64
means:
- the name of the board config file is include/configs/FOO.h
- the generated file include/config.h will contain these
lines:
#define CONFIG_HAS_BAR 1
#define CONFIG_BAZ 64
Signed-off-by: Marek Vasut
[...@denx.de: edited commit message; added code to deal with an
optional board configuration name]
Signed-off-by: Wolfgang Denk
2 files changed, 31 insertions(+), 7 deletions(-)
[PATCH 2/3] mkconfig: change CONFIG_MK_ prefix into plain CONFIG_
mkconfig: change CONFIG_MK_ prefix into plain CONFIG_
When planning for more generalization and Makefile cleanup it became
obvious that the introduction of a separate CONFIG_MK_ name space for
config options that were set through scripting in the Makefile was
not a good idea.
Originally the idea was to provide a script-free approach to supply
configuration options - there was no real need for a separate name
space. But when we now convert the existing Makefile entries to make
use of this approach, it would mean that we have to touch a large
number of board config files and add #ifdef / #define sequences to
"convert" from the CONFIG_MK_ to the CONFIG_ name space.
It seems much cleaner to get rid of this somewhat arbitrary _MK
string now for the few boards that actually use it.
Signed-off-by: Wolfgang Denk
21 files changed, 54 insertions(+), 59 deletions(-)
[PATCH 3/3] Rename TEXT_BASE into CONFIG_SYS_TEXT_BASE
Rename TEXT_BASE into CONFIG_SYS_TEXT_BASE
The change is currently needed to be able to remove the board
configuration scripting from the top level Makefile and replace it by
a simple, table driven script.
Moving this configuration setting into the "CONFIG_*" name space is
also desirable because it is needed if we ever should move forward to
a Kconfig driven configuration system.
Signed-off-by: Wolfgang Denk
799 files changed, 1494 insertions(+), 1436 deletions(-)
Potential testers can find these (and some more experimental) commits
in the "Makefile-cleanup" branch in the u-boot-testing repository.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Brontosaurus Principle: Organizations can grow faster than their
brains can manage them in relation to their environment and to their
own physiology: when this occurs, they are an endangered species.
- Thomas K. Connellan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] mmc: seperate block number into small parts for multi-write cmd
On Mon, Oct 11, 2010 at 5:22 PM, Wolfgang Denk wrote: > Dear Reinhard Meyer, > > In message <4cb2d225.6020...@emk-elektronik.de> you wrote: >> >> After thinking alot about this: >> Preface: (for understanding of the issue) > > Thanks!! > >> I see two possible solutions for that problem here: >> 1. generally limit the number of blocks requested to 65535. The performance >> penalty for that is insignificant. (65535 blocks are about 32 MiB) >> 2. limit it on a case by case basis by passing such limit like a host >> capability to the high level part. >> >> Here I would (after much deliberation) favour version 1. > > I agree. Implementing 2) is not worth the effort or the code. 32 MiB > should be enough in most practical cases, and even for really big > transfers it is a more than appropriate chunk size. > >> The second and more serious problem Lei Wen seems to have with his hardware >> is that DMA seems problematic (how so?) for more than 512 KiB. > > Indeed. So far it is totally unclear to me what sort of restriction > this actually is. If my interpretation is correct, than such DMA > transfers should not cross 512 KiB memory boundaries, so the maximum > transfer size is 512 KiB, but only when you start on a 512 KiB > aligned address. Also my interpretation is that this is not actually > a hard restriction, but only a convenience to avoid handling some DMA > interrupt properly - in Linux. I wonder if this really applied to > U-Boot at all, where we use polling instead. > >> I really don't see that we should pull such (unusual?) limitations into the >> high level part. I think the low level driver could issue several DMA >> transfers in that case. > > Again I agree. thi is a low-level, controller specific detail, which > should not affect any upper-layer code. It should be completely hidden > in the controller specific driver code. > >> We need concensus here first before we can issue and comment patches. > > I think both of us agree. We just need to convince Lei Wen... Ok, I am also fine with not include the 512KiB restriction. So we comes to a conclusion that we still use v1 patch, but cut the 512KiB limitation? Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] mmc: seperate block number into small parts for multi-write cmd
Dear Reinhard Meyer, In message <4cb2d225.6020...@emk-elektronik.de> you wrote: > > After thinking alot about this: > Preface: (for understanding of the issue) Thanks!! > I see two possible solutions for that problem here: > 1. generally limit the number of blocks requested to 65535. The performance > penalty for that is insignificant. (65535 blocks are about 32 MiB) > 2. limit it on a case by case basis by passing such limit like a host > capability to the high level part. > > Here I would (after much deliberation) favour version 1. I agree. Implementing 2) is not worth the effort or the code. 32 MiB should be enough in most practical cases, and even for really big transfers it is a more than appropriate chunk size. > The second and more serious problem Lei Wen seems to have with his hardware > is that DMA seems problematic (how so?) for more than 512 KiB. Indeed. So far it is totally unclear to me what sort of restriction this actually is. If my interpretation is correct, than such DMA transfers should not cross 512 KiB memory boundaries, so the maximum transfer size is 512 KiB, but only when you start on a 512 KiB aligned address. Also my interpretation is that this is not actually a hard restriction, but only a convenience to avoid handling some DMA interrupt properly - in Linux. I wonder if this really applied to U-Boot at all, where we use polling instead. > I really don't see that we should pull such (unusual?) limitations into the > high level part. I think the low level driver could issue several DMA > transfers in that case. Again I agree. thi is a low-level, controller specific detail, which should not affect any upper-layer code. It should be completely hidden in the controller specific driver code. > We need concensus here first before we can issue and comment patches. I think both of us agree. We just need to convince Lei Wen... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de For every problem there is one solution which is simple, neat, and wrong.- H. L. Mencken ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Followup: GCC-4.3.5 and U-Boot (arm, reloc) not working
Reinhard Meyer schrieb: > Hello, > > I just have built gcc-4.3.5 for arm-eabi. When I compile u-boot with it, > it stops after the DRAM: 64 MiB. I _assume_ that relocation does not work. > > I do not have time right now to further investigate this issue, but if > someone else finds the same problem, this might be an issue worth > investigating. Followup: Kernel compiles and works with gcc 4.3.5 Linux version 2.6.36-rc7+ (reinh...@sieb) (gcc version 4.3.5 (Buildroot 2010.11-git) ) #1 Mon Oct 11 10:37:52 CEST 2010 That _could_ indicate that the ARM u-boot relocation method is toolchain sensitive. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] mmc: seperate block number into small parts for multi-write cmd
Dear Lei Wen, > As suggested by Reinhard, I add two additional member in mmc structure, > so that we could specify its value in each driver. If that value is 0, then > the behavior would be the same as original, as no seperation. After thinking alot about this: Preface: (for understanding of the issue) The high level "driver/part" mmc.c prepares a command structure, a data structure and passes them to the hardware dependant low level driver: err = mmc_send_cmd(mmc, &cmd, &data); I agree that it would be improper for the low level driver to split that command into several commands on its own when the data length cannot be handled by the hardware. That would require repeating some of the logic that already exists in the high level part. The low level driver should be and stay as little aware of the command details as possible. Also some hardware really has only a 16 bit wide block counter. That includes ATMEL's MCI, but since the data transfer is programmed in a loop, that register is not used. I see two possible solutions for that problem here: 1. generally limit the number of blocks requested to 65535. The performance penalty for that is insignificant. (65535 blocks are about 32 MiB) 2. limit it on a case by case basis by passing such limit like a host capability to the high level part. Here I would (after much deliberation) favour version 1. The second and more serious problem Lei Wen seems to have with his hardware is that DMA seems problematic (how so?) for more than 512 KiB. I really don't see that we should pull such (unusual?) limitations into the high level part. I think the low level driver could issue several DMA transfers in that case. We need concensus here first before we can issue and comment patches. With Best Regards to All, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: musb: only write CLRDATATOG when appropriate
On Friday, August 13, 2010 06:25:05 Sergei Shtylyov wrote: > Remy Bohmer wrote: > > Sergei, do you agree that I apply this patch? > > Well, if it's based on the Linux code... although it still does look > wrong... I don't know. :-) do you have a board you could test on ? otherwise, it seems this patch has stalled and will stay that way ... -mike 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 1/3] FPGA: add support for downloading Lattice bitstream
Wolfgang Denk wrote: > Dear Stefano Babic, > Hi Wolfgang, >> @@ -0,0 +1,3166 @@ >> +/* >> + * (C) Copyright 2010 >> + * Stefano Babic, DENX Software Engineering, sba...@denx.de. >> + * >> + * Porting to u-boot of Lattice ispVME Embedded to >> + * load Lattice's FPGA: >> + * >> + * Copyright 2009 Lattice Semiconductor Corp. > > I read this such that Lattice Semiconductor did the porting to U-Boot, > but is this correct? I though you did that? In that case you > probably want to write something like: > > Porting to U-Boot: > > (C) Copyright 2010 > Stefano Babic, DENX Software Engineering, sba...@denx.de. > > Lattice ispVME Embedded code to load Lattice's FPGA: > > Copyright 2009 Lattice Semiconductor Corp. > > or so? That is correct. I wanted only to state that the original code comes from Lattice, but I was not clear enough in the statement. I will post the patch again ;-) Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 1/2] MTD/SPI: introduce table driven probing
Dear Mike Frysinger, >> NONE of the existing functions work with expansion, so they all get the >> unshifted, full ID buffer. > > err, right. was thinking it also shifted off the manu id byte and not just > the continuation bytes. > > i'll tweak the patch i posted and pull in your ramtron patch. Thanks. > >> If you provide the unshifted buffer to the function, the function should >> get the shift amount as well. Otherwise the function will again have look >> how many 0x7e's to skip > > not really. the probe funcs already know the layout of the idcode, so > starting at a constant offset of 3 is the same as starting at 1. True. I was already contemplating the possibility of one probe function having to deal with different amounts of shift... But this would not work safe in either method right now. (Assuming the unlikely case that 7e 7e 7e 55 and 7e 7e 55 have to be handled by the same probe function...) This would indeed favour passing the unshifted ID buffer for such functions to find out the amount of 7f's. If you favour that, I am game with it. But I will resubmit the ramtron part only when the new probe is in mainline and I have rebased my tree to it. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] sf: ramtron: new spi fram driver
From: Reinhard Meyer
Supports most types that support Read-Id and the FM25H20.
Signed-off-by: Reinhard Meyer
Signed-off-by: Mike Frysinger
---
drivers/mtd/spi/Makefile |1 +
drivers/mtd/spi/ramtron.c| 319 ++
drivers/mtd/spi/spi_flash.c |8 +
drivers/mtd/spi/spi_flash_internal.h |1 +
4 files changed, 329 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/spi/ramtron.c
diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index 4f11b36..a082ca7 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -32,6 +32,7 @@ COBJS-$(CONFIG_SPI_FLASH_SPANSION)+= spansion.o
COBJS-$(CONFIG_SPI_FLASH_SST) += sst.o
COBJS-$(CONFIG_SPI_FLASH_STMICRO) += stmicro.o
COBJS-$(CONFIG_SPI_FLASH_WINBOND) += winbond.o
+COBJS-$(CONFIG_SPI_FRAM_RAMTRON) += ramtron.o
COBJS-$(CONFIG_SPI_M95XXX) += eeprom_m95xxx.o
COBJS := $(COBJS-y)
diff --git a/drivers/mtd/spi/ramtron.c b/drivers/mtd/spi/ramtron.c
new file mode 100644
index 000..171390d
--- /dev/null
+++ b/drivers/mtd/spi/ramtron.c
@@ -0,0 +1,319 @@
+/*
+ * (C) Copyright 2010
+ * Reinhard Meyer, EMK Elektronik, reinhard.me...@emk-elektronik.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/*
+ * Note: RAMTRON SPI FRAMs are ferroelectric, nonvolatile RAMs
+ * with an interface identical to SPI flash devices.
+ * However since they behave like RAM there are no delays or
+ * busy polls required. They can sustain read or write at the
+ * allowed SPI bus speed, which can be 40 MHz for some devices.
+ *
+ * Unfortunately some RAMTRON devices do not have a means of
+ * identifying them. They will leave the SO line undriven when
+ * the READ-ID command is issued. It is therefore mandatory
+ * that the MISO line has a proper pull-up, so that READ-ID
+ * will return a row of 0xff. This 0xff pseudo-id will cause
+ * probes by all vendor specific functions that are designed
+ * to handle it. If the MISO line is not pulled up, READ-ID
+ * could return any random noise, even mimicking another
+ * device.
+ *
+ * We use CONFIG_SPI_FRAM_RAMTRON_NON_JEDEC
+ * to define which device will be assumed after a simple status
+ * register verify. This method is prone to false positive
+ * detection and should therefore be the last to be tried.
+ * Enter it in the last position in the table in spi_flash.c!
+ *
+ * The define CONFIG_SPI_FRAM_RAMTRON_NON_JEDEC both activates
+ * compilation of the special handler and defines the device
+ * to assume.
+ */
+
+#include
+#include
+#include
+#include "spi_flash_internal.h"
+
+/* RAMTRON commands common to all devices */
+#define CMD_RAMTRON_WREN 0x06/* Write Enable */
+#define CMD_RAMTRON_WRDI 0x04/* Write Disable */
+#define CMD_RAMTRON_RDSR 0x05/* Read Status Register */
+#define CMD_RAMTRON_WRSR 0x01/* Write Status Register */
+#define CMD_RAMTRON_READ 0x03/* Read Data Bytes */
+#define CMD_RAMTRON_WRITE 0x02/* Write Data Bytes */
+/* not all have those: */
+#define CMD_RAMTRON_FSTRD 0x0b/* Fast Read (for compatibility - not
used here) */
+#define CMD_RAMTRON_SLEEP 0xb9/* Enter Sleep Mode */
+#define CMD_RAMTRON_RDID 0x9f/* Read ID */
+#define CMD_RAMTRON_SNR0xc3/* Read Serial Number */
+
+/*
+ * Properties of supported FRAMs
+ * Note: speed is currently not used because we have no method to deliver that
+ * value to the upper layers
+ */
+struct ramtron_spi_fram_params {
+ u32 size; /* size in bytes */
+ u8 addr_len; /* number of address bytes */
+ u8 merge_cmd; /* some address bits are in the command byte */
+ u8 id1;/* device ID 1 (family, density) */
+ u8 id2;/* device ID 2 (sub, rev, rsvd) */
+ u32 speed; /* max. SPI clock in Hz */
+ const char *name; /* name for display and/or matching */
+};
+
+struct ramtron_spi_fram {
+ struct spi_flash flash;
+ const struct ramtron_spi_fram_params *params;
+};
+
+static inline struct ramtron_spi_fram *to_ramtron_spi_fram(struct spi_flash
+
[U-Boot] [PATCH 1/2] sf: turn probe switch into a lookup table
From: Reinhard Meyer
This allows for arbitrarily long manufacturer ids following the JEDEC
standard of 0x7f continuation bytes. It also makes adding new entries
easier as it's just one element in an array. The downside is that it
increases code size a bit, but we're talking ~50 bytes.
Signed-off-by: Reinhard Meyer
Signed-off-by: Mike Frysinger
---
v2
- restore passing shifted idcode buffer to probe
- tweak defines further so gcc optimizes better
drivers/mtd/spi/spi_flash.c | 126 ---
1 files changed, 82 insertions(+), 44 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index ea875dc..b4ba1dd 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -2,6 +2,8 @@
* SPI flash interface
*
* Copyright (C) 2008 Atmel Corporation
+ * Copyright (C) 2010 Reinhard Meyer, EMK Elektronik
+ *
* Licensed under the GPL-2 or later.
*/
@@ -96,13 +98,68 @@ int spi_flash_read_common(struct spi_flash *flash, const u8
*cmd,
return ret;
}
+/*
+ * The following table holds all device probe functions
+ *
+ * shift: number of continuation bytes before the ID
+ * idcode: the expected IDCODE or 0xff for non JEDEC devices
+ * probe: the function to call
+ *
+ * Non JEDEC devices should be ordered in the table such that
+ * the probe functions with best detection algorithms come first.
+ *
+ * Several matching entries are permitted, they will be tried
+ * in sequence until a probe function returns non NULL.
+ *
+ * IDCODE_CONT_LEN may be redefined if a device needs to declare a
+ * larger "shift" value. IDCODE_PART_LEN generally shouldn't be
+ * changed. This is the max number of bytes probe functions may
+ * examine when looking up part-specific identification info.
+ *
+ * Probe functions will be given the idcode buffer starting at their
+ * manu id byte (the "idcode" in the table below). In other words,
+ * all of the continuation bytes will be skipped (the "shift" below).
+ */
+#define IDCODE_CONT_LEN 0
+#define IDCODE_PART_LEN 5
+static const struct {
+ const u8 shift;
+ const u8 idcode;
+ struct spi_flash *(*probe) (struct spi_slave *spi, u8 *idcode);
+} flashes[] = {
+ /* Keep it sorted by define name */
+#ifdef CONFIG_SPI_FLASH_ATMEL
+ { 0, 0x1f, spi_flash_probe_atmel, },
+#endif
+#ifdef CONFIG_SPI_FLASH_MACRONIX
+ { 0, 0xc2, spi_flash_probe_macronix, },
+#endif
+#ifdef CONFIG_SPI_FLASH_SPANSION
+ { 0, 0x01, spi_flash_probe_spansion, },
+#endif
+#ifdef CONFIG_SPI_FLASH_SST
+ { 0, 0xbf, spi_flash_probe_sst, },
+#endif
+#ifdef CONFIG_SPI_FLASH_STMICRO
+ { 0, 0x20, spi_flash_probe_stmicro, },
+#endif
+#ifdef CONFIG_SPI_FLASH_WINBOND
+ { 0, 0xef, spi_flash_probe_winbond, },
+#endif
+ /* Keep it sorted by best detection */
+#ifdef CONFIG_SPI_FLASH_STMICRO
+ { 0, 0xff, spi_flash_probe_stmicro, },
+#endif
+};
+#define IDCODE_LEN (IDCODE_CONT_LEN + IDCODE_PART_LEN)
+
struct spi_flash *spi_flash_probe(unsigned int bus, unsigned int cs,
unsigned int max_hz, unsigned int spi_mode)
{
struct spi_slave *spi;
- struct spi_flash *flash;
- int ret;
- u8 idcode[5];
+ struct spi_flash *flash = NULL;
+ int ret, i, shift;
+ u8 idcode[IDCODE_LEN], *idp;
spi = spi_setup_slave(bus, cs, max_hz, spi_mode);
if (!spi) {
@@ -117,53 +174,34 @@ struct spi_flash *spi_flash_probe(unsigned int bus,
unsigned int cs,
}
/* Read the ID codes */
- ret = spi_flash_cmd(spi, CMD_READ_ID, &idcode, sizeof(idcode));
+ ret = spi_flash_cmd(spi, CMD_READ_ID, idcode, sizeof(idcode));
if (ret)
goto err_read_id;
- debug("SF: Got idcode %02x %02x %02x %02x %02x\n", idcode[0],
- idcode[1], idcode[2], idcode[3], idcode[4]);
-
- switch (idcode[0]) {
-#ifdef CONFIG_SPI_FLASH_SPANSION
- case 0x01:
- flash = spi_flash_probe_spansion(spi, idcode);
- break;
+#ifdef DEBUG
+ printf("SF: Got idcodes\n");
+ print_buffer(0, idcode, 1, sizeof(idcode), 0);
#endif
-#ifdef CONFIG_SPI_FLASH_ATMEL
- case 0x1F:
- flash = spi_flash_probe_atmel(spi, idcode);
- break;
-#endif
-#ifdef CONFIG_SPI_FLASH_MACRONIX
- case 0xc2:
- flash = spi_flash_probe_macronix(spi, idcode);
- break;
-#endif
-#ifdef CONFIG_SPI_FLASH_WINBOND
- case 0xef:
- flash = spi_flash_probe_winbond(spi, idcode);
- break;
-#endif
-#ifdef CONFIG_SPI_FLASH_STMICRO
- case 0x20:
- case 0xff: /* Let the stmicro func handle non-JEDEC ids */
- flash = spi_flash_probe_stmicro(spi, idcode);
- break;
-#endif
-#ifdef CONFIG_SPI_FLASH_SST
- case 0xBF:
- flash = spi_flash_probe_sst(spi, idcode);
- break;
-#endif
- default:
-
Re: [U-Boot] [PATCH V2] arm: bugfix: replace ble with blo in start.S files
Dear Albert Aribaud,
In message <1286287599-5198-1-git-send-email-albert.arib...@free.fr> you wrote:
> Generalized misuse of ble within relocation and bss
> initialization loops caused one iteration too many.
> Instead of ble ('branch if lower or equal'), use
> blo ('branch if lower').
>
> While we're at it, fix all 'addreee' typos.
>
> Signed-off-by: Albert Aribaud
> ---
> V1Initial submission
> V2Fixed all remaining 'addreee' typos
>
> arch/arm/cpu/arm1136/start.S |8
> arch/arm/cpu/arm1176/start.S | 10 +-
> arch/arm/cpu/arm720t/start.S | 10 +-
> arch/arm/cpu/arm920t/start.S | 10 +-
> arch/arm/cpu/arm925t/start.S | 10 +-
> arch/arm/cpu/arm926ejs/start.S | 10 +-
> arch/arm/cpu/arm946es/start.S |8
> arch/arm/cpu/arm_intcm/start.S | 10 +-
> arch/arm/cpu/armv7/start.S |8
> arch/arm/cpu/ixp/start.S | 10 +-
> arch/arm/cpu/lh7a40x/start.S | 11 +--
> arch/arm/cpu/pxa/start.S |8
> arch/arm/cpu/s3c44b0/start.S | 12 ++--
> arch/arm/cpu/sa1100/start.S| 10 +-
> 14 files changed, 67 insertions(+), 68 deletions(-)
Applied to u-boot-arm, thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-atmel/at91
Dear Reinhard Meyer, In message <4cab35de.2010...@emk-elektronik.de> you wrote: > Dear Wolfgang, > > The following changes since commit d6288664743cdd4824cb877ca424619c827c1256: > Wolfgang Denk (1): > Merge branch 'master' of git://git.denx.de/u-boot-blackfin > > are available in the git repository at: > > git://git.denx.de/u-boot-atmel at91 > > Alexander Stein (1): > at91: Add arch_preboot_os which disables PIT in a faster way > > Andreas Biessmann (4): > at91_emac.c: fix 'Warning: eth device name has a space!' > at91_emac.c: poll for IDLE when writing PHY > at91_emac.h: fix typo in register definition > atmel_usart: change register access to C structure > > Reinhard Meyer (1): > AT91: convert cpu.c to struct SoC access > > arch/arm/cpu/arm926ejs/at91/cpu.c | 48 ++-- > arch/arm/include/asm/arch-at91/at91_emac.h |2 +- > drivers/net/at91_emac.c| 22 +++--- > drivers/serial/atmel_usart.c | 36 +++--- > drivers/serial/atmel_usart.h | 56 > > 5 files changed, 90 insertions(+), 74 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de panic: kernel trap (ignored) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Pull request: u-boot-imx
Dear Stefano Babic,
In message <4cad8492.3000...@denx.de> you wrote:
> Hi Wolfgang,
>
> please pull from u-boot-imx.
>
> The following changes since commit 2e6e1772c0e34871769be4aef79748fe3e47d953:
> Wolfgang Denk (1):
> Merge branch 'next' of /home/wd/git/u-boot/next
>
> are available in the git repository at:
>
> git://git.denx.de/u-boot-imx master
>
> Stefano Babic (10):
> Use common function to set GPIOs for MX3 and MX5
> ARM: Use syslib functions for all CORTEXA8
> MX51: Added pins definition to set up pads
> MX51: add structure to access System Reset Controller
> MXC: Add watchdog support to serial driver
> MX51: Drop unused header file for mx51evk
> MXC: Correct SPI_CPOL setting in SPI driver
> MXC: Fix byte-ordering in SPI driver for i.MX31/i.MX51
> MX51: Register definitions cannot be included in board config file
> MX51: Support for TTECH vision2 board
>
> MAINTAINERS|1 +
> arch/arm/cpu/armv7/Makefile|3 +-
> arch/arm/cpu/armv7/omap-common/Makefile|1 -
> arch/arm/cpu/armv7/{omap-common => }/syslib.c |0
> arch/arm/include/asm/arch-mx31/mx31-regs.h | 14 +-
> arch/arm/include/asm/arch-mx31/mx31.h | 25 -
> arch/arm/include/asm/arch-mx51/imx-regs.h | 26 +-
> arch/arm/include/asm/arch-mx51/mx51_pins.h | 44 ++
> arch/arm/include/asm/arch-mx51/sys_proto.h |1 +
> board/davedenx/qong/qong.c | 29 +-
> board/freescale/mx51evk/mx51evk.c |2 -
> board/ttcontrol/vision2/Makefile | 48 ++
> board/ttcontrol/vision2/config.mk | 25 +
> board/ttcontrol/vision2/imximage_hynix.cfg | 209 ++
> board/ttcontrol/vision2/vision2.c | 711
>
> boards.cfg |1 +
> drivers/gpio/Makefile |2 +-
> drivers/gpio/{mx31_gpio.c => mxc_gpio.c} | 47 +-
> drivers/misc/fsl_pmic.c| 10 +-
> drivers/serial/serial_mxc.c|7 +-
> drivers/spi/mxc_spi.c | 168 --
> include/configs/imx31_litekit.h|4 +-
> include/configs/imx31_phycore.h|2 +-
> include/configs/mx31ads.h |4 +-
> include/configs/mx31pdk.h |4 +-
> include/configs/mx51evk.h |2 +-
> include/configs/qong.h |6 +-
> include/configs/vision2.h | 214 ++
> include/mc13892.h |3 +
> .../mx51evk/mx51evk.h => include/mxc_gpio.h| 50 +-
> 30 files changed, 1510 insertions(+), 153 deletions(-)
> rename arch/arm/cpu/armv7/{omap-common => }/syslib.c (100%)
> create mode 100644 board/ttcontrol/vision2/Makefile
> create mode 100644 board/ttcontrol/vision2/config.mk
> create mode 100644 board/ttcontrol/vision2/imximage_hynix.cfg
> create mode 100644 board/ttcontrol/vision2/vision2.c
> rename drivers/gpio/{mx31_gpio.c => mxc_gpio.c} (63%)
> create mode 100644 include/configs/vision2.h
> rename board/freescale/mx51evk/mx51evk.h => include/mxc_gpio.h (54%)
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Though a program be but three lines long,
someday it will have to be maintained."
- The Tao of Programming
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 1/2] MTD/SPI: introduce table driven probing
On Monday, October 11, 2010 03:56:26 Reinhard Meyer wrote:
> Dear Mike Frysinger,
>
> > On Tuesday, October 05, 2010 10:56:39 Reinhard Meyer wrote:
> >> + /*
> >> + * count the number of continuation bytes, but
> >> + * leave at least 3 bytes to the end of the buffer untouched
> >> + */
> >> + for (shift = 0, idp = idbuf;
> >> + shift < (sizeof(idbuf) - 3) && *idp == 0x7f;
> >> + shift++, idp++)
> >> + ;
> >> +
> >> + /* search the table for matches in shift and id */
> >> + for (i = 0; i < ARRAY_SIZE(flashes); i++) {
> >> + if (flashes[i].shift == shift && flashes[i].idcode == *idp) {
> >> + /* we have a match, call probe */
> >> + flash = flashes[i].probe(spi, idp);
> >> + if (flash)
> >> + break;
> >> + }
> >>
> >>}
> >
> > thinking about this some more, i see two problems. (1) we've been
> > providing 4 bytes to probe funcs (like the spansion), so 3 is too small.
> > (2) all of the probe devices today expect to get the whole idcode
> > buffer. so if we're going to change this API, we need to fix all the
> > probe funcs too. but that is a lot of changes to roll into one commit,
> > so let's first focus on converting to a table without changing any probe
> > semantics.
>
> NONE of the existing functions work with expansion, so they all get the
> unshifted, full ID buffer.
err, right. was thinking it also shifted off the manu id byte and not just
the continuation bytes.
i'll tweak the patch i posted and pull in your ramtron patch.
> If you provide the unshifted buffer to the function, the function should
> get the shift amount as well. Otherwise the function will again have look
> how many 0x7e's to skip
not really. the probe funcs already know the layout of the idcode, so
starting at a constant offset of 3 is the same as starting at 1.
-mike
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 3/3] MX31: Add USB Host support to the QONG board
Dear Remy, In message <1286443640-29526-3-git-send-email-sba...@denx.de> you wrote: > Signed-off-by: Stefano Babic > --- > board/davedenx/qong/qong.c | 33 + > include/configs/qong.h | 18 +- > 2 files changed, 50 insertions(+), 1 deletions(-) even though USB related, this looks like a board specific patch to me. Is it OK with you that Stefano pulls this through the iMX repository? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A conservative is a man who believes that nothing should be done for the first time. - Alfred E. Wiggam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] FPGA: add support for downloading Lattice bitstream
Dear Stefano Babic, In message <1286441988-28998-2-git-send-email-sba...@denx.de> you wrote: > The patch adds support to load a Lattice's bitstream > image (called VME file) into a Lattice FPGA. The code > containing the state machine delivered as part of > Lattice's ispVMtools is integrated. > > The FPGA is programmed using the JTAG interface. The > board maintainer must provide accessors to drive the > JTAG signals TCK, TMS, TDI and to get the value of the > input signal TDO. ... > diff --git a/drivers/fpga/ivm_core.c b/drivers/fpga/ivm_core.c > new file mode 100755 > index 000..ae43ac7 > --- /dev/null > +++ b/drivers/fpga/ivm_core.c > @@ -0,0 +1,3166 @@ > +/* > + * (C) Copyright 2010 > + * Stefano Babic, DENX Software Engineering, sba...@denx.de. > + * > + * Porting to u-boot of Lattice ispVME Embedded to > + * load Lattice's FPGA: > + * > + * Copyright 2009 Lattice Semiconductor Corp. I read this such that Lattice Semiconductor did the porting to U-Boot, but is this correct? I though you did that? In that case you probably want to write something like: Porting to U-Boot: (C) Copyright 2010 Stefano Babic, DENX Software Engineering, sba...@denx.de. Lattice ispVME Embedded code to load Lattice's FPGA: Copyright 2009 Lattice Semiconductor Corp. or so? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Any time things appear to be going better, you have overlooked some- thing. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-x86
Dear Graeme Russ, In message <4cad929f.9040...@gmail.com> you wrote: > Hi Wolfgang, > > please pull from u-boot-x86. > > The following changes since commit d6288664743cdd4824cb877ca424619c827c1256: > > Merge branch 'master' of git://git.denx.de/u-boot-blackfin (2010-10-05 > 14:42:32 +0200) > > are available in the git repository at: > > git://git.denx.de/u-boot-x86 master > > Graeme Russ (20): > x86: Remove bi_env from do_bdinfo > x86: Make CONFIG_RELOC_FIXUP_WORKS generic for all x86 boards > x86: Use TEXT_BASE in linker scripts > x86: zboot update > x86: use gc sections to reduce image size > x86: Move loading of GTD to C code > x86: Coding Style Cleanup > x86: Change compiler options > x86: Fix %ss and %esp in register structure for interrupts > x86: Remove progress indication in low-level init > x86: Move ECC initialisation outside RAM initialisation > x86: Remove usage of %ebp as a return pointer > x86: Don't clobber %ebx > x86: Dont clobber %eax after getting memory size > x86: Place global data below stack before entering C > x86: Set cold/warm boot flag > x86: Rename linker script symbols > x86: Rearrange linker script > x86: Use loops instead of memcpy/memset in board_init_f > x86: Implement fully relocatable image > > arch/i386/config.mk | 11 + > arch/i386/cpu/cpu.c | 57 +++ > arch/i386/cpu/interrupts.c | 28 +- > arch/i386/cpu/sc520/sc520.c | 54 ++-- > arch/i386/cpu/sc520/sc520_asm.S | 668 > +-- > arch/i386/cpu/start.S | 225 +++- > arch/i386/cpu/start16.S | 18 +- > arch/i386/include/asm/config.h |2 + > arch/i386/include/asm/global_data.h | 27 ++- > arch/i386/include/asm/interrupt.h |4 +- > arch/i386/include/asm/ptrace.h | 24 ++ > arch/i386/lib/bios_setup.c | 14 +- > arch/i386/lib/board.c | 119 +++ > arch/i386/lib/realmode.c| 14 +- > arch/i386/lib/zimage.c | 18 +- > board/eNET/eNET_start.S | 14 +- > board/eNET/eNET_start16.S |3 +- > board/eNET/u-boot.lds | 67 ++-- > common/cmd_bdinfo.c |1 - > include/configs/eNET.h |2 - > 20 files changed, 668 insertions(+), 702 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de G's Third Law: In spite of all evidence to the contra- ry, the entire universe is composed of only two basic substances: magic and bullshit. H's Dictum:There is no magic ... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Observation: GCC-4.3.5 and U-Boot (arm, reloc) not working
Hello, I just have built gcc-4.3.5 for arm-eabi. When I compile u-boot with it, it stops after the DRAM: 64 MiB. I _assume_ that relocation does not work. I do not have time right now to further investigate this issue, but if someone else finds the same problem, this might be an issue worth investigating. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx.git
Dear Kumar Gala, In message you wrote: > The following changes since commit d6288664743cdd4824cb877ca424619c827c1256: > > Merge branch 'master' of git://git.denx.de/u-boot-blackfin (2010-10-05 > 14:42:32 +0200) > > are available in the git repository at: > > git://git.denx.de/u-boot-mpc85xx master > > Emil Medve (1): > powerpc/corenet_ds: Various updates to initial env cfg > > Haiying Wang (3): > mpc8569mds: fix CONFIG_ENV_SIZE > mpc8569mds: fix consuming long time while relocating code. > mpc8569mds: fix some ddr settings > > Kim Phillips (1): > powerpc/85xx: fix rev.2 job queue LIODN error storm > > Kumar Gala (2): > powerpc/85xx: Add support for 4th PCI controller on corenet_ds > powerpc/p4080: Add new CPC register - HDBCR0 > > Timur Tabi (3): > p1022ds: add audclk hwconfig setting to enable codec reference clock > fsl: verify writes to the MAC address EEPROM > fsl: add support for NXID v1 EEPROM format > > arch/powerpc/cpu/mpc85xx/p4080_ids.c| 14 +-- > arch/powerpc/include/asm/immap_85xx.h |5 ++- > board/freescale/common/sys_eeprom.c | 44 - > board/freescale/corenet_ds/pci.c| 28 - > board/freescale/mpc8569mds/ddr.c| 16 ++- > board/freescale/mpc8569mds/mpc8569mds.c | 26 > board/freescale/mpc8569mds/tlb.c| 15 +-- > board/freescale/p1022ds/p1022ds.c | 67 ++ > doc/README.fsl-hwconfig | 21 ++ > include/configs/MPC8569MDS.h|7 ++- > include/configs/P1022DS.h |1 + > include/configs/corenet_ds.h| 23 --- > 12 files changed, 225 insertions(+), 42 deletions(-) > create mode 100644 doc/README.fsl-hwconfig Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
