[U-Boot] U-boot for Atmel AT91SAM9G20 problem
We have a strange problem running U-boot on an AT91SAM9G20 board. The board uses single 16 bit data bus SDRAM chip. Everything works fine when using 32MB SDRAM chip but U-boot seems to hang when putting in a 64MB SDRAM chip. The Atmel boot strap code was modified to have the correct row and column settings for the SDRAM chip. The hardware is verified to be working fine with JTAG. We can also boot directly to Linux from Atmel boot strap code with some modification. The memtester is used to verify the SDRAM working fine after booting up Linux. So it must be some thing between the boot strap code and U-boot that upsets the U-boot. Can anyone give a hint what might be wrong? Many thanks in advance, ZL ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx: Drop FIT support to allow u-boot image to fit in 512k
On Mar 11, 2010, at 5:27 PM, Wolfgang Denk wrote: > Dear Kumar Gala, > > In message <1268263008-31505-1-git-send-email-ga...@kernel.crashing.org> you > wrote: >> The 36-bit build exceeds the 512k size we have. Removing FIT type image >> support allows us to fit and we dont really use it. >> >> Signed-off-by: Kumar Gala >> --- >> include/configs/P2020DS.h |4 >> 1 files changed, 0 insertions(+), 4 deletions(-) > > Applied directly to fix the curent build problem. Hope this is OK > with you. Yep, that was the idea :) - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] video: Fix console display when splashscreen is used
Dear Wolfgang, On Thu, 11 Mar 2010 23:43:13 +0100 Wolfgang Denk wrote: > In message > <1263294391-15715-1-git-send-email-matthias.weis...@graf-syteco.de> Matthias > Weisser wrote: > > If a splashscreen is used the console scrolling used the > > scroll size as needed when a logo was displayd. This > > patch sets the scroll size to the whole screen if > > a splashscreen is shown. > > > > Signed-off-by: Matthias Weisser > > --- > > drivers/video/cfb_console.c | 21 - > > 1 files changed, 12 insertions(+), 9 deletions(-) ... > What's the status of this patch? Is it on your queue? Yes, in is on my TODO list. Sorry, I'm quite busy now, but I hope to look at this patch soon. Best regards, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx: Drop FIT support to allow u-boot image to fit in 512k
Dear Kumar Gala, In message <1268263008-31505-1-git-send-email-ga...@kernel.crashing.org> you wrote: > The 36-bit build exceeds the 512k size we have. Removing FIT type image > support allows us to fit and we dont really use it. > > Signed-off-by: Kumar Gala > --- > include/configs/P2020DS.h |4 > 1 files changed, 0 insertions(+), 4 deletions(-) Applied directly to fix the curent build problem. Hope this is OK with you. 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 only way to learn a new programming language is by writing pro- grams in it.- Brian Kernighan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc82xx: Remove SL8245 board and the now orpahned sk98lin network driver.
Dear Detlev Zundel, In message <1268054661-25699-1-git-send-email-...@denx.de> you wrote: > This code has compile problems and the company does not even exist any > more. So we take the liberty to drop support for it. > > Signed-off-by: Detlev Zundel > CC: Wolfgang Denk > CC: Ben Warren > --- > > The patch is too large for the ML, so it can be found here: > 0001-mpc82xx-Remove-SL8245-board-and-the-now-orpahned-sk.patch If you had provided an URL here I had applied it now... Hm... I cannot even find it on any of the hosts that come to my mind. Please provide a working URL. 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 "Send lawyers, guns and money..." - Lyrics from a Warren Zevon song ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Cosmetic change - indentation correction.
Dear Michael Zaidman, In message <1267367305-19064-1-git-send-email-michael.zaid...@gmail.com> you wrote: > Signed-off-by: Michael Zaidman > --- > common/miiphyutil.c |4 ++-- > 1 files changed, 2 insertions(+), 2 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 Humans do claim a great deal for that particular emotion (love). -- Spock, "The Lights of Zetar", stardate 5725.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] cmd_mtdparts.c: prevent printbuffer overflows
Dear Anatolij Gustschin, In message <1266967784-12611-1-git-send-email-ag...@denx.de> you wrote: > The length of configured MTDPARTS_DEFAULT string > could be greater than console printbuffer size. > Replace printf() by puts() to avoid potential buffer > overflows. > > Signed-off-by: Anatolij Gustschin > --- > Changes since v2: > - add comment explaining the reason for usage of puts(). > > Changes since v1: > - use puts() instead of printf() as suggested by Wolfgang. > > common/cmd_mtdparts.c | 10 -- > 1 files changed, 8 insertions(+), 2 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 In the future, you're going to get computers as prizes in breakfast cereals. You'll throw them out because your house will be littered with them. - Robert Lucky ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] README.mpc8536ds corrected address
Dear Frans Meulenbroeks, In message <123960-18553-1-git-send-email-fransmeulenbro...@gmail.com> you wrote: > This patch corrects small mistake in the register list. > These registers are 32 bits and this one starts at c not e > > When using the ...c address I can boot from sd, when using the ...e > address I cannot. > > Signed-off-by: Frans Meulenbroeks Please ignore my previous comment. 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 Every little picofarad has a nanohenry all its own. - Don Vonada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] small but important doc patch
Dear Frans Meulenbroeks, In message you wrote: > Dear all, > > Attached a patch for doc/README.mpc8536ds. > This patch corrects small mistake in the register list. > These registers are 32 bits and this one starts at c not e > > When using the ...c address I can boot from sd, when using the ...e > address I cannot. > > *** README.mpc8536ds.orig 2010-02-18 15:29:07.0 +0100 > --- README.mpc8536ds 2010-02-19 11:25:22.0 +0100 > *** > *** 98,104 > | 0x90-0x93 | 0xFF72 | Config Addr 3 | > | 0x94-0x97 | 0x8001 | Config Data 3 | > > ! | 0x98-0x9b | 0xFF72e40e | Config Addr 4 | > | 0x9c-0x9f | 0x0040 | Config Data 4 | > > | 0xa0-0xa3 | 0x4001 | Config Addr 5 | > --- 98,104 > | 0x90-0x93 | 0xFF72 | Config Addr 3 | > | 0x94-0x97 | 0x8001 | Config Data 3 | > > ! | 0x98-0x9b | 0xFF72e40c | Config Addr 4 | > | 0x9c-0x9f | 0x0040 | Config Data 4 | > > | 0xa0-0xa3 | 0x4001 | Config Addr 5 | > > Signed-off-by: Frans Meulenbroeks Manually applied - please get used to using git tools and the correct format for patch submission. 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 No journaling file system can recover your data if the disk dies. - Steve Rago in ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add Yaffs2 image writing support.
Wolfgang Denk wrote:
> Dear Scott,
>
> In message <1263145126-23165-1-git-send-email-liwenha...@gmail.com> Li Wenha
> wrote:
>> Signed-off-by: Li Wenhao
>> ---
>> common/cmd_nand.c | 21 +
>> 1 files changed, 21 insertions(+), 0 deletions(-)
>>
>> diff --git a/common/cmd_nand.c b/common/cmd_nand.c
>> index 075a8af..38c6480 100644
>> --- a/common/cmd_nand.c
>> +++ b/common/cmd_nand.c
>> @@ -390,6 +390,27 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char
>> *argv[])
>> ret = nand->read_oob(nand, off, &ops);
>> else
>> ret = nand->write_oob(nand, off, &ops);
>> +} else if (!strcmp(s, ".yaffs2") && !read) {
>> +mtd_oob_ops_t ops = {
>> +.mode = MTD_OOB_AUTO,
>> +.len = 2048,/* page size */
>> +.ooblen = 64, /* spare size */
>> +};
What about 512 or 4096 byte pages?
>> +
>> +ulong page = 0;
>> +ulong block_size = ops.len + ops.ooblen;
>> +while (page * block_size < size) {
What if "size" is not a multiple of "block_size"? Should not read past
the end of the input array, and should warn the user.
>> +ret = nand->write_oob(nand,
>> + off + page * ops.len,
>> + &ops);
>> +
>> +if (ret) break;
The break should go on its own line, and you should tell the user about
the failure.
>> +
>> +page++;
>> +}
>> } else {
>> printf("Unknown nand command suffix '%s'.\n", s);
>> return 1;
>> --
>> 1.6.3.3
>
> What is the status of this patch? Is it in your queue?
No, I didn't notice it -- the subject doesn't mention NAND, and it
presumably wasn't CCed to me.
Li Wenhao, could you send a new patch addressing the above issues, plus
updated documentation?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] [PATCH] doc: add README for CONFIG_HWCONFIG option
Dear Heiko Schocher, In message <4b725a39.4040...@denx.de> you wrote: > Signed-off-by: Heiko Schocher > --- > changes since v1: > - spelling check from Mike Frysinger, thanks! > > doc/README.hwconfig | 51 > +++ > 1 files changed, 51 insertions(+), 0 deletions(-) > create mode 100644 doc/README.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 Often it is fatal to live too long. - Racine ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TFTP: allow for adjustable retransmission timout
Hi Wolfgang,
On 3/11/2010 2:44 PM, Wolfgang Denk wrote:
> Dear Ben,
>
> In message<1263768953-18819-1-git-send-email...@denx.de> I wrote:
>
>> So far, TFTP negotiated a fixed retransmission timeout of 5 seconds.
>> In some cases (busy networks, slow TFTP servers) this caused very
>> slow transfers. Add new environment variable "tftptimeout" allows to
>> set this timeout. Lowering this value may make downloads succeed
>> faster in networks with high packet loss rates or with unreliable
>> TFTP servers.
>>
>> Signed-off-by: Wolfgang Denk
>> Cc: Ben Warren
>> ---
>> I submitted this patch for RFC in October, but never received any
>> feedback. Let's see if it goes in or gets rejected...
>>
>> README | 19 ---
>> net/tftp.c | 22 +-
>> 2 files changed, 33 insertions(+), 8 deletions(-)
>>
>> diff --git a/README b/README
>> index 22e35c3..13bad41 100644
>> --- a/README
>> +++ b/README
>> @@ -2982,7 +2982,9 @@ environment. As long as you don't save the environment
>> you are
>> working with an in-memory copy. In case the Flash area containing the
>> environment is erased by accident, a default environment is provided.
>>
>> -Some configuration options can be set using Environment Variables:
>> +Some configuration options can be set using Environment Variables.
>> +
>> +List of environment variables (most likely not complete):
>>
>> baudrate - see CONFIG_BAUDRATE
>>
>> @@ -3094,7 +3096,7 @@ Some configuration options can be set using
>> Environment Variables:
>>available network interfaces.
>>It just stays at the currently selected interface.
>>
>> - netretry - When set to "no" each network operation will
>> + netretry - When set to "no" each network operation will
>>either succeed or fail without retrying.
>>When set to "once" the network operation will
>>fail when all the available network interfaces
>> @@ -3110,7 +3112,18 @@ Some configuration options can be set using
>> Environment Variables:
>> tftpdstport - If this is set, the value is used for TFTP's UDP
>>destination port instead of the Well Know Port 69.
>>
>> - vlan - When set to a value< 4095 the traffic over
>> + tftpblocksize - Block size to use for TFTP transfers; if not set,
>> + we use the TFTP server's default block size
>> +
>> + tftptimeout - Retransmission timeout for TFTP packets (in milli-
>> + seconds, minimum value is 1000 = 1 second). Defines
>> + when a packet is considered to be lost so it has to
>> + be retransmitted. The default is 5000 = 5 seconds.
>> + Lowering this value may make downloads succeed
>> + faster in networks with high packet loss rates or
>> + with unreliable TFTP servers.
>> +
>> + vlan - When set to a value< 4095 the traffic over
>>Ethernet is encapsulated/received over 802.1q
>>VLAN tagged frames.
>>
>> diff --git a/net/tftp.c b/net/tftp.c
>> index a02463b..3f402d1 100644
>> --- a/net/tftp.c
>> +++ b/net/tftp.c
>> @@ -211,7 +211,7 @@ TftpSend (void)
>> pkt += 5 /*strlen("octet")*/ + 1;
>> strcpy ((char *)pkt, "timeout");
>> pkt += 7 /*strlen("timeout")*/ + 1;
>> -sprintf((char *)pkt, "%lu", TIMEOUT / 1000);
>> +sprintf((char *)pkt, "%lu", TftpTimeoutMSecs / 1000);
>> debug("send option \"timeout %s\"\n", (char *)pkt);
>> pkt += strlen((char *)pkt) + 1;
>> #ifdef CONFIG_TFTP_TSIZE
>> @@ -413,7 +413,6 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
>> unsigned len)
>> }
>>
>> TftpLastBlock = TftpBlock;
>> -TftpTimeoutMSecs = TIMEOUT;
>> TftpTimeoutCountMax = TIMEOUT_COUNT;
>> NetSetTimeout (TftpTimeoutMSecs, TftpTimeout);
>>
>> @@ -528,10 +527,24 @@ TftpStart (void)
>> {
>> char *ep; /* Environment pointer */
>>
>> -/* Allow the user to choose tftpblocksize */
>> +/*
>> + * Allow the user to choose TFTP blocksize and timeout.
>> + * TFTP protocol has a minimal timeout of 1 second.
>> + */
>> if ((ep = getenv("tftpblocksize")) != NULL)
>> TftpBlkSizeOption = simple_strtol(ep, NULL, 10);
>> -debug("tftp block size is %i\n", TftpBlkSizeOption);
>> +
>> +if ((ep = getenv("tftptimeout")) != NULL)
>> +TftpTimeoutMSecs = simple_strtol(ep, NULL, 10);
>> +
>> +if (TftpTimeoutMSecs< 1000) {
>> +printf("TFTP timeout (%ld ms) too low, "
>> +"set minimum = 1000 ms\n);
>> +TftpTimeoutMSecs = 1000;
>> +}
>> +
>> +debug("TFTP blocksize = %i, timeout = %ld ms\n",
>> +TftpBlkSizeOption, TftpTimeoutMSecs);
>>
>> TftpServerIP = NetServerIP;
>> if (BootFile[0] == '\0') {
>> @@ -588,7 +601,6 @@ T
Re: [U-Boot] [PATCH 2/2] TQM8xx: enable device tree support on all TQM8xx based boards.
Dear Heiko Schocher, In message <4b717633@denx.de> you wrote: > also enable support for CONFIG_HWCONFIG, because we use this > feature for configuring, if this hardware has an fec or not. > So we can adjust the DTS, if there is a fec or not. > > syntax: > > hwconfig=fec:on if hardware has an fec > hwconfig=fec:off if hardware has no fec > > Signed-off-by: Heiko Schocher > Signed-off-by: Wolfgang Denk > --- > include/configs/FPS850L.h |5 + > include/configs/FPS860L.h |5 + > include/configs/HMI10.h|5 + > include/configs/NSCU.h |5 + > include/configs/SM850.h|5 + > include/configs/TK885D.h |5 + > include/configs/TQM823L.h |5 + > include/configs/TQM823M.h |5 + > include/configs/TQM850L.h |5 + > include/configs/TQM850M.h |5 + > include/configs/TQM855L.h |5 + > include/configs/TQM855M.h |5 + > include/configs/TQM860L.h |5 + > include/configs/TQM860M.h |5 + > include/configs/TQM862L.h |5 + > include/configs/TQM862M.h |5 + > include/configs/TQM866M.h |5 + > include/configs/TQM885D.h |5 + > include/configs/virtlab2.h |6 ++ > 19 files changed, 96 insertions(+), 0 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 How many NASA managers does it take to screw in a lightbulb? "That's a known problem... don't worry about it." ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] TQM8xx: add device tree support for TQM8xx based boards.
Dear Heiko Schocher, In message <4b71762d.8070...@denx.de> you wrote: > also use hwconfig feature for configuring, if this hardware > has an fec or not. So we can adjust the DTS, if there is a fec > or not. > > syntax: > > hwconfig=fec:on if hardware has an fec > hwconfig=fec:off if hardware has no fec > > Signed-off-by: Heiko Schocher > Signed-off-by: Wolfgang Denk > --- > board/tqc/tqm8xx/tqm8xx.c | 119 > + > 1 files changed, 119 insertions(+), 0 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 I am a computer. I am dumber than any human and smarter than any ad- ministrator. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] auto-update and DHCP
Dear "Beaman, Thomas", In message <561e05732443a84a9bb3a75519c098f60b5a9...@usa0300ms03.na.xerox.net> you wrote: > > This patch and running dhcp from preboot does work as expected. Is this > a change that should be put back? Done. 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 "It may be that our role on this planet is not to worship God but to create him." - Arthur C. Clarke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mkimage: dont force entry point with xip
Dear Mike Frysinger, In message <1264463411-30105-1-git-send-email-vap...@gentoo.org> you wrote: > Some people boot images with the entry point in the middle of the blob > (like Linux with the head code in discardable .init.text), and there is no > no real requirement that the entry point be right after the mkimage header > when doing XIP, so let people specify whatever they want. If they do need > an entry right after the header, then they still can do that with normal > -e behavior. > > Signed-off-by: Mike Frysinger > --- > tools/mkimage.c | 14 -- > 1 files changed, 0 insertions(+), 14 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 : I've tried (in vi) "g/[a-z]\n[a-z]/s//_/"...but that doesn't : cut it. Any ideas? (I take it that it may be a two-pass sort of solution). In the first pass, install perl. :-) Larry Wall <6...@jpl-devvax.jpl.nasa.gov> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] PPC: Record uboot's relocated address in RAM and show in bdinfo.
Dear richardretanu...@ruggedcom.com, In message <20100125183120.ga11...@richardretanubun.eng.lan> you wrote: > From 58e9529fa466ef79232398aeda69373125eb2aac Mon Sep 17 00:00:00 2001 > From: Richard Retanubun > Date: Fri, 15 Jan 2010 10:06:06 -0500 > Subject: [PATCH] PPC: Record uboot's relocated address in RAM and show in > bdinfo. > > This patch uses gd->relocaddr variable to store uboot's relocated > address in RAM and shows it in bdinfo command. > > This patch moves CONFIG_AMIGAONEG3SE style copying of the address > in board_init_f to just before relocation is actually done. > > Signed-off-by: Richard Retanubun > --- > Hi Detlev, > > Sorry it took a while, got swamped with other tasks. > I see your point and have made a patch per your request. > > Cheers, > > -Richard > > common/cmd_bdinfo.c |1 + > include/asm-ppc/global_data.h |2 -- > lib_ppc/board.c |6 ++ > 3 files changed, 3 insertions(+), 6 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 One difference between a man and a machine is that a machine is quiet when well oiled. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue in drivers/mmc/mmc.c
Dear Quentin Armitage, In message <1263812183.2553.104.ca...@samson.armitage.org.uk> you wrote: > > Herewith patch resubmitted with Signed-off-by line added: Ah. Found it. I just wish you had used the required standard format for patches (i. e. git based). Thanks anyway. 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 Prepare for tomorrow -- get ready. -- Edith Keeler, "The City On the Edge of Forever", stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TFTP: allow for adjustable retransmission timout
Dear Ben,
In message <1263768953-18819-1-git-send-email...@denx.de> I wrote:
> So far, TFTP negotiated a fixed retransmission timeout of 5 seconds.
> In some cases (busy networks, slow TFTP servers) this caused very
> slow transfers. Add new environment variable "tftptimeout" allows to
> set this timeout. Lowering this value may make downloads succeed
> faster in networks with high packet loss rates or with unreliable
> TFTP servers.
>
> Signed-off-by: Wolfgang Denk
> Cc: Ben Warren
> ---
> I submitted this patch for RFC in October, but never received any
> feedback. Let's see if it goes in or gets rejected...
>
> README | 19 ---
> net/tftp.c | 22 +-
> 2 files changed, 33 insertions(+), 8 deletions(-)
>
> diff --git a/README b/README
> index 22e35c3..13bad41 100644
> --- a/README
> +++ b/README
> @@ -2982,7 +2982,9 @@ environment. As long as you don't save the environment
> you are
> working with an in-memory copy. In case the Flash area containing the
> environment is erased by accident, a default environment is provided.
>
> -Some configuration options can be set using Environment Variables:
> +Some configuration options can be set using Environment Variables.
> +
> +List of environment variables (most likely not complete):
>
>baudrate - see CONFIG_BAUDRATE
>
> @@ -3094,7 +3096,7 @@ Some configuration options can be set using Environment
> Variables:
> available network interfaces.
> It just stays at the currently selected interface.
>
> - netretry - When set to "no" each network operation will
> + netretry - When set to "no" each network operation will
> either succeed or fail without retrying.
> When set to "once" the network operation will
> fail when all the available network interfaces
> @@ -3110,7 +3112,18 @@ Some configuration options can be set using
> Environment Variables:
>tftpdstport- If this is set, the value is used for TFTP's UDP
> destination port instead of the Well Know Port 69.
>
> - vlan - When set to a value < 4095 the traffic over
> + tftpblocksize - Block size to use for TFTP transfers; if not set,
> + we use the TFTP server's default block size
> +
> + tftptimeout- Retransmission timeout for TFTP packets (in milli-
> + seconds, minimum value is 1000 = 1 second). Defines
> + when a packet is considered to be lost so it has to
> + be retransmitted. The default is 5000 = 5 seconds.
> + Lowering this value may make downloads succeed
> + faster in networks with high packet loss rates or
> + with unreliable TFTP servers.
> +
> + vlan - When set to a value < 4095 the traffic over
> Ethernet is encapsulated/received over 802.1q
> VLAN tagged frames.
>
> diff --git a/net/tftp.c b/net/tftp.c
> index a02463b..3f402d1 100644
> --- a/net/tftp.c
> +++ b/net/tftp.c
> @@ -211,7 +211,7 @@ TftpSend (void)
> pkt += 5 /*strlen("octet")*/ + 1;
> strcpy ((char *)pkt, "timeout");
> pkt += 7 /*strlen("timeout")*/ + 1;
> - sprintf((char *)pkt, "%lu", TIMEOUT / 1000);
> + sprintf((char *)pkt, "%lu", TftpTimeoutMSecs / 1000);
> debug("send option \"timeout %s\"\n", (char *)pkt);
> pkt += strlen((char *)pkt) + 1;
> #ifdef CONFIG_TFTP_TSIZE
> @@ -413,7 +413,6 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
> unsigned len)
> }
>
> TftpLastBlock = TftpBlock;
> - TftpTimeoutMSecs = TIMEOUT;
> TftpTimeoutCountMax = TIMEOUT_COUNT;
> NetSetTimeout (TftpTimeoutMSecs, TftpTimeout);
>
> @@ -528,10 +527,24 @@ TftpStart (void)
> {
> char *ep; /* Environment pointer */
>
> - /* Allow the user to choose tftpblocksize */
> + /*
> + * Allow the user to choose TFTP blocksize and timeout.
> + * TFTP protocol has a minimal timeout of 1 second.
> + */
> if ((ep = getenv("tftpblocksize")) != NULL)
> TftpBlkSizeOption = simple_strtol(ep, NULL, 10);
> - debug("tftp block size is %i\n", TftpBlkSizeOption);
> +
> + if ((ep = getenv("tftptimeout")) != NULL)
> + TftpTimeoutMSecs = simple_strtol(ep, NULL, 10);
> +
> + if (TftpTimeoutMSecs < 1000) {
> + printf("TFTP timeout (%ld ms) too low, "
> + "set minimum = 1000 ms\n);
> + TftpTimeoutMSecs = 1000;
> + }
> +
> + debug("TFTP blocksize = %i, timeout = %ld ms\n",
> + TftpBlkSizeOption, TftpTimeoutMSecs);
>
> TftpServerIP = NetServerIP;
> if (BootFile[0] == '\0') {
> @@ -588,7 +601,6 @@ TftpStart (void)
>
> puts ("Loading: *\b");
>
> - TftpTimeoutMSecs = TftpRRQTimeoutMSecs;
>
Re: [U-Boot] [PATCH] video: Fix console display when splashscreen is used
Dear Anatolij,
In message <1263294391-15715-1-git-send-email-matthias.weis...@graf-syteco.de>
Matthias Weisser wrote:
> If a splashscreen is used the console scrolling used the
> scroll size as needed when a logo was displayd. This
> patch sets the scroll size to the whole screen if
> a splashscreen is shown.
>
> Signed-off-by: Matthias Weisser
> ---
> drivers/video/cfb_console.c | 21 -
> 1 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
> index 506337b..2391f31 100644
> --- a/drivers/video/cfb_console.c
> +++ b/drivers/video/cfb_console.c
> @@ -260,7 +260,7 @@ void console_cursor (int state);
> #define CURSOR_ON
> #define CURSOR_OFF
> #define CURSOR_SET video_set_hw_cursor(console_col * VIDEO_FONT_WIDTH, \
> - (console_row * VIDEO_FONT_HEIGHT) + VIDEO_LOGO_HEIGHT);
> + (console_row * VIDEO_FONT_HEIGHT) + video_logo_height);
> #endif /* CONFIG_VIDEO_HW_CURSOR */
>
> #ifdef CONFIG_VIDEO_LOGO
> @@ -298,7 +298,7 @@ void console_cursor (int state);
> #define VIDEO_BURST_LEN (VIDEO_COLS/8)
>
> #ifdef CONFIG_VIDEO_LOGO
> -#define CONSOLE_ROWS ((VIDEO_ROWS - VIDEO_LOGO_HEIGHT) /
> VIDEO_FONT_HEIGHT)
> +#define CONSOLE_ROWS ((VIDEO_ROWS - video_logo_height) /
> VIDEO_FONT_HEIGHT)
> #else
> #define CONSOLE_ROWS (VIDEO_ROWS / VIDEO_FONT_HEIGHT)
> #endif
> @@ -349,6 +349,8 @@ static GraphicDevice *pGD;/* Pointer to Graphic
> array */
> static void *video_fb_address; /* frame buffer address */
> static void *video_console_address; /* console buffer start address */
>
> +static int video_logo_height = VIDEO_LOGO_HEIGHT;
> +
> static int console_col = 0; /* cursor col */
> static int console_row = 0; /* cursor row */
>
> @@ -527,7 +529,7 @@ static inline void video_drawstring (int xx, int yy,
> unsigned char *s)
>
> static void video_putchar (int xx, int yy, unsigned char c)
> {
> - video_drawchars (xx, yy + VIDEO_LOGO_HEIGHT, &c, 1);
> + video_drawchars (xx, yy + video_logo_height, &c, 1);
> }
>
>
> /*/
> @@ -620,11 +622,11 @@ static void console_scrollup (void)
> #ifdef VIDEO_HW_BITBLT
> video_hw_bitblt (VIDEO_PIXEL_SIZE, /* bytes per pixel */
>0, /* source pos x */
> - VIDEO_LOGO_HEIGHT + VIDEO_FONT_HEIGHT, /* source pos y
> */
> + video_logo_height + VIDEO_FONT_HEIGHT, /* source pos y
> */
>0, /* dest pos x */
> - VIDEO_LOGO_HEIGHT, /* dest pos y */
> + video_logo_height, /* dest pos y */
>VIDEO_VISIBLE_COLS,/* frame width */
> - VIDEO_VISIBLE_ROWS - VIDEO_LOGO_HEIGHT -
> VIDEO_FONT_HEIGHT /* frame height */
> + VIDEO_VISIBLE_ROWS - video_logo_height -
> VIDEO_FONT_HEIGHT /* frame height */
> );
> #else
> memcpyl (CONSOLE_ROW_FIRST, CONSOLE_ROW_SECOND,
> @@ -1101,7 +1103,7 @@ void logo_plot (void *screen, int width, int x, int y)
>
> int xcount, i;
> int skip = (width - VIDEO_LOGO_WIDTH) * VIDEO_PIXEL_SIZE;
> - int ycount = VIDEO_LOGO_HEIGHT;
> + int ycount = video_logo_height;
> unsigned char r, g, b, *logo_red, *logo_blue, *logo_green;
> unsigned char *source;
> unsigned char *dest = (unsigned char *)screen +
> @@ -1225,6 +1227,7 @@ static void *video_logo (void)
> #endif /* CONFIG_SPLASH_SCREEN_ALIGN */
>
> if (video_display_bitmap (addr, x, y) == 0) {
> + video_logo_height = 0;
> return ((void *) (video_fb_address));
> }
> }
> @@ -1249,7 +1252,7 @@ static void *video_logo (void)
>
> #ifdef CONFIG_CONSOLE_EXTRA_INFO
> {
> - int i, n = ((VIDEO_LOGO_HEIGHT - VIDEO_FONT_HEIGHT) /
> VIDEO_FONT_HEIGHT);
> + int i, n = ((video_logo_height - VIDEO_FONT_HEIGHT) /
> VIDEO_FONT_HEIGHT);
>
> for (i = 1; i < n; i++) {
> video_get_info_str (i, info);
> @@ -1278,7 +1281,7 @@ static void *video_logo (void)
> }
> #endif
>
> - return (video_fb_address + VIDEO_LOGO_HEIGHT * VIDEO_LINE_LEN);
> + return (video_fb_address + video_logo_height * VIDEO_LINE_LEN);
> }
> #endif
>
> --
What's the status of this patch? Is it on your queue?
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
They're usually so busy thinking about what happens next that the
only time they ever find out what is happening now is when they come
to look back on it
Re: [U-Boot] [PATCH] Add Yaffs2 image writing support.
Dear Scott,
In message <1263145126-23165-1-git-send-email-liwenha...@gmail.com> Li Wenha
wrote:
>
> Signed-off-by: Li Wenhao
> ---
> common/cmd_nand.c | 21 +
> 1 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/common/cmd_nand.c b/common/cmd_nand.c
> index 075a8af..38c6480 100644
> --- a/common/cmd_nand.c
> +++ b/common/cmd_nand.c
> @@ -390,6 +390,27 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char
> *argv[])
> ret = nand->read_oob(nand, off, &ops);
> else
> ret = nand->write_oob(nand, off, &ops);
> + } else if (!strcmp(s, ".yaffs2") && !read) {
> + mtd_oob_ops_t ops = {
> + .mode = MTD_OOB_AUTO,
> + .len = 2048,/* page size */
> + .ooblen = 64, /* spare size */
> + };
> +
> + ulong page = 0;
> + ulong block_size = ops.len + ops.ooblen;
> + while (page * block_size < size) {
> + ops.datbuf = addr + page * block_size;
> + ops.oobbuf = ops.datbuf + ops.len;
> +
> + ret = nand->write_oob(nand,
> + off + page * ops.len,
> + &ops);
> +
> + if (ret) break;
> +
> + page++;
> + }
> } else {
> printf("Unknown nand command suffix '%s'.\n", s);
> return 1;
> --
> 1.6.3.3
What is the status of this patch? Is it in your queue?
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 year spent in artificial intelligence is enough to make one believe
in God.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue in drivers/mmc/mmc.c
Dear Quentin Armitage,
In message <1262480450.2820.140.ca...@samson.armitage.org.uk> you wrote:
> There appears to be a path through mmc_read in drivers/mmc/mmc.c where
> malloc'd memory is not freed before exiting mmc_read, although this may
> be a hypothetical situation. It occurs if mmc_set_blocklen() returns a
> non-zero value.
>
> The following patch appears to resolve the issue:
>
> --- o/drivers/mmc/mmc.c 2010-01-03 00:44:41.0 +
> +++ drivers/mmc/mmc.c 2010-01-03 00:46:14.0 +
> @@ -172,7 +172,7 @@ int mmc_read(struct mmc *mmc, u64 src, u
> err = mmc_set_blocklen(mmc, mmc->read_bl_len);
>
> if (err)
> - return err;
> + goto free_buffer;
>
> for (i = startblock; i <= endblock; i++) {
> int segment_size;
As you did not follow up on my request to repostwith you SoB-line
added I went ahead and added the fix myself. Thanks for reporting it.
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
No question is too silly to ask. Of course, some questions are too
silly to to answer... - L. Wall & R. L. Schwartz, _Programming Perl_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC5200: possible to "reserve" embedded flash sectors ?
Dear André Schwarz, In message <1268325452.4803.34.ca...@swa-m460> you wrote: > > hmm - I'm not *that* familiar with all that abbreviations ... have to > ask someone : http://www.abbreviations.com/YMMV > > Hopefully you didn't mean the worst one ;-) The common (and intended) interpretation is Your Mileage May Vary. > > > > Why are you asking? You wrote you have been doing this since 1.1.4, so > > where exactly is your problem? > > The linker script has moved to the CPU directory, i.e. there's no local > linker script anymore. This is because all boards used the same script anyway, so there was no use in keeping multiple copies of the same file. But please note that nothing prevents you to use a local, customized linker script. All you need to do is set it's name in you config.mk (add a line "LDSCRIPT="). > Since I want to submit the board files as soon as the merge window will > open I'm asking for a reasonable way to implement this in current > U-Boot. Use a customized linker script. 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 easiest way to figure the cost of living is to take your income and add ten percent. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-imx51 NAND flash Uncorrectable ECC Error
Hi all! Thanks a lot for all. Finally it happens to be a hardware problem. It is working fine with the new hardware board. We don't have any reason why it was not working with the older board. Perhaps, the chip might have gone bad. Thank you very much to all! :) Now, we have written some smaller jffs2 image (128K) & successfully mounted (ofcourse with some warnings). When we write the whole root file system (16MB), it is giving the following warnings & in the mounted directory, no files are seen. JFFS2 doesn't use OOB jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x: 0xd5ba in stead (several such errors). Further such events for this erase block will not be printed Old JFFS2 bitmask found at 0x00019d64 You cannot use older JFFS2 filesystems with newer kernels Empty flash at 0x0001f7fc ends at 0x0001f800 Has any body else faced these kind of problem? Since the people who have worked in u-boot, might also have worked in kernel. So that i am posting this query here. Anway, Thanks a lot to all the folks...! :) Thanks & Regards, Navaneethan P "Liu Hui-R64343" 03/11/2010 04:46 PM To "Stefano Babic" , "Navaneethan P" cc Subject RE: [U-Boot] u-boot-imx51 NAND flash Uncorrectable ECC Error BR, Jason > -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Stefano Babic > Sent: 2010年3月10日 1:51 > To: Navaneethan P > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] u-boot-imx51 NAND flash Uncorrectable ECC Error > > Navaneethan P wrote: > > * > > *Hi Stefano Babic, > > > > Hi Navaneethan, > > I will kindly ask you to send your questions directly to the > u-boot mailing list, too. > > This information can be helpful for other users of this > board. And you get a large number of developers who could help you. > > > We are using the imx51 babbage board with external NAND flash > > (NAND01GR3B2C , numonyx 8 bit, 2k page size, 1Gbit, 128k > block size) > > connected. > > In the patchset I provided to the ML I will not set the iomux > for NAND, because the babbage board (mx51evk) has no NAND at > all. I suppose you have configured the iomux, too. Anything > else you changed ? > > > We are using the standard NAND driver from u-boot source > > (u-boot-2009.08). Initially nand read was not proper. > > I changed the read operation from auto operation to manual > operation. > > After that time, some patches went to the mainline for the > MXC NAND driver to support revision 1.1 of the Freescale's > NAND controller. As I can see, the MX51 has version 1.1 as > the MX25 (not really checked, but it seems so). MX51 NFC(nand flash controler) is not the MX25 like. There is Big difference.MX51 support auto-mode and the register is 32-bit width While MX25 not that. > > I think it makes sense if you align your code with the actual > u-boot top of tree, that you can find on git.denx.de > > > > > Now, write, read, and erase are seems to be working fine. > > > > When we write the filesystem/linux kernel, there seems to be a byte > > error. Means, one byte mismatch between the written data & > read data. > > > > Example, (written data != read data) > > > > byte at 0x90800457 (0xff) != byte at 0x90c00457 (0x92) byte at > > 0x90800458 (0x92) != byte at 0x90c00458 (0xff) byte at 0x9080045a > > (0xff) != byte at 0x90c0045a (0xea) byte at 0x9080045a > (0xff) != byte > > at 0x90c0045a (0xea) byte at 0x9080045b (0xea) != byte at > 0x90c0045b > > (0x4f) byte at 0x9080045c (0x4f) != byte at 0x90c0045c > (0x00) byte at > > 0x9080045e (0x00) != byte at 0x90c0045e (0xea) > > > > When we read the linux kernel, it is giving Uncorrectable > RS ECC Error Kernel print out Uncorrectable RS ECC Error means the data corruption and the HW ECC of NFC can't correct it. It may due to the NAND driver. BTW, please make sure erase the block first when you operate on MLC nand flash since NOP=1. > > Ok, this is understandable, if the values read are not what > you wanted to write. It seems each byte is written at the > next address. I have not yet an explanation, but maybe > someone else in the ML can help. > > 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 > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM1176: Coexist with other ARM1176 platforms
The current ARM1176 CPU specific code is too specific to the SMDK6400
architecture. The following changes were necessary prerequisites for the
addition of other SoCs based on ARM1176.
Existing board's (SMDK6400) configuration has been modified to keep behavior
unchanged despite these changes.
1. Peripheral port remap configurability
The earlier code had hardcoded remap values specific to s3c64xx in start.S.
This change makes the peripheral port remap addresses and sizes configurable.
2. Skip low level initialization
Ability to skip low level initialization if necessary. Many other platforms
have a similar capability, and this is quite useful during debug/bring-up.
3. U-Boot code relocation support
Most architectures allow u-boot code to run initially at a different
address (possibly in NOR) and then get relocated to its final resting place
in RAM. Added support for this capability in ARM1176 architecture.
4. Disable TCM if necessary
If a ROM based bootloader happened to have initialized TCM, we disable it here
to keep things sane.
5. Remove unnecessary SoC specific includes
ARM1176 code does not really need this SoC specific include. The presence
of this include prevents builds on other ARM1176 archs.
6. ARM926 style MMU disable when !CONFIG_ENABLE_MMU
The original MMU disable code masks out too many bits from the load address
when it tries to figure out the physical address of the jump target label.
Consequently, it ends up branching to the wrong address after disabling the
MMU.
Signed-off-by: Cyril Chemparathy
---
cpu/arm1176/cpu.c |1 -
cpu/arm1176/start.S| 60 ++--
include/configs/smdk6400.h |6
3 files changed, 58 insertions(+), 9 deletions(-)
diff --git a/cpu/arm1176/cpu.c b/cpu/arm1176/cpu.c
index 2c0014f..c0fd114 100644
--- a/cpu/arm1176/cpu.c
+++ b/cpu/arm1176/cpu.c
@@ -33,7 +33,6 @@
#include
#include
-#include
#include
static void cache_flush (void);
diff --git a/cpu/arm1176/start.S b/cpu/arm1176/start.S
index 68a356d..beec574 100644
--- a/cpu/arm1176/start.S
+++ b/cpu/arm1176/start.S
@@ -1,5 +1,5 @@
/*
- * armboot - Startup Code for S3C6400/ARM1176 CPU-core
+ * armboot - Startup Code for ARM1176 CPU-core
*
* Copyright (c) 2007 Samsung Electronics
*
@@ -35,7 +35,6 @@
#ifdef CONFIG_ENABLE_MMU
#include
#endif
-#include
#if !defined(CONFIG_ENABLE_MMU) && !defined(CONFIG_SYS_PHY_UBOOT_BASE)
#define CONFIG_SYS_PHY_UBOOT_BASE CONFIG_SYS_UBOOT_BASE
@@ -145,6 +144,7 @@ reset:
*
*
*/
+#ifndef CONFIG_SKIP_LOWLEVEL_INIT
/*
* we do sys-critical inits only at reboot,
* not when booting from ram!
@@ -170,6 +170,8 @@ cpu_init_crit:
bic r0, r0, #0x0087 @ clear bits 7, 2:0 (B--- -CAM)
orr r0, r0, #0x0002 @ set bit 2 (A) Align
orr r0, r0, #0x1000 @ set bit 12 (I) I-Cache
+
+#ifdef CONFIG_ENABLE_MMU
/* Prepare to disable the MMU */
adr r1, mmu_disable_phys
/* We presume we're within the first 1024 bytes */
@@ -187,20 +189,60 @@ mmu_disable:
nop
nop
mov pc, r2
+mmu_disable_phys:
+#else
+ mcr p15, 0, r0, c1, c0, 0
#endif
-mmu_disable_phys:
+#ifdef CONFIG_DISABLE_TCM
+ /*
+* Disable the TCMs
+*/
+ mrc p15, 0, r0, c0, c0, 2 /* Return TCM details */
+ cmp r0, #0
+ beq skip_tcmdisable
+ mov r1, #0
+ mov r2, #1
+ tst r0, r2
+ mcrne p15, 0, r1, c9, c1, 1 /* Disable Instruction TCM if present*/
+ tst r0, r2, LSL #16
+ mcrne p15, 0, r1, c9, c1, 0 /* Disable Data TCM if present*/
+skip_tcmdisable:
+#endif
+#endif
+
+#ifdef CONFIG_PERIPORT_REMAP
/* Peri port setup */
- ldr r0, =0x7000
- orr r0, r0, #0x13
+ ldr r0, =CONFIG_PERIPORT_BASE
+ orr r0, r0, #CONFIG_PERIPORT_SIZE
mcr p15,0,r0,c15,c2,4 @ 256M (0x7000 - 0x7fff)
+#endif
/*
* Go setup Memory and board specific bits prior to relocation.
*/
bl lowlevel_init /* go setup pll,mux,memory */
+#endif /* CONFIG_SKIP_LOWLEVEL_INIT */
+
+#ifndef CONFIG_SKIP_RELOCATE_UBOOT
+relocate: /* relocate U-Boot to RAM */
+ adr r0, _start /* r0 <- current position of code */
+ ldr r1, _TEXT_BASE /* test if we run from flash or RAM */
+ cmp r0, r1 /* don't reloc during debug */
+ beq stack_setup
+
+ ldr r2, _armboot_start
+ ldr r3, _bss_start
+ sub r2, r3, r2 /* r2 <- size of armboot*/
+ add r2, r0, r2 /* r2 <- source end address */
+
+copy_loop:
+ ldmia r0!, {r3-r10} /* copy from
Re: [U-Boot] MPC5200: possible to "reserve" embedded flash sectors ?
Wolfgang, > Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz, > > In message <1268321602.4803.24.ca...@swa-m460> you wrote: > > > > is there any reasonable way to reserve some small flash sectors embedded > > inside U-Boot for other usage ? > > Yes, of course there is. For example, in many board configurations we > use such small sectors for the environment (then called "embedded > environment"). > > > Example : > > > > 2 sectors @ 0-16k U-boot start including initial code @ reset vector. > > 1 sector @ 16k-24k e.g. environment. > > 2 sectors @ 24k-40k reserved (small linux mtd partitions). > > ? sectors @ 40k+ remaining U-Boot code. > > This can easily be done. > > > Back with U-Boot 1.1.4 I used the board's local u-boot.lds like this : > > Right. The linker script is the pace that needs to be tweaked. > > > The primary goal is to create a dedicated sector holding the auto/boot > > script being available through a nested mtd partition. > > Well, I think there might be more efficient ways to acchieve this, but > YMMV. hmm - I'm not *that* familiar with all that abbreviations ... have to ask someone : http://www.abbreviations.com/YMMV Hopefully you didn't mean the worst one ;-) > > Why are you asking? You wrote you have been doing this since 1.1.4, so > where exactly is your problem? The linker script has moved to the CPU directory, i.e. there's no local linker script anymore. Since I want to submit the board files as soon as the merge window will open I'm asking for a reasonable way to implement this in current U-Boot. What's your favorite way of doing this ? I'd be happy to implement it that way. > > Best regards, > > Wolfgang Denk > Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
On Thu, Mar 11, 2010 at 4:11 AM, Martin Krause wrote: > Joakim Tjernlund wrote on Wednesday, March 10, 2010 6:29 PM: >> "Martin Krause" wrote on 2010/03/10 17:52:40: >>> >>> Hi Jocke, >>> >>> Joakim Tjernlund wrote on Wednesday, March 10, 2010 5:36 PM: > Andrew Dyer wrote on Wednesday, March 10, 2010 4:50 PM: [SNIP] > > Hm, on the wikipedia article for the 'variable length arrays' > (VLA) I read, that the GNU C compiler always uses the stack for > this type of variables. So I think, if the stack is working for > all other local variables, it should not be an memory layout > problem. > > Eventually the following might be interesting. I have tried to make > the VLA much bigger, to eliminate 'normal' buffer overrun problems: > > char filename[dirent.namelen + 1 + 2048] > > But this leads to the same result, U-Boot dies. With an fixed > length array of comparable length it works: > > char filename[2048] > > Both (local) variables should end up on the stack. Try alloca to see if stack allocs works at all in your toolchain. >>> >>> I didn't find alloca(), so I tried it with __builtin_alloca(). >> >> Did you do #include ? > > Yes, but then I get an "ext2fs.c:31:20: error: alloca.h: No such file > or directory" error. I'm using an older Version of U-Boot, though ... > (U-Boot 1.3.4). > >> __builtin_alloca should work too. >> >>> The result is the same as with variable length array - u-boot >>> dies during the ext2ls command call. >>> >>> Does this mean, my toolchain is broken? I use ELDK4.2 for ARM. >> >> I belive so, how many bytes is in dirent.namelen? alloca can not > > In the first call 2 bytes, in the second call 3 bytes, and then > U-Boot dies. So, should I send a message to the gcc mailing list explaining the issue? >> handle to big allocs (arch dependant) and will silently fail is it is >> too big. >> >> VLA might be impl. using alloca so if alloca is broken, probably VLA >> too. > > This sounds plausible. > > I compiled the original code with VLA with ELDK4.1 and there > everything works. And also the '__builtin_alloca' Version works > with ELDK4.1. > > Regards, > Martin > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC5200: possible to "reserve" embedded flash sectors ?
Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz, In message <1268321602.4803.24.ca...@swa-m460> you wrote: > > is there any reasonable way to reserve some small flash sectors embedded > inside U-Boot for other usage ? Yes, of course there is. For example, in many board configurations we use such small sectors for the environment (then called "embedded environment"). > Example : > > 2 sectors @ 0-16k U-boot start including initial code @ reset vector. > 1 sector @ 16k-24k e.g. environment. > 2 sectors @ 24k-40k reserved (small linux mtd partitions). > ? sectors @ 40k+ remaining U-Boot code. This can easily be done. > Back with U-Boot 1.1.4 I used the board's local u-boot.lds like this : Right. The linker script is the pace that needs to be tweaked. > The primary goal is to create a dedicated sector holding the auto/boot > script being available through a nested mtd partition. Well, I think there might be more efficient ways to acchieve this, but YMMV. Why are you asking? You wrote you have been doing this since 1.1.4, so where exactly is your problem? 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 It all seemed, he thought, to be rather a lot of trouble to go to just sharpen a razor blade. - Terry Pratchett, _The Light Fantastic_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Debugging u-boot
Dear =?iso-8859-1?Q?Bj=F8rnar_Syverstad?=, In message <3f466ddf09a55d46858fc39b22de56f23a30259...@pat.prediktor.no> you wrote: > > I am trying to debug the u-boot with help of gdb + eclipse. Useing the > phy3250_config. > > The problem is that when debugging, the listed source code seems to be out of > sync. > The debugger pointer in the source code, seems not to point to the correct > source code. Did you read the manual, for example here: http://www.denx.de/wiki/view/DULG/DebuggingTricks > The assembler windows shows typical this: > > ... > It does miss the code in "" So what? Eventually the compiler optimized this code away, of shifted it to some other place where you don;t expect it. > I did look at u-boot.lds and did not find any debug sections. The linker script has little to do with that. > Is there something parameters to make to add more debug information? I don't think that this is your problem. 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 Motto of the Electrical Engineer: Working computer hardware is a lot like an erect penis: it stays up as long as you don't fuck with it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] MPC5200: possible to "reserve" embedded flash sectors ?
Hi,
is there any reasonable way to reserve some small flash sectors embedded
inside U-Boot for other usage ?
Example :
2 sectors @ 0-16k U-boot start including initial code @ reset vector.
1 sector @ 16k-24k e.g. environment.
2 sectors @ 24k-40k reserved (small linux mtd partitions).
? sectors @ 40k+ remaining U-Boot code.
Back with U-Boot 1.1.4 I used the board's local u-boot.lds like this :
[snip]...
.text:
{
cpu/mpc5xxx/start.o (.text)
lib_ppc/board.o (.text)
lib_ppc/interrupts.o (.text)
lib_ppc/ticks.o (.text)
. = DEFINED(env_offset) ? env_offset : .;
common/environment.o (.text)
. = DEFINED(CFG_ENV_ADD_SPACE) ? (. + CFG_ENV_ADD_SPACE) : .;
*(.text)
*(.fixup)
[snip]...
The primary goal is to create a dedicated sector holding the auto/boot
script being available through a nested mtd partition.
Since the flash is completely used up there's no chance using sectors
outside of U-Boot.
Any hints are welcome.
Regards,
André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner,
Hans-Joachim Reich
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MAINTAINERS: sort the list of ARM Maintainers by last name
Minkyu Kang wrote: > Dear Tom, > > On 8 March 2010 16:22, Minkyu Kang wrote: >> Signed-off-by: Minkyu Kang >> --- >> MAINTAINERS | 22 +++--- >> 1 files changed, 11 insertions(+), 11 deletions(-) >> > > Please apply this patch to arm tree. > Or, please give your opinion. > Sorry, I have been busy. I will review this today. Tom > Thanks > Minkyu Kang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Debugging u-boot
Hello, I am trying to debug the u-boot with help of gdb + eclipse. Useing the phy3250_config. The problem is that when debugging, the listed source code seems to be out of sync. The debugger pointer in the source code, seems not to point to the correct source code. The assembler windows shows typical this: 0x00013f0c : ldrr1, [pc, #480] ; 0x140f4 0x00013f14 : ldrr3, [r1, #120]; 0x78 0x00013f1c : orrr3, r3, #1 0x00013f20 : strr3, [r1, #120] ; 0x78 It does miss the code in "" It is the same problem useing only gdb. So it seems to me that some debug information is missing in the elf file u-boot. I did look at u-boot.lds and did not find any debug sections. I do find some debug information on the u-boot elf file in readelf/objdump. Bellow is an output of some part of the compiling. And there it have -g and -Os flags. arm-none-linux-gnueabi-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -msoft-float -fno-strict-aliasing -fno-common -ffixed-r8 -D__KERNEL__ -DTEXT_BASE=0x -I/opt/ltib/ltib-10-1-1a-sv/rpm/BUILD/u-boot-2009.03-rc1/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.1.2/include -pipe -DCONFIG_ARM -D__ARM__ -march=armv5te -mabi=aapcs-linux -mno-thumb-interwork -march=armv5te -Wall -Wstrict-prototypes -fno-stack-protector -c -o lowlevelsys_init.o lowlevelsys_init.c Is there something parameters to make to add more debug information? Best Regards Bjørnar Syverstad ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MAINTAINERS: sort the list of ARM Maintainers by last name
Dear Tom, On 8 March 2010 16:22, Minkyu Kang wrote: > Signed-off-by: Minkyu Kang > --- > MAINTAINERS | 22 +++--- > 1 files changed, 11 insertions(+), 11 deletions(-) > Please apply this patch to arm tree. Or, please give your opinion. Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Support for SMSC Phy LAN8700C
I would like to know if there is any version of u-boot that supports SMSC PHY LAN8700C. I have interfaced it with AT91RM9200 (MII interface). If u-boot supports then I will go over to that particular version. Regards Raj Nikumbh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-imx51 NAND flash Uncorrectable ECC Error
BR, Jason > -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Stefano Babic > Sent: 2010年3月10日 1:51 > To: Navaneethan P > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] u-boot-imx51 NAND flash Uncorrectable ECC Error > > Navaneethan P wrote: > > * > > *Hi Stefano Babic, > > > > Hi Navaneethan, > > I will kindly ask you to send your questions directly to the > u-boot mailing list, too. > > This information can be helpful for other users of this > board. And you get a large number of developers who could help you. > > > We are using the imx51 babbage board with external NAND flash > > (NAND01GR3B2C , numonyx 8 bit, 2k page size, 1Gbit, 128k > block size) > > connected. > > In the patchset I provided to the ML I will not set the iomux > for NAND, because the babbage board (mx51evk) has no NAND at > all. I suppose you have configured the iomux, too. Anything > else you changed ? > > > We are using the standard NAND driver from u-boot source > > (u-boot-2009.08). Initially nand read was not proper. > > I changed the read operation from auto operation to manual > operation. > > After that time, some patches went to the mainline for the > MXC NAND driver to support revision 1.1 of the Freescale's > NAND controller. As I can see, the MX51 has version 1.1 as > the MX25 (not really checked, but it seems so). MX51 NFC(nand flash controler) is not the MX25 like. There is Big difference.MX51 support auto-mode and the register is 32-bit width While MX25 not that. > > I think it makes sense if you align your code with the actual > u-boot top of tree, that you can find on git.denx.de > > > > > Now, write, read, and erase are seems to be working fine. > > > > When we write the filesystem/linux kernel, there seems to be a byte > > error. Means, one byte mismatch between the written data & > read data. > > > > Example, (written data != read data) > > > > byte at 0x90800457 (0xff) != byte at 0x90c00457 (0x92) byte at > > 0x90800458 (0x92) != byte at 0x90c00458 (0xff) byte at 0x9080045a > > (0xff) != byte at 0x90c0045a (0xea) byte at 0x9080045a > (0xff) != byte > > at 0x90c0045a (0xea) byte at 0x9080045b (0xea) != byte at > 0x90c0045b > > (0x4f) byte at 0x9080045c (0x4f) != byte at 0x90c0045c > (0x00) byte at > > 0x9080045e (0x00) != byte at 0x90c0045e (0xea) > > > > When we read the linux kernel, it is giving Uncorrectable > RS ECC Error Kernel print out Uncorrectable RS ECC Error means the data corruption and the HW ECC of NFC can't correct it. It may due to the NAND driver. BTW, please make sure erase the block first when you operate on MLC nand flash since NOP=1. > > Ok, this is understandable, if the values read are not what > you wanted to write. It seems each byte is written at the > next address. I have not yet an explanation, but maybe > someone else in the ML can help. > > 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 > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
Joakim Tjernlund wrote on Wednesday, March 10, 2010 6:29 PM: > "Martin Krause" wrote on 2010/03/10 17:52:40: >> >> Hi Jocke, >> >> Joakim Tjernlund wrote on Wednesday, March 10, 2010 5:36 PM: Andrew Dyer wrote on Wednesday, March 10, 2010 4:50 PM: [SNIP] Hm, on the wikipedia article for the 'variable length arrays' (VLA) I read, that the GNU C compiler always uses the stack for this type of variables. So I think, if the stack is working for all other local variables, it should not be an memory layout problem. Eventually the following might be interesting. I have tried to make the VLA much bigger, to eliminate 'normal' buffer overrun problems: char filename[dirent.namelen + 1 + 2048] But this leads to the same result, U-Boot dies. With an fixed length array of comparable length it works: char filename[2048] Both (local) variables should end up on the stack. >>> >>> Try alloca to see if stack allocs works at all in your toolchain. >> >> I didn't find alloca(), so I tried it with __builtin_alloca(). > > Did you do #include ? Yes, but then I get an "ext2fs.c:31:20: error: alloca.h: No such file or directory" error. I'm using an older Version of U-Boot, though ... (U-Boot 1.3.4). > __builtin_alloca should work too. > >> The result is the same as with variable length array - u-boot >> dies during the ext2ls command call. >> >> Does this mean, my toolchain is broken? I use ELDK4.2 for ARM. > > I belive so, how many bytes is in dirent.namelen? alloca can not In the first call 2 bytes, in the second call 3 bytes, and then U-Boot dies. > handle to big allocs (arch dependant) and will silently fail is it is > too big. > > VLA might be impl. using alloca so if alloca is broken, probably VLA > too. This sounds plausible. I compiled the original code with VLA with ELDK4.1 and there everything works. And also the '__builtin_alloca' Version works with ELDK4.1. Regards, Martin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
