Re: [U-Boot] [PATCH] Marvell GuruPlug Board Support
On Mon, 2010-03-15 at 09:08 -0700, Wolfgang Denk wrote: > ... > > --- /dev/null > > +++ b/board/Marvell/guruplug/guruplug.h > > @@ -0,0 +1,39 @@ > > > +#define GURUPLUG_OE_LOW (~(0)) > > +#define GURUPLUG_OE_HIGH (~(0)) > > Is this correct? Both LOW and HIGH use the same value?? > Sorry. forget to respond to this one. Yes this is correct. LOW and HIGH does not represent logic levels here. The registers which control GPIO pins 0 though 31 are suffixed LOW and those which control the rest are suffixed HIGH. -siddarth ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Marvell GuruPlug Board Support
GuruPlug Standard: 1 Gb Ethernet, 2 USB 2.0 GuruPlug Plus: 2 Gb Ethernet, 2 USB 2.0, 1 eSATA, 1 uSD slot References: http://www.globalscaletechnologies.com/t-guruplugdetails.aspx http://plugcomputer.org This patch is for GuruPlug Plus, but it supports Standard version as well. Signed-off-by: Siddarth Gore --- Changes compared to the previous version (messaage-id: 1268660568-23022-1-git-send-email-go...@marvell.com) - maintainers entry sorted according to last name - removed trailing comment from board/Marvell/guruplug/config.mk - removed CONFIG_CMD_AUTOSCRIPT from include/configs/guruplug.h - removed word 'minimal' from comment in include/configs/guruplug.h MAINTAINERS |4 + MAKEALL |1 + Makefile|3 + board/Marvell/guruplug/Makefile | 51 + board/Marvell/guruplug/config.mk| 27 + board/Marvell/guruplug/guruplug.c | 167 + board/Marvell/guruplug/guruplug.h | 39 +++ board/Marvell/guruplug/kwbimage.cfg | 162 include/configs/guruplug.h | 198 +++ 9 files changed, 652 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/guruplug/Makefile create mode 100644 board/Marvell/guruplug/config.mk create mode 100644 board/Marvell/guruplug/guruplug.c create mode 100644 board/Marvell/guruplug/guruplug.h create mode 100644 board/Marvell/guruplug/kwbimage.cfg create mode 100644 include/configs/guruplug.h diff --git a/MAINTAINERS b/MAINTAINERS index 80057ce..ed0731d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -195,6 +195,10 @@ Niklaus Giger MCU25 PPC405GPr HCU5PPC440EPx +Siddarth Gore + + guruplugARM926EJS (Kirkwood SoC) + Frank Gottschling MHPCMPC8xx diff --git a/MAKEALL b/MAKEALL index beacb5f..b15c2d1 100755 --- a/MAKEALL +++ b/MAKEALL @@ -562,6 +562,7 @@ LIST_ARM9=" \ edb9312 \ edb9315 \ edb9315a\ + guruplug\ imx27lite \ lpd7a400\ mv88f6281gtw_ge \ diff --git a/Makefile b/Makefile index d801e25..30d5968 100644 --- a/Makefile +++ b/Makefile @@ -2952,6 +2952,9 @@ davinci_dm365evm_config : unconfig davinci_dm6467evm_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs dm6467evm davinci davinci +guruplug_config: unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs $(@:_config=) Marvell kirkwood + imx27lite_config: unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs imx27lite logicpd mx27 diff --git a/board/Marvell/guruplug/Makefile b/board/Marvell/guruplug/Makefile new file mode 100644 index 000..99748a7 --- /dev/null +++ b/board/Marvell/guruplug/Makefile @@ -0,0 +1,51 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor +# Written-by: Siddarth Gore +# +# 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., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := guruplug.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 .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/Marvell/guruplug/config.mk b/board/Marvell/guruplug/config.mk new file mode 100644 index 000..caa26b6 --- /dev/null +++ b/board/Marvell/guruplug/config.mk @@ -0,0 +1,27 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor +# Written-by: Siddarth Gore +# +# 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 Sof
Re: [U-Boot] Hi guys, maybe this is not the best list but I ask about my problem
Dear Fabio Giovagnini, you are indeed completely off topic here on the U-Boot list. In message <201003180657.27345.fabio.giovagn...@aurion-tech.com> you wrote: > > Im able to mount the nfsroot filesystem but I get this message: ... > Warning: unable to open an initial console. ^ > In rootpath I should read someting? You should read the error messages and contemplate their meaning. > Could the problem be my PC is little endian and I' exporting to a big endian > CPU? No. "unable to open an initial console" usually means that there is no "/dev/console" entry in your root file system, so check your root file system if it is complete. [If you were using the ELDK, my bet was that you have forgotten to run the ELDK_MAKEDEV (plus eventually the ELDK_FIXOWNER) script(s), but you don't include such vital information as where this root file system is coming from and why you think it should be a working one.] 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 Quantum particles: The dreams that stuff is made of. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATH] at91: add hwecc method for nand
Hi, all. This is a patch to use the hardware ECC controller of the AT91SAM9260 for the AT91 nand. Taken from the kernel 2.6.33. To use this it is necessary to add two definitions in config: CONFIG_ATMEL_NAND_HWECC CONFIG_SYS_NAND_ECC_BASE (AT91_ECC for the AT91SAM9260 and AT91_ECC0 for the AT91SAM9263 boards) It has been tested only on AT91SAM9260-EK. u-boot version : 2009.11 kernel version : 2.6.27(32) Results of read bandwidth: u-boot with SWECC: 1MB/s u-boot with HWECC: 3MB/s linux with HWECC: 6MB/s Signed-off-by: Nikolay Petukhov diff -uprN u-boot-2009.11/drivers/mtd/nand/atmel_nand.c u-boot-2009.11-at91-nand-hwecc/drivers/mtd/nand/atmel_nand.c --- u-boot-2009.11/drivers/mtd/nand/atmel_nand.c2009-12-16 03:20:54.0 +0500 +++ u-boot-2009.11-at91-nand-hwecc/drivers/mtd/nand/atmel_nand.c 2010-03-18 11:15:01.0 +0500 @@ -31,6 +31,210 @@ #include +#ifdef CONFIG_ATMEL_NAND_HWECC + +/* Register access macros */ +#define ecc_readl(add, reg)\ + readl(AT91_BASE_SYS + add + ATMEL_ECC_##reg) +#define ecc_writel(add, reg, value)\ + writel((value), AT91_BASE_SYS + add + ATMEL_ECC_##reg) + +#include "atmel_nand_ecc.h"/* Hardware ECC registers */ + +/* oob layout for large page size + * bad block info is on bytes 0 and 1 + * the bytes have to be consecutives to avoid + * several NAND_CMD_RNDOUT during read + */ +static struct nand_ecclayout atmel_oobinfo_large = { + .eccbytes = 4, + .eccpos = {60, 61, 62, 63}, + .oobfree = { + {2, 58} + }, +}; + +/* oob layout for small page size + * bad block info is on bytes 4 and 5 + * the bytes have to be consecutives to avoid + * several NAND_CMD_RNDOUT during read + */ +static struct nand_ecclayout atmel_oobinfo_small = { + .eccbytes = 4, + .eccpos = {0, 1, 2, 3}, + .oobfree = { + {6, 10} + }, +}; + +/* + * Calculate HW ECC + * + * function called after a write + * + * mtd:MTD block structure + * dat:raw data (unused) + * ecc_code: buffer for ECC + */ +static int atmel_nand_calculate(struct mtd_info *mtd, + const u_char *dat, unsigned char *ecc_code) +{ + struct nand_chip *nand_chip = mtd->priv; + unsigned int ecc_value; + + /* get the first 2 ECC bytes */ + ecc_value = ecc_readl(CONFIG_SYS_NAND_ECC_BASE, PR); + + ecc_code[0] = ecc_value & 0xFF; + ecc_code[1] = (ecc_value >> 8) & 0xFF; + + /* get the last 2 ECC bytes */ + ecc_value = ecc_readl(CONFIG_SYS_NAND_ECC_BASE, NPR) & ATMEL_ECC_NPARITY; + + ecc_code[2] = ecc_value & 0xFF; + ecc_code[3] = (ecc_value >> 8) & 0xFF; + + return 0; +} + +/* + * HW ECC read page function + * + * mtd:mtd info structure + * chip: nand chip info structure + * buf:buffer to store read data + */ +static int atmel_nand_read_page(struct mtd_info *mtd, + struct nand_chip *chip, uint8_t *buf, int page) +{ + int eccsize = chip->ecc.size; + int eccbytes = chip->ecc.bytes; + uint32_t *eccpos = chip->ecc.layout->eccpos; + uint8_t *p = buf; + uint8_t *oob = chip->oob_poi; + uint8_t *ecc_pos; + int stat; + + /* read the page */ + chip->read_buf(mtd, p, eccsize); + + /* move to ECC position if needed */ + if (eccpos[0] != 0) { + /* This only works on large pages +* because the ECC controller waits for +* NAND_CMD_RNDOUTSTART after the +* NAND_CMD_RNDOUT. +* anyway, for small pages, the eccpos[0] == 0 +*/ + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, + mtd->writesize + eccpos[0], -1); + } + + /* the ECC controller needs to read the ECC just after the data */ + ecc_pos = oob + eccpos[0]; + chip->read_buf(mtd, ecc_pos, eccbytes); + + /* check if there's an error */ + stat = chip->ecc.correct(mtd, p, oob, NULL); + + if (stat < 0) + mtd->ecc_stats.failed++; + else + mtd->ecc_stats.corrected += stat; + + /* get back to oob start (end of page) */ + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1); + + /* read the oob */ + chip->read_buf(mtd, oob, mtd->oobsize); + + return 0; +} + +/* + * HW ECC Correction + * + * function called after a read + * + * mtd:MTD block structure + * dat:raw data read from the chip + * read_ecc: ECC from the chip (unused) + * isnull: unused + * + * Detect and correct a 1 bit error for a page + */ +static int atmel_nand_correct(struct mtd_info *mtd, u_char *dat, + u_char *read_ecc, u_char *isnull) +{ + struct nand_chip *nand_chip = mtd->priv; + //struct atmel_nand_host *host = nand_chip->priv; + unsigned int ecc_status, ecc_parity, ecc_mode; + unsigned int ecc_word, ecc_
Re: [U-Boot] [PATCH] Marvell GuruPlug Board Support
> -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Siddarth Gore > Sent: Thursday, March 18, 2010 10:59 AM > To: Wolfgang Denk > Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik > Subject: Re: [U-Boot] [PATCH] Marvell GuruPlug Board Support ...snip... > > > > We have pretty much identical code already in mv_phy_88e1116_init() > > [in "board/Marvell/rd6281a/rd6281a.c"], in reset_phy() [in > > "board/Marvell/openrd_base/openrd_base.c"], in reset_phy(0 [in > > "board/Marvell/sheevaplug/sheevaplug.c"] and I don't know > where else. > > > > I object against adding more and more copies of the same > code. Please > > factor out the common part into a single implementation, > and call this > > everwhere where such code is used. Thanks. > > > i can create a new file ethphy.c in board/Marvell/common and put this > code there. but if we are going to move to a phy driver (as Prafulla > suggested) then that wont be necessary. Please advise. > > Also i think we should maintain different init functions for 1116 and > 1121 as they represent different phy families, even though the code is > pretty much the same right now. Hi Siddarth I think you keep this part as it is as of now, Once Ben suggest something, I will post the cleanup patch Regards.. Prafulla .. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Marvell GuruPlug Board Support
> -Original Message- > From: Siddarth Gore [mailto:go...@marvell.com] > Sent: Thursday, March 18, 2010 1:12 PM > To: u-boot@lists.denx.de > Cc: Prafulla Wadaskar; Prabhanjan Sarnaik; Ashish Karkare; > Siddarth Gore > Subject: [PATCH v2] Marvell GuruPlug Board Support > > GuruPlug Standard: 1 Gb Ethernet, 2 USB 2.0 > GuruPlug Plus: 2 Gb Ethernet, 2 USB 2.0, 1 eSATA, 1 uSD slot > > References: > http://www.globalscaletechnologies.com/t-guruplugdetails.aspx > http://plugcomputer.org > > This patch is for GuruPlug Plus, but it supports Standard version > as well. > > Signed-off-by: Siddarth Gore > --- > Changes compared to the previous version (messaage-id: > 1268660568-23022-1-git-send-email-go...@marvell.com) > - maintainers entry sorted according to last name > - removed trailing comment from board/Marvell/guruplug/config.mk > - removed CONFIG_CMD_AUTOSCRIPT from include/configs/guruplug.h > - removed word 'minimal' from comment in include/configs/guruplug.h > > MAINTAINERS |4 + > MAKEALL |1 + > Makefile|3 + > board/Marvell/guruplug/Makefile | 51 + > board/Marvell/guruplug/config.mk| 27 + > board/Marvell/guruplug/guruplug.c | 167 > + > board/Marvell/guruplug/guruplug.h | 39 +++ > board/Marvell/guruplug/kwbimage.cfg | 162 > > include/configs/guruplug.h | 198 > +++ > 9 files changed, 652 insertions(+), 0 deletions(-) > create mode 100644 board/Marvell/guruplug/Makefile > create mode 100644 board/Marvell/guruplug/config.mk > create mode 100644 board/Marvell/guruplug/guruplug.c > create mode 100644 board/Marvell/guruplug/guruplug.h > create mode 100644 board/Marvell/guruplug/kwbimage.cfg > create mode 100644 include/configs/guruplug.h > Looks okay to me Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Marvell GuruPlug Board Support
Dear Siddarth Gore, In message <1268890125.23313.27.ca...@pe-dt434> you wrote: > ... > > We have pretty much identical code already in mv_phy_88e1116_init() > > [in "board/Marvell/rd6281a/rd6281a.c"], in reset_phy() [in > > "board/Marvell/openrd_base/openrd_base.c"], in reset_phy(0 [in > > "board/Marvell/sheevaplug/sheevaplug.c"] and I don't know where else. > > > > I object against adding more and more copies of the same code. Please > > factor out the common part into a single implementation, and call this > > everwhere where such code is used. Thanks. > > > i can create a new file ethphy.c in board/Marvell/common and put this > code there. but if we are going to move to a phy driver (as Prafulla > suggested) then that wont be necessary. Please advise. Is there any actual development for a generic PHY support layer going on anywhere? I must have missed this, then. If there is such a thing, it should be used, obviously. > Also i think we should maintain different init functions for 1116 and > 1121 as they represent different phy families, even though the code is > pretty much the same right now. If the code is the same, then duplication makes no sense to me. 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 Space is big. You just won't believe how vastly, hugely, mind- bogglingly big it is. I mean, you may think it's a long way down the road to the drug store, but that's just peanuts to space. -- The Hitchhiker's Guide to the Galaxy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot stack overwrites end ramdisk
I was not totally correct. gunzip/inflate has nothing to do with this problem. the problem is this: - do_bootm->bootm_start->arch_lmb_reserve reserves "unused" memory as in cur_sp-1k upto end-of-mem in my case this is 0x0fb0cb28 - 0x1000 - do_bootm->do_bootm_linux->boot_body_linux->boot_ramdisk_high places ramdisk as close to (and below) the "unused" memory reservation (0x1000 aligned) in my case ramdisk is copied to 0x0f8c - 0x0fb0ca24 - the end of the ramdisk is overwritten while printing "Loading Device Tree to 00ffa000, end 00fff593 ... OK" this happens from: do_bootm->do_bootm_linux->boot_relocate_fdt->printf->vsprintf->number bootm_start and arch_lmb_reserve together use 40 + 32 = 72 bytes stack. The assumption that u-boots' stack usage will not exceed arch_lmb_reserve stack pointer - 1k is simply incorrect. The "do_bootm_linux->boot_relocate_fdt->printf->vsprintf->number" call chain (called from that same do_bootm) uses 56 + 40 + 1112 + 56 + 104 = 1368 bytes This problem will only occur with CONFIG_OF_LIBFDT #defined and it depends on how the 0x1000 alignment of the ramdisk image turns out. Btw. It looks like latest u-boot also has this problem. I'll send a patch later making it 4k. I do wonder why it was set so tight in the first place. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] soft_spi.c crash while saveenv
Hello Horst, > I used the soft_spi - driver for saving the u-boot-environment. > > When I started "saveenv" u-boot hang - no output. > I located the problem in soft_spi.c in function "spi_xfer()". > This function writes every byte received from the spi-device to the > pointer "dout". > In case of writing to the spi-device the returned bytes are also > written to the dout-pointer. > > The function "spi_flash_cmd()" in "drivers/mtd/spi/spi_flash.c" calls > now this function with > a NULL-pointer. Ok, I see that the mtd does a call with NULL pointers, so your fix actually works for your combination. On the other hand, this check of parameters is not consistent in the other drivers. drivers/spi/mpc8xxx_spi.c does no checks, while drivers/spi/bfin_spi.c does - I did not bother to check others. As I'm a friend of passive programming, I would go down your route but eventually fix all other drivers too. So can you please cook up a proper patch with a signed-off-by line as stated in the docs[1]? Thanks Detlev [1] http://www.denx.de/wiki/U-Boot/Patches -- Die eine Haelfte der Welt lacht ueber die andere, und Narren sind alle. --- Baltasar Gracian -- 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] uboot on microblaze, compilation error
Mike Frysinger wrote: > On Wednesday 17 March 2010 14:36:38 Horst Gall wrote: >> Hi, >> >> I try to compile an actual version of u-boot for xilinx microblaze. >> The linker ends with the error-message: >> >> ... mb-ld.real:u-boot.lds:1: parse error >> >> In u-boot main-directory I found the file 'u-boot.lds': >> >> OUTPUT_ARCH(1) >> ENTRY(_start) >> ... >> cpu/1/start.o (.text) >> ... >> >> When I change the "1" to "microblaze" it works: >> >> OUTPUT_ARCH(microblaze) >> ENTRY(_start) >> ... >> cpu/microblaze/start.o (.text) >> ... >> >> >> After "make ...config" my modification is overwritten. >> How can I fix this problem? > > add "#undef microblaze" to the top of board/xilinx/microblaze-generic/u- > boot.lds Mike is right. I expect you are using toolchain from EDK where the problem is. Linux toolchain are ok. Michal > -mike > > > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot -- 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] Environmentvar. "ipaddr" - microblaze
Hi Horst, > in "lib_microblaze/board.c board_init()" the function "env_relocate()" > should be called before "getenv_IPaddr()" > otherwise there is no chance to save an ip-address in the environment (like > in lib_ppc/board.c). You should check this issues with the microblaze custodian listed on the web page[1]. Actually I put Michal on CC on this mail already. Thanks Detlev [1] http://www.denx.de/wiki/U-Boot/Custodians -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. -- 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
[U-Boot] serial init
Hi! I have some problems with understanding the serial initialization. Maybe someone can help me out here... In my case I want to use a second serial console on a DM365 davinci dvevm which is provided on an external chip through EMIF. The use case would be then to switch from the internal SoC serial (ns16550) to the second external console and back during runtime. So here is my question: While board initialization, serial_init() gets called, which calls the driver specific (hardware, etc...) init stuff. The default is that the default serial (in my case the SoC ns16550 ) will be initialized. So my extra serial port stays uninitialized because it's not default. When i switch stdout/stdin/stderr to the second serial port during runtime, serial_assign() gets called, but without calling serial_init () of the second serial port first. This confuses me, or am I misunderstanding the architecture / how serial interfaces work in uboot? Thanks for your help, Valentin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] [ARM] at91: Add support for taskit AT91SAM9G20 boards
This adds support for the AT91SAM9G20 boards by taskit GmbH. Both boards, Stamp9G20 and PortuxG20, are integrated in one file. PortuxG20 is basically a SBC built around Stamp9G20. Signed-off-by: Achim Ehrlich --- MAINTAINERS|5 + MAKEALL|1 + Makefile |4 + board/taskit/stamp9G20/Makefile| 50 + board/taskit/stamp9G20/config.mk |1 + board/taskit/stamp9G20/stamp9G20.c | 203 include/configs/stamp9G20.h| 180 7 files changed, 444 insertions(+), 0 deletions(-) create mode 100644 board/taskit/stamp9G20/Makefile create mode 100644 board/taskit/stamp9G20/config.mk create mode 100644 board/taskit/stamp9G20/stamp9G20.c create mode 100644 include/configs/stamp9G20.h diff --git a/MAINTAINERS b/MAINTAINERS index 7f40ebd..c4259a0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -138,6 +138,11 @@ Jon Diekema sbc8260 MPC8260 +Achim Ehrlich + + Stamp9G20 AT91SAM9G20 + PortuxG20 AT91SAM9G20 + Dirk Eibach devconcenterPPC460EX diff --git a/MAKEALL b/MAKEALL index 1949985..516 100755 --- a/MAKEALL +++ b/MAKEALL @@ -675,6 +675,7 @@ LIST_at91=" \ pm9261 \ pm9263 \ SBC35_A9G20 \ + stamp9G20 \ TNY_A9260 \ TNY_A9G20 \ " diff --git a/Makefile b/Makefile index ce77e10..ed9ae00 100644 --- a/Makefile +++ b/Makefile @@ -2903,6 +2903,10 @@ TNY_A9260_config : unconfig @echo "#define CONFIG_$(@:_config=) 1" >$(obj)include/config.h @$(MKCONFIG) -a tny_a9260 arm arm926ejs tny_a9260 calao at91 +portuxG20_config \ +stamp9G20_config : unconfig + @$(MKCONFIG) -t $(@:_config=) stamp9G20 arm arm926ejs stamp9G20 taskit at91 + ## ARM Integrator boards - see doc/README-integrator for more info. integratorap_config\ diff --git a/board/taskit/stamp9G20/Makefile b/board/taskit/stamp9G20/Makefile new file mode 100644 index 000..191fb8e --- /dev/null +++ b/board/taskit/stamp9G20/Makefile @@ -0,0 +1,50 @@ +# +# (C) Copyright 2010 +# Achim Ehrlich, taskit GmbH, aehrl...@taskit.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-y+= stamp9G20.o + +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) +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/taskit/stamp9G20/config.mk b/board/taskit/stamp9G20/config.mk new file mode 100644 index 000..ff2cfd1 --- /dev/null +++ b/board/taskit/stamp9G20/config.mk @@ -0,0 +1 @@ +TEXT_BASE = 0x23f0 diff --git a/board/taskit/stamp9G20/stamp9G20.c b/board/taskit/stamp9G20/stamp9G20.c new file mode 100644 index 000..b543b0a --- /dev/null +++ b/board/taskit/stamp9G20/stamp9G20.c @@ -0,0 +1,203 @@ +/* + * (C) Copyright 2007-2008 + * Stelian Pop + * Lead Tech Design + * + * (C) Copyright 2010 + * Achim Ehrlich + * taskit GmbH + * + * 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 Licens
Re: [U-Boot] serial init
On Thu, Mar 18, 2010 at 12:33 PM, Valentin Ecker wrote: ... > While board initialization, serial_init() gets called, which calls the > driver specific (hardware, etc...) init stuff. The default is that the > default serial (in my case the SoC ns16550 ) will be initialized. So > my extra serial port stays uninitialized because it's not default. Did you add the CONFIG_SYS_NS16550_COM2 in your board configuration file? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] correct a syntax typo in at91_matrix.h
Signed-off-by: Asen Dimov --- include/asm-arm/arch-at91/at91_matrix.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/asm-arm/arch-at91/at91_matrix.h b/include/asm-arm/arch-at91/at91_matrix.h index 9b3c110..981ec20 100644 --- a/include/asm-arm/arch-at91/at91_matrix.h +++ b/include/asm-arm/arch-at91/at91_matrix.h @@ -80,7 +80,7 @@ typedef struct at91_matrix { u32 mrcr; /* 0x100 Master Remap Control */ u32 reserve4[3]; #ifdefined(CONFIG_AT91SAM9G45) - u32 ccr[52] /* 0x110 - 0x1E0 Chip Configuration */ + u32 ccr[52];/* 0x110 - 0x1E0 Chip Configuration */ u32 womr; /* 0x1E4 Write Protect Mode */ u32 wpsr; /* 0x1E8 Write Protect Status */ u32 resg45_1[10]; -- 1.5.5.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] using AT91_PMC_MCKR_MDIV_ instead of LEGACY one in at91/clock.c
Signed-off-by: Asen Dimov --- cpu/arm926ejs/at91/clock.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/cpu/arm926ejs/at91/clock.c b/cpu/arm926ejs/at91/clock.c index b06d760..ecf91f5 100644 --- a/cpu/arm926ejs/at91/clock.c +++ b/cpu/arm926ejs/at91/clock.c @@ -203,7 +203,8 @@ int at91_clock_init(unsigned long main_clock) if (mckr & AT91_PMC_MCKR_MDIV_MASK) freq /= 2; /* processor clock division */ #elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) - mck_rate_hz = (mckr & AT91_PMC_MCKR_MDIV_MASK) == AT91SAM9_PMC_MDIV_3 + mck_rate_hz = (mckr & AT91_PMC_MCKR_MDIV_MASK) == + (AT91_PMC_MCKR_MDIV_2 | AT91_PMC_MCKR_MDIV_4) ? freq / 3 : freq / (1 << ((mckr & AT91_PMC_MCKR_MDIV_MASK) >> 8)); #else -- 1.5.5.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] serial init
well, i don't want to use the second com port of the ns16550. Im using an external serial chip over EMIF. so -> no, i don't, wouldn't make any sense to me... thx for the help On 18.03.2010, at 12:31, Michael Zaidman wrote: > On Thu, Mar 18, 2010 at 12:33 PM, Valentin Ecker > wrote: > ... >> While board initialization, serial_init() gets called, which calls >> the >> driver specific (hardware, etc...) init stuff. The default is that >> the >> default serial (in my case the SoC ns16550 ) will be initialized. So >> my extra serial port stays uninitialized because it's not default. > Did you add the CONFIG_SYS_NS16550_COM2 in your board > configuration file? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] serial init
On Thu, Mar 18, 2010 at 2:21 PM, Valentin Ecker wrote: > well, i don't want to use the second com port of the ns16550. Im using an > external serial chip over EMIF. I am not familiar with Davinci architecture and probably my case is completely different from yours but on our board we have dual uart on mpc8349 chip + external quad uart ns16554 chip connected via local bus. The current u-boot code supports up to 4 ns16550 devices, i.e. from COM1 to COM4. So I extended the serial_ports array to 6 entries and in this way got ability to communicate via COM5 and COM6. Michael. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot Env Vars in Flash and EEPROM at the same time (hybrid env)?
(puts on flame retardant underwear) Can environment variables be pulled from Flash and EEPROM? Why would I want to do this? I need to provide fail safe upgrade path and need to do something similar to the bootcount feature in PPC (I'm using ARM though). I have a internal SRAM that I can use for the bootcount feature (no registers survive reset so SRAM is next best option) but I want to be able to select Kernel B or Kernel A. Let me explain more. Right now the bootcount feature boots a primary kernel and if it fails it tries a secondary kernel. So in my case the bootcount feature would translate to Kernel A always tried first, then B and we want to be able to say boot B first, then A on failure (make the choice configurable based on upgrades etc). The goal is to not brick a device during a upgrade. Whatever bank you are running out of, you upgrade by flashing the bank not being used. Once a bank has been upgraded, if I want to select that bank to boot ... I would need to modify a environment variable but if it is stored in flash then while that sector (a 256k sector in my case) is being updated ... if power is lost I just hosed myself. If the environment variable I update was stored in EEPROM, then it would be closer to an atomic action that couldn't be interrupted with say a power failure. So what I'm asking about is a Hybrid environment were some variables are in flash and some are in EEPROM. The env is read from both locations and saveenv writes some vars in flash and some in EEPROM. With the current u-boot code I have (1.1.6) the environment choices are mutually exclusive (flash, eeprom, nvram etc.) Is this a sane approach or am I heading for heart ache? This has to be something that others have dealt with but I didn't see any similar discussions in the archives. Regards, Brian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Env Vars in Flash and EEPROM at the same time (hybrid env)?
... oops, one glaring thing I didn't think about in the approach I presented was the I2C transaction. If power is lost during that transaction I have a similar problem to a loss of power during a saveenv and the flash sector being erased and re written. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hi guys, maybe this is not the best list but I ask about my problem
Thanks alot. The very first problem was a permission problem, as you suggestied to ckech. But now I think a Have a problem of irq losing form eth. Thanks again In data giovedì 18 marzo 2010 09:04:22, Wolfgang Denk ha scritto: : > Dear Fabio Giovagnini, > > you are indeed completely off topic here on the U-Boot list. > > In message <201003180657.27345.fabio.giovagn...@aurion-tech.com> you wrote: > > Im able to mount the nfsroot filesystem but I get this message: > > ... > > > Warning: unable to open an initial console. > > ^ > > > In rootpath I should read someting? > > You should read the error messages and contemplate their meaning. > > > Could the problem be my PC is little endian and I' exporting to a big > > endian CPU? > > No. > > "unable to open an initial console" usually means that there is no > "/dev/console" entry in your root file system, so check your root file > system if it is complete. > > [If you were using the ELDK, my bet was that you have forgotten to run > the ELDK_MAKEDEV (plus eventually the ELDK_FIXOWNER) script(s), but > you don't include such vital information as where this root file > system is coming from and why you think it should be a working one.] > > Best regards, > > Wolfgang Denk > -- Fabio Giovagnini Aurion s.r.l. P.I e C.F. 00885711200 Tel. +39.051.594.78.24 Cell. +39.335.83.50.919 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] serial init
I see...I think we have a very similar setup, and I see how you init your ports. Although I'm not sure if this is suitable for me, since editing the ns16550-files to support/init an external COM-chip is not a really clean/nice implementation. I'm not sure if there is any way to implement this in a nice way. But I will let you know if we find something ;) thx for your help! Valentin On 18.03.2010, at 15:37, Michael Zaidman wrote: > On Thu, Mar 18, 2010 at 2:21 PM, Valentin Ecker > wrote: >> well, i don't want to use the second com port of the ns16550. Im >> using an >> external serial chip over EMIF. > > I am not familiar with Davinci architecture and probably my case is > completely different from yours but on our board we have dual uart on > mpc8349 chip + external quad uart ns16554 chip connected via local > bus. The current u-boot code supports up to 4 ns16550 devices, i.e. > from COM1 to COM4. So I extended the serial_ports array to 6 entries > and in this way got ability to communicate via COM5 and COM6. > > Michael. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] serial init
On Thu, Mar 18, 2010 at 4:58 PM, Valentin Ecker wrote: > I see...I think we have a very similar setup, and I see how you init your > ports. Although I'm not sure if this is suitable for me, since editing the > ns16550-files to support/init an external COM-chip is not a really > clean/nice implementation. > > I'm not sure if there is any way to implement this in a nice way. But I will > let you know if we find something ;) > I implemented it first in board specific code. It added small code overhead due to necessity to duplicate the serial_ports array and add uart_init for ports higher then 4. Afterwards, I implemented the same in common code. Extending the original serial_ports array makes the code more generic. I also added serial loopback tests availible via CLI and POST. I am going to post this patch on u-boot-list promptly. Michael. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Nios] Pull Request
Wolfgang, The following changes since commit f1fdc42e5efb9e3b6d0dd3b605d0848d3ca8a039: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-video are available in the git repository at: git://git.denx.de/u-boot-nios.git master Renato Andreola (1): nios2: Added support to YANU UART Thomas Chou (1): nios2: use generic unaligned.h cpu/nios2/serial.c| 168 - include/asm-nios2/unaligned.h |6 ++ include/nios2-yanu.h | 115 3 files changed, 288 insertions(+), 1 deletions(-) create mode 100644 include/asm-nios2/unaligned.h create mode 100644 include/nios2-yanu.h Regards, --Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Env Vars in Flash and EEPROM at the same time (hybrid env)?
Dear Brian Hutchinson, In message <3d1967ab1003180758p2006f562pc56cee3438eb2...@mail.gmail.com> you wrote: > (puts on flame retardant underwear) Can environment variables be > pulled from Flash and EEPROM? Not directly. > Why would I want to do this? I need to provide fail safe upgrade path > and need to do something similar to the bootcount feature in PPC (I'm > using ARM though). Hm... And redundant environment is not safe enough for you? > The goal is to not brick a device during a upgrade. Whatever bank you > are running out of, you upgrade by flashing the bank not being used. > Once a bank has been upgraded, if I want to select that bank to boot > ... I would need to modify a environment variable but if it is stored > in flash then while that sector (a 256k sector in my case) is being > updated ... if power is lost I just hosed myself. If the environment > variable I update was stored in EEPROM, then it would be closer to an > atomic action that couldn't be interrupted with say a power failure. EEPROM is not a bit more reliable than NOR, on contrary (read for example doc/I2C_Edge_Conditions - unless you write-protect your EEPROm in hardware it is actually way less reliable). And redundant environment should cover your use case just fine. > So what I'm asking about is a Hybrid environment were some variables > are in flash and some are in EEPROM. The env is read from both > locations and saveenv writes some vars in flash and some in EEPROM. > With the current u-boot code I have (1.1.6) the environment choices > are mutually exclusive (flash, eeprom, nvram etc.) This makes little sense to me. If you really fell like it, you can of course store some script image in EEPROM which you can then read and run (using "eeprom read" plus "source" commands). > Is this a sane approach or am I heading for heart ache? This has to > be something that others have dealt with but I didn't see any similar > discussions in the archives. Maybe because redundant environment is good enough for all practical purposes? 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 Objects in mirror are closer than they appear. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] add new board pm9g45
Add the new board PM9G45 from Ronetix GmbH. * AT91SAM9G45 MCU at 400Mhz. * 128MB DDR2 SDRAM * 256MB NAND * 4MB DataFlash (optional) * 10/100 MBits Ethernet DP83848 * Serial number chip DS2401 The board is made as SODIMM200 module. For more info www.ronatix.at or i...@ronetix.at. Signed-off-by: Asen Dimov --- MAINTAINERS|1 + MAKEALL|1 + Makefile |4 + board/ronetix/pm9g45/Makefile | 54 .../at91sam9m10g45ek => ronetix/pm9g45}/config.mk |0 board/ronetix/pm9g45/pm9g45.c | 317 include/configs/pm9g45.h | 218 ++ 7 files changed, 595 insertions(+), 0 deletions(-) create mode 100644 board/ronetix/pm9g45/Makefile copy board/{atmel/at91sam9m10g45ek => ronetix/pm9g45}/config.mk (100%) create mode 100644 board/ronetix/pm9g45/pm9g45.c create mode 100644 include/configs/pm9g45.h diff --git a/MAINTAINERS b/MAINTAINERS index 80057ce..3659947 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -225,6 +225,7 @@ Ilko Iliev PM9261 AT91SAM9261 PM9263 AT91SAM9263 + PM9G45 ARM926EJS (AT91SAM9G45 SoC) Gary Jennejohn diff --git a/MAKEALL b/MAKEALL index beacb5f..ad591d5 100755 --- a/MAKEALL +++ b/MAKEALL @@ -673,6 +673,7 @@ LIST_at91=" \ otc570 \ pm9261 \ pm9263 \ + pm9g45 \ SBC35_A9G20 \ TNY_A9260 \ TNY_A9G20 \ diff --git a/Makefile b/Makefile index d801e25..438580a 100644 --- a/Makefile +++ b/Makefile @@ -2882,6 +2882,10 @@ otc570_config: unconfig pm9263_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs pm9263 ronetix at91 +pm9g45_config : unconfig + @mkdir -p $(obj)include + @$(MKCONFIG) -a pm9g45 arm arm926ejs pm9g45 ronetix at91 + SBC35_A9G20_NANDFLASH_config \ SBC35_A9G20_EEPROM_config \ SBC35_A9G20_config : unconfig diff --git a/board/ronetix/pm9g45/Makefile b/board/ronetix/pm9g45/Makefile new file mode 100644 index 000..dd5b02e --- /dev/null +++ b/board/ronetix/pm9g45/Makefile @@ -0,0 +1,54 @@ +# +# (C) Copyright 2003-2008 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2008 +# Stelian Pop +# Lead Tech Design +# +# 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-y += pm9g45.o + +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) +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/atmel/at91sam9m10g45ek/config.mk b/board/ronetix/pm9g45/config.mk similarity index 100% copy from board/atmel/at91sam9m10g45ek/config.mk copy to board/ronetix/pm9g45/config.mk diff --git a/board/ronetix/pm9g45/pm9g45.c b/board/ronetix/pm9g45/pm9g45.c new file mode 100644 index 000..28221ec --- /dev/null +++ b/board/ronetix/pm9g45/pm9g45.c @@ -0,0 +1,317 @@ +/* + * (C) Copyright 2010 + * Ilko Iliev + * Asen Dimov + * Ronetix GmbH + * + * (C) Copyright 2007-2008 + * Stelian Pop + * Lead Tech Design + * + * 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
Re: [U-Boot] [PATCH V5 10/11] fsl_esdhc: add support for mx51 processor
On Mar 4, 2010, at 1:23 PM, Stefano Babic wrote: > The esdhc controller in the mx51 processor is quite > the same as the one in some powerpc processors > (MPC83xx, MPC85xx). This patches adapts the driver > to support the arm mx51. > > Signed-off-by: Stefano Babic > --- Do you have any time to possible test a few patches to fsl_esdhc on mx51? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 10/11] fsl_esdhc: add support for mx51 processor
Hi Kumar, > On Mar 4, 2010, at 1:23 PM, Stefano Babic wrote: > >> The esdhc controller in the mx51 processor is quite >> the same as the one in some powerpc processors >> (MPC83xx, MPC85xx). This patches adapts the driver >> to support the arm mx51. >> >> Signed-off-by: Stefano Babic >> --- > > Do you have any time to possible test a few patches to fsl_esdhc on mx51? At the moment Stefano is somewhat under water currently - I hope he will resurface beginning next week. What exactly do you want him to test? Cheers Detlev -- ... that every year or so they're going to give you a new release full of 50 000 additional lines of code all written by monkeys. Because they generally follow the ``million monkeys typing, and eventually they'll come up with something useful'' school of system development. -- Richard M. Stallman -- 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] U-Boot Env Vars in Flash and EEPROM at the same time (hybrid env)?
> > Hm... And redundant environment is not safe enough for you? I don't know much about redundant env but now that you mention it ... I do remember seeing something about that in the code. I'll look into it. Thanks! > >> The goal is to not brick a device during a upgrade. Whatever bank you >> are running out of, you upgrade by flashing the bank not being used. >> Once a bank has been upgraded, if I want to select that bank to boot >> ... I would need to modify a environment variable but if it is stored >> in flash then while that sector (a 256k sector in my case) is being >> updated ... if power is lost I just hosed myself. If the environment >> variable I update was stored in EEPROM, then it would be closer to an >> atomic action that couldn't be interrupted with say a power failure. > > EEPROM is not a bit more reliable than NOR, on contrary (read for > example doc/I2C_Edge_Conditions - unless you write-protect your EEPROm > in hardware it is actually way less reliable). I've seen that document and have raised the issues (and discussions I found about it in the archives) to those that "really" want to use the EEPROM. I guess when I first thought about this I had sector erase time of flash vs hitting a single byte of the EEPROM but I wasn't thinking of the I2C transaction. That realization hit me right after I hit send and realized what I posted was heading in the weeds. > > And redundant environment should cover your use case just fine. Cool! I will surely read all I can on it. > >> So what I'm asking about is a Hybrid environment were some variables >> are in flash and some are in EEPROM. The env is read from both >> locations and saveenv writes some vars in flash and some in EEPROM. >> With the current u-boot code I have (1.1.6) the environment choices >> are mutually exclusive (flash, eeprom, nvram etc.) > > This makes little sense to me. Thanks for being gentle. I had temporary insanity. Regards, Brian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 10/11] fsl_esdhc: add support for mx51 processor
Kumar Gala wrote: > > Do you have any time to possible test a few patches to fsl_esdhc on mx51? Hi Kumar, I could test your patches next week, I have no possibility to access to the imx51evk board before. Should be ok for you ? Stefano -- = 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 10/11] fsl_esdhc: add support for mx51 processor
On Mar 18, 2010, at 11:15 AM, Detlev Zundel wrote: > Hi Kumar, > >> On Mar 4, 2010, at 1:23 PM, Stefano Babic wrote: >> >>> The esdhc controller in the mx51 processor is quite >>> the same as the one in some powerpc processors >>> (MPC83xx, MPC85xx). This patches adapts the driver >>> to support the arm mx51. >>> >>> Signed-off-by: Stefano Babic >>> --- >> >> Do you have any time to possible test a few patches to fsl_esdhc on mx51? > > At the moment Stefano is somewhat under water currently - I hope he will > resurface beginning next week. What exactly do you want him to test? I've got a few patches from our internal team for PQ3/eSHDC support and want to make sure they didn't break mx51 support. I'll post the patches once I clean them up (not 100% sure on the rationale for all of them at this point). - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATH] at91: add hwecc method for nand
On Thu, Mar 18, 2010 at 11:55:29AM +0500, Nikolay Petukhov wrote: > + /* move to ECC position if needed */ > + if (eccpos[0] != 0) { > + /* This only works on large pages > + * because the ECC controller waits for > + * NAND_CMD_RNDOUTSTART after the > + * NAND_CMD_RNDOUT. > + * anyway, for small pages, the eccpos[0] == 0 > + */ > + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, > + mtd->writesize + eccpos[0], -1); > + } [snip] > + /* get back to oob start (end of page) */ > + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1); Is the second RNDOUT OK on small page NAND? > + //struct atmel_nand_host *host = nand_chip->priv; Just remove the line. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] TI: Davinci: NAND Driver Cleanup
On Wed, Mar 17, 2010 at 10:03:10AM -0400, Cyril Chemparathy wrote: > Modified to use IO accessor routines consistently. Eliminated volatile usage > to keep checkpatch.pl happy. > > Signed-off-by: Cyril Chemparathy > --- > Minor formatting Applied to u-boot-nand-flash/next -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uboot on microblaze, compilation error
On Thursday 18 March 2010 05:29:19 Michal Simek wrote: > Mike Frysinger wrote: > > On Wednesday 17 March 2010 14:36:38 Horst Gall wrote: > >> I try to compile an actual version of u-boot for xilinx microblaze. > >> > >> The linker ends with the error-message: > >> ... mb-ld.real:u-boot.lds:1: parse error > >> > >> In u-boot main-directory I found the file 'u-boot.lds': > >> OUTPUT_ARCH(1) > >> ENTRY(_start) > >> ... > >> cpu/1/start.o (.text) > >> ... > >> > >> When I change the "1" to "microblaze" it works: > >> OUTPUT_ARCH(microblaze) > >> ENTRY(_start) > >> ... > >> cpu/microblaze/start.o (.text) > >> ... > >> > >> After "make ...config" my modification is overwritten. > >> How can I fix this problem? > > > > add "#undef microblaze" to the top of board/xilinx/microblaze-generic/u- > > boot.lds > > Mike is right. I expect you are using toolchain from EDK where the > problem is. Linux toolchain are ok. i dont think the toolchain is broken. this is standard gcc behavior for all arches. i would check the microblaze gcc port, but it doesnt seem to be mainlined at gcc.gnu.org, so ive lost interest. -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] Attn
Prize Won! (Five hundred and fifty two Thousand pounds sterling), kindly confirm receipt of this email, by forwarding Your Details as stated below to our events manager on Email: rennyharli...@live.com Name/Address/Tel number/Age/Occupation/Country of Origin. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot